CS 557 Distance Vector Routing RIPv2 - Carrying Additional - - PowerPoint PPT Presentation

CS 557 Distance Vector Routing RIPv2 - Carrying Additional Informatioin, RFC 1723, 1994

Detection of Invalid Routing Announcements in the RIP Protocol

• D. Pei, D. Massey, and L. Zhang, , 2003

Spring 2011

Distance Vector Protocols

• Employed in the early Arpanet
• Distributed next hop computation

– adaptive

• Unit of information exchange

– vector of distances to destinations

• Distributed Bellman-Ford Algorithm

Distributed Bellman-Ford

Start Conditions: Each router R starts with a vector of (zero) distances to all directly attached networks Send step: Each router advertises its current vector to all neighboring routers. Receive step: Upon receiving vectors from each of its neighbor N, for each destination D announced by N if next(R,D) == N or dist(R,D) > cost(R,N) + dist(N,D) dist(R,D) = cost(R,N) + dist(N,D) next(R,D) = N endif endfor

Example - Initial Distances

A B E C D Info at node A B C D A B C 7 ~ 7 1 ~ 1 ~ ~ 2 7 1 1 2 2 8 Distance to node D ~ ~ 2 E 1 8 ~ 2 1 8 ~ 2 E

E Receives D’s Routes

A B E C D Info at node A B C D A B C 7 ~ 7 1 ~ 1 ~ ~ 2 7 1 1 2 2 8 Distance to node D ~ ~ 2 E 1 8 ~ 2 1 8 ~ 2 E

E Updates Cost to C

A B E C D Info at node A B C D A B C 7 ~ 7 1 ~ 1 ~ ~ 2 7 1 1 2 2 8 Distance to node D ~ ~ 2 E 1 8 4 2 1 8 ~ 2 E

A Receives B’s Routes

A B E C D Info at node A B C D A B C 7 ~ 7 1 ~ 1 ~ ~ 2 7 1 1 2 2 8 Distance to node D ~ ~ 2 E 1 8 4 2 1 8 ~ 2 E

A Updates Cost to C

A B E C D Info at node A B C D A B C 7 8 7 1 ~ 1 ~ ~ 2 7 1 1 2 2 8 Distance to node D ~ ~ 2 E 1 8 4 2 1 8 ~ 2 E

A Receives E’s Routes

A B E C D Info at node A B C D A B C 7 8 7 1 ~ 1 ~ ~ 2 7 1 1 2 2 8 Distance to node D ~ ~ 2 E 1 8 4 2 1 8 ~ 2 E

A Updates Cost to C and D

A B E C D Info at node A B C D A B C 7 5 7 1 ~ 1 ~ ~ 2 7 1 1 2 2 8 Distance to node D 3 ~ 2 E 1 8 4 2 1 8 ~ 2 E

Final Distances

A B C D Info at node A B C D A B C 6 5 6 1 5 1 3 3 2 7 1 1 2 2 8 Distance to node D 3 3 2 E 1 5 4 2 1 5 4 2 E E

Final Distances After Link Failure

A B C D Info at node A B C D A B C 7 8 7 1 8 1 10 3 2 7 1 1 2 2 8 Distance to node D 10 3 2 E 1 8 9 11 1 8 9 11 E E

View From a Node

A B E C D dest A B C D A B D 1 14 5 7 8 5 6 9 4 4 11 2 7 1 1 2 2 8 Next hop E’s routing table

The Bouncing Effect

A 25 1 1 B C B C 2 1 dest cost A C 1 1 dest cost A B 1 2 dest cost

C Sends Routes to B

A 25 1 B C B C 2 1 dest cost A C 1 ~ dest cost A B 1 2 dest cost

B Updates Distance to A

A 25 1 B C B C 2 1 dest cost A C 1 3 dest cost A B 1 2 dest cost

B Sends Routes to C

A 25 1 B C B C 2 1 dest cost A C 1 3 dest cost A B 1 4 dest cost

