Bgp Advanced New

7/30/2019 Bgp Advanced New

http://slidepdf.com/reader/full/bgp-advanced-new 1/139

BGP – From Dinosaur to racecar

Webinar - 28 February 2012



© 2010 Cisco and/or its affiliates. All rights reserved. Cisco PublicGoogle December 2011:Advances in BGP 2

Agenda

§ Deployment Profiles

Summary of current service provider and enterprisecustomer BGP deployment profiles

§ New Developments A review of BGP recent enhancements and features

§ Scale & Performance Results

BGP RR and PE scaling data

§ Future Work

Upcoming BGP features and enhancements






Service Provider Profile

§ Most deployments use route reflector model

§ BGP deployed for L3VPN (VPNv4/6), L2VPN,

Internet (IPv4/6), and MVPN routing

§ Current BGP table sizes

Internet: ~415KVPN: ~1.5M

Approximately 10% YOY growth expected for both




Enterprise Profile

§ BGP deployed for large enterprise core networksrunning DMVPN, L3VPN over MPLS, and L3VPNover IP

§ L3VPN over IP exploding in enterprise environment§ L2VPN BGP is gaining momentum

§ Typical deployment scale in the range of a 50K+ routes reflected



© 2010 Cisco and/or its affiliates. All rights reserved. Cisco PublicBRKRST-3371: Advances in BGP 6

New Developments

§ Deployment Profiles

§ New Developments

§ Scaling & Performance Results


http://slidepdf.com/reader/full/bgp-advanced-new 7/139© 2010 Cisco and/or its affiliates. All rights reserved. Cisco PublicGoogle December 2011:Advances in BGP 7

New Developments

§ Scale & Performance

Increase scalability for existing hardware, newer RP cards,and new platforms

Faster convergence

§ Resiliency & High Availability

Increase robustness of BGP peering

Provide redundancy for routes and sessions

§ Features

Support for new functionality in the network



Scale & Performance Enhancements

§ BGP Scaling

Update Generation Enhancements

Parallel Route Refresh

Keepalive Enhancements

Adaptive Update Cache Size

§ PE Scaling

PE-CE Optimization

VRF-Based Advertise Bits

§ Route Reflector Scaling

Selective RIB Download





General Update Generation Enhancements

§ Optimize to improve convergence

New update generation process

Parcel work into discrete units

Peer-based update message queues

Inline freeing of transmitted update messages

Optimizing prefix based checkpointing

BGP Scale/Performance Enhancement

Update generation is the most important, time-critical task

Predictable CPU quantum

Efficient suspension/resumption of work

Simplified, efficient peer update message handling




§ Parallelize refresh and incremental updatesReal update group spawns a refresh update group to re-

announce BGP table


Significant delay (up to 15-30 minutes) seen in advertising

incremental updates while RR is servicing route refresh

requests or converging newly established peers

VRF provisioning triggers route refresh request from PE every

10 to 30 minutes at typical tier-1 service providers

Persistent BGP VPN issue on existing production

networks




§ Original update group handles new transient updates while refresh update group handles re-announcements

§ Refresh groups used to service newly established

peers


Version 0 Version X

Refresh Group Re-announcements Transient Updates

Table Versions of Prefixes

End-to-end convergence reduced from 15-30 minutes to 5-20seconds for typical tier-1 VPN service providers



Keepalive Enhancements

§ Insulate keepalive processing

Separate keepalive process to only handle keepalives

Priority queues for reading/writing keepalive/updatemessages

Optimizing keepalive timeout cases


Issue: Delayed processing of BGP keepalives often results in

session flaps for peers configured with aggressive keepalive

timers

Cascading outages and CPU/transient memory usage

Aggressive keepalive timers supported reliably under scaled/stressed conditions

Fixes unwanted session flaps and outages



Adaptive Update Message Cache Size

§ Scale up cache size appropriately considering

Amount of installed system memory

Number of peers in an update group

Type of peers in an update group

Address family of update group


Update message cache size throttles update groups during

update generation and controls transient memory usage

Fast convergence aided by large cache sizes

Old cache sizing scheme cant take advantage of expanded

memory available on new platforms



Adaptive Update Cache SizeBGP Scale/Performance Enhancement

Routers with more system memory get bigger cache sizes and

thereby queue more update messages

VPNv4 iBGP update groups have larger cache size

Update groups with large number of peers get larger update

cache

Faster convergence is the result



Scale & Performance Enhancements

§ BGP Scaling

§ PE Scaling

§ Route Reflector Scaling





VRF-Based Advertise Bits

§ Smart reuse of advertise bit space for VRFs

Prefixes in a VRF used to have advertise bit for every CEupdate group on the router

Bits only needed for CEs in the same VRF


Issue: Increased memory consumption when the number

VRFs was scaled on a PE router

For PE with 1000 VRFs, savings of about 120+B per prefix

Considerable memory savings allows greater prefix scaling








Scaling & Performance Release Matrix

12.2(31)SB

12.2(33)SB

12.2SRSRC, SRD

12.2XNXNC, XND

Component Code12.2SRE 12.2XNE 15.0x

Selective RIB

DownloadNo No No 12.2XNC Yes Yes Yes

PE-CE Optimization 31SB16 33SB6 No 12.2XND Yes Yes Yes

Update Generation

Task31SB14 No No No Yes Yes Yes

Parallel RouteRefresh

31SB14 No No No Yes Yes Yes

Keepalive

Enhancements31SB16 33SB6 No No Yes Yes Yes

Variable UpdateCache Size

31SB16 33SB6 No 12.2XND Yes Yes Yes

§ RR: 31SB, 12.2XN, component code

§ PE: 33SB, component code






BGP Resiliency/HA Enhancement

PIC Edge

Issue: Sub-second convergence is desirable. Presently, routingaround failures is not immediate, resulting in forwarding traffic loss at

