Deploying BGP4 (RST-243)

8/14/2019 Deploying BGP4 (RST-243)

1/134

111 2002, Cisco Systems, Inc. All rights reserved.

Session Number

Presentation_ID


2/134


3/134

3RST-243 2002, Cisco Systems, Inc. All rights reserved.

Deploying BGP-4RST-243

Torsten Neuber

[email protected]


4/134444 2002, Cisco Systems, Inc. All rights reserved.RST-243

Prerequisites

Understand how BGP scales Internet

routing by connecting ISPs with globallyunique AS numbers

Understand need for stable BGP

advertisement (ie BGP dampening)

Understand difference between BGP

external and internal BGP Basic protocol knowledge: TCP port

179incremental updates



Prerequisites

Understand BGP attributes: ASPATH,

NEXT_HOP, MED, LOCAL_PREFallowrouting policy via route-map.

Understand the bestpath decision

algorithm

Know why to turn off synchronization

and auto-summary!



Overview

Protocol Overview

Using BGP Attributes

Deploying IBGP

Deploying EBGP

Connecting to an ISP

Being an ISP

Focus on Stability, Scalability, andConfiguration Templates



Complex Network Scalability

Scalable

Stable

Simple


8/1348RST-243 2002, Cisco Systems, Inc. All rights reserved.

Recap of BGP

What Is it? Why Use it?



Basic to Basics

Peering

AS 100

BB

AA

AS 102

EE

AS 101

DD

CC

Runs over TCPport 179

Path vector protocol

Incremental updates

Internal and External BGP



General Operation

Learns multiple paths via internaland external BGP speakers

Picks THE bestpath, installs it in

the IP forwarding table, forwards to EBGPneighbors (not IBGP)

Policies applied by influencing thebestpath selection



BGP SessionsTCP Port 179,4 Basic Message Types

1: OPEN MESSAGEExchange AS, router ID, holdtime

Capability negotiation

2: NOTIFICATION

Example: peer in wrong AS

3: KEEPALIVEwhen no updates 4: UPDATES (incremental)


12/134

121212 2002, Cisco Systems, Inc. All rights reserved.RST-243

BGP AttributesTools for Routing Policy

1: ORIGIN

2: AS-PATH

3: NEXT-HOP

4: MED

5: LOCAL_PREF

6: ATOMIC_AGGREGATE

7: AGGREGATOR

8: COMMUNITY

9: ORIGINATOR_ID

10: CLUSTER_LIST

14: MP_REACH_NLRI

15: MP_UNREACH_NLRI


13/134


Why Use It?

You need to scale your IGP

Youre a multihomed ISP customer

You need to transit full Internet routes


14/134


Deploying BGP

Turn of the Archaic Features!


15/134


16/134


Deploying Internal BGP

Loopbacks, Peer-Groups, Route Reflectors and Confederations


17/134


Guidelines for Stable IBGP

IBGP peer using loopback addresses

neighbor { ip address | peer-group}update-source loopback0

Independent of physicalinterface failure

IGP performs any load-sharing IBGP onlyuse on RR clients with care!!!


18/134


Peering with Loopbacks

Without Loopbacks, the TCP

Session Is Always

Sourced from the IP Addressof the Outbound Interface

Which Can Go Down!

Configuration:

Router A

router bgp 1neighbor 1.0.1.1 remote-as 1

Router B

router bgp 1

neighbor 1.0.1.2 remote-as 1

A B

1.0.1.1 1.0.1.2

If Redundant Paths Exist,

Use Loopback Interfaces

to Establish the Session


19/134


Guidelines for Scaling IBGP

Carry only next-hops in IGP

Carry full routes in BGP only

if necessary Do not redistribute BGP into IGP

Use peer groups and RRs


20/134


BGP TemplateIBGP Peers

IBGP Peer Group AS1

router bgp 1

neighbor internal peer-group

neighbor internal description ibgp peers

neighbor internal remote-as 1neighbor internal update-source Loopback0

neighbor internal next-hop-self

neighbor internal send-communityneighbor internal version 4

neighbor internal password 7 03085A09

neighbor 1.0.0.1 peer-group internalneighbor 1.0.0.2 peer-group internal


21/134


What Is a Peer Group?

Simplifies configuration All peer-group members have

a common outbound policy

Updates generated once per peer group

Members can have differentinbound policy


22/134


Why Route Reflectors?

Avoid n(n-1)/2 iBGP Mesh

n=1000 => NearlyHalf a MillioniBGP Sessions!

13 Routers =>78 IBGP

Sessions!


23/134


Using Route Reflectors

Golden Rule

of RR Loop Avoidance:

RR Topology Should FollowPhysical Topology

=> Be Careful with Loopback Peering!!!!

RRC

Cluster A

RR

RR

RRC

Cluster B

RR

BackboneRR

RRC

Cluster CRR

RRC

Cluster DRR


24/134


Route Reflectors

Provide additional control to allowrouter to advertise (reflect) iBGPlearned routes to other iBGP peers

Method to reduce the size of the iBGP mesh Normal BGP speakers can coexist

Only the RR has to support this featureneighbor x.x.x.x route-reflector-client


25/134


Route ReflectorsTerminology

Clients

Clusters

Non-client Route Reflector

Clients

Lines Represent Both Physical Links and BGP Logical Connections


26/134


Route ReflectorsTerminology (Cont.)

Route reflector

