MSTP Issue on Ubiquiti Edgeswitch

[DaveLegg Developer]

I've been banging my head against a brick wall on this all afternoon, so I'm hoping @BudMan or @sc302 (or someone else) will have some insight about what to try next.

 

At the day job, we're shortly going to be moving to a different datacenter, and as part of the move, we're looking to improve our redundancy so we don't have any single points of failure.

 

We've got two Mikrotik CloudCore routers routing our traffic, and acting as the firewall. They're running VRRP, and traffic to our subnet will be routed to the virtual IP by the datacenter.

 

We then have two 48 port Ubiquiti Edgeswitches, both of which are connected to each of the routers. Each public facing server has four NICs, two for the public vlan, two for the private vlan, one of each is connected to each switch. The switches are also cross-connected on the private vlan.

 

We've got the equipment in the office, and I've spent the afternoon trying to get MSTP working on the switches properly, but getting nowhere fast. VRRP is working fine, that was nice and easy to setup.

 

We've configured both switches with the same MSTP config, one for the public vlan, one for the private. The Mikrotik routers don't support MSTP, so RSTP/STP is disabled on them.

 

At the moment I'm testing with just a single PC plugged into one of the switches, the servers are not connected, yet.

 

The ideal outcome is that the cross-connect between the two switches remains active to pass all traffic, and one of the cables to each router and server is in blocking mode, ready to fail active if its partner cable to the same vlan on the other switch, or the other switch, fails.

 

What I'm seeing happen is the cross connect is disabled, and three of the four links to the routers remain active. This is fine, on the public side, but means that no traffic is able to pass between the switches on the private vlan.

 

MSTP should be seeing that the cross-connect needs to remain active for the private vlan to be able to pass traffic, but this doesn't seem to be happening.

 

Any ideas?

 

Diagram attached - Shows the cross-connect hosting both vlans, but currently have it configured with only the private vlan, as cross-connect probably won't be needed on the public side.

[sc302 Veteran]

Unfortunately I don't have experience with ubiquiti switches...the best I could offer is online manuals or youtube videos. 

 

I may be able to look at the configs on both switches and try to make sense of it, it looks very similar to cisco iOS.  If you want PM them to me, obviously it will stay confidential.

[+BudMan MVC]

Same here I don't have any edgeswitches to play with.. I want to get some

 

But what scenario of failure are you looking to mitigate here.. Looks like your servers are going to have redundant paths..   And your not showing multiple vlans here.. I don't see the point of mstp.. Normally you would use mstp when you want to map your different vlans to different paths and use the other path(s) as failover for those vlans if their path fails, etc..

 

 

[DaveLegg Developer]

I think perhaps the solution I'm missing could be running the public vlan over the cross-connect, I'll have to give that a go tomorrow when I'm back in the office, without that link being present, MSTP would be needed to allow both vlans to be fully connected, but with it there, I think it may work. Will report back in the morning.

[sc302 Veteran]

It also doesn't help that I am color blind...might as well have put them all in red...  the top 2 colors look the same to me.

 

me: http://www.colourblindawareness.org/colour-blindness/types-of-colour-blindness/ 

i am red/green color blind.

 

[+BudMan MVC]

  On 10/01/2017 at 22:47, DaveLegg said:

MSTP would be needed to allow both vlans to be fully connected, but with it there, I think it may work. Will report back in the morning.

Expand  

I do not see this..  I think maybe your misunderstanding the point of mstp.. You would normally use it to allow mapping of your vlans to take different paths while leveraging the other path as failover..  So you get what amounts to load sharing across your physical paths.. Vlans x,y and z take path A, while vlans C and D use path B.. If path A fails then vlans x,y and z can use path B..

 

If you do not want to do that then you would normally just use pvstp or pvstp+ in the cisco world.. where there is a stp instance running on each vlan.. Not sure what they call that in unifi land?  Or on Mikrotik..  But with only your 2 vlans here.. I am not sure why you think mstp is the answer?

 

But to me your 2 switches are your core or distribution layer depending on how you want to look at.. Why would you not just create a VSL between them (cisco term..) I a VSS (virtual switching system) so since your client devices (servers) have connection to each switch wouldn't matter if one of the switches takes a crap.. 

 

So I am not seeing a reason for mstp here at all??

[DaveLegg Developer]

I'm pretty sure we were confusing ourselves into wanting to use MSTP by not including the public vlan on the cross-connect between the switches. I've added the public vlan there, and switched back to regular RSTP and it's all working fine.

[+BudMan MVC]

MSTP to be honest isn't used very often.. I have only ever seen it used a few places..  We don't use it on our DC.. To be honest its old tech anyway.. STP and all its forms should of died off already.. Is this something your adding to your setup or is the is a greenfield deployment?

 

There multiple options out there that get rid of the time for convergence with your traditional stp, pvstp, rstp, mstp, etc.. If you where cisco shop you would be using fabricpath.. Your other protocols out there are STB and TRILL..

 

Is this system isolated or does it connect to a much larger network?

[DaveLegg Developer]

This will be a fresh deployment, we've been having issues with the DC we're currently hosted in, so moving over to a new one, and taking the opportunity to get new switches etc. The transit network obviously connects into the data center's backbone, but otherwise it's essentially isolated. There will be an ipsec VPN link connecting it to our offices.