Transcript Customer - to - provider connectivity with BGP

Customer-to-Provider
Connectivity with BGP
© 2001, Cisco Systems, Inc.
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-2
Customer
Connectivity
Requirements
© 2001, Cisco Systems, Inc.
www.cisco.com
Customer-to-Provider Connectivity with BGP-3
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-4
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
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-5
Single Permanent Connection
to the Internet
Customer
Router
Customer Edge
Router
Customer Network
Provider Edge
Router
Service Provider Network
• The simplest setup - a single link between the
customer network and the Internet.
• No redundancy on link or equipment failure.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-6
Permanent Connection with
Dial Backup
Customer
Router
Customer Edge
Router
Dial-out Router
Customer Network
Dialup
network
(ISDN)
Provider Edge
Router
Dial-in Router
Service Provider Network
• 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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-7
Multiple Connections
Load Sharing
Customer
Router
Customer Edge
Router
Customer Network
Provider Edge
Router
Service Provider Network
• 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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-8
Multiple Permanent
Connections
Customer
Router
Customer Edge
Router
Provider Edge
Router
Customer Edge
Router
Provider Edge
Router
Customer Network
Service Provider Network
• 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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-9
Connections to Multiple
Service Providers
Customer
Router
Customer Edge
Router
Provider Edge
Router
Service
Provider A
Customer
Network
Customer Edge
Router
Provider Edge
Router
Service
Provider B
• 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 nondeterministic load control.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-10
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-11
Routing for Customers with
Single Permanent Connection
Customer
Router
Customer Edge
Router
Customer Network
Provider Edge
Router
Service Provider Network
• Static routing is always adequate.
• Do not use BGP in this setup.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-12
Routing for Customers with
Dial Backup
Customer
Router
Customer Edge
Router
Dial-out Router
Customer Network
Dialup
network
(ISDN)
Provider Edge
Router
Dial-in Router
Service Provider Network
• 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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-13
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
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-14
Routing for Customers with
Multiple Connections
Customer
Router
Customer Edge
Router
Customer Network
Provider Edge
Router
Service Provider Network
• Static routing is preferred if you can detect physical link failure.
• Traffic will be black-holed if the physical link failure is not
detected.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-15
Routing for Customers with
Multiple Connections
BGP
Customer
Router
Customer Edge
Router
Provider Edge
Router
BGP
Customer Edge
Router
Customer Network
Provider Edge
Router
Service Provider Network
• 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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-16
Routing for Multi-Homed
Customers
BGP
Customer
Router
Customer Edge
Router
Provider Edge
Router
Service
Provider A
Provider Edge
Router
Service
Provider B
BGP
Customer
Network
Customer Edge
Router
• BGP must be used in this setup; static routing is not possible.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-17
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
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-18
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
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-19
Public and Private Customer
Addresses
Customer
Router
Firewall
Customer
Edge Router
Provider Edge
Router
Network Address
Translation (NAT) is
performed at the firewall
Firewall
Customer
Router
Customer Network
Private addresses
© 2001, Cisco Systems, Inc.
Customer
Edge Router
Customer
DMZ
Provider Edge
Router
Service Provider
Network
Public addresses
Customer-to-Provider Connectivity with BGP-20
AS-Number Allocation for
Single-Homed Customers
BGP
Customer
Router
Customer Edge
Router
Provider Edge
Router
BGP
Customer Edge
Router
AS 65001
Customer Network
Provider Edge
Router
Service Provider Network
• 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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-21
AS-Number Allocation for
Multi-Homed Customers
BGP
Customer
Router
Customer Edge
Routers
Provider Edge
Router
Service
Provider A
Provider Edge
Router
Service
Provider B
BGP
AS 123
Customer Network
• Multi-homed customers have to run BGP with Service Providers.
• They must use public AS numbers for their autonomous system.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-22
Load Sharing
Load sharing of return traffic - controlled
by the Service Providers. Might be
influenced by the customer
Customer
Router
Customer Edge
Router
Provider Edge
Router
Service
Provider A
Provider Router
Customer
Network
Customer Edge
Router
Provider Edge
Router
Service
Provider B
Load sharing of outgoing traffic controlled by the customer
There are two aspects to load sharing: outgoing and return traffic.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-23
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-24
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-25
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-26
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?
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-27
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?
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-28
Static Routing Toward
the Customer
© 2001, Cisco Systems, Inc.
www.cisco.com
Customer-to-Provider Connectivity with BGP-29
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-30
Static Routing Overview
IGP
Customer
Router
BGP
Customer Edge
Router
11.2.3.0/24
Customer Network
Provider Edge
Router
Provider
Router
AS 387
Service Provider Network
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
• Default route is configured on the
customer router.
• Default route is redistributed into
the customer network.
• Route for customer address space
is configured on provider router.
• Customer route is redistributed
into BGP.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-31
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-32
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-33
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-34
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-35
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
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-36
Define Static Route Tags
Example
Customer
Route
Propagation


© 2001, Cisco Systems, Inc.
QoS
Type
Tag
Communities
Normal
1000
Normal
1001
no-export
387:31000
387:31000
Gold
2000
Gold
2001
no-export
387:32000
387:32000
Customer-to-Provider Connectivity with BGP-37
Configuring the Route Map
IGP
Customer
Router
BGP
Customer Edge
Router
11.2.3.0/24
Customer Network
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
!
…
© 2001, Cisco Systems, Inc.
Provider Edge
Router
Provider
Router
AS 387
Service Provider Network
Every combination of services
offered to the customer has to be
matched individually due to routemap limitations.
Do not insert permit all at the end.
Only routes with proper tags are
redistributed into BGP.
Customer-to-Provider Connectivity with BGP-38
Configuring the Redistribution
and Customer Routes
IGP
Customer
Router
BGP
Customer Edge
Router
11.2.3.0/24
Customer Network
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
!
Normal customer, do not
…
Provider Edge
Router
Provider
Router
AS 387
Service Provider Network
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
propagate address block.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-39
Static Route on the Provider
Edge Router
IGP
Customer
Router
BGP
Customer Edge
Router
11.2.3.0/24
Customer Network
Provider Edge
Router
Provider
Router
AS 387
Service Provider Network
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
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-40
BGP Route on the Provider
Edge Router
IGP
Customer
Router
BGP
Customer Edge
Router
11.2.3.0/24
Customer Network
Provider Edge
Router
Provider
Router
AS 387
Service Provider Network
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
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-41
Backup Setup with Static
Routes
IGP
BGP
Customer
Router
Customer Primary
11.2.3.0/24
Customer Backup
Customer Network
Provider Primary
Provider
Router
AS 387
Service Provider Network
Provider 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.
© 2001, Cisco Systems, Inc.
Per-user AAA routes are
used on Provider Backup
router for ISDN dial backup.
Customer-to-Provider Connectivity with BGP-42
Primary/Backup Setup
Customer Configuration
IGP
BGP
Customer
Router
Customer Primary
11.2.3.0/24
Customer Backup
Customer Network
Provider Primary
Provider
Router
AS 387
Service Provider Network
Provider 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
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-43
Primary/Backup Setup
Provider Configuration
IGP
BGP
Customer
Router
Customer Primary
11.2.3.0/24
Customer Backup
Customer Network
Provider Primary
Provider
Router
AS 387
Service Provider Network
Provider 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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-44
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
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-45
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-46
Sample Static Route Tags with
Support for Backup Links
Customer
Route
Propagation
Backup







© 2001, Cisco Systems, Inc.