Router that reflects the iBGP information

Client

Routers between which the RR reflects

updates (may be fully meshed amongthemselves)

Cluster

Set of one or more RRs and their clients(may overlap)

Non-client

iBGP neighbour outside the cluster


27/134


What Is a Route Reflector?

Reflector receives path from clients andnon clients

If best path is from a client, reflect toclients and non-clients

If best path is from a non-client, reflectto clients


28/134


Route ReflectorsHierarchy

Clusters may be

configuredhierarchically

RRs in a cluster are clients

of RRs in a higher level

Provides anaturalmethod to limit routinginformation sent to lowerlevels

Level 2

Level 1


29/134


Deploying Route Reflectors

Divide backbone into multiple clusters

Each cluster contains at least oneRR; Clients can peer with RRs in otherclusters for redundancy

RRs are fully meshed via IBGP

Still use single IGPnext-hop unmodifiedby RR; unless via explicit inboundroute-map


30/134


Route ReflectorsMigration

Where to place the route reflectors?

Follow the physical topology!

This will guarantee that the packet forwarding wont beaffected

Configure one RR at a time

Eliminate redundant iBGP sessions

Place one RR per cluster


31/134



Step 0:full iBGP mesh

A

E

D

B C

Logical Links

Physical AND Logical Links


32/134



A

E

D

B C

RR

Step 1:configure D

as a RR; Eis the client

Logical Links



33/134



RR

Step 2:eliminate

unnecessaryiBGP links

A

E

D

B C

Logical Links



34/134



RR

RR RR

Step 3:repeat for other

clustersand iBGPlinks

A

E

D

B C

Logical Links



35/134


BGP Template: Peer-Group for RR Clients

This Line on RRs

Only RRCs Use

Still Use Internal

Peer Group

Will this Break the

Golden Rule?

router bgp 1

neighbor rr-client peer-group

neighbor rr-client description RR clientsneighbor rr-client remote-as 1

neighbor rr-client update-source Loopback0

neighbor rr-client route-reflector-clientneighbor rr-client next-hop-self

neighbor rr-client send-community

neighbor rr-client version 4neighbor rr-client password 7 03085A09

neighbor 10.0.1.1 peer-group rr-client

neighbor 10.0.1.2 peer-group rr-client


36/134


RR Specific BGP Attributes

Example:

RouterB>sh ip bgp 3.0.0.0BGP routing table entry for 3.0.0.0/8

3

1.0.1.2 from 1.4.1.1 (1.1.1.1)

Origin IGP, metric 0, localpref 100, valid, internal, best

C

RR

D

A RRC Router id1.2.1.1

Router id

1.3.1.1

1.4.1.1

1.0.1.2

Router id1.1.1.1

3.0.0.0

AS3

B

RRC

RR

Originator: 1.1.1.1

Cluster list: 1.3.1.1, 1.2.1.1


37/134


BGP Attributes: ORIGINATOR_ID

ORIGINATOR_ID

Router ID of IBGP speaker that injectsroute into ASapplied by RR

Useful for troubleshooting andloop detection


38/134


BGP Attributes: CLUSTER_LIST

CLUSTER_LIST

String of CLUSTER_IDs through which theroute has passed

Usually CLUSTER_ID=ROUTER_ID

Overridden by: bgp cluster-id x.x.x.xbutremember: dont do this!!!!

Useful for troubleshooting andloop detection


39/134


Route ReflectorsRedundancy

Multiple RRs can be configured in the

same clusterbut we now adviseagainst this

Other RRs in the same cluster should

be treated as iBGP peers (non-clients)All RRs in the clustermust have the samecluster-id

A router may be a client for RRsin different clusters


40/134


Multiple Route Reflectors

1.0.1.1

1.0.0.1

RR2 RR1

cluster-id 3.0.0.1

eBGP

2.0.0.2

10.0.0.0/24

B

routerB>sh ip bgp 10.0.0.0BGP routing table entry for 198.10.10.0/24

3

2.0.0.2 from 1.0.0.1 (1.0.1.1)

Origin IGP, metric 0, localpref 100, valid, internal, best

Originator: 1.0.1.1Cluster list: 3.0.0.1

If A and C have the sameCLUSTER_ID, C will not reflect

routes from A to B ( ignored due to

3.0.0.1 in the CLUSTER_LIST)

Lines Represent Both Physical

Links and BGP Logical Connections

If the direct links C-D and B-A fail,D cannot reach 10.0.0.0

R t R fl t R lt


41/134


Route ReflectorsResults

Number of neighbors is reduced

No need for full iBGP mesh

Number of routes propagated is reduced

Each RR advertises only the best pathto its clients

Stability and scalability are achieved!

C f d ti


42/134


Confederations

Divide the AS into sub-AS

eBGP between sub-AS, but some iBGPinformation is kept

Preserve NEXT_HOP across thesub-AS (IGP carries this information)

Preserve LOCAL_PREF and MED

Usually a single IGP

C f d ti (C t )


43/134


Confederations (Cont.)

Visible to outside world as single AS

Confederation IndentifierEach sub-AS uses a number from theprivate space

iBGP speakers in sub-AS arefully meshed

The total number of neighbors is reduced bylimiting the full mesh requirement to only thepeers in the sub-AS

C f d ti (C t )


44/134



Configuration (rtr B):router bgp 65532confederation identifier 2bgp confederation peers 65530 65531neighbor 141.153.12.1 remote-as 65530


