Marian, thanks for confirming this!
regards, Martin On 1/22/15, Marian Ďurkovič <m...@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 <m4rtn...@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.dav...@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 <m4rtn...@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@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@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/