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
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
