BGP Multihoming: An Enterprise Viewandrei.clubcisco.ro/cursuri/4prc/deploying/BRKRST-2322.pdf · BGP Multihoming: An Enterprise View ... Consider using the Project Cymru or another

© 2006, Cisco Systems, Inc. All rights reserved.Presentation_ID.scr

1

© 2008 Cisco Systems, Inc. All rights reserved. Cisco PublicBRKRST-232214475_04_2008_C1 2

BGP Multihoming: An Enterprise View

BRKRST-2322


2

© 2008 Cisco Systems, Inc. All rights reserved. Cisco Public 3BRKRST-232214475_04_2008_C1

BGP Multihoming Techniques

Multihoming Basics

Single Provider

Multiple Providers

Using Policy

Provider 2Provider 1

192.2.34.0/24

The Internet


Multihoming Basics


3


Multihoming Basics

Definition

Policies Used in this Presentation

Why Multihome?

Assigned Netblock Filters


Multihoming Definition

More than one link external to the local networkTwo or more links to the same ISP

Two or more links to different ISPs

Usually two external facing routersOne router gives link and provider redundancy only


4



Three basic principles for Cisco IOS configuration examples throughout presentation:

prefix-lists to filter prefixes

filter-lists to filter ASNs

route-maps to apply policy



Local preferenceOutbound traffic flows

Metric (MED)Inbound traffic flows (local scope)

AS-PATH prependInbound traffic flows (Internet scope)

CommunitiesSpecific inter-provider peering


5


Why Multihome?

Single exit point, single provider

No need for BGPPoint static default to upstream ISP

Upstream ISP advertises stub network

Policy confined within upstream ISP’s policy

The Internet

192.2.34.0/24


Why Multihome?

Multiple exit points, single provider

Use BGP (not IGP or static) to loadshare

Use private AS (ASN > 64511)

Upstream ISP advertises stub network

Policy confined within upstream ISP’s policy

Provider

A B

C

The Internet


6


Provider 2

Why Multihome?

Many Situations Possible

Multiple sessions to same ISP

Secondary for backup only

Load-share between primary and secondary

Selectively use different ISPs

The Internet

192.2.34.0/24

Provider 1


Why Multihome?

RedundancyOne connection to Internet means the network is dependent on:

Local router (configuration, software, hardware)

WAN media (physical failure, carrier failure)

Upstream service provider (configuration, software, hardware)

ReliabilityBusiness critical applications demand continuous availability

Lack of redundancy implies lack of reliability implies loss of revenue


7


Why Multihome?

Supplier Diversity

Many businesses demand supplier diversity as a matter of course

Internet connection from two or more suppliersWith two or more diverse WAN paths

With two or more exit points

With two or more international connections

Two of everything


Why Multihome?

Note Well

Using multiple providers does not guarantee circuit diversity

There is much backhauling in the world today

There is much cross leasing of facilities

Fate sharing is still an issue

So, be careful out there…

Single Fiber, Multiple Wavelengths

Single CO, Multiple Racks

Provider 2

The Internet

192.2.34.0/24

Provider 1


8


Why Multihome?

Leverage:

Playing one ISP off against the other for:Service quality

Service offerings

Availability

Not really a reason, but oft quoted…


Why Multihome?

Multihoming is easy to demand as requirement for any service provider or end-site network

But what does it really mean:In real life?

For the network?

And how do we do it?

Summary:


9



You must announce assigned address block to Internet

You may also announce subprefixes—reachability is not guaranteed

Current RIR minimum allocation is /21Several ISPs filter RIR blocks on this boundary

Several ISPs filter the rest of address space according to the IANA assignments

This activity is called “net police” by some



The RIRs publish their minimum allocation sizes at:AfriNIC: www.afrinic.net/docs/policies/afpol-v4200407-000.htmAPNIC: www.apnic.net/db/min-alloc.htmlARIN: www.arin.net/reference/ip_blocks.htmlLACNIC: lacnic.net/en/registro/index.htmlRIPE NCC: www.ripe.net/ripe/docs/smallest-alloc-sizes.html

IANA publishes the address space it has assigned to end-sites and allocated to the RIRs:

www.iana.org/assignments/ipv4-address-space

Several ISPs use this published information to filter prefixes on:

What should be routed (from IANA)The minimum allocation size from the RIRs


10



Meant to “punish” ISPs who pollute the routing table with specifics rather than announcing aggregates

Impacts legitimate multihoming especially at the Internet’s edge

Impacts regions where domestic backbone is unavailable or costs $$$ compared with international bandwidth

Hard to maintain—requires updating when RIRs start allocating from new address blocks

Don’t filter based on assigned netblocks unless consequences are well understood and you are prepared to keep the list current

Consider using the Project Cymru or another reputable bogon BGP feed:

http://www.cymru.com/BGP/bogon-rs.html


Single Provider


11


Single Provider

Using Private Autonomous Systems

One Link As Backup

Load Sharing



An ISP with customers multihomed on their backbone (RFC2270)

-or-

A corporate network with several regions but connections to the Internet only in the core

-or-

Within a BGP confederation

65001

192.2.32.0/2465002

192.2.33.0/24

65003

192.2.35.0/24

1880

192.2.34.0/24

192.2.32.0/22{1880}

Applications


12



Private ASNs must be removed from all prefixes announced to the public Internet

Include configuration to remove private ASNs in the eBGP template

As with RFC1918 address space, private ASNs are intended for internal use

They should not be leaked to the public Internet

Cisco IOSneighbor x.x.x.x remove-private-AS


One Link as Backup

Use one link as the primary, the other as a backup

One link is large, the other small

One link is fixed bandwidth, the other is charged per unit of traffic

It’s best to use a private AS in this situation

No need for the upstreams on the Internet to know details about the connection

The provider might aggregate towards the Internet attheir edge Private AS

Provider Aggregation

Secondary Link

Primary Link

A B

C D

The Internet

Provider


13


Accept only defaults on both links

Use local preference to prefer the primary default over the secondary

Use internal IGP metrics to draw traffic to the primary link

Advertise the same address space on both links

Ask the provider to prefer one link over the other using local preference

Using conditional advertisement is another option

One Link as Backup

Same Route

Local PrefPrefers C

Provider Strips Private AS

DefaultOnly

DefaultOnly

B

D

The Internet

Provider

IGP Metric Prefers C

A

C


One Link as Backup

router bgp 65534network 121.10.0.0 mask 255.255.224.0neighbor 122.102.10.2 remote-as XXXneighbor 122.102.10.2 description primary-linkneighbor 122.102.10.2 prefix-list aggregate outneighbor 122.102.10.2 prefix-list default in

!ip prefix-list aggregate permit 121.10.0.0/19ip prefix-list default permit 0.0.0.0/0!ip route 121.10.0.0 255.255.224.0 null0

Primary Link

Secondary Link

Primary Link

B

D

The Internet

Provider


A

C


14


One Link as Backup

router bgp 65534network 121.10.0.0 mask 255.255.224.0neighbor 122.102.10.6 remote-as XXXneighbor 122.102.10.6 description backup-linkneighbor 122.102.10.6 prefix-list aggregate outneighbor 122.102.10.6 route-map backup-out outneighbor 122.102.10.6 prefix-list default inneighbor 122.102.10.6 route-map backup-in in

!ip prefix-list aggregate permit 121.10.0.0/19ip prefix-list default permit 0.0.0.0/0!ip route 121.10.0.0 255.255.224.0 null0!route-map backup-out permit 10match ip address prefix-list aggregateset metric 10

route-map backup-out permit 20!route-map backup-in permit 10set local-preference 90

!

Secondary Link

Primary Link

B

D

The Internet

Provider


A

C


Load Sharing

If you have multiple links between the same pair of routersUse eBGP multihop

eBGP to loopback addresseseBGP prefixes learned with loopback address as next hop

router bgp 65534neighbor 1.1.1.1 remote-as XXXneighbor 1.1.1.1 ebgp-multihop 2

!ip route 1.1.1.1 255.255.255.255 serial 1/0ip route 1.1.1.1 255.255.255.255 serial 1/1

eBGP Multihop

The Internet

Provider


15


Load Sharing

One major problem…

If one link fails the multihopsession can switch to the alternate path

