detecting inconsistent advertisements from neighboring ases

28
Detecting Inconsistent Advertisements from Neighboring ASes Nick Feamster, M.I.T. Z. Morley Mao, University of Michigan Jennifer Rexford, AT&T Labs -- Research

Upload: others

Post on 12-Sep-2021

2 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Detecting Inconsistent Advertisements from Neighboring ASes

Detecting Inconsistent Advertisements from Neighboring ASes

Nick Feamster, M.I.T.Z. Morley Mao, University of Michigan

Jennifer Rexford, AT&T Labs -- Research

Page 2: Detecting Inconsistent Advertisements from Neighboring ASes

Settlement-Free Peering

Settlement-Free Interconnection Policy "3.1 Each Internet Network will announce consistent

customer routes at all interconnection points, unless both Internet Networks mutually agree otherwise based on special circumstances."

A peer should: 1. Advertise routes at all peering points. 2. The routes must have equal: - AS path length - MED values

Page 3: Detecting Inconsistent Advertisements from Neighboring ASes

Advertising Consistent Routes is Important

Enables an AS to perform "hot potato" routing.

AS 1

AS 2

"Hot−potato" Routing

AS 1

AS 2

If AS 1 does not advertise

cannot do "hot potato" routing!a consistent route on this session, AS 2

Page 4: Detecting Inconsistent Advertisements from Neighboring ASes

This Work Addresses Three Questions

Why do inconsistent advertisements happen? How can an AS detect inconsistent advertisements? How often do they appear in practice?

Page 5: Detecting Inconsistent Advertisements from Neighboring ASes

Why do inconsistent advertisements happen?

Intentional Cheating Misconfiguration Inconsistent export policies to a peer iBGP signaling partitions Inconsistent routes from customer Fundamental Limitations Mix of customer and peer routes (not all routers in the AS will select routes from the same AS)

Page 6: Detecting Inconsistent Advertisements from Neighboring ASes

Inconsistent Export Policies

route−map AS−A permit 10 set prepend 123

neighbor 10.1.2.3 route−map PEER outroute−map AS−A permit 10neighbor 10.4.5.6 route−map PEER out

set prepend 123123

AS 123

10.1.2.3 10.2.3.4

"rcc" detects inconsistent export policies.

http://nms.lcs.mit.edu/bgp/rcc/

Page 7: Detecting Inconsistent Advertisements from Neighboring ASes

iBGP Signaling Partitions

Router never learns route A

A

When iBGP is not configured correctly, all routers

may not learn "equally good" routes.

Page 8: Detecting Inconsistent Advertisements from Neighboring ASes

iBGP Signaling Partitions

AS Path Length = 3AS Path Length = 2

Router never learns route A

A B

Router never learns route B

When iBGP is not configured correctly, all routers

may not learn "equally good" routes.

Page 9: Detecting Inconsistent Advertisements from Neighboring ASes

iBGP Signaling Partitions

Route reflectors can cause more subtle partitions.

AS Path Length = 3AS Path Length = 2

Router never learns route A

A B

Route Reflectors

Router never learns route B

When iBGP is not configured correctly, all routers

may not learn "equally good" routes. (rcc also detects iBGP signaling partitions.)

Page 10: Detecting Inconsistent Advertisements from Neighboring ASes

Inconsistent Advertisements from a Customer

A B "No Export"

Customer AS

but does not readvertiseRouter selects route "B",

Some routers may select routes with "no export"

community.

Page 11: Detecting Inconsistent Advertisements from Neighboring ASes

Mix of Customer and Peer Routes

Customer 1

Peer 2

Peer 1

Router selects route "B"but won’ t export Peer 1’sroutes to Peer 2

A B

Some routers may select "customer" routes while others

select "peer" routes.

Page 12: Detecting Inconsistent Advertisements from Neighboring ASes

Mix of Customer and Peer Routes

Date: Thu Mar 13 1997 - 02:14:00 EST From: Randy Bush <[email protected]> Subject: consistent policy != consistent announcements

I have a peer P who connects to multihomed site M. I also have a customer C who connects to M. I will see M as either "P M" or "C M" - again equal length AS paths. If I follow the ’normal’ BGP path selection rules (and don’t always prefer customers over peers), then in some portions of my network, I will prefer M via P and in others I will prefer M via C.

Therefore, I will not announce any route to M to my peers in some locations, as I don’t announce peers to other peers, and in others I will announce "C M". Again, I do not make identical announcements to my peers, yet I have a consistent policy.

Page 13: Detecting Inconsistent Advertisements from Neighboring ASes

Problem Statement:

Detect when a neighboring AS does not announce "equally good" routes

on all peering sessions.

Page 14: Detecting Inconsistent Advertisements from Neighboring ASes

Ideally: Compare all eBGP routes from a peer

CB

A

AS A AS B

eBGP routescompare

This approach is not tenable today. Would require one of: vendor enhancements separate BGP feeds from all peers packet monitors on every link

