SG-300 Odd Behavior on non-default VLAN

[scott.pendleton]

I have a SG-300 with version 1.4.2.4 and am experiencing an issue using VLANs. The switch is in layer-2 mode.  I have a FioS gateway router to which I want to put in VLAN 198 along with some other devices.  Whether I configure those ports as access, trunk, or general, The FiOS router won't give out DHCP addresses unless the PVID on the port is VLAN 1.  If workstation 1 and the FIOS router are on an access port in VLAN 1, everything works. If I configure those ports as trunks with native VLAN as 1, everything works. If I configure the native VLAN on those ports as 198, DHCP breaks.  If I configure them as access ports with Untagged VLAN as 198, DHCP breaks.  If I configure them as general ports with PVID as 198 (no filtering, admit all)  DHCP breaks.  This doens't make sense to me as if they are access ports the virtual connections are made on the backplane and the devices would be totally unaware they are on a VLAN. 

Update:  Upgraded to 1.4.10.6 and still have the same behavior

Update 2:  If I change the switch default VLAN to 198 via the default VLAN settings,  everything works when the ports are in access VLAN 198. I also verified via the FioS Router's log that the Router is not receiving DHCP requests when it is connected to a port who PVID is different than the switch default VLAN.  This is definitely a bug that the switch is doing something on the non-default VLANs that is breaking it.   I also tried setting a static IP when in the non-default VLAN and that does not work either.  However the issue is only with the FioS router.  Other Static IP'd devices can communicate. 

Now instead trying to punt and say this is a FioS Router issue, I argue it is not. Any device connected to an port in access mode should be completely unaware of anything on the switch as it should receive a standard IEEE non tagged frame. It should be no different from the devices perspective than if it were connected to an unmanaged switch

Update 3:   I configured another managed switch in the same manner with two access ports in VLAN 198 and it works flawlessly.  This issue is most definitely an issue with the SG300. 

Update 4: just for grins I connected the FioS router in VLAN 198 as an access port on the other managed switch and then trunked all VLAN over to the SG300.  I connected the workstation to an access port in 198 on the SG300.  This worked. However if I reverse it and plug the FioS router into the SG300 and the workstation on the other switch, its broken.  The only other thing I could do to troubleshoot is if I had and inline sniffer to capture an analyze the frames between the Router and SG300. A SPAN port I don't think would work since that's a copy and not the actual frame leaving the switch. That is only definitive proof that I provide that the SG300 is mangling something in the frame that the FioS router won't accept. However all other evidence points in that direction.

I'd leave them as VLAN 1 except I have an Access Point where the FioS network SSID is trunked as VLAN 198, so I have to have it working on somthing other than VLAN 1

[thrtnastrx1]

It sounds like you tested everything properly.  Why don't you try configuring the FIOS router VLAN198 as a tagged subinterface and configuring the SG port as trunk native VLAN1?

[scott.pendleton]

The FiOS router doesn't support tagging VLANs.

[leecoxhouse1]

I use DHCP on a SG300-28 layer 3 switch.  It works great and supports tagged VLANs.

You could switch your switch to layer 3 and use DHCP on the switch.  Define all the VLANs on the switch.  Use the SG300 switch for all local routing.  Let the router handle just the internet traffic.  I have posted how to do this on other threads here about SG300 switches.

[scott.pendleton]

I'm not sure changing it to layer-3 would make a difference as my updates seem to indicate it goes beyond DHCP. Even if I static IP clients the FiOS router seems to drop frames unless it is in the Default VLAN defined on the SG300.  Unless you think that the frame exiting a non-tagged port would be different in layer-3 mode. It would still be layer 2 from the client to the router.

The next thing I am going to try is putting an unmanaged switch in between the router and the access mode port to see if it somehow 'corrects' the frame going to the FiOS router. 

[leecoxhouse1]

You could use the default VLAN to route all the layer 3 switch networks to the FIOS router.  It probably would not be my choice, when I first setup my SG300 layer 3 switch I had it running that way.  Connect the FIOS router to an access port in the default VLAN.  Turn on layer 3 switching on the SG300 switch.  Setup DHCP on the SG300 layer 3 switch.

You need 2 more things to make this work.  You the default gateway for the layer 3 switch to point to the FIOS router and you need the static maps on the FIOS router pointing to the layer 3 switch IP access port.

