Reinforcing the Kitchen Sink - Aligning BGP-4 Error Handling with Modern Network Requirements
•
0 likes•407 views
The document discusses extending BGP to better handle errors and improve reliability. It describes how current BGP implementations rely on multiple TCP sessions to separate address families (AFIs), which can cause all routes to be impacted if a single session fails. The document outlines requirements for the protocol, such as not sending notifications on invalid updates, recovering routing information if updates are lost, avoiding forwarding outages when restarting sessions, and better monitoring of errors. It argues BGP needs improvements to address complexities in message processing and ensure not all errors have equal impact.
Recommended
More Related Content
What's hot
What's hot (19)
Similar to Reinforcing the Kitchen Sink - Aligning BGP-4 Error Handling with Modern Network Requirements
Similar to Reinforcing the Kitchen Sink - Aligning BGP-4 Error Handling with Modern Network Requirements (20)
More from Rob Shakir
More from Rob Shakir (8)
Reinforcing the Kitchen Sink - Aligning BGP-4 Error Handling with Modern Network Requirements
- 1. Reinforcing the Kitchen Sink. Aligning Error Handling in BGP-4 with Modern Network Requirements. Rob Shakir (rjs@rob.sh) Netnod Autumn Meeting 2011
- 2. Extending BGP-4: “iBGP” Across an L3VPN VIRTUAL iBGP CE1 PE1 L3VPN PE2 CE2 eBGP eBGP ATTR_SET LOCAL_PREF LOCAL_PREF AS_PATH PACKED LOCAL_PREF UNPACKED AS_PATH ... AS_PATH ... ... Customer sees iBGP attributes despite the fact the UPDATE passed through eBGP in the SP L3VPN Topology. Neat – looks like a useful extension to me!
- 3. DFZ, meet ATTR_SET… INTERNET ROUTING TABLE AS65535 INTERNET AS64512 ASBR DFZ ASBR L3VPN ATTR_SET LOCAL_PREF AS_PATH ... ATTR_SET intended in an VPNv4 context! But it was leaked to the DFZ… ATTR_SET is not valid in this context! UPDATE UPSTREAM ATTR_SET AS JunOS NOTIFICATION
- 4. A familiar story? RIPE NCC/Duke AS4_PATH AS_HOPLIMIT Experimental All of these are new or unrecognised attributes! But... IPv4 Unicast
- 5. A familiar story? RIPE NCC/Duke AS4_PATH AS_HOPLIMIT Experimental All of these are new or unrecognised attributes! But... IPv4 Unicast IPv6 Unicast
- 6. A familiar story? RIPE NCC/Duke AS4_PATH AS_HOPLIMIT Experimental All of these are new or unrecognised attributes! But... MPLS L3VPN IPv4 Unicast IPv6 Unicast (VPNv[46])
- 7. A familiar story? RIPE NCC/Duke AS4_PATH AS_HOPLIMIT Experimental All of these are new or unrecognised attributes! But... MPLS PWE3 MPLS L3VPN IPv4 Unicast IPv6 Unicast (L2VPN) (VPNv[46])
- 8. A familiar story? RIPE NCC/Duke AS4_PATH AS_HOPLIMIT Experimental All of these are new or unrecognised attributes! But... MPLS PWE3 VPLS PE MPLS L3VPN IPv4 Unicast IPv6 Unicast (L2VPN) Membership (VPNv[46])
- 9. A familiar story? RIPE NCC/Duke AS4_PATH AS_HOPLIMIT Experimental All of these are new or unrecognised attributes! But... MPLSM-VPN MDT PWE3 VPLS PE MPLS L3VPN IPv4 Unicast IPv6 Unicast (L2VPN) Membership Membership (VPNv[46])
- 10. A familiar story? RIPE NCC/Duke AS4_PATH AS_HOPLIMIT Experimental All of these are new or unrecognised attributes! But... MPLSM-VPN MDT PWE3 VPLS PE MPLS L3VPN IPv4 Unicast IPv6 Unicast TE for Alto Link (L2VPN) Membership Membership (VPNv[46])
- 11. A familiar story? RIPE NCC/Duke AS4_PATH AS_HOPLIMIT Experimental All of these are new or unrecognised attributes! But... MPLSM-VPN MDT PWE3 VPLS PE MPLS L3VPN IPv4 Unicast IPv6 Unicast TE for Alto The kitchen Link sink? (L2VPN) Membership Membership (VPNv[46])
- 12. A familiar story? RIPE NCC/Duke AS4_PATH AS_HOPLIMIT Experimental All of these are new or unrecognised attributes! But... MPLSM-VPN MDT PWE3 VPLS PE MPLS L3VPN IPv4 Unicast IPv6 Unicast TE for Alto The kitchen Link sink? (L2VPN) Membership Membership (VPNv[46]) BGP is the “generic, scalable signalling mechanism” for IP/MPLS networks.
- 13. Protecting Networks from BGP Failures (Today) TCP/BGP SESSION 1 - AFI 1 BGP BGP SPEAKER SPEAKER A TCP/BGP SESSION 2- AFI 2 B UPDATE BGP BGP SPEAKER SPEAKER A B NOTIFICATION BGP BGP SPEAKER SPEAKER A B Multi-Session BGP - either kludged (lo4, lo6…), or pre-standard! (Implemented and on-by-default in 12.2(33)SRC+)
- 14. Problems with Multi-Session… INTERNET INTERNET PE PE INTERNET INTERNET INTERNET “Internet” Networks BCP: PE RR PE IPv4 Unicast over IPv4 transport. INTERNET INTERNET IPv6 Unicast over IPv6 transport. PE PE (or 6PE over IPv4 transport) IPv4 IPv6 L3VPN L3VPN PE PE “VPN” Networks BCP: L3VPN PE L3VPN L3VPN RR L3VPN PE VPNv4 over IPv4 transport. L3VPN L3VPN PE PE VPNv4 All routes (or topologies) are RT 1:1 RT 1:2 affected due to a single error RT 1:3 within their <AFI,SAFI>!
- 15. What are the requirements for the protocol? When an invalid UPDATE is received, stop sending NOTIFICATION. If we lose UPDATE contents, have a way to recover the RIB. If we must restart a session, don’t cause a forwarding outage. Have better ways to monitor errors in UPDATE messages. (Stretched out to 8,500 words in draft-ietf-grow-ops-reqs-for-bgp-error-handling…)
- 16. Message Processing Complexities. In stream processing, not all errors are created equal. MARKER HEADER: MSG LEN = 128 If we have length discrepancies – this can mean TOTAL PATH ATTRIBUTES LEN = 2000 that we can’t accurately locate path attributes. MP_REACH_NLRI COMMUNITY “Critical” error – AS_PATH no safe NLRI extraction. Invalid attribute contents – we can parse the MARKER message, but something is malformed. HEADER: MSG LEN = 128 TOTAL PATH ATTRIBUTES MP_REACH_NLRI “Semantic” error – COMMUNITY we know exactly which NLRI are contained. AS4_PATH: (65535) 1273 5413 29636
- 17. Handling “Critical” Errors. RTR A OPEN RTR B ERROR GR OPEN ERROR GR Received RTR A UPDATE RTR B UPDATE invalid - cannot FIB FIB extract NLRI. RIB RIB RTR A NOTIFICATION RTR B ! FIB FIB ! STALE IP DATA STALE RIB RIB RTR A OPEN RTR B FIB FIB DATA IP RIB RIB Re-use existing graceful-restart functionality to maintain forwarding on NOTIFICATION.
- 18. Handling “Semantic” Errors. Received UPDATE UPDATE ADVERTISE invalid - but RTR A 192.0.2.0/24 RTR B concerns 192.0.2.0/24 UPDATE RTR A RTR B WITHDRAW 192.0.2.0/24 via RTR A Erroneous advertisement interpreted as withdrawl of the NLRI. DST 192.0.2.0/24 RTR A RTR B IP Null0 ONE-TIME ORF RE-REQUEST ROUTE REFRESH RTR A RTR B ROUTES RTC
- 19. Making errors visible to the NOC… Today, an error with a BGP session is very visible to a NOC! BGP to 192.0.2.1 is down - NOTIFICATION received (3/4) SNMP/ BGP OSS NOTIFICATION SYSLOG ROUTER NOC Without NOTIFICATION, we need a new way to signal an error occurred… UPDATE OSS SNMP/ BGP BGP SYSLOG ROUTER OPERATIONAL ROUTER NOC MUP Local system NLRI: generated invalid 192.0.2.0/24 UPDATE - 192.168.0.0/16 192.0.2.0/24 and 192.168.0.0/16 withdrawn by 1.2.3.4
- 20. So, where next? Requirements are being pushed in the IETF GROW WG – Please review them! Numerous drafts in progress in the IDR working group – solutions work. New error handling mechanisms proposed in JUNOS, IOS, TiMOS… Feature request these mechanisms with your vendors of choice!
- 21. Questions? Thanks (especially to Netnod!)
- 22. Further interest? I’m always happy to discuss operational issues, and thoughts on solutions! Rob Shakir <rjs@rob.sh> +44(0)207 100 7532 Relevant IETF Working Groups: Global Routing Operations WG – GROW: http://tools.ietf.org/wg/grow Inter-domain Routing – IDR: http://tools.ietf.org/wg/idr Mailing lists at: http://www.ietf.org/mailman/listinfo/