Regarding global BGP community values
Alex P. Rudnev
alex at Relcom.EU.net
Thu Oct 7 11:07:22 UTC 1999
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)
More information about the NANOG
mailing list