Impact in adding VLANs to MST instances dynamically
I am wondering if it's viable to add and remove VLANs dynamically to MST instances. If so, I can make a good traffic balance. However, I read in CCO site that each time some VLAN is added, the MST database is reinitialized, but will it stop the traffic a little, for example ?
Re: Impact in adding VLANs to MST instances dynamically
MST needs to ensure that there is a consistent vlan to instance mapping, else there would be a possibility of bridging loops (see example in the end). That's why the concept of region was introduced: a region is basically a group of switches with same vlan to instance mapping.
As a result, if you are changing the vlan to instance mapping on one switch, MST needs to reconverge because this switch just moved to a different region. The simple solution that was chosen in order to implement that was to restart the MST process from scratch as soon as you change the configuration. There might have been complex optimization, but considering that MST needs to reconverge anyway, they were not going to be very useful. This is basically an issue of MST, not of the implementation. The best work around I know of is to pre-provision vlans and instances in the MST configuration so that they are available when you need them.
Loop example with inconsistent vlan to instance mapping:
Suppose you have two bridge A and B running two instances 1 an 2. A has two ports p1 and p2 connecting to two ports p1 and p2 on B. Instance 1 is blocking p1 on A, instance 2 is blocking p2 on B. Now suppose that vlan X is mapped to instance 2 on A but mapped to instance 1 on B -> vlan X has a permanent loop between A and B. MST prevents this issue by putting A and B in different region, and forcing all the vlans to be handle by a single instance (the CIST) between region.
[toc:faq]The ProblemOn traditional switches whenever we have a trunk
interface we use the VLAN tag to demultiplex the VLANs. The switch needs
to determine which MAC Address table to look in for a forwarding
decision. To do this we require the switch to do...
[toc:faq]Introduction:Netdr is a tool available on a RSP720, Sup720 or
Sup32 that allows one to capture packets on the RP or SP inband. The
netdr command can be used to capture both Tx and Rx packets in the
software switching path. This is not a substitut...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...