Let's back a step and ask the questions we should have been asking in the first place:
* Are you an end-user or a Service Provider (somewhat reliable answer could be gleaned from Drew's e-mail address)? * What's the size of your network? * How many uplinks do you have? * How far apart are your uplinks? If it turns out Drew's uplinks are close together, all the beautiful design ideas presented here are a huge overkill. 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 > -----Original Message----- > From: Scott Granados [mailto:[email protected]] > Sent: Monday, January 04, 2010 10:03 PM > To: Drew Weaver; Cisco-nsp > Subject: Re: [c-nsp] BGP - Announcing routes to Internet providers. > > Drew, network statements are for the weak.:) > (I'm kidding of course) but there is a better way. > You should use community tagging in combination with prefix lists and > route > maps. The idea is that you announce routes according to a tag and the > behavior of the announcements depends on the specific tag applied. For > example, you could tag routes as peers, transits, global announce, etc and > formulate the type of feeds you give your customers by filtering against > communities so a customer wants peers and customers only you could match > the > two appropriate community tags. This also allows you to tag the > communities > you globally announce uniquely and make the announcements in a unified way > at your edges. If you accompany this method with the appropriate > redistribute static, redistribute connected, etc and use route maps to > control this behavior you can remove the need for network statements > completely and greatly decrease the things you need to modify and as a > result the possible mistakes. The other upside here is you can mark your > more specifics as do not export and better control traffic internally > better > directing the traffic in your example. It also allows you to accept > communities from your customers and have automatic actions taken based on > the tags they apply. Let me know if you need some configuration examples. > > > > ----- Original Message ----- > From: "Drew Weaver" <[email protected]> > To: "Cisco-nsp" <[email protected]> > Sent: Monday, January 04, 2010 12:35 PM > Subject: [c-nsp] BGP - Announcing routes to Internet providers. > > > > Howdy, > > > > I am trying to figure out if there is a different/newer/better(?) way to > > announce our public IP ranges to our Internet providers, currently we > are > > declaring our subnets in 'network statements' in the BGP configuration, > we > > have static routes setup like ip route x.x.x.x 255.255.224.0 Null0 254 > and > > then we have a extended access-list applied to each peer with our net > > blocks listed in them. > > > > It appears that because of the network statements, the supernet routes > > (/18s, /19s, etc) are being distributed via BGP to the rest of the > network > > which is by design(I assume). This doesn't seem ideal because if traffic > > is sent to an IP address that doesn't have a more specific route than > say > > /18, or /19 it travels all the way through the network to the edge > before > > stopping. I might be blowing the impact of this out of proportion, but > it > > just seems like a waste of resources. > > > > Does anyone know of a seemingly more sensible way of doing this? > > > > -Drew > > > > > > > > _______________________________________________ > > cisco-nsp mailing list [email protected] > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
