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