Page 15: Detecting Inconsistent Advertisements from Neighboring ASes

Detecting inconsistent advertisements is hard

CB

A C

A

iBGP

AS A AS B

eBGP routes

Each router selectsbest eBGP−learned route.

No way to tell if Aand B are equally good!

Problem: Can’t see all eBGP-learned routes Thus, can’t always see all routes from a peer.

Page 16: Detecting Inconsistent Advertisements from Neighboring ASes

Questions

How to detect inconsistent advertisements with only

incomplete monitoring? (i.e., only the best route from each router)

Prevalence of inconsistent advertisements in practice: How often do inconsistent route advertisements happen

in practice?

How long do inconsistent route episodes last? How "severe" is the resulting cold potato routing?

Page 17: Detecting Inconsistent Advertisements from Neighboring ASes

Making inferences about "invisible" routes

1. Invert the import policies at each router 2. Infer properties of routes we don’t see based on the best route

CB

A

iBGPA’ C’

like before import policy.

"C is at least as good as B."2. Would like to say:

1. Figure out what route C looked

AS 1 AS 2

If route C is "worse" than A, then either: - B was worse than A - B was not advertised

Page 18: Detecting Inconsistent Advertisements from Neighboring ASes

When can we do this, given only iBGP routes?

The import policy: Must be invertible. Must not make consistent routes inconsistent.

Page 19: Detecting Inconsistent Advertisements from Neighboring ASes

Non-Invertible Import Policy

If AS path == "1" then prepend "1 1"

prepend "1"If AS path == "1 1" then

AS 1

"1 1""1"

Both routes have AS path "1 1 1"

Impossible to tell from iBGP routes alone whether eBGP routes are consistent.

Page 20: Detecting Inconsistent Advertisements from Neighboring ASes

Import Policy that Creates Inconsistent Routes

AS 1 AS 2

"1 4 6""1 5 6"

"2 7 8 6"If AS Path contains "5" then "depref" the route

and makes one route look worse.Import policy takes two routes with equal AS path lengths

Impossible to tell from iBGP routes alone

whether eBGP routes are consistent.

Page 21: Detecting Inconsistent Advertisements from Neighboring ASes

Questions

Prevalence of inconsistent advertisements in practice: How often do inconsistent route advertisements happen

in practice?

How long do inconsistent route episodes last? How "severe" is the resulting cold potato routing?

Page 22: Detecting Inconsistent Advertisements from Neighboring ASes

Inconsistent Advertisements Occur Continually

BGP Announcements from One Peer

05/01 05/02 05/03 05/04 05/05 05/06 05/07 05/08 05/090

100

200

300

400

500

600

700

800T

otal

num

ber

of in

cons

iste

nt p

refix

es

Page 23: Detecting Inconsistent Advertisements from Neighboring ASes

Most Events are Transient, Some Persistent

Missing Routes: 99% are shorter than 100 seconds. 0.1% of routes are inconsistent for entire week. Different AS Path Lengths: 99% are shorter than 100 seconds. All are shorter than 5 minutes.

BGP convergence causes most, but not all, inconsistencies.

Page 24: Detecting Inconsistent Advertisements from Neighboring ASes

Most Prefixes Consistent Most of the Time

BGP Announcements from One Peer

10

−410

−210

010

270

75

80

85

90

95

100

Percentage of time

Pct

g of

pre

fixes

inco

nsis

tent

for

time

x or

sho

rter

MissingPath Length

Page 25: Detecting Inconsistent Advertisements from Neighboring ASes

Some Peers are Persistently Inconsistent

BGP Announcements from Five Peers

10

−310

−210

−110

010

110

280

82

84

86

88

90

92

94

96

98

100

Percentage of time

Pct

g of

pre

fixes

inco

nsis

tent

for

time

x or

sho

rter

Peer 1Peer 2Peer 3Peer 4Peer 5

significantinconsistency

smallinconsistency

Page 26: Detecting Inconsistent Advertisements from Neighboring ASes

Conclusions

Settlement-free peering arrangements are violated. Until now, there has been no good way to detect these violations.

A monitoring protocol that dumped all eBGP routes would make this problem easy!

Thousands of inconsistent advertisements in a week. Most of these are due to convergence. (99% of inconsistencies last less than ~2 minutes.) Missing routes are more common that path length differences. Most peers advertise consistently in steady state. Some peers have consistent inconsistencies. In one case, more than 15% of prefixes were inconsistent for 70% of

the trace.

Page 27: Detecting Inconsistent Advertisements from Neighboring ASes
Page 28: Detecting Inconsistent Advertisements from Neighboring ASes

Most Events are Transient, Some Persistent

BGP Announcements from One Peer

10

010

210

410

610

−3

10−2

10−1

100

101

102

Event duration (sec)

Com

plem

enta

ry c

umul

ativ

e di

strib

utio

n MissingPath Length