[c-nsp] Cisco 1841 with IOS 12.4(3i) does not pad frame to 68 bytes if it adds the 802.1q field?

Martin T m4rtntns at gmail.com
Tue Jan 20 05:23:15 EST 2015


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

interface GigabitEthernet0/23
 switchport mode trunk
 media-type rj45
 speed auto 100
 spanning-tree portfast trunk
 spanning-tree bpduguard enable

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
 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 -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

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.


More information about the cisco-nsp mailing list