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

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