the site of failure

§ PIC: Prefix Independent Convergence All prefixes using failed nexthop for forwarding shift tobackup in constant time

PIC Edge can update nexthop for 250K prefixes in < 500ms using 12.2(33)SRE

§ Current solution targets VPNs and IP edge routers

§ PIC Edge supports 2 cases: link and node failures






10.1.1.0/24VPN1Site#1

MPLSCloud

TrafficFlow10.2.2.0/24VPN1Site#2

PE1

PE2

PE3

PE4

CE1 CE2

Primary

Backup

RR

PIC Edge: Link ProtectionBGP Resiliency/HA Enhancement

§ PE3 has primary and backup path

Primary via directly connected PE3-CE2 link

Backup via PE4 best external route

§ What happens when PE3-CE2 link fails?




10.1.1.0/24VPN1Site#1

MPLSCloud


PE1

PE2

PE3

PE4

CE1 CE2

Primary

Backup

RR


§ CEF (via BFD or link layer mechanism) detects

PE3-CE2 link failureCEF immediately swaps to repair path labelTraffic shunted to PE4 and across PE4-CE2 link




10.1.1.0/24VPN1Site#1

MPLSCloud

TrafficFlow

10.2.2.0/24VPN1Site#2

PE1

PE2

PE3

PE4

CE1 CE2

Primary

Backup

RR


WithdrawrouteviaPE3

§ PE3 withdraws route via PE3-CE2 link

Update propagated to remote PE routers




10.1.1.0/24VPN1Site#1

MPLSCloud

TrafficFlow

10.2.2.0/24VPN1Site#2

PE1

PE2

PE3

PE4

CE1 CE2

Primary

Backup

RR


WithdrawrouteviaPE3

§ BGP on remote PEs selects new bestpath

New bestpath is via PE4

Traffic flows directly to PE4 instead of via PE3





PIC Edge: Edge Node Protection

10.1.1.0/24VPN1Site#1

MPLSCloud


PE1

PE2

PE3

PE4

CE1 CE2

Primary

Backup

RR

§ PE3 configured as primary, PE4 as backup

PE3 preferred over PE4 by local preference

CE2 has different RDs in VRFs on PE3 and PE4

PE4: advertise-best-external, to advertise route via PE4-CE2 link

PE1: additional-paths install, to install primary and backup path




10.1.1.0/24VPN1Site#1

MPLSCloud

TrafficFlow

10.2.2.0/24VPN1Site#2

PE1

PE2

PE3

PE4

CE1 CE2

Primary

Backup

RR


§ PE1 has primary and backup path

Primary via PE3

Backup via PE4 best external route

§ What happens when node PE3 fails?





10.1.1.0/24VPN1Site#1

MPLSCloud

TrafficFlow

10.2.2.0/24VPN1Site#2

PE1

PE2

PE3

PE4

CE1 CE2

Primary

Backup

RR


PE3 s/32hostrouteremoved

fromIGP


§ IGP propagates loss of PE3s /32 host route across

the core to remote PEs









Slow Peer Management

Issue: Slow peers in update groups block convergence of

other update group members by filling message queues/

transmitting slowly

Persistent network issue affecting all BGP routers

§ Two components to solution

Detection

Protection

§ Detection

BGP update timestamps

Peer s TCP connection characteristics







VRF-Based Dampening

§ BGP route dampening is now configurable per-VRF instead of for whole VPN table

§ Allows service provider to configure dampening

parameters on an individual customer basis

§ Gives operators more flexible control of unstablecustomer routes in service provider network






Graceful Restart Changes

§ Configurable RIB failsafe timer

New CLI parameter

Allows users to tune value according to scale requirements

§ GR configurable per neighbor

§ New address family support

MDT

L2VPN





Resiliency & HA Release Matrix

12.2(31)SB

12.2(33)SB

12.2SRSRC, SRD

12.2XNXNC, XND Component Code12.2SRE 12.2XNE 15.0x

PIC Edge No No No No Yes

Hardware Yes

Software Yes

Software


31SB16 No No No Yes Yes Yes

VRF-Based Dampening No No No No Yes Yes Yes

GR/NSR Changes 31SB16 33SB633SRD3

(No NSR)No Yes Yes Yes




BGP Features

§ 4-Byte AS Support

§ Automated Route Target Filtering

§ BGP L3VPN Over MGRE

§ Dynamic Neighbor Discovery

§ BGP L2VPN Autodiscovery




BGP Features (Cont’d)

§ Enhanced Route Refresh

§ Route Consistency Checker

§ BGP MVPNs

§ BGP Origin Validation

§ BGP Graceful Shutdown






§ 2B ASN pool being exhausted

§ RIRs allocating 4B ASNs by default

§ IOS BGP extended to support RFC 4893

4B ASN capability negotiated when opening session

Support for mixed 2B/4B AS deployments

4-Byte AS SupportBGP Feature




§ Increased VPN service deployment increases loadon VPN routers

10% YOY VPN table growth

Highly desirable to filter unwanted VPN routes

§ Multiple filtering approaches

New RT filter address family

Extended community ORF

Automated Route Target FilteringBGP Feature






PE-1!

PE-2!

PE-3!

PE-4!

RR-1! RR-2!

VRF- Blue!

VRF- Red!

VRF- Red!VRF- Green!

RT-Constraint:!NLRI= {VRF-Blue, VRF-Red}!

RT-Constraint:!NLRI= {VRF-Green, VRF-Purple}!

RT-Constraint:!NLRI= {VRF-Purple, VRF-Blue}!

RT-Constraint:!NLRI= {VRF-Red, VRF-Green}!

RT-Constraint:!NLRI= {VRF-Blue, VRF-Red, VRF-Green}!

