Deploying IP Fast Reroute for OSPF & BGP (IOS Advantage Webinar)

© 2010 Cisco and/or its affiliates. All rights reserved. 1

Cisco IOS Advantage Webinars Deploying IP Fast Reroute for ISIS, OSPF, and BGP Jean-Marc Barozet and Bertrand Duvivier

We’ll get started a few minutes past the top of the hour.

Note: you may not hear any audio until we get started.

© 2011 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 2

Bertrand Duvivier Product Manager [email protected]

Jean-Marc Barozet Technical Leader Technical Marketing [email protected]

Ahmed Bashandy Technical Leader Engineering [email protected]

Anton Smirnov Software Engineer Engineering [email protected]

Panelists

Speakers


•  Submit questions in Q&A panel and send to “All Panelists”

Avoid CHAT window for better access to panelists

•  For Webex audio, select COMMUNICATE > Join Audio Broadcast

•  For Webex call back, click ALLOW Phone button at the bottom of Participants side panel

•  Where can I get the presentation? https://communities.cisco.com/docs/DOC-27274

Or send email to: [email protected]

•  Please fill in Survey at end of event

•  Join us on February 8 for our next IOS Advantage Webinar: Recommendations for Network Application Identification and Policy


Fast Reroute Requirements

Failure Scenarios

The Right Forwarding Infrastructure

Hierarchical FIB

BGP PIC PIC Core PIC Edge

Loop Free Alternate (LFA) Key Concepts Applicability

Conclusion



Failure Scenarios


Hierarchical FIB



Conclusion


•  Assume a flow from A to B

•  T1: when L dies, the best path is impacted loss of traffic

•  T2: when traffic reaches the destination again If fast reroutes technologies are used, this may happen well before the network convergence Once the network converges, a next best path is computed

•  Loss of Connectivity: T2 – T1, called “convergence” hereafter

•  Analyzed for streams going to IGP and BGP learned prefixes

20

Default metric = 1

Link L

T1 T2 Convergence

F R

R

A B


Convergence Low motion best

Low motion worst

High motion best

High motion worst

10ms 33ms 634ms 33ms 634ms

50ms 167ms 667ms 67ms 667ms

100ms 267ms 767ms 167ms 667ms

200ms 434ms 934ms 267ms 767ms If we have a 10mS outage, the best we can expect is a 33mS disruption because we lose a b-frame and the worst case is because we got unlucky and lost an I-frame. The worst case loss for low motion is longer than the worst case loss for high motion : because there are more frames in high motion.


•  Minimize network downtime/traffic loss “Classical” Convergence > 1 sec. Fast Convergence < 1 sec. Fast Re-Route < 50-100 msec.

•  Support all types (Link, Node or SRLG) of IP/MPLS restoration mechanisms.

•  Keep it simple and straight.

•  Keep it cost effective (both capex/opex)


Detection (link or node aliveness, routing updates received)

State propagation

(routing updates send)

Walkthrough routing DB’s

Compute primary path & label

Download to HW FIB

Switch to newer path


Detection (link or node aliveness, routing updates received)

State propagation

(routing updates send)

Walkthrough routing DB’s

Compute primary path & label

Download to HW FIB

Switch to repair path

Pre-Compute backup path

Download to HW FIB

Offline calculation

Switch to newer path


Edge Core (IP)

Core (MPLS)

“Classical” convergence (Industry Standard) Few min. Few 10 sec.

Fast Convergence < 1 sec. “MPLS-VPN BGP FC” ISIS / OSPF Fast Convergence

( LDP sync for link up convergence)

Fast ReRoute < 50-100 msec.

BGP PIC Core/Edge

(lower bounded by IGP Convergence)

LFA FRR MPLS-TE FRR LFA FRR

FRR Signaling Section of the network protected

LFA FRR Install a primary and backup path (& label) in forwarding

MPLS-TE FRR Install a backup TE tunnel LSP in forwarding

PIC Core Enable hierarchical forwarding rewrite: - H1: IGP and tunnel LSP label - H2: BGP or service LSP label (BGP, L3VPN, L2VPN!)

