[c-nsp] Options for customer prefix injection into iBGP at the edge

[Scott Granados]

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" <justin at justinshore.com>
To: "'Cisco-nsp'" <cisco-nsp at puck.nether.net>
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  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/