cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
828
Views
0
Helpful
1
Replies

How to prevent undesired reordering within a 4500 switch?

tempest26
Level 1
Level 1

Hi,

4500 configured as layer 2 switch.

I am testing a cisco WS-C4948-10GE in the lab.

I have found a unique "feature" of the switch where frames are re-ordered only when the following conditions are met:

1. The frames are of an unknown format (ie not IP)

2. The frames have the same source MAC address but different destination MAC address. And are sent interleaved. Destination A, B, A, B etc.

3. The frames of the two streams are of the same length but incrementing. 64,64,65,65....1510,1510,64,64,...etc.

4. The switch has learnt the MAC address

When the frames lengths wrap around the sequence 1510,1510,64,64,65,65 is reordered to 1510,64,1510,64,65,65

If the protocol is IP then the problem goes away.

If the MAC addresses are unknown then the problem goes away.

If the length limits are closer then the problem goes away.

I have looked at the switch architecture and I can only assue that the two frames are pushed into seperate Tx queues somehow when the conditions above are not met.

Relevant config;

version 12.2

boot system flash bootflash:cat4500-ipbase-mz.122-31.SGA.bin

boot system flash bootflash:cat4000-i5s-mz.122-25.EWA10.bin

no qos rewrite ip dscp

qos map dscp 0 1 2 3 4 5 6 7 to tx-queue 3

qos map dscp 8 9 10 11 12 13 14 15 to tx-queue 3

qos map dscp 16 17 18 19 20 21 22 23 to tx-queue 3

qos map dscp 24 25 26 27 28 29 30 31 to tx-queue 3

qos map dscp 48 49 50 51 52 53 54 55 to tx-queue 3

qos map dscp 56 57 58 59 60 61 62 63 to tx-queue 3

qos map dscp 8 9 10 11 12 13 14 15 to cos 0

qos map dscp 16 17 18 19 20 21 22 23 to cos 0

qos map dscp 24 25 26 27 28 29 30 31 to cos 0

qos map dscp 32 33 34 35 36 37 38 39 to cos 0

qos map dscp 40 41 42 43 44 45 46 47 to cos 0

qos map dscp 48 49 50 51 52 53 54 55 to cos 0

qos map dscp 56 57 58 59 60 61 62 63 to cos 0

qos map cos 1 2 3 4 5 6 7 to dscp 0

vtp interface default

no errdisable detect cause pagp-flap

no errdisable detect cause dtp-flap

no errdisable detect cause link-flap

no errdisable detect cause l2ptguard

no errdisable detect cause gbic-invalid

no errdisable detect cause dhcp-rate-limit

no errdisable detect cause arp-inspection

errdisable recovery interval 30

!

no spanning-tree vlan 100,126,999-1001,2000-2001

system mtu 1552

interface GigabitEthernet1/23

switchport trunk encapsulation dot1q

switchport trunk native vlan 999

no switchport trunk native vlan tag

switchport trunk allowed vlan 999,1001,2001

switchport mode trunk

switchport nonegotiate

qos trust cos

udld port aggressive

no cdp enable

!

interface GigabitEthernet1/24

switchport trunk encapsulation dot1q

switchport trunk native vlan 999

no switchport trunk native vlan tag

switchport trunk allowed vlan 999,1001,2001

switchport mode trunk

switchport nonegotiate

qos trust cos

no cdp enable

!

interface GigabitEthernet1/25

switchport trunk encapsulation dot1q

switchport trunk native vlan 999

no switchport trunk native vlan tag

switchport trunk allowed vlan 999,1001,2001

switchport mode trunk

switchport nonegotiate

qos trust cos

no cdp enable

!

monitor session 1 source interface Gi1/23 rx

monitor session 1 destination interface Gi1/25 encapsulation dot1q ingress vlan 999

1 Reply 1

Dale Miller
Cisco Employee
Cisco Employee

Are some packet in the stream being punted to the CPU? You mention if you use IP it goes away, unknown unicast and it goes away. I suspect that is becuase the packets are handled in HW forwarding path. It is common to see out of order packets when some packets in a stream are punted to SW. The delay encountered through the SW path, wont get the packet out on the wire before the next packet in the stream is handled in HW.

There is a built in sniffer to show you what is punted to the CPU while testing the flow in the broken state.

- debug platform packet all receive buffer

- show platform cpu packet buffered

If you see the packets that are out of order hitting the CPU that is your cause. Next you will want to find out why and I would need details on the frames your sending. The output of the commands above would be helpful.

Regards,

Dale