Network Myths and Mysteries. Radia Perlman Intel Labs

Transcription

1 Network Myths and Mysteries Radia Perlman Intel Labs 1

2 All opinions expressed herein Are mine alone 2

3 All opinions expressed herein Are mine alone hough I m sure independently shared by lots of other people 3

4 Network Protocols A lot of what we all know is false! 4

5 How networking tends to be taught Memorize these RFCs Nothing else ever existed Except possibly to make snide comments about other teams 5

6 hings are so confusing Comparing technology A vs B Nobody knows both of them Somebody mumbles some vague marketing thing, and everyone repeats it Both A and B are moving targets 6

7 How I wish we d compare Isolate conceptual pieces Ignore which team 7

8 Orthogonal ways networks can differ What information is in a packet Who computes the forwarding table Whether forwarding table is always complete, or created on demand when a flow starts Whether switch can choose among multiple next hops How to translate from layer 3 to layer 2 address 8

9 What does a switch do? Forward based on: Info in packet Destination address If need to keep things in order, other stuff in packet (e.g., CP ports, flow ID, entropy field) Forwarding table lookup Destination: single port Destination: {ports} Flow : single port 9

10 Different types of Destination Lookup Direct lookup: simple and fast. Only possible if small enough address that table is not too large Hash (like Ethernet) Longest Prefix match (like IP) 10

11 houghts Flow-based vs destination-based Only way to make flow-based not totally explode the forwarding table is to create entry when flow starts (incur latency) Switch in better position to load-split traffic than central fabric manager If switch has to keep packets of a flow in order, switch can look at CP ports, etc., or have entropy field in header Switch can do new hash to adjust traffic 11

12 Exploiting parallel paths R1a R2a R3a R1b R2b R3b S R1c R2c R3c D R1d R2d R3d R1e R2e R3e Intel Confidential 12

13 Completely orthogonal concept 13

14 Where does forwarding table come from? Distributed algorithm Central fabric manager Neither concept new and completely orthogonal to data plane Concept of separation of control plane from data plane not new 14

15 Where does forwarding table come from? Distributed algorithm Central fabric manager Neither concept new and completely orthogonal to data plane I think distributed algorithm is superior, because it can react to topology changes more quickly 15

16 Where does forwarding table come from? Distributed algorithm Central fabric manager Neither concept new and completely orthogonal to data plane Distributed algorithm isn t what makes switches expensive 16

17 Also orthogonal: Fancy extra features 17

18 What kinds of features are in DC switches? Security features (firewalls, intrusion detection/protection, IPsec, SSL session termination) NA (and other stateful features) Multipathing raffic engineering/bandwidth guarantees Multiprotocol ports: layer 2 and layer 3; IPv4, IPv6 IP multicast Dynamic VLAN registration 18

19 When does forwarding table get filled in? Proactively When a flow starts 19

20 Proactively seems better 20

21 How do you manage a network? From a management console, which translates big commands, such as forward based on this metric or traffic engineer this path into individual commands to switches 21

22 How do you manage a network? From a management console, which translates big commands, such as forward based on this metric or traffic engineer this path into individual commands to switches Protocols define parameters that are settable, readable, events that trigger alerts 22

23 Management commands to switches SNMP Netconf YANG OpenFlow 23

24 Now, sorting out a few existing things IP, Ethernet, RILL, etc. 24

25 A bit of layer 3 history ISO s layer 3 (CLNP: ConnectionLess Network Protocol) 20 byte address op 14 bytes an entire cloud Inside cloud No configuration of switches Flat address space (bottom 6 bytes) Endnodes help by announcing to routers where they are Endnodes can move around and keep address 25

26 CLNP addresses 14 bytes: longest prefix match 6 bytes: exact match Endnode Which cloud address 26

27 In contrast: IP Every link has its own prefix Routers need to be configured If node moves, address has to change 27

28 Hierarchy One prefix per link (like IP) One prefix per campus (like CLNP) 22* 293* 28* 292* 25* 2* 2* 28

29 Advantages of CLNP over IP No configuration of routers inside a cloud Flat address within cloud so endnodes can move around within the cloud No need for ARP (since cloud address is carried within the layer 3 address) Other things not enough time to go into 29

