HPE Aruba Networking & ProVision-based
1829729 Members
1644 Online
109992 Solutions
New Discussion

Re: MST design

 
Brad_199
Frequent Advisor

MST design

Site A, B & C joined in ring topology


MST enabled on all switches

No MST instances in either site, just default IST instance containing all VLAN's.
OSPF enabled on all switches


Site A port B1 (Trk1)    --> Site B port B1 (Trk1)
Site A port A1                 --> Site C port A1
 
Site A (part of show run):
 
spanning-tree
spanning-tree Trk1 priority 4
spanning-tree instance ist Trk1 path-cost 200000
 
Site B port B1 (Trk1)   --> Site A port B1 (Trk1)
Site B port C1                --> Site C port C1
 
Site B (part of show run):
 
spanning-tree
spanning-tree Trk2 priority 4
spanning-tree Trk1 priority 4
spanning-tree instance ist Trk2 path-cost 20000
spanning-tree instance ist Trk1 path-cost 200000
 
Site C port A1               --> Site A port A1
Site C port C1               --> Site B port A1
 
Site C (part of show run):
 
spanning-tree
spanning-tree Trk1 priority 4
 

Must have ring topology between all sites so OSPF functions correctly and can route traffic via different sites if a link between a site fails.

Port B1 (Trk1) in site B is being blocked by MST which is causing a problem with OSPF between all sites.
;

On the basis that we must have the above goal - is MST on the core switches a bad idea?  I guess it's always going to block a port and prevent a loop right? Or is there a way to enable MST on the switches but exclude the ports joining sites to continue the ring topology?
Is port B1 (Trk1) in site B being blocked because of the (higher) cost that has been configured for that port? (200000)
Why is it the cost shown against various interfaces in each site are different to that configured (& shown from 'show run') when using the command 'show spanning-tree'?
An example:
 
From site B
 
  Trk1            | 20000     64   Forwarding   | 002661-564299 2    Yes   No
 
 

10 REPLIES 10
John Gelten
Regular Advisor

Re: MST design

Not sure if I understand your goal correctly. On layer 2, you will never be able to have a ring operational; that would be a loop.So any VLAN that you have in all sites will be blocking at some point.

 

In spanning-tree, one of the switches in assigned the root bridge; this is considered the 'core' of the network. You can influence this by assigning priorities (0 through 15, default 7) to your switches, the lowest priority is root. If more than one switch have the same lowest priority, the MAC address is the tie-breaker.

The reason your switch B has this interface in blocking mode is that this interface has the longest distance to the root bridge. In a triange setup, the other side of the link has the same distance; probably switch B was just a bit faster in calculating things than the other switch (or there is some stuff in the equation I am not completely familiar with ;- )

 

You can influence things a bit by playing with the cost of interfaces, but I would only take those off their defaults if you know what you are actually doing. There is hardly ever a need to do that. The cost shown in the spanning-tree output is the total cost from this interface to the root-bridge, the cost in the configuration is only the local cost.

 

Why do you think you need a full ring between your switches ?

It seems to me that for OSPF to work, you need full layer-2 connectivity between them, and you have that in your current setup. What you might mean is that in many whitepapers, you see a ring of devices, forming a non-blocking ring; but that is a layer-3 ring, so if going from one site to the other, all traffic is routed instead of switched. Again, to implement OSPF, the setup you have should work fine.

 

John Gelten
Regular Advisor

Re: MST design

Lower cost is less preferred. So if the cost-value is less, is 'costs' more to get via that route.

I can only say I didn't invent this... ;- )

Actually, a higher cost implies higher available bandwidth (also not completely true).

 

And as to your ring topology: as long as you have a layer-2 ring, you NEED spanning-tree to block one of the links. The result is that you still have full connectivity between the three sites, correct. And that is what you need: connectivity. That some traffic is going over a sub-optimal link, is just by design, and can't be changed.

 

I don't know where yet got the idea you need a non-blocked ring in your network. That is only valid if you wanted to create a layer-3 ring, that can be looped without one of the links blocking. But when you have a layer-2 ring, it will always have one link blocked or your entire network is down; you would be guaranteed completely offline.

 

Sure enough, you can (using MST) build a layer-3 ring on top of your existing physical topology and have that a non-blocked ring, and then run your OSPF over those VLAN's. But that would make your setup quite complex.

 

 

In my opinion, your current setup is conform your goal.

If one of the links fail, the blocked link will go forwarding (almost) immediately. I assume you are going to use OSPF to make connections to other networks redundant by providing a second path via an other site ? The ring you have at the moment (including that one blocked link) is a solid redundant network to build that OSPF on top of.

Richard Brodie_1
Honored Contributor

Re: MST design

"No MST instances in either site, just default IST instance containing all VLAN's."

 

By default all switches will be in different MST regions, so setting IST parameters will have no effect.

Brad_199
Frequent Advisor

Re: MST design

Sorry not sure what that means to my setup/goal?

 

 

 

Richard Brodie_1
Honored Contributor

Re: MST design

I was attempting to answer your question 3.

 

You set:  spanning-tree instance ist Trk1 path-cost 200000

 