Sub-AS65530

AS 2

Sub-AS65532

B

Sub-AS

65531

Ro te Propagation Decisions


45/134


Route Propagation Decisions

Same as with normal BGP:

From peer in same sub-AS only toexternal peers

From external peers to all neighbors

External peers refers to

Peers outside the confederation

Peers in a different sub-AS

Preserve LOCAL_PREF, MED and NEXT_HOP

Confederations (Cont )


46/134



Example (cont.):

BGP table version is 78, local router ID is 141.153.17.1

Status codes: s suppressed, d damped, h history,* valid, > best, i - internal

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

*> 10.0.0.0 141.153.14.3 0 100 0 (65531) 1 i

*> 141.153.0.0 141.153.30.2 0 100 0 (65530) i

*> 144.10.0.0 141.153.12.1 0 100 0 (65530) i

*> 199.10.10.0 141.153.29.2 0 100 0 (65530) 1 i

RRs or Confederations


47/134


RRs or Confederations

Internet

Connectivity

Multi-Level

Hierarchy

Policy

ControlScalability

Anywhere

In theNetwork

Migration

Complexity

Yes Yes Medium

Medium

To High

Anywhere

In the

Network

Yes Yes Very High Very Low

Confederations

Route

Reflectors

More Points about Confeds


48/134


More Points about Confeds

Can ease absorbing other ISPs into you

ISPeg, if one ISP buys another (can uselocal-as feature to do a similar thing)

You can use route-reflectors withinconfederation sub-as to reduce the sub-asibgp mesh

So Far


49/134


So Far

Is IBGP peering Stable?

Use loopbacks for peering

Will it Scale?

Use peer groups

Use route reflectors

Simple, hierarchical config?


50/134


COMMUNITIES

Theyre for Everyone!

Problem: Scale Routing PolicySolution: COMMUNITY


51/134


Solution: COMMUNITY

NOT in decision algorithm

BGP route can be a member of manycommunities

Typical communities:Destinations learned from customers

Destinations learned from ISPs or peersDestinations in VPNBGP community isfundamental to the operation of BGP VPNs



52/134


Solution: COMMUNITY

ISP 1

Customer 1

(no Default,

Wants Full Routes)

ISP 2

Communities:

1:100Customer Routes

1:80 ISP Routes

ISP 4ISP 3

Customer 2

(Uses Default,

Wants Your Routes)

0.0.0.0



53/134


Solution: COMMUNITY

ISP 1

Customer 1

(no Default,

Wants Full Routes)

ISP 2

Communities:

1:100Customer Routes

1:80 ISP Routes

ISP 4ISP 3

Customer 2

(Uses Default,

Wants Your Routes)

0.0.0.0

Match Community1:100

Match Community

1:100 1:80 Match Community1:100

Set Community1:80

Set Community

1:100

BGP Attributes: COMMUNITY


54/134


BGP Attributes: COMMUNITY

Activated per neighbor/peer-group:neighbor {peer-address | peer-group-name}send-community

Carried across AS boundaries

Common convention is stringof four bytes: :[0-65536]

BGP Attributes: COMMUNITY (Cont.)


55/134


BGP Attributes: COMMUNITY (Cont.)

Each destination can be a member ofmultiple communities

Using a route-map: set community community number

aa:nn community number in aa:nn format

additive Add to the existing community

none No community attribute

local-AS Do not send to EBGP peers (well-knowncommunity)

no-advertise Do not advertise to any peer (well-knowncommunity)

no-export Do not export outside AS/confed (well-knowncommunity)

Community Filters


56/134


Community Filters

Filter based on Community Strings

ip community-list [permit|deny] comm

ip community-list [permit|deny]regexp

Per neighborInbound or outbound route-maps

match community [exact-match]exact match only for standard lists

Community Filters


57/134


Community Filters

Example 1:Mark some prefixes as part of the 1:120 community(+remove existing community!)

Configuration:router bgp 1


neighbor 10.0.0.1 send-community

neighbor 10.0.0.1 route-map set_community out

!

route-map set_community 10 permitmatch ip address 1

set community 1:120

!access-list 1 permit 10.10.0.0 0.0.255.255

Community Filters


58/134


y

Example 2:Set LOCAL_PREF depending on the community thatthe prefix belongs to.

Configuration:router bgp 1


neighbor 10.0.0.1 route-map filter_on_community in

!

route-map filter_on_community 10 permit

match community 1set local-preference 150

!

ip community-list 1 permit 2:150

Regular Expression SyntaxURL


59/134


g p y

Overview of IOS regular expressionsyntax:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios11/arbook/arapptrn.htm


60/134


Deploying External BGPfor Enterprises

Aggregation, Policy, and Loadsharing

Tasks


61/134


Steps

Configure neighbor

Advertise stable prefixes to your ISP

Set inbound policy

Set output policy

Configure loadsharing/multi-homing

BGP Template: BGP to an ISP


62/134


AS 2

AS1

10.0.0.0

A

B10.60.0.0/16

.1

.2

AS 1 Is a Customer

of ISP AS 2

Router B:

router bgp 1

network 10.60.0.0 mask 255.255.0.0neighbor external peer-group

neighbor external remote-as 2

neighbor external description ISP connection

neighbor external remove-private-ASneighbor external version 4

neighbor external prefix-list ispout out ; accident filter

