[c-nsp] BGP network stops being advertized

[Pekka Savola]

On Thu, 5 Jun 2008, Jeff Fitzwater wrote:
> The /16 net has subs on multiple interfaces and also my loopback.   I did as 
> you mentioned, by looking at what was being advertised to my peers, that's 
> how I knew what the problem was to begin with.
...
> One thing we do often is add null routes and we have BGP auto-summarize ON. 
> So I might think that every time we add a null some IOS process must crunch 
> the statics to do the summarization.   Not sure exactly how this might impact 
> the BGP route injection.

Smells like a problem with auto-summarization, possibly a bug.  It's 
much preferable to disable auto-summarization and just add a static 
route for /16 to null0 and redistribute that.

>
> Is it possible for our IGP (RIP) to inject something into the table that 
> might do this ?
>
> Thanks for the help.
>
>
> Jeff
>
>
> On Jun 5, 2008, at 5:29 PM, Deepak Jain wrote:
>
>> 
>> 
>> Justin Shore wrote:
>>> Jeff Fitzwater wrote:
>>>> For some unknown reason we stop announcing the 128.112.0.0/16 to all our 
>>>> ISPs.  This is the second time it has happened in about 2 months.
>>>> 
>>>> To get things going again I have to remove the BGP "network 128.112.0.0" 
>>>> statement and just add it again.
>>> Jeff,
>>> What did your router think it was advertising when the problem occurred? 
>>> sh ip bgp a.b.c.d advertised-routes  will give you what you need.  For 
>>> example:
>>> 7206-1.clr#sh ip bgp neighbors aa.bb.cc.dd advertised-routes
>>> BGP table version is 20975573, local router ID is aa.bb.98.59
>>> Status codes: s suppressed, d damped, h history, * valid, > best, i - 
>>> internal,
>>>             r RIB-failure, S Stale
>>> Origin codes: i - IGP, e - EGP, ? - incomplete
>>>  Network          Next Hop            Metric LocPrf Weight Path
>>> *> aa.bb.96.0/21    0.0.0.0                  0         32768 i
>>> *> aa.bb.104.0/21   10.64.0.129            200         32768 i
>>> *> aa.bb.112.0/21   10.64.0.129            200         32768 i
>>> *> aa.bb.120.0/21   0.0.0.0                  0         32768 i
>>> *> aa.cc.192.0/21   0.0.0.0                  0         32768 i
>>> *> aa.cc.200.0/21   10.64.0.129            200         32768 i
>>> Total number of prefixes 6
>>> I would be curious to see if there was a RIB-failure at the time of the 
>>> problem.  Has your SP told you that you aren't advertising the prefix to 
>>> them?  How are you getting the route that matches your advertisement into 
>>> the RIB?  Local static or learned via your IGP?
>>> Justin
>> 
>> 
>> Justin hit on most of the right points. The only one I'd add is that you 
>> probably want to make sure your address blocks are "nailed down" to the 
>> loopback or another interface (usually a static route of last resort to the 
>> loopback address/interface). This will ensure that even if the route is 
>> withdrawn within your network for some reason, your border will still 
>> announce it to your upstreams.
>> 
>> If you aren't doing any TE and/or aren't prepending announcements, you may 
>> want to consider having your SPs nail the announcements into their BGP mesh 
>> for you (with your AS).  This will reduce the potential for 
>> jitter/flaps/etc. This isn't as commonly done as it used to be, but it 
>> works.
>> 
>> Deepak Jain
>> AiNET
>> 
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings