Removing untagged VLAN from a route-only interface breaks DEFAULT-VLAN

[kpfleming]

I'm running the 09.0.10dT213 router firmware on a stack of three ICX 7150-C12Ps (although this problem was also seen with the 'c' firmware, and I upgraded while troubleshooting).

I had one of the Ethernet interfaces added to a non-default VLAN in untagged mode, and also set to 'route-only' because it was being used as an OSPF transport link. This worked fine.

I have a VE in the default VLAN which handles routing traffic to/from that VLAN and also provides DHCP relay.

When I decommissioned the device which was using that interface, I removed the interface from the non-default VLAN, but did *not* revert to 'no route-only'. No errors were issued at the CLI when I made this change, and the stack continued operating normally. The VE continued working as it had been.

Today I had to power down the stack for a UPS battery installation, and when it came back up VE 1 was gone... it did not appear in 'show running-config' even though it appeared in 'show config'. 'show interface ve 1' showed it as 'down', which isn't something I thought could happen to a VE.

Since the VE was down various parts of my network did not work properly, and I spent quite a long time reviewing the config against my last-known-good backup... multiple reboots, a firmware upgrade, and a complete erase-and-reconfigure did not cure the problem, so I had to conclude it was in the configuration itself.

Finally I noticed the 'route-only' in the interface configuration for that Ethernet interface. Using 'no route-only' at the CLI did not bring the VE back up, but a final reboot *did* bring it back up.

In summary, having an Ethernet interface that is configured in 'route-only' mode also in the default VLAN badly breaks that VLAN; if there's a VE in that VLAN it will not be setup during boot.

[BenBeck]

Please open a case for this item (see my signature) so it can be properly investigated.

[kpfleming]

As much as I'd like to do that I don't have a support contract because I bought my equipment used and Ruckus does not offer support contracts in that situation. I'm happy to help out here as much as I'm able, and I'd actually like to get a support contract for various reasons, but so far that hasn't been an option 🙂

[BenBeck]

Understood. We certainly want to find any issues and fix them, but the forum is not the right avenue to do that. I am not sure if there are any feasible options being that you bought used. Generally speaking, we do not officially support those customers at all. The forum is a best effort place, but it will not be a substitute for official support and case work. You could try reaching out to the account team in your region and see if they would look at recertifying the equipment and then selling you a support contract. I have heard of that being done in the past, but that is admittedly not my area of expertise, so I can't make any promises there. For now, I would recommend shying away from 9.x. It is still relatively new code. We currently are recommending 8095g/8095h for almost all of the 7xxx line. 

[kpfleming]

Your replies are very much appreciated, especially on a weekend 🙂

I posted here mostly for visibility in case someone else ran into a similar issue; I don't need a solution as I've already corrected the problem and my stack is back in working order.

On the version front: I had loads of weird IPv6 failures when running 80xx firmware, and when 90xx arrived I figured I'd give it a try. It solved my IPv6 issues and hasn't caused me any problems (I don't consider this current one as caused by the firmware, it was a configuration error on my part). I'm happy to be a beta tester 🙂