Deploying BGP4 Teichtahl

8/14/2019 Deploying BGP4 Teichtahl

1/90

1RST-2103025_05_2001_c1 2001, Cisco Systems, Inc. All rights reserved.


2/90


3/90

3 2001, Cisco Systems, Inc. All rights reserved.

Deploying BGP4Marc Teichtahl

Consulting Engineer EMEA PTT2


4/90


4

Contacts

Speaker: Marc Teichtahl([email protected])

Slides will be available at the networksURL


5/90


6/90


7/90


7

Overview

Protocol Overview

Using BGP Attributes

Deploying IBGP

Deploying EBGP

Connecting to an ISP

Being an ISP

Focus on Stability, Scalability, and ConfigurationTemplates


8/90


8

Complex Network Scalability

ScalableScalable

StableStable

SimpleSimple

Network routing architectures should focus on being


9/90


BGP Review

What Is it? Why Use it?


10/90


10

Basic to Basics

Runs over TCPport 179

Path vector protocol

Incremental updates

Internal and External BGP

AS 100 AS 101

AS 102

EE

BB DD

AA CC

Peering


11/90


11

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 are applied by influencing thebestpath selection

Policy tools include local-pref, communities, MED, etc


12/90


12

BGP SessionsTCP Port 179,4 Basic Message Types

4 BGP Messages control the opening,updates, withdrawals and BGP sessionsmaintenance.


13/90


13

BGP Sessions - Control

1: OPEN MESSAGE

Exchange AS, router ID, holdtime

Capability negotiation

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Optional Parameters (as specified above)Optional Parameters (as specified above)

BGP Identifier (4 bytes)BGP Identifier (4 bytes)

Opt. Parm. Len. (1)Opt. Parm. Len. (1)

Hold Time (2 bytes)Hold Time (2 bytes)

My Auto. System (2 bytes)My Auto. System (2 bytes)

Version (1 bytes)Version (1 bytes)


14/90


14


2: NOTIFICATION

Example: peer in wrong AS

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Error code | Error subcode | Data |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1 = HRD Error, 2 = OPEN Error, 3= UPDATE Error

4 = Hold Time Expired, 5 = FSM Error, 6 = Cease


15/90


15


3: KEEPALIVEwhen no updates

These keepalives ensure that the BGP neighbour relationship

Is maintained and not the TCP level connectivity


16/90


16


4: UPDATES (incremental)+-----------------------------------------------------+

| Unfeasible Routes Length (2 octets) |

+-----------------------------------------------------+

| Withdrawn Routes (variable) |

+-----------------------------------------------------+

| Total Path Attribute Length (2 octets) |

+-----------------------------------------------------+

| Path Attributes (variable) |

+-----------------------------------------------------+

| Network Layer Reachability Information (variable) |

+-----------------------------------------------------+

+---------------------------+

| Length (1 octet) |

+---------------------------+

| Prefix (variable) |

+---------------------------+

0 10 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Attr. Flags |Attr. Type Code|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


17/90


17

BGP Routing Policy

Defines in technical terms your businessrules

Default to provider X

Select paths according to cost/reliabilityUse path Y for Backup

Tools to achieve this policy are the BGPattribute tools


18/90


19/90


19

Why Use BGP ?

You need to scale your IGP

Youre a multihomed ISP customer

You need to transit full Internet routes


20/90


Deploying BGP


21/90


21

BGP TemplateBGP Global Settings

router bgp 1bgp deterministic-med

no synchronisationno auto-summary

router bgp 1bgp deterministic-med

no synchronisationno auto-summary

For BGP config templates from now on, Illassume youve already done this!


22/90


Deploying Internal BGP

Loopbacks, Peer-Groups, Route Reflectors and Confederations


23/90


23

Guidelines for Stable IBGP

IBGP peer using loopback addressesneighbor { ip address | peer-group}

update-source loopback0

Independent of physicalinterface failure

TCP carries our BGP information

Loopbacks reachable via IGP

IGP/CEF performs any load-sharing

IBGP onlyuse on RR clients with care!!!


24/90


24

Without Loopbacks, the TCPSession Is Always

Sourced from the IP Addressof the Outbound Interface

Which Can Go Down!

Without Loopbacks, the TCPSession Is Always

Sourced from the IP Addressof the Outbound Interface

Which Can Go Down!

Peering with Loopbacks

Configuration:

Router A

router bgp 1neighbor 1.0.1.1 remote-as 1

Router Brouter bgp 1neighbor 1.0.1.2 remote-as 1

A B

1.0.1.11.0.1.1 1.0.1.21.0.1.2

If Redundant Paths Exist,

Use Loopback Interfacesto Establish the Session

If Redundant Paths Exist,

Use Loopback Interfacesto Establish the Session


25/90


25

Guidelines for Scaling IBGP

Carry only next-hops in IGP

Aggregation at IGP level can be dangerous

Carry full routes in BGP only

if necessaryImportant at peering points

MPLS does not have this concern

Do not redistribute BGP into IGP

Use peer groups and RRs


26/90


26

BGP TemplateIBGP Peers

IBGP Peer Group AS1

router bgp 1neighbor internal peer-group

neighbor internal description ibgp peersneighbor internal remote-as 1neighbor internal update-source Loopback0

neighbor internal next-hop-selfneighbor internal send-communityneighbor internal version 4

neighbor internal password 7 03085A09neighbor 1.0.0.1 peer-group internalneighbor 1.0.0.2 peer-group internal


27/90


27

What Is a Peer Group?

Simplifies configuration

All peer-group members havea common outbound policy

Updates generated once per peer groupUpdate replication efficiency

Members can have differentinbound policy

Differing outbound policies will negate the value of thepeer-group and lower update replication efficiency


28/90


28

Why Route Reflectors?

n=1000 => NearlyHalf a MillioniBGP Sessions!

n=1000 => NearlyHalf a MillioniBGP Sessions!

Avoid n(n-1)/2 iBGP Mesh

13 Routers =>78 IBGP

Sessionstotal


29/90


29

Using Route Reflectors

Golden Ruleof RR Loop Avoidance:

RR Topology Should FollowPhysical Topology

=> Be Careful with Loopback Peering!!!!

RRC

Cluster ACluster A

RRRR

RRRR

RRCRRC

Cluster BCluster B

RRRR

BackboneBackboneRRRR

RRC

Cluster CCluster CRRRR

RRC

Cluster DCluster DRRRR


30/90


30

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 coexistOnly the RR has to support this feature

neighbor x.x.x.x route-reflector-client

Route reflector clients receive the best route

as seen by the RR Beware this may not alwaysbe the best route for the client


31/90


31

Route Reflector

Clients Clients

Clusters

Non-client

Lines Represent Both Physical Links and BGP Logical ConnectionsLines Represent Both Physical Links and BGP Logical Connections

Route ReflectorsTerminology


32/90


32

Route ReflectorsTerminology (Cont.)

Route reflector

Router that reflects the iBGP information

Client

Routers between which the RR reflects updates (may

be fully meshed among themselves)

Cluster

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

Non-clientiBGP neighbour outside the cluster


33/90


33

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


34/90


34

Clusters may beconfigured hierarchically

RRs in a cluster are clientsof RRs in a higher level

Provides a

naturalmethod to limit routinginformation sent to lowerlevels

Beware of segmenting theBGP layers

Route ReflectorsHierarchy

Level 2

Level 1


35/90


36/90


36

Route ReflectorsMigration

Where to place the route reflectors?

Follow the physical topology!

This will guarantee that the packet forwarding

wont be affected

Configure one RR at a time

Eliminate redundant iBGP sessions

Place one RR per cluster


37/90


37

BGP Template: Peer-Group for RR Clients

This Line on RRsOnly RRCs Use

Still Use Internal

Peer Group

This Line on RRsOnly RRCs Use

Still Use Internal

Peer Group

Will this Break theGolden Rule

Will this Break theGolden Rule

router bgp 1neighbor rr-client peer-group

neighbor rr-client description RR clients

neighbor rr-client remote-as 1

neighbor rr-client update-source Loopback0

neighbor rr-client route-reflector-client

neighbor rr-client next-hop-selfneighbor rr-client send-community

neighbor rr-client version 4

neighbor rr-client password 7 03085A09neighbor 10.0.1.1 peer-group rr-client

neighbor 10.0.1.2 peer-group rr-client


38/90


38

RR Specific BGP Attributes

Example:

RouterB>sh ip bgp 3.0.0.0

BGP 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

ARRC Router id

1.2.1.1

Router id1.3.1.1

1.4.1.1

1.0.1.2

Router id1.1.1.1

3.0.0.0AS3

B

RRC

RR

Originator: 1.1.1.1Cluster list: 1.3.1.1, 1.2.1.1


39/90


39

BGP Attributes: ORIGINATOR_ID

ORIGINATOR_ID

Router ID of IBGP speaker that injectsroute into ASapplied by RR

Useful for troubleshooting andloop detection


40/90


40

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

remember: dont do this!!!!

Useful for troubleshooting andloop detection


41/90


41

Route ReflectorsRedundancy

Multiple RRs can be configured in thesame clusterbut we now adviseagainst this

Other RRs in the same cluster should

be treated as iBGP peers (non-clients)

All RRs in the cluster must have the samecluster-id

A router may be a client for RRsin different clusters


42/90


42

Route ReflectorsResults

Number of neighbors is reduced

No need for full iBGP mesh

Number of routes propagated is reducedEach RR advertises only the best pathto its clients

Stability and scalability are achieved!


43/90


43

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


44/90


45/90


45

Confederations (Cont.)

Configuration (rtr B):router bgp 65532confederation identifier 2

bgp confederation peers 65530 65531neighbor 141.153.12.1 remote-as 65530neighbor 141.153.17.2 remote-as 65531

Sub-AS65530

AS 2

Sub-AS65532

B Sub-AS65531


46/90


46

Route Propagation Decisions

Same as with normal BGP:

From peer in same sub-AS only toexternal peers (eBGP rules)

From external peers to all neighbors (iBGP rules)

External peers refers to

Peers outside the confederation

Peers in a different sub-AS

Preserve LOCAL_PREF, MED and NEXT_HOP


47/90


48/90


48

RRs or Confederations

Internet

Connectivity

Internet

ConnectivityMulti-Level

Hierarchy

Multi-Level

HierarchyPolicy

Control

Policy

ControlScalabilityScalability

Route

Reflectors

Confederations

Anywhere

In theNetwork

Anywhere

In theNetwork

Migration

Complexity

Migration

Complexity

YesYes YesYes Medium MediumTo High

AnywhereIn the

Network

AnywhereIn the

NetworkYesYes YesYes Very High Very Low


49/90


49

More Points about Confeds

Can assist in absorbing other ISPs intoyou ISP

If one ISP buys another (can use local-as

feature to do a similar thing)

You can use route-reflectors withinconfederation sub-as

Reduce the sub-as ibgp mesh


50/90


50

So Far

Is IBGP peering Stable?

Use loopbacks for peering

Will it Scale?Use peer groups

Use route reflectors

Simple, hierarchical config?


51/90


COMMUNITIES

Theyre for Everyone!

Problem: Scale Routing Policy


52/90


52

g ySolution: COMMUNITY

NOT in decision algorithm

BGP route can be a member of manycommunities

Typical communities:Destinations learned from customers

Destinations learned from ISPs or peers

Destinations in VPNBGP community is fundamentalto the operation of BGP VPNs (rfc2547)



53/90


53

Solution: COMMUNITY

ISP 1ISP 1

Customer 1

(no Default,Wants Full Routes)

ISP 2

Communities:1:100Customer Routes

1:80 ISP Routes


1:80 ISP Routes

ISP 4ISP 3

Customer 2(Uses Default,

Wants Your Routes)

0.0.0.0



54/90


54

Solution: COMMUNITY

ISP 1ISP 1

Customer 1

(no Default,Wants Full Routes)

ISP 2


1:80 ISP Routes


1:80 ISP Routes

ISP 4ISP 3

Customer 2(Uses Default,

Wants Your Routes)

0.0.0.0

Match Community1:100

Match Community1:100 1:80 Match Community

1:100

Set Community1:80

Set Community

1:100


55/90


55

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]

32 AS address space in coming

BGP A ib COMMUNITY (C )


56/90


56

BGP Attributes: COMMUNITY (Cont.)

Each destination can be a member ofmultiplecommunities

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)

C it Filt


57/90


57

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

C it Filt


58/90


58

Community Filters

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

Configuration:router bgp 1

neighbor 10.0.0.1 remote-as 2

neighbor 10.0.0.1 send-communityneighbor 10.0.0.1 route-map set_community out

!

route-map set_community 10 permit

match ip address 1

set community 1:120

!

access-list 1 permit 10.10.0.0 0.0.255.255

C it Filt


59/90


59

Community Filters

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

Configuration:router bgp 1

neighbor 10.0.0.1 remote-as 2

neighbor 10.0.0.1 route-map filter_on_community in!

route-map filter_on_community 10 permit

match community 1

set local-preference 150

!

ip community-list 1 permit 2:150

Regular Expression Syntax URL


60/90


60

Regular Expression SyntaxURL

Overview of IOS regular expressionsyntax:

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


61/90


Deploying External BGPfor ISPs

Route Aggregation, Customer Aggregation, NAPs

ISP EBGP Tasks


62/90


62

ISP EBGP Tasks

Configure stable aggregates

Scale BGP customer aggregation

Offer a choice of route-feeds

Peer with other providers

Provide a backup service


63/90

How to Aggregate


64/90


64

How to Aggregate

aggregate-address 10.60.0.0 255.255.0.0{as-set} {summary-only} {route-map}

Use as-setto include path and communityinformation from specifics

summary-onlysuppresses specifics

route-map sets other attributes

Why Aggregate?


65/90


65

Why Aggregate?

Reduce number of Internet prefixesadvertise 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

BGP Attributes: Atomic Aggregate


66/90


66

BGP Attributes: Atomic Aggregate

Indicates loss of AS-PATH information

Must not be removed once set

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

Not set if as-setkeyword is used, however,AS-SET and COMMUNITY then carriesinformation from specifics

BGP Attributes: Aggregator


67/90


67

BGP Attributes: Aggregator

AS number and IP address of routergenerating aggregate

Useful for troubleshooting

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

Aggregate Attributes


68/90


68

Aggregate Attributes

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


69/90


69

ISP EBGP Tasks





Provide a backup service

Propagate QoS policy

Customer Aggregation Guidelines


70/90


70

Customer Aggregation Guidelines

Define at least three peer groups:

cust-defaultsend default route only

cust-custsend customer routes only

cust-full send full Internet routes

Tag routes via communities

Use identifier and action communities

2:100=customers; 2:80=peers; 2:1000 announce totransit

Apply passwords and an inbound prefix-list on aper neighbor basis

if applicable password management can be trickyfrom an operational perspective

Customer Aggregation


71/90


71

Custo e gg egat o

CORECORE

Route ReflectorRoute Reflector

Client Peer Group

Aggregation Router(RR Client)

Customer Routes

Peer Group

Default

Peer Group

Full Routes

Peer Group

Your ASCIDR Block: 10.0.0.0/8Your ASCIDR Block: 10.0.0.0/8

BGP template - customers


72/90


72

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

