BGP Multihoming: An Enterprise View BRKRST , Cisco Systems, Inc. All rights reserved. Presentation_ID.scr

(1)

BGP Multihoming:

An Enterprise View

(2)

3

BRKRST-2322 14475_04_2008_C1

BGP Multihoming Techniques

Multihoming Basics

Single Provider

Multiple Providers

Using Policy

Provider 2

Provider 1

192.2.34.0/24

The Internet

BRKRST-2322

Multihoming Basics

(3)

5

BRKRST-2322 14475_04_2008_C1

Multihoming Basics

Definition

Policies Used in this Presentation

Why Multihome?

Assigned Netblock Filters

Multihoming Definition

Two or more links to the same ISP

Two or more links to different ISPs

Usually

two

external facing routers

(4)

7

BRKRST-2322 14475_04_2008_C1

Policies Used in this Presentation

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

BRKRST-2322

Policies Used in this Presentation

Local preference

Outbound traffic flows

Metric (MED)

Inbound traffic flows (local scope)

AS-PATH prepend

Inbound traffic flows (Internet scope)

Communities

(5)

9

BRKRST-2322 14475_04_2008_C1

Why Multihome?

Single exit point,

single provider

No need for BGP

Point 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)

11

BRKRST-2322 14475_04_2008_C1

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

BRKRST-2322

Why Multihome?

Redundancy

One 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)

Reliability

Business critical applications demand continuous availability

Lack of redundancy implies lack of reliability implies loss

of revenue

(7)

13

BRKRST-2322 14475_04_2008_C1

Why Multihome?

Supplier Diversity

Many businesses demand supplier diversity as a

matter of course

Internet connection from two or more suppliers

With 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)

15

BRKRST-2322 14475_04_2008_C1

Why Multihome?

Leverage:

Playing one ISP off against the other for:

Service quality

Service offerings

Availability

Not really a reason, but oft quoted…

BRKRST-2322

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)

17

BRKRST-2322 14475_04_2008_C1

Assigned Netblock Filters

You

must

announce assigned address block to Internet

You

may

also announce subprefixes—reachability is

not guaranteed

Current RIR minimum allocation is /21

Several 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

Assigned Netblock Filters

The RIRs publish their minimum allocation sizes at:

AfriNIC:

www.afrinic.net/docs/policies/afpol-v4200407-000.htm

APNIC: www.apnic.net/db/min-alloc.html

ARIN:

www.arin.net/reference/ip_blocks.html

LACNIC:

lacnic.net/en/registro/index.html

RIPE 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)

19

BRKRST-2322 14475_04_2008_C1

Assigned Netblock Filters

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

BRKRST-2322

(11)

21

BRKRST-2322 14475_04_2008_C1

Single Provider

Using Private Autonomous Systems

One Link As Backup

Load Sharing

Using Private Autonomous Systems

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/24

65002

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)

23

BRKRST-2322 14475_04_2008_C1

Using Private Autonomous Systems

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 IOS

neighbor x.x.x.x remove-private-AS

BRKRST-2322

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 at

their edge

Private AS

Provider

Aggregation

Secondary

Link

Primary

Link

A

B

C

D

The Internet

Provider

(13)

25

BRKRST-2322 14475_04_2008_C1

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 Pref

Prefers C

Provider Strips

Private AS

Default

Only

Default

Only

B

D

The Internet

Provider

IGP Metric

Prefers C

A

C

One Link as Backup

router bgp 65534

network 121.10.0.0 mask 255.255.224.0

neighbor 122.102.10.2 remote-as XXX

neighbor 122.102.10.2 description primary-link

neighbor 122.102.10.2 prefix-list aggregate out

neighbor 122.102.10.2 prefix-list default in

!

ip prefix-list aggregate permit 121.10.0.0/19

ip 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

IGP Metric

Prefers C

A

C

(14)

27

BRKRST-2322 14475_04_2008_C1

One Link as Backup

router bgp 65534

network 121.10.0.0 mask 255.255.224.0

neighbor 122.102.10.6 remote-as XXX

neighbor 122.102.10.6 description backup-link

neighbor 122.102.10.6 prefix-list aggregate out

neighbor 122.102.10.6 route-map backup-out out

neighbor 122.102.10.6 prefix-list default in

neighbor 122.102.10.6 route-map backup-in in

!

ip prefix-list aggregate permit 121.10.0.0/19

ip 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 10

match ip address prefix-list aggregate

set metric 10

route-map backup-out permit 20

!

route-map backup-in permit 10

set local-preference 90