neighbor external route-map ispout out ; real filter

neighbor external route-map ispin inneighbor external password 7 020A0559

neighbor external maximum-prefix 65000 [warning-only]

neighbor 10.200.0.1 peer-group external

ip route 10.60.0.0 255.255.0.0 null0 254

10.200.0.0

Neighbor Template: Notes


63/134


The slide shows a complete EBGP configuration. Notice that it has quite a fewmore features enabled than the simple configuration I gave at the start of thesession. These features are not all mandatorythey are suggestions, and youshould read the justifications that follow to see if they make sense in your network.

I begin my generating a stable aggregate (or supernet) route that covers all of thesubnets in my network. There is no need for the Internet to know about morespecific routes in my network, and I do not want to flap routes as theseindividual subnets may come and go within my network.

First, even though there is only one neighbor, I define a peer group. This does no

harm, and may remind me to re-use the peer-group if I have a another session tothe same ISP (with the same outbound policy), thereby obtaining the updategeneration efficiency that comes with this feature.

Next, I define the remote-as 2, and the provide a text description. I also instruct theneighbor to remove any private AS numbers (64512-65535). Although not strictly

necessary if you are not using private AS, this is a nice safeguard should you everdecide to use private AS numbers in your network, and forget to update youroutbound policy accordingly.

I lock down the BGP version to version 4, to guard against the hopefully rare, butpossible, outcome the ISP configures their sessions with version 3 (call me

paranoid :-) ).

Neighbor Template: BGP to an ISP


64/134


Now I apply the routing policy. Because Im paranoid, I double-up on the outboundpolicy. I apply a route-map containing a community list as my primary filter;however I back this up with a prefix list. This is only really feasible if you are anenterprise and the number of entries in the prefix-list is small. For an ISP, you will

probably just use a community list, and extreme care!!!

I apply an inbound policy, which essentially prevents me against mistakes my ISPmake make, such as sending me my own routes, sending me private IP addressspace (eg network 10.0.0.0 etc).

Speaking of mistakes: what if the ISP messes up their outbound policy and sendsme more routes than the memory in my router can take? If this router is not onlyconnecting me to the outside world, but also performing critical routing functionsWITHIN my network, it would be bad for a problem with the ISP to disrupt internalnetwork connectivity. I protect my router against this by using the maximum-

prefix command. I know roughly how many routes my ISP should be sending me,and I choose a number a little higher than thisif the ISP sends me more, then therouter will close down the session, and keep it down until I issue a clear ip bgp10.200.0.1. Alternatively, if I know that network management is quick to respondto problems, I could just configure the command to log a warning instead.

Finally, I apply a password, negotiated with my ISP, to the session.

Maximum Prefix Tracking (Cont.)


65/134


Sample logs:

The number of prefixes received from a peer

reaches 75% of the maximum configured:

%BGP-4-MAXPFX: No. of prefix receivedfrom 44.1.1.2 reaches 3, max 4

The number of prefix exceeds the maximumnumber of prefixes configured:

%BGP-3-MAXPFXEXCEED: No. of prefixreceived from 44.1.1.2: 4 exceed limit 3

Tasks


66/134


Steps

Configure neighbor

Advertise stable prefixes to your ISP

Set inbound policy

Set output policy


Advertise Stable Prefixes to Your ISP


67/134


Avoid redistributionit propagates IGPinstabilities to the Internet; Unstableroutes may be dampened!

Try to summarize!

For loadsharing, may split the

aggregatemore later

BGP Template: BGP to an ISP


68/134


The first instinct for many people is to redistribute their IGP into BGP. This is a badidea for a couple of reasons:

First, IGPs tend to have a lot our routing activity as they route-around network

failures. This is the good an dproper behavior of an IGP. However, one ofprimary goals of BGP is to hide internal rouring changes to your networkthat have no impact on global routing. Remember it is common practice byISPs in the Internet to dampen unstable routes learned from the customersof other ISPs.

Second, the subnetting used by an IGP is probably not of interest to the widerInternet. As with good IGP design, you should attempt to summarize youroutes, so that you advertise the minimum number of routes to the Internetrouting tables. Its everyones responsibility to try and minimize the size of theInternet routing tables.

You can also use a route-map to adjust other BGP attributes. For example, youmay connect to your ISPs in two location, and generate two aggregates. You canset the MEDs so that traffic for one aggregate will come into one link, and traffic tothe other will come in the other link (with both links providing a backup to the

other). Now I apply the routing policy.

Why Summarize?


69/134


Reduce number of Internet prefixes

Increase stabilityaggregate stayseven if specifics come and go

How to Summarize?


70/134


Use the network statement to defineprefixcan add route-map

network statement only installs BGP routeif there is a matching route in IGP

=> lock down a stable static to null0; set admindistance to 254 so it does not override anyreal IGP route

router bgp 1

network 10.60.0.0 mask 255.255.0.0 :

ip route 10.60.1.0 255.255.255.0 null0 254

router bgp 1

network 10.60.0.0 mask 255.255.0.0 :

ip route 10.60.1.0 255.255.255.0 null0 254

Tasks


71/134


Steps

Configure neighborAdvertise stable prefixes to your ISP

Set inbound policySet output policy


Why Inbound Policy?


72/134


Apply a recognizable community touse in outbound filters or other policy

Apply local preferences

Filter our you own/martian routes

Multihoming loadsharingmore later