BGP PIC Edge Install a primary and backup path (& label) in forwarding



Failure Scenarios


Hierarchical FIB



Conclusion


•  Upon a core failure, the IGP finds an alternate path to the BGP next-hop PE2 ASBR used is unchanged before and after repair Changing trajectory to egress ASBR

•  The BGP prefixes depending on reachability to PE2 must leverage the new IGP path as soon as it is updated in the FIB

!""#"#"#"$%&'!""#!#"#"$%&'

('

!"#$%&'()*&

)*%'

+*!' +*%'

,,'

PE1’s RIB 110.0.0.0/24 via PE2 110.1.0.0/24 via PE2

...

PE2 reachable via E0/0

E0/0

E1/0

)*!'

!!"#"#"#"$%&'!!"#!#"#"$%&'!!"#%#"#"$%&'#'#'#'


•  Upon a PE node failure, the IGP propagates loss of PE’s /32 host route across the core to remote PEs

•  Changing which ASBRs to switch to for the group of prefixes. As a consequence of its IGP convergence, PE1 has to update its FIB tree such that all the BGP prefixes be forwarded via the alternate path through PE4

•  Could be a PE-CE link failure if BGP next-hop-self is not set on the remote PE

!""#"#"#"$%&'!""#!#"#"$%&'

('

!"#$%&'()*&

)*!'

)*%'

)*-'

)*&'

+*!' +*%'

)./01.2'

314567'

,,'

!!"#"#"#"$%&'!!"#!#"#"$%&'!!"#%#"#"$%&'#'#'#'


•  If PE3 does not set next-hop-self, same as case 2 PE1 reaction is triggered by IGP convergence

•  If set next-hop-self on PE3 – BGP Signaling involved PE3 is the reacting point PE3 reaction is triggered by local interface failure PE1 is blind in this case as the next-hop is PE3

!""#"#"#"$%&'!""#!#"#"$%&'

('

!"#$%&'()*&

)*!'

)*%'

)*-'

)*&'

+*!' +*%'

)./01.2'

314567'

,,'

!!"#"#"#"$%&'!!"#!#"#"$%&'!!"#%#"#"$%&'#'#'#'



Failure Scenarios


Hierarchical FIB



Conclusion


•  What is it, and why?

•  PIC is the ability to restore forwarding without resorting to per prefix operations.

•  Loss Of Connectivity does not increase as my network grows (one problem less).

0

10

20

30

n 2n 3n 4n 5n 6n

t, Lo

ss O

f C

onne

ctiv

ity

no pic pic


!""#"#"#"$%&'!""#!#"#"$%&'

('

!"#$%&'()*&

)*-'

+*!' +*%'

E0/0

E1/0

)*!'

Advertised with NH 10.0.0.3/32

!!"#"#"#"$%&'!!"#!#"#"$%&'!!"#%#"#"$%&'#'#'#'

! BGP Net

110.0.0.0/24

BGP Net 110.5.0.0/24

IGP Net 10.0.0.3/32

OIF

OIF

OIF

!  Each BGP FIB entry has its own local Outgoing Interface (oif) information !  Forwarding Plane must directly recurse on local oif Information !  FIB changes can take long, dependent on number of prefixes


!""#"#"#"$%&'!""#!#"#"$%&'

('

!"#$%&'()*&

)*-'

+*!' +*%'

E0/0

E1/0

)*!'


!!"#"#"#"$%&'!!"#!#"#"$%&'!!"#%#"#"$%&'#'#'#'

FIB Entry 110.0.0.0/24

FIB Entry 110.2.0.0/24

! Via 10.0.0.3

•  Pointer Indirection between BGP and IGP entries allow for immediate leveraging of the IGP convergence, and immediate update of the multipath BGP pathlist at IGP convergence

•  Only the parts of FIB actually affected by a change needs to be touched •  Used in newer IOS and IOS-XR (all platforms), enables Prefix Independent Convergence

BGP Next Hops

10.1.2.2 10.1.5.5

IGP pathlist

