The memory impact isn't that bad and one person's over kill is another
person's good planning ahead of time. Why not do something right the first
time and prevent the redesign / reconfiguration down the road which makes
things that much more tricky in the long term. I can't tell you how many
messes I get dragged in to that need cleaning up because someone took the up
front short cuts. We're not talking about rocket science here, from the
atlantic.net address and from Drew's long history on the list I assumed (and
I think correctly) that there was the required clue there and justified
need.
----- Original Message -----
From: "Ivan Pepelnjak" <i...@ioshints.info>
To: "'Scott Granados'" <gsgrana...@comcast.net>; "'Drew Weaver'"
<drew.wea...@thenap.com>; "'Cisco-nsp'" <cisco-nsp@puck.nether.net>
Sent: Monday, January 04, 2010 11:30 PM
Subject: RE: [c-nsp] BGP - Announcing routes to Internet providers.
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:gsgrana...@comcast.net]
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" <drew.wea...@thenap.com>
To: "Cisco-nsp" <cisco-nsp@puck.nether.net>
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 cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
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/
