Hi, I have a following network-topology:
T60_laptop[eth2] <-> [Fa0/1]C1841_1[Fa0/0] <-> [Fa0/1]C1841_2[Fa0/0] <-> [Fa0/0]C1841_3[Fa0/1] <-> passive_network_tap <-> [Gi0/23]C2960[Gi0/1] <-> [eth0]HP_laptop "C2960" interface Gi0/23 is a 802.1q trunk interface with very simple configuration: interface GigabitEthernet0/23 switchport mode trunk media-type rj45 speed auto 100 spanning-tree portfast trunk spanning-tree bpduguard enable end Likewise, there is a 802.1q sub-interface configured to "C1841_3": interface FastEthernet0/1 no ip address duplex auto speed auto ! interface FastEthernet0/1.2 encapsulation dot1Q 2 ip address 192.168.23.254 255.255.255.0 no ip redirects ip nat inside no ip virtual-reassembly no snmp trap link-status ! Now if I send ICMP "echo request" messages with no payload(ping 192.168.23.1 -s 0) from "T60_laptop" to "HP_laptop", then "T60_laptop" puts following frames onto wire: https://www.cloudshark.org/captures/19068f94522c As seen from the packet capture, packets are padded with zeros correctly to 64 bytes(includes FCS). So far everything looks good. Now the packet is sent over IPsec tunnel to "C1841_3" router, which needs to send the packet over Fa0/1.2 interface. This means that "C1841_3" has to add the IEEE 802.1q field. Now if I packet-capture those ICMP "echo request" messages originated from "T60_laptop" with a passive network tap right before they reach the "C2960" switch port Gi0/23, then "C1841_3" puts following frames onto wire: https://www.cloudshark.org/captures/6c935c056545 As seen from the packet-capture, 4-byte 802.1q field is added to the frame as it should, but for some reason, packet is not padded to 68 bytes, but left to 64 bytes(again, capture results include the FCS). WS-C2960G-24TC-L switch port Gi0/23 receives those frames, counts those properly as "TrunkFramesRx" according to "sh int Gi0/23 counters trunk", but also counts those frames as "Undersize" according to "sh int Gi0/23 counters errors": WS-C2960G-24TC-L#sh int Gi0/23 counters errors Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize Gi0/23 0 0 0 0 12 Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Giants Gi0/23 0 0 0 0 0 0 0 WS-C2960G-24TC-L# This makes sense as after popping the 802.1q field, the frame is 60 bytes in length. Am I correct that this is an erroneous behavior and thus a bug in "C1841_3" router? I also checked with Cisco "Bug Search" for bugs for 1841 platform and c1841-advsecurityk9-mz.124-3i.bin software release, but found nothing related. Has anyone seen something like this before? In addition, what I also find strange, is that "C2960" switch forwards frames to "HP_laptop" instead of dropping those.. Or maybe it is the switch which should pad the frame back to 64 bytes according to RFC's and thus the router behaves correctly? Please let me know if additional information is needed. thanks, Martin _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/