OIF



Failure Scenarios


Hierarchical FIB



Conclusion


•  Addresses failures “in the core” where the recursive BGP path stays intact. Failures covered are P-PE link or P node failures that trigger a change of the IGP path to the BGP next-hop.

•  IGP convergence on PE1 leads to a modification of the RIB path to PE3. BGP Dataplane Convergence is finished assuming the new path to the BGP nhop is leveraged immediately

!""#"#"#"$%&'!""#!#"#"$%&'

('8/9:';!' )*!'

)*-'

)*&'

+*!' +*%'

,%'

!!"#"#"#"$%&'!!"#!#"#"$%&'!!"#%#"#"$%&'#'#'#'

,<'


! BGP nexthop(s)

IGP nexthop(s) Output Interface

•  FIB Leaf: group of prefixes, 110.x.0.0/24 •  BGP Path-List: list of best ECMP BGP nhops and list of alternate BGP nhops •  IGP Path-List: list of ECMP IGP paths

•  Adjacency: OIF and immediate nhop

BGP Net 200.0.0.0/24

BGP Net 200.1.0.0/24

BGP Net 200.5.0.0/24

BGP pathlist

PE3 PE4 IGP pathlist

R5

OIF

IGP pathlist

R2 R5 OIF

OIF

Example: PE1 is configured for BGP Multipath. PE1 has two ECMP paths to PE3 and 1 IGP path to PE4. The alternate list is empty.


•  As soon as IGP converges 0(200msec), the IGP PL memory is updated and hence all children BGP PL’s leverage the new path immediately

•  Optimum convergence, Optimum Load-Balancing, Excellent Robustness

! BGP nexthop(s)

IGP nexthop(s) Output Interface

BGP Net 110.0.0.0/24

BGP Net 110.1.0.0/24

BGP Net 110.5.0.0/24

BGP pathlist

PE3 PE4 IGP pathlist

R5

OIF

IGP pathlist

R2 R5 OIF

OIF



Failure Scenarios


Hierarchical FIB



Conclusion


•  BGP PIC Edge addresses a change in the BGP path •  i.e. a change to a different BGP next-hop due to a PE node failure, which

normally would require network wide BGP best-path re-computation and path withdrawing

•  BGP Dataplane Convergence is kicked in on PE1 and immediately redirects the packets via PE4 using a pre-calculated alternate (repair) path.

!""#=#"#"$%&'>)?!'8/9:';!'

)*!'

)*-'

)*&'

+*!' +*%'

,%'

>)?!'8/9:';%'!!"#"#"#"$%&'!!"#!#"#"$%&'!!"#%#"#"$%&'#'#'#'

,<'

1


!""#=#"#"$%&'>)?!'8/9:';!'

@)A8'+BC6D'

!"#$%&'()*&

!!"#=#"#"$%&'>)?!'8/9:';%'

)*!'

)*%'

)*-'

)*&'

+*!' +*%'

)./01.2'

314567'

,,'

•  PE1 has primary and backup path Primary via PE3

Backup via PE4 best external route

•  What happens when node PE3 fails?


!""#=#"#"$%&'>)?!'8/9:';!'

@)A8'+BC6D'

!"#$%&'()*&

!!"#=#"#"$%&'>)?!'8/9:';%'

)*!'

)*%'

)*-'

)*&'

+*!' +*%'

)./01.2'

314567'

,,'

)*-EF'$-%'GCF9'.C69:'.:0CH:D'

I.C0'JK)'

•  IGP propagates loss of PE3’s /32 host route across the core to remote PEs


!""#=#"#"$%&'>)?!'8/9:';!'

@)A8'+BC6D'

!"#$%&'()*&

!!"#=#"#"$%&'>)?!'8/9:';%'

)*!'

)*%'

)*-'

)*&'

+*!' +*%'

)./01.2'

314567'

,,'

)*-EF'$-%'GCF9'.C69:'.:0CH:D'

I.C0'JK)'

•  PE1 detects loss of PE3’s /32 host route in IGP CEF immediately swaps forwarding destination label from PE3 to PE4 using backup path

