09-12-2012 02:34 AM - edited 03-07-2019 08:50 AM
Hi,
I used three modules of WS-X6148-GE-TX (48 copper gigabit ports) in my Catalyst 6509 box and "show inventory" output give me that:
Aerobus_cat6509#show inventory | i 6148
NAME: "2", DESCR: "WS-X6148-GE-TX 48 port 10/100/1000mb EtherModule Rev. 7.2"
NAME: "3", DESCR: "WS-X6148-GE-TX 48 port 10/100/1000mb EtherModule Rev. 5.0"
NAME: "9", DESCR: "WS-X6148-GE-TX 48 port 10/100/1000mb EtherModule Rev. 2.0"
As you can see, there are three kind of revisions for that module: 2.0, 5.0 and 7.2.
Someone can tell me what the difference between those revisions? Is there some hardware changes? Or different software firmware?
I consider this because I face a lot of problem exactly with nine-slot module with revision 2.0 and wondering if my problems linked with old revision and maybe I could upgrade this.
Thank you.
Solved! Go to Solution.
09-16-2012 02:58 AM
Hi Vasiliy,
The short version of this Revision Number is that due to some internal product identification changes, it is changed the way we programmed the idproms of these linecards.
I have gone through this issue and found that that the line card WS-X6148-GE-TX which has less than HW rev 3.0 experience below issue.
This issue is matching with the known Bug CSCeb67650
CSCeb67650 - WS-X6548-GE-TX & WS-X6148-GE-TX may drop frames on egress
Packets destined out the WS-X6548-GE-TX or the WS-X6148-GE-TX that are less than 64 bytes will be dropped. This can occur when a device forwards a packet that is 60 bytes and the 4 byte dot1q tag is to added to create a valid
64 byte packet. When the tag is removed the packet is 60 bytes. If the destination is out a port on the WS-X6548-GE-TX or the WS-X6148-GE-TX it will be dropped by the linecard.
Additionally, if packets are received on an interface that does not have a minimum MTU of 64 bytes (e.g. ATM,POS) and are destined out the WS-X6548-GE-TX or the WS-X6148-GE-TX it will be dropped by the linecard.
Workaround / Solution
Regards,
Aru
*** Please rate if this post is useful ***
09-16-2012 02:58 AM
Hi Vasiliy,
The short version of this Revision Number is that due to some internal product identification changes, it is changed the way we programmed the idproms of these linecards.
I have gone through this issue and found that that the line card WS-X6148-GE-TX which has less than HW rev 3.0 experience below issue.
This issue is matching with the known Bug CSCeb67650
CSCeb67650 - WS-X6548-GE-TX & WS-X6148-GE-TX may drop frames on egress
Packets destined out the WS-X6548-GE-TX or the WS-X6148-GE-TX that are less than 64 bytes will be dropped. This can occur when a device forwards a packet that is 60 bytes and the 4 byte dot1q tag is to added to create a valid
64 byte packet. When the tag is removed the packet is 60 bytes. If the destination is out a port on the WS-X6548-GE-TX or the WS-X6148-GE-TX it will be dropped by the linecard.
Additionally, if packets are received on an interface that does not have a minimum MTU of 64 bytes (e.g. ATM,POS) and are destined out the WS-X6548-GE-TX or the WS-X6148-GE-TX it will be dropped by the linecard.
Workaround / Solution
Regards,
Aru
*** Please rate if this post is useful ***
09-17-2012 06:34 AM
Hi Aru,
Thank you a lot for you time spent for looking this issue and found the bug describing this behavior.
Actually I face a problem when two host can`t communicate each other on the same same because ARP-reply do not return to sender. As I know, ARP-reply is 60-bytes ethernet-frame packet, so it will comparing with 60\64-bytes frames concerning the bug description.
I wonder if I can do RMA for this modules and solve the problem this way, because I spent two months for identification a problem and found a solution.
09-17-2012 07:08 AM
Hi Vasiliy,
Thanks for your kind response. Sure, please raise the RMA for the module which will help to fix this issue.
At the same time, If you would like to reconfirm, you execute the below commands and verify the detail.
Example assumes port 9/33 is the outgoing port
Native IOS:
version 12.1(19)E and older
Router#remote command switch show asicreg revati slot 9 port 33 error-count
00A0: 0000
00A1: 0000
00A2: 0000
00A3: 002D
00A4: 0000
00A5: 0008
00A6: 0000
00A7: 0008
00A8: 0000
00A9: 0000
version 12.1(19)E1 and later
Router#remote command switch show platform hardware asicreg revati slot 9 port 33 error-count
00A0: 0000
00A1: 0000
00A2: 0000
00A3: 002D
00A4: 0000
00A5: 0008
00A6: 0000
00A7: 0008
00A8: 0000
00A9: 0000
Registers that we are concerned with are the egress length drop counters 00A6 & 00A7:
00A6: = 0000
00A7: = 0021
If the values are non-zero in either register, then packets have been dropped due to this problem.
The counters are cleared on read. This means, once you execute the command, the value of the counter is reset to zero.
Could you share the serial number of the module as well..
Regards,
Aru
09-17-2012 07:15 AM
Hi Aru,
Here are all my X6148 Rev2.0 modules:
Aerobus_cat6509#show idprom module 9
IDPROM for module #9
(FRU is '48 port 10/100/1000mb EtherModule')
OEM String = 'Cisco Systems'
Product Number = 'WS-X6148-GE-TX'
Serial Number = 'SAD07260258'
Manufacturing Assembly Number = '73-8670-04'
Manufacturing Assembly Revision = 'A0'
Hardware Revision = 2.0
Current supplied or consumed = -2.47A
SB-C6509-2#show idprom module 6
IDPROM for module #6
(FRU is '48 port 10/100/1000mb EtherModule')
OEM String = 'Cisco Systems'
Product Number = 'WS-X6148-GE-TX'
Serial Number = 'SAD072803VX'
Manufacturing Assembly Number = '73-8670-04'
Manufacturing Assembly Revision = 'A0'
Hardware Revision = 2.0
Current supplied or consumed = -2.47A
SB-C6509-2#show idprom module 7
IDPROM for module #7
(FRU is '48 port 10/100/1000mb EtherModule')
OEM String = 'Cisco Systems'
Product Number = 'WS-X6148-GE-TX'
Serial Number = 'SAD07240267'
Manufacturing Assembly Number = '73-8670-04'
Manufacturing Assembly Revision = 'A0'
Hardware Revision = 2.0
Current supplied or consumed = -2.47A
SB-C6509-2#show idprom module 8
IDPROM for module #8
(FRU is '48 port 10/100/1000mb EtherModule')
OEM String = 'Cisco Systems'
Product Number = 'WS-X6148-GE-TX'
Serial Number = 'SAD072803V1'
Manufacturing Assembly Number = '73-8670-04'
Manufacturing Assembly Revision = 'A0'
Hardware Revision = 2.0
Current supplied or consumed = -2.47A
SB-C6509-1#show idprom module 6
IDPROM for module #6
(FRU is '48 port 10/100/1000mb EtherModule')
OEM String = 'Cisco Systems'
Product Number = 'WS-X6148-GE-TX'
Serial Number = 'SAD072400LA'
Manufacturing Assembly Number = '73-8670-04'
Manufacturing Assembly Revision = 'A0'
Hardware Revision = 2.0
Current supplied or consumed = -2.47A
SB-C6509-1#show idprom module 8
IDPROM for module #8
(FRU is '48 port 10/100/1000mb EtherModule')
OEM String = 'Cisco Systems'
Product Number = 'WS-X6148-GE-TX'
Serial Number = 'SAD0726021U'
Manufacturing Assembly Number = '73-8670-04'
Manufacturing Assembly Revision = 'A0'
Hardware Revision = 2.0
Current supplied or consumed = -2.47A
SB-C6509-1#show idprom module 9
IDPROM for module #9
(FRU is '48 port 10/100/1000mb EtherModule')
OEM String = 'Cisco Systems'
Product Number = 'WS-X6148-GE-TX'
Serial Number = 'SAD0726023X'
Manufacturing Assembly Number = '73-8670-04'
Manufacturing Assembly Revision = 'A0'
Hardware Revision = 2.0
Current supplied or consumed = -2.47A
And what if 00A6 and 00A7 registers show zeros (first output, before clearing) on all ports for those modules?
09-17-2012 08:02 AM
Hi Vasiliy,
These two registers are the egress length drop counters 00A6 & 00A7. if you are seeing non-Zero, indecates then packets have been dropped due to this problem (experiencing packet loss on outgoing ports of the module 'WS-X6148-GE-TX'. otherwise it doesnt impact.
I verified the below detail from the output and it looks like below points are matching with this issue,
If you experiencing packet loss on outgoing ports of all module which has HW Ver 2.0, please verify the counters once again, if you see that issue, you can raise the request for RMA.
Regards,
Aru
09-18-2012 12:19 AM
Hi Aru,
Unfortunately, I do not seeing non-Zero numbers at any ports in all my X6148 Rev2.0 modules, so I seems to be another issue which I experience with my packet loss.
09-18-2012 12:59 AM
Hi Vasiliy,
Thanks for your kind response. Yes, if you are not seeing non-zero numbers on the counters, then it could be different issue. Not related with the above mentioned problem.
Regards,
Aru
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide