© 2005 Cisco Systems, Inc. All rights reserved. BGP v3.2—3-1 Route Selection Using Policy Controls Using Multihomed BGP Networks

© 2005 Cisco Systems, Inc. All rights reserved. BGP v3.2—3-2 Outline Overview Business Requirements for Multihomed BGP Networks Technical Requirements for Multihomed BGP Networks BGP Route Selection Without BGP Policies Multihomed Customer Routing Policies Influencing BGP Route Selection BGP Filters Summary

© 2005 Cisco Systems, Inc. All rights reserved. BGP v3.2—3-3 Some customers need redundant Internet access for their mission-critical applications. Full redundancy is achieved only by connecting to two independent service providers. Business Requirements for Multihomed BGP Networks

© 2005 Cisco Systems, Inc. All rights reserved. BGP v3.2—3-4 Multihomed customers have to run BGP with their ISPs. Multihomed customers usually need a public AS number and provider-independent address space. Technical Requirements for Multihomed BGP Networks

© 2005 Cisco Systems, Inc. All rights reserved. BGP v3.2—3-5 Customer configures two BGP sessions and announces its address space. BGP Route Selection Without BGP Policies

© 2005 Cisco Systems, Inc. All rights reserved. BGP v3.2—3-6 The BGP routes are selected based on AS-path length. The default BGP route selection does not always result in optimum routing. BGP Route Selection Without BGP Policies (Cont.)

© 2005 Cisco Systems, Inc. All rights reserved. BGP v3.2—3-7 Multihomed customers could require a number of routing policies, for example: One provider is primary; the other is backup. Traffic to direct customers of the ISPs goes direct; all other traffic goes through the primary provider. All traffic to a particular part of the world goes through one ISP. Traffic toward a specific destination goes through only one of the ISPs. Multihomed Customer Routing Policies

© 2005 Cisco Systems, Inc. All rights reserved. BGP v3.2—3-8 Influencing BGP Route Selection Internet traffic always flows over primary ISP. Routes received from primary ISP should be preferred over routes received from backup ISP. A route selection tool is needed in BGP weights or local preference.

© 2005 Cisco Systems, Inc. All rights reserved. BGP v3.2—3-9 Influencing BGP Route Selection (Cont.) Internet traffic flows over primary ISP; traffic to customers of backup ISP goes direct. Route selection has to be performed based on AS numbers in the AS path.

© 2005 Cisco Systems, Inc. All rights reserved. BGP v3.2—3-10 BGP Filters―Transit Traffic Issue Customers could become a transit AS for the service providers. Requirement: Do not propagate provider routes to other providers.

© 2005 Cisco Systems, Inc. All rights reserved. BGP v3.2—3-11 Customers running BGP could announce any route to the service providers. Requirement: Service providers have to filter IP prefixes in incoming updates. BGP Filters―Routing Update Reliability Issue

© 2005 Cisco Systems, Inc. All rights reserved. BGP v3.2—3-12 BGP Filters―Return Traffic Issue Customers can influence only their outgoing traffic, not the return traffic. Return traffic can take any path—backup ISP must also perform proper route selection.

© 2005 Cisco Systems, Inc. All rights reserved. BGP v3.2—3-13 Summary Some customers need redundant Internet access for their mission-critical applications and address this need by having two separate connections to one ISP or implementing a multihomed configuration (connecting to two different Internet service providers). The multihomed customer network must exchange BGP information with both ISP networks. Dynamic routing is required for full redundancy, and BGP is the only protocol available that can be used in this scenario. An approach to multihoming that is too simple can be a source of problems. Starting BGP sessions and announcing customer networks to multiple ISPs by using the default behavior of BGP may not result in optimal routing.

© 2005 Cisco Systems, Inc. All rights reserved. BGP v3.2—3-14 Summary (Cont.) Depending on the circumstances, a multihomed customer may require different polices, such as one of the two ISPs being considered the primary connection or reaching destinations in one part of the world more optimally via one of the ISPs. Optimization should be done with the most common destinations in mind, resulting in specific rules on how to reach specific destination networks or the AS. In BGP route selection, a routing policy may be created that gives precedence to reaching destinations within the AS of the primary ISP and all upstream autonomous systems over the primary link and reaching destinations within the AS of the backup ISP over the backup link. When BGP has selected the best path and the information has been propagated to all neighboring autonomous systems, the customer AS may become a transit AS between the two ISPs. The customer must avoid this situation by using BGP filters.

© 2005 Cisco Systems, Inc. All rights reserved. BGP v3.2—3-15