Try and avoid use of eBGP-multihop unless:

It’s absolutely necessary

–or–

Load sharing across multiple links

Many ISPs discourage its use

eBGP Multihop

Original Path

Path When A->C Fails

The Internet

Provider

A B

C


Load Sharing

If you haveMultiple iBGP sessions to the same provider (peering AS)

Terminating in the same router

You can also use iBGP multipath

router bgp 201neighbor 1.1.2.1 remote-as XXXneighbor 1.1.2.5 remote-as XXXneighbor 1.1.2.9 remote-as XXXmaximum-paths 3

iBGP Multihop

The Internet

Provider

A B

C


16


Load Sharing

The most common case, however, is multiple connections at multiple points

You probably don’t normally buy circuits to leave them idle

Even if the circuits have unequal capacity, you want to use both of them

Controlling Traffic Through Announcements

The Internet

Provider

A B

C D


Load Sharing

Outbound Traffic FlowAccept only default routes

Run iBGP between the edge BGP speakers for backup

Allow each eBGP speaker to prefer its local default

Control traffic into the edge using IGP metrics

Default Only


The Internet

Provider

A B

C D

iBGP

IGP Metric to Adjust Inbound Traffic


17


Load Sharing

Inbound Traffic FlowAdvertise the full block out both paths

Split the block, and advertise more specifics out different paths

Adjust where you split the block and advertise to achieve the utilizations you want

Full Block + Specifics

Full Block + Specifics


The Internet

Provider

A B

C D

iBGP


Load Sharing

Assume you have 10.1.0.0/22Router C:

10.1.0.0/22

10.1.0.0/23

Router D:10.1.0.0/22

10.1.2.0/23

Pulls half the destinations in through one link, and the other half in through the other link


10.1.0.0/2210.1.0.0/23

10.1.0.0/2210.1.2.0/23

The Internet

Provider

A B

C D

iBGP


18


Load Sharing

If the A->C link is still taking more traffic....Router C:

10.1.0.0/2210.1.0.0/24

Router D:10.1.0.0/2210.1.1.0/2410.1.2.0/23

Pulls three quarters of the destinations in through one link, and the other quarter in through the other link


10.1.0.0/2210.1.0.0/23

10.1.0.0/2210.1.2.0/2410.1.2.0/23

The Internet

Provider

A B

C D

iBGP


Load Sharing

If the providerIs aggregating the space you’re using outbound

And doesn’t care what prefix lengths you advertise in

Then, you have a lot of flexibility with this technique

Not all providers will support this, though

Make certain to ask before diving too deep into long length prefixes

Aggregate Here


10.1.0.0/2210.1.0.0/23

10.1.0.0/2210.1.2.0/2410.1.2.0/23

The Internet

Provider

A B

C D

iBGP


19


Load Sharing

router bgp 65534network 10.1.0.0 mask 255.255.224.0network 10.1.0.0 mask 255.255.240.0neighbor x.x.x.x remote-as XXXneighbor x.x.x.x prefix-list morespecifics out

!ip prefix-list morespecifics permit 10.1.0.0/22ip prefix-list morespecifics permit 10.1.0.0/23!ip route 10.1.0.0 255.255.240.0 null0ip route 10.1.0.0 255.255.224.0 null0

router bgp 65534network 10.1.0.0 mask 255.255.224.0network 10.1.1.0 mask 255.255.240.0neighbor x.x.x.x remote-as XXXneighbor x.x.x.x prefix-list morespecifics out

!ip prefix-list morespecifics permit 10.1.0.0/22ip prefix-list morespecifics permit 10.1.2.0/23!ip route 10.1.0.0 255.255.240.0 null0ip route 10.1.0.0 255.255.224.0 null0


10.1.0.0/2210.1.0.0/23

10.1.0.0/2210.1.2.0/2410.1.2.0/23

The Internet

Provider

A B

C D

iBGP


Load Sharing

If you are only advertising one prefix

The provider only chooses one path out to your network

The provider only advertises one path to their upstreams

AS path prepend and MED require multiple advertisements

In which case, you can use the techniques already described

Short AS Path

Long AS Path

Only One of Two Will Be Chosen