BGP TemplateInbound Policy


73/134


route-map ISPin permit deny 10match ip address prefix-list ISPout sanity-check

route-map ISPin permit 20

set local-preference 200set community 1:2

routes from ISPyou coulduse theno-export wellknown community instead

Notes on Inbound Policy Template


74/134


Now lets look at inbound policy. The roles of inbound policy are to protect youagainst mistakes made by your ISP; to place routes into communities forsubsequent use in outbound policy; and to modify BGP attributes to allow us tocontrol which exit we use to send traffic to various destinations on the Internet.

To implement inbound policy I apply a route-map to the peer-group. Rememberthan inbound-policy does NOT have to be the same for all peer-group members, soI can apply different policies to different neighbors within a peer-group.

The route-map, which Ive call ISPin does three things:

1) rejects any networks in prefix-list ISPoutthis prefix lists contains theprefixes I send to my ISP, so I should not expect to receive them back. I alsocall a prefix list that rejects private address space and other insane ormartian (not on this planet!) routes.

2) applied a local-preference of 200 to all of the routesperhaps because thisexist point is the primary exit point, and another connection to my ISP is thebackup, and uses the default local-preference of 100.

3) Put the routes in community 1:2, which signifies routes Ive learned from

my ISP.

Sanity-Check Prefix-List 1/2


75/134


ip prefix-list sanity-check seq 5 deny 0.0.0.0/32

# deny the default route -YOU MAY WANT TO OMIT THIS LINE

ip prefix-list sanity-check seq 10 deny 0.0.0.0/8 le 32

# deny anything beginning with 0ip prefix-list sanity-check seq 15 deny 0.0.0.0/1 ge 20

# deny masks > 20 for all class A nets (1-127)


# deny 10/8 per RFC1918ip prefix-list sanity-check seq 25 deny 127.0.0.0/8 le 32

# reserved by IANA - loopback address

ip prefix-list sanity-check seq 30 deny 128.0.0.0/2 ge 17

deny masks >= 17 for all class B nets (129-191)ip prefix-list sanity-check seq 35 deny 128.0.0.0/16 le 32

# deny net 128.0 - reserved by IANA


# deny 172.16 as RFC1918

Sanity-Check Prefix-List 2/2


76/134



# class C 192.0.20.0 reserved by IANA




# deny 192.168/16 per RFC1918

ip prefix-list sanity-check seq 60 deny 191.255.0.0/16 le 32# deny 191.255.0.0 - IANA reserved (I think)


# deny masks > 25 for class C (192-222)


# deny anything in net 223 - IANA reserved


# deny class D/Experimental

Tasks


77/134


Steps




Why Outbound Policy?


78/134


Main filter based on communities

Adding a prefix filter helps protect againstmistakes (can apply as-path filters too)

Send community based on agreementswith ISPeg RFC1998 (remember toconfig send-community)

Multihoming loadsharing policy

Notes On Outbound Policy


79/134


Now that inbound policy is set, I next setup the outbound policy. A commonmistake made by many enterprises that dual home it to take a full set of routesfrom one ISP, and immediately send them up to the other ISP. This effectively says

the entire Internet is reachable through your network!!! Outbound policy preventsthis from occurring, so you can see why its critical.

I typically use primary outbound filter based on communities. I only send to my ISPall of the routes originated in my network, which I identify with the community 1:1.

In smaller installations, where the number of prefixes in the network is small, I mayalso use a prefix-list as a backup for the primary community filter. This doesnothing more than to help protect the world against my mistakes!!! :-)

I may also have configured some communities in agreement with my ISP. Forexample, RFC1998 describes a way to indicate which of your ISPs is primary a

secondary for a particular set of routes.

Finally, you can configure any multihoming/loadsharing policy. You may want todivide your address space, and make traffic to half of your network come in via oneISP, and traffic for the other half come in through the other.

BGP TemplateOutbound Policy


80/134


ip prefix-list ISPout seq 5 permit 10.60.0.0 255.255.0.0:

ip community-list 1 permit 1:1 ; all routes to send to ISP

:

route-map ISPout permit 10

match community 1 ; Internet transit community

set community 1:3 [additive] ; something agreed with ISP

Notes On Outbound Policy


81/134


The previous slide shows my outbound policy. First, the prefix-list ISPout matchesall of the routes I intend to send to the Internetin this case only onelife is

simple in the powerpoint world of network design :-) This prefix-list is my backupin case I make a mistake with communities. I only used it on my connections tomy ISP.

The primary filter is based on communities. I match all communities in community-

list 1: ie, only community 1:1, corresponding to all the routes local to my network.This assumes that on ingress to by BGP tables (either via EBGP sessions,network/aggregate-address, or redistribution from an IGP, I have used a route-map to set the community to 1:1.

Finally I add the outbound community to 1:3 community attribute. This is done to

meet some arbitrary agreement Ive have made with my ISP on how it will treatroutes I put in this community.

Tasks


82/134


Steps




Load-Sharing Template: Single Path


83/134


AS1AS2

A Loopback 02.0.0.1

Router A:

interface loopback 0

ip address 1.0.0.1 255.255.255.255

ip route 2.0.0.1 255.255.255.255 serial0/0

ip route 2.0.0.1 255.255.255.255 serial0/1

!

router bgp 1


neighbor 2.0.0.1 update-source loopback0

neighbor 2.0.0.1 ebgp-multi-hop 2

B

Load-Sharing Template: MultiplePaths from Same AS


84/134


Router A:

router bgp 1


neighbor 2.0.0.2 remote-as 2maximum-paths 2; can configure up to 6

AS 1

AS 2A2.0.0.1

2.0.0.2

B

C

Outbound loadsharing works well :-)

