On Tue, Jan 05, 2010 at 08:30:27AM +0100, Ivan Pepelnjak wrote: > > And, BTW, I wish those of you that propose redistributing connected and > static routes into BGP a huge budget you'll need to upgrade RAM and TCAM of > your routers/switches when everyone decides (after reading this mailing list > :) that following your recommendations unconditionally is a good idea :D > > Ivan >
I believe Scott was advocating using redistribution with route-maps to community tag internal-only routes as no-export or similar to prevent sending them to their upstreams. This is a way to keep customer prefixes in iBGP instead of your IGP. Your actual global announcements can be tagged with communities when generated (either by redistribution, or network statements with route-maps) to be matched by per-eBGP peer route-maps to influence (prepend, block, allow, change MED, tag with provider community) their behavior. This provides more control over your actual global announcements, and provides much more information regarding your actual customer prefixes as Scott stated when announcing to peers or other customers, especially if you publish a BGP community document for them to reference. (See extremely long NANOG thread from Oct/Nov regarding upstream community support) Regarding Drew's initial question -- unless you are seeing significant enough traffic to your unassigned address space to cause actual congestion or network issues, there really isn't a performance problem. If it is, the suggestion of setting next-hop for your static hold-down routes to an IP that is routed to Null0 on all your edge routers (192.0.2.1 is what I commonly see listed in remote-blackholing documents) would cause the traffic to be dropped at the ingress edge instead of transiting the network would cause the traffic to be dropped at the ingress edge instead of crossing your network from ingress to where the annoucement is sourced. -- Brandon Ewing (nicot...@warningg.com)
pgpW1MtSYXItB.pgp
Description: PGP signature
_______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/