Only One Advertisement

Why Not AS Path Prepend or MED?

Upstream 1 Upstream 2

B

DC

A

Provider


20


Multiple Providers


Multiple Providers


One Link as Backup

Inbound Load Sharing

Outbound Load Sharing


21



Provider 1 and 2 both strip the private AS

At upstream providers, this looks like the route originated in two different autonomous systems

Some providers might filter for this

As BGP security comes on line, this may be problematic

Talk to your providers before doing this

10.1.1.0/24 {Provider 1}

10.1.1.0/24{Provider 2}

Upstream

Private AS

10.1.1.0/24{65555}

10.1.1.0/24{65555}

B

DC

A

Provider 1 Provider 2


Use AS path prepend to prefer one entrance

This causes the upstream providers to prefer provider 1 over provider 2

Use local preference to not use the link for outbound traffic

One Path as BackupAS Path Prepend

Upstream


Local Pref to Prefer Primary Link

Customer 2

10.1.1.0/20{65555}

10.1.1.0/20{65555}

B

DC

A


22


One Path as Backup

router bgp 65555network 10.1.0.0 mask 255.255.224.0neighbor x.x.x.x remote-as XXXneighbor x.x.x.x prefix-list aggregate outneighbor x.x.x.x prefix-list default in

!ip prefix-list aggregate permit 121.10.0.0/19ip prefix-list default permit 0.0.0.0/0!ip route 10.1.0.0 255.255.224.0 null0

router bgp 65555network 10.1.0.0 mask 255.255.224.0neighbor x.x.x.x remote-as 120neighbor x.x.x.x prefix-list aggregate outneighbor x.x.x.x route-map prepend-out outneighbor x.x.x.x route-map set-pref in

!ip prefix-list aggregate permit 121.10.0.0/19!route-map prepend-out permit 10set as-path prepend 130 130 130

!route-map set-pref permit 10set local-preference 80

AS Path Prepend

10.1.1.0/20{65555, 65555}


10.1.1.0/20{65555}

B

DC

A

Upstream Customer 2


One Path as Backup

This does not direct all the traffic through the one link, however

The AS path length doesn’t impact forwarding decisions within provider 2

Virtually all providers set the local preference to prefer routes learned from customers over routes learned from peers

AS Path Prepend


Local Pref Set to Prefer Routes Learned from

Customers

10.1.1.0/20{65555}

B

DC

A

10.1.1.0/20{65555, 65555}

Upstream Customer 2


23


One Path as Backup

If customer 2 prefers the path through provider 2

They could have a default only to provider 2They could be accepting a partial routing tableEtc. …

Then provider 2 will prefer the B->C link

Rather than taking the path through the Upstream->provider 1->A->CAll the traffic coming from provider 2’s customers will follow the B->C link

AS Path Prepend


Local Pref Set to Prefer Routes Learned from

Customers

10.1.1.0/20{65555}

B

DC

A

10.1.1.0/20{65555, 65555}

Upstream Customer 2


One Path as Backup

Conditional advertisementProvides total control over the use of the backup path

Only advertises routes to one peer when the other peer is down

If the A->C link fails, advertise 10.1.0.0/22 to B from D

Conditional Advertisement


10.1.1.0/20{65555}

B

DC

A

10.1.1.0/20{65555, 65555}

Upstream Customer 2


24


One Path as Backup

router bgp 65555 bgp log-neighbor-changes network 10.1.0.0 mask 255.255.240.0 neighbor <B> remote-as XXXneighbor <B> advertise-map ADVERTISE non-exist-map NON-EXISTneighbor <C> remote-as 65555

! ip route 10.1.0.0 255.255.240.0 null0 ! access-list 60 permit <a->b link address> access-list 65 permit 10.1.0.0! route-map NON-EXIST permit 10 match ip address 65

! route-map ADVERTISE permit 10 match ip address 60

Conditional Advertisement


10.1.1.0/20{65555}

B

DC

A

10.1.1.0/20{65555, 65555}

Make Certain this Link Is Advertised to D in BGP

Upstream Customer 2


10.1.1.0/24


65600

65300 65200

65100

We want to inbound load share between these two connections

