Community discussions

MikroTik App
 
OndrejHolas
newbie
Topic Author
Posts: 26
Joined: Mon Jul 30, 2018 5:54 pm

Bridge - invalid VLAN ethertype

Thu Sep 26, 2019 1:24 pm

HW: RB 3011UiAS
ROS: 7.0beta1

Simple VLAN-aware bridge setup with ether9 as trunk port a ether10 as access port:

[admin@rb3011] > /int bri exp
/interface bridge
add name=bridge0 protocol-mode=none pvid=998 vlan-filtering=yes
/interface bridge port
add bridge=bridge0 edge=yes frame-types=admit-only-untagged-and-priority-tagged ingress-filtering=yes interface=ether10 pvid=6
add bridge=bridge0 frame-types=admit-only-vlan-tagged ingress-filtering=yes interface=ether9 pvid=998
/interface bridge vlan
add bridge=bridge0 tagged=ether9 untagged=ether10 vlan-ids=6
add bridge=bridge0 untagged=ether9 vlan-ids=998

Test machine has eth3 connected to RB3011/ether9 and eth4 to RB3011/ether10. After sending untagged frame to ether10 (access port) using scapy:

>>> frame=Ether(dst="ff:ff:ff:ff:ff:ff")/ARP(psrc="192.168.0.1",pdst="192.168.0.2")
>>> sendp(frame,iface="eth4")
.
Sent 1 packets.

The frame leaving eth4 is untagged ARP query as seen in tcpdump:

# tcpdump -i eth4 -nnvvXX not stp
tcpdump: listening on eth4, link-type EN10MB (Ethernet), capture size 262144 bytes
11:44:55.567452 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.2 tell 192.168.0.1, length 28
        0x0000:  ffff ffff ffff 6470 0205 f70c 0806 0001  ......dp........
        0x0010:  0800 0604 0001 6470 0205 f70c c0a8 0001  ......dp........
        0x0020:  0000 0000 0000 c0a8 0002                 ..........

RB3011 forwards the frame to ether9 (trunk port) and adds 802.1Q tag, but ethertype in Ethernet header is byte-swapped (0x0081 instead of 0x8100 at offset 12). Apparently missing or overused host-to-network endianness conversion:

# tcpdump -i eth3 -nnvvXX not stp
tcpdump: listening on eth3, link-type EN10MB (Ethernet), capture size 262144 bytes
11:44:55.567688 64:70:02:05:f7:0c IP > ff:ff:ff:ff:ff:ff Null Information, send seq 4, rcv seq 3, Flags [Command], length 50
        0x0000:  ffff ffff ffff 6470 0205 f70c 0081 0006  ......dp........
        0x0010:  0806 0001 0800 0604 0001 6470 0205 f70c  ..........dp....
        0x0020:  c0a8 0001 0000 0000 0000 c0a8 0002 0000  ................
        0x0030:  0000 0000 0000 0000 0000 0000 0000 0000  ................

In reverse direction, tagged frame sent to ether9 (trunk port):

>>> frame2=Ether(dst="ff:ff:ff:ff:ff:ff")/Dot1Q(vlan=6)/ARP(psrc="192.168.0.2",pdst="192.168.0.1")
>>> sendp(frame2,iface="eth3")
.
Sent 1 packets.

# tcpdump -i eth3 -nnvvXX not stp
tcpdump: listening on eth3, link-type EN10MB (Ethernet), capture size 262144 bytes
11:46:48.007801 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.2, length 28
        0x0000:  ffff ffff ffff 6470 0205 f70c 8100 0006  ......dp........
        0x0010:  0806 0001 0800 0604 0001 6470 0205 f70c  ..........dp....
        0x0020:  c0a8 0002 0000 0000 0000 c0a8 0001       ..............

The frame is forwarded to ether10 (access port) with correct VLAN decapsulation:

# tcpdump -i eth4 -nnvvXX not stp
tcpdump: listening on eth4, link-type EN10MB (Ethernet), capture size 262144 bytes
11:46:48.008016 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.2, length 46
        0x0000:  ffff ffff ffff 6470 0205 f70c 0806 0001  ......dp........
        0x0010:  0800 0604 0001 6470 0205 f70c c0a8 0002  ......dp........
        0x0020:  0000 0000 0000 c0a8 0001 0000 0000 0000  ................
        0x0030:  0000 0000 0000 0000 0000 0000            ............

After downgrading to 6.45.6, the same configuration works well in both directions, frame sent to ether10 (access port) is forwarded to ether9 (trunk port) with correctly encoded ethertype (0x8100 at offset 12):

# tcpdump -i eth3 -nnvvXX not stp
tcpdump: listening on eth3, link-type EN10MB (Ethernet), capture size 262144 bytes
12:11:23.969532 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.2 tell 192.168.0.1, length 46
        0x0000:  ffff ffff ffff 6470 0205 f70c 8100 0006  ......dp........
        0x0010:  0806 0001 0800 0604 0001 6470 0205 f70c  ..........dp....
        0x0020:  c0a8 0001 0000 0000 0000 c0a8 0002 0000  ................
        0x0030:  0000 0000 0000 0000 0000 0000 0000 0000  ................

Ondrej
 
OndrejHolas
newbie
Topic Author
Posts: 26
Joined: Mon Jul 30, 2018 5:54 pm

Re: Bridge - invalid VLAN ethertype

Thu Sep 26, 2019 6:56 pm

As 7.0beta2 was released to public moments ago, I've just re-tested scenarios described above on beta2 (ROS and firmware), observed behavior applies to 7.0beta2 as well, no change between beta1 and beta2.

Ondrej
 
OndrejHolas
newbie
Topic Author
Posts: 26
Joined: Mon Jul 30, 2018 5:54 pm

Re: Bridge - invalid VLAN ethertype

Wed Oct 23, 2019 5:45 pm

I've just briefly tested this scenario in beta3 and it seems to be fixed, although changelist does not mention it.

Ondrej

Who is online

Users browsing this forum: No registered users and 4 guests