!

Secondary

Link

Primary

Link

B

D

The Internet

Provider

IGP Metric

Prefers C

A

C

BRKRST-2322

Load Sharing

If you have multiple links

between the same pair of

routers

Use eBGP multihop

eBGP to loopback addresses

eBGP prefixes learned with

loopback address as next hop

router bgp 65534

neighbor 1.1.1.1 remote-as XXX

neighbor 1.1.1.1 ebgp-multihop 2

!

ip route 1.1.1.1 255.255.255.255 serial 1/0

ip route 1.1.1.1 255.255.255.255 serial 1/1

eBGP Multihop

The Internet

Provider

(15)

29

BRKRST-2322 14475_04_2008_C1

Load Sharing

One major problem…

If one link fails the multihop

session 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 have

Multiple iBGP sessions to the

same provider (peering AS)

Terminating in the same router

You can also use

iBGP multipath

router bgp 201

neighbor 1.1.2.1 remote-as XXX

neighbor 1.1.2.5 remote-as XXX

neighbor 1.1.2.9 remote-as XXX

maximum-paths 3

iBGP Multihop

The Internet

Provider

A

B

C

(16)

31

BRKRST-2322 14475_04_2008_C1

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

BRKRST-2322

Load Sharing

Outbound Traffic Flow

Accept 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

Controlling Traffic Through Announcements

The Internet

Provider

A

B

C

D

iBGP

IGP Metric to Adjust

(17)

33

BRKRST-2322 14475_04_2008_C1

Load Sharing

Inbound Traffic Flow

Advertise 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

Controlling Traffic Through Announcements

The Internet

Provider

A

B

C

D

iBGP

Load Sharing

Assume you have 10.1.0.0/22

Router 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

Controlling Traffic Through Announcements

10.1.0.0/22

10.1.0.0/23

10.1.0.0/22

10.1.2.0/23

The Internet

Provider

A

B

C

D

iBGP

(18)

35

BRKRST-2322 14475_04_2008_C1

Load Sharing

If the A->C link is still taking

more traffic....

Router C:

10.1.0.0/22

10.1.0.0/24

Router D:

10.1.0.0/22

10.1.1.0/24

10.1.2.0/23

Pulls three quarters of the

destinations in through one

link, and the other quarter in

through the other link

Controlling Traffic Through Announcements

10.1.0.0/22

10.1.0.0/23

10.1.0.0/22

10.1.2.0/24

10.1.2.0/23

The Internet

Provider

A

B

C

D

iBGP

BRKRST-2322

Load Sharing

If the provider

Is 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

Controlling Traffic Through Announcements

10.1.0.0/22

10.1.0.0/23

10.1.0.0/22

10.1.2.0/24

10.1.2.0/23

The Internet

Provider

A

B

C

D

iBGP

(19)

37

BRKRST-2322 14475_04_2008_C1

Load Sharing

router bgp 65534

network 10.1.0.0 mask 255.255.224.0

network 10.1.0.0 mask 255.255.240.0

neighbor x.x.x.x remote-as XXX

neighbor x.x.x.x prefix-list morespecifics out

!

ip prefix-list morespecifics permit 10.1.0.0/22

ip prefix-list morespecifics permit 10.1.0.0/23

!

ip route 10.1.0.0 255.255.240.0 null0

ip route 10.1.0.0 255.255.224.0 null0

router bgp 65534

network 10.1.0.0 mask 255.255.224.0

network 10.1.1.0 mask 255.255.240.0

neighbor x.x.x.x remote-as XXX

neighbor x.x.x.x prefix-list morespecifics out

!

ip prefix-list morespecifics permit 10.1.0.0/22

ip prefix-list morespecifics permit 10.1.2.0/23

!

ip route 10.1.0.0 255.255.240.0 null0

ip route 10.1.0.0 255.255.224.0 null0

Controlling Traffic Through Announcements

10.1.0.0/22

10.1.0.0/23

10.1.0.0/22

10.1.2.0/24

10.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

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

Why Not AS Path Prepend or MED?

Upstream 1

Upstream 2

B

D

C

A

Provider

(20)

39

BRKRST-2322 14475_04_2008_C1

Multiple Providers

BRKRST-2322

Multiple Providers

Using Private Autonomous Systems

One Link as Backup

Inbound Load Sharing

(21)

41

BRKRST-2322 14475_04_2008_C1

Using Private Autonomous Systems

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

D

C

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 Backup

AS Path Prepend

Upstream

Provider 1

Provider 2

Local Pref to Prefer