Why can’t we just AS path prepend for this?

Traffic from AS65500 will still flow through 65200

Traffic from AS65400 will still flow through AS65300

Only the traffic sourced from AS65600 will be impacted by AS path prepend by itself

This might work, or it might not

6550065400


25



What are our other options?

Longer match prefixes are still your friend…

Advertise 10.1.0.0/22 through one connection

Advertise 10.1.0.0/22 and 10.1.0.0/23 through the other connection

Customer 2


Upstream

A

10.1.0.0/2210.1.0.0/2310.1.0.0/22

DC

B



router bgp 65555network 10.1.0.0 mask 255.255.252.0network 121.10.0.0 mask 255.255.254.0neighbor x.x.x.x remote-as <provider 2>neighbor x.x.x.x prefix-list firstblock out!ip prefix-list firstblock permit 10.1.0.0/22ip prefix-list firstblock permit 10.1.0.0/23

router bgp 65555network 10.1.0.0 mask 255.255.252.0network 10.1.0.0 mask 255.255.254.0neighbor x.x.x.x remote-as <provider 1>neighbor x.x.x.x prefix-list secondblock out

!ip prefix-list secondblock permit 10.1.0.0/22

10.1.0.0/2210.1.0.0/2310.1.0.0/22

Customer 2


Upstream

A

DC

B


26



This is a very basic case

But shows the first steps in designing a load-sharing solution

Start with a simple concept

And build on it… ! 10.1.0.0/2210.1.0.0/2310.1.0.0/22

Customer 2


Upstream

A

DC

B



You can extend this concept by

Adding various longer prefix matches on both links

Combining advertisements of longer prefixes out both links with AS path prepending

For instance, here we are Prepending the /22 to influence traffic towards C

Advertising a longer prefix to influence other traffic towards D

10.1.0.0/2210.1.0.0/2310.1.0.0/22

Customer 2


Upstream

A

DC

B


27



router bgp 65555network 10.1.0.0 mask 255.255.252.0neighbor x.x.x.x remote-as <provider 1>neighbor x.x.x.x prefix-list aggregate out

!ip prefix-list aggregate permit 10.1.0.0/22!ip route 10.1.0.0 255.255.252.0 null0

router bgp 65555network 10.1.0.0 mask 255.255.252.0network 10.1.0.0 mask 255.255.253.0 neighbor x.x.x.x remote-as <provider 2>neighbor x.x.x.x prefix-list subblocks outneighbor x.x.x.x route-map traffic-eng out

!route-map traffic-eng permit 10match ip address prefix-list aggregateset as-path prepend 65555 65555

route-map traffic-eng permit 20!ip prefix-list subblocks permit 10.1.0.0/22 le 23ip prefix-list aggregate permit 10.1.0.0/22

10.1.0.0/2210.1.0.0/2310.1.0.0/22

Customer 2


Upstream

A

DC

B



This example is more commonplace

Shows how ISPs and end-sites subdivide address space frugally, as well as use the AS-PATH prependconcept to optimise the load sharing between different ISPs

Notice that the /22 aggregate block is always announced

10.1.0.0/2210.1.0.0/2310.1.0.0/22

Customer 2


Upstream

A

DC

B


28



Informational RFC

Describes how to implement load sharing and backup on multiple inter-AS links

BGP communities used to determine local preference in upstream’s network

Gives control to the customer

Simplifies upstream’s configurationSimplifies network operation!

RFC1998 Communities



Community values defined to have particular meanings:ASx:100 set local pref 100 preferred route

ASx:90 set local pref 90 backup route if dualhomed on ASx

ASx:80 set local pref 80 main link is to another ISP with same AS path length

ASx:70 set local pref 70 main link is to another ISP

RFC1998 Communities


29



Sample customer router configurationrouter bgp 130

neighbor x.x.x.x remote-as 100

neighbor x.x.x.x description Backup ISP

neighbor x.x.x.x route-map config-community out

neighbor x.x.x.x send-community

!

ip as-path access-list 20 permit ^$

ip as-path access-list 20 deny .*

!

route-map config-community permit 10

match as-path 20

set community 100:90

RFC1998 Communities



