UUNET supports a user configurable routing policy by allowing customers to
fine tune their routing announcements via the BGP community attribute. The
following information outlines the policy and demonstrates how customers can
implement the routing policy of their choice.
Customers now can set
values which modify the BGP attributes "Local Preference" and "AS Path Length"
as well as control which route(s) should be advertised to UUNET peers (ISPs).
These controls are customer implemented by advertising routes tagged with the
appropriate BGP community and when received UUNET will act on the community
value as shown below.
The attribute "LOCAL_PREF" is used to set a route
as "preferred" or "least preferred" over all others. Since BGP
selects the route
with the highest local preference a route can be made "preferred" by
setting the
"LOCAL_PREF" value higher than the default value of 100. Also, any route can be
made to be "least preferred" by setting the "LOCAL_PREF" value lower than the
default value of 100. The "LOCAL_PREF" setting is non-transitive and affects
routes only in the AS in which it is set and does not pass to external BGP
peers. The table below defines the values and actions for the "LOCAL_PREF"
attribute.
| ATTRIBUTE | LOCAL PREF VALUE | ACTION |
|---|---|---|
| Local Pref Default | 100 | Value of all customer routes by default |
| Local Pref Low | 80 | Use this route as a last resort |
| Local Pref High | 120 | Prefer this route over all others |
Customers may modify the UUNET "LOCAL_PREF" value by tagging their route
announcements with ONE of the communities defined below. Each route should be
tagged with only one value for "LOCAL_PREF." Once UUNET receives this route
announcement tagged with the appropriate community string for modifying
"LOCAL_PREF", the attribute will be set accordingly. "LOCAL_PREF" is set
immediately on the UUNET router to which the customer attaches. Please refer to
the table below for the community string values that UUNET will accept for
setting "LOCAL_PREF."
| COMMUNITY TAG | LOCAL_PREF VALUE |
|---|---|
| 701:80 | 80 |
| 701:120 | 120 |
A case may arise where 2 or more paths exist for the same destination
with the same "LOCAL_PREF" value. The next configurable option in BGP route
selection process is to lengthen the AS PATH. The route with the shortest AS
PATH LENGTH is preferred. The table below defines the values and actions for AS
PATH LENGTH.
| ATTRIBUTE | VALUE | ACTION |
|---|---|---|
| AS Path Length ADD-1 | 701 | Prepend the UUNET AS (701) one time |
| AS Path Length ADD-2 | 701 701 | Prepend the UUNET AS (701) two times |
| AS Path Length ADD-3 | 701 701 701 | Prepend the UUNET AS (701) three times |
The AS PATH LENGTH is adjusted at the egress or UUNET peering points to
all peers. The table below defines the community value for setting AS PATH
LENGTH and the total path length announced to peers.
| COMMUNITY TAG | AS PATH LENGTH |
|---|---|
| 701:1 | 701 701 |
| 701:2 | 701 701 701 |
| 701:3 | 701 701 701 701 |
UUNET maintains multiple autonomous systems with each one providing
continental coverage. AS 701 is used in North America, AS 702 provides coverage
for Europe, and AS 703 is growing in Asia. Routes UUNET hears from
customers are
advertised to all UUNET autonomous systems as well as UUNET peers. However,
customers have the ability to change this in two ways. Routes can be contained
to UUNET's AS's and not announced to peers or routes can be contained
to a UUNET
continental AS and not announced to peers. This is accomplished by filtering
routes based on a community value filtering at UUNET's egress points. The table
below defines the community values a customer may send to instruct UUNET to
filter route(s) to its peers.
| COMMUNITY TAG | ACTION |
|---|---|
| 701:20 | Keep within UUNET, don't announce to peers |
| 701:30 | Keep within Continental UUNET, don't announce to peers |
If for example, a customer is multi-homed to UUNET and maintains a web farm and wants all traffic destined for the web farm netowrk (191.255.1.0/24) to use the connection via Router A and all other traffic to use the connection via Router B, this could be achieved by modifying LOCAL_PREF:
Router A
!
ip bgp-community new-format
router bgp ASxx
neighbor 157.130.x.y remote-as 701
neighbor 157.130.x.y version 4
neighbor 157.130.x.y route-map to-UUNET out
neighbor 157.130.x.y send-community
!
ip as-path access-list 1 permit .*
!
ip address 101 permit ip 191.255.1.0 0.255.255.255 255.255.255.0
0.255.255.255
!
route-map to-UUNET permit 10
match ip address 101
set community 701:120
!
route-map to-UUNET permit 20
match as path 1
set community 701:80
!
The above example would set the value of LOCAL_PREF to 120 for all networks
listed in access list 101 and all other networks from ASxx would be sent with a
LOCAL-PREF value of 80.
Router B
!
ip bgp-community new-format
router bgp ASxx
neighbor 157.130.x.z remote-as 701
neighbor 157.130.x.z version 4
neighbor 157.130.x.z route-map to-UUNET out
neighbor 157.130.x.z send-community
!
!
ip as-path access-list 1 permit .*
!
ip address 101 permit ip 191.255.1.0 0.255.255.255 255.255.255.0
0.255.255.255
!
route-map to-UUNET permit 10
match ip address 101
set community 701:80
!
route-map to-UUNET permit 20
match as path 1
set community 701:120
!
The above example would set the value of LOCAL_PREF to 80 for all networks
listed in access list 101 and all other networks from ASxx would be sent with a
LOCAL-PREF value of 120. Technically, its not necessary to set the
LOCAL-PREF to
120 for the rest of the networks, using the default of 100 would work as well.
But by setting the LOCAL_PREf high makes for a more explicit routing policy. So
looking at the the routing announcements from both A and B, UUNET would select
Router A as the primary path for the customer's web farm and Router B for all
others destinations to this customer.
If for example, a customer is
connected to UUNET and a local exchange point and wants all of its peers at the
exchange points to prefer its direct connection over a alternative path
advertised by UUNET but still wants to use UUNET to reach UUNET customers and
other peers, this situation is best solved by modifying the AS PATH LENGTH. The
customers router configuration might look like this:
Router A
!
ip bgp-community new-format
router bgp ASxx
neighbor 157.130.x.y remote-as 701
neighbor 157.130.x.y version 4
neighbor 157.130.x.y route-map from-UUNET in
neighbor 157.130.x.y route-map to-UUNET out
neighbor 157.130.x.y send-community
!
ip community-list 2 deny 705:666
ip community-list 2 permit
!
ip as-path access-list 1 permit .*
!
route-map to-UUNET permit 10
match as-path 1
set community 701:2
!
route-map from-UUNET permit 10
match community 2
set community 701:80
!
Questions on this material should be directed to a Senior.