[c-nsp] iBGP peerings timing out

[Kevin Barrass]

Hi

Thank you for the reply what you say below looks right from our testing
30 seconds after R1 fails BGP removes the route to 0.0.0.0/0 via ISPR1
as the next hop is no longer available but wierdly 30 seconds later BGP
re--installs the route via ISPR1 as though it now thinks it can get to
ISPR1 via 0.0.0.0/0 which sounds right from below then when the iBGP
peer to R1 times out the BGP routing table now goes back via ISPR2.

I would be interested to try the selective tracking option can you
please email me some links to docs on this and I will test on the lab.

Kind Regards

Kev

-----Original Message-----
From: Oliver Boehmer (oboehmer) [mailto:oboehmer at cisco.com] 
Sent: 31 October 2007 11:12
To: Kevin Barrass; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] iBGP peerings timing out

Kevin Barrass <> wrote on Wednesday, October 31, 2007 11:57 AM:

> Hi
> 
> On a test setup we have below,
> 
> ISPR1  ISPR2
>>      |  <--- point to point ethernet links
>>      |
> R1     R2
>>      |
>>      |
> ---------vlan100---------- <--- resilient ethernet backbone
>    |                |
>    |                |
>    R3               R4
> 
> R1 has eBGP peering to ISPR1 and R2 has eBGP peering to ISPR2. all 
> routers R1-R4 have iBGP peerings to each other. We are running EIGRP 
> only for the loopback addresses of the routers R1-R4 and the next hop 
> addresses to the ISP Routers 1 and 2.
> 
> We receive only a default route from both ISPR1 and ISPR2 which is 
> then passed to our other BGP routers over iBGP. We are not currently 
> re-distributing that default into EIGRP for this test.
> 
> If R1 fails "i.e. blows up" how long will it take for routers R2-R4 to

> know that the default route R1 was advertising over iBGP is no longer 
> valid. The way I understand it is that it would take either 3 * 30 
> seconds for the iBGP peer to time out or 1 minute for the next hop for

> routes advertised from R1 to be un-validated due to the next hop to
> ISPR1 dropping out of EIGRP is this the case.

Yes, unless R2-R4 still have a way of reaching the next-hop (which could
be through a default-route).

> If there is still a default route available will that mean that the 
> next hop to ISPR1 is still valid from iBGPs point of view.

yes, see above.

To improve this, we've integrated BGP Next-Hop Address Tracking in IOS.
With this feature, the next-hop going away will be signalled to BGP, and
BGP doesn't need to wait for the next periodic scanner run. There is an
addition to this called "Selective Address Tracking" which will allow
you to control which routes BGP will consider to determine if the
next-hop is still reachable. You need to use this feature if you also
have a default-route or a summary covering the next-hop in your routing
table. With the selective tracking, you could limit BGP to use /32
addresses, so once your NH is gone in EIGRP, BGP marks this NH as
unreachable and invalidates the prefixes.

	oli