[c-nsp] iBGP peerings timing out

[Oliver Boehmer (oboehmer)]

Kevin,

see
http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_
guide09186a00803b8dd9.html and 
http://www.cisco.com/en/US/products/ps6922/products_feature_guide09186a0
0807c64d0.html for NHT and selective NHT respectively..
These features are not yet widely available, you need halfway recent
code..

	oli

Kevin Barrass <mailto:K.J.Barrass at leeds.ac.uk> wrote on Wednesday,
October 31, 2007 1:08 PM:

> 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