Inbound loadsharing depends on ISP IGP :-|

What Is Multi-homing?


85/134


Connecting to two or more ISPs toincrease:

Reliabilityone ISP fails, still OK

Performancebetter paths to commonInternet destinations

Types of Multi-homing


86/134


Three common cases:Default from all ISPs

Default + customer routes from all ISPsFull routes from all ISPs

Look first at outbound loadsharing

Default from All ISPs


87/134


Low memory/CPU solution All ISPs send (or you generate) default

ISP decided by IGP metrics toreach default

Default from All ISPs


88/134


AS 1

ISP

AS 2

Customer

AS 4

4.0.0.0/8

ISP

AS 3

E

B

C

A

D0.0.0.0 0.0.0.0

C Chooses Lowest

IGP Metric to Default

Customer+Default from All ISPs


89/134


Medium memory and CPU

Best pathusually shortest AS-path

Use local-preference to override based onprefix, as-path, or community

IGP metric to default used to reach non-

direct customers of ISPs

Customer Routers from All ISPs


90/134


AS 1

ISP

AS 2

Customer

AS 4

4.0.0.0/8

ISP

AS 3

E

BA

D

C Chooses

Shortest AS Path

C

Customer Routes from All ISPs


91/134


ISP

AS 3

ISP

AS 2

D

ip prefix-list AS4 permit 4.0.0.0/8

route-map AS3in permit 10

match ip address prefix-list AS4

set local-preference 800

800

Customer

AS 44.0.0.0/8

BA

AS 1

E

C Chooses Highest

Local-Preference

C

Customer Routes from All ISPs


92/134


AS 1

Tier 2 ISPAS 2

Tier 1 ISP

AS 4

Tier 1 ISP

AS3

B

C

A

ED

AS 6

AS400 Takes Sub-

Optimal AS Path

Tier 1 ISP

AS 5

Full Routes from All ISPs


93/134


Higher memory/CPU solution

Reach all destinations by bestpathusually shortest AS path

Can still manually tuneusing local-pref and

as-path/community/prefix matches

Full Routes from All ISPs


94/134


AS 1

Tier 2 ISPAS 2

Tier 1 ISP

AS 4

Tier 1 ISP

AS3

B

C

A

ED

AS 6Tier 1 ISP

AS 5

C Chooses

Shortest AS Path

Controlling Inbound Traffic?


95/134


Inbound is more difficult to control due to

lack of a transitive metric

You can evenly divide outgoing address

blocks across providers, but whathappens to redundancy?

If you split your address block, ISPs may

filter out the specifics anyway

Controlling Inbound Traffic? (Cont.)

B d I t t iti


96/134


Bad Internet citizen:

Divide address space

Set as-path prepend

Good Internet citizenRFC2260

Divide address space

Use advertise maps

Results may not be as good as NAT withtransport level loadsharing

Warning: if you split your address block using these techniques

it may be filtered by some ISPs

Using AS-PATH Prepend

10.1.0.0/16 3 1 1


97/134


AS 1

ISP

AS 2

Customer

AS 100

ISP

AS 3

E

B

C

A

D

router bgp 1


neighbor 30.0.0.1 route-map AS3out outip prefix-list AS1 permit 10.1.0.0/16

route-map AS3out permit 10

match ip address prefix-list AS1

set as-path prepend 1

30.0.0.1

10.2/16

to

10.1/16

10.1/16

10.1.0.0/16 3 1 110.1.0.0/16 2 1 (best)

10.2.0.0/16 3 1 (best)

10.2.0.0/16 2 1 1

Using an Advertise-Map

router bgp 100


98/134


gpneighbor advertise-map am non-exist-map bb

access-list 1 permit 10.15.7.0 !Advertise when...

access-list 2 permit 10.15.0.0 ! this disappears

route-map am permit 10match ip address 1

route-map bb permit

match ip address 2ISP1

ISP2R1

R3

1.10.6/2410.15.7/24

1.10.6.110.15.7.4

10.15.7/24

10.15.7/24 Auto-Inject

10.15/16

R4

1.10/16

AS 2

10.15.20/30

R2

1.10.6/24

Summary for Enterprise EBGP

St bilit th h


99/134


Stability through:

Aggregation/summary routes

Multihoming

Inbound/outbound policy

Scalability of memory/CPU:

Default, customer routes, full routes

Simplicity using standard solutions


100/134


Deploying External BGPfor ISPs

Route Aggregation, Customer Aggregation, NAPs

ISP EBGP Tasks


101/134


Configure stable aggregates

Scale BGP customer aggregation

Offer a choice of route-feeds Peer with other providers

Provide a backup service

What Is Aggregation?


102/134


Summarization based on specifics from

the BGP routing table10.60.1.0 255.255.255.0

10.60.2.0 255.255.255.240=> 10.60.0.0 255.255.0.0

How to Aggregate


103/134


aggregate-address 10.60.0.0 255.255.0.0

{as-set} {summary-only} {route-map} Use as-setto include path and community

info from specifics summary-onlysuppresses specifics

route-map sets other attributes

How to AggregateNotes

