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 Human errors are unavoidable 2

Errors lead to policy violaAons Policy ViolaAon Network verificaAon is important 3

Some violaAons only occur under failures R C R B DST 1 OSPF 3 1 R A SRC Network verificaAon under arbitrary failures is required 4

State-of-the-art verificaAon with failures • Analyze current data plane [HSA NSDI’13, VeriFlow NSDI’13] – Cannot verify policies across failures • Simulate low level protocol messages [Ba[ish NSDI’15] • Generate data planes for each failure case – Time consuming Forwarding Forwarding Forwarding Forwarding Forwarding Forwarding Forwarding Forwarding Table’ Table Table’ Table Table’’ Table’’ Table’’’ Table’’’ Forwarding Forwarding Forwarding Forwarding Table’ Table Table’’ Table’’’ 5

How do we speedup network verificaAon under failures ? Network Graph verificaAon Analysis under failures 6

Network verificaAon under failures using graph algorithms 4 2 2 10 6 …... 0 1.2 Network configuraAons CollecAon of weighted digraphs • 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 7

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 4 2 2 2 10 6 0 10 1.2 6 • Actual path under parAcular failure scenario is obtainable through graph traversal 9

ARC construcAon: First steps Shortest path OSPF BGP D A SRC 10 1 1 SRC 10 DST 10 C DST 20 20 20 1 1 10 1 E B 10 1 10 Opportuni:es Challenges • Network topology is • Route redistribuAon essenAally a graph • RouAng cost varies / protocol • RouAng protocols do least • AdministraAve Distance Need sophisAcated approaches to determine cost forwarding • Traffic class filters graph structure and edge weights – OSPF: Djikstra’s Algorithm • RouAng granulariAes using OSPF weights • … – BGP: Min AS hops 10

ARC ConstrucAon: Graph Structure Inter-device: adver:sements D ST :T X.3 I Y.3 O Z.3 I T X Y 2 OSPF 3 3 X.3 O Y.3 I Z.3 O 1 Z BGP 1 Intra: Route S RC :S redistribu:on A S B A.1 I B.1 O Z.1 I Intra: within device forwarding A.1 O B.1 I Z.1 O • One directed graph per Src-Dst subnet pair • Ver:ces : hosts, rouAng processes • Edges : flow of data enabled by exchange of rouAng informaAon 11

ARC construcAon: Edge weights For single rouAng instance, • use: D ST :T X.3 I Y.3 O Z.3 I 0.4 2 0.6 3 OSFP link weights • 0 0 0 BGP hop counts • Z.5 O X.3 O 2 Y.3 I 3 Z.3 O 0.4 0.6 MulAple processes: AD? • S RC :S 1 2 RedistribuAon? A.1 I B.1 O Z.1 I 1 1 Normalize weights across • 0 0 0 instances A.1 O B.1 I Z.1 O 1 1 Novel algorithm for scaling • Shortest path in ARC weights == actual path 12

Policy verificaAon using ARCs Does the graph saAsfy some Is a policy :: property ? violated in the network? What graph algorithms to use ? 13

Verify always blocked policy Does there exist Is communicaAon a path from SRC :: between SRC and DST to DST in the not allowed under any corresponding failure scenario? ARC? Connected components DST C D ST S RC 1 B C O D I 1 3 SRC C I D O D 14

Verify ‘k-’reachability policy Are there ’k’ edge-disjoint Is DST always :: paths from SRC to DST ? reachable from SRC with ‘< k’ failures ? Max-flow algorithm on ARC F O G O F G OSPF 1 ∞ F I G I E E O C B E I B I C I D ST D D O DST SRC B O C O D I 3 edge-disjoint paths S RC Max-flow = 3 15

Verify path equivalency Is a traffic class forwarded :: Are ARCs the same ? in the same manner, before and aner a configuraAon change? u 2 w 2 u 6 w 6 u 1 w 1 ? u 1 w 1 u 3 u 7 w 3 w 7 u 4 u 10 w 4 w 10 u 8 w 8 u 5 w 5 u 9 w 9 • Re-scaling algorithms can result in different weights • Reduce weights to canonical form and compare 16

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 Time to build ARCs (seconds) Parse configuraAons Build ARC from scratch Networks (sorted by size) Fast (<10 seconds) even for large networks 20

Time to verify ARC Always blocked Always reachable Equivalent paths (connected components) with < k failures (convert to canonical (max flow) weights and compare) < 500 ms < 1 sec Up to 100 s • VerificaAon per traffic class is parallelizable 21

Comparison with Ba[ish Always blocked Always blocked using ARC using BaCish < 500 ms Up to 694 days! 3 - 5 orders of magnitude speedup 22

ARC fidelity • 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 23

ARC fidelity • For remaining networks – We can sAll generate the graph structure – Cannot generate edge weights – Verify “always blocked”, “k-reachability” All properAes can be verified 96% 4% Cannot verify path equivalence 24

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(10 3 )-O(10 5 ) speedup in verificaAon hDps://bitbucket.org/uw-madison-networking-research/arc 25

26