neighbor x.x.x.x peer-group (cust-full or cust_cust

or cust_default)neighbor x.x.x.x prefix-list ASXXX in

!

ip prefix-list ASXXX seq 5 permit

p

BGP template - full routes peer-group


73/90


73

p p g p

neighbor cust-full peer-groupneighbor cust-full description Send fullRoutes

neighbor cust-full remove-private-AS

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

neighbor cust-full route-mapfull-routes out

BGP template: full routes route-map


74/90


74

p p

ip prefix-list cidr-block seq 5 deny 10.0.0.0/8 ge 9ip prefix-list cidr-block seq 10 permit 0.0.0.0/0 le 32



.route-map full-routes permit 10

match ip cidr-block ; deny CIDR subnets

match community 1 80 ; customer & peers

set metric-type internal ; MED = IGP metricset ip next-hop peer-address; our own

BGP template: customer inboundroute-map


75/90


75

p

route-map cust-in permit 10

set metric 4294967294 ; ignore MEDset ip next-hop peer-address

set community 2:100

BGP template: customer routespeer-group


76/90


76

neighbor cust-cust peer-group

neighbor cust-cust description customer routes

neighbor cust-cust remove-private-ASneighbor 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


77/90


77

route-map cust-routes permit 10

match ip cidr-block

match community 1 ; customers only

set metric-type internal ; MED = igp metric

set ip next-hop peer-address ; our own

BGP Template: default routepeer-group


78/90


78

neighbor cust-default peer-groupneighbor cust-default description Send defaultneighbor cust-default default-originate

route-map default-route

neighbor cust-default remove-private-ASneighbor cust-default version 4neighbor cust-default route-map cust-in inneighbor 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


79/90


79





Peering with other ISPs


80/90


80

Similar to EBGP customer aggregationexcept inbound prefix filtering is rarely

used (lack of global registry) Use maximum-prefix and prefix sanity

checking instead

BGP Template: ISP peers peer-group


81/90


81

neighbor nap peer-group

neighbor nap description for peer ISPs

neighbor nap remove-private-AS

neighbor nap version 4neighbor nap prefix-list sanity-check in

neighbor nap prefix-list cidr-block out

neighbor nap route-map nap-out out

neighbor nap maximum prefix 30000

BGP Template: ISP peers route-


82/90


82

route-map nap-out permit 10

match community 1 ; customers onlyset metric-type internal ; MED = IGP metric

set ip next-hop peer-address ; our own


83/90

Peer Groups for NAPs:Sanity-Check Prefix-List


84/90


84

ip prefix-list sanity-check seq 45 deny 192.0.2.0/24 le 32

# class C 192.0.20.0 reserved by IANA


# class C 192.0.0.0 reserved by IANA


# deny 192.168/16 per RFC1918


# deny 191.255.0.0 - IANA reserved (I think)

ip prefix-list sanity-check seq 65 deny 192.0.0.0/3 ge 25

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


# deny anything in net 223 - IANA reservedip prefix-list sanity-check seq 75 deny 224.0.0.0/3 le 32

# deny class D/Experimental

Summary for Deploying EBGP


85/90


85

Stability through:

Aggregation/summary routes

Inbound prefix-filtering and passwords

Apply sanity-check and maximum-prefixfeature to ISP peering.

Scalability of memory/CPU:

Three peer-groups for customers: Default,customer routes, full routes

One peer group for ISP peers

Simplicity using standard solutions

Session Summary 1


86/90


86

Scalability:

Use attributes, especially community

Use peer groups and route reflectors

Stability:

Use loopback addresses for IBGP

Generate aggregates/summary addresses

Apply passwords

Always filter inbound and outbound

Session Summary 2


87/90


87

Simplicitystandard solutions:

Three multihoming options

Group customers into communities

Apply standard policy at the edge

Avoid special configs

Script your config generation

For Further Reference:


88/90


88

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


89/90

Documents

Deploying BGP4 Teichtahl