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 : 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

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

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 ?

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.

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 : 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

Why do you apply the rule to switch1-cpu and not to ether1 ?

Why do you apply the rule to switch1-cpu and not to ether1 ?

Because the rules are executed only at ingress.

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?

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.

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

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.

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)

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...

The only Russian I know involves a russian dude called smirnov (smirnoff due to escaping to France).
So please do a translation sometime soon.

So @Zoolander06, here are the results from my lab:

• at switch1-cpu port, the rules can only match on src-mac-address and dst-mac-address, the other match conditions fail as indicated earlier, likely because the format of the ingress frame is specific at the CPU port of the switch. However, the rules match regardless whether the Ethernet/SFP interface is a member port of a software bridge or not. Which is in a way obvious as even if the interface is a member port of the bridge, it is the (software) bridge forwarding table which chooses the initerface to use, so the CPU tags the egress frame with the interface ID in either case to tell the switch which interface to egress it through. So to make the switch chip set the 802.1p priority field of the 802.1Q tag to binary value 2 only if the packet is sent out via ether1, the rule looks as follows:
  /interface ethernet switch rule
  add new-vlan-priority=2 ports=switch1-cpu src-mac-address=mac:add:ress:of:eth:er1/FF:FF:FF:FF:FF:FF switch=switch1
  It only works if something else causes the 802.1Q tag to be added to the resulting egress frame. The new-vlan-priority action alone doesn't create the 802.1Q tag (which is surprising, because such a tag with the VLAN-ID field set to 0 is a standard way to convey the 802.1p information to the recipient and tell it to treat the frame as if it wasn't VLAN-tagged, i.e. the recipient is free to set the VLAN-ID field of the tag to the default VLAN ID of its ingress port).
• to tag the pppoe frames with the 802.1Q tag on their way from the CPU to the line, and untag them in the opposite direction, two methods can be used:
  1. the software one, where you don't touch the default VLAN-related settings of the switch chip, add a software VLAN interface to the ethernet/sfp port, and attach the pppoe client interface to the vlan interface rather than directly to the ethernet/sfp port:
     /interface vlan
     add interface=ether1 vlan-id=4001 name=ether1.4001
     /inteface pppoe-client set [find interface=ether1] interface=ether1.4001
     This way, the tagging (on egress) and untagging (on ingress) operation will be done in software (so will cost some CPU power), so the frame will ingress from CPU via the CPU port of the switch already tagged, and the switch will not add or strip the VLAN tag, but the rule will modify the priority field in the tag. Tagged frames which ingress from the wire/fiber will be forwarded without modification to the CPU port.
  2. the hardware one, where you keep the pppoe client interface attached directly to ether1 and it will be the switch chip which will tag the tagless frames that will ingress via the CPU port as it will forward them to the egress ethernet/sfp one and untag the frames forwarded from the ingress ethernet/sfp port to the CPU one. These settings require that the vlan handling on the switch chip is activated on all ports, so if possible, configure the device via the other switch chip, serial port, or wireless interface - or at least activate the safe mode before you issue the commands below, and deactivate it a minute after you execute them and don't get disconnected. Assuming you use no other VLANs on switch chip 1's ports, you start from a default state of the switch chip configuration, and you use ether1 to connect to the ONU, the setup will look as follows:
     /interface ethernet switch vlan
     add vlan-id=4001 ports=switch1-cpu,ether1,ether2,ether3,ether4,ether5,sfp1 switch=switch1
     /interface ethernet switch port
     set switch1-cpu,ether2,ether3,ether4,ether5,sfp1 default-vlan-id=4001 vlan-mode=secure
     set ether1 vlan-mode=secure
     Once you set the vlan-mode of an ingress port to secure, the switch chip starts tagging frames which egress through any port whose default-vlan-id differs from the one of the ingress port, that's why you have to set the default-vlan-id of all ports except ether1 to 4001.

@anav, check the spam folder of your inbox.

Thanks a lot Sindy,

So, if I use src-mac-address of the ether1 port, it should work ? This is more convenient than the way I use it (with dst-mac-address).

But I think I made a huge mistake : I was sniffing packets directly from the Mikrotik and it never worked, but I presume that priority is applied after the packet sniffer, that's why I didn't see anything, right ?

I'm such a noob...

Joris

Well, that sure is a noob mistake! You should connect a separate system to the output of the router and check it there.
Or at the very least configure a mirror-source=ether1 and mirror-target=some other port and then trace the traffic on that other port. That could or could not work.

So, if I use src-mac-address of the ether1 port, it should work ? This is more convenient than the way I use it (with dst-mac-address).

It's not so much about convenience as about tolerance of the ONU/PPPoE server for PADI frames without the requested value of the priority field. If you use dst-mac-address and set it to match the MAC address of the PPPoE server, the rule will ignore the PADI frame which goes to ff:ff:ff:ff:ff:ff:ff. So by matching on src-mac-address, you make sure that the rule will treat all frames sent from ether1 but will leave alone all frames sent "in the name of" other interfaces.

But it just dawned on me that maybe the ISP has just "overspecified" the required 802.1Q tag population and you actually may not need any rule at all. Because if you don't use any rule to set the 802.1p priority field in the tag, it is set to 0 by default as the tag is added to carry the VLAN ID.

But I think I made a huge mistake : I was sniffing packets directly from the Mikrotik and it never worked, but I presume that priority is applied after the packet sniffer, that's why I didn't see anything, right ?

Correct. The sniffing is done at the CPU, let's say "on the outer side of the CPU port of the switch". So whatever modification the switch chip does when forwarding the frame to the Ethernet port can be only seen on an equipment connected to that Ethernet port (and you have to be careful that the sniffing hardware doesn't modify the packet too, as I've explained above regading Windows drivers etc.). And vice versa, the CPU will see the received frames eventually modified by the switch chip.

I'm such a noob...

Don't worry, it's an inevitable stage of any education process. The more headache a mistake causes, the better you remember the correct way

Thanks a lot for the explanations

You're right for the ISP who need priority code 0, it doesn't need a rule to work.
But for the other one, if I don't tag frames, the PPPoE session is established, but the bandwith is very low (something like 2Mbps for a 100Mbps optical fiber).

Joris