Comprehensive community Guideline and Policies for an AS

Mailman List Mirror (Read Only)
1

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

2

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

3

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

4

See nLayer. That should be the gold standard. :slight_smile:

5

Kevin Blackham wrote:

See nLayer. That should be the gold standard. :slight_smile:

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