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