[j-nsp] How reliable is EX multichassis? 3300 and 8200 switches

[Luca Salvatore]

Just an update on this after some more troubleshooting today.
I'm only seeing the issue on my EX4500-VC switches.

On my EX4200-VC switches, when the master reboots my OSPF neighbours stay up - i drop about 2 pings but that's it.
The EX4500 switches have the exact same configuration.  All switches are running 11.4r2.14

Probably log this with JTAC - looks to me like a bug.

Luca


-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Luca Salvatore
Sent: Thursday, 1 November 2012 7:32 AM
To: Morgan McLean
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches

I see the 60 sec delay when crashing master. It seems the backup switch takes a while to notice the master is gone. But my main delay is the fact that my OSPF neighbours are lost when master crashes.

@Doug, nonstop bridging is also configured.

Luca

On 01/11/2012, at 7:25 AM, "Morgan McLean" <wrx230 at gmail.com<mailto:wrx230 at gmail.com>> wrote:

Did you see the failover times I mentioned? Is that expected timing?

8 seconds using VC-LAG w/ LACP to a third switch when pulling masters power over 60 seconds when crashing master

Morgan

On Wed, Oct 31, 2012 at 1:20 PM, Doug Hanks <dhanks at juniper.net<mailto:dhanks at juniper.net>> wrote:
Don't forget to configure NSB to help with LACP and other L2 stuffs.


set ethernet-switching-options nonstop-bridging

On 10/31/12 1:05 PM, "Luca Salvatore" <Luca at ninefold.com<mailto:Luca at ninefold.com>> wrote:

>Yes so GRES and NSR is configured am correctly then?
>
>The AE is a VC-lag with one member on each switch.
>
>Luca
>
>On 01/11/2012, at 3:56 AM, "Stefan Fouant"
><sfouant at shortestpathfirst.net<mailto:sfouant at shortestpathfirst.net>> wrote:
>
>> On Oct 31, 2012, at 10:01 AM, Luca Salvatore <Luca at ninefold.com<mailto:Luca at ninefold.com>> wrote:
>>
>>> Yep my mistake.
>>> However I do have 'set chassis redundancy graceful-switchover'
>>>configured as well as 'set protocols nonestop-routing'
>>>
>>> On 31/10/2012, at 11:24 PM, "Stefan Fouant"
>>><sfouant at shortestpathfirst.net<mailto:sfouant at shortestpathfirst.net><
>>>mailto:sfouant at shortestpathfirst.net<mailto:sfouant at shortestpathfirst
>>>.net>>>
>>>wrote:
>>>
>>> I think you are confusing GRES w/ GR.  NSR and GRES are NOT mutually 
>>>exclusive and in fact NSR requires it to function.
>>
>> 'set chassis redundancy graceful-switchover' is GRES, not GR.
>>
>>> What I actually see when the master switch robots is that the AE 
>>>interfaces between my devices flaps. I think this causes my OSPF 
>>>neighbours to go down.
>>>
>>> I see this in the logs: "rpd[2241]: RPD_OSPF_NBRDOWN: OSPF neighbor
>>>10.255.255.9 (realm ospf-v2 vlan.83 area 0.0.0.1) state changed from 
>>>Full to Down due to KillNbr (event reason: interface went down"
>>
>> Which device is the ae interface tied to?  Is it a VC-LAG with 
>>members tied to multiple physical devices, or is it comprised of only 
>>links belonging to a single device?
>>
>> Stefan Fouant
>> JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI
>> Systems Engineer, Juniper Networks
>




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