Route Filtering and Route Selection in BGP docx

Upon completion of this lesson, you will be able to perform the following tasks: – Describe Multi-Home BGP Networks – Describe Transit BGP Networks – Filter incoming and outgoing BGP u

Route Filtering and Route Selection in BGP

Upon completion of this lesson, you will be able to

perform the following tasks:

– Describe Multi-Home BGP Networks

– Describe Transit BGP Networks

– Filter incoming and outgoing BGP updates

route-maps

– Influence BGP route selection

– Monitor and troubleshoot BGP filters

– Implement non-disruptive BGP policy changes

– Limit the number of routes received from a BGP

neighbor

Multi-Homed BGP

Networks

Multi-homed Customers

Business Requirements

 Some customers need redundant Internet access

for their mission-critical applications

 Full redundancy is only achieved by connecting to

two independent Service Providers

Internet

Multi-homed Customer

Service Provider #2 Service Provider #1

Multi-homed Customers

Technical Requirements

 Multi-homed customers have to run BGP with the

Internet Service Providers

 They usually need public AS-number and

provider-independent address space

Internet

Multi-homed Customer

Service Provider #2 Service Provider #1

Service Provider #2 Service Provider #1

router bgp my-AS-number neighbor provider-A remote-as ISP-A neighbor provider-B remote-as ISP-B network my-network

The Results of Simple-Minded Approach

 BGP routes are selected based on AS-path length

 The default BGP route selection does not always

result in optimum routing

as123# show ip bgp

BGP table version is 16, local router ID is 1.2.3.4

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

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

Network Next Hop Metric LocPrf Weight Path

Routing Policies for Multi-Homed

Customers

Multi-homed customers could require a number of

routing policies, for example:

– One provider is primary, the other is backup

– Traffic to direct customers of the ISPs go direct, all

other traffic goes through the primary provider

– All transatlantic traffic goes through one ISPs

– Traffic toward a specific destination goes only

through one of the ISPs

Primary/Backup Provider

 Internet traffic always flows over primary ISP

 Routes received from primary ISP should be preferred

over routes received from backup ISP

 A route selection tool is needed in BGP - weights or

Upstream AS

Another Customer

Primary ISP

Local Traffic Goes Direct

 Internet traffic flows over primary ISP, traffic to

customers of backup ISP goes direct

 Route selection has to be performed based on

AS-numbers in the AS-path

Upstream AS

Another Customer

Primary ISP

Transit Traffic Issue

 Customers could become transit AS for the Service

Providers

Internet

Multi-homed Customer

Service Provider #2 Service Provider #1

• Requirement: do not propagate provider

routes to other providers

Routing Update Reliability Issue

 Customers running BGP could announce any route to

the Service Providers

Internet

Multi-homed Customer AS123 21.0.0.0/8

Service Provider #2 Service Provider #1

Network=10.0.0.0/8 AS-Path=123

• Requirement: Service Providers have to filter

IP prefixes in incoming updates

Return Traffic Issue

Upstream AS

Another Customer

Primary ISP

 Customers can only influence their outgoing traffic,

not the return traffic

must also perform proper route selection

Multi-Homed Customer Requirement

Summary

BGP must support the following mechanisms:

– Route selection based on BGP neighbors

– Route selection based on numbers in the

AS-path

– Filters based on AS-numbers in the AS-path

– Filters on IP prefixes

After completing this section, you should be able to

perform the following tasks:

– Describe the issues in multi-homed BGP networks

– Describe the need to influence BGP route selection

– Describe the need for BGP filters

–List three potential customer routing policies

–What are the issues an ISP with multi-homed customers is facing?

Transit Autonomous System Functions

Upon completion of this section, you will be able to

perform the following tasks:

– List the functions of a transit autonomous system

– Describe the external route propagation through

Transit Autonomous System Tasks

 Propagate routes between remote Autonomous

Routes between autonomous systems are always

exchanged via External BGP (EBGP) The only protocol that can transport all BGP

attributes across the backbone is BGP inside

autonomous system, called Internal BGP (IBGP)

IBGP session must be established between transit

Packet Forwarding in an Autonomous

Conclusion#1: Rtr-C needs external routes for proper packet forwarding

Conclusion#2: Rtr-C must receive BGP routes

Packet from AS 14 toward AS 12 is received by Rtr-D

Rtr-D forwards the packet toward Rtr-A as dictated

by an IBGP-learned entry in its IP routing table

How will RTR-C forward the packet?

Packet Forwarding in an Autonomous

System

 All core routers must have all external routes

 Core routers must receive BGP routes

–Redistribution of BGP routes into IGP is not scalable

–Default routing is not applicable in transit AS core

After completing this section, you should be able to

perform the following tasks:

–List the functions of a transit autonomous system