QoS Type
Tag
Communities
Local
Preference
Normal
1000
no-export
387:31000
100
Normal
1010
no-export
387:31000
50
Normal
1001
387:31000
100
Normal
1011
387:31000
50
Gold
2000
no-export
387:32000
100
Gold
2010
no-export
387:32000
50
Gold
2001
387:32000
100
Gold
2011
387:32000
50
Customer-to-Provider Connectivity with BGP-47
Modified Redistribution RouteMap
• The redistribution route-map needs to be
updated on all Provider Edge routers
route-map IntoBGP permit 10
route-map IntoBGP permit 30
match tag 1000
match tag 1010
set community no-export 387:31000 set community no-export 387:31000
set local-preference 100
set local-preference 50
!
set weight 0
route-map IntoBGP permit 20
!
match tag 1001
route-map IntoBGP permit 40
set community 387:31000
match tag 1011
set community 387:31000
set local-preference 100
set local-preference 50
set weight 0
Only the first half of the route-map is displayed.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-48
BGP Table on Backup Router
Primary Link Active
IGP
BGP
Customer
Router
Customer Primary
11.2.3.0/24
Customer Backup
Customer Network
Provider Primary
Provider
Router
AS 387
Service Provider Network
Provider 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
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-49
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
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-50
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
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-51
Load Sharing with Static Routes
Outgoing Traffic
Customer
Router
Customer Edge
Router
Provider Edge
Router
Customer
Router
Customer Edge
Router
Provider Edge
Router
Customer Network
Provider
Router
Provider
Router
Service Provider Network
• 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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-52
Load Sharing with Static Routes
Return Traffic
Customer
Router
Customer Edge
Router
Provider Edge
Router
Customer
Router
Customer Edge
Router
Provider Edge
Router
Customer Network
Provider
Router
Provider
Router
Service Provider Network
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-53
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-54
Return Traffic Load Sharing
Example
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
Customer Edge
Router
Provider Edge
Router
Customer Edge
Router
Provider Edge
Router
11.2.3.0/24
Customer Network
AS 387
Service Provider Network
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
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-55
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-56
Review Questions
• 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?
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-57
BGP Customer MultiHomed to a Single
Service Provider
© 2001, Cisco Systems, Inc.
www.cisco.com
Customer-to-Provider Connectivity with BGP-58
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-59
Running BGP with the
Customer - Overview
Customer advertises allocated
address space into BGP
BGP is run between the
Customer and the Service
Provider
BGP
Customer
Router
Service
has to
Provider Provider
Edge
Router
deploy
inbound BGP filters
Customer Edge
Router
BGP
Customer Edge
Router
AS 65001
Customer Network
Customer uses
private AS number
© 2001, Cisco Systems, Inc.
Provider Edge
Router
AS 387
Service Provider Network
Provider announces
only the default route
to the customer
Customer-to-Provider Connectivity with BGP-60
Configuring BGP on the
Customer Routers
ip route 11.2.3.0 255.255.255.0 null 0
IBGP
session
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
BGP
11.2.3.0/24
AS 65001
Customer Network
BGP
AS 387
Service Provider Network
• 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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-61
Conditional Advertising of
Customer Address Space
Data packets still arrive at
the failed router where they
are dropped, resulting in
connectivity loss

11.2.3.0/24
AS 65001
Customer Network
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
BGP
BGP
AS 387
Service Provider Network
• 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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-62
Conditional Advertising in a
Firewall
Customer
Router
Firewall
Customer
Edge Router
Provider Edge
Router
Firewall
Customer
Edge Router
Provider Edge
Router
Customer
Router
Customer Network
DMZ
11.2.3.0/24
interface ethernet 0/0
Service
Provider
ip address 11.2.3.2
255.255.255.0
Network
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-63
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-64
Conditional Advertising
Example
BGP
13.5.1.0/24
Customer Core
IBGP
AS 387
13.5.0.0/16
AS 65001
Customer Network
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
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-65
Configuring BGP on the
Service Provider Routers
BGP
11.2.3.0/24
AS 65001
Customer Network
BGP
AS 387
Service Provider Network
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-66
Advertising Default Route in
BGP
router(config-router)#
neighbor ip-address default-information
• 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 routemap).
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-67
Configuring BGP on the
Service Provider Routers
BGP
11.2.3.0/24
AS 65001
Customer Network
router bgp 387
neighbor 10.0.0.1
neighbor 10.0.0.1
neighbor 10.0.0.1
neighbor 10.0.0.1
neighbor 10.0.0.1
neighbor 10.0.0.1
ip
ip
ip
ip
BGP
11.2.0.0/16
AS 387
Service Provider Network
remote-as 65001
default-information
prefix-list CustomerA in
prefix-list DefaultOnly out
filter-list 15 in
route-map AllCustomersIn in
as-path access-list 15 permit ^65001(_65001)*$
prefix-list CustomerA permit 11.2.3.0/24 le 32
prefix-list DefaultOnly permit 0.0.0.0/0
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
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-68
Propagating Customer Routes
to Other Service Providers
EBGP
IBGP
EBGP
EBGP
13.5.0.0/16
AS 65001
AS 387
13.5.0.0/16
AS=65001
AS 217
13.5.0.0/16
AS=65001
13.5.0.0/16
AS=387 65001
• 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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-69
Removing Private AS-numbers
router(config-router)#
neighbor ip-address remove-private-as
• 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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-70
Removing Private ASNumbers - Example
router bgp 387
neighbor 10.2.3.3 remote-as 217
neighbor 10.2.3.3 remove-private-AS
EBGP
IBGP
EBGP
EBGP
13.5.0.0/16
AS 65001
AS 387
13.5.0.0/16
AS=65001
AS 217
13.5.0.0/16
AS=65001
13.5.0.0/16
AS=387
Private AS number is propagated inside AS387
Private AS number is removed before the update is sent into AS387
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-71
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-72
Primary/Backup Link Selection
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
Primary
11.2.3.0/24
AS 65001
Customer Network
Backup
AS 387
Service Provider Network
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
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-73
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-74
Configuring Dial Backup with
BGP
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
Primary
11.2.3.0/24
AS 65001
Customer Network
11.2.1.1 dialer 0 250
ISDN
AS 387
Service Provider Network
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
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-75
Configuring Multi-Hop EBGP
Session
router(config-router)#
neighbor ip-address ebgp-multihop [ TTL ]
• 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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-76
Dial Backup - Establishing BGP
Session Between Backup Routers
Route to Customer Backup router’s loopback
address is advertised in BGP.
EBGP session between
the backup routers is
established across the
primary link.
11.2.3.5
ISDN
11.2.1.1
11.2.3.0/24
AS 65001
Customer Network
Primary
11.2.3.5
11.2.3.5
11.2.1.1
11.2.1.1
AS 387
Service Provider Network
Route to Provider Backup router’s loopback
address is advertised in BGP.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-77
Dial Backup - Primary Link
Failure
no 11.2.1.1
BGP routes are revoked
after primary link failure.
11.2.3.0/24
AS 65001
Customer Network
EBGP session between backup
routers runs over ISDN dial
backup connection.
BGP next-hop is reachable
over ISDN link, data flows
over dial backup connection.
© 2001, Cisco Systems, Inc.
Floating static route is
installed, ISDN call is placed.