30 Worst decision ever 1992 Internet could have adopted CLNP Easier to move to a new layer 3 back then Internet smaller Not so mission critical IP hadn t yet (out of necessity) invented DHCP, NA, so CLNP gave understandable advantages CLNP still has advantages over IPv6 (e.g., large multilink routed bottom layer) 30

31 So that s why we are stuck with both Ethernet and IP Need Ethernet to create a flat cloud at bottom layer for IP Original Ethernet CSMA/CD But now based on spanning tree 31

32 Constraint in 1983 for designing spanning tree ( transparent ) bridge No change to Ethernet frame (including adding to length) No change to endnode behavior 32

33 Spanning ree doesn t give A optimal paths X

34 hen length restriction ended 34

35 So RILL (Ransparent Interconnection of Lots of Links Allows clouds with flat address space, optimal routing, and no configuration of switches Evolutionary: Can replace any subset of spanning tree bridges with RILL switches First published about 10 years ago Been an IEF working group for about 8 years, initial version standardized about 3 years ago 35

36 Basic RILL concept RILL switches find each other (perhaps with bridges in between) Calculate paths to other RILL switches First RILL switch tunnels to last RILL switch 36

37 Basic RILL concept R4 R2 c R7 R9 R11 R5 R3 R8 R6 a R1 37

38 What s in RILL header? RILL switches autoconfigure a 2-byte nickname So header contains Ingress RILL switch (2 bytes) Egress RILL switch (2 bytes) Hop count Flags (e.g., unicast vs multicast) 38

39 RILL-encapsulated Ethernet pkt 6 bytes rill hdr Ethernet packet 39

40 RILL Header 2 bytes 2 bytes 2 bytes Egress nickname Ingress nickname Hop count flags 40

41 Unicast vs multicast use of egress field in RILL header Unicast: egress is last switch Multicast: egress is which tree 41

42 Multiple trees for multicast R1 R1 specifies which tree (yellow, red, or blue) 42

43 RILL switches find each other, creating network of just RILL switches b b b b b b b 43

44 b b b b b b b 44

45 endnodes b b b endnodes endnodes 45

46 endnodes b b endnodes endnodes 46

47 endnodes endnodes endnodes 47

48 Reason for extra header Forwarding table in RILL switches just size of # of RILL switches (not # of endnodes) Layer 3-like header (hop count) Small, easy to look up, addresses (16 bits can be direct lookup rather than prefix match or hash) 48

49 Switches inside cloud don t need to know about endnodes R4 R2 c R7 R9 R11 R5 R3 R8 R6 a R1 49

50 Gluing two clouds together S1 S3 50

51 Gluing two clouds together S1 Any tunnel: IP, IPsec, etc. S3 Only S1 and S3 need to know this RILL link isn t Ethernet 51

52 Advantage of CLNP vs IP+RILL No need for ARP: no layer 2 address. It s all part of layer 3 52

53 Some advantages of IP+RILL vs CLNP Easier forwarding lookup inside cloud (16 bit nicknames allows direct lookup) Smaller forwarding table in switches inside cloud (table size # of switches rather than endnodes) Ability to multipath multicast VLANs 53

54 How does R1 know R2 is last switch? Orthogonal concept to rest of RILL R1 needs table of (destination MAC, egress switch) Various possibilities Edge switch learns when decapsulating data, floods if destination unknown Configuration of edge switches Directory that R1 queries Central fabric manager pushes table 54

55 Orthogonal concept 55

56 Who encapsulates/decapsulates? Could be first switch Or hypervisor Or VM Or application Having endnode do it saves work for switch, easier to eliminate stale entries 56

57 Recently, a bunch of similar things invented NVGRE, VXLAN, 57

58 How to compare Inner packet based on flat address space IP or Ethernet IP header bigger, addresses smaller, well-known how to get unique Ethernet addresses without configuring Outer header location dependent RILL header small, nickname; simple forwarding lookup 58

59 So review some of what I said Proactive forwarding table vs incur latency when flow starts Distributed algorithm vs central fabric manager Load split based on fabric manager placing flows vs switch choosing among a set of next hops RILL evolutionary, efficient outer header, Ethernet for flat cloud, can glue distant clouds together by having RILL link which is a tunnel over IP 59

60 Questions? 60