BGP ERROR HANDLING. DEVELOPING AN OPERATOR-LED APPROACH IN THE IETF. - PowerPoint PPT Presentation

BGP ERROR HANDLING. DEVELOPING AN OPERATOR-LED APPROACH IN THE IETF. Rob Shakir, Cable&Wireless Worldwide. NANOG 51 – Feb. 01, 2011 – MIAMI, FL

A Typical SP Network? CUSTOMER PE PE TRANSIT PEER PE P P PE P PE PE BGP IGP CUSTOMER IGP Signals customer/Internal prefixes between PEs EGP Propagates internal prefixes to neighbouring ASes.

A (Modern) Typical SP Network? CUSTOMER PE PE RR TRANSIT PEER PE PE P P P PE PE BGP IGP CUSTOMER IGP Minimal infrastructure routing information. BGP Propagate internal routing and service data.

BGP Failures I. JAN. ERRORS IN AS4_PATH 09 Erroneous ¡data ¡in ¡the ¡AS4_PATH ¡op6onal ¡transi6ve ¡a9ribute ¡ causing ¡BGP ¡session ¡failure ¡(JunOS ¡bug). ¡ FEB. VERY LONG AS_PATH 09 Very ¡long ¡AS_PATHs ¡in ¡the ¡global ¡BGP ¡table ¡cause ¡session ¡failure. ¡ Not ¡the ¡first ¡6me ¡this ¡had ¡been ¡seen. ¡

BGP Failures II. AUG. RIPE NCC RIS EXPERIMENT 10 A ¡RIPE ¡NCC ¡RIS/Duke ¡University ¡experiment ¡results ¡in ¡BGP ¡ sessions ¡being ¡reset ¡– ¡disrup6ng ¡global ¡table ¡(IOS ¡XR ¡bug). ¡ ?? iBGP FAILURES ?? Mul6ple ¡occurrences ¡within ¡xSP ¡networks. ¡ Likely ¡to ¡cause ¡higher ¡financial ¡impact ¡(L3VPN ¡margin). ¡

Why do we see these events? RTR A RTR B UPDATE Error! RTR A RTR B NOTIFICATION

Cause/Impact. LIMITED Must ¡either ¡DISCARD ¡a9ributes ¡or ¡ TOOLSET IN STANDARDS. respond ¡with ¡NOTIFICATION. ¡ SERVICE Transit/Peering ¡failure ¡ ¡-­‑ ¡although ¡error ¡source ¡may ¡be ¡remote. ¡ IMPACT. iBGP ¡failure ¡– ¡high ¡impact ¡sessions? ¡Route ¡reflectors? ¡ Results in loss of RIB! Would you tolerate this in your IGP based on one erroneous LSP?

Intent of Work. DEFINE HOW Document ¡the ¡way ¡xSPs ¡use ¡BGP. ¡ BGP IS USED. Ensure ¡that ¡cri6cal ¡nature ¡of ¡the ¡protocol ¡is ¡understood. ¡ PROVIDE Determine ¡how ¡ OPERATORS ¡think ¡that ¡BGP ¡should ¡ REQUIREMENTS fail ¡– ¡and ¡what ¡we’ll ¡compromise ¡on. ¡ TIE TOGETHER Ensure ¡that ¡tools ¡resul6ng ¡from ¡exis6ng ¡dra]s ¡ IETF WORK ITEMS. form ¡a ¡useful ¡framework ¡to ¡make ¡BGP ¡robust. ¡

Approach Overview. 04 01 DON’T SEND NOTIFICATION. MONITORING 02 RECOVER RIB CONSISTENCY. 03 RESTART BGP HITLESSLY.

Avoid sending NOTIFICATION. Error! 172.16.0.0/12 WITHDRAWN UPDATE 172.16.0.0/12 RTR A RTR B NOTIFICATION WHAT DO WE “treat-­‑as-­‑withdraw” ¡mechanism ¡can ¡result ¡in ¡ COMPROMISE ON? rou6ng ¡inconsistency ¡(possible ¡loops!). ¡ EXISTING WORK dra]-­‑chen ¡(eBGP ¡errors) ¡– ¡includes ¡Opt ¡Trans. ¡ ITEMS IN IETF? Needs ¡to ¡be ¡extended ¡to ¡cover ¡iBGP. ¡