RT-Constraint:!NLRI={VRF-Green, VRF-Purple, VRF-Blue}!

VRF- Green"

VRF- Purple"

VRF- Purple"VRF- Blue"

Automated Route Target FilteringBGP Feature

§ Improves PE and RR scaling and performance bysending only relevant VPN routes




BGP L3VPN Over MGRE

§ Providers want to offer VPN service withoutusing MPLS

MPLS is powerful, but complex

Replace MPLS with MGRE tunnel for forwarding

§ Earlier tunnel solution is complex to configure onPE

Manual tunnel creation (source interface, mode)

RIV (Resolve-in VRF)

Static default route to tunnel in RIV

Route map sets nexthop in RIV for recursive lookup

BGP Feature




§ New feature streamlines PE config

User creates encapsulation profile

Automatic BGP discovery of source and remote endpoints

BGP inbound route map associates routes with profile

Profile used to set up forwarding

§ Tunnel endpoints created/destroyed dynamically

§ No RIV, no static default route, no recursive lookup,simple config

BGP L3VPN Over MGREBGP Feature




§ BGP passively listens to configured address range for incoming sessions

§ BGP neighbor dynamically createdRemote address is source of TCP connection

Config template associated with listen range is applied

§ ProvisioningNo manual config necessary on hub for new clients

Significant reduction in config overhead

Dynamic Neighbor DiscoveryBGP Feature






§ Route Refresh modified to send Refresh Start-of-RIB and Refresh End-of-RIB

§ Force cleanup of stale routes in ADJ-RIB-IN after receiving Refresh End-of-RIB

Provided timer support in case Refresh End-of-Rib is not

received

Provided timer support to generate Refresh EOR

§ Allows cleanup of stale routes after route refresh is

done

BGP Feature

BGP Enhance Route Refresh




§ Provides consistency checking of BGP nexthopsand Labels

Same nexthops across different paths should have samelabels for a given prefix

§ Check outbound policies against ADJ-RIB-OUT

§ CLI to configure and run consistency checker

§ Force Route Refresh to fix issues or notify operator

§ Ability to detect stale nexthops or labels

BGP Feature

BGP Route Consistency Checker




§ Support for BGP based MVPNs

Support for BGP AD and C-multicast routing within an AS

§ Next release to provide an Inter-AS support

§ Support for SAFI 129 (VPN equivalent of SAFI 2)

§ Helps avoid PIM soft state refresh in the provider network

§ Allows MVPN to scale by using standard BGPbased VPN filtering mechanism

BGP Feature

BGP MVPNs




§ Origin Validation for E-BGP routes

Next release to cover origin validation for locally sourcedroutes

§ Support client functionality of RPKI RTR protocol

Separate database to store record entries from the cache

§ Support to announce path validation state to IBGPneighbors using a well known path validation stateextended community

§ Modified route policies to incorporate pathvalidation states

BGP Feature

BGP Origin Validation






§ Designed to be used at Internet Exchanged points

Alternative to EBGP full mesh

§ Does E-bgp route reflection without adding its own AS to the ASPath

§ Support for IPv4 and IPv6 afi

§ Allow customized bestpaths for RS Clients

Policy dictates which path gets to be announced to RS

clients

§ Allows Internet Exchange points to scale its E-BGPpeering by avoiding full mesh

BGP Feature

BGP Route Servers

C C d




Feature Release Matrix

12.2XNXNC, XND

Component CodeS Train T Train

4-Byte AS Support Yes 12.2(33)SRE 15.0(1)M

Dynamic Neighbors No XE3.1/15.0(1)S 15.1(2)T

Automated Route Target Filtering No XE3.2/15.1(1)S 15.2T

BGP L3VPN over MGRE No XE3.1/15.0(1)S Yes

BGP L2VPN AD IAS Option B No XE3.4/15.1(3)S Yes

BGP Enhance Route Refresh No XE3.4/15.1(3)S 15.2(3)T

BGP Route Consistency Checker No XE3.3/15.1(2)S 15.2(3)T

BGP MVPNs No XE3.6/15.2(2)S 15.2(3)T

BGP Origin Validation No XE3.5/15.2(1)S 15.2(4)M

BGP Graceful Shutdown No XE3.6/15.2(2)S 15.3(1)T

BGP Route Server No XE3.3/15.1(2)S 15.2(3)T








ASR1000RP1 (2GB)

ASR1000RP1 (4GB)

ASR1000RP2 (8GB)

ASR1000RP2 (16GB)

IPv4

Routes

2M* 7M* 12M* 29M*

VPNv4

Routes

2M 6M 10M 24M

IPv6

Routes

500K 1.5M 3M 7M

VPNv6

Routes

2M 5M 9M 21M

BGP

Sessions

4000 4000 8000 8000

*Tested with BGP Selective RIB Download feature for IPv4 for dedicated RR. This feature will be

implemented for IPv6 address family in future releases.

ASR1K RR Scale Results




RR Software Recommendations

§ 7200 NPE G1/G2

12.2(31)SB18

12.2(33)SRE

§ ASR1K

12.2(33)XNC

12.2(33)XND

12.2(33)XNE




C10K PRE2/PRE4 PE Scalability

§ Testing with PRE2550K total VPNv4, VPNv6 prefixes with convergence under 10 minutes

1200 eBGP sessions, 4 iBGP sessions, no NSR/GR

Should scale higher depending on prefix/attribute mix

§ Testing with PRE4

800K-1M total VPNv4, VPNv6 prefixes

Same profile as listed above

ASR1K PE Scalability




ASR1K PE ScalabilityRP1/ESP10 RP2/ESP20

VRF 1K 4K

VPNv4 routes (use per VRF label allocation, assume 20%

local routes and 80% routes learned from remote PEs)1M (RP1 4GB)

1M (RP2 8GB)

4M (RP2 16GB)

