cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2248
Views
15
Helpful
7
Replies

Different revisons of module WS-X6148-GE-TX for Catalyst 6500.

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.

1 Accepted Solution

Accepted Solutions

Arumugam Muthaiah
Cisco Employee
Cisco Employee

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

  • A hardware modification has been implemented on these modules that eliminate the packet drop problem
  • For the WS-X6148-GE-TX which has higher HW Rev 3.0 and above doesnt affect due to this issue

Regards,

Aru

*** Please rate if this post is useful ***

Regards, Aru *** Please rate if the post useful ***

View solution in original post

7 Replies 7

Arumugam Muthaiah
Cisco Employee
Cisco Employee

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

  • A hardware modification has been implemented on these modules that eliminate the packet drop problem
  • For the WS-X6148-GE-TX which has higher HW Rev 3.0 and above doesnt affect due to this issue

Regards,

Aru

*** Please rate if this post is useful ***

Regards, Aru *** Please rate if the post useful ***

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.

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

Regards, Aru *** Please rate if the post useful ***

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?

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,

  1. All the serial number of the module
  2. Manufacture numbers (73-8670-04)
  3. Hardware version (HW 2.0)

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

Regards, Aru *** Please rate if the post useful ***

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.

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

Regards, Aru *** Please rate if the post useful ***
Review Cisco Networking products for a $25 gift card