[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
Fri Jan 23 06:51:05 EST 2015
Marian,
thanks for confirming this!
regards,
Martin
On 1/22/15, Marian Ďurkovič <md at bts.sk> wrote:
> The minimum frame size on ethernet is 64 bytes, no matter if it contains
> 802.1q
> header or two of them (QinQ), or none. So yes, if the switch removes 802.1q
> header, it should add 4 padding bytes instead to be compliant. And it should
> not
> count 64 byte frames including 802.1q header as undersize.
>
> Regards,
>
> M.
>
> On Thu, 22 Jan 2015 11:12:20 +0000, Martin T wrote
>> 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/
>> >>
>> _______________________________________________
>> 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/
>
>
More information about the cisco-nsp
mailing list