–Describe the external route propagation through transit AS

–Explain the need for internal BGP inside the transit AS

–Explain the need for deploying IBGP on all core routers

Internal BGP

Upon completion of this section, you will be able to

perform the following tasks:

–List the differences between internal BGP and external BGP

–Describe the AS path processing in internal BGP

–Explain the need for BGP split horizon and its implications

–Understand the next-hop processing in internal BGP and its implications

AS Path Processing in IBGP

EBGP

session

IBGP session

AS path as received from

external neighbor is not

changed on IBGP sessions

other IBGP peers

Result: Full mesh of IBGP sessions is required

for proper IBGP update propagation

prevent BGP routing loops.

IBGP Full-mesh

 Full mesh of IBGP sessions has to be established

between all BGP-speaking routers in the AS for proper

IBGP route propagation

TCP sessions, physical full mesh is not required

EBGP update IBGP update

Incoming EBGP update is directly

propagated from ingress router to all

BGP-speaking routers in the AS

EBGP update

Incoming IBGP update is further

propagated to next AS

IBGP Full-mesh

IBGP Neighbors

 Due to IBGP full-mesh requirements, IBGP

neighbors are usually not directly connected

? Which interfaces shall you choose as the

source and destination addresses of IBGP TCP

EBGP session IBGP session

Physical connections

(for example, WAN

links)

IBGP Neighbor Sessions

Always run your IBGP sessions between loopback

IBGP Next-hop Processing

IP address

1.0.0.1

1.0.0.2

3.0.0.2 3.0.0.1

Network X is announced with the next-hop 1.0.0.1

Transit Network Using External

Next-hops

 All EBGP peers must be reachable by all

BGP-speaking routers within the AS

 EBGP next hops shall be announced using IGP:

–Redistribute connected interfaces into IGP at the edge routers or

–Include links to EBGP neighbors into IGP and make them passive interfaces

Transit Network Using Edge Routers as

Next-hops

Alternate design: Next-hop processing is modified at

the edge routers

–Edge routers announce themselves as the next-hop

in IBGP updates

–No redistribution of external subnets is necessary

–This design might result in suboptimal routing if

you have multiple paths to a neighbor AS

Use default next-hop processing if at all possible

Transit Network Using Edge Routers as

Next-hops

Alternate design: Next-hop processing is modified at

the edge routers

–Edge routers announce themselves as the next-hop

in IBGP updates

–No redistribution of external subnets is necessary

–This design might result in suboptimal routing if

you have multiple paths to a neighbor AS

Use default next-hop processing if at all possible

Change the Next-hop Processing at Edge

Routers

 Bypass the BGP next-hop processing and announce

the local IP address as the BGP next hop in outgoing

updates sent to the specified neighbor

 Has to be set on all IBGP neighbor to fully bypass IBGP

next-hop processing

neighbor ip-address next-hop-self

router(config-router)#

X (1.0.0.1)

Next-hop is set to the

loopback address when

Differences Between EBGP and IBGP

Sessions

 No BGP attributes are changed in IBGP updates

 Due to BGP split horizon, routes learned from IBGP

peer are not advertised to other IBGP peers

 Local-preference and MED attributes are only

propagated over IBGP sessions

 EBGP peers are directly connected, IBGP peers are

usually distant

 Route selection rules slightly prefer EBGP

routes

Route Selection Slightly Favors EBGP

External route is preferred

Identical routes are received

from internal and external

peer

Whenever identical routes are received from IBGP and

EBGP peers, the route from EBGP peer is preferred

After completing this section, you should be able

to perform the following tasks:

– List the differences between internal BGP and external BGP – Describe the AS path processing in internal BGP

– Explain the need for BGP split horizon and its implications – Understand the next-hop processing in internal BGP and its implications

Packet Forwarding in Transit Autonomous

Systems

Upon completion of this section, you will be able to

perform the following tasks:

–Explain the packet forwarding requirements in a transit AS

–Explain recursive lookup in IOS

–Explain the need for IGP in a transit backbone running BGP on all routers

–Explain interactions between BGP and IGP

Packet Forwarding in an Autonomous

System

 All core routers must receive external routes

-they must run BGP

– The only scalable design, route redistribution into IGP is not scalable

Router on a transit path needs to know all external destinations for proper packet forwarding

Packet Forwarding for External

Destinations

 Routes learned via BGP don’t have outgoing interface associated

with them in the routing table

 Recursive lookup is performed to forward IP packets toward external

destinations

wg3pe2# show ip route 128.51.0.0

Routing entry for 128.51.0.0/16

Known via "bgp 5", distance 200, metric 0

Tag 99, type internal

Last update from 192.168.5.1 01:21:25 ago

Routing Descriptor Blocks:

* 192.168.5.1, from 192.168.5.1, 01:21:25 ago

