Hello, I've also come to think that there should be global communities for the basic purposes that most autonomous systems have built their own communities for. My approach is probably a little different to those of the other contributers to this discussion. Here is a sketch of the new well-known communities I have come up with: 0xFFFn:arg where n designates a function and arg designates a parameter to the function. These could be the functions: n=0 Never announce to AS <arg>. n=1 May announce to AS <arg>. n=2 If you announce to AS <arg>, prepend your own AS once. n=3 If you announce to AS <arg>, prepend your own AS twice. : : n=7 If you announce to AS <arg>, prepend your own AS six times. n=8 When announcing to AS <arg>, change this community to "local-AS" n=9 When announcing to AS <arg>, change this community to "no-advertise" n=10 When announcing to AS <arg>, change this community to "no-export" n=11 Reserved for brainstorming. n=12 Reserved for brainstorming. n=13 Reserved for brainstorming. n=14 Reserved for brainstorming. n=15 This contains the old well-known communities. Perhaps this could also double as "set local preference to <arg>?" 0xFFF0 is 65520, so 0xFFFn is 65520+n. Now I'm not saying these are all useful. I for one don't like to see anyone prepend more than three times and setting "no-advertise" at a distant location can also have quite nasty consequences. They may still have use in some special circumstances. Further brainstorming: an arg of 0 could be interpreted as "all transits" and 65535 as "all peers." If these special cases were to be hard coded into the BGP implementation, then there should be a way to mark sessions as transit/peering/other. If on the other hand support for these communities would be simply via auto-generated route-maps, you would only have to tell the generator the type of the session, and since the data for the generator would most probably come from a database of some kind the generator would get the type from there automagically. These communities should be able to travel through multiple autonomous systems. They should be usable to influence not only your transits' transits' routing decisions, but your transits' peers', your transits' transits' peers', your transits' transits' transits' peers' and so on. Getting all involved parties to turn on send-community on all involved BGP sessions is of course a challenge, but a one that has already been overcome with the existing "transit provider proprietary" communities where needed. Randy Bush pointed out an underlying problem with trusting preference hints from distant autonomous systems. I would like to argue the case against him and for letting everyone influence one's routing decisions. Suppose I have a transit T, a peer P, a customer C and a distant third party D. Suppose also that D has contractual agreements that result in me hearing D's routes from all of T, P and C. By default I would prefer D's routes heard from C. However, if D wishes me to use T or P to reach D instead, D can do so without the use of any communities. D can lower the preference of a path through P or C by arranging it so that I don't hear D from P or C, and D can increase the preference of a path by making me hear D's routes as more specifics from there. Both of these practises I frown upon. I would therefore see that it would be in my best interest to let D influence my routing decisions directly instead of littering my routing table or eating at the redundancy between my customers and D. Furthermore it should be in D's best interest not to give hints to use a bad path between D and me. If D would choose to maliciously abuse my trust (whether via the kludges or via the preference hints presented) I can always work to override or filter the bad routes and try to contact D's upstreams or D directly to resolve the issue. Alex Bligh noted that main stream IOS has insufficient means of manipulating communities. The bleeding edge versions have had methods for removing only some communities while preserving others for a good time now. I do agree though that routing policies can often be much more complicated than what is implementable with route-maps no matter how modern. -- Aleksi Suhonen Here is a sample shell script that does simple automagic. If anyone would use it, it would need to be modified to implement one's own routing policy too. It is included only as an example and proof of concept. I have not tested that what it produces actually works. #!/bin/sh # Usage: this-program my-as their-as their-ip comm-list session-type # comm-list: index of first available "ip community-list" # session-type: (T)ransit (P)eer (C)ustomer my_as=$1 their_as=$2 their_ip=$3 comm_deny=$4 comm_pre1=`echo 1+$4|bc` comm_pre2=`echo 2+$4|bc` comm_pre3=`echo 3+$4|bc` comm_pre4=`echo 4+$4|bc` comm_pre5=`echo 5+$4|bc` comm_pre6=`echo 6+$4|bc` comm_loas=`echo 7+$4|bc` comm_noad=`echo 8+$4|bc` comm_noex=`echo 9+$4|bc` # these can be reused for all sessions comm_local_pref_80=1 comm_local_pref_90=2 comm_local_pref_110=3 comm_remove=4 # set these to your values transit_route_tag=${my_as}:666 peer_route_tag=${my_as}:555 customer_route_tag=${my_as}:777 route_map_name_prefix=axu-${their_as} case $5 in T*) announce_community=$customer_route_tag denounce_community="$transit_route_tag $peer_route_tag" tag_community=$transit_route_tag default_preference=90 their_class=0 ;; P*) announce_community=$customer_route_tag denounce_community="$transit_route_tag $peer_route_tag" tag_community=$peer_route_tag default_preference=100 their_class=65535 ;; *) announce_community="$transit_route_tag $peer_route_tag $customer_route_t ag" denounce_community="" tag_community=$customer_route_tag default_preference=101 their_class=65534 ;; esac denounce_community="$denounce_community 65520:${their_as} 65520:${their_class}" cat <<EOF ! reused community-lists ip community-list $comm_local_pref_80 deny 65535:100 ip community-list $comm_local_pref_80 permit 65535:80 ip community-list $comm_local_pref_90 deny 65535:100 ip community-list $comm_local_pref_90 permit 65535:90 ip community-list $comm_local_pref_110 deny 65535:100 ip community-list $comm_local_pref_110 permit 65535:110 ip community-list $comm_remove permit 65535:80 65535:90 65535:100 65535:110 ip community-list $comm_remove permit $transit_route_tag $peer_route_tag ip community-list $comm_remove permit $customer_route_tag ! new community-lists ip community-list $comm_deny permit $denounce_community ip community-list $comm_pre1 permit 65522:${their_as} ip community-list $comm_pre1 permit 65522:${their_class} ip community-list $comm_pre2 permit 65523:${their_as} ip community-list $comm_pre2 permit 65523:${their_class} ip community-list $comm_pre3 permit 65524:${their_as} ip community-list $comm_pre3 permit 65524:${their_class} ip community-list $comm_pre4 permit 65525:${their_as} ip community-list $comm_pre4 permit 65525:${their_class} ip community-list $comm_pre5 permit 65526:${their_as} ip community-list $comm_pre5 permit 65526:${their_class} ip community-list $comm_pre6 permit 65527:${their_as} ip community-list $comm_pre6 permit 65527:${their_class} ip community-list $comm_loas permit 65528:${their_as} ip community-list $comm_loas permit 65528:${their_class} ip community-list $comm_noad permit 65529:${their_as} ip community-list $comm_noad permit 65529:${their_class} ip community-list $comm_noex permit 65530:${their_as} ip community-list $comm_noex permit 65530:${their_class} route-map ${route_map_name_prefix}-in permit 10 match community $comm_local_pref_80 set local-preference 80 set comm-list $comm_remove delete set community $tag_community additive ! route-map ${route_map_name_prefix}-in permit 20 match community $comm_local_pref_90 set local-preference 90 set comm-list $comm_remove delete set community $tag_community additive ! route-map ${route_map_name_prefix}-in permit 30 match community $comm_local_pref_110 set local-preference 110 set comm-list $comm_remove delete set community $tag_community additive ! route-map ${route_map_name_prefix}-in permit 40 set local-preference $default_preference set comm-list $comm_remove delete set community $tag_community additive ! route-map ${route_map_name_prefix}-out deny 10 match community $comm_deny ! route-map ${route_map_name_prefix}-out permit 20 match community $comm_pre1 set as-path prepend ${my_as} ! route-map ${route_map_name_prefix}-out permit 30 match community $comm_pre2 set as-path prepend ${my_as} ${my_as} ! route-map ${route_map_name_prefix}-out permit 40 match community $comm_pre3 set as-path prepend ${my_as} ${my_as} ${my_as} ! route-map ${route_map_name_prefix}-out permit 50 match community $comm_pre4 set as-path prepend ${my_as} ${my_as} ${my_as} ${my_as} ! route-map ${route_map_name_prefix}-out permit 60 match community $comm_pre5 set as-path prepend ${my_as} ${my_as} ${my_as} ${my_as} ${my_as} ! route-map ${route_map_name_prefix}-out permit 70 match community $comm_pre6 set as-path prepend ${my_as} ${my_as} ${my_as} ${my_as} ${my_as} ${my_as} ! route-map ${route_map_name_prefix}-out permit 80 match community $comm_loas set comm-list $comm_loas delete set community local-AS additive ! route-map ${route_map_name_prefix}-out permit 90 match community $comm_noad set comm-list $comm_noad delete set community no-advertise additive ! route-map ${route_map_name_prefix}-out permit 100 match community $comm_noex set comm-list $comm_noex delete set community no-export additive ! route-map ${route_map_name_prefix}-out permit 110 router bgp ${my_as} neighbor ${their_ip} remote-as ${their_as} neighbor ${their_ip} next-hop-self neighbor ${their_ip} send-community neighbor ${their_ip} remove-private-AS neighbor ${their_ip} route-map ${route_map_name_prefix}-in in neighbor ${their_ip} route-map ${route_map_name_prefix}-out out EOF
Hmm, we just are discussing this issue in the private mail -:). The internet is ripen for this idea, isn't it? Can I add you to this discussion (am not sure if it was ready for the nanog at whole yet)? You are quite right, but my concept of this was another a little. First of all, any ISP can realise only those communities which do not restrict their own policies and make the routing more stable. Second, why don't you mentioned the AS-PREPEND methods are widely used only because there is not well known community _SET-LOW-LOCALPREF_ known buy the over-world ISP's. I think, it should be started from the simple things which can be realised. First of all, there is a global demand for the BACK-UP well-known community. This days ISP often use different ASxxx:70 etc communities to distinguish back-up and primary links, or (for example) RUSSIA-ONLY+BACK-UP/INTERNATIONAL link usages. It works fine, except existing trigger effect - if you back-up announce have not glocal decreasing localpreference over the world, and there is a few transit AS-es between your primary and secondary links, there exist the trigger effect - after the back-up link became primary, the right connectivity can not turn back after the primary link will be restored. I can explain this in details, if you want. This is the first demand, and moreover, it's safe to realise such option over the world-wide ISP because it don't restrict existing policies but prevent you from the numerous AS-PREPEND's (did someone attempted to calculate the number os this prepends in the existing network?). This is, WORST-PATHS (or BACK-UP-PATHS) global community should be the first step, and should be _HIGHLY RECOMMENDED FOR REALISATION_. The second proposals could be ones you proposed below, with one only change - it's better to have _set up WORST-PATHS community_ instead of _add 10 AS-PREPENDS_ in most cases. May be (this can restrict existing policies and I am not sure) there is demand for the REGIONAL-BASED communities (WORST-PATHS-FOR-{AMERICA/EUROPE/AZIA/etc}, but it seems for me the crazy idea. This communities should be _RECOMMENDED IF DO NOT RESTRICT EXISTING POLICIES_. In addition, there is demand to make internal-used communities more safe than this days (if ISP use it's internal communities and the customer-defined communities, it have a chance to pass customer's communities into his network or to drop out all customer-defined communities including the global ones). Then, please point me any cases when you does need NO-EXPORT or NO-ADVERTISE communities (if you are not the primary ISP)? Usially, you need - no export to the uplinks, or back-up to the uplinks - no export to the peers, or back-up to the peers (last restrict the policies, btw) - no export to the expansive inter-continent links, or back-up to those links.
n=7 If you announce to AS <arg>, prepend your own AS six times. ^^^^^^^^^^^^ Just what I was talking about - wrong method used because we had not another one... -:) See the fist step above...
n=15 This contains the old well-known communities. Perhaps this could also double as "set local preference to <arg>?" Approx what I meant, but remember - ISP can't allow transit or peering neighbour to inject pathes withouth strict control, and can't allow you ANY localpref. But usially they can allow you (and anyone) to use decreasing-communities (instead of writing 10 - 20 prepends_.
Alex Bligh noted that main stream IOS has insufficient means of manipulating communities. The bleeding edge versions have had methods for removing only some communities while preserving others for a good time now. I do agree though that routing policies can often be much more complicated than what is implementable with route-maps no matter how modern. Yes, and it's very pleasant to have in ISP some SELECTION-CLASS allowing you to define community-localpref interaction withouth writing it in every route-map explicitly.
But its' more CISCO concern.
-- Aleksi Suhonen
Here is a sample shell script that does simple automagic. If anyone would use it, it would need to be modified to implement one's own routing policy too. It is included only as an example and proof of concept. I have not tested that what it produces actually works.
#!/bin/sh # Usage: this-program my-as their-as their-ip comm-list session-type # comm-list: index of first available "ip community-list" # session-type: (T)ransit (P)eer (C)ustomer
my_as=$1 their_as=$2 their_ip=$3 comm_deny=$4 comm_pre1=`echo 1+$4|bc` comm_pre2=`echo 2+$4|bc` comm_pre3=`echo 3+$4|bc` comm_pre4=`echo 4+$4|bc` comm_pre5=`echo 5+$4|bc` comm_pre6=`echo 6+$4|bc` comm_loas=`echo 7+$4|bc` comm_noad=`echo 8+$4|bc` comm_noex=`echo 9+$4|bc`
# these can be reused for all sessions comm_local_pref_80=1 comm_local_pref_90=2 comm_local_pref_110=3 comm_remove=4 # set these to your values transit_route_tag=${my_as}:666 peer_route_tag=${my_as}:555 customer_route_tag=${my_as}:777 route_map_name_prefix=axu-${their_as}
case $5 in T*) announce_community=$customer_route_tag denounce_community="$transit_route_tag $peer_route_tag" tag_community=$transit_route_tag default_preference=90 their_class=0 ;; P*) announce_community=$customer_route_tag denounce_community="$transit_route_tag $peer_route_tag" tag_community=$peer_route_tag default_preference=100 their_class=65535 ;; *) announce_community="$transit_route_tag $peer_route_tag $customer_route_t ag" denounce_community="" tag_community=$customer_route_tag default_preference=101 their_class=65534 ;; esac
denounce_community="$denounce_community 65520:${their_as} 65520:${their_class}"
cat <<EOF ! reused community-lists ip community-list $comm_local_pref_80 deny 65535:100 ip community-list $comm_local_pref_80 permit 65535:80 ip community-list $comm_local_pref_90 deny 65535:100 ip community-list $comm_local_pref_90 permit 65535:90 ip community-list $comm_local_pref_110 deny 65535:100 ip community-list $comm_local_pref_110 permit 65535:110 ip community-list $comm_remove permit 65535:80 65535:90 65535:100 65535:110 ip community-list $comm_remove permit $transit_route_tag $peer_route_tag ip community-list $comm_remove permit $customer_route_tag
! new community-lists ip community-list $comm_deny permit $denounce_community ip community-list $comm_pre1 permit 65522:${their_as} ip community-list $comm_pre1 permit 65522:${their_class} ip community-list $comm_pre2 permit 65523:${their_as} ip community-list $comm_pre2 permit 65523:${their_class} ip community-list $comm_pre3 permit 65524:${their_as} ip community-list $comm_pre3 permit 65524:${their_class} ip community-list $comm_pre4 permit 65525:${their_as} ip community-list $comm_pre4 permit 65525:${their_class} ip community-list $comm_pre5 permit 65526:${their_as} ip community-list $comm_pre5 permit 65526:${their_class} ip community-list $comm_pre6 permit 65527:${their_as} ip community-list $comm_pre6 permit 65527:${their_class} ip community-list $comm_loas permit 65528:${their_as} ip community-list $comm_loas permit 65528:${their_class} ip community-list $comm_noad permit 65529:${their_as} ip community-list $comm_noad permit 65529:${their_class} ip community-list $comm_noex permit 65530:${their_as} ip community-list $comm_noex permit 65530:${their_class}
route-map ${route_map_name_prefix}-in permit 10 match community $comm_local_pref_80 set local-preference 80 set comm-list $comm_remove delete set community $tag_community additive ! route-map ${route_map_name_prefix}-in permit 20 match community $comm_local_pref_90 set local-preference 90 set comm-list $comm_remove delete set community $tag_community additive ! route-map ${route_map_name_prefix}-in permit 30 match community $comm_local_pref_110 set local-preference 110 set comm-list $comm_remove delete set community $tag_community additive ! route-map ${route_map_name_prefix}-in permit 40 set local-preference $default_preference set comm-list $comm_remove delete set community $tag_community additive ! route-map ${route_map_name_prefix}-out deny 10 match community $comm_deny ! route-map ${route_map_name_prefix}-out permit 20 match community $comm_pre1 set as-path prepend ${my_as} ! route-map ${route_map_name_prefix}-out permit 30 match community $comm_pre2 set as-path prepend ${my_as} ${my_as} ! route-map ${route_map_name_prefix}-out permit 40 match community $comm_pre3 set as-path prepend ${my_as} ${my_as} ${my_as} ! route-map ${route_map_name_prefix}-out permit 50 match community $comm_pre4 set as-path prepend ${my_as} ${my_as} ${my_as} ${my_as} ! route-map ${route_map_name_prefix}-out permit 60 match community $comm_pre5 set as-path prepend ${my_as} ${my_as} ${my_as} ${my_as} ${my_as} ! route-map ${route_map_name_prefix}-out permit 70 match community $comm_pre6 set as-path prepend ${my_as} ${my_as} ${my_as} ${my_as} ${my_as} ${my_as} ! route-map ${route_map_name_prefix}-out permit 80 match community $comm_loas set comm-list $comm_loas delete set community local-AS additive ! route-map ${route_map_name_prefix}-out permit 90 match community $comm_noad set comm-list $comm_noad delete set community no-advertise additive ! route-map ${route_map_name_prefix}-out permit 100 match community $comm_noex set comm-list $comm_noex delete set community no-export additive ! route-map ${route_map_name_prefix}-out permit 110
router bgp ${my_as} neighbor ${their_ip} remote-as ${their_as} neighbor ${their_ip} next-hop-self neighbor ${their_ip} send-community neighbor ${their_ip} remove-private-AS neighbor ${their_ip} route-map ${route_map_name_prefix}-in in neighbor ${their_ip} route-map ${route_map_name_prefix}-out out EOF
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
Here is a sketch of the new well-known communities I have come up with:
0xFFFn:arg
You should attempt to implement it; I suspect that its not going to be easy. If you want this to go forward, I suggest that you draft configs for a number of router types (cisco, juniper, gated). I also suggest that you draft configs for everyone else to do if they just want to let these new communities through without acting on them. Remember that communities are dropped by default - unless you configure your routers to let them through. --asp@partan.com (Andrew Partan)
Here is a sketch of the new well-known communities I have come up with:
0xFFFn:arg
You should attempt to implement it; I suspect that its not going to be easy.
If you want this to go forward, I suggest that you draft configs for a number of router types (cisco, juniper, gated).
I also suggest that you draft configs for everyone else to do if they just want to let these new communities through without acting on them. Remember that communities are dropped by default - unless you configure your routers to let them through. More and more ISP allow communities through; and anyway the idead to allow
the couter treat some part of community as an _arg_ is a very interesting (at least for the future implementations and/or protocols).
--asp@partan.com (Andrew Partan)
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
participants (4)
-
Aleksi Suhonen -
Alex P. Rudnev -
Andrew Partan -
Sean Butler