Hi, so if I were you I'd go with options 1-3 inclusive.
use prefix lists inside route-maps to set the correct community and then
have route-maps that act on these. Also redistribute static, connected, etc
through and use a route-map to set the appropriate communities so something
like...
ip prefix list not-to-specific seq 5 permit 0.0.0.0/0 le 24
route-map transit1-in permit 10
match ip address prefix-list not-to-specific
set community as:666
or for a customer
ip prefix-list customera seq 5 permit 192.168.0.0/20
route-map customera-in seq 10 permit
match ip address prefix-list customera
set community as:115
You can also add in functions here to prepend your AS on a community tag,
set local pref, etc.
you would need to then just build your community lists so that they know
what to do with the various tags (666, no export, 115, announce, etc)
for your redistribution do the same match against your prefix list with your
CIDR for announcements, against another prefix list which allows for longer
prefixes for your internals (tag appropriately) and biggity bam you're set.
Tag everything differently for example peering prefixes learned differently
from transit and use the route-maps to apply the appropriate tag. This also
removes the need for network statements in your BGP section and once in
place greatly simplifies and I think in the end creates less room for fat
finger errors. With the different tags you will find it very simple to
provide customers what ever feed they wish whether it's customers only,
customers + peers, customers plus peers + transit, full routes, etc.
Thanks
Scott
----- Original Message -----
From: "Justin Shore" <[email protected]>
To: "'Cisco-nsp'" <[email protected]>
Sent: Thursday, September 03, 2009 12:31 PM
Subject: [c-nsp] Options for customer prefix injection into iBGP at the edge
I'm soliciting suggestions on the pros and cons on the assortment of ways
to inject customer routes into iBGP at the edge.
One could simply reference prefix-lists in the BGP config on a
per-neighbor basis (or peer-group). The downside to this is that
prefix-lists can't haven't inline comments for storing information about
the individual prefixes. As the prefixes on the edge grow I would think
that admin overhead and potential for errors would grow as well.
I could reference route-maps in the BGP config as well (per
neighbor/peer-group). I'm doing this today, matching against a
prefix-list to get my routes. The upside is I add a new sequence to the
route-map per customer and create a uniquely-named prefix-list per
customer. This of course requires more config and more potential typos
but makes changes as customers come and go much more clearcut (ie, there
is no question which prefixes belong to which customer). Another upside
is that I can also put specific communities on prefixes with a route-map.
I'm not doing this today but I plan to in the future as my BGP community
design progresses.
A third option is redistributing statics into BGP. This gives me the
opportunity to tag specific prefixes and filter them with a route-map so I
only redistribute the prefixes that I want redistributed. I can also name
static routes. I need a static route anyway to tack up the route for
outbound advertisement and to prevent loops. The downside is that I hate
using redistribution. I'm not a big fan of it. I've been bit too many
times to consider redistribution a good method of doing anything. It will
also result in higher CPU load as the RIB is frequently parsed for statics
and processed with the route-map if I'm not mistaken. Correct?
A fourth option would be to use distribute-lists. I can use remarks to
label my individual prefixes in the ACL which is good but I end up with
one large distribute-list ACL for all my customer prefixes. That means
any errors could affect all customers at once. I also don't end up using
route-maps so I don't get to set communities on advertised prefixes.
And finally I could use a combination of any of the above to accomplish my
goals.
What methods do my SP colleagues prefer to use when managing the injection
of customer routes into iBGP? I'm open to suggestions. I've tried both
of the first 2 options and lean towards the 2nd. It's time I get the
remaining customer routes out of the IGP but unfortunately I can't see far
enough ahead to decide which method is best. I can't help but to think
that there must be a better way to accomplish my goals without increasing
my work load too much and without increasing the likelihood of making
major mistakes.
Thanks
Justin
_______________________________________________
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/