Primary Link

Customer 2

10.1.1.0/20

{65555}

10.1.1.0/20

{65555}

B

D

C

A

(22)

43

BRKRST-2322 14475_04_2008_C1

One Path as Backup

router bgp 65555

network 10.1.0.0 mask 255.255.224.0

neighbor x.x.x.x remote-as XXX

neighbor x.x.x.x prefix-list aggregate out

neighbor x.x.x.x prefix-list default in

!

ip prefix-list aggregate permit 121.10.0.0/19

ip prefix-list default permit 0.0.0.0/0

!

ip route 10.1.0.0 255.255.224.0 null0

router bgp 65555

network 10.1.0.0 mask 255.255.224.0

neighbor x.x.x.x remote-as 120

neighbor x.x.x.x prefix-list aggregate out

neighbor x.x.x.x route-map prepend-out out

neighbor x.x.x.x route-map set-pref in

!

ip prefix-list aggregate permit 121.10.0.0/19

!

route-map prepend-out permit 10

set as-path prepend 130 130 130

!

route-map set-pref permit 10

set local-preference 80

AS Path Prepend

10.1.1.0/20

{65555, 65555}

Provider 1

Provider 2

10.1.1.0/20

{65555}

B

D

C

A

Upstream

Customer 2

BRKRST-2322

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

Provider 1

Provider 2

Local Pref Set to

Prefer Routes

Learned from

Customers

10.1.1.0/20

{65555}

B

D

C

A

10.1.1.0/20

{65555, 65555}

Upstream

Customer 2

(23)

45

BRKRST-2322 14475_04_2008_C1

One Path as Backup

If customer 2 prefers the

path through provider 2

They could have a default

only to provider 2

They could be accepting a

partial routing table

Etc. …

Then provider 2 will prefer

the B->C link

Rather than taking the path

through the

Upstream->provider 1->A->C

All the traffic coming from

provider 2’s customers will

follow the B->C link

AS Path Prepend

Provider 1

Provider 2

Local Pref Set to

Prefer Routes

Learned from

Customers

10.1.1.0/20

{65555}

B

D

C

A

10.1.1.0/20

{65555, 65555}

Upstream

Customer 2

One Path as Backup

Conditional advertisement

Provides 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

Provider 1

Provider 2

10.1.1.0/20

{65555}

B

D

C

A

10.1.1.0/20

{65555, 65555}

Upstream

Customer 2

(24)

47

BRKRST-2322 14475_04_2008_C1

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 XXX

neighbor <B> advertise-map

ADVERTISE

non-exist-map

NON-EXIST

neighbor <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

Provider 1

Provider 2

10.1.1.0/20

{65555}

B

D

C

A

10.1.1.0/20

{65555, 65555}

Make Certain this Link Is

Advertised to D in BGP

Upstream

Customer 2

BRKRST-2322

10.1.1.0/24

Inbound Load Sharing

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

65500

65400

(25)

49

BRKRST-2322 14475_04_2008_C1

Inbound Load Sharing

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

Provider 2

Provider 1

Upstream

A

10.1.0.0/22

10.1.0.0/23

10.1.0.0/22

D

C

B

Inbound Load Sharing

router bgp 65555

network 10.1.0.0 mask 255.255.252.0

network 121.10.0.0 mask 255.255.254.0

neighbor 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/22

ip prefix-list

firstblock

permit 10.1.0.0/23

router bgp 65555

network 10.1.0.0 mask 255.255.252.0

network 10.1.0.0 mask 255.255.254.0

neighbor 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/22

10.1.0.0/23

10.1.0.0/22

Customer 2

Provider 2

Provider 1

Upstream

A

D

C

B

(26)

51

BRKRST-2322 14475_04_2008_C1

Inbound Load Sharing

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/22

10.1.0.0/23

10.1.0.0/22

Customer 2

Provider 2

Provider 1

Upstream

A

D

C

B

BRKRST-2322

Inbound Load Sharing

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/22

10.1.0.0/23

10.1.0.0/22

Customer 2

Provider 2

Provider 1

Upstream

A

D

C

B

(27)

53

BRKRST-2322 14475_04_2008_C1

Inbound Load Sharing

router bgp 65555

network 10.1.0.0 mask 255.255.252.0

neighbor 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 65555

network 10.1.0.0 mask 255.255.252.0

network 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

out

neighbor x.x.x.x route-map

traffic-eng

out

!

route-map

traffic-eng

permit 10

match ip address prefix-list

aggregate

set as-path prepend 65555 65555

