Possible vlan tag config bug

Hi Alta Team,

10+ year network engineer here, mainly work with data center networks, but I want to say I am extremely impressed by the products so far. I’ve spent a few hours playing around with the starter pack from ISP (2x APs and 1 8 port switch) and I think these are going to be a huge game changer.

That being said, I ran across what might be a possible VLAN tagging bug on the switch. In my topology, I have the AP connected to my 8 port switch. The AP is set for mgmt VLAN 7 which I can see is tagged in the 802.1q header. Now, if I set the native VLAN on the AP facing switch port to 7, I shouldn’t be able to reach the AP anymore, since the AP is tagging VLAN 7 yet the switch configuration says VLAN 7 should be untagged.

Only when I bounce the interface on the switch do I lose connectivity to the AP (which I would expect to). Is this the desired behavior? I am running the latest firmwares on all devices.

Thanks!

@jeffk931 In this case, the switch will treat untagged and tagged VLAN7 traffic the same on that port, i.e. it will forward/flood ingress packets from that port to other ports that have VLAN7 allowed on them. If it’s forwarding to an untagged VLAN7 port, it would strip the 802.1q header off before forwarding to that port, and if it’s forwarding to a tagged VLAN7 port, it would keep or add the 802.1q header for VLAN7.

Okay that makes sense if that is the way it is intended. The one caveat is that the behavior is not consistent once the switch port is brought down then back up. When it comes back up, it no longer will pass traffic for VLAN 7 that is tagged.

@jeffk931 How are you bringing the port down and then back up? Just by Disabling and then setting to Standard mode in the UI?

Yes. Both the disable → standard as well as physically unplugging the cable trigger the behavior.

We will look into this and see if we can reproduce it. I’ll DM you shortly

Hi @jeffk931 I’ve been trying to reproduce this for the last hour or so and I think I was able to do it the first time but not subsequent attempts.

Would it be possible for you to write out an “STR” or Steps to Reproduce? A list of every action that you perform to get the network in this state and some pre-established conditions (i.e. we know that you have a functioning VLAN 7 on your network; if we didn’t know that, that would be an example of a pre-established condition. Another example would be knowing if your AP(s) have meshing allowed as that can affect the flow of traffic in some situations.)

I promise, I’m really trying here, but I’ve read your OP and your follow-ups no less than 20 times to make sure I’m going through it properly, even deviating a little bit just in case I misunderstood one aspect of it to allow for a little margin of error.

Hey Matt,

Try these steps. Seems complex but it’s mainly just getting everything in the proper state between my upstream L3 switch and the alta switch and AP.

VLAN5 = User VLAN
VLAN7 = Mgmt VLAN

Alta switch will be connected to an upstream L3 switch that has interface in trunking mode, native VLAN 7.

  1. Create new site on management portal. Did this to ensure all default settings were present.
  2. Start with factory reset 8 port switch and factory reset AP6 Pro. Running firmware 1.2i and 1.1o respectively.
  3. Plugged in uplink switch/gateway to port 1. Plugged in AP to port 2.
  4. Register both in the management portal.
  5. Give each device a name.
  6. Disable “fallback upon failure” on switch settings and AP settings.
  7. Add VLANs 5 and 7 to VLAN section in switch → ports tab.
  8. Set Alta Switch mgmt VLAN to 7. Lose connectivity to switch mgmt IP here as the upstream switch interface has VLAN 7 as native for initial setup.
  9. On the upstream switch’s Alta switch facing interface, remove native vlan as 7, since Alta switch is now tagging VLAN 7 traffic. Connectivity to AP mgmt IP drops. Connectivity to switch mgmt IP comes back.
  10. Set Alta switch port #2 (where AP is connected) native VLAN to 7. Connectivity to AP mgmt IP comes back.
  11. Set mgmt VLAN of AP to 7. Lose connectivity to AP mgmt IP here.
  12. Set Alta switch port #2 native VLAN to default. Connectivity to AP mgmt IP comes back. Everything is now configured as I would leave it.

  1. Set Alta switch port #2 (where AP is connected) native VLAN back to 7. Connectivity to AP mgmt IP does NOT drop here, but would expect it to, since AP is tagging VLAN 7 yet the switch expects no tag for VLAN 7 on that port.
  2. Unplug AP. Plug AP back in. Connectivity to AP is lost due to mismatch in tagging on port 2 of the switch. To fix, simply change native VLAN back to default.

Steps 13 and 14 is where the problem is shown. If the expected behavior is that the Alta switch will accept both tagged and untagged packets for the VLAN set as native on the port, that’s fine, but the behavior shouldn’t change after a port flap.

I should also add that after you complete step 13, in a packet capture, egress traffic from the switch to the AP on VLAN 7 is not tagged, so the native VLAN seems properly applied. It’s the ingress traffic from AP to switch that doesn’t seem properly handled.

Let me know if you need anything else. I’m also happy to demonstrate it live if you can’t reproduce.

Thanks,
Jeff

Ok, first, thank you for the STR, that helped immensely. And I’m man enough to admit that I accidentally used VLAN 7 despite it not existing on my network (I was using 20 and 30 as they already existed on my network) and had to default numerous times because the Fallback feature was disabled :laughing: :man_facepalming:t3:

At any rate, using your STR, I was able to reproduce the issue and I cannot explain it. Sounds like you’re set though (up to step 12 where you said you’d be done with configuration), correct?

We’re going to look into the issue one way or the other, I just want to make sure you’re all set.

Yep I am all set, just wanted to point out the behavior so that you can hopefully RCA and fix. Thanks again.

@jeffk931 You’re right that connectivity should be lost after step 13, because the frames should be untagged and dropped by the AP. However, there may be some caching happening in the MAC table on the AP. Does the problem of having connectivity go away after a period of time after step 13?

That’s a great question. I think I only tested for about 5 min. Let me set it up again and leave it overnight and I will let you know if it drops eventually.

@Alta-Jeff I tested a few times and funnily enough it seems to drop right around the 4 hr 10 min mark, but it is consistent.