C Sends Routes to B

A 25 1 B C B C 2 1 dest cost A C 1 5 dest cost A B 1 4 dest cost

Counting to Infinity

1 1 1 1

A B C D

• When link breaks, C marks D as

unreachable and reports that to A and B.

• Suppose A learns it first. A now

thinks best path to D is through

• B. A reports D unreachable to B

and a route of cost=3 to C.

• C thinks D is reachable through

A at cost 4 and reports that to B.

• B reports a cost 5 to A who

reports new cost to C.

• Distance increases until it

reaches infinity

– Infinity = 16 in RIP!

ARPANet in 1971[McQuillan:TOC78(12)]

Fail-Stop Failure Assumptions

My Distance to UCLA is Zero!

UCLA

• Fail-Stop: a router either works perfectly, or completely stops.

BGPmon ¡Relays ¡

Background ¡

22 ¡

• Autonomous ¡

System ¡(AS) ¡

• Border ¡Gateway ¡

Protocol ¡(BGP) ¡

• Profit-­‑driven ¡

policy ¡

AS ¡B ¡ ¡ AS ¡E ¡ AS ¡D ¡ AS ¡A ¡ AS ¡C ¡ I ¡own ¡prefix ¡p! ¡ AS ¡Path: ¡BE ¡ AS ¡Path: ¡ABE ¡ AS ¡Path: ¡DE ¡ AS ¡Path: ¡CBE ¡ Peer-­‑Peer ¡ Customer-­‑provider ¡ AS ¡update ¡message ¡

Background ¡(cont.) ¡

23 ¡ 23 ¡

AS ¡B ¡ ¡ AS ¡E ¡ AS ¡D ¡ AS ¡A ¡ AS ¡C ¡ AS ¡Path: ¡CBE ¡ Peer-­‑Peer ¡ Customer-­‑provider ¡ AS ¡update ¡message ¡ I ¡own ¡prefix ¡p! ¡ AS ¡Path: ¡CBA ¡ AS ¡Path: ¡BA ¡

• BGP ¡lacks ¡

authenJcaJon ¡

• Fabricated ¡AS ¡

announcement ¡

• Prefix ¡hijacking ¡

p ¡ April ¡8, ¡2010: ¡Chinese ¡ISP ¡ hijacks ¡the ¡Internet: ¡China ¡ Telecom ¡originated ¡37,000 ¡ prefixes ¡not ¡belonging ¡to ¡ them ¡in ¡15 ¡minutes, ¡causing ¡ massive ¡outage ¡of ¡services ¡

• globally. ¡

¡Why ¡Track ¡BGP ¡Prefixes? ¡

• Given ¡a ¡network ¡outage ¡report... ¡
• Are ¡key ¡sectors ¡such ¡a ¡financial, ¡ ¡criJcal ¡

infrastructure, ¡ ¡ ¡government ¡ ¡impacted? ¡

• What ¡is ¡the ¡geographic ¡range ¡of ¡the ¡event? ¡
• Is ¡it ¡an ¡unintenJonal ¡error ¡or ¡an ¡aXack? ¡
• Who ¡is ¡responsible ¡and ¡who ¡needs ¡to ¡act ¡to ¡

repair ¡it? ¡

10/9/2012 ¡ 24 WIT: ¡A ¡Watchdog ¡for ¡Internet ¡RouJng ¡

How ¡BGP ¡Data ¡CollecJon ¡Works ¡(1/3) ¡

• ISPs ¡around ¡the ¡world ¡
• ffer ¡to ¡provide ¡BGP ¡data ¡

¡

• Agree ¡data ¡can ¡be ¡made ¡

publically ¡available ¡to ¡any ¡

• perator ¡or ¡researcher ¡

¡ ¡

25 ¡ 10/9/2012 ¡ WIT: ¡A ¡Watchdog ¡for ¡Internet ¡RouJng ¡

