Passing VLAN traffic to city's network - traffic comes in, but not back out

I have a CCR2116 router installed in a City’s data center. Their network is layer 2 only and is passed to me over SFP3 with vlan 355.

I have a Vlan setup and directly linked to interface SFP3. I also have a DHCP server setup to assign IPs on that VLAN.

Every few minutes, I can see a DHCP request come in. It shows up on my leases as “offered” but is never bound. It appears that traffic doesn’t make it back to the client requesting DHCP. The City tells me that the problem is on my end because I’m not tagging the traffic correctly back to them. Could someone help verify that I am (or not?) setup to correctly send traffic back out over vl 355?

Here’s my config as a Gist on Github: https://gist.github.com/rscott78/f26f9cebb48544bd83575116476aacc1

Which kind of 802.1q tags do they expect? Is it “customer” VLANs (the usual one) with TPID 0x8100 or is it “service” VLANs with TPID 0x88a8? If the later, then set use-service-tag=yes on relevant vlan interface (default is no and works fine for “customer” VLANs).

They tell me it’s customer. If it were service, would I still see the traffic come in when I don’t have that checked?

I’m guessing now: I’d say vlan interface would still strip one layer of 802.1q tag for ingress traffic (regardless the TPID), but would add a header on egress with TPID set to value that connecting device doesn’t expect.

Other than that, you have quite a few disabled items in different bridge sectiobs … and dome which should be consequently inactive but might not be due to some bug. I’d try to clean setup a bit. Or create a lab setup (even using another smaller ROS device) with only minimum setup just to verify what’s needed.

regarding your guess - how would I handle that if it’s indeed the case? I’ve been wondering about ways to test and verify which tpid is headed out… any suggestions on how I could do this? I do have a CRS available that isn’t being used for anything, if that could be of help to do some verification.

I’ll do some cleanup of the disabled items, just in case.

From the exported config it’s apparent that you’re using sfp port as hardware WAN interface directly, i.e. not as member of a bridge. Then you have a vlan interface anchored to that sfp port. Just use use-service-tag=yes on that vlan interface.

If you decide to go with bridge solution, then it might get complicated as whole bridge works with single TPID …