[scott.pendleton]

I tested with an unmanaged switch in between and that didn't make a difference.  A managed switch with a default configuration (all ports in the default vlan 1 on the intermediate switch) in between the SG300 and the FioS router does make a difference, so a managed switch is at least rebuilding the frame coming out of the SG300. 

Every VLAN in the topology gets layer-3 from an upstream device so moving  layer-3 onto the switch fundamentally changes a lot of what went into the architecture.

What I decided to do for now until Cisco fixes the bug is just set the default VLAN to 198 still in layer 2 mode. So far the only device I have found that is effected is the FiOS router. Thanks to Murphy it of course had to be a critical node in the architecture that has an issue.  If I find other devices on other VLANs that end up with the same issue, my solution will have to be buy a different brand switch. 

[leecoxhouse1]

Your DHCP does not make sense to me if you have a layer 3 switch upstream.  Are all the networks defined to the FIOS router?

[scott.pendleton]

No.  The Fios Router is just one of the layer-3 devices.  The other VLANs each have some other device connected to the switch acting as the IP gateway. 

[leecoxhouse1]

I just read Update 4.   Is VLAN 198 tagged or untagged?   I believe all untagged traffic is redirected to the default VLAN.

[scott.pendleton]

On update 4 specifically.  VLAN 198 would be untagged on egress of any port that had its PVID set to 198.  Access ports are explicitly assigned the PVID. On trunk ports the PVID is the "Native" VLAN of the trunk. The FiOS router is connected to a access port. 

Traffic would never be "redirected" to the default VLAN in any  IEEE compliant managed switch. On a modern managed switch all frames transiting from port to port are tagged ( to prevent VLAN hopping).  Untagged frames are tagged on ingress with the PVID of the port while tagged frames keep their existing tag field value. The default VLAN is simply the PVID of all ports that are not explicitly configured with a different PVID (ether access VLAN or native VLAN).  On older switches if a port was not explicitly configured this was simply sent across the switch untagged, which lead to the VLAN hopping vulnerability. Even then if the port was configured with a specific VLAN it was tagged with that ID and never gets re-tagged.  If traffic was "redirected" (retagged) with the default VLAN how would it know which VLAN the frame belonged to. 

[leecoxhouse1]

I did not mean redirected but passed on as default traffic.  You seem to know a lot more than me.

So I assume you did this.

https://www.cisco.com/c/en/us/support/docs/smb/switches/cisco-small-business-200-series-smart-switches/smb3090-configuration-of-native-vlan-on-the-sf-and-sg-200-300-series.html

[scott.pendleton]

Yes. On a trunk port if the Native VLAN is not specifically configured it forwards untagged traffic on the default VLAN.  Basically a managed switch forwards all untagged traffic on the PVID of the port.  The PVID is determined by one of the following settings

1) Explicitly set value for the trunk native VLAN ID, or

2) Explicitly set value access VLAN ID, or

3) Default VLAN ID for the switch if neither of the above is configured.

In my case the Router is not tagging and it will not receive traffic if the port is configured via either method 1 or 2 unless the Default VLAN ID for the entire switch is configured as the same as PVID on the port. While the FiOS router is the only device I have found to be affected by this, it is definitely an issue with the Sg300 as the end device is supposed to be completely agnostic to what the VLAN configuration on the switch is. 

[leecoxhouse1]

I can tell you I have a RV340 router with default VLAN 1  and no other networks defined.  It is a VLAN mismatch to VLAN4 on my SG300-28 layer 3 switch.  The port on my SG300 switch is an access port in VLAN4 and default VLAN is VLAN1.  This seems to work fine.

I remember in one of the recent firmware upgrades for the SG300 switches there was a DHCP fix.  You might look it up.  Also did you do a factory reset on the new firmware.

[scott.pendleton]

So are you saying its reporting as a VLAN mismatch or simply that one device has VLAN 1 and one device has VLAN 4? That ussually doesn't happen unless one side is configured as a trunk and CDP will detect the mismatch.  Its only a warning to let you know that traffic is going to be retagged on the native VLAN.

In that scenario frames egressing in either direction would be untagged and upon ingress would get tagged with the PVID of the port (VLAN1 on the RV and VLAN 4 on the SG)