So what is aggregation? Aggregation is generating that all-important stable route


104/134


So what is aggregation? Aggregation is generating that all important stable routethat summarizes all of the routes I want to send to the Internet. My route is stablebecause it is common practice by ISPs in the Internet to dampen the routeslearned from the customers of other ISPs.

Generating a stable aggregating it a three step process. First I configure theaggregate-address command to define the aggregate prefix to be generated. Thecommand includes both net and mask.

If I include the as-set keyword, it causes the router to generate an AS-SET withinthe AS-PATH. Remember from earlier in the session, that an AS-SET includes AS-

PATH information from all more specific routes that contributed to the aggregate.As well as generating an AS-SET, the router will also include BGP communityinformation from all of the more specific routes in the community attribute of theaggregate route.

By default, the aggregate address command does NOT filter out the more specific

BGP routes. TO do this you need to add the summary-address keyword. Mostlylikely you will want to do this.

You can also use a route-map to adjust other BGP attributes. For example, youmay connect to your ISPs in two location, and generate two aggregate. You can setthe MEDs so that traffic for one aggregate will come into one link, and traffic to theother will come in the other link (with both links providing a backup to the other).

Why Aggregate?


105/134


Reduce number of Internet prefixes

advertise only your CIDR block Increase stabilityaggregate stays

even if specifics come and go Stable aggregate generation:

router bgp 1aggregate-address 10.60.0.0 255.255.0.0 as-set summary-only

network 10.60.1.0 255.255.255.0:ip route 10.60.1.0 255.255.255.0 null0 254

router bgp 1aggregate-address 10.60.0.0 255.255.0.0 as-set summary-only

network 10.60.1.0 255.255.255.0:ip route 10.60.1.0 255.255.255.0 null0 254

Why Aggregate: Notes

Once youve configured the aggregate the next step is to configure a stable MORE


106/134


Once you ve configured the aggregate, the next step is to configure a stable MORESPECIFIC route in the BGP table. After all, your aggregate depends on the existingof more specific routes, to you must ensure at least one of the more specificroutes is stable.

To do this, use the network command. Choose a more specific route than youraggregatea route that is used somewhere in route network. In the slide Ivechosen 10.60.1/24.

The network command will install a corresponding route in the BGP table, ONLY ifthere is a matching route in the IP routing table. The third, and final step, is

therefore to generate a stable route in the IP routing table. To do this, I configure aSTATIC route for 10.60.1/24, pointing to the NULL0 interface. However, I do notwant this route to override any real route that Im learning via an IGP for10.60.1/24so, I set the ADMIN DISTANCE of the static route to 254.

Note that if you do note want to generate AS-SET/community summary

information, you can omit the aggregate-address command. Use the networkcommand to generate the aggregate prefix, and then put a matching static route inpointing to NULL0. Many, perhaps most, folks tend to do it this way, and do notuse the aggregate address command. Note that you need to be careful to filter outmore specific BGP routes if you use this technique, as the network command doesnot provide any summary-only functionality.

BGP Attributes Atomic Aggregate


107/134


Indicates loss of AS-PATH information

Must not be removed once set

Set by: aggregate-address x.x.x.x

Not set ifas-setkeyword is used, however,AS-SET and COMMUNITY then carries

information about specifics

BGP Attributes: Aggregator


108/134


AS number and IP address of router

generating aggregate

Useful for troubleshooting

Only set by aggregate-address; NOT setby the network statement

Aggregate Attributes


109/134


NEXT_HOP = local (0.0.0.0)

WEIGHT = 32768

LOCAL_PREF = none (assume 100)

AS_PATH = AS_SET or nothing

ORIGIN = IGP

MED = none

ISP EBGP Tasks



110/134




Offer a choice of route-feeds

Peer with other providers Provide a backup service

Propagate QoS policy

Customer Aggregation Guidelines

Define at least three peer groups:


111/134


Define at least three peer groups:

cust-defaultsend default route only

cust-custsend customer routes only

cust-full send full Internet routes

Identify routes via communities

eg, 2:100=customers; 2:80=peers

Apply passwords and an inbound prefix-list on a per neighbor basis

Customer Aggregation

COREYour AS


112/134


CORE

Route Reflector

Client Peer Group

Aggregation Router(RR Client)

Customer RoutesPeer Group

DefaultPeer Group

Full RoutesPeer Group

Your AS

CIDR Block: 10.0.0.0/8

Apply Passwords and Inbound

Prefix-list Directly to Each Neighbor

BGP template - customers


113/134


neighbor x.x.x.x remote-as X

neighbor x.x.x.x peer-group (cust-full or cust_custor cust_default)

neighbor x.x.x.x password

neighbor x.x.x.x prefix-list ASXXX in.

ip prefix-list ASXXX seq 5 permit

BGP template - full routes peer-group


114/134


neighbor cust-full peer-group

neighbor cust-full description Send full Routesneighbor cust-full remove-private-AS

neighbor cust-full version 4

neighbor cust-full route-map cust-in in

neighbor cust-full route-mapfull-routes out

.

BGP template: full routes route-map

ip prefix-list cidr-block seq 5 deny 10.0.0.0/8 ge 9


115/134


p p q y g

ip prefix-list cidr-block seq 10 permit 0.0.0.0/0 le 32

ip community-list 1 permit 2:100ip community-list 80 permit 2:80

.

route-map full-routes permit 10