route-map

traffic-eng

permit 20

!

ip prefix-list subblocks

permit 10.1.0.0/22 le 23

ip prefix-list

aggregate

permit 10.1.0.0/22

10.1.0.0/22

10.1.0.0/23

10.1.0.0/22

Customer 2

Provider 2

Provider 1

Upstream

A

D

C

B

Inbound Load Sharing

This example is more

commonplace

Shows how ISPs and

end-sites subdivide address

space frugally, as well as

use the AS-PATH prepend

concept to optimise the

load sharing between

different ISPs

Notice that the /22

aggregate block is

always

announced

10.1.0.0/22

10.1.0.0/23

10.1.0.0/22

Customer 2

Provider 2

Provider 1

Upstream

A

D

C

B

(28)

55

BRKRST-2322 14475_04_2008_C1

Inbound Load Sharing

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 configuration

Simplifies network operation!

RFC1998 Communities

BRKRST-2322

Inbound Load Sharing

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)

57

BRKRST-2322 14475_04_2008_C1

Inbound Load Sharing

Sample customer router configuration

router 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

Inbound Load Sharing

Sample ISP router configuration

! Homed to another ISP

ip community-list 70 permit 100:70

! Homed to another ISP with equal ASPATH length

ip community-list 80 permit 100:80

! Customer backup routes

ip community-list 90 permit 100:90

!

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

match community 70

set local-preference 70

!

..next slide

(30)

59

BRKRST-2322 14475_04_2008_C1

Inbound Load Sharing

RFC1998 Communities

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

match community 80

set local-preference 80

!

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

match community 90

set local-preference 90

!

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

set local-preference 100

BRKRST-2322

Inbound Load Sharing

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)

61

BRKRST-2322 14475_04_2008_C1

Inbound Load Sharing

RFC1998 is okay for “simple” multihomed customers

Assumes 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

RFC1998

The four standard communities

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

Efforts have been made to document from time to time

totem.info.ucl.ac.be/publications/papers-elec-versions/draft-quoitin-bgp-comm-survey-00.pdf

But so far… nothing more…

/

Collection of ISP communities at

www.onesc.net/communities

ISP policy is usually published

On the ISP’s website

(32)

63

BRKRST-2322 14475_04_2008_C1

Inbound Load Sharing

Other Policies: Sprintlink Example

More Info at:

www.sprintlink.net/policy/bgp.html

BRKRST-2322

aut-num: AS2764

as-name: ASN-CONNECT-NET

descr: AAPT Limited

admin-c: CNO2-AP

tech-c: CNO2-AP

remarks: Community support definitions

remarks:

remarks: Community Definition

remarks:

---remarks: 2764:2 Don't announce outside local POP

remarks: 2764:4 Lower local preference by 15

remarks: 2764:5 Lower local preference by 5

remarks: 2764:6 Announce to customers and all peers