Recover RIB Consistency. Missing 172.16.0.0/12 from RTR A REQUEST 172.16.0.0/12 RTR A RTR B UPDATE 172.16.0.0/12 HOW CAN THIS Mechanisms ¡to ¡re-­‑request ¡missing ¡NLRI. ¡ BE ACHIEVED? One ¡prefix ¡at ¡once, ¡or ¡whole ¡RIB. ¡ EXISTING WORK “One-­‑Time ¡Prefix ¡ORF”. ¡ ITEMS? Enhanced ¡ROUTE ¡REFRESH. ¡

Reduce Impact of Session Reset. SESSION RESETS, NOTIFICATION ¡has ¡u6lity ¡for ¡resecng ¡state. ¡ CAN WE AVOID THEM? Consider ¡that ¡some6mes ¡it ¡is ¡unavoidable. ¡ FORWARDING PLANE UNAFFECTED. SESSION RESET RTR A RTR B SESSION RE-OPEN EXISTING WORK (Expired) ¡“SOFT-­‑NOTIFICATION”. ¡ ITEMS IN IETF? Further ¡work ¡required ¡to ¡revive! ¡

Introduce Further Monitoring. EXISTING ERRORS NOCs ¡can ¡see ¡session ¡failures ¡very ¡easily ¡– ¡both ¡ ARE VERY VISIBLE. via ¡session ¡monitoring ¡and ¡forwarding ¡outage! ¡ ¡ FURTHER COMPLEXITY Mechanisms ¡are ¡required ¡to ¡make ¡error ¡ MEANS LESS MANAGEABLE handling ¡visible ¡to ¡both ¡BGP ¡speakers. ¡ EXISTING WORK (In-­‑band) ¡ADVISORY ¡and ¡DIAGNOSTIC. ¡ ITEMS IN IETF? (Out-­‑of-­‑Band) ¡BGP ¡Monitoring ¡Protocol. ¡

Complexities of Approach. Know ¡the ¡NLRI? ¡ Re-­‑request ¡ (ORF) ¡ Error! ¡ Re-­‑request ¡the ¡ Hitless ¡Session ¡ treat-­‑as-­‑ whole ¡RIB ¡ Reset ¡ withdraw ¡ OOPS! OOPS!

Why am I standing here? NAN O G As Operators, we deal with the fall-out of protocol issues! SO… an agreed, operator-recommended approach is required.

Questions, comments, review… ALL MUCH APPRECIATED! Feedback form at http://rob.sh/bgp http://tools.ietf.org/html/draft-shakir-idr-ops-reqs-for-bgp-error-handling-00 rob.shakir@cw.com // +44(0)207 100 7532 // RJS-RIPE

ADDITIONAL SLIDES. Q&A AND FURTHER BACKGROUND.

Receiver side only? UTILITY FOR Yes ¡– ¡we ¡can ¡s6ll ¡use ¡these ¡mechanisms. ¡ RX-SIDE BUGS? Although ¡u6lity ¡of ¡RIB ¡consistency ¡refresh ¡is ¡reduced. ¡ Error! ¡ Repeat ¡errors ¡– ¡ ¡ Hitless ¡Session ¡ treat-­‑as-­‑ NLRI ¡remains ¡ Reset ¡ withdraw ¡ withdrawn? ¡ REQUIREMENTS Must ¡ensure ¡that ¡this ¡is ¡flagged ¡to ¡Operator. ¡ Implementa6on ¡bugs ¡cannot ¡be ¡recovered ¡by ¡ any ¡protocol ¡mechanism. ¡

Multi-session BGP IS MULTISESSION No ¡– ¡it ¡helps, ¡but ¡is ¡not ¡a ¡complete ¡solu6on. ¡ ANOTHER SOLUTION? Many ¡topologies ¡in ¡one ¡AFI. ¡ DOES HAVE Can ¡achieve ¡AFI ¡error ¡separa6on. ¡ UTILITY e.g. ¡IPv4 ¡and ¡IPv6 ¡errors ¡can ¡be ¡independent ¡of ¡each ¡other. ¡ ¡ SOLUTION DOES For ¡complete ¡solu6on, ¡we ¡would ¡need ¡one ¡session ¡ NOT SCALE per ¡topology ¡– ¡control-­‑plane ¡does ¡not ¡scale ¡to ¡this! ¡