Primary
ISDN
AS 387
Service Provider Network
Dynamic host route to
customer’s backup router is
installed when the ISDN call
is accepted.
Customer-to-Provider Connectivity with BGP-78
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-79
Configuring BGP Multipath
Support
router(config-router)#
maximum-paths number
• 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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-80
Load Sharing with EBGP
Multihop
EBGP session is run between loopback
interfaces of adjacent routers
Customer Edge
AS65001
Customer Network
Provider Edge
AS 387
Service Provider Network
• 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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-81
Configuring Load Sharing with
EBGP Multihop
Customer Edge
AS65001
Customer Network
Provider Edge
AS 387
Service Provider Network
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
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 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
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 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
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
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-82
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-83
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?
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-84
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?
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-85
BGP Customer MultiHomed to Multiple
Service Providers
© 2001, Cisco Systems, Inc.
www.cisco.com
Customer-to-Provider Connectivity with BGP-86
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-87
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-88
Running BGP with Multihomed Customer - Overview
Customer advertises allocated
address space into BGP.
BGP is run between the
Customer and the Service
Provider.
BGP
Customer
Router
Service
Provider A
Service Providers have to
deploy inbound BGP filters.
Provider Edge
Router
Customer Edge
Routers
168.22.4.0/18
AS 123
Customer Network
BGP
Provider Edge
Router
Service
Provider B
Providers announce default route,
local networks or full Internet routing
to the customer.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-89
Multi-homed Customers
Considerations
Customer
Router
Customer Edge
Routers
168.22.4.0/18
AS 123
Customer Network
Provider Edge
Router
Service
Provider A
Provider Edge
Router
Service
Provider B
Link usage – primary/backup or
load sharing
Address space – customer’s or ISP assigned
AS number – private or registered
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-90
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-91
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-92
AS Number Translation
AS 123
I am AS 65053
Service
Provider A
AS 65053
AS 234
Customer
Network
I am AS 65286
Service
Provider B
• 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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-93
AS Number Translation
router(config-router)#
neighbor ip-address local-as private-as
• 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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-94
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
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-95
Primary/Backup Link Selection
Outgoing link selection:
• We can use the same solution as with multihomed 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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-96
Incoming Backup Link
Selection
AS 123
Primary
MED=50
No
Med
AS 387
Customer
Network
Backup
Service
Provider A
AS 234
MED=100
Service
Provider B
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-97
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
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-98
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-99
Using BGP Communities
Primary
AS 123
Service
Provider A
AS 387
Customer
Network
Backup
Community 234:50
Inbound updates carrying
this community are assigned
Local Preference 50.
© 2001, Cisco Systems, Inc.
AS 234
Service
Default
Local
Provider
B
Preference 100 is
assigned.
Customer-to-Provider Connectivity with BGP-100
Backup Link Implementation
with BGP Communities
AS 387
Customer Network
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
© 2001, Cisco Systems, Inc.
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
Customer-to-Provider Connectivity with BGP-101
Drawback of BGP
Communities
Primary
AS 123
AS 321 may decide
Service
to use the path
Provider A
through AS 234.
AS 387
AS 321
Customer
Network
Service
Provider X
Backup
AS 234
Community 234:50
Inbound updates carrying
this community are assigned
Local Preference 50.
© 2001, Cisco Systems, Inc.
Service
Provider B
The second update
never arrives to AS 234.
Customer-to-Provider Connectivity with BGP-102
Backup Link Selection with
AS-path Prepending
• Multiple copies of customer’s ASnumber 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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-103
Using AS Path Prepending
Primary
AS 387
AS 387
AS 123
AS 321 will always
Service
decide to use the
Provider A
path through AS 123.
AS 321
Customer
Network
Service
Provider X
Backup
AS 387 387 387 387
AS 387 is prepended three
times.
© 2001, Cisco Systems, Inc.
AS 234
Service
Provider B
Customer-to-Provider Connectivity with BGP-104
Backup Link Implementation
with AS Path Prepending
AS387
Customer Network
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
© 2001, Cisco Systems, Inc.
AS 234
Backup ISP
no special configuration
needed
Customer-to-Provider Connectivity with BGP-105
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-106
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
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-107
Load Sharing
Case Study Solution
Primary
AS 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
Service
Provider A
AS Path forces other
autonomous systems
to use the primary link
For prefix 200.1.1.0/24
AS 321
Service
Provider X
Backup
Prefix 200.1.1.0/24
AS 387 387 387 387
Community 234:150
AS 387 is prepended three
times for prefix 200.1.1.0/24.
Community 234:150 is
translated to LP 150.
© 2001, Cisco Systems, Inc.
AS 123
AS 234
Service
Provider B
Local Preference forces AS
234 to use the direct link.
Customer-to-Provider Connectivity with BGP-108
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-109
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-110
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?
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-111
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.
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-112
© 2001, Cisco Systems, Inc.
Customer-to-Provider Connectivity with BGP-113