Sample ISP router configuration! Homed to another ISP

ip community-list 70 permit 100:70

! Homed to another ISP with equal ASPATH length


! Customer backup routes


!

route-map set-customer-local-pref permit 10

match community 70

set local-preference 70

!

..next slide

RFC1998 Communities


30


Inbound Load SharingRFC1998 Communitiesroute-map set-customer-local-pref permit 20

match community 80


!


match community 90


!





Supporting RFC1998

Many ISPs do, more should

Check AS object in the Internet routing registry

If you do, insert comment in AS object in the IRR

Or make a note on your website

RFC1998 Communities


31



RFC1998 is okay for “simple” multihomed customersAssumes that upstreams are interconnected

ISPs have created many other communities to handle more complex situations

Simplify ISP BGP configuration

Give customer more policy control

RFC1998 Communities


ISP BGP Communities

There are no recommended ISP BGP communities apart from

RFC1998The four standard communities

www.iana.org/assignments/bgp-well-known-communities

Efforts have been made to document from time to timetotem.info.ucl.ac.be/publications/papers-elec-versions/draft-quoitin-bgp-comm-survey-00.pdfBut so far… nothing more…Collection of ISP communities at www.onesc.net/communities

ISP policy is usually publishedOn the ISP’s websiteReferenced in the AS object in the IRR


32


Inbound Load SharingOther Policies: Sprintlink Example

More Info at: www.sprintlink.net/policy/bgp.html


aut-num: AS2764as-name: ASN-CONNECT-NETdescr: AAPT Limitedadmin-c: CNO2-APtech-c: CNO2-APremarks: Community support definitionsremarks: remarks: Community Definitionremarks: ------------------------------------------------remarks: 2764:2 Don't announce outside local POPremarks: 2764:4 Lower local preference by 15remarks: 2764:5 Lower local preference by 5remarks: 2764:6 Announce to customers and all peers

