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

[Alexander Marhold]

Therefore if you want to put one node out of a 2 node VC you need to put the
Master down not the backup
Sounds strange but this is according to the rules stated below

Regards

alexander

-----Ursprüngliche Nachricht-----
Von: juniper-nsp [mailto:juniper-nsp-bounces at puck.nether.net] Im Auftrag von
Alexander Marhold
Gesendet: Donnerstag, 26. Juli 2018 09:52
An: 'Tobias Heister'; 'Victor Sudakov'; 'Pavel Lunin'
Cc: 'juniper-nsp'
Betreff: Re: [j-nsp] EX4200 virtual chassis problem, master going into
linecard mode

Hi 

According to the documentation there should be the following behavior with
split-detection enabled:
In case of a complete split:
If the Master-RE sees MORE THAN HALF of the devices it survives otherwise it
disables that part of the cluster
If the Backup-RE sees HALF of the devices the backup Re will survive and
play the master

--> so then in a 2node VC one node is Master one node is backup
If they split the master will go down but the backup should survive as it is
still half of the original cluster

So this means you should make the part you want to survive to be the
backup-RE and not the master-RE

--- or did I miss something ?!

Regards

Alexander

-----Ursprüngliche Nachricht-----
Von: juniper-nsp [mailto:juniper-nsp-bounces at puck.nether.net] Im Auftrag von
Tobias Heister
Gesendet: Donnerstag, 26. Juli 2018 09:26
An: Victor Sudakov; Pavel Lunin
Cc: juniper-nsp
Betreff: Re: [j-nsp] EX4200 virtual chassis problem, master going into
linecard mode

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
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp