[j-nsp] EX4200 virtual chassis problem, master going into linecard mode

Tobias Heister lists at tobias-heister.de
Thu Jul 26 03:25:30 EDT 2018


Hi,

On 26.07.2018 09:06, Victor Sudakov wrote:
>>> I don't like to explain what others say but I think yes. It's been known
>>> behavior since always: in a two-member VC always disable split-detection.
>>> You can google for other threads on this in this list.
>>>
>>> It's always been kind of poorly documented. Last time I checked the docs,
>>> instead of just writing clearly that it must be disabled in two-members
>>> mode, they "don't recommend" it with some kind of hand-waving explanation
>>> that if you estimate that the backup RE failure probability is higher that
>>> a split-brain condition blah-blah-blah... Just disable split-detection,
>>> that's it :)
>>
>> Tomorrow we are planning a lab with and without split-detection. I
>> hope this solves the issue for us, and if it does, I'm sure to make a
>> note in my engineering journal.
> 
> 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!

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 ;)

-- 
Kind Regards
Tobias Heister


More information about the juniper-nsp mailing list