Tobias Heister wrote: > > > > Yes, no-split-detection did help. > > I would like to add to that. My point of view is that you do not > always disable split-detection in a two member VC. You can do so if > you know what that implies. > > The reasoning for the remaining node going into LC mode is that only > the portions of the VC having the majority of nodes stays up and > operational. In a two member VC if for whatever reason one of the > nodes looses connection to the other, we cannot have a majority so > both sides go down. Even if it is the only node remaining. > > But imagine an error scenario where the second node does not crash, > but for whatever reason both sides stay up, but the connection > between them gets lost. With split-detection configured, both sides > will go down and you have a controlled service outage. When no > split-detection is configured both sides remain up and you might > have interesting effects happening in your network with two switches > with the same configuration and same "identity" being up and > forwarding. I have seen that happening in DC scenarios doing stp to > other devices and it is not pretty!
Thank you for the explanation. However, in my case I would rather risk an active/active configuration than have two unresponsive switches which can only be revived through manual intervention. This is mainly because: 1. The stacks are in remote locations, you have to ride an all-terrain vehicle to reach them for manual intervention, or sometimes even a helicopter. 2. The stack members are located together in one rack, so the most likely scenarios requiring failover will be a) one switch hardware failure or b) a failure of one of the UPSes or invertors. 3. An active/active situation can be easily mitigated remotely by shutting down a port on the uplink. > > So always check the implications of what the command are doing. If > in your case an active/active split scenario (for worst case) works > out better than a completely offline VC, that is perfectly fine. I > have seen lots of scenarios where it would not be the expected or > wanted behavior. But in my world a VC is no real redundancy method > it is just stacking-NG for additional ports under one MGMT so i > would have two VCs if i relay need redundancy in most setups. But > that is just me ;) I guess, in my case a completely offline VC is unacceptable. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN AS43859 _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp