Individual Contribution James Uttaro Internet Drafts AT&T Expiration Date April 2003 Customer Managed Gateway Selection for RFC2547 VPN(s) draft-uttaro-mult-gws-00.txt 1. Status of This Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited 2. Abstract This document presents an application of the BGP community attribute in simplifying the implementation and configuration of routing policies between two or more VPN service providers. It is assumed that RFC2547 has been implemented to provide the VPN service although this is not a requirement of this application It shows how use of the community attribute along with the setting of a BGP metric can be used by customers to select the best gateway between one or more VPN service providers. This technique simplifies configuration and management at the provider level, and gives the customer the ability to control its own routing policy with respect to the selection of gateways between service providers. 3. Introduction In a global VPN mult-provider scenario, it will be common for customers to have more than one VPN service provider. Customers will need to devise routing strategies that take advantage of the nearest VPN gateway between one or more VPN service providers. The current paradigm requires coordination between the VPN service providers and the customer to favor a certain gateway. This coordination would require identification of prefixes that need to use a specific gateway as the default. Due to the large number of customers a provider serves, an inordinate burden is placed on the customer to provide the information, the service provider to develop OSS(s) to capture customer information and provision the appropriate configuration on the router. This approach presents management and scalability problems for service providers due to the large number of customers that are anticipated to utilize a VPN solution. This document presents an application of the BGP community attribute that will significantly simplify routing strategies in the global VPN solution space. It represents a paradigm shift in that it provides customers with the ability to control routing strategies with respect to it's service providers. This ability is provided at a prefix based granularity rather than the current AS based granularity available today. 4. LOCAL_PREF Configuration and its Drawbacks Currently customers require that it's service providers configure their border routers with a customized configuration to implement their desired routing strategy for selecting the best gateway between VPN(s). It is common for a provider to assign higher BGP "LOCAL_PREF" values for routes that need to be primary at a specific gateway. This allows for routing strategies to be done at the ip prefix level instead of at an AS PATH level. Primarily due to scalability concerns it becomes impractical for providers to provide "LOCAL_PREF" type customization at an ip prefix level instead of at an AS Path level. There are several drawbacks to the customer and provider to provide "LOCAL_PREF" configuration at the ip prefix level. * The ordering and provisioning OSS(s) need to be developed to capture detaililed ip prefix information, store it and provision it on the gateway routers. Customer information can be expected to change as customers devise different routing strategies. OSS(s) and processes need to be enhanced to deal with these changes. * The configuration of the gateway router will become unwiedly. Each ip prefix as identified by the customer will need to have a some manipulation done to favor or not favor that route at this gateway and possibly other gateways. This could be modification of the AS_PATH, setting of the LOCAL_WEIGHT or AS_PATH manipulation. * Customers cannot implement routing strategies without conveying information to multiple VPN service providers. * Keeping configurations synchronized, up-to-date can become problematic at gateway routers. 5. Implementation Each customer will identify the gateway of interest for a specific route by assigning a BGP Community Value to the route for the desired gateway for that route. Load balancing can be accomplished by assigning multiple BGP Community Values to the route. Upon receit of the route into the VPN Service Provider routing domain a route map will be used to identify the gateway(s) of interest. Gateway(s) that the route has been recieved over will set the MED metric to 0 for the route. All other gateways not identified as being primary will have a MED metric of 50 applied at those gateway(s) to the route. As MED is non-transitive attribute this setting will not affect the customers' routing domain. For the partner ISP (AT&T Canada, Concert etc...) the community values to be assigned are 200 - 250. This provides the ability to recognize 50 distinct GW(s). Following find an example approach to assignment for gateways. Initially reserve 5 GW(s) between AT&T and each service provider. These values need to be coordinated with customer with an explanation of where the gateway is and what community value is assigned to that gateway. There is no need to coordinate with partners. For each AT&T partner we will assign CV(s) representing the gateways to that partner. Obviously, it would be best for each VPN Service Provider to follow the same scheme although this is not a requirement. Below is an example for the CV(s) for AT&T Canada. GW1 = 200 GW2 = 201 GW3 = 202 GW4 = 203 GW5 = 204 6. Customer Edge Router Configuration Following find examples of how the customer router configuration would be built to select gateways. 6.1 GATEWAY 1 defined as Primary. Flows destined for the route will be sent over primary gateway. Only if primary fails will other gateways be used. The customer will apply to routes of the customer AS. This is only an example. Does not imply singular way of setting up an access-list. Could also set up for ip address prefixes. Do not apply to transit routes. This is up to the customer. The routes being advertised from this router want to have the primary gateway to ROW (Rest of World) location be Gateway 1. Other gateways will be used if GW-1 fails. For transit routes customer does not care. This assumes that the customer is an ISP. router bgp 100 neighbor 171.79.233.1 remote-as 13979 neighbor 171.79.233.1 send-community neighbor 171.79.233.1 route-map set_GW_CV out ! route-map set_GW_CV 10 match as-path 1 set community 200 additive route-map set_GW_CV 20 ! ip as-path access-list 1 permit CUST_ASN$ 6.2 GATEWAY 1 & 2 Defined as Primary. Flows destined for the route will be load balanced across the two gateways. Only if both fail will other gateways be used. router bgp 100 neighbor 171.79.233.1 remote-as 13979 neighbor 171.79.233.1 send-community neighbor 171.79.233.1 route-map set_GW_CV out ! route-map set_GW_CV 10 match as-path 1 set community 200 201 additive ip as-path access-list 1 permit CUST_ASN$ 6.3 No primary gateway defined. router bgp 100 neighbor 171.79.233.1 remote-as 13979 7. VPN Service Provider Edge Router Configuration(s) Following find examples of how the provider router configuration would be built to select gateways. 7.1 Provider Edge Router Configuration The routers that are directly connected to CE(s) require the following configuration. The IBGP links between PER(s) will need to have the send-community both configured for each link. This configuration assumes point-to-point. Route reflection configuration is not detailed. This will send the community value set by the customer to all ibgp peers including all gateways. router bgp 13979 no synchronization no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 10.0.0.33 remote-as 13979 update-source Loopback0 no auto-summary exit-address-family ! address-family vpnv4 neighbor 10.0.0.33 activate send-community extended exit-address-family ! 7.2 VPN Service Provider Gateway Configuraion. Set the MED at GW(s) to reflect Customer configuration On GW routers we will match the community value that has been configured by the customer to the appropriate MED value to achieve the desired effect. We will set the MED metric on routes that do not have the CV value set for the gateway in question. All routes not matching the CV will be assigned a MED of 50. As we are assigning the same MED for all routes not matching there will be no effect on routes that do not care which gateway they use. In other words all routes that do not care about gateway selection will be assigned a MED 50. As they will all have the same MED value there will be no prioritization between them. Set the MED value for routes containing the CV matching this GW. The notion is that routes that are being sent over the GW to the partner will be investigated to see if the community value associated with this GW is set. If it is set MED to 0. Otherwise set the MED to 50 to tell partner that there is possibly a better gateway. router bgp 13979 address-family ipv4 vrf V25:V64 redistribute static redistribute connected neighbor 192.168.200.21 remote-as 64534 neighbor 192.168.200.21 activate neighbor 192.168.200.21 as-override neighbor 192.168.200.21 route-map GW-COMMUNITY out ! ip community-list 1 permit 13979:200 route-map GW-COMMUNITY permit 10 match community 1 set metric 0 route-map GW-COMMUNITY permit 20 set metric 50 8. Authors' Address James Uttaro AT&T E-mail: uttaro@att.com Expiration Date: April 2003