Century ¡Link ¡ Telstra ¡ IIJ ¡ Level3 ¡ Telia ¡ Tiscali ¡ NepalIX ¡ France ¡Telecom ¡ Sprint ¡ Hurricane ¡ RUSnet ¡ CERNET ¡ KDDI ¡

WIDE ¡ Telefonica ¡

And ¡Many ¡Many ¡More ¡

26 ¡ WIT: ¡A ¡Watchdog ¡for ¡Internet ¡RouJng ¡

¡Routers ¡ To ¡Monitor ¡ ¡Oregon ¡IX ¡ ¡LINX ¡ ¡Sydney ¡ ¡BGP ¡Data ¡ Collectors ¡

10/9/2012 ¡

How ¡BGP ¡Data ¡CollecJon ¡Works ¡(2/3) ¡

• Monitoring ¡projects ¡deploy ¡

collectors ¡at ¡exchange ¡points ¡

• ISP ¡routers ¡peer ¡with ¡

collectors ¡

• To ¡the ¡ISP ¡router, ¡ ¡the ¡

collector ¡is ¡just ¡another ¡BGP ¡ peer ¡(e.g. ¡router) ¡

• Only ¡the ¡collector ¡never ¡

announces ¡any ¡routes! ¡ ¡ ¡

27 ¡ WIT: ¡A ¡Watchdog ¡for ¡Internet ¡RouJng ¡

¡Routers ¡ To ¡Monitor ¡ ¡Oregon ¡IX ¡ ¡LINX ¡ ¡Sydney ¡ ¡BGP ¡Data ¡ Collectors ¡

10/9/2012 ¡

How ¡BGP ¡Data ¡CollecJon ¡Works ¡(3/3) ¡

¡ ¡

¡ResulJng ¡ ¡ Data ¡ ¡ Archive ¡

• All ¡Route ¡Updates ¡Are ¡

Logged ¡ ¡

• 15 ¡minute ¡intervals ¡
• Collector ¡also ¡archives ¡

rouJng ¡table ¡of ¡each ¡peer ¡ router ¡

• 2 ¡hour ¡intervals ¡

¡ ¡

hXp://archive.routeviews.org/bgpdata/ ¡

Oregon ¡RouteViews ¡Today ¡

10/9/2012 ¡ WIT: ¡A ¡Watchdog ¡for ¡Internet ¡RouJng ¡ 29

Real-­‑Time ¡Data ¡Access ¡

• Fundamental ¡Changes ¡In ¡Monitoring ¡Infrastructure ¡

– Provide ¡real-­‑Jme ¡access ¡to ¡route ¡tables ¡and ¡incremental ¡updates ¡ – Manage ¡table ¡transfers ¡and ¡update ¡bursts ¡from ¡routers ¡ – Scale ¡to ¡large ¡numbers ¡of ¡BGP ¡peers ¡ – Scale ¡to ¡vast ¡numbers ¡of ¡clients ¡ – Protect ¡monitoring ¡system ¡from ¡slow ¡or ¡misconfigured ¡clients ¡ ¡

• Requires ¡Soiware ¡Dedicated ¡to ¡Monitoring ¡

– BGPmon: ¡ ¡dedicated ¡soiware ¡for ¡monitoring ¡and ¡real-­‑Jme ¡delivery ¡ – XML ¡format ¡for ¡resulJng ¡data ¡with ¡integrated ¡updates ¡and ¡tables ¡

• BGPmon ¡overcomes ¡both ¡design ¡and ¡ ¡deployment ¡challenges ¡

CollecJng ¡RouJng ¡Data ¡ (Oregon ¡RouteViews ¡+ ¡BGPmon) ¡

BGPmon ¡Architecture ¡

Routeviews ¡ Collector ¡ BGPmon ¡ Collector ¡ Routers ¡ Peer ¡ Thread ¡ Peer ¡ Thread ¡ Peer ¡ Thread ¡ Chain ¡ Thread ¡ MRT ¡ Thread ¡ MRT ¡ Thread ¡ In-­‑ ¡Memory ¡ Backlog ¡ RIB ¡ Label ¡ Thread ¡ XML ¡ Thread ¡ Client ¡ Thread ¡ Client ¡ Thread ¡ Client ¡ Thread ¡ Client ¡ Thread ¡

