On Thursday, March 20, 2014 08:26:45 PM Andy Litzinger
wrote:
Hi Adam,
how can i tell if fast external failover is enabled? I
haven't had any luck finding the command or the Junos
documentation. Same question for Next-Hop Address
Trac(k)ing
These are mostly Cisco concepts, and even
That would be one hell of a coincidence to have the same bug across different
implementations of NSR/NSF across two different vendors. That said, stranger
things literally have happened. There are a bunch of other possible causes
though.
What happened in the rest of the network? Was all
You can verify whether the fast external failover is enabled for the
peer/globally (should be on by default).
-in that case the 3min hold down timer does not need to expire when the link to
neighbor fails and the adj-rib-in is flushed immediately.
Also you can verify whether the BGP Next-Hop
Hi Payam,
yes the logs clearly show that the failures start after the link goes
down.
We have external monitors set up via a 3rd party monitoring ASP that watch
our various services. Some, but not all, of them reported connection
issues for about 4 minutes. We also run 'rpm' probes from the
Hi John,
you might be spot on- graceful restart is configured for this peer and it
does look like my side is respecting it:
show bgp neighbor
snip
Options: Preference HoldTime AuthKey GracefulRestart LogUpDown PeerAS
Refresh
I'll let you know what I find out
-andy
On Thu, Mar 13, 2014 at
John,
do you have any idea how to view the negotiated parameters for Graceful
Restart? Or peak into its current state?
I tried setting traceoptions: protocols bgp group my-group traceoptions
flag graceful-restart detail
but that hasn't yielded any log messages. perhaps negotiation only happens
One of my providers (and eBGP neighbor) recently had a hardware failure
which caused the port that connects our two routers to go down. My router
did detect the link failure and BGP pretty much immediately transitioned to
an Idle state. my side is a Juniper MX80 running 11.4, their side I
Once upon a time, Andy Litzinger andy.litzinger.li...@gmail.com said:
what surprised me is that it looks like routes toward that provider were
not immediately removed from my routing table. Instead i see evidence of
blackholing for almost 3 minutes.
Are you taking full routes from this
Hi Chris,
yes, i am taking full routes from this neighbor.
is there any way to reduce the time it takes to handle the updates? if i
wanted to test this behavior in my lab, what would i want to watch?
(logs/traceoptions)
i don't think I've seen this behavior during scheduled maintenance- for
Are you sure? Ive never seen an update to remove routes take 3min.
Andy, are you sure the 3min outage was after the link hard down and not just
prior? Guessing this is easy to find due to time stamps. Ive seen this due to
line protocol down and everything blackholes until bgp fails but never
10 matches
Mail list logo