(incl int'l peers), but not transit

remarks: 2764:7 Announce to customers only

remarks: 2764:14 Announce to AANX

notify: [email protected]

mnt-by: CONNECT-AU

changed: [email protected] 20050225

source: CCAIR

Inbound Load Sharing

More at:

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

(33)

65

BRKRST-2322 14475_04_2008_C1

aut-num: AS702

descr: Verizon Business EMEA - Commercial IP service provider in Eur

remarks: VzBi uses the following communities with its customers:

702:80 Set Local Pref 80 within AS702

702:120 Set Local Pref 120 within AS702

702:20 Announce only to VzBi AS'es and VzBi customers

702:30 Keep within Europe, don't announce to other VzBi AS

702:1 Prepend AS702 once at edges of VzBi to Peers

702:2 Prepend AS702 twice at edges of VzBi to Peers

702:3 Prepend AS702 thrice at edges of VzBi to Peers

Advanced communities for customers

702:7020 Do not announce to AS702 peers with a scope of

National but advertise to Global Peers, European

Peers and VzBi customers.

702:7001 Prepend AS702 once at edges of VzBi to AS702

peers with a scope of National.

702:7002 Prepend AS702 twice at edges of VzBi to AS702

peers with a scope of National.

(more)

Inbound Load Sharing

Other 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, National

Peers and VzBi

customers.

702:8001 Prepend AS702 once at edges of VzBi to AS702

peers with a scope of European.

702:8002 Prepend AS702 twice at edges of VzBi to AS702

peers with a scope of European.

702:8003 Prepend AS702 thrice at edges of VzBi to AS702

peers 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-MNT

source: RIPE

Inbound Load Sharing

(34)

67

BRKRST-2322 14475_04_2008_C1

aut-num: AS5400

descr: BT Ignite European Backbone

remarks:

remarks: Community to Community to

remarks: Not announce To peer: AS prepend 5400

remarks:

remarks: 5400:1000 All peers & Transits 5400:2000

remarks:

remarks: 5400:1500 All Transits 5400:2500

remarks: 5400:1501 Sprint Transit (AS1239) 5400:2501

remarks: 5400:1502 SAVVIS Transit (AS3561) 5400:2502

remarks: 5400:1503 Level 3 Transit (AS3356) 5400:2503

remarks: 5400:1504 AT&T Transit (AS7018) 5400:2504

remarks: 5400:1506 GlobalCrossing Trans(AS3549) 5400:2506

remarks:

remarks: 5400:1001 Nexica (AS24592) 5400:2001

remarks: 5400:1002 Fujitsu (AS3324) 5400:2002

remarks: 5400:1004 C&W EU (1273) 5400:2004

<snip>

notify: [email protected]

mnt-by: CIP-MNT

source: RIPE

Inbound Load Sharing

Other Policies: BT Ignite Example

BRKRST-2322

aut-num: AS3356

descr: Level 3 Communications

<snip>

remarks:

---remarks: customer traffic engineering communities - Suppression

remarks:

---remarks: 64960:XXX - announce to AS XXX if 65000:0

remarks: 65000:0 - announce to customers but not to peers

remarks: 65000:XXX - do not announce at peerings to AS XXX

remarks:

---remarks: customer traffic engineering communities - Prepending

remarks:

---remarks: 65001:0 - prepend once to all peers

remarks: 65001:XXX - prepend once at peerings to AS XXX

<snip>

remarks: 3356:70 - set local preference to 70

remarks: 3356:80 - set local preference to 80

remarks: 3356:90 - set local preference to 90

remarks: 3356:9999 - blackhole (discard) traffic

<snip>

mnt-by: LEVEL3-MNT

source: RIPE

Inbound Load Sharing

(35)

69

BRKRST-2322 14475_04_2008_C1

Outbound Load Sharing

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 Only

Customer 2

Provider 2

Provider 1

Upstream

B

D

C

A

Use IGP Metrics to Draw

Traffic in Evenly

Outbound Load Sharing

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 Only

Customer 2

Provider 2

Provider 1

Upstream

B

D

C

A

Use IGP Metrics to Draw

Traffic in Evenly

(36)

71

BRKRST-2322 14475_04_2008_C1

Outbound Load Sharing

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

Default +

Provider 2’s

Customers

Customer 2

Provider 2

Provider 1

Upstream

B

D

C

A

BRKRST-2322

Outbound Load Sharing

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

Default +

Provider 1’s

Customers

Default +

Provider 2’s

Customers

Customer 2

Provider 2

Provider 1

Upstream

B

D

C

A

Use IGP Metrics to Draw

Traffic in Evenly

(37)

73

BRKRST-2322 14475_04_2008_C1

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

Outbound Load Sharing

Full Routes

Customer 2

Provider 2

Provider 1

Upstream

B

D

C

A

Use IGP Metrics to Draw

Traffic in Evenly

iBGP

(38)

75

BRKRST-2322 14475_04_2008_C1

Summary

Multihoming is not hard, really…

Keep it simple and stupid!

Full routing table is rarely required

A default is often just as good

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

BRKRST-2322

(39)

77

BRKRST-2322 14475_04_2008_C1

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

(40)

79

BRKRST-2322 14475_04_2008_C1

BGP Multihoming: An Enterprise View BRKRST , Cisco Systems, Inc. All rights reserved. Presentation_ID.scr

BGP Multihoming:

An Enterprise View

3

BGP Multihoming Techniques



Multihoming Basics



Single Provider



Multiple Providers



Using Policy

Provider 2

Provider 1

192.2.34.0/24

The Internet

Multihoming Basics

5

Multihoming Basics



Definition



Policies Used in this Presentation



Why Multihome?



Assigned Netblock Filters

Multihoming Definition



More than one link external to the local network

Two or more links to the same ISP

Two or more links to different ISPs



Usually

two

external facing routers

7

Policies Used in this Presentation



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

Policies Used in this Presentation



Local preference

Outbound traffic flows



Metric (MED)

Inbound traffic flows (local scope)



AS-PATH prepend

Inbound traffic flows (Internet scope)



Communities

9

Why Multihome?



Single exit point,

single provider



No need for BGP

Point 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