MPLS label space 1M 1M

VLAN (per port/per SPA/per system) 4K/8K/32K 4K/8K/64K

ATM PVC (per port/per SPA/per system/with OAM enabled) 1K/3K/4K/1K 1K/3K/4K/1K

eBGP PE-CE sessions 4K 8K

OSPF PE-CE sessions 1K 1K

EIGRP PE-CE sessions 1K 1K

RIP PE-CE sessions 1K 4K

Link/Targeted LDP sessions 1K 2K

Number of Traffic Engineering Tunnel Head 1K 1K

Number of Traffic Engineering Tunnel Midpoint 15K 15K

ATM CRoMPLS AC/PW (VC/VP mode)1K (max 200 VP

mode)1K (max 200

VP mode)

EoMPLS AC/PW 8K 16K

Unique QOS service policy/class maps per service policy 4K/256 4K/256

ACL/ACE 4K/50K 4K/100K

Non-drop rate (with uRPF, security ACL and ingresspolicing on VLAN subinterfaces)

8Mpps/10Gbps 10Mpps/20Gbps

FIB download/Convergence speed (prefixes/second) 1500 5500

Uni-dimensional Scale





© 2010 Cisco and/or its affiliates. All rights reserved. Cisco PublicBRKRST-3371: Advances in BGP 65

Backup Slides

A d



© 2006 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 66

Agenda

q XR BGP Feature Set - Current releases

q XR BGP new Features deep-dive

- Multi-instance/Multi-AS, RT-Constrain, Add-path, PIC,

3107 Labeled architecture, Attribute Error handling.

q XR BGP Roadmap and Q& A






IOS-XR 3.8.X Release Features

Major Features Deployment Knobs Internal

1. BGP NSR

2. BGP Session Scale

1700 (PRP-2/CRS)

2000 (C12k/PRP-3)3. BGP 3107

Architecture

1. IPv6 over IPv4 session2. NH change

3. Reset Weight on import4. Disable connected check

5. Per neighbor enforce-first as

6. Ability to change anyattribute on Route-reflector

7. Support for multiple cluster-id in BGP

8. Allow-as-in changes to

avoid hard reset

9. Route-reflectionFunctionality under VRF

10. Min-acceptable hold-timer

knob

11. Local-as replace-as knob

1. show bgp prefixdetail

2. Net timestamp within show bgp prefix

3. “show bgp

sessions” command4. Show bgp nsr

5. Show bgp table<afi> <safi>

6. Additional VPN

stats into o/p of

“show bgp processperformance detailcommand”






1. BGP PIC Unipath2. BGP Best-External

3. BGP Session Scale

• 1700 (PRP-2/CRS)

• 2400 (C12k/PRP-3)

4. Ability to support

aggressive timers with

large Session Scale5. L2VPN BGP Auto-

discovery with BGP/LDP

Signaling

6. Implementation of v0 of

draft – Error handling for

Optional Transitive

Attributes

1.

BFD for directly connectediBGP peers

2. BGP BFD for IPv6 Sessions

3. IPv6 eBGP Multipath Support

4. Per VRF MDT Source

Selection Capability

5. Ability to configure sub-second

MRAI timer 6. BGP Local-as dual-as knob

7. MVPN w/ CsC

8. BGP NBR Adj change msg

enhancement to show more

info

9. 6PE per VRF/per-CE label

allocation (3.9.2)

1. Async Socket APIs toimprove BGP-TCP

interaction

2. Import/Label thread

optimizations

3. Control plane batching

4. Ltrace optimization

5. BGP MIB Perf improvements

(Caching / Batching)

6. BGP MIB traps

batching

7. Moved BGP MIB

implementation to RFC

4273 from draft

8. Added support for

additional afi/safi

9. RPL optimization in

case policy name is

different but content is

the same

IOS XR 4 0 X Release Features






1. BGP Add-path

2. Support for AIGP3. AIGP to Cost-community

conversion

4. AIGP to MED conversion

5. MVPN Hub & Spoke

support

6. BGP changes for PIC-

Edge for labeled unicast

(default VRF)

7. X86 Support for CRS-3

8. Parallel update-gen

during route-refresh

9. Native as-path matches in

as-set10. Deterministic regex

engine porting & usage

11. IPv6 Peer table MIB and

IPv6 trap support

12. Netflow support for

L3VPN and IPv6

1. IOS message when OPEN

with unsupported hold-timer value received

2. ORF optimization for update-

group allocation

3. Next-hop self knob on RR

4. eBGP NH unchanged knob

5. BGP remove-private-as

enhancement

6. Support for prefix-set or

route-policy names with

colons in it

7. XML support for “show rpl”

8. IGP metric change

propagation timer knob9. 6PE iBGP PE-CE Support

10. 6PE per VRF/per CE label

11. Allow-as-in and as-override

knobs for default VRF

sessions (4.0.2)

1. Show command

enhancement for RIBinstall stats/flags

2. Commit replace

optimization

3. BGP attribute ID

allocation change

4. Support for 4-byte-AS in

the Cisco






Update-generation Optimizations

§ Incremental Update-generation with RT Constrain

§ Only send relevant updates in response to a route refreshrequest instead of the entire bgp table

§ Parallel update-generation

§ Ensures that bgp convergence is not affected on accountof servicing route-refresh requests.

§ Prioritizes prefix updates over the refresh so that we do notsee head of the line blocking.

§ Optimized CE update-generation

§ Scoped walk of the CE VRF table, instead of a entire VPNwalk used to generate updates. Distinct PE/CE advertisebits in use




Multi instance BGP

and Multi-AS Support(IOS-XR 4.2.0)

What is Multi Instance BGP?




What is Multi-Instance BGP?

§ A new IOS-XR BGP architecture to support multiple instancesalong the lines of OSPF instances

§ Each BGP instance is a separate process running on thesame or a different RP/DRP node

§ The BGP instances do not share any prefix table betweenthem

§ No need for a common adj-rib-in (bRIB) as is the case withdistributed BGP

§ The BGP instances do not communicate with each other anddo not set up peering with each other

§ Each individual instance can set up peering with another router independently

What is Multi-AS BGP?




What is Multi-AS BGP?

§ It will be possible to configure each instance of a multi-

instances BGP with a different AS number § Global address families can’t be configured under more than

one AS except vpnv4 and vpnv6

§ VPN address-families may be configured under multiple AS

instances that do not share any VRFs

Why Multi-Instance/Multi-AS?




Why Multi Instance/Multi AS?

§ It provides a mechanism to consolidate the servicesprovided by multiple routers using a common routing

infrastructure into a single IOS-XR router § It provides a mechanism to achieve AF isolation by

configuring the different AFs in different BGP instances

§ It provides a means to achieve higher session scale

by distributing the overall peering sessions betweenmultiple instances

§ It provides a mechanism to achieve higher prefix scale(especially on a RR) by having different instancescarrying different BGP tables

§ IOS-XR CRS Multi-chassis systems can be usedoptimally by placing the different BGP instances ondifferent RP/DRPs

Deployment – Route-reflector




Deployment Route reflector

Rack1 Rack2 Rack3 Rack4

RP L

C

L

C

BGP(VPN)

RPRPRP

BGP(IPv4)

L

C

L

C

L

C

L

C

L

C

DRP

BGP(IPv6)

BGP(VPNv6)

Deployment – AF Isolation




Deployment AF Isolation


RP LC LC

BGP(VPNv4)

RPRPRP

BGP(VPNv6)

LC LC LC LC LC LC

BGP(IPv4)

BGP(IPv6)

Deployment – Service Integration




Deployment Service Integration


DRP LC LC

BGP AS1

(L3VPN)

DRPDRPDRP

BGP AS2

(L2VPN)

LC LC LC LC LC LC

BGP AS3

(Internet)

Deployment – Session Scale increase




p y

Rack1

RP LC LC

BGP AS1

(L3VPN)

DRP

BGP AS1

(L3VPN)

BGP AS1

(L3VPN)

PE-CEsessions

PE-CEsessions

PE-CEsessions

RR



Peering Example




g p

§ Multi-instance PE1 peering with a multi-instance RR1 and a regular BGP on RR2

§ Each BGP instance on PE1 has a peering with the correspondinginstance of BGP on RR1

§ Separate loopbacks needed on RR2 due to use of multi-instance BGP

PE1

RR2 (backup)

RR1 (Active)

BGPVPNv4

BGPVPNv4

BGPIPv4

BGPIPv4

BGP

10.0.0.1

10.0.0.2

20.0.0.1

20.0.0.2

30.0.0.1

30.0.0.2




RT Constrain and

Legacy PE SupportIOS-XR4.1.0

Subtitle

RT-Constrain Feature Overview




RT-Constrain Feature Overview

§ In L3VPN, PE routers use Route Target extended communities tocontrol the distribution of routes into the destination VRFs. Thisenables the separation of the VPNs.

§ It is common for PEs to receive more than the routes they areinterested in and then filter out the unwanted routes for VPNs thatthey are not connected to.

§ This results in waste of router resources in cases where VPNmembership is sparse (not many PEs are connected to the sameVPN). The sender generates and transmits a routing update and thereceiver has to filter out the unwanted routes.

§ It would be beneficial to avoid the generation of such route updates inthe first place.

RFC 4684 (Constrained Route distribution or RT constrain)




RFC 4684 (Constrained Route distribution or RT constrain)

§ PEs send RT membership information to RR (carried in a new

SAFI in BGP)

§ RR creates multiple filter groups (one per PE) corresponding toRT membership of PEs

§ RR sends to PEs only the routes for RTs configured on the PEs

PEs receive and filter less routes (less processing overhead)

èimproved scale & stability

§ RR collects the RT membership information from its clients andadvertises that set to the neighbouring RRs

§ RR receives and stores only the routes for all the RTs that PEsin its region are interested in

RRs store and process less routes

èimproved scale & stability

Advantages




Advantages

§ Reduce load on PE (nothaving to receive all networkroutes and filter)

§ Reduce load on RR (nothaving to receive and store

all network routes)

§ Improved stability due toreduced load on RR and PE

Region1

PEPE

PE

PE

PEPE

RRplane1

RRplane2

rt membership NLRI

Region2

PEPE

PE

PEPE

PE

RRplane1

RRplane2

RT i I l i f




RT constrain – Implementation features

§ Single update-generation walk for the neighbors with commonoutbound characteristics. Will not increase number of update-groups on RR.

§ Policy / Filtering optimizations for efficient filtering

§ Incremental Update generation sends only relevant delta VPNroutes to peer after a new RT update is received

§ Support for default RT announcement for PEs to avoid having tostore membership RT information

§ Automatic default RT to iBGP peer if one of the RRC is not RT-constrain capable

Migration path



© 2006 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialSA915 – Confidential 88

Migration path

§ RT constrain requires PE to send RT membershipinformation to the RR using NLRIs

– New code required on PE to do this

§ RR creates a RT filter list based upon the RT

membership information received from PE. It propagatesthis list to other RRs in the IBGP mesh

– New code required on RR to do this

§ Thus RT constrain requires both RR and PEs be

upgraded

Limitations




Limitations

§ Vanilla RT constrain doesn’t support PEs that are notupgraded, a.k.a, legacy PEs

Legacy PEs cannot signal RT membership information to the RRautomatically

Thus Legacy PE will have to receive and filter routes from ALL other

RTs even though it is not interested in them

§ Even if one PE doesn’t get upgraded, the corresponding RRhas to store ALL routes for the entire network (or plane)

§ Thus benefit seen on RR only if ALL PEs in the cluster areupgraded

§ 4.1 XR implements legacy PE support in addition to RFC4684 which does not require all PEs to be upgraded

Legacy PE support – Solution description




Legacy PE support – Solution description

§ Use existing VPN advertisement mechanism to convey

RT membership from the legacy PEs

§ Requires new configuration step on those PEs

§ Upgraded PEs advertise RT constrain NLRIs

§ RR processes both advertisement mechanisms of RTmembership information(from legacy and upgraded PEs)

§ Requires new code on the RRs to build RT filter list from bothadvertisement mechanisms

§ RRs translate the legacy PE RT membership informationto equivalent RT constrain NLRIs to propagate to other RRs

L PE t




Legacy PE support

Region1

PEPE

PE

PEPE

PE

RRplane1

RRplane2

Legacy PEs (propagates RT membershipusing VPN routes with a special community.Receive reduced set of routes from RRs) after filtering

Upgraded PEs (propagates RT membershipinformation using rt-filter SAFI. Receivereduced set of routes from RRs after RT filtering)

RR doesn’t propagate Legacy PE VPNroutes to iBGP peers – RR sends equivalentconverted RT SAFI NLRI



Legacy PE support – Illustration




• Each PE generates special routesattaching Import RTs for each VPNconfigured. The RD is configured tobe the same value across all legacyPEs

• The RR Identifies A/B by thereserved CV that has been attached

• Based upon the commonality of A/Bs the RR creates a set of filters tobe applied to each session that anA/B was received on.

PE3

PE2 RR

PE1 VPNA RT 1,1VPNB RT 2,2VPNC RT 3,3

VPNA RT 1,1VPNB RT 2,2VPNC RT 3,3

VPNA RT 1,1VPND RT 4,4VPNE RT 5,5

A/B:RD1 1,4,5 CV-C

A/B:RD1 1,2,3 CV-C

A/B:RD 1,2,3 CV-C

Legacy PE support – Illustration




BGP Add-path

IOS-XR4.0.0

Add h i XR




Add-path in XR

§ Add-path:IETF add-path draft: draft-ietf-idr-add-paths-02

§ Goal: to improve path diversity in BGP topologies

Assumption: multiple paths to the same prefix are generally available at

the edge of the networkMultiple analyses show they do

§ Application

Fast Connectivity Restoration / PIC

Load balancing

Eliminate route oscillation

Churn reduction

backup-path-RR

PE3

RR1

Z/p

PE1

PE2Z/p PE2

Z/p PE1

Z/p PE1Z/p PE2

Problem Data hiding




Problem: Data hiding

∝

§ Path reduction at two places:

Less preferred border (AS or confed) routers don’t announce their paths to iBGP

RRs (or confed-ebgp peers) hide all but the best path

§ Thus ingress routers most often know about one exit point only

§ When that exit point fails, traffic loss proportional to control planeconvergence

Local repair techniques can’t get triggered

§ Not knowing about more exit points also means the ingress

routers can’t do load balancing§ Not having path diversity has other issues as well:

Route oscillation: a protocol bug



Add path draft overview




Add-path draft overview

§ Extend NLRI format to include path-ID (so that multiplepaths for the same prefix can be advertised).

§ Path-ID is application specific, but mostly an opaque IDthat is pair-wise

id 1:z/p ≠ id 2 :z/p

§ Capability negotiation for add-path support per [AFI,SAFI] along with a send/receive flag for each

Ingress routers most often need the support for only receivingmultiple paths

Implementing the “receive” part is quite straightforward

Prefix

LengthPath ID

Prefix

Length

Applications




Applications

§ Fast convergence / connectivity restoration – As theingress routers have visibility to more paths, they canswitch to the backup paths faster once the primary pathgoes away. Requires backup paths to be sent.

§ Load balancing – As the ingress routers have visibilityto more paths, they can do ECMP on multiple paths.Requires either backup paths or all paths to be sent.

§ Churn reduction – since alternate paths are available,

withdraws can be suppressed (implicit update).§ Route oscillation – see RFC 3345 for scenarios.

Requires group best paths (in some cases all paths) tobe sent.

Implementation: what does it change?




Implementation: what does it change?

§ What paths to advertise? (when we don’t want toadvertise all)

Selecting backup paths / second-best

Selecting group bests

§ Update generation

Adj-RIB-Out is per-prefix today since only best path is sent

Needs change to advertise multiple paths

§ Update receptionControl plane: process multiple instances of prefix, selectsecond-best

Add th l ti d b t




Add-path: selecting second-best

Select best

Remove all paths whose next-hop == best’s (including best)

Run bestpath selection again on the remaining paths to selectbackup

1

2

3

Simple rule

CLI




CLI

§ Global command, per address family, to turn on add-path in BGP

It can optionally accept a route policy where the policy matcheson prefixes and sets one of the following:

Select and send backup paths (& how many)Select and send group-best paths

Send all paths

router bgp 7018address-family vpnv4 unicast

additional-paths install backupadditional-paths advertiseadditional-paths receiveadditional-paths selection route-policy xx

iBGP and Add path




iBGP and Add-path

§ BGP speakers within an AS must have a consistentrouting view, otherwise forwarding loops can occur

§ With add-path, it is thus important to maintain thatproperty by the senders disseminating the same set of

paths to each IBGP receiver § Each BGP speaker (receiver) can independently run

the decision process with the consistent view and loopfreedom will be guaranteed

Cost




Cost

§ Memory overhead• Additional memory overhead on the receiving PE due to

additional paths

• Additional memory overhead of maintaining per path Adj-Rib-Out information

§ CPU cycle increase for update processing

• Update reception at edge routers increases proportional to#additional paths

•

Update generation at aggregators also increasesproportional to #additional paths

§ CPU cycle increase for other internal processing as well

E.g. Next-hop trigger




BGP PIC-Edge

Subtitle

Feature Overview



© 2009 Cisco Systems, Inc. All rights reserved.Cisco Confidential 106NAG 09

Feature Overview

§ Internet Service Providers provide a strict SLAs to their

Financial and Business VPN customers where they needto offer a sub-second convergence in the case of Core/Edge Link or node failures in their network

§ Prefix Independent Convergence (PIC) has beensupported in IOS-XR for a while for CORE link failures aswell as edge node failures

§ BGP Best-External project provides support for advertisement of Best-External path to the iBGP/RRpeers when a locally selected bestpath is from an internal

peer § BGP PIC Unipath projects provides a capability to install a

backup path into the forwarding table to provide prefixindependent convergence in case of the PE-CE linkfailure

End to End Service Availability – Customer Uptime



© 2006 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialEDCS-720331 107

CE2

CE1

CE3

RR1 RR2

BGP

IP/OSPF/MPLS/TE-FRR

Improved

Failure Detection

L1/2 OAM & BFD

Edge Domain BGP PIC – Sub-second convergence

Core Domain & GETS

TE FRR

Improved

Failure Detection

L1/2 OAM & BFD

PE2

PE1PE3

IP/OSPF/MPLS/BGP PIC

IP/OSPF/MPLS/BGP PIC

PIC i th d B t E t l




PIC unipath and Best-External

PE3

PE1

PE2

RD1:1/8 via PE1,

LOCPREF=200

RD2:1/8 via PE2,

LOCPREF=100

1/8

1/8

..

CEs

CE

RR

PE3

PE1

PE2

RD1:1/8 via PE1,

LOCPREF=200

RD2:1/8 via PE2,

LOCPREF=100

1/8

1/8

..

CEs

CE

RR

:: bestexternal path ::

:: best path :: q Create “primary-backup” topology (primary =

PE1-CE link, backup = PE2-CE link).

q Make PE1 “exit point” more preferableand PE2 “exit point” less preferable

(e.g. LOCAL_PREF configuration)q Makes PE2 select IBGP path as best

q But PE2’s EBGP path should be advertised toincrease path diversity and achieve much

faster failover to the backup path.

Note: “Add-path” may still be a requirement to pass best-external paths through the route reflectors to ingress PEs.(e.g. non-unique RD VPN design, non-VPN prefixes).

W i t di




We are going to discuss…

PE3

PE1

PE2

RD1:1/8 via PE1,

LOCPREF=200

RD2:1/8 via PE2,

LOCPREF=100

1/8

1/8

..

CEs

CE

RR

PE3

PE1

PE2

RD1:1/8 via PE1,

LOCPREF=200

LOCPREF=100

1/8

1/8

..

CEs

CE

RR

Primary PE and itsbehavior upon CE linkfailure

Backup PE and itsbehavior wrt. bestexternal advertisement

Ingress PE and itsbehavior on best egressPE failure



F di T bl S t




Forwarding Table Setup

PE3

PE1

PE2

RD1:1/8 via PE1,LOCPREF=200


1/8 1/8

..

CEs

CE

RR

PE3

PE1

PE2



1/8 1/8

..

CEs

CE

RR

:: bestexternal path ::

:: best path :: q PE1

IP 1/8à CE

Label L1 (allocated for 1/8) à CE

q PE2IP 1/8à PE1, push [L1], [PE1 IGP label]

Label L2 (allocated for 1/8) à CE

q PE3IP 1/8à PE1, push [L1], [PE1 IGP label]

New with

best-external

Traffic flow – Primary link failure( ith B k th i f di )




(with Backup path in forwarding)

q FIB detects CE failure

q FIB will modify the BGP loadinfo tonow point to the backup path (PE2)

q Traffic is restored once the loadinfotouch-up is done

q Since PE2 has pre-programmed thelabel pointing to CE, traffic will beforwarded to the CE.

q BGP prefix independentconvergence

Behavior at

PE1

PE1IP 1/8à CE (active)

à PE2, push [L2],[PE2 IGP label] (backup)

Label L1 (allocated for 1/8)à CE (active) à PE2, push [L2],

[PE2 IGP label] (backup)

PE3

PE1

PE2



1/8

1/8 ..

CEs

CE

RR

PE3

PE1

PE2



1/8

1/8 ..

CEs

CE

RR

Traffic flow – Primary PE failure( ith B k th i f di )




(with Backup path in forwarding)

q FIB detects PE1 failure upon IGPconvergence

q FIB will modify the BGP loadinfo tonow point to the backup path (PE2)

q Traffic is restored once the loadinfotouch-up is done

q Since PE2 has pre-programmed thelabel pointing to CE, traffic will beforwarded to the CE.

q BGP prefix independentconvergence

Behavior at

PE3

PE3IP 1/8à PE1, push [L1],

[PE1 IGP label] (active)à PE2, push [L2],

[PE2 IGP label] (backup)

PE3

PE1

PE2



1/8

1/8 ..

CEs

CE

RR

PE3

PE1

PE2



1/8

1/8 ..

CEs

CE

RR






3107 (BGP LabeledUnicast) Architecture& AIGP Attribute

IOS-XR (3.8.0 / 4.0.0)

ISP CORE with multiple IGP Areas




ISP CORE with multiple IGP Areas

PE2

PE1

PE7

PE8

P3

P5

P4P6

CE0

CE9

IGP+LDP IGP+LDP IGP+LDP

i B G P




ISP Core

§ IGP runs in the core

§ May be segmented into different areas

§ IGP+LDP provides reachability to PEs in the network

§ May span one or more AS under the sameadministration

§ Problem: When PE scale increases, IGP database sizeincreases

§ Problem: Convergence is affected

