but I think we are discussing a 3011 here, right?
Correct
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.
EDIT: 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.
EDIT 2: 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).
EDIT 3: it cannot work either as the DHCPDISCOVERY goes to a broadcast MAC address. And as the source MAC address is the same for all VLANs, matching on src-mac-address may be problematic too.