[j-nsp] Strange VRRP problem -- question about restarting process

[Alex Arseniev]

Well, that's fairly straightforward - either (1) VRRP on master [J] stopped 
sending or (2) CSCO switches stopped forwarding VRRP hellos, or (3) backup 
[J] drops incoming VRRP hellos.
You can verify (1) by using "monitor traffic interface <blah> no-resolve 
size 9999".
(2) could be verified with SPAN/RSPAN
(3) cannot be verified with "monitor traffic interface" _if_ there is an 
input FW filter. "monitor traffic interface" a.k.a. tcpdump does not capture 
packets dropped by FW filter. Which begs a question - do you have an input 
FW filter on VRRP interfaces or lo0 and if yes, do you allow "protocol vrrp" 
as well as AH/proto 51 and have you added/changed VRRP auth type recently? 
Proto 51 is used when VRRP MD5 auth is configured. In any case, I'd suggest 
to configure a FW filter to log/syslog incoming VRRP packets (dst.ip 
224.0.0.18/32) on backup [J].
HTH
Rgds
Alex

----- Original Message ----- 
From: "John Neiberger" <jneiberger at gmail.com>
To: <juniper-nsp at puck.nether.net>
Sent: Friday, November 02, 2012 3:37 PM
Subject: [j-nsp] Strange VRRP problem -- question about restarting process


> We have a very odd problem that we've been dealing with for a couple of
> weeks. JTAC is involved but we have not come to a resolution yet. The gist
> of the problem is that we have two MX960s and we're running VRRP on
> multiple interfaces with different Cisco switches in between each pair of
> Juniper interfaces.
>
> [J] ----- [C]----[C]------ [J]
>
> The switches are just layer two and we're running VRRP on the routers. The
> problem is that one day, three of the interfaces on the backup router
> suddenly stopped receiving VRRP messages from its peer. JTAC seems to 
> think
> that the Cisco switches just suddenly stopped forwarding VRRP messages to
> the backup router, but that makes zero sense unless some bizarre issue 
> just
> happened to occur on multiple unrelated switches at exactly the same
> moment. I'm still leaning toward a problem on the router.
>
> Which leads me to my question. What is the risk of restarting the VRRP
> process? I see we have "soft" and "graceful" as options. Both sound fairly
> low-risk. I'm tempted to just restart the process on the backup router to
> see if that fixes the problem.
>
> What do you think?
>
> Thanks,
> John
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>