(incl int'l peers), but not transitremarks: 2764:7 Announce to customers onlyremarks: 2764:14 Announce to AANXnotify: [email protected]: CONNECT-AUchanged: [email protected] 20050225source: CCAIR


More at: http://info.connect.com.au/docs/routing/general/multi-faq.shtml#q13

Other Policies: AAPT Example


33


aut-num: AS702descr: Verizon Business EMEA - Commercial IP service provider in Eurremarks: VzBi uses the following communities with its customers:

702:80 Set Local Pref 80 within AS702702:120 Set Local Pref 120 within AS702702:20 Announce only to VzBi AS'es and VzBi customers702:30 Keep within Europe, don't announce to other VzBi AS702:1 Prepend AS702 once at edges of VzBi to Peers702:2 Prepend AS702 twice at edges of VzBi to Peers702:3 Prepend AS702 thrice at edges of VzBi to PeersAdvanced communities for customers702:7020 Do not announce to AS702 peers with a scope of

National but advertise to Global Peers, EuropeanPeers and VzBi customers.

702:7001 Prepend AS702 once at edges of VzBi to AS702peers with a scope of National.

702:7002 Prepend AS702 twice at edges of VzBi to AS702peers with a scope of National.

(more)

Inbound Load SharingOther Policies: Verizon Business Europe Example


(more) 702:7003 Prepend AS702 thrice at edges of VzBi to AS702

peers with a scope of National.702:8020 Do not announce to AS702 peers with a scope of

European but advertise to Global Peers, NationalPeers and VzBi customers.

702:8001 Prepend AS702 once at edges of VzBi to AS702peers with a scope of European.

702:8002 Prepend AS702 twice at edges of VzBi to AS702peers with a scope of European.

702:8003 Prepend AS702 thrice at edges of VzBi to AS702peers with a scope of European.

--------------------------------------------------------------Additional details of the VzBi communities are located at:http://www.verizonbusiness.com/uk/customer/bgp/--------------------------------------------------------------

mnt-by: WCOM-EMEA-RICE-MNTsource: RIPE

Inbound Load SharingOther Policies: Verizon Business Europe Example


34


aut-num: AS5400descr: BT Ignite European Backboneremarks:remarks: Community to Community toremarks: Not announce To peer: AS prepend 5400remarks:remarks: 5400:1000 All peers & Transits 5400:2000remarks:remarks: 5400:1500 All Transits 5400:2500remarks: 5400:1501 Sprint Transit (AS1239) 5400:2501remarks: 5400:1502 SAVVIS Transit (AS3561) 5400:2502remarks: 5400:1503 Level 3 Transit (AS3356) 5400:2503remarks: 5400:1504 AT&T Transit (AS7018) 5400:2504remarks: 5400:1506 GlobalCrossing Trans(AS3549) 5400:2506remarks:remarks: 5400:1001 Nexica (AS24592) 5400:2001remarks: 5400:1002 Fujitsu (AS3324) 5400:2002remarks: 5400:1004 C&W EU (1273) 5400:2004<snip>notify: [email protected]: CIP-MNTsource: RIPE

Inbound Load SharingOther Policies: BT Ignite Example


aut-num: AS3356descr: Level 3 Communications<snip>remarks: -------------------------------------------------------remarks: customer traffic engineering communities - Suppressionremarks: -------------------------------------------------------remarks: 64960:XXX - announce to AS XXX if 65000:0remarks: 65000:0 - announce to customers but not to peersremarks: 65000:XXX - do not announce at peerings to AS XXXremarks: -------------------------------------------------------remarks: customer traffic engineering communities - Prependingremarks: -------------------------------------------------------remarks: 65001:0 - prepend once to all peersremarks: 65001:XXX - prepend once at peerings to AS XXX<snip>remarks: 3356:70 - set local preference to 70remarks: 3356:80 - set local preference to 80remarks: 3356:90 - set local preference to 90remarks: 3356:9999 - blackhole (discard) traffic<snip>mnt-by: LEVEL3-MNTsource: RIPE

Inbound Load SharingOther Policies: Level 3 Example


35



What about my outbound traffic?

First option: Accept only a default route

Use the metrics on the internal IGP default routes to pull traffic to specific exit points

Default OnlyCustomer 2


Upstream

B

DC

A

Use IGP Metrics to Draw Traffic in Evenly



This can lead to suboptimal routing

Traffic destined to customer 2 could be drawn to C, and exit through provider 1

You actually might not care about this…

It does take the load off your network, and push it onto the provider’s network

Default OnlyCustomer 2


Upstream

B

DC

A



36



Second option: accept partial routes

Partial routes include a default route and all the networks the provider is directly connected to

In this case, provider 2 would send a route for customer 2 and a default

Partial Routes

Default + Provider 1’s Customers


Customer 2


Upstream

B

DC

A



You still draw internal traffic to the edge with IGP default routes

But now iBGP between the internal speakers draws traffic to the correct exit

Eliminates 80%+ of all suboptimal routing at the edge

Partial Routes



Customer 2


Upstream

B

DC

A


iBGP


37


What about full routes?

You can gain a lot of control over your exit point

But—you probably won’t ever need this, as a leaf node

Only pull in full routes if you are transiting traffic


Full Routes

Full Routes

Full Routes

Customer 2


Upstream

B

DC

A


iBGP


Summary


38


Summary

Multihoming is not hard, really…Keep it simple and stupid!

Full routing table is rarely requiredA default is often just as good

If customers want 235k prefixes, charge them money for it


Q and A


39


Recommended Reading

Continue your Cisco Live learning experience with further reading from Cisco Press

Check the Recommended Reading flyer for suggested books

Available Onsite at the Cisco Company Store


Complete Your Online Session Evaluation

Give us your feedback and you could win fabulous prizes. Winners announced daily.

Receive 20 Passport points for each session evaluation you complete.

Complete your session evaluation online now (open a browser through our wireless network to access our portal) or visit one of the Internet stations throughout the Convention Center.

Don’t forget to activate your Cisco Live virtual account for access to all session material on-demand and return for our live virtual event in October 2008.

Go to the Collaboration Zone in World of Solutions or visit www.cisco-live.com.



40


Documents

BGP Multihoming: An Enterprise Viewandrei.clubcisco.ro/cursuri/4prc/deploying/BRKRST-2322.pdf · BGP Multihoming: An Enterprise View ... Consider using the Project Cymru or another