but I think we are discussing a 3011 here, right?
So this makes you Lucky Luke, because the switch chips of 3011 are QCA8337 which bless us with hardware manipulation of frame headers.
To set the priority field of the VLAN tag of all frames sent by the CPU and tagged with VLAN ID 2
towards the MAC address of google's gateway in VLAN 2 to the magic value of 3, regardless whether the IP packets they carry are generated locally (like the DHCP ones) or routed from LAN, and also if they carry ARP packets, you need to do the following:
/interface ethernet switch rule add switch=switch2 ports=switch2-cpu vlan-id=2 new-vlan-priority=3
/interface ethernet switch rule add switch=switch2 ports=switch2-cpu dst-mac-address=gg:gg:gg:00:00:00/ff:ff:ff:ff:ff:ff new-vlan-priority=3
The above is true if the uplink is really connected to ether6-google
as you've stated in your OP; if you connected the fibre to an SFP module inserted directly into the 3011, you wouldn't be able to benefit from the switch chip features as the SFP cage is connected directly to the CPU, bypassing the switch chip. So in that case, you'd have to make the SFP interface a member port of a bridge and use /interface bridge filter
rules instead, which would make the WAN processing more CPU costly. If the frames carrying DHCP packets (or ARP packets) need not have the vlan priority field set to 3, /ip firewall mangle add chain=postrouting action=set-priority new-priority=3 out-interface=GoogleVLAN
is sufficient as it covers both the locally originated IP traffic (except DHCP) and the IP traffic routed (and NATed) from LAN. But ARP is not IP traffic so it this rule won't set the priority field in frames carrying ARP packets either because it won't ever see the ARP packets.
: I'm not sure now why but the miracle above actually doesn't happen because the priority value is not being set for frames which ingress the chip via its cpu-facing port; I've seen the rule to work for the ethernet ingress ports, but when sniffing what the switch chip has forwarded from the cpu port to an ethernet port on a device connected to that ethernet port, the priority has to be set using the /ip firewall bridge filter
or /ip firewall mangle
to be seen at the sniffing device. The switch chip rule doesn't overwrite it.
: matching on vlan-id
on the CPU port seems to be the spoiler of the miracle. I've tried to replace the vlan-id
matching in the original rule
by different match condition serving the same purpose in my environment and the rule started matching and setting the priority field. I guess it has something to do with the proprietary format of the frame header which is used between the CPU and the switch. In my case, I was matching a single dst-mac-address
because I have more VLANs on the bridge and port; in your case, as the /interface ethernet switch rule
don't allow to match on the egress port, it might make sense to match only the first three bytes of the gateway's MAC address, i.e. the vendor ID. Also, I haven't tested whether /interface ethernet switch rule
works the same even if the egress port is not a member of any bridge in ROS (i.e. when the /interface VLAN
is attached directly to ether6
as in your setup).
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.