Fast Control Plane Analysis Using an Abstract Representation Aaron - - PowerPoint PPT Presentation

Fast Control Plane Analysis Using an Abstract Representation

Aaron Gember-Jacobson, Raajay Viswanathan, Aditya Akella, Ratul Mahajan

1

ConfiguraAon errors are common

• MulAple rouAng protocols
• RouAng process prioriAes
• Route exchange
• Traffic SelecAvity

– Route Filters – ACLs

2

Human errors are unavoidable

Errors lead to policy violaAons

3

Network verificaAon is important

ViolaAon Policy

Some violaAons only occur under failures

4

RC RB RA

OSPF

1 1 3 SRC DST

Network verificaAon under arbitrary failures is required

State-of-the-art verificaAon with failures

• Analyze current data plane [HSA NSDI’13, VeriFlow NSDI’13]

– Cannot verify policies across failures

5

Forwarding Table Forwarding Table Forwarding Table Forwarding Table’ Forwarding Table’ Forwarding Table’ Forwarding Table’’ Forwarding Table’’ Forwarding Table’’ Forwarding Table’’’ Forwarding Table’’’ Forwarding Table’’’

• Simulate low level protocol messages [Ba[ish NSDI’15]
• Generate data planes for each failure case

– Time consuming

6

How do we speedup network verificaAon under failures ?

Network verificaAon under failures Graph Analysis

Network verificaAon under failures using graph algorithms

7

Network configuraAons

• Graphs encode the network’s forwarding behavior under all

possible failure scenarios

• VerificaAon reduces to checking simple graph-level properAes

à polynomial :me

• CollecAon of digraphs à ARC: Abstract RepresentaAon for

Control planes

2 2 4 1.2 10 6

CollecAon of weighted digraphs

…...

Outline

• MoAvaAon
• Requirements & Challenges for ARC creaAon
• Our approach for construcAng ARCs
• Network verificaAon using ARCs
• EvaluaAon

8

Requirement: Encoding forwarding behaviors under all failures

• Graph contains all possible paths in the actual

network

• Actual path under parAcular failure scenario is
• btainable through graph traversal

9

2 2 4 1.2 10 6 6 2 10

ARC construcAon: First steps

• Network topology is

essenAally a graph

• RouAng protocols do least

cost forwarding

– OSPF: Djikstra’s Algorithm using OSPF weights – BGP: Min AS hops

• Route redistribuAon
• RouAng cost varies / protocol
• AdministraAve Distance
• Traffic class filters
• RouAng granulariAes
• …

10

Shortest path SRC DST

Need sophisAcated approaches to determine graph structure and edge weights

Opportuni:es Challenges

1 1 1 1 1 1 10 10 10 10 20 20 OSPF BGP SRC DST A D E B C 20 10 10

ARC ConstrucAon: Graph Structure

• One directed graph per Src-Dst subnet pair
• Ver:ces: hosts, rouAng processes
• Edges: flow of data enabled by exchange of rouAng

informaAon

11

SRC:S DST:T A.1I A.1O B.1I B.1O Z.1I Z.1O Z.3I Z.3O Y.3O Y.3I X.3I X.3O Z B X BGP1 OSPF3 T S Y

1 2

A

3

Inter-device: adver:sements Intra: Route redistribu:on Intra: within device forwarding

2

Z.5O

ARC construcAon: Edge weights

• For single rouAng instance,

use:

• OSFP link weights
• BGP hop counts
• MulAple processes: AD?

RedistribuAon?

• Normalize weights across

instances

• Novel algorithm for scaling

weights

12

SRC:S DST:T A.1I A.1O B.1I B.1O Z.1I Z.1O Z.3I Z.3O Y.3O Y.3I X.3I X.3O

1 1 1 1 2 2 3 3 1 0.4 0.6 0.4 0.6

Shortest path in ARC == actual path

Policy verificaAon using ARCs

13

Is a policy violated in the network?

::

Does the graph saAsfy some property ? What graph algorithms to use ?

Verify always blocked policy

14

CI CO DO DI DST SRC

Is communicaAon between SRC and DST not allowed under any failure scenario?

::

Does there exist a path from SRC to DST in the corresponding ARC? Connected components

SRC DST

3 1 1

D C B

Verify ‘k-’reachability policy

15

Max-flow = 3

DO DI EO EI FO FI GO GI CO CI BO BI DST SRC OSPF ∞

1

Is DST always reachable from SRC with ‘< k’ failures ? Are there ’k’ edge-disjoint paths from SRC to DST ? Max-flow algorithm on ARC

::

SRC DST

D C B F G

3 edge-disjoint paths

E

Verify path equivalency

• Re-scaling algorithms can result in different weights
• Reduce weights to canonical form and compare

16

?

u2 u1 u3 u1 u5 u4 u8 u7 u6 u9 u10 w2 w1 w3 w1 w5 w4 w8 w7 w6 w9 w10

Is a traffic class forwarded in the same manner, before and aner a configuraAon change? Are ARCs the same ?

::

AddiAonal properAes we can verify

• Always isolated: Traffic of different tenants

are always isolated

• Always traverse waypoints: Traffic between

hosts always traverse waypoints

17

EvaluaAon

• ARC construcAon performance
• ARC verificaAon performance
• ARC fidelity

18

Network configuraAons

• ConfiguraAons from 314 data

center networks operated by a large online service provider

19

Time to generate ARC

20

Fast (<10 seconds) even for large networks

Time to build ARCs (seconds) Networks (sorted by size) Parse configuraAons Build ARC from scratch

Time to verify ARC

21

Always blocked (connected components) Always reachable with < k failures (max flow) Equivalent paths (convert to canonical weights and compare) < 500 ms Up to 100 s < 1 sec

• VerificaAon per traffic class is parallelizable

Comparison with Ba[ish

22

Always blocked using ARC Always blocked using BaCish < 500 ms Up to 694 days!

3 - 5 orders of magnitude speedup

ARC fidelity

23

• For any given failure scenario, is ARC shortest

path == actual network path?

• Formally prove ARC fidelity for networks with:

– RouAng protocols : OSPF, RIP, BGP – Route redistribuAon is acyclic – Route selecAon preference follow a global order

96% of networks saAsfy these properAes

ARC fidelity

24

• For remaining networks

– We can sAll generate the graph structure – Cannot generate edge weights – Verify “always blocked”, “k-reachability”

96% 4%

All properAes can be verified Cannot verify path equivalence

Summary

• Network verificaAon under

failures can be formulated as graph analysis

• Presented an abstract

representaAon, ARC

• Can construct high fidelity ARCs

for 96% of networks

• O(103)-O(105) speedup in

verificaAon

25

hDps://bitbucket.org/uw-madison-networking-research/arc

26