Download presentation
Presentation is loading. Please wait.
Published byAgnes Jordan Modified over 9 years ago
1
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP
2
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-2 Objectives Upon completion of this chapter, you will be able to perform the following tasks: Describe the connectivity, redundancy, routing and addressing requirements of Service Providers’ customers. Configure static routing with a customer. Configure BGP routing with a customer multi-homed to the same Service Provider. Configure BGP routing with a customer multi-homed to several Service Providers. Design and configure backup solutions, including dial backup. Design and configure load-sharing of a customer’s traffic and return traffic.
3
Customer Connectivity Requirements www.cisco.com © 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-3
4
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-4 Objectives Upon completion of this section, you will be able to perform the following tasks: List customer connectivity requirements. Identify different levels of customer redundancy requirements. Describe the customer-to-provider routing requirements. Describe the difference between provider-independent and provider-assigned IP address space and where they could be used. Describe the customer’s AS-number requirements. Describe the impact of customer using Network Address Translation (NAT). Describe the load-sharing requirements. Describe the difference between inbound and outbound load sharing.
5
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-5 Physical Connectivity and Redundancy Requirements Internet customers have a wide range of connectivity and redundancy requirements: Single permanent connection to the Internet Single permanent connection backed up with a dial-up connection Multiple permanent connections in primary/backup configuration Multiple permanent connections used for load-sharing of traffic Connections to multiple Service Providers for maximum redundancy
6
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-6 Single Permanent Connection to the Internet The simplest setup - a single link between the customer network and the Internet. No redundancy on link or equipment failure. Customer Network Customer Edge Router Customer Router Service Provider Network Provider Edge Router
7
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-7 Permanent Connection with Dial Backup A single permanent link to the Internet is backed up with a dialup connection. Redundancy on link or equipment failure. No redundancy on Service Provider failure. Good solution for lower speeds. Customer Network Customer Edge Router Customer Router Service Provider Network Provider Edge Router Dial-out RouterDial-in Router Dialup network (ISDN)
8
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-8 Multiple Connections Load Sharing Customers that want to increase their access speed can install several physical links between a pair of routers. Redundancy on link failure; no redundancy on equipment failure. Load sharing in this setup is optimal. Customer Network Customer Edge Router Customer Router Service Provider Network Provider Edge Router
9
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-9 Multiple Permanent Connections Customers that want increased redundancy install several physical links to the Internet. Redundant link can be used in primary/backup setup or for load sharing. Redundancy on link or equipment failure; no redundancy on Service Provider failure. Good load sharing is still possible to achieve. Customer Network Customer Edge Router Customer Router Service Provider Network Provider Edge Router Customer Edge Router Provider Edge Router
10
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-10 Connections to Multiple Service Providers Customers with maximum redundancy requirements install physical links to multiple Internet Service Providers. Redundancy on link, equipment or Service Provider failure. Primary/Backup setup is complex without Service Provider assistance. Good load sharing is impossible to achieve; the best solution is non- deterministic load control. Customer Network Customer Edge Router Customer Router Service Provider A Provider Edge Router Customer Edge Router Service Provider B Provider Edge Router
11
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-11 Customer-to-Provider Routing Requirements Static or dynamic routing can be used between an Internet customer and an ISP. BGP is the only acceptable dynamic routing protocol. Static routing is preferred, due to lower complexity.
12
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-12 Routing for Customers with Single Permanent Connection Static routing is always adequate. Do not use BGP in this setup. Customer Network Customer Edge Router Customer Router Service Provider Network Provider Edge Router
13
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-13 Routing for Customers with Dial Backup Static routing is recommended if you can detect physical link failure or remote equipment failure reliably. Otherwise, BGP must be used on the primary link. Static routing is used on the dial-up connection. Customer Network Customer Edge Router Customer Router Service Provider Network Provider Edge Router Dial-out RouterDial-in Router Dialup network (ISDN)
14
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-14 Link or Remote Equipment Failure Detection Link or remote equipment failure can always be detected on: Point-to-point links running HDLC or PPP Dial-up connections DSL and Cable networks Point-to-point LAN links Remote equipment failure might not be detected on: Frame Relay links with no end-to-end signaling ATM links without end-to-end support for OAM cells Remote equipment failure is impossible to detect on: Shared or switched LAN media LAN emulation over ATM Frame Relay DLCI converted to ATM PVC
15
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-15 Routing for Customers with Multiple Connections Static routing is preferred if you can detect physical link failure. Traffic will be black-holed if the physical link failure is not detected. Customer Network Customer Edge Router Customer Router Service Provider Network Provider Edge Router
16
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-16 Routing for Customers with Multiple Connections Static routing can still be used if you can detect link and remote equipment failure reliably. BGP between the customer and the Service Provider is usually used in this setup. Customer Network Customer Edge Router Customer Router Service Provider Network Provider Edge Router Customer Edge Router Provider Edge Router BGP
17
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-17 Routing for Multi-Homed Customers BGP must be used in this setup; static routing is not possible. Customer Network Customer Edge Router Customer Router Service Provider A Provider Edge Router Customer Edge Router Service Provider B Provider Edge Router BGP
18
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-18 Addressing Requirements Single-Homed Customers Customers connected to a single Service Provider usually get the address space from the Service Provider Provider Assigned (PA) address space Most common setup Customer has to renumber on Service Provider change Customer gets only a small address block from the Service Provider Private address are used inside customer network Network Address Translation (NAT) has to be used
19
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-19 Addressing Requirements Multi-Homed Customers Customers connected to multiple Service Providers should get their own address space: Provider Independent (PI) address space No renumbering required on Service Provider change Some Service Providers might not guarantee routing for small block (for example /24) of PI space Multi-homed customers can sometimes use PA address space: Must have a separate public AS number The provider must agree to having another ISP advertise its address space
20
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-20 Public and Private Customer Addresses Customer Network Service Provider Network Provider Edge Router Customer DMZ Customer Edge Router Customer Router Customer Edge Router Provider Edge Router Customer Router Firewall Public addressesPrivate addresses Network Address Translation (NAT) is performed at the firewall
21
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-21 AS-Number Allocation for Single-Homed Customers Customers running BGP with the Service Provider need their own BGP AS-number. Private AS numbers (64512 - 65535) can be used for customers connected to a single Service Provider. AS 65001 Customer Network Customer Edge Router Customer Router Service Provider Network Provider Edge Router Customer Edge Router Provider Edge Router BGP
22
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-22 AS-Number Allocation for Multi-Homed Customers Multi-homed customers have to run BGP with Service Providers. They must use public AS numbers for their autonomous system. AS 123 Customer Network Customer Edge Routers Customer Router Service Provider A Provider Edge Router Service Provider B Provider Edge Router BGP
23
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-23 Load Sharing There are two aspects to load sharing: outgoing and return traffic. Customer Network Customer Edge Router Service Provider A Provider Edge Router Customer Edge Router Service Provider B Provider Edge Router Provider Router Customer Router Load sharing of return traffic - controlled by the Service Providers. Might be influenced by the customer Load sharing of outgoing traffic - controlled by the customer
24
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-24 Load Sharing Requirements Typical Internet customer Return traffic is several times larger than the outgoing traffic. Primary requirement is load sharing of return traffic. Content providers Outgoing traffic is several times larger than the return traffic. Proper load sharing of outgoing traffic is most important. Return traffic load sharing is a concern, due to asymmetrical routing.
25
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-25 Load Sharing Limitations Optimal return traffic load sharing is impossible to achieve for multi-homed customers. Do not establish load sharing over unequal speed links connected to different routers.
26
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-26 Summary After completing this section, you will be able to perform the following tasks: List customer connectivity requirements. Identify different levels of customer redundancy requirements. Describe the customer-to-provider routing requirements. Describe the difference between provider-independent and provider-assigned IP address space and where they could be used. Describe the customer’s AS-number requirements. Describe the impact of customer using Network Address Translation (NAT). Describe the load-sharing requirements. Describe the difference between inbound and outbound load sharing.
27
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-27 Review Questions Describe the most common customer connectivity options. List the failure options that each connection option overcomes. Why does a routing protocol need to detect that a link is down? Which scenarios require BGP and why? Why can’t the other routing protocols be used? Why can’t dial-up lines always be used as backup? Is BGP required when a customer is multi-homed to different ISPs?
28
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-28 More Review Questions What are provider assigned (PA) IP addresses compared to provider independent (PI) addresses? List two benefits of using private addresses within a customer’s network Can the load distribution over two links from the customer to different ISPs be totally controlled? Why is it or why is it not possible to totally control the load?
29
Static Routing Toward the Customer www.cisco.com © 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-29
30
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-30 Objectives Upon completion of this section, you will be able to perform the following tasks: Identify when static routing will meet the customer’s requirements. Configure static customer-to-provider routing on customer and provider routers. Configure redistribution of static routes into BGP. Design and deploy dial backup solutions with static routing. Design and deploy load-sharing solutions with static routing.
31
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-31 Static Routing Overview 11.2.3.0/24 Customer Network Customer Edge Router Customer Router AS 387 Service Provider Network Provider Edge Router Provider Router Default route is configured on the customer router. Route for customer address space is configured on provider router. Default route is redistributed into the customer network. IGP Customer route is redistributed into BGP. BGP ip route 0.0.0.0 0.0.0.0 serial 0 ! router ospf 1 default-information originate ip route 11.2.3.0 255.255.255.0 serial 0 ! router bgp 387 redistribute static [route-map map] no auto-summary
32
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-32 Applicability of Static Routing Static routing is used for: Customers with a single connection to the Internet Customers with multiple connections to the same Service Provider in environments where link and equipment failure can be detected Dynamic routing with BGP must be used in all other cases.
33
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-33 Routing Inside the Customer Network Default route must be announced into the customer network: Redistribute default route into customer’s IGP if the customer is running EIGRP. Use default-information originate if the customer is running OSPF or RIP.
34
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-34 Propagation of Customer Routes in Service Provider Network Customer routes should be carried in BGP, not core IGP. Redistribute static routes into BGP, not IGP. Routes to subnets of Service Provider’s address block should not be propagated to other autonomous systems. Mark redistributed routes with no-export community. Use static route tags for consistent tagging.
35
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-35 Designing Static Route Propagation in a Service Provider Network 1.Identify all possible combination of services offered to a customer, including QoS services. 2.Assign a tag to each combination of services. 3.Configure a route-map that matches defined tags and sets BGP communities or other BGP attributes. 4.Redistribute static routes into BGP through a route-map. 5.For each customer, configure static route toward the customer with the proper tag.
36
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-36 Static Route Propagation Case Study Sample service offering Addressing: PA address block not propagated to upstream ISPs PI or PA address block propagated to upstream ISP Quality of Service: Normal customers Gold customers
37
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-37 Define Static Route Tags Example Customer Route Propagation QoS Type TagCommunities Normal1000no-export 387:31000 Normal1001387:31000 Gold2000no-export 387:32000 Gold2001387:32000
38
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-38 Configuring the Route Map 11.2.3.0/24 Customer Network Customer Edge Router Customer Router AS 387 Service Provider Network Provider Edge Router Provider Router IGPBGP route-map IntoBGP permit 10 match tag 1000 set community no-export 387:31000 ! route-map IntoBGP permit 20 match tag 1001 set community 387:31000 ! … Every combination of services offered to the customer has to be matched individually due to route- map limitations. Do not insert permit all at the end. Only routes with proper tags are redistributed into BGP.
39
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-39 Configuring the Redistribution and Customer Routes 11.2.3.0/24 Customer Network Customer Edge Router Customer Router AS 387 Service Provider Network Provider Edge Router Provider Router IGPBGP route-map IntoBGP permit 10 match tag 1000 set community no-export 387:31000 ! route-map IntoBGP permit 20 match tag 1001 set community 387:31000 ! … router bgp 387 redistribute static route-map IntoBGP neighbor IBGP-neighbor send-community no auto-summary no synchronization ! ip route 11.2.3.0 255.255.255.0 serial1/0.2 tag 1000 Normal customer, do not propagate address block.
40
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-40 Static Route on the Provider Edge Router 11.2.3.0/24 Customer Network Customer Edge Router Customer Router AS 387 Service Provider Network Provider Edge Router Provider Router IGPBGP PE_AS387#show ip route 11.2.3.0 Routing entry for 11.2.3.0/24 Known via "static", distance 1, metric 0 (connected) Tag 1000 Redistributing via bgp 387 Advertised by bgp 387 route-map IntoBGP Routing Descriptor Blocks: * directly connected, via Serial1/0.2 Route metric is 0, traffic share count is 1
41
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-41 BGP Route on the Provider Edge Router 11.2.3.0/24 Customer Network Customer Edge Router Customer Router AS 387 Service Provider Network Provider Edge Router Provider Router IGPBGP AS387#show ip bgp 11.2.3.0 BGP routing table entry for 11.2.3.0/24, version 3 Paths: (1 available, best #1, not advertised to EBGP peer) Local 0.0.0.0 from 0.0.0.0 (1.0.0.2) Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best Community: 387:31000 no-export
42
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-42 Backup Setup with Static Routes 11.2.3.0/24 Customer Network Customer Primary Customer Router AS 387 Service Provider Network Provider Router IGPBGP Provider PrimaryCustomer BackupProvider Backup Floating static routes are configured on the backup routers. Floating static routes are redistributed into customer IGP and provider BGP after the primary link fails. Per-user AAA routes are used on Provider Backup router for ISDN dial backup.
43
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-43 Primary/Backup Setup Customer Configuration 11.2.3.0/24 Customer Network Customer Primary Customer Router AS 387 Service Provider Network Provider Router IGPBGP Provider PrimaryCustomer BackupProvider Backup ip route 0.0.0.0 0.0.0.0 serial 0 ! router ospf 1 default-information originate ip route 0.0.0.0 0.0.0.0 serial 0 250 ! router ospf 1 default-information originate
44
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-44 Primary/Backup Setup Provider Configuration 11.2.3.0/24 Customer Network Customer Primary Customer Router AS 387 Service Provider Network Provider Router IGPBGP Provider PrimaryCustomer BackupProvider Backup ip route 11.2.3.0 255.255.255.0 serial 0/0 tag 1000 250 ! router bgp 387 redistribute static route-map IntoBGP Caveat: local BGP route is always better than an IBGP route. Floating static route is inserted into the BGP table and cannot be removed from there.
45
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-45 BGP Table on Provider Backup Router The BGP table on Provider Backup router contains the floating static route ProviderBackup#sh ip bgp 11.2.3.0 BGP routing table entry for 11.2.3.0/24, version 7 Paths: (2 available, best #1, not advertised to EBGP peer) Advertised to non peer-group peers: 10.3.0.5 Local 0.0.0.0 from 0.0.0.0 (10.3.0.6) Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best Community: 387:31000 no-export Local 10.3.0.2 (metric 128) from 10.3.0.5 (1.0.0.2) Origin incomplete, metric 0, localpref 100, valid, internal Originator: 1.0.0.2, Cluster list: 10.3.0.5 Community: 387:31000 no-export ProviderBackup#sh ip bgp 11.2.3.0 BGP routing table entry for 11.2.3.0/24, version 7 Paths: (2 available, best #1, not advertised to EBGP peer) Advertised to non peer-group peers: 10.3.0.5 Local 0.0.0.0 from 0.0.0.0 (10.3.0.6) Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best Community: 387:31000 no-export Local 10.3.0.2 (metric 128) from 10.3.0.5 (1.0.0.2) Origin incomplete, metric 0, localpref 100, valid, internal Originator: 1.0.0.2, Cluster list: 10.3.0.5 Community: 387:31000 no-export
46
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-46 Floating Static Routes with BGP Floating static routes do not work correctly with BGP. Weight has to be lowered to default value in order for other BGP routes to be considered. BGP local preference has to be changed for floating static routes redistributed into BGP, to make sure other routes take precedence. Administrative distance cannot be matched with a route-map; additional tags need to be defined for static routes.
47
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-47 Sample Static Route Tags with Support for Backup Links Customer Route Propagation BackupQoS TypeTagCommunitiesLocal Preference Normal1000no-export 387:31000 100 Normal1010no-export 387:31000 50 Normal1001387:31000100 Normal1011387:3100050 Gold2000no-export 387:32000 100 Gold2010no-export 387:32000 50 Gold2001387:32000100 Gold2011387:3200050
48
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-48 Modified Redistribution Route- Map The redistribution route-map needs to be updated on all Provider Edge routers route-map IntoBGP permit 30 match tag 1010 set community no-export 387:31000 set local-preference 50 set weight 0 ! route-map IntoBGP permit 40 match tag 1011 set community 387:31000 set local-preference 50 set weight 0 route-map IntoBGP permit 10 match tag 1000 set community no-export 387:31000 set local-preference 100 ! route-map IntoBGP permit 20 match tag 1001 set community 387:31000 set local-preference 100 Only the first half of the route-map is displayed.
49
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-49 BGP Table on Backup Router Primary Link Active 11.2.3.0/24 Customer Network Customer Primary Customer Router AS 387 Service Provider Network Provider Router IGPBGP Provider PrimaryCustomer BackupProvider Backup ProviderBackup#show ip bgp 11.2.3.0 BGP routing table entry for 11.2.3.0/24, version 2 Paths: (1 available, best #1, not advertised to EBGP peer) Local 10.3.0.2 (metric 128) from 10.3.0.5 (1.0.0.2) Origin incomplete, metric 0, localpref 100, internal, best Community: 387:31000 no-export Originator: 1.0.0.2, Cluster list: 10.3.0.5
50
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-50 Primary Link Failure Floating static route is activated after primary link failure ProviderBackup# BGP(0): 10.3.0.5 rcv UPDATE about 11.2.3.0/24 -- withdrawn BGP(0): no valid path for 11.2.3.0/24 BGP(0): nettable_walker 11.2.3.0/24 no best path RT: del 11.2.3.0/24 via 10.3.0.2, bgp metric [200/0] RT: delete subnet route to 11.2.3.0/24 RT: add 11.2.3.0/24 via 0.0.0.0, static metric [250/0] BGP(0): route 11.2.3.0/24 up BGP(0): nettable_walker 11.2.3.0/24 route sourced locally BGP(0): 10.3.0.5 computing updates, afi 0, neighbor version 4, table version 6, starting at 0.0.0.0 BGP(0): 10.3.0.5 send UPDATE (format) 11.2.3.0/24, next 10.3.0.6, metric 0, path BGP(0): 10.3.0.5 1 updates enqueued (average=66, maximum=66) BGP(0): 10.3.0.5 update run completed, afi 0, ran for 12ms, neighbor version 4, start version 6, throttled to 6 ProviderBackup# BGP(0): 10.3.0.5 rcv UPDATE about 11.2.3.0/24 -- withdrawn BGP(0): no valid path for 11.2.3.0/24 BGP(0): nettable_walker 11.2.3.0/24 no best path RT: del 11.2.3.0/24 via 10.3.0.2, bgp metric [200/0] RT: delete subnet route to 11.2.3.0/24 RT: add 11.2.3.0/24 via 0.0.0.0, static metric [250/0] BGP(0): route 11.2.3.0/24 up BGP(0): nettable_walker 11.2.3.0/24 route sourced locally BGP(0): 10.3.0.5 computing updates, afi 0, neighbor version 4, table version 6, starting at 0.0.0.0 BGP(0): 10.3.0.5 send UPDATE (format) 11.2.3.0/24, next 10.3.0.6, metric 0, path BGP(0): 10.3.0.5 1 updates enqueued (average=66, maximum=66) BGP(0): 10.3.0.5 update run completed, afi 0, ran for 12ms, neighbor version 4, start version 6, throttled to 6
51
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-51 Primary Link Reactivation Floating static route is removed when the primary route reappears ProviderBackup# BGP(0): 10.3.0.5 rcvd UPDATE w/ attr: nexthop 10.3.0.2, origin ?, localpref 100, metric 0, originator 1.0.0.2, clusterlist 10.3.0.5, community no-export BGP(0): 10.3.0.5 rcvd 11.2.3.0/24 BGP(0): Revise route installing 11.2.3.0/24 -> 10.3.0.2 to main IP table RT: closer admin distance for 11.2.3.0, flushing 1 routes RT: add 11.2.3.0/24 via 10.3.0.2, bgp metric [200/0] BGP(0): route 11.2.3.0/24 down BGP(0): 10.3.0.5 computing updates, afi 0, neighbor version 6, table version 7, starting at 0.0.0.0 BGP(0): 10.3.0.5 send unreachable 11.2.3.0/24 BGP(0): 10.3.0.5 send UPDATE 11.2.3.0/24 -- unreachable BGP(0): 10.3.0.5 1 updates enqueued (average=27, maximum=27) BGP(0): 10.3.0.5 update run completed, afi 0, ran for 8ms, neighbor version 6, start version 7, throttled to 7 ProviderBackup# BGP(0): 10.3.0.5 rcvd UPDATE w/ attr: nexthop 10.3.0.2, origin ?, localpref 100, metric 0, originator 1.0.0.2, clusterlist 10.3.0.5, community no-export BGP(0): 10.3.0.5 rcvd 11.2.3.0/24 BGP(0): Revise route installing 11.2.3.0/24 -> 10.3.0.2 to main IP table RT: closer admin distance for 11.2.3.0, flushing 1 routes RT: add 11.2.3.0/24 via 10.3.0.2, bgp metric [200/0] BGP(0): route 11.2.3.0/24 down BGP(0): 10.3.0.5 computing updates, afi 0, neighbor version 6, table version 7, starting at 0.0.0.0 BGP(0): 10.3.0.5 send unreachable 11.2.3.0/24 BGP(0): 10.3.0.5 send UPDATE 11.2.3.0/24 -- unreachable BGP(0): 10.3.0.5 1 updates enqueued (average=27, maximum=27) BGP(0): 10.3.0.5 update run completed, afi 0, ran for 8ms, neighbor version 6, start version 7, throttled to 7
52
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-52 Load Sharing with Static Routes Outgoing Traffic Outgoing traffic load sharing is easy to achieve. Each customer router uses the closest customer edge router as the exit point. Balanced load sharing is achieved if the customer edge routers are co-located. Customer Network Customer Edge Router Customer Router Service Provider Network Provider Edge Router Customer Edge Router Provider Edge Router Provider Router Customer Router Provider Router
53
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-53 Load Sharing with Static Routes Return Traffic Customer Network Customer Edge Router Customer Router Service Provider Network Provider Edge Router Customer Edge Router Provider Edge Router Provider Router Customer Router Provider Router Load sharing of return traffic is impossible to achieve with multiple edge routers: All provider routers select the same BGP route to the destination. All return traffic arrives at the same provider edge router.
54
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-54 Optimizing Return Traffic Load Sharing Return traffic load sharing can be optimized with routing tricks. Each provider edge router only advertises part of customer’s address space into the provider backbone. Every provider edge router also advertises the whole customer’s address space for backup purposes. Load sharing is not optimal - every link will carry return traffic for part of customer’s address space.
55
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-55 Return Traffic Load Sharing Example 11.2.3.0/24 Customer Network Customer Edge Router AS 387 Service Provider Network Provider Edge Router Customer Edge Router Provider Edge Router ip route 11.2.3.0 255.255.255.128 serial 0 tag 1000 ip route 11.2.3.0 255.255.255.0 serial 0 tag 1000 ! router bgp 387 redistribute static route-map IntoBGP ip route 11.2.3.128 255.255.255.128 serial 0 tag 1000 ip route 11.2.3.0 255.255.255.0 serial 0 tag 1000 ! router bgp 387 redistribute static route-map IntoBGP
56
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-56 Summary After completing this section, you will be able to perform the following tasks: Identify when the static routing will meet the customer’s requirements. Configure static customer-to-provider routing on customer and provider routers. Configure redistribution of static routes into BGP. Design and deploy dial backup solutions with static routing. Design and deploy load-sharing solutions with static routing.
57
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-57 ReviewQuestions When can static routing between customer and ISP be used? When do you have to migrate from static routing to BGP? How are the static routes configured on provider edge routers propagated to the other ISP routers? How are the subnets of ISPs address space prevented from being advertised to other ISPs? How are different communities on customer routes set without using address filters? How are static routes used to implement backup solutions? When using static routing toward the customer, what are the load sharing options?
58
BGP Customer Multi- Homed to a Single Service Provider www.cisco.com © 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-58
59
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-59 Objectives Upon completion of this section, you will be able to perform the following tasks: Configure BGP between the Service Provider and the customer. Disable propagation of private AS-numbers to external BGP peers. Design and deploy backup solutions for customers running BGP with the Service Provider. Design and deploy load-sharing solutions for customers running BGP with the Service Provider.
60
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-60 Running BGP with the Customer - Overview AS 65001 Customer Network Customer Edge Router Customer Router AS 387 Service Provider Network Provider Edge Router Customer Edge Router Provider Edge Router BGP BGP is run between the Customer and the Service Provider Customer uses private AS number Provider announces only the default route to the customer Customer advertises allocated address space into BGP Service Provider has to deploy inbound BGP filters
61
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-61 Configuring BGP on the Customer Routers Customer address space is advertised on every customer edge router. Customer edge routers run IBGP between themselves and advertise default route to the rest of the customer network. 11.2.3.0/24 AS 65001 Customer Network AS 387 Service Provider Network BGP ip route 11.2.3.0 255.255.255.0 null 0 router bgp 65001 neighbor 11.2.3.1 remote-as 65001 neighbor 10.0.0.2 remote-as 387 network 11.2.3.0 mask 255.255.255.0 router ospf 1 default-information originate IBGP session
62
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-62 Conditional Advertising of Customer Address Space The customer edge router will always advertise the customer’s address space - even when it has no connectivity with the rest of the customer network. 11.2.3.0/24 AS 65001 Customer Network AS 387 Service Provider Network BGP ip route 11.2.3.0 255.255.255.0 null 0 router bgp 65001 network 11.2.3.0 mask 255.255.255.0 Data packets still arrive at the failed router where they are dropped, resulting in connectivity loss
63
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-63 Conditional Advertising in a Firewall Customer Network Service Provider Network Provider Edge Router DMZ 11.2.3.0/24 Customer Edge Router Customer Router Customer Edge Router Provider Edge Router Customer Router Firewall interface ethernet 0/0 ip address 11.2.3.2 255.255.255.0 router bgp 65001 network 11.2.3.0 mask 255.255.255.0 BGP route is revoked if the LAN interface of the edge router fails.
64
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-64 Conditional Advertising in a Larger Customer Network Customer edge routers should announce the whole customer’s address space into BGP. Static route covering the whole customer’s address should point to the core of the customer network, not to null 0. Customer edge router revokes the BGP announcement of customer’s address space if the edge router loses connectivity with the customer’s core.
65
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-65 Conditional Advertising Example 13.5.0.0/16 AS 65001 Customer Network AS 387 BGP ip route 13.5.0.0 255.255.0.0 13.5.1.1 router bgp 65001 neighbor 11.2.3.1 remote-as 65001 neighbor 10.0.0.2 remote-as 387 network 13.5.0.0 mask 255.255.0.0 router ospf 1 default-information originate IBGP 13.5.1.0/24 Customer Core
66
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-66 Configuring BGP on the Service Provider Routers The Service Provider must: Advertise default route to the customer through BGP. Filter incoming BGP updates with a prefix-list to verify that the customer announces only the assigned address space. Filter incoming BGP updates with an AS-path filter-list to verify that the customer uses only its own AS-number. Optionally, no-export community has to be set on customer routes. 11.2.3.0/24 AS 65001 Customer Network AS 387 Service Provider Network BGP
67
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-67 Advertising Default Route in BGP neighbor ip-address default-information router(config-router)# By default, the default route (0.0.0.0/0) is not advertised in outgoing BGP updates. The neighbor default-information command advertises default route to a BGP neighbor even if the default route is not present in the BGP table. Caveat: the default route is not sent through the outbound BGP filters (prefix-list, filter-list or route- map).
68
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-68 Configuring BGP on the Service Provider Routers 11.2.3.0/24 AS 65001 Customer Network 11.2.0.0/16 AS 387 Service Provider Network BGP router bgp 387 neighbor 10.0.0.1 remote-as 65001 neighbor 10.0.0.1 default-information neighbor 10.0.0.1 prefix-list CustomerA in neighbor 10.0.0.1 prefix-list DefaultOnly out neighbor 10.0.0.1 filter-list 15 in neighbor 10.0.0.1 route-map AllCustomersIn in ip as-path access-list 15 permit ^65001(_65001)*$ ip prefix-list CustomerA permit 11.2.3.0/24 le 32 ip prefix-list DefaultOnly permit 0.0.0.0/0 ip prefix-list Provider permit 11.2.0.0/16 le 32 route-map AllCustomersIn permit 10 match ip prefix-list Provider set community no-export additive route-map AllCustomersIn permit 9999
69
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-69 Propagating Customer Routes to Other Service Providers 13.5.0.0/16 AS 65001 AS 387AS 217 EBGP IBGP Private AS numbers should not be advertised into the Internet. The private AS numbers must be removed from the AS-path before the customer BGP routes are advertised to other Service Providers. 13.5.0.0/16 AS=65001 13.5.0.0/16 AS=65001 13.5.0.0/16 AS=387 65001
70
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-70 Removing Private AS-numbers neighbor ip-address remove-private-as router(config-router)# The command modifies AS-path processing on outgoing updates sent to specified neighbor. Private AS-numbers are removed from the tail of the AS-path before the update is sent. Private AS-numbers followed by a public AS-number are not removed. Sender’s AS-number is prepended to the AS-path after this operation.
71
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-71 Removing Private AS- Numbers - Example 13.5.0.0/16 AS 65001 AS 387AS 217 EBGP IBGP 13.5.0.0/16 AS=65001 router bgp 387 neighbor 10.2.3.3 remote-as 217 neighbor 10.2.3.3 remove-private-AS 13.5.0.0/16 AS=65001 Private AS number is propagated inside AS387 13.5.0.0/16 AS=387 Private AS number is removed before the update is sent into AS387
72
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-72 Backup Solutions with BGP The route selection is controlled entirely by the customer routers: Local preference is used to differentiate primary and backup links for the outgoing traffic. Multi-exit-discriminator (MED) is used to differentiate primary and backup links for the return traffic. No Service Provider configuration is required.
73
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-73 Primary/Backup Link Selection 11.2.3.0/24 AS 65001 Customer Network AS 387 Service Provider Network Backup Primary router bgp 65001 bgp default local-preference 50 neighbor 10.0.0.2 remote-as 387 neighbor 10.0.0.2 route-map HiMED out route-map HiMED permit 10 set metric 2000 router bgp 65001 bgp default local-preference 100 neighbor 10.0.0.6 remote-as 387 neighbor 10.0.0.6 route-map LowMED out route-map LowMED permit 10 set metric 1000
74
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-74 Dial Backup with BGP BGP session between the backup routers must be pre-established: Establishing BGP session and exchanging BGP routes after the dial-up connection is established takes too long. EBGP Multi-hop session is configured between backup routers. The EBGP multi-hop session runs over primary link and switches over to the dial-up link when the primary link fails.
75
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-75 Configuring Dial Backup with BGP 11.2.3.0/24 AS 65001 Customer Network AS 387 Service Provider Network Primary ISDN interface loopback 0 ip address 11.2.1.1 255.255.255.255 router bgp 387 network 11.2.1.1 mask 255.255.255.255 neighbor 11.2.3.5 remote-as 65001 neighbor 11.2.3.5 update-source loop 0 neighbor 11.2.3.5 ebgp-multihop interface loopback 0 ip address 11.2.3.5 255.255.255.255 router bgp 65001 neighbor 11.2.1.1 remote-as 387 neighbor 11.2.1.1 update-source loop 0 neighbor 11.2.1.1 ebgp-multihop ip route 11.2.1.1 dialer 0 250
76
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-76 Configuring Multi-Hop EBGP Session neighbor ip-address ebgp-multihop [ TTL ] router(config-router)# By default, EBGP neighbors must be directly connected. The ebgp-multihop command declares an EBGP neighbor to be distant (several hops away). Number of hops can be specified in the TTL parameter. Usually used to run EBGP between loopback interfaces for dial backup or load sharing purposes. Use with extreme caution, routing loops can occur very easily.
77
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-77 Dial Backup - Establishing BGP Session Between Backup Routers 11.2.3.0/24 AS 65001 Customer Network AS 387 Service Provider Network Primary ISDN 11.2.1.1 Route to Provider Backup router’s loopback address is advertised in BGP. 11.2.3.5 Route to Customer Backup router’s loopback address is advertised in BGP. EBGP session between the backup routers is established across the primary link.
78
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-78 Dial Backup - Primary Link Failure 11.2.3.0/24 AS 65001 Customer Network AS 387 Service Provider Network Primary ISDN EBGP session between backup routers runs over ISDN dial backup connection. no 11.2.1.1 BGP routes are revoked after primary link failure. Floating static route is installed, ISDN call is placed. BGP next-hop is reachable over ISDN link, data flows over dial backup connection. Dynamic host route to customer’s backup router is installed when the ISDN call is accepted.
79
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-79 Load Sharing with Customers Running BGP Load sharing of outgoing customer traffic is identical to the static routing scenario. Load sharing of return traffic can be implemented in a number of ways: Announcements of parts of customer’s address space. Configuring BGP multi-path support in the Service Provider network. Using EBGP multihop in environments where parallel links run between a pair of routers.
80
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-80 Configuring BGP Multipath Support maximum-paths number router(config-router)# By default, BGP selects a single path as the best path and installs it in the IP routing table. With the maximum-paths configured, a BGP router can select several identical EBGP routes as the best routes and install them in the IP routing table for load-sharing purposes. Up to six BGP routes can be installed in the IP routing table.
81
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-81 Load Sharing with EBGP Multihop Due to recursive lookup, load sharing toward a BGP destination always occurs if there are several equal-cost IGP paths to the BGP next-hop. Equal-cost IGP paths are easily generated if the BGP next-hop is not directly connected. AS65001 Customer Network Customer Edge AS 387 Service Provider Network Provider Edge EBGP session is run between loopback interfaces of adjacent routers
82
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-82 Configuring Load Sharing with EBGP Multihop AS65001 Customer Network Customer Edge AS 387 Service Provider Network Provider Edge interface loopback 0 ip address 1.0.0.1 255.255.255.255 interface serial 3/2 ip address 2.0.0.1 255.255.255.252 interface serial 3/5 ip address 2.0.0.5 255.255.255.252 router bgp 387 neighbor 3.0.0.1 remote-as 65001 neighbor 3.0.0.1 update-source loop 0 neighbor 3.0.0.1 ebgp-multihop ip route 3.0.0.1 255.255.255.255 2.0.0.2 ip route 3.0.0.1 255.255.255.255 2.0.0.6 interface loopback 0 ip address 3.0.0.1 255.255.255.255 interface serial 0 ip address 2.0.0.2 255.255.255.252 interface serial 1 ip address 2.0.0.6 255.255.255.252 router bgp 65001 neighbor 1.0.0.1 remote-as 387 neighbor 1.0.0.1 update-source loop 0 neighbor 1.0.0.1 ebgp-multihop ip route 1.0.0.1 255.255.255.255 2.0.0.1 ip route 1.0.0.1 255.255.255.255 2.0.0.5
83
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-83 Summary After completing this section, you will be able to perform the following tasks: Configure BGP between the Service Provider and the customer. Disable propagation of private AS-numbers to external BGP peers. Design and deploy backup solutions for customers running BGP with the Service Provider. Design and deploy load-sharing solutions for customers running BGP with the Service Provider.
84
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-84 Review Questions Why can static routing not be used in all cases with redundant links between a customer and a single ISP? Why is BGP the preferred routing protocol when a customer is exchanging routing information with a single ISP? Which AS numbers can customers use? What is a private AS number? Why must private AS numbers not be propagated to the rest of the Internet?
85
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-85 More Review Questions How and where can an ISP remove private AS numbers from the AS path? Which attribute can be used to select the primary/backup link for outgoing traffic? Which attribute can be used to select the primary/backup link for incoming traffic? What three options can be used to enable load sharing on parallel links connected to one router? What options can be used to provide load sharing on parallel links connected to separate routers?
86
BGP Customer Multi- Homed to Multiple Service Providers www.cisco.com © 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-86
87
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-87 Objectives Upon completion of this section, you will be able to perform the following tasks: Use advanced BGP attributes (Local Preference, MED and BGP communities) to support customers multi-homed to multiple Service Providers. Design Service Provider networks to support multi-homed customers without forcing the customers to use AS-path prepending. Design and deploy backup solutions for customers running BGP with the Service Provider. Design and deploy load-sharing solutions for customers running BGP with the Service Provider.
88
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-88 Multi-homed Customers Overview This option is used to provide the highest level of resilience. It is assumed that all equipment is duplicated and set up in a fully redundant way. BGP should take care of rerouting in case of link failure, equipment failure or ISP failure.
89
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-89 Running BGP with Multi- homed Customer - Overview 168.22.4.0/18 AS 123 Customer Network Customer Edge Routers Customer Router Service Provider A Provider Edge Router Service Provider B Provider Edge Router Providers announce default route, local networks or full Internet routing to the customer. Customer advertises allocated address space into BGP. Service Providers have to deploy inbound BGP filters. BGP is run between the Customer and the Service Provider. BGP
90
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-90 Multi-homed Customers Considerations Link usage – primary/backup or load sharing Address space – customer’s or ISP assigned AS number – private or registered
91
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-91 Address Space If the customer owns the address space, there should be no limitations regarding announcing it to both service providers. If the customer uses ISP-assigned small address blocks, then there is no purpose in using BGP to provide redundant connectivity. NAT is easier to implement and solves the problem of reverse path.
92
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-92 AS Number Recommended: Registered AS number – this is the preferred option but it is usually very difficult to get a registered AS number. Discouraged: One private AS number – the customer has to get permission to use the same private AS number with both service providers. Two different private AS numbers – the customer gets a private AS number assigned by each of the service providers and uses one of them internally; the other has to be translated.
93
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-93 AS Number Translation On one EBGP adjacency the real AS number is used. On the other EBGP adjacency the AS number is translated to the one assigned by the second ISP. Customer Network Service Provider A Service Provider B AS 65053 AS 123 AS 234 I am AS 65053 I am AS 65286
94
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-94 AS Number Translation neighbor ip-address local-as private-as router(config-router)# Optionally, the customer can get two different private AS numbers assigned by the service providers. Internally, the customer can ISP-assigned AS number or even any other private AS number. Externally, the customer is seen as one private AS number to ISP1, and as a different AS to ISP2. Caveat: when using this option, the AS-path of the customer’s network contains two AS-numbers. ISP has to adapt the incoming AS-path filters.
95
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-95 Registered vs. Private AS Number Registered AS number: +Does not require ISPs to assign a private AS number +Consistent routing information in the Internet -Very difficult to get, especially for small networks Private AS number: +Easier to get; even easier with AS translation -Causes inconsistent routing information
96
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-96 Primary/Backup Link Selection Outgoing link selection: We can use the same solution as with multi- homed customers connected to one service provider. Incoming link selection: MED cannot be used because it can only be sent to the neighboring AS and no further.
97
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-97 Incoming Backup Link Selection AS 234 decision: MED is not compared even if it is set by AS 387 and AS 123. The decision will probably be based on the AS path length. Customer Network Service Provider A Service Provider B AS 387 AS 123 AS 234 Primary Backup MED=50 MED=100 No Med
98
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-98 Incoming Link Selection BGP Communities: Requires the “backup” ISP to support such Community May not work in all situations AS-path prepending: Depends solely on customer’s configuration Always works
99
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-99 Solution with Communities Customer sets the appropriate BGP community attribute on updates sent to the backup ISP. The ISP translates the BGP community attribute to a Local Preference attribute that is lower than the default value of 100.
100
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-100 Using BGP Communities Customer Network Service Provider A Service Provider B AS 387 AS 123 AS 234 Primary Backup Inbound updates carrying this community are assigned Local Preference 50. Default Local Preference 100 is assigned. Community 234:50
101
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-101 Backup Link Implementation with BGP Communities AS 387 Customer Network AS 234 Backup ISP router bgp 234 neighbor 3.0.0.1 remote-as 387 neighbor 3.0.0.1 route-map MatchComm in ! route-map MatchComm permit 10 match community 1 set local-preference 50 ! route-map MatchComm permit 1000 ! ip community-list 1 permit 234:50 router bgp 387 neighbor 1.0.0.1 remote-as 234 neighbor 1.0.0.1 route-map SetComm out neighbor 1.0.0.1 send-community ! route-map SetComm permit 10 set community 234:50
102
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-102 Drawback of BGP Communities Customer Network Service Provider A Service Provider B AS 387 AS 123 AS 234 Primary Backup Service Provider X AS 321 Inbound updates carrying this community are assigned Local Preference 50. The second update never arrives to AS 234. Community 234:50 AS 321 may decide to use the path through AS 234.
103
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-103 Backup Link Selection with AS-path Prepending Multiple copies of customer’s AS- number are prepended to the AS-path to lengthen the AS-path sent over the backup link. The customer does not depend on service provider’s configuration.
104
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-104 Using AS Path Prepending Customer Network Service Provider A Service Provider B AS 387 AS 123 AS 234 Primary Backup Service Provider X AS 321 AS 387 is prepended three times. AS 387 AS 387 387 387 387 AS 123 387 AS 321 will always decide to use the path through AS 123. AS 321 123 387
105
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-105 Backup Link Implementation with AS Path Prepending AS387 Customer Network AS 234 Backup ISP no special configuration needed router bgp 387 neighbor 1.0.0.1 remote-as 234 neighbor 1.0.0.1 route-map Prepend3x out ! route-map Prepend3x permit 10 set as-path prepend 387 387 387
106
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-106 Load Sharing Load sharing for outgoing traffic: We can use the same solution as with multi-homed customers connected to one service provider. Load sharing for incoming traffic: The only option from the previous section that can be used in this setup is to separate address space into two or more smaller address blocks. Some traffic analysis is needed to fine-tune address space separation according to link bandwidths. AS path prepending should be used to assure symmetric routing as well as backup for noncontiguous address blocks.
107
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-107 Load Sharing Case Study Customer’s address space: 1.0.0.0/8 split into two blocks 1.0.0.0/9 and 1.128.0.0/9 200.1.1.0/24 is not split to prevent it from being filtered somewhere in the Internet Requirements: Load sharing Backup Symmetric routing Neighboring ISPs use “direct link” regardless of other parameters
108
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-108 Load Sharing Case Study Solution Service Provider A Service Provider B AS 387 AS 123 AS 234 Primary Backup Service Provider X AS 321 AS 387 Prefix 200.1.1.0/24 AS 387 387 387 387 Community 234:150 AS 123 387 1.0.0.0/9 1.0.0.0/8 200.1.1.0/24 1.128.0.0/9 1.0.0.0/8 200.1.1.0/24 AS 387 is prepended three times for prefix 200.1.1.0/24. Community 234:150 is translated to LP 150. Local Preference forces AS 234 to use the direct link. AS 321 123 387 AS Path forces other autonomous systems to use the primary link For prefix 200.1.1.0/24
109
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-109 Comments on Case Study Solution ISPs should offer a service that translates a Community to Local Preference higher than 100 (implementing “direct link”). ISPs should send at least their own prefixes to the customer (implementing symmetric routing with “direct link”). AS path prepending has to be used with prefixes that can not be split into smaller prefixes. Communities have to be used with all prefixes to achieve the “direct link” option.
110
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-110 Summary After completing this section, you will be able to perform the following tasks: Use advanced BGP attributes (Local Preference, MED and BGP communities) to support customers multi-homed to multiple Service Providers. Design Service Provider networks to support multi-homed customers without forcing the customers to use AS-path prepending. Design and deploy backup solutions for customers running BGP with the Service Provider. Design and deploy load-sharing solutions for customers running BGP with the Service Provider.
111
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-111 Review Questions Do multi-homed customers require a registered AS number? Must multi-homed customers have their own address space? How is the primary/backup design different from the one used for multi-homed customers connected to one ISP? How is the load sharing design different from the one used for multihomed customers connected to one ISP?
112
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-112 Summary After completing this chapter, you will be able to perform the following tasks: Describe the connectivity, redundancy, routing and addressing requirements of Service Providers’ customers. Configure static routing with a customer. Configure BGP routing with a customer multi-homed to the same Service Provider. Configure BGP routing with a customer multi-homed to several Service Providers. Design and configure backup solutions, including dial backup. Design and configure load-sharing of customer’s traffic and return traffic.
113
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-113
114
© 2001, Cisco Systems, Inc. Customer-to-Provider Connectivity with BGP-114 Blank for Pagination
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.