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" <jneiber...@gmail.com>
To: <juniper-nsp@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