Stage ¡1 ¡ Stage ¡2 ¡ Stage ¡3 ¡ Stage ¡4 ¡

Peer ¡Queue ¡ MRT ¡Queue ¡ Labeling ¡ ¡Queue ¡ Update ¡ Queue ¡ Periodic ¡ Thread ¡ RIB ¡ Queue ¡ BGPmon ¡ Collector ¡

BGPmon ¡Architecture ¡ (with ¡chaining) ¡

The ¡Assignment: ¡

Replace ¡Chaining ¡with ¡light-­‑weight ¡Relays ¡

BGPmon ¡ (P1-­‑P10) ¡ BGPmon ¡ (P11-­‑P20) ¡ BGPmon ¡ (P21-­‑P30) ¡ Relay ¡ Relay ¡ Relay ¡ Relay ¡ Relay ¡

BGPmon ¡ (P1-­‑P10) ¡ BGPmon ¡ (P11-­‑P20) ¡ BGPmon ¡ (P21-­‑P30) ¡ Relay ¡ Relay ¡ Relay ¡ Relay ¡ Relay ¡

Challenges ¡

• Loop ¡DetecJon ¡

– Drop ¡on ¡arrival ¡is ¡too ¡expensive ¡

• Path ¡Choice ¡(addiJon/removal ¡of ¡clients/

relays) ¡

– Local ¡(greedy ¡decisions) ¡may ¡prevent ¡other ¡clients ¡ from ¡gemng ¡data ¡ – Global ¡decision ¡may ¡be ¡NP-­‑hard ¡

• This ¡is ¡a ¡research/open ¡quesJon ¡

Definition The BGPmon mesh can be described as a directed graph G=(V,E,W). Let V = the full set of vertices. V = (P, R, C)where P, R and C are disjoint sets. P = the set of provider (source) vertices. These are peers. R = the set of relay vertices. I am including collectors as relays. C = the set of consumer vertices (clients). Let E = the set of directed edges in the graph. Let KV = the capacity at each vertex in V Let KE = the capacity at each edge in E Let D = the data from each provider dp ∈ D ∧ dp is the data from provider p Contraints: < vi, vj >∈ E → vi / ∈ C ∧ vj / ∈ P < vi, vj > ∧vi ∈ C → vj / ∈ P < vi, vj > carries all data from dp or no data from dp Assume v ∈ Corv ∈ R → v receives dp through only one edge Σd over edge e ≤ ke The traffic coming into a node must not exceed the nodes capabilities Data must not be sent, just to be dropped due to loop detection Each node may receive exactly 0 or 1 copies of each piece of data

Assignment ¡

• Part ¡I: ¡Soiware ¡

Engineering ¡

– Write ¡a ¡BGPmon ¡client ¡ – Expand ¡the ¡client ¡to ¡act ¡as ¡ a ¡server ¡that ¡can ¡accept ¡ client ¡connecJons ¡ – Will ¡need ¡a ¡threaded ¡ soluJon ¡ – Expand ¡client ¡to ¡connect ¡to ¡ mulJple ¡servers ¡ – Implement ¡simple ¡loop ¡ detecJon ¡

• Part ¡II: ¡Less ¡Engineering/ ¡

More ¡Research ¡

– Outcome ¡1: ¡

• Write ¡an ¡algorithm ¡and ¡

implement ¡it ¡for ¡relay ¡ rouJng ¡

• Must ¡saJsfy ¡constraints ¡as ¡

laid ¡out ¡on ¡project ¡website ¡

– Outcome ¡2: ¡

• Present ¡a ¡proof ¡that ¡our ¡

the ¡problem ¡is ¡NP-­‑hard ¡

• Write ¡a ¡heurisJc ¡and ¡

implement ¡it ¡