Route metric is 0, traffic share count is 1

AS Hops 5 wg3pe2# show ip route 192.168.5.1

Routing entry for 192.168.5.1/32

Known via "ospf 1", distance 110, metric 1563, type intra area

Redistributing via ospf 1, rip

Advertised by rip metric 3

Last update from 192.168.5.17 on Serial1/0.121, 02:09:15 ago

Routing Descriptor Blocks:

* 192.168.5.17, from 192.168.5.1, 02:09:15 ago, via Serial1/0.121

Route metric is 1563, traffic share count is 1

BGP next-hop

No outgoing interface

Route toward BGP next-hop

Outgoing interface

Recursive Lookup in IOS

1.5.4.1 Ethernet 0 1.2.3.0

OSPF

- Ethernet 0 1.5.4.0

conn.

Prefix

/24 /24

ARP cache

MAC address

L2 header

1.2.3.4 0c.00.11.22.33.44 ARP cache lookup is performed

to build layer-2 header Lookup result is stored in the switching cache

Recursive Lookup in IOS

 Traditional IOS switching mechanisms perform

recursive lookup when forwarding the first packet

– Fast switching, Optimum switching

 Cisco Express Forwarding (CEF) pre-computes the

forwarding table

– All recursive lookups are performed while the forwarding table

is built

Recursive Lookup in IOS

 Traditional IOS switching mechanisms perform

recursive lookup when forwarding the first packet

– Fast switching, Optimum switching

 Cisco Express Forwarding (CEF) pre-computes the

forwarding table

– All recursive lookups are performed while the forwarding table

is built

Routing Protocols in a Transit

Autonomous System

 With IBGP running on all core routers, is IGP still

needed in the core?

• IGP is needed to resolve BGP next hops and

perform fast convergence after a failure in the

All core routers

are running IBGP

Autonomous System

Core routers need to run BGP and IGP

 BGP shall carry all external routes

 IGP shall only propagate BGP next-hops and

other core subnets

 All customer routes shall also be carried in BGP

– Reduces IGP topology database

– Removes customer-caused route flaps from IGP:

IGP becomes more stable

Interactions Between BGP

and IGP

Ideally, there would be no interaction between BGP and

IGP

– BGP carries external and customer routes

– IGP carries only core subnets

– IGP is not affected by external route flaps

– BGP is not affected by failures internal to the network as long as

the BGP next-hop remains reachable

– The only link between BGP and IGP should be the recursive

lookup

Interactions Between BGP

and IGP

Sometimes, BGP and IGP will propagate the same route

– Usually due to bad network design – In this case, routes are believed in EBGP/IGP/IBGP order based

on administrative distances of the routes

Routing protocol Default administrative

distance

Caveats of BGP/IGP Interaction

If an IGP route is learned through EBGP, EBGP-route will

After completing this section, you should be able

to perform the following tasks:

– Explain the packet forwarding requirements in a transit AS – Explain recursive lookup in IOS

– Explain the need for IGP in a transit backbone running BGP on all routers

– Explain interactions between BGP and IGP

Configuring Transit Backbone with IBGP

Upon completion of this section, you will be able to

perform the following tasks:

–Configure IBGP neighbors

–Configure IBGP sessions between loopback interfaces

–Configure additional BGP parameters required for successful IBGP operation

–Change the administrative distance of BGP routes

–Identify the scalability limitations of IBGP-based backbones

neighbor ip-address remote-as AS-number

router(config-router)#

• Configures BGP neighbor

• The AS number configured determines whether the

session is EBGP session (neighbor AS is different from

local AS) or IBGP session (same AS number)

Configuring IBGP Neighbors

neighbor ip-address description text

router(config)#

• Attaches optional description to a neighbor

neighbor ip-address update-source interface

router(config-router)#

• Configures the source interface for the TCP session

that carries BGP traffic

• For IBGP sessions, the source interface shall be a

loopback address

• Source address configured on one peering router must

match the destination address configured on the other

-BGP session will not start otherwise

• Make sure that your loopback interfaces are announced

in the backbone IGP

Configuring IBGP Sessions Between

Loopback Interfaces

no synchronization

router(config-router)#

• Disables synchronization between BGP and IGP

• Modern Transit Autonomous Systems do not need

synchronization as they don’t rely on redistribution of

BGP routes into IGP

• BGP synchronization has to be disabled in modern

Transit AS designs on all BGP routers

Configuring Additional BGP Parameters

Change the Administrative Distance of

BGP Routes

 Sets administrative distance for EBGP, IBGP and local

routes

 Applies only to routes received after the command has

been entered (similar to filters)

Defaults:

 EBGP routes have distance 20, IBGP and local routes

have distance 200

Defaults are usually OK, don’t change them

distance bgp external internal local

router(config-router)#