[c-nsp] BGP network stops being advertized

[Jeff Fitzwater]

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.

It's also strange that it has been the same net in both incidences,  
even though there is another /16 that I announce along with some  
other /24s.

I was still advertising all the other nets just fine.

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.



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
>