but then you "show spanning tree" which shows you the CST path costs and not "show spanning-tree instance ist"

 

However, if you haven't configured the switches to have a common MST configuration, configuring the IST parameters will have no effect. You probably wanted  set "spanning-tree  Trk1 path-cost 200000"

 

 

 

Peter_Debruyne
Honored Contributor

Re: MST design

Hi,

 

If I understand your requirements correctly, there are no vlans which require access over the sites, so it is only routed traffic between the sites.

If that is the case, you only need routed links between the sites and OSPF to handle it, there is NO need for xSTP on these links.

 

The problem you probably have at this point is that you may have configured the 3 sites wan connections into 1 ip subnet (on the same vlan), which is why you may have started playing with xSTP to avoid the loop on that 1 ip subnet (1 vlan).

 

If that is the case, remove the existing wan vlan, and create 3 new WAN (routed) vlans, but each of these should only contain 1 WAN link, and they should each be in their own IP subnet.

That way, OSPF will actually see 3 routed links and will be able to use the shortest (routed!) path.

Since only OSPF can manage the WAN links, ensure that only these vlans are enabled on the ports and disable xSTP on the ports with a bpdu-filter.

 

Assume these are the WAN links:

SW1-A1 --- SW2-A1

SW2-A2 --- SW3-A2

SW3-A3 --- SW1-A3

 

#SW1

span a1,a3 bpdu-filter

 

vlan11

 name L3-to-SW2

 untag a1

 ip ad 10.0.1.1 255.255.255.252

 ip ospf

vlan 13

 name L3-to-SW3

 untag a3

 ip ad 10.0.3.2 255.255.255.252

 ip ospf

 

#SW2

span a1,a2 bpdu-filter

 

vlan11

 name L3-to-SW1

 untag a1

 ip ad 10.0.1.2 255.255.255.252

 ip ospf

vlan 12

 name L3-to-SW3

 untag a2

 ip ad 10.0.2.1 255.255.255.252

 ip ospf

 

#SW3

span a2,a3 bpdu-filter

 

vlan13

 name L3-to-SW1

 untag a3

 ip ad 10.0.3.1 255.255.255.252

 ip ospf

vlan 12

 name L3-to-SW2

 untag a2

 ip ad 10.0.2.2 255.255.255.252

 ip ospf

 

 

# verify on the switches that no other vlans are passing (this setup does not cause a loop, since the vlans are not transported over all the links of the ring, but better verify twice :) )

show vlan port a1 detail

 -> ensure no tagged vlans are allowed to avoid L2 loops on the ring.

 

and some ospf area config of course.

 

Best regards,Peter

 

Brad_199
Frequent Advisor

Re: MST design

thanks peter.

 

Is there a IST instance per region?

Is there a IST root switch per IST instance?

Is the CST a combination of all regions?

If there're no MST instances, what 'root switch' would the switches be calculating it's cost path too?  Would it be to the IST root switch or the CST root switch?

Richard Brodie_1
Honored Contributor

Re: MST design

I think the way to get into MSTP is to grasp the interoperability rule with RSTP: you can replace the whole of an MSTP region with a single virtual RSTP instance.  In that way it's rather like a proprietary stacking scheme: there are some internal links which don't run RSTP but observed externally that's completely transparent.

 

In the case where you have a vanilla MST configuration, each switch is in its own region, so is its own regional root. All links between switches are inter-regional links, and normal RSTP rules apply.

 

Is there a IST instance per region?  Yes.

 

Is there a IST root switch per IST instance?  Yes.

 

Is the CST a combination of all regions? It's what you see when you treat the regions as a black box internally.

 

If there're no MST instances, what 'root switch' would the switches be calculating it's cost path too?  Would it be to the IST root switch or the CST root switch? Both, but as there are no internal links, all traffic flows over the CST.

 

Here's a more comprehensive guide: http://blog.ine.com/2010/02/22/understanding-mstp/

Brad_199
Frequent Advisor

Re: MST design


What is the recommended/or best practice spanning-tree design per site?

Should the config remain as it is? (each switch is its the IST root and no MSTI's)
Should each site be in its own region?
Should each site be in its own region without MSTI's but with a single IST/CST root per site?
Something else?
Peter_Debruyne
Honored Contributor

Re: MST design

Hi,

 

You are right that each site will have its own STP topology, the WAN has bpdu filters, so it ensures the STP domains remain isolated.

Due to the single connected links, STP is not required for failover, but I would still recommend it as a network-wide (meaning site-wide) loop detection protocol.

Single connected links means load balancing is not even an option, so forget about MSTP config (default MSTP config results in actual RSTP between all the switches).

On the Core, it is recommended to make it the root

  # prio

  span prio 0

  # enable stp

  span

On the access, it is recommended to enable bpdu-protection on the access ports (so access ports will be shutdown when they are inter connected or any other stp switch is connected to an access port).

  # auto re-enable ports after 60 sec in case they were shutdown by the bpdu-protection

 span bpdu-protection-timeout 60

  # enable on all access ports (adjust range to your actual switches)

 span 1-24 bpdu-protection

  # enable stp

 span

 

Best regards,Peter