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

Thu Jan 22 06:12:20 EST 2015

Hi,

I upgraded switch software from c2960-lanbasek9-mz.122-35.SE5.bin to
c2960-lanbasek9-mz.150-2.SE7.bin and after that the 64 byte frames
including the 802.1q
field(https://www.cloudshark.org/captures/6c935c056545) are no longer
counted as "Undersize" in "sh int Gi0/23 counters errors" output.

So my hypothesis is that router, which will route packet to 802.1q
sub-interface, checks the total length field in IPv4 header and if it
is <42 bytes, then the router will pad the packet with zeros besides
inserting the 802.1q field. Now if the switch receives a 64 byte frame
including the 802.1q header on a trunk port, the switch has to pop the
4 byte 802.1q header, pad the frame with 4 bytes and send a 64 byte
frame out of an access port. Is my train of thought correct?

thanks,
Martin

On Tue, Jan 20, 2015 at 1:24 PM, Martin T <m4rtntns at gmail.com> wrote:
> 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/
>>