SG200 VLAN issue

[robbosch]

We are replacing some netgear switches with the Cisco SG200.  The situation is relatively straightforward.  We have a series of VLAN's coming in on a trunk from a service provider for our Metro Ethernet locations.  These trunks then get cross-connect to various location for connectivity.  The problem we have is there are two VLAN's that need to go to the same switch which provides access to our public IP block.

I set up the two VLAN's on the SG200 with the trunk port VLAN tagging on the service provider port.  Then I set up a separate port for untagging the traffic with the PVID of the respective VLANS's as follows:

GE1 - service provider trunk - configured as VLAN trunk with tagged participation inVLAN 100 and 101

GE2 - trunk port in VLAN 100, untagged, PVID of 100

GE3 - trunk port in VLAN 101, untagged, PVID of 101

The public switch has no VLAN's configured (it is an SG200 too). 

If I connect GE2 to the public switch everything works fine.  When I connect GE3 to the public switch, things die.  I thought this might be caused by STP although STP should not be detecting issues like this across separate VLAN's.  Disabled STP, no change.

The same configuration with the Netgear worked without an issue.  Any suggestions?  FYI, the VLAN's cannot be changed...they are defined by the service provider in this particular case.  otherwise we'd just make them the same...but there should be a way to accomplish what I'm trying to do.

Rob

[robbosch]

I should clarify, in my last paragraph I meant to say the VLAN ID's cannot be changed...the VLAN's can obviously be changed. 

[David Hornstein]

Hi Rob

Why could you not VLAN the public switch ?

I sorta threw up a rough diagram to see interactions that might be occuring.

You've broken down the VLAN barrier between networks by placing VLAN100 and VLAN101 into a psuedo unmanaged switch.

seems like broadcast coming in  on  VLAN , say 100 witll automatically be propogated in vlan 101 and vlan1. same will happen on VLAN101 with incoming and outgoing broadcasts and multicast.

Sure makes sense to vlan the public switch as there wont by any layer 3 switching occuring between hosts on the SG200 series switch.  So my not half the broadcast/multicast traffic by VLANing the public switch..

I'm thinking almost a loop is occuring here with broadcasts/multicast within VLAN100 and VLAN101 coming into the network will be propogated back out the network to the metro ethernet.

VLANing the public switch should quiet down this scenario. I am guessing that a wireshark capture would show a large percentage of the traffic would be broadcast type traffic.

tell me how it goes.

regards Dave

[robbosch]

Thanks for the post!  Just for clarity, let's call the public switch with no VLAN's today pub_switch and the other vlan_switch. 

How would you propose that configuration would look like on pub_switch?  Here is some more information that might help.  The pub_switch has two feeds from redundant routers which are not in VLAN's (default configuration for the port where everything is in VLAN1).  Other feeds come out of the pub_switch to other distribution switches, non of which are using VLAN's. 

Are you suggesting to create two VLAN's on the pub_switch, 100 and 101, and only put the ports connected into the existing VLAN's in those VLAN's as untagged and PID 100 and 101?  Essentially creating a single-port VLAN on pub_switch?  That would break their connectivity to the rest of the public traffic, right?  Or are you suggesting something else?

If I make the ports the public routers are connected to as tagged trunks, the routers will not be able to see any of the traffic on the pub_switch since they are not configured to use VLAN's.  Setting them up to do so would break a ton of other upstream items.

And it seems to me that the purpose of having untagged VLAN ports with PID's is to make the transition between VLAN and non-VLAN traffic, right?

I am open to any suggestions...these are just my immediate thoughts after reading your post.  Am I missing something (highly likely!).

By the way, I like the drawing.  It makes it easier to understand.  It is reasonably accurate, just assume the public routers are on two ports in the bottom switch.  The routers are using VRRP by the way.

[David Hornstein]

Hi Rob,

ah   yes the fog is clearing.

I assumed VLAN100 and 101 were the incoming ports from the metro ethernet providing Internet connectivity.

yep a picture is worth a thousand words, sorta clarifies the setup. 

Could i beg your indulgence to have pity on me and maybe put together a simple diagram to show the real topology setup.

So I'm guessing now that the metro ethernet connection,  takes the internet to two different sites to provide them with internet connectivity ?

Yeah, a picture would be nice, and it doesn't have to be fancy, even pencil and paper , scanned and loaded up to the next posting would be great.

Also , just to play it safe, please ensure your switches are running the latest and greatest firmware.

Yep the public switch doesn't have to be VLANed, I guess better not be VLANed as your VRRP WAN routers would be in one and not the other VLAN.

