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

WS-C2960G-24TC-L supports only 802.1q "encapsulation":


WS-C2960G-24TC-L(config-if)#switchport trunk ?
  allowed  Set allowed VLAN characteristics when interface is in trunking mode
  native   Set trunking native characteristics when interface is in trunking
           mode
  pruning  Set pruning VLAN characteristics when interface is in trunking mode

WS-C2960G-24TC-L(config-if)#do sh int Gi0/23 trunk

Port        Mode         Encapsulation  Status        Native vlan
Gi0/23      on           802.1q         trunking      1

Port        Vlans allowed on trunk
Gi0/23      1-4094

Port        Vlans allowed and active in management domain
Gi0/23      1-4

Port        Vlans in spanning tree forwarding state and not pruned
Gi0/23      1-4
WS-C2960G-24TC-L(config-if)#



regards,
Martin

On 1/20/15, Rich Davies <rich.davies at gmail.com> wrote:
>
> On your 2960 trunk port you may be missing
>
> switchport trunk encapsulation dot1q
>
>
> Sent from my iPhone
>
>> On Jan 20, 2015, at 5:23 AM, Martin T <m4rtntns at gmail.com> wrote:
>>
>> 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 at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>