•  BGP NHT sends a “delete” notification to BGP which triggers BGP Control-Plane Convergence

BGP on PE1 computes a new bestpath later, choosing PE4


•  PE1 and PE3 are the reacting points •  Enhancement to the MPLS VPN BGP Local Convergence feature •  Improvement by calculating a backup/alternate path in advance •  When primary link PE3– CE2 fails:

Data plane: The traffic is sent to the backup/alternate path Control Plane: PE1 is expected to converge to start using PE4’s label to send traffic to 110.x.0.0/24

2

!""#=#"#"$%&'8/9:';!'

)*!'

)*-'

)*&'

+*!' +*%'

,%'

!!"#"#"#"$%&'!!"#!#"#"$%&'!!"#%#"#"$%&'#'#'#'

,<'

PE3 does set next-hop-self


!""#=#"#"$%&'>)?!'8/9:';!'

@)A8'+BC6D'!"#$%&'()*&

!!"#=#"#"$%&'>)?!'8/9:';%'

)*!'

)*%'

)*-'

)*&'

+*!' +*%'

)./01.2'

314567'

,,'

•  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?


!""#=#"#"$%&'>)?!'8/9:';!'

@)A8'+BC6D'!"#$%&'()*&

!!"#=#"#"$%&'>)?!'8/9:';%'

)*!'

)*%'

)*-'

)*&'

+*!' +*%'

)./01.2'

314567'

,,'

•  CEF (via BFD or link layer mechanism) detects PE3-CE2 link failure •  CEF immediately swaps to repair path label

Traffic shunted to PE4 and across PE4-CE2 link


!""#=#"#"$%&'>)?!'8/9:';!'

@)A8'+BC6D'

!"#$%&'()*&

!!"#=#"#"$%&'>)?!'8/9:';%'

)*!'

)*%'

)*-'

)*&'

+*!' +*%'

)./01.2'

314567'

,,'

L/9GD.1M'.C69:'H/1')*-'

•  PE3 withdraws route via PE3-CE2 link •  Update propagated to remote PE routers


!""#=#"#"$%&'>)?!'8/9:';!'

@)A8'+BC6D'

!"#$%&'()*&

!!"#=#"#"$%&'>)?!'8/9:';%'

)*!'

)*%'

)*-'

)*&'

+*!' +*%'

314567'

,,'

L/9GD.1M'.C69:'H/1')*-'

•  BGP on remote PEs selects new bestpath •  New bestpath is via PE4 •  Traffic flows directly to PE4 instead of via PE3



Failure Scenarios


Hierarchical FIB



Conclusion


•  Why not just use Fast Convergence? •  ISIS/OSPF and CEF can be very fast !

200ms on high end platform can be achieved.

•  But!.. It runs at the process level

Does not guarantee time limit

Performance depends on tuning and platform implementation

!""#"#"#"$%&'!""#!#"#"$%&'

('8/9:';!'

!"#$%&'()*&

)*-'

+*!' +*%'

E0/0

E1/0

)*!'


!!"#"#"#"$%&'!!"#!#"#"$%&'!!"#%#"#"$%&'#'#'#'?


•  Sub 50 msec convergence without using RSVP-TE. •  Simple operation with minimal configuration; •  Superior LFA scaling without tunnel requirement. •  Incremental deployment with no inter-operability req.

There is no change to the standard based IGP protocols IP FRR capability is internal to a box.

•  Applicable to pure IP (IP FRR) and MPLS (LDP FRR) networks

MPLS Network IP Network OSPF/ISIS OSPF/ISIS

LDP Simple CLI Simple CLI Configuration

Control Plane

IP/LDP FRR


Primary Path Repair Path

Primary Next-Hop

Protecting Node

A B

C

•  Stands for Loop Free Alternate •  A node other than the primary next hop •  Provides local protection for unicast traffic in pure IP (and MPLS/LDP) networks

in event of a single failure, whether link, node, or shared risk link group (SRLG) •  An LFA takes forwarding decision without knowledge of the failure