I would be really interesting to see a 20 second wireshark capture  via port mirroring of a public_switch port that goes to the VLAN_switch.  But the easiest thing to do is, if needed, upgrade the firmware in switches and see if the problem is still evident.

regards Dave

[robbosch]

You're right...the Metro Ethernet is used to distribute public traffic to these two sites.  It does both private and public based on VLAN's and needs. 

I verified the firmware is the latest.  I think we're going to get rid of these Cisco switches and go back to the netgear devices.  We never had a problem with them.

Here is the picture...similar to yours. 

[David Hornstein]

Hi Rob,

The configuration looks Ok, visually.  There's a lot of smarts built into a smart switch. From the discussions up to now, I have only been guessing what you mean by, "When I connect GE3 to the public switch, things die."

Spend a few minutes and call the Small Business Support center (SBSC).  refer them to this posting, so they understand the topology.  It will be more cost effective for you and Cisco to avail yourself of the tremendous warranty on the 200 series product  to resolve the issue quickly.

I would hazard a guess that the issue is something fundamental.  there is still alot you have not disclosed in terms of VLAN mode / interface setup.  I think a technician looking at the configuration may spot the issue quickly. 

the contact details for the SBSC is found via the following URL;

www.cisco.com/go/sbsc

Been a interesting interaction

regards Dave

[robbosch]

I'll call into the SBSC...good idea. 

One other thing that comes to mind...do you think CTP is messing with  the configuration?  What I don't get is that the two ports with 100UP  and 101UP on vlan_switch are NOT in the management VLAN of 1.  That  means that there should not be any way for pub_switch to detect a  loop...especially since STP is disabled on both switches.  I think that  is what is happening, however, and it might be related to CTP. 

[robbosch]

I waited on hold for about 25 minutes this morning to talk to a Cisco tech.  They reviewed the switches and indicated that it was a problem with the Native VLAN.  They didn't have a solid answer on how to modify the switch but suggested including the ports in VLAN 1, even iwth an excluded status.

None of this made any sense to me but I tried it anyway.  It didn't help at all.  I turned off CDP just to get rid of the message because I don't think it was really telling me the right information.

Then I reviewed an obscure setting on the STP interface settings...BDPU.  I changed the setting from Flood (the default when STP is disabled) to Filtered.  All problems went away. 

So the answer is:

1. The Native VLAN message had nothing to do with the problem.

2. You should not accept the defaults thinking they are "the best"

3. The BDPU setting is impacting STP decisions even when STP is disabled

4. CDP is worthless in this scenario

I changed the setting to filter on all the interfaces to avoid future issues since this is a common setup we have in our configuration. 

[David Hornstein]

Hi Rob,

So the problem occured, because spanning tree was disabled ,  and you fixed the problem by disabling BPDU flooding.

Interesting...

after this process is now complete, it would have been interesting to see what the error log of the switch was saying.

I would have thought that flooding of BPDU would have been acceptable, as even a unmanaged switch would allow the flooding of BPDU's.  In fact I guess a unmanaged switch would have worked as a public_switch.

hmm..

anyway glad to hear that your issue is resolved.

regards Dave

[robbosch]

Dave,

I'm not sure I'd say the problem occurred because spanning tree was disabled.  The configuration is correct to get multiple VLAN's to transition to non-VLAN traffic since the switch does not support MSTP.  The problem was that despite spanning tree being disabled, the BPDU flooding was causing a loop to be detected ACROSS VLAN's. The best solution is to have the switch support MSTP.

There are some basic features in the SG200's that Cisco has chosen to disable.  Maybe by pulling these features out there have been some unforeseen consequences?

I still don't understand why the SG200 switches don't support SNMP.  Is there really a good reason to disable SNMP because the switch is just a "smart switch"?  OK, that's a totally unrelated rant.

I did review the logs while making changes hoping to find some  indication of the problem.  The only thing ever logged was the Native  VLAN mismatch error which really didn't have anything to do with  anything.  The way I found the issue was to dig through everything  related to STP and the disabling of STP.  This is how I figured out the  real issue was the BPDU flooding.

In any case, changing BPDU flooding to filtering allowed the switch to operate correctly and the switch is now properly respecting the VLAN separation of the connections. 

Thanks for your help in the forum...I appreciate it.

Rob

[David Hornstein]

Hi Rob,

Valid rants, yep the 200  "smart switch" series is  more cost effective but with fewer features  compared to it's bigger brother/sister,  the 300 series switch. But we don't call the 300 series the smarter switch just a fully managed switch.

But I gotta wonder what was reacting to the flooding of BPDU..dunno.  Is there some underlying problem we are just skimming over..

I am scratching my head over the solution, but really  glad it is working..

regards Dave