match ip cidr-block ; deny CIDR subnets

match community 1 80 ; customer & peersset metric-type internal ; MED = IGP metric

set ip next-hop peer-address ; our own

BGP template: customer inboundroute-map


116/134


route-map cust-in permit 10

set metric 4294967294 ; ignore MED

set ip next-hop peer-address

set community 2:100

BGP template: customer routespeer-group


117/134


neighbor cust-cust peer-group

neighbor cust-cust description customer routes

neighbor cust-cust remove-private-AS

neighbor cust-cust version 4

neighbor cust-cust route-map cust-in in

neighbor cust-cust route-map cust-routes out

BGP Template: template: customerroutes route-map


118/134


route-map cust-routes permit 10match ip cidr-block

match community 1 ; customers only

set metric-type internal ; MED = igp metric


BGP Template: default routepeer-group

neighbor cust default peer group


119/134


neighbor cust-default peer-group

neighbor cust-default description Send default

neighbor cust-default default-originateroute-map default-route

neighbor cust-default remove-private-AS

neighbor cust-default version 4neighbor cust-default route-map cust-in in

neighbor cust-default prefix-list deny-all out

ip prefix-list deny-all seq 5 deny 0.0.0.0/0 le 32

ISP EBGP Tasks


120/134




Offer a choice of route-feeds

Peer with other providers

Peering with other ISPs


121/134


Similar to EBGP customer aggregation

except inbound prefix filtering is rarelyused (lack of global registry)

Use maximum-prefix and prefix sanitychecking instead

Still use per-neighbor passwords!

BGP Template: ISP peers peer-group


122/134


neighbor nap peer-group

neighbor nap description for peer ISPsneighbor nap remove-private-AS

neighbor nap version 4

neighbor nap prefix-list sanity-check in

neighbor nap prefix-list cidr-block out

neighbor nap route-map nap-out outneighbor nap maximum prefix 30000

BGP Template: ISP peers route-


123/134


route-map nap-out permit 10

match community 1 ; customers only

set metric-type internal ; MED = IGP metric


Peer Groups for NAPs:Sanity-Check Prefix-List

# FIRST - FILTER OUT YOUR IGP ADDRESS SPACE!!

ip prefix-list sanity-check seq 5 deny 0.0.0.0/32


124/134


# deny the default route


# deny anything beginning with 0ip prefix-list sanity-check seq 15 deny 0.0.0.0/1 ge 20

# deny masks > 20 for all class A nets (1-127)


# deny 10/8 per RFC1918ip prefix-list sanity-check seq 25 deny 127.0.0.0/8 le 32

# reserved by IANA - loopback address


deny masks >= 17 for all class B nets (129-191)ip prefix-list sanity-check seq 35 deny 128.0.0.0/16 le 32

# deny net 128.0 - reserved by IANA


# deny 172.16 as RFC1918

Peer Groups for NAPs:Sanity-Check Prefix-List


# class C 192 0 20 0 reserved by IANA


125/134






# deny 192.168/16 per RFC1918


# deny 191.255.0.0 - IANA reserved (I think)


# deny masks > 25 for class C (192-222)

ip prefix-list sanity-check seq 70 deny 223.255.255.0/24 le 32# deny anything in net 223 - IANA reserved


# deny class D/Experimental

Summary for Deploying EBGP

Stability through:Aggregation/summary routes


126/134


Aggregation/summary routes

Inbound prefix-filtering and passwordsApply sanity-check and maximum-prefixfeature to ISP peering

Scalability of memory/CPU:

Three peer-groups for customers: Default,

customer routes, full routesOne peer group for ISP peers

Simplicity using standard solutions

Session Summary 1

Scalability:Use attributes especially community


127/134


Use attributes, especially community

Use peer groups and route reflectors

Stability:

Use loopback addresses for IBGPGenerate aggregates/summary addresses

Apply passwordsAlways filter inbound and outbound

Session Summary 2

Simplicitystandard solutions:

Three multihoming options


128/134


Three multihoming options

Group customers into communities

Apply standard policy at the edge

Avoid special configs

Script your config generation

For Further Reference:

BGP bestpath


129/134


BGP bestpath

http://www.cisco.com/warp/public/459/25.shtml

Case studies on www.cisco.com:

http://www.cisco.com/warp/public/459/18.html

www.cisco.comsearch BGP

www.nanog.org

Recommended Reading

Cisco BGP-4 Command and

Configuration Handbook
http://www.cisco.com/warp/public/459/25.shtmlhttp://www.cisco.com/warp/public/459/18.htmlhttp://www.cisco.com/warp/public/459/18.htmlhttp://www.cisco.com/warp/public/459/25.shtmlhttp://www.cisco.com/warp/public/459/25.shtml


130/134


Configuration Handbook

ISBN: 1-58705-017-X

Advanced IP Network Design

ISBN: 1-57870-097-3

Internet Routing Architectures

ISBN: 1-57870-233-X

Routing TCP/IP, Volume II

ISBN: 1-57870-089-2

Troubleshooting IP Routing Protocols

ISBN: 1-58705-019-6

Available online or on-site at the Cisco Company Store


131/134


Deploying BGP-4

RST-243


132/134


Please Complete YourEvaluation FormRST-243

Date post:	30-May-2018
Category:	Documents
Upload:	pohseng
View:	218 times
Download:	0 times

Deploying BGP4 (RST-243)

Documents