Comprehensive community Guideline and Policies for an AS
I am looking to put together a comprehensive BGP communities guideline and policies for an AS starting from a blank slate. When I say comprehensive, I mean covers *everything* that is known to be best practice such as: Route Type Prepends Learned from Peers Learned from Peers Peers Learned from Transits Learned from Customers Learned from Customers Customers Advertise to Peers Advertise to Peers Peers Advertise to Transits Advertise to Customers Advertise to Customers Customers Local Preferences No exports No advertise Leaking to Peers/Transits/Customers Null-Route Region/POP And anything else I may have overlooked. Naturally, the resulting policy needs to be easily implementable on current IOS. My own experience and the publicly available information doesnt even come close to a consensus on the objectives that should be handled, let alone the number patterns preferred to be used. What I am looking for is a best practice guide on community policy setup. Barring that, I plan to continue examining every publicly published guideline to try to produce one, but likely as not it will suffer from the all to common human failing of shortsightedness. Thanks, Joe
What I am looking for is a best practice guide on community policy setup.
Barring that, I plan to continue examining every publicly published guideline to try to produce one, but likely as not it will suffer from the all to common human failing of shortsightedness.
Feel free to look at our online collection of BGP Community guides. Some are more extensive than others and some intentionally leave off internal identifers. http://www.onesc.net/communities As a yearly request, if anybody knows of guides out there that we do not have listed, please let me know. thanks, charles
Charles Gucker wrote:
What I am looking for is a best practice guide on community policy setup.
Barring that, I plan to continue examining every publicly published guideline to try to produce one, but likely as not it will suffer from the all to common human failing of shortsightedness.
Feel free to look at our online collection of BGP Community guides. Some are more extensive than others and some intentionally leave off internal identifers.
http://www.onesc.net/communities
As a yearly request, if anybody knows of guides out there that we do not have listed, please let me know.
thanks, charles
Its a great list and resource, and the real problem I am looking to address is trying to create a best of breed out of them all. I want to express my appreciation to you and to anyone else involved in maintaining this resource. Thanks, Joe
See nLayer. That should be the gold standard. :) On 2/20/09, Joe Maimon <jmaimon@ttec.com> wrote:
Charles Gucker wrote:
What I am looking for is a best practice guide on community policy setup.
Barring that, I plan to continue examining every publicly published guideline to try to produce one, but likely as not it will suffer from the all to common human failing of shortsightedness.
Feel free to look at our online collection of BGP Community guides. Some are more extensive than others and some intentionally leave off internal identifers.
http://www.onesc.net/communities
As a yearly request, if anybody knows of guides out there that we do not have listed, please let me know.
thanks, charles
Its a great list and resource, and the real problem I am looking to address is trying to create a best of breed out of them all.
I want to express my appreciation to you and to anyone else involved in maintaining this resource.
Thanks,
Joe
Kevin Blackham wrote:
See nLayer. That should be the gold standard. :)
A gold standard is precisely what I am looking for. http://onesc.net/communities/as4436/ nLayer's does look fairly comprehensive. A few nitpick that lead me to hesitate to adopt it. " The informational tags comprised of 4436:TCRPP T The type of relationship that the route was learned through C The continent where the route was learned R The region where the route was learned PP The POP location (city code) " *) Type of routes have a maximum of 6 possible types. That could be limiting. nLayer lists 1-5 types already, granted those are the typical relationships and should cover most needs. *) Pop location code has a maximum of 99. nLayer is already up to 30. What are they going to do when they reach 100? Suppose instead of cities you wanted to number pops? Quite conceivable to have multiple pops in the same city. " Import/Export Action Communities These communities define specific import/export behaviors, and contain location codes to specify which BGP sessions the actions should be applied to. The second half of the Community will always be 4 digits long, and will have the following structure: ASN:A0CR -or- ASN:A1PP ASN The Autonomous System Number to affect A The export action to perform C Continental code (or 0 for all continents) R Regional code (or 0 for all regions) PP POP Location code (city code) " Using other ASN's as part of your communities policy raises two issues: - Is it a good idea without drawback (sprint does this also but only with private ASNs)? - How will this scale to 4byte ASN's? Anyways, the point I am working from is that there are too many divergent approaches and all networks cant be that different and there should be one general approach that will work for all. Thanks, Joe
participants (3)
-
Charles Gucker -
Joe Maimon -
Kevin Blackham