BGP 3107




BGP 3107

§ BGP 3107 to carry PE reachability§ BGP IPv4-label address-family sessions between PE and

P routers

§ IGP+LDP still runs within areas but does not carry PE

reachability across areas

§ Remote PE loopback is a BGP ipv4 labeled route in RIB

§ Nexthop for BGP service prefix (L3VPN, L2VPN) is aBGP 3107 route

BGP 3107 Architecture




BGP 3107 Architecture

PE2

PE1

PE7

PE8

P3

P5

P4P6

V P N v 4 ( b g p

)

CE0

CE9

ABR-RR

IG P + L D P

BGP 3107 Pros




BGP 3107 Pros

§ Higher PE scale

§ Add-path capability can be enabled for 3107address-families to provide path diversity

§ PIC functionality to handle core link/router

failures (future release)

§ AIGP attribute to enable use of moreaccurate (end-to-end) metrics

AIGP§ IGPs run within a single administrative domain and select




§ IGPs run within a single administrative domain and selectthe best path between two nodes based on total distance/metric.

§ When a single administration runs multiple BGP networks, itcan be desirable for BGP to select best path based on end-to-end metric

§ AIGP: new BGP attribute that carries the accumulated metricfor an end-to-end path

§ Usage:

• Originate the AIGP attribute for routes local to the AS

• Accumulation: For a received route with an AIGP metric, addthe metric of the route to the nexthop to the existing valuebefore advertising if the router sets itself as nexthop

• Decision process: Compare the AIGP metric of paths after local-preference comparison step

BGP Knobs to enable 3107/AIGP Solution

• AIGP




PE2

PE1

PE7

PE8

P3

P5

P4P6

V P N v 4 ( b g p

)

CE0

CE9

RR

IG P + L D P

• IPv4 LabelAdd-path

Send

• IPv4 LabelPIC• IPv4 Label

PIC

AIGPoriginate

• AIGPaccumulate

• AIGPaccumulate

• AIGP

comparision





© 2006 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 124© 2006 Cisco Systems, Inc. All rights reserved. Cisco ConfidentialPresentation_ID 124

Cisco BGP

Attribute filtering and error-handling

Overview




§ Attribute filtering

Unwanted optional transitive attribute such as ATTR_SET, CONFED segment in AS4_PATH causing outage in some equipments.

Prevent unwanted/unknown BGP attributes from hitting the legacy equipments.

Block specific attributes

Block a range of non-mandatory attributes

§ Error-handlingdraft-ietf-idr-optional-transitive-04.txt

Punishment should not exceed the crime

Gracefully fix or ignore non-severe errors

Avoid session resets for most cases



Attribute filtering




g

§ First level of inbound filtering

§ Filtering is configured as a range of attribute codes and acorresponding action to take

§ Actions

Discard the attribute

Treat-as-withdraw

§ Applied when parsing each attribute in the received Updatemessage

When a attribute matches the filter, further processing of theattribute is stopped and the corresponding action is taken

Error-handling




g

§ Comes into play after attribute-filtering is applied§ When we detect one or more malformed attributes or

NLRIs or other fields in the Update message

§ Steps

Classification of errors

Actions to be taken

Logging

Error-handling details




g

§ Classification of errors

Minor: invalid flags, zero length, duplicates, optional-transitive attributes

Medium: Non-optional-transitive attributes, inconsistent attribute length

Major: Invalid or 0 length nexthop

Critical: NLRI parsing, inconsistent message / total attributes length

§ Actions taken

Local repair

Discard attribute

Treat-as-withdraw

Reset session

Discard Update message

IOS-XR implementation




§ Error-handling

Router level configuration knob

Separately for EBGP and IBGP

Separately for “basic” and “extended” degrees of error-handling

Neighbor level configuration knob

Last resort hidden knob to avoid session reset at all costs (by simply discardingmalformed Update message)

Logging

Last few malformed messages are stored

§ Attribute-filtering

Neighbor level configuration knob

Specify a range of attribute codes (except ORIGIN, AS_PATH, NEXT_HOP,

MP_REACH, MP_UNREACH)Two possible actions: discard-attribute; treat-as-withdraw

Logging

Optionally store the last few messages that matched any filter




Roadmap

Future Release Features




Future Release Features

No specific Priority1. Add-path for eBGP peers2. BGP Flow-Spec

3. Import from default VRF to non-default VRF4. Import from non-default VRF to default VRF

5. Conditional RPL policies

6. Support for traffic blackhole via RPL7. mGRE AF

8. IPv4 over IPv6 (RFC 5747)9. BGP mibv2

10. Import/export policy filtering

11. Per neighbor NSR knob12. mLDP / MVPN enhancements

13. BGP diverse path14. Half Duplex Hub & Spoke





Future Work




§ BGP E-VPN

§ BGP Error handling§ Accumulated IGP

§ Connect Apps and Instrumentation for Route Servers

§ Vrf to Global import

§ Enhanced GR

§ BGP RT Filtering for Legacy Routers

§ BGP Based Auto-discovery for SAF and other services (iBGP)

§ BGP Advisory Message/Soft-notify

§ BGP Flow-Spec (RFC5575)

§ BGP Monitoring Protocol

§ BGP Virtual Aggregation

Note: Expected availability dates are tentative

Summary




§ Scale and performance has been enhancedNew RPs, platforms

Existing platforms

§ Software releases are consolidating to singlecodebase

Reduction in quality issues

Increased feature velocity

§ Full feature roadmap










§ Static protection[no] neighbor … slow-peer split-update-group static

§ Dynamic detection

[no] bgp slow-peer detection [threshold <seconds>]

§ Dynamic protection

[no] neighbor … slow-peer detection [threshold <seconds>]

[no] bgp slow-peer split-update-group dynamic [permanent]

Documents

Bgp Advanced New