Community discussions

 
Zoolander06
newbie
Topic Author
Posts: 25
Joined: Thu Jan 03, 2019 5:26 pm

Switch rule doesn't work

Fri Nov 08, 2019 3:21 pm

Hi,

In order to establish a PPPoE connection, my provider ask me two things :
- using VLAN4001
- using priority code 0

For the VLAN, no problem, I've created a vlan interface and my pppoe interface over this vlan interface.

For the priority code, I've created a switch rule :
/interface ethernet switch rule add dst-mac-address=<mac_address_of_ont>/FF:FF:FF:FF:FF:FF new-vlan-priority=0 ports=switch1-cpu switch=switch1
I've managed to get the mac adress by making wireshark traces of traffic going through my ether1 interface.
I also added vlan 4001 to ports ether1 and switch1-cpu (not sure that's useful).

But, sadly, nothing change, when I make new traces of what's going through ether1, the PCP bits are unchanged.
I've tried to modify the rule to set other priority, just to check, but it doesn't seem to do anything.

What am I missing ???

Thanks

Joris

But, when I make wireshark traes
 
pe1chl
Forum Guru
Forum Guru
Posts: 5913
Joined: Mon Jun 08, 2015 12:09 pm

Re: Switch rule doesn't work

Fri Nov 08, 2019 3:57 pm

Priority 0 is the default so there is nothing you need to do.
Switch rules do not work on all switches (or cannot do the same thing on all switches) so you need to check that first.
https://wiki.mikrotik.com/wiki/Manual:S ... p_Features
 
Zoolander06
newbie
Topic Author
Posts: 25
Joined: Thu Jan 03, 2019 5:26 pm

Re: Switch rule doesn't work

Fri Nov 08, 2019 5:17 pm

According to Wikipedia (https://en.wikipedia.org/wiki/IEEE_P802.1p), priority code 1, with PCP value 0 is the default.
I think my provider need a priority code of 0 (PCP value of 1) since he specifically ask for that.

Yet, some providers ask for a priority code 2, and what I did doesn't work with 2 either. So the question remain, what did I do wrong ?
 
sindy
Forum Guru
Forum Guru
Posts: 3897
Joined: Mon Dec 04, 2017 9:19 pm

Re: Switch rule doesn't work

Sat Nov 09, 2019 6:29 pm

So the question remain, what did I do wrong ?
First of all, @pe1chl's question remains, which routerboard model are we talking about?

Second, do you use an SFP or a copper interface with some kind of media converter to connect to the ONU? The thing is that on many models the SFP cage is connected directly to the CPU so the switch chip is not in the path at all.

Third, you say you have "set VLAN on the switch port", which is unlikely to be correct, as when the ISP requires a use of a particular VLAN, they expect that frames belonging to this VLAN to be tagged on the link. So the ONU-facing interface of the switch chip should have a different pvid than 4001, otherwise the frames of VID 4001 would be sent out tagless even if they eventually come tagged from the CPU.

So state your device model, and export the current configuration following the hint in my automatic signature.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
Zoolander06
newbie
Topic Author
Posts: 25
Joined: Thu Jan 03, 2019 5:26 pm

Re: Switch rule doesn't work

Tue Nov 12, 2019 11:17 am

Hi Sindy,

You're right I forgot the routerboard model : it's a rb2011, and since I use the ether1 interface, I think the rules should work.
Like I said, another provider ask me to tag the packets with priority code 2 (for this one, no mistakes are possible), and I just tried it on another rb2011, it doesn't work either when I check the packets content in Wireshark.
The destination mac address is the same as in my rule, but the priority is unchanged.

Here is an export of my conf :
/interface bridge
add admin-mac=74:4D:28:5A:48:5C auto-mac=no comment=defconf name=bridge
add arp=proxy-arp name=bridge-voip
/interface vlan
add interface=ether1 name=vlan2900 vlan-id=2900
/interface pppoe-client
add allow=chap disabled=no interface=vlan2900 keepalive-timeout=disabled \
    name=sdsl-vlan2900 user=ipxxxxxxxxxxxxx@yyyy.zzz
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=default-dhcp ranges=192.168.88.10-192.168.88.254
add name=vpn-pool ranges=192.168.250.201-192.168.250.220
/ip dhcp-server
add address-pool=default-dhcp disabled=no interface=bridge name=defconf
/ppp profile
add local-address=192.168.250.254 name=VPN remote-address=vpn-pool
/interface bridge port
add bridge=bridge-voip comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether6
add bridge=bridge comment=defconf interface=ether7
add bridge=bridge comment=defconf interface=ether8
add bridge=bridge comment=defconf interface=ether9
add bridge=bridge comment=defconf interface=ether10
add bridge=bridge comment=defconf interface=sfp1
add bridge=bridge-voip interface=ether3
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface ethernet switch rule
add dst-mac-address=06:47:01:00:00:00/FF:FF:FF:FF:FF:FF new-vlan-priority=2 \
    ports=switch1-cpu switch=switch1
/interface list member
add comment=defconf interface=bridge list=LAN
add interface=bridge-voip list=LAN
add interface=sdsl-vlan2900 list=WAN
/interface ovpn-server server
set certificate=Server enabled=yes
/interface pptp-server server
set default-profile=default enabled=yes max-mru=1480 max-mtu=1480
/ip address
add address=192.168.88.1/24 comment="lan admin" interface=bridge network=\
    192.168.88.0
add address=192.168.250.254/24 interface=bridge-voip network=192.168.250.0
/ip dhcp-client
add comment=defconf dhcp-options=hostname,clientid disabled=no interface=\
    ether1
/ip dhcp-server network
add address=192.168.88.0/24 comment=defconf gateway=192.168.88.1
add address=192.168.250.0/24 gateway=192.168.250.254
/ip dns
set allow-remote-requests=yes servers=8.8.8.8,8.8.4.4
/ip dns static
add address=192.168.88.1 name=router.lan
/ip firewall filter
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
    in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
    ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
    ipsec-policy=out,ipsec
add action=accept chain=forward comment=\
    "defconf: accept established,related, untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf:  drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
    connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    ipsec-policy=out,none out-interface-list=WAN
/ip firewall service-port
set sip disabled=yes
/ip route
add check-gateway=ping distance=1 gateway=sdsl-vlan2900
/system clock
set time-zone-name=Europe/Rome
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN
/tool sniffer
set file-limit=100000KiB file-name=prio.pcap filter-interface=ether1 \
    memory-limit=1000KiB
And what I see in wireshark is that packets coming from 06:47:01:00:00:00 are tagged with VLAN2900 and priority 2, but packets going to 06:47:01:00:00:00 are tagged with VLAN2900 and priority 0.

As I understand, the switch rule should change priority of my outgoing packets no ?

Thanks,

Joris
 
pe1chl
Forum Guru
Forum Guru
Posts: 5913
Joined: Mon Jun 08, 2015 12:09 pm

Re: Switch rule doesn't work

Tue Nov 12, 2019 11:20 am

Why do you apply the rule to switch1-cpu and not to ether1 ?
 
sindy
Forum Guru
Forum Guru
Posts: 3897
Joined: Mon Dec 04, 2017 9:19 pm

Re: Switch rule doesn't work

Tue Nov 12, 2019 11:25 am

Why do you apply the rule to switch1-cpu and not to ether1 ?
Because the rules are executed only at ingress.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
CZFan
Forum Guru
Forum Guru
Posts: 1434
Joined: Sun Oct 09, 2016 8:25 pm
Location: South Africa, Randburg
Contact:

Re: Switch rule doesn't work

Tue Nov 12, 2019 12:01 pm

Not that it matters in this situation, but the sfp interface of the RB2011 is connected to switch chip 8327.

@sindy, would you mind to elaborate a little on the post "cause rules are executed on ingress only" As per @pe1chl post, if you set the rulke to ether 1, then surely that is still ingress, i.e. as it enters the interface?
MTCNA, MTCTCE, MTCRE & MTCINE
 
sindy
Forum Guru
Forum Guru
Posts: 3897
Joined: Mon Dec 04, 2017 9:19 pm

Re: Switch rule doesn't work

Tue Nov 12, 2019 1:58 pm

Not that it matters in this situation, but the sfp interface of the RB2011 is connected to switch chip 8327.
Not only that it does matter, it's a keystone - if the cage was connected directly to CPU, like at the hEX something, the switch chip rules wouldn't be applicable at all.
@sindy, would you mind to elaborate a little on the post "cause rules are executed on ingress only" As per @pe1chl post, if you set the rule to ether 1, then surely that is still ingress, i.e. as it enters the interface?
The frame header modification the OP needs to do must happen on the way from the CPU to the wire, and on this direction, the CPU-facing port of the switch is an ingress one, and the sfp1 port is the egress one. At least on 8327, the switch chip only matches the ingress frames against the rules' match criteria and eventually changes the frame contents or the way it is forwarded.

But there's the Atheros proprietary tag which the CPU uses to tell the swicth chip which egress port to use, and I had a case when it did interfere with the switch chip rules matching on VLAN tag on CPU port. That's why I am so doubtful regarding a chance to selectively modify only frames towards sfp1, because they cannot be identified by destination MAC address which is ff:ff:ff:ff:ff:ff for the PADI and some unicast one for the rest of the PPPoE traffic, and with the proprietary tag in place, matching of any of the switch rules' match fields other than MAC addresses may be problematic.

So a rule on the switch1-cpu port which always sets the priority field of the VLAN tag to the desired value does work (I've tested it on 8327 in hAP ac²), but matching on VLAN ID did not work for me on CPU port. And when I tested, there was a software bridge configured, which should not change the format of the frame being sent by CPU to the switch chip but I am not sure about this and cannot test right now.

Another important point is that the switch chip rule will only adjust the priority field in the VLAN tag if the tag is already present in the frame. This will definitely work if the frame comes from the CPU already tagged, using software /interface vlan interface=sfp1 vlan-id=4001 name=sfp1.4001 and attaching the /interface pppoe-client to interface=sfp1.4001 rather than to interface=sfp1 at RouterOS level. It may also work if the VLAN tag gets added by the switch chip itself, by setting /interface ethernet switch port set switch1-cpu default-vlan-id=4001 while the default-vlan-id of port sfp1 remains 1 (or anything else but 4001), but that requires to set the default-vlan-id to 4001 also on all other switch chip ports except sfp1, as otherwise you cut their connection to the CPU for tagless frames. But the latter method may be the solution of "how to get rid of the problem of setting the priority field of the frames on which I don't want it", and costs the least CPU power if successful.

Regarding Wireshark - I strongly recommend to sniff into file using another Mikrotik and only use Wireshark to analyse the files, because most Windows network card drivers silently cut the VLAN tags, and some Linux drivers do the same, so winpcap/libpcap/npcap get the frames already modified from the driver.

The last resort would be to create a dedicated bridge, make sfp1 its only member port, attach the /interface vlan mentioned above to the new bridge rather than to sfp1 directly, and use /interface bridge rule instead of /interface ethernet switch rule. We made this work on RB4011 recently, but on the much weaker CPU of the 2011, the throughput drop may be too painful.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
CZFan
Forum Guru
Forum Guru
Posts: 1434
Joined: Sun Oct 09, 2016 8:25 pm
Location: South Africa, Randburg
Contact:

Re: Switch rule doesn't work

Tue Nov 12, 2019 5:04 pm

Thank you @sindy,

The reason I said it does not matter in this situation, IIRC, the OP said he uses ether 1 and not SFP interface

I hope and pray the Mikrotik community do not lose you as a member
MTCNA, MTCTCE, MTCRE & MTCINE
 
sindy
Forum Guru
Forum Guru
Posts: 3897
Joined: Mon Dec 04, 2017 9:19 pm

Re: Switch rule doesn't work

Tue Nov 12, 2019 5:34 pm

The reason I said it does not matter in this situation, IIRC, the OP said he uses ether 1 and not SFP interface
Yeah, sorry, I've missed the statement about ether1 being used (it often happens to me that when one piece of information I was waiting for is present in a message, I miss the bits I did not expect). But the rest of what I wrote remains valid: all changes to the frames being sent by the Tik to the ONU have be done by switch rules acting on switch1-cpu port, regardless whether the ONU-facing port is sfp1 or ether1 with a media converter. I hope the OP could bite his way through my complex post :)

Now as thinking about it, there actually should be a way to make the switch rule on switch1-cpu port selective exactly in the case where there is no /interface bridge configured on the CPU with ether1 as a member port, so the /interface pppoe-client or /interface vlan vlan-id=4001 are attached directly to ether1, because in this case, the frames sent by CPU via ether1 will have ether1's MAC address as a source one, whereas other frames will have the MAC address of the bridge as source, and the bridge inherits its MAC address from one of its member ports none of which will be ether1. So the rule could be matching on ether1's MAC address as src-mac-address in this case.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
anav
Forum Guru
Forum Guru
Posts: 3100
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Switch rule doesn't work

Tue Nov 12, 2019 6:00 pm

Reminds me of an ISP provider I have that uses vlanxx for internet and vlanyy for TV and to make the first connection (get DHCP on router for TV) the router had to be able to return/recognize a specific 802.1p? code ( I think it was priority 2 but cannot recall). The zyxel router I had didn't have this until a firmware update. I applied the update and through wireshark and data captures realized that the firmware applied the standard to everywhere except the initial connection/conversation with the ISP........... still fuming so many hours lost LOL.
It would interesting to know if the MT RouterOS addresses this issue.

(PS Using wireshark made me realize that to understand networking one must a beach of knowledge whereas all I know is perhaps a grain of sand and @CZFAN yes Sindy has a big bucket and concur, super glad he does)
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
sindy
Forum Guru
Forum Guru
Posts: 3897
Joined: Mon Dec 04, 2017 9:19 pm

Re: Switch rule doesn't work

Tue Nov 12, 2019 6:26 pm

Using wireshark made me realize that to understand networking one must a beach of knowledge whereas all I know is perhaps a grain of sand
Actually Wireshark is great also to build the understanding of networking because it visualizes how the frames and packets actually look like. So it allows you to see how a packet (an L3 structure) gets transported using a frame (L2 structure), that the destination IP address stays the same all the way from source device to destination device (unless something uses dst-nat to change it) whereas the destination MAC address changes each time a router forwards the packet from one interface to another.

And then it's the "love your tool" approach, where you need to realize and accept (and worst of all, remember) also the drawbacks and limitations of the devices and software you use. Some hours ago I was debugging a VoIP unidirectional silence, where packets were routed by a hAP ac² so "hardware-accelerated bridging" should have no impact, but nevertheless I could not see them in the sniff. So I remembered that half a year ago I have seen this elsewhere, set hw=no on the /interface bridge port row, and voilà, the mystery disappeared (or, rather, was replaced by another one, why the heck does hw=yes make the sniffer ignore the frames although they do get from the switch port to the CPU).

BTW, as I've noticed that many U.S. and Canada - based forum users are actually of Russian, Ukrainian etc. origin, don't you happen to understand Russian? I have a presentation on the networking basics for technical people who never had anything to do with packet networks but I haven't converted it to English yet...
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
anav
Forum Guru
Forum Guru
Posts: 3100
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Switch rule doesn't work

Tue Nov 12, 2019 6:51 pm

The only Russian I know involves a russian dude called smirnov (smirnoff due to escaping to France).
So please do a translation sometime soon. :-)
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)

Who is online

Users browsing this forum: No registered users and 104 guests