LFA must not use the failed element to forward the traffic LFA must not use the protecting node to forward traffic LFA must not cause loop


Primary Path Repair Path

Primary Next-Hop

Protecting Node

A B

C

•  Protecting Node, also referred as “Calculating Node”, is responsible for pre-computing an alternate next-hop

•  IGP pre-computes a backup path per IGP prefix No degradation for IGP FC. Per-Prefix LFA Computation is throttled by its own independent exp-backoff, does not start until the primary computation is finished and is interrupted if a new primary computation is scheduled

•  FIB pre-installs the backup path in dataplane Upon local failure, all the backup paths of the impacted prefixes are enabled in a prefix-independent manner (<50msec LoC)


P/p

N2

N3

D1 D2

B

N1 Potential LFA

for P/p S

Primary path to P/p

Repair path P/p

•  For each IGP route P/p, S’s primary path is link S-N2

•  N1 is a LFA for P/p if Distance(NI,P/p) < Distance(NI, S) + Distance(S, P/p)

•  i.e. Does the optimal path from the potential LFA to P/p pass through me? Distance from the LFA to P/p via the protecting node S is greater than optimum distance from the LFA to P/p


P/p

N2

N3

D1 D2

B

N1 Potential

LFA for P/p

Path if V1 is node protecting LFA

Path if V1 is link protecting LFA

S

•  Does the optimal path from the potential LFA to P/p pass through my primary NH?

•  N1 is a node protecting LFA if Distance(N1,p/P) < distance(NI, N2) + distance(N2, p/P)

i.e. The distance from the LFA to the prefix via my primary next-hop is greater than the optimum distance from the LFA to the prefix

•  If a neighbor is a node protecting LFA, then it is a Link protecting LFA ⇒ node protection is a sufficient condition for link protection

Primary path to P/p


10.0.0.0/8

20.0.0.0/8

•  IGP pre-computes a backup path per IGP prefix •  FIB pre-installs the backup path in dataplane

A

F

B

D E

C

2

6 5

5 1 1

2

4

6

10.0.0.0/8, NH = D, cost= 10 20.0.0.0/8, NH = D, cost= 7


10.0.0.0/8

20.0.0.0/8


A

F

B

D E

C

2

6 5

5 1 1

2

4

6

10.0.0.0/8, NH = D, cost= 10 20.0.0.0/8, NH = D, cost= 7

10.0.0.0/8, NH = C, cost=11 20.0.0.0/8, NH = A, cost=9

10.0.0.0/8, NH = A, cost=14 20.0.0.0/8, NH = direct, cost=6


10.0.0.0/8

20.0.0.0/8


A

F

B

D E

C

2

6 5

5 1 1

2

4

6

10.0.0.0/8, NH = D, cost= 10 20.0.0.0/8, NH = D, cost= 7

10.0.0.0/8, NH = D, cost=10 – LFA: B 20.0.0.0/8, NH = D, cost=7 – LFA: F


10

10

10

20

10 Protecting Node

20

Primary Node 10.0.0.0/8

A

B

C

D E

Primary SPF run 10.0.0.0/8, Next-Hop = B, Cost = 30

Secondary SPF rooted at neighbor D 10.0.0.0/8, Next-Hop = A, Cost = 40

No LFA for 10.0.0.0/8!


10

10

10

20

10 Protecting Node Link

Failure

20

Primary Node

Reconverge Normally

10.0.0.0/8

A

B

C

D E

Primary SPF run 10.0.0.0/8, Next-Hop = B, Cost = 30

Secondary SPF rooted at neighbor D 10.0.0.0/8, Next-Hop = A, Cost = 40

No LFA for 10.0.0.0/8!


Another Possible LFA

Possible LFA

2

1

4

5

1

2

6

5

Protecting Node

10.0.0.0/8

A

B

D

F

E

C

•  Multiple LFA selection is a tie-breaker mechanism used to select best alternative path if multiple LFAs are found for same prefix


•  IGP will select one and only one backup path per primary path

•  Need to select an LFA among multiple candidates (tie-break)

