Reinforcing the Kitchen Sink - Aligning BGP-4 Error Handling with Modern Network Requirements

Reinforcing the Kitchen Sink. Aligning Error Handling in BGP-4 with

Modern Network Requirements. Rob Shakir ([email protected]) Netnod Autumn Meeting 2011

Extending BGP-4: “iBGP” Across an L3VPN

L3VPNCE1 CE2PE1 PE2

VIRTUAL iBGP

eBGP eBGP

LOCAL_PREFAS_PATH

...LOCAL_PREF

AS_PATH...

ATTR_SETLOCAL_PREF

AS_PATH...

PACKED UNPACKED

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!

DFZ, meet ATTR_SET…

L3VPN

INTERNETDFZ

AS64512ASBR

INTERNETROUTING TABLE

AS65535ASBR

LOCAL_PREFAS_PATH

...

ATTR_SET

ATTR_SET intended in an VPNv4 context! But it was leaked to the DFZ…

JunOSUPSTREAM

AS

UPDATEATTR_SET

ATTR_SET is not valid

in this context!

NOTIFICATION

IPv4 Unicast

A familiar story?

AS4_PATH RIPE NCC/Duke

Experimental AS_HOPLIMIT

All of these are new or unrecognised attributes! But...

IPv4 Unicast IPv6 Unicast

A familiar story?




IPv4 Unicast MPLS L3VPN (VPNv[46])

IPv6 Unicast

A familiar story?





IPv6 Unicast MPLS PWE3

(L2VPN)

A familiar story?






(L2VPN) VPLS PE

Membership

A familiar story?






(L2VPN) VPLS PE

Membership M-VPN MDT Membership

A familiar story?






(L2VPN) VPLS PE


Link TE for Alto

A familiar story?






(L2VPN) VPLS PE


Link TE for Alto The kitchen sink?

A familiar story?






(L2VPN) VPLS PE


Link TE for Alto The kitchen sink?

A familiar story?




BGP is the “generic, scalable signalling mechanism” for IP/MPLS networks.

Protecting Networks from BGP Failures (Today)

BGPSPEAKER

A

BGPSPEAKER

B

TCP/BGP SESSION 1 - AFI 1

TCP/BGP SESSION 2- AFI 2

BGPSPEAKER

A

BGPSPEAKER

B

UPDATE

BGPSPEAKER

A

BGPSPEAKER

B

NOTIFICATION

Multi-Session BGP - either kludged (lo4, lo6…), or pre-standard! (Implemented and on-by-default in 12.2(33)SRC+)

Problems with Multi-Session… INTERNET

PE

INTERNETPE

INTERNETPE

INTERNETPE

INTERNETPE

INTERNETPE

INTERNETRR

IPv4

IPv6

“Internet” Networks BCP: IPv4 Unicast over IPv4 transport. IPv6 Unicast over IPv6 transport.

(or 6PE over IPv4 transport)

“VPN” Networks BCP: VPNv4 over IPv4 transport.

L3VPN

VPNv4

L3VPNPE

L3VPNRR

L3VPNPE

L3VPNPE

L3VPNPE

L3VPNPE

L3VPNPE

RT 1:1RT 1:2RT 1:3

All routes (or topologies) are affected due to a single error

within their <AFI,SAFI>!

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…)

Message Processing Complexities.

In stream processing, not all errors are created equal.

MARKER

HEADER: MSG LEN = 128

TOTAL PATH ATTRIBUTES LEN = 2000

MP_REACH_NLRI

COMMUNITY

AS_PATH

If we have length discrepancies – this can mean that we can’t accurately locate path attributes.

“Critical” error – no safe NLRI extraction.

MARKER

HEADER: MSG LEN = 128

TOTAL PATH ATTRIBUTES

MP_REACH_NLRI

COMMUNITY

AS4_PATH: (65535) 1273 5413 29636

Invalid attribute contents – we can parse the message, but something is malformed.

“Semantic” error – we know exactly which NLRI are contained.

Handling “Critical” Errors.

UPDATE

FIB

RIB

FIB

RIB

RTR A RTR B

FIB

RIB

FIB

RIB

RTR A RTR BNOTIFICATION

OPENRTR A RTR BERROR GR

OPENERROR GR

FIB

RIB

FIB

RIB

RTR A RTR BOPEN

STALE!

STALE!

Received UPDATE

invalid - cannot extract NLRI.

DATAIP

DATAIP

Re-use existing graceful-restart functionality to maintain forwarding on NOTIFICATION.

Handling “Semantic” Errors.

Erroneous advertisement interpreted as withdrawl of the NLRI.

ROUTE REFRESH

RTR A RTR B DST 192.0.2.0/24IP

Null0

RTR A RTR BRE-REQUEST

ROUTES

ONE-TIME ORF

RTC

RTR A RTR B

UPDATEADVERTISE

192.0.2.0/24

Received UPDATE

invalid - but concerns

192.0.2.0/24

RTR A RTR BUPDATE

WITHDRAW 192.0.2.0/24 via RTR A

Making errors visible to the NOC…

BGPROUTER

NOTIFICATIONOSS SNMP/SYSLOG

BGP to 192.0.2.1 is down -

NOTIFICATION received (3/4)

NOC

Today, an error with a BGP session is very visible to a NOC!

Without NOTIFICATION, we need a new way to signal an error occurred…

BGPROUTER

BGPROUTER

UPDATEOSS SNMP/

SYSLOGNOC

MUPNLRI:192.0.2.0/24192.168.0.0/16

OPERATIONAL

Local system generated invalid

UPDATE - 192.0.2.0/24 and 192.168.0.0/16 withdrawn by

1.2.3.4

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!

Questions?

Thanks (especially to Netnod!)

Further interest?

I’m always happy to discuss operational issues, and thoughts on solutions! Rob Shakir <[email protected]>

+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/

Date post:	12-May-2015
Category:	Documents
Upload:	rob-shakir
View:	337 times
Download:	4 times

Reinforcing the Kitchen Sink - Aligning BGP-4 Error Handling with Modern Network Requirements

Documents