•  Tie-break works as BGP Best-Path a set of consecutive rules each rule discards candidates scheme stops when one single path remains if a rule excludes all paths, then the rule is skipped

•  Each LFA candidate has different attributes LC disjointness, primary vs secondary, guaranteed-node-protection, backup path metric, etc

•  The default Tie breaking order is configurable



Failure Scenarios


Hierarchical FIB



Conclusion


•  LFA is a simple low-cost bonus If LFA is available, sub-50msec bonus

If not, IGP Fast Convergence as intended Anyway, no degradation on IGP Fast Convergence

Keep the simplicity trademark of IGP Fast Convergence

“KISS” approach to network availability

LFA Applicability?

Target <sec LFA is a bonus for IGP FC

Target <50msec

Topology Optimization

BB

If yes: LFA is applicable

If no: TE FRR is better

Edge Sweet spot for LFA!

http://tools.ietf.org/id/draft-ietf-rtgwg-lfa-applicability-03.txt


•  Sub-50msec likely comes with predictability LFA coverage depends on topology

•  LFA is possible if the topology can be optimized BB: a few SP’s do optimize topology for LFA Edge: sweet spot, see next

LFA Applicability?

Target <sec LFA is a bonus for IGP FC

Target <50msec

Topology Optimization

BB

If yes: LFA is applicable

If no: TE FRR is better

Edge Sweet spot for LFA!

http://tools.ietf.org/id/draft-ietf-rtgwg-lfa-applicability-03.txt


•  Edge represents the majority of the network •  Edge benefits most of simplicity •  Edge is made of a large number of repetitions of a few small patterns •  If the designer carefully alters the few base topologies to favor LFA, then by

repeating these n times, he simply preserves the LFA properties across all the edge network

•  All intra-pop links and nodes are protected with LFA FRR

A1 A2

C1 C2

PE

C1 C2

PE

C1 C2

PE

100

C2’s best path to PE is via C1 due to the bad asymetric metric on C2-PE (100)

Obviously, this is not good


•  Simple the router computes everything automatically No IETF protocol change, no interop testing, incremental deployment

•  <50msec pre-computed, pre-installed, enabled on link down in a prefix independent manner prefix-independent Leverage Hierarchical dataplane FIB

•  Good Scaling •  No degradation on IGP convergence for primary paths •  Node Protection or De Facto

An LFA can be chosen on the basis of the guaranteed-node protection Simulation indicate that most link-based LFA’s anyway avoid the node (ie. De Facto Node Protection)


•  Topology dependent Availability of a backup path depends on topology Is there a neighbor which meets the requirements?

•  IPFRR IGP computation is very CPU-intensive task



Failure Scenarios


Hierarchical FIB



Conclusion


•  BGP PIC Core/Edge as well as LFA leverage hierarchical forwarding structure

•  All BGP prefixes (no matter how many) converge as quickly as their next-hop

•  Generally IGP responsible for next-hop convergence " BGP convergence depends on IGP convergence

•  LFA is Simple The router computes everything automatically No IETF protocol change, no interop testing, incremental deployment <50msec Pre-computed, pre-installed, enabled on link down in a prefix independent manner


•  BGP PIC Edge Configuration (IOS-XE): http://www.cisco.com/en/US/partner/docs/ios/ios_xe/iproute_bgp/configuration/guide/irg_bgp_mp_pic_xe.html

•  LFA RFC-5286 Basic Specification for IP Fast Reroute: Loop-Free Alternates RFC-5714 IP Fast Reroute Framework RFC-5715 A Framework for Loop-Free Convergence draft-ietf-rtgwg-lfa-applicability-03

•  CiscoLive 2012 London BRKIPM-2265, Deploying BGP Fast Convergence


• Thank you! • Please complete the post-event survey.

•  Join us February 8 for our next webinar: Recommendations for Network Application Identification and Policy

To register, go to www.cisco.com/go/iosadvantage

Thank you.

Technology

Deploying IP Fast Reroute for OSPF & BGP (IOS Advantage Webinar)