Homework Assignment #1 1 Homework Assignment • Part 1: LAN setup – All nodes are hosts (including middle nodes) – Each link is its own LAN, with its own IP subnet – Can ARP and ping only to directly-connected hosts H H H H H H H H 2 Homework Assignment • Part 2: Writing your own switch – Middle nodes are switches and know nothing about IP – Switches transit Ethernet frames between interfaces – All hosts belong to a common IP subnet H H H H S S H H 3 Homework Assignment • Part 3: Fun with OSPF – All nodes are routers running Quagga – Each link is its own (say, /30) subnet – Each node has an OSPF adjacency with each neighbor R R R R R R R R 4 Homework Suggestions • Automation with scripts – Generate the host, Click, and OSPF configuration – Faster, less error-prone, and saves your work • Checking the host configuration – ifconfig – arp -a • Passive monitoring – Tcpdump on host interfaces – ListenEther on switches • Start simple – E.g., two hosts connected to a single switch or router 5 Enterprise Configuration Jennifer Rexford Fall 2010 (TTh 1:30-2:50 in COS 302) COS 561: Advanced Computer Networks http://www.cs.princeton.edu/courses/archive/fall10/cos561/ Outline • Enterprise network components – Repeaters/hubs, bridges/switches, and routers • Enterprise network design – Hubs and switches, with DHCP server – Ethernet subnets interconnected by routers • Flexible connectivity – Virtual Local Area Networks (VLANs) – Multi-homing to multiple ISPs – Interconnecting multiple enterprise locations • Discussion of papers – VLAN survey and SEATTLE architecture 7 Enterprise Network Components 8 Physical Layer: Repeaters • Distance limitation in local-area networks – Electrical signal becomes weaker as it travels – Imposes a limit on the length of a LAN • Repeaters join LANs together – Analog electronic device – Continuously monitors electrical signals on each LAN – Transmits an amplified copy Repeater 9 Physical Layer: Hubs • Joins multiple input lines electrically – Do not necessarily amplify the signal – Very similar to repeaters • Disadvantages – Limited aggregate throughput due to shared link – Cannot support multiple rates or formats hub (e.g., 10 Mbps vs. 100 Mbps Ethernet) – Limitations on maximum # of nodes and physical distance hub hub 10 Link Layer: Bridges • Connects two or more LANs at the link layer – Extracts destination address from the frame – Looks up the destination in a table – Forwards the frame to the appropriate LAN segment • Each segment can carry its own traffic host host host host host host host host Bridge host host host host 11 Link Layer: Switches • Typically connects individual computers – A switch is essentially the same as a bridge – Supports concurrent communication • Cut-through switching – Start forwarding a frame while it is still arriving switch/bridge segment hub segment segment hub hub 12 Hubs, Switches, and Routers Hub/ Bridge/ Router Protocol layer Repeater physical Switch link Traffic isolation no yes yes Plug and play yes yes no Efficient routing no no yes Cut through yes yes no networ k 13 Enterprise Network Design 14 Simple Enterprise Design • A single layer-two subnet – Hubs and switches – Gateway router connecting to the Internet – ISP announces the address block into BGP • Local services: DHCP and DNS S 1.2.3.1 S DHCP server 1.2.3.0/24 Internet G 1.2.3.76 0.0.0.0/0 S 1.2.3.5 1.2.3.150 S DNS server 15 Scalability Limitations • Spanning tree – Paths that are longer than necessary – Heavy load on the root bridge – Bandwidth wasted for links not in the tree • Forwarding tables – Bridge tables grow with number of hosts • Broadcast traffic – ARP and DHCP – Applications that broadcast (e.g., iTunes) • Flooding – Frames sent to unknown destinations 16 Hybrid of Switches and Routers • Layer-two subnets interconnected by routers – No plug-and-play and mobility between layer-2 subnets – Need consistent configuration of IP routing and DHCP 1.2.3.0/26 Ethernet Bridging - Flat addressing - Self-learning - Flooding - Forwarding along a tree R R IP Routing - Hierarchical addressing - Subnet configuration - Host configuration - Forwarding along shortest paths 1.2.3.192/26 R Internet R 1.2.3.128/26 R 1.2.3.64/26 17 Virtual Local Area Networks (VLANs) 18 Evolution Toward Virtual LANs • In the olden days… – Thick cables snaked through cable ducts in buildings – Every computer they passed was plugged in – All people in adjacent offices were put on the same LAN – Independent of whether they belonged together or not • More recently… – Hubs and switches changed all that – Every office connected to central wiring closets – Often multiple LANs (k hubs) connected by switches – Flexibility in mapping offices to different LANs Group users based on organizational structure, rather than the physical layout of the building. 19 Why Group by Organizational Structure? • Privacy – Ethernet is a shared media – Any interface card can be put into “promiscuous” mode – … and get a copy of any flooded/broadcast traffic – So, isolating traffic on separate LANs improves privacy • Load – Some LAN segments are more heavily used than others – E.g., researchers running experiments get out of hand – … can saturate their own segment and not the others – Plus, there may be natural locality of communication – E.g., traffic between people in the same research group 20 People Move, and Roles Change • Organizational changes are frequent – E.g., faculty office becomes a grad-student office – E.g., graduate student becomes a faculty member • Physical rewiring is a major pain – Requires unplugging the cable from one port – … and plugging it into another – … and hoping the cable is long enough to reach – … and hoping you don’t make a mistake • Would like to “rewire” the building in software – The resulting concept is a Virtual LAN (VLAN) 21 Example: Two Virtual LANs R O O R O O R R O RO O R R O R O R Red VLAN and Orange VLAN Switches forward traffic as needed 22 Making VLANs Work • Changing the Ethernet header – Adding a field for a VLAN tag – Implemented on the bridges/switches – … but can still interoperate with old Ethernet cards • Bridges/switches trunk links – Saying which VLANs are accessible via which interfaces • Approaches to mapping access links to VLANs – Each interface has a VLAN color Only works if all hosts on same segment belong to same VLAN – Each MAC address has a VLAN color Useful when hosts on same segment belong to different VLANs Useful when hosts move from one physical location to another 23 Multi-Homing 24 Motivation for Multi-Homing • Benefits of multi-homing – Extra reliability, e.g., survive single ISP failure – Financial leverage through competition – Better performance by selecting better path – Gaming the 95th-percentile billing model ISP 1 ISP 2 1.2.3.0/24 25 Multi-Homing Without BGP Inbound Traffic • Ask each ISP to originate the IP prefix Outbound Traffic • One ISP as a primary, the other as a backup • … to rest of the Internet • Or simple load balancing of all traffic ISP 1 ISP 2 1.2.3.0/24 26 Multi-Homing With BGP • Inbound traffic – Originate the prefix to both providers – Do not allow traffic from one ISP to another • Outbound traffic – Select the “best” route for each remote prefix – Define BGP policies based on load, performance, cost ISP 1 ISP 2 BGP sessions 1.2.3.0/24 “Intelligent route control” or “multihomed traffic engineering”. 27 Interconnecting Multiple Enterprise Sites 28 Challenges • Challenges of interconnecting multiple sites – Performance – Reliability – Security – Privacy • Solutions – Connecting via the Internet using secure tunnels – Virtual Private Network (VPN) service – Dedicated backbone between sites 29 Connecting Via the Internet • Each site connects to the Internet – Encrypted tunnel between each pair of sites – Packet filtering to block unwanted traffic – But, no performance or reliability guarantees Site 1 Internet Site 2 Site 3 30 Virtual Private Network (VPN) • Each site connects to a common VPN provider – Provider allows each site to announce IP prefixes – Separate routing/forwarding table for each customer – Performance guarantees by overprovisioning resources Site 1 VPN Provider Site 2 Site 3 31 Conclusions • Simple enterprise network is (mostly) plug and play – Ethernet with MAC learning and spanning tree – DHCP server to assign IP addresses from single subnet – Gateway router with default route to the Internet • Quickly starts to require configuration – Choosing the root bridge in the spanning tree – Consistent configuration of DHCP and IP routers – VLAN access and trunk link configuration – Access control for traffic between VLANs – BGP sessions and routing policy • Discussion of the two papers 32 Discussion • Flat vs. hierarchical addressing? • Roles of the end host vs. the network? • How to best support flexible policies? • Alternatives or extensions to VLANs? 33 Backup Slides on VLAN Survey 34 Uses of VLANs • Scoping broadcast traffic • Simplifying access control policies • Decentralizing network management • Enabling host mobility 35 Problem: Limited Granularity • Limited number of VLANs – Placing multiple groups in the same VLAN – Reusing limited VLAN • Limited number of hosts per VLAN – Divide a large group into multiple VLANs • One VLAN per access port – Supporting VLANs on the end host – Supporting multiple groups at the router 36 Problem: Complex Configuration • Host address assignment – Wasting IP addresses – Complex host address assignment • Spanning tree computation – Limitation of automated trunk configuration – Enabling extra links to survive failures – Distributing load over the root bridges 37 Backup Slides on SEATTLE 38 Avoiding Flooding • Bridging uses flooding as a routing scheme – Unicast frames to unknown destinations are flooded “Don’t know where destination is.” “Send it everywhere! At least, they’ll learn where the source is.” – Does not scale to a large network • Objective #1: Unicast unicast traffic – Need a control-plane mechanism to discover and disseminate hosts’ location information Restraining Broadcasting • Liberal use of broadcasting for bootstrapping (DHCP and ARP) – Broadcasting is a vestige of shared-medium Ethernet – Very serious overhead in switched networks • Objective #2: Support unicast-based bootstrapping – Need a directory service • Sub-objective #2.1: Yet, support general broadcast – Nonetheless, handling broadcast should be more scalable Keeping Forwarding Tables Small • Flooding and self-learning lead to unnecessarily large forwarding tables – Large tables are not only inefficient, but also dangerous • Objective #3: Install hosts’ location information only when and where it is needed – Need a reactive resolution scheme – Enterprise traffic patterns are better-suited to reactive resolution Ensuring Optimal Forwarding Paths • Spanning tree avoids broadcast storms. But, forwarding along a single tree is inefficient. – Poor load balancing and longer paths – Multiple spanning trees are insufficient and expensive • Objective #4: Utilize shortest paths – Need a routing protocol • Sub-objective #4.1: Prevent broadcast storms – Need an alternative measure to prevent broadcast storms Backwards Compatibility • Objective #5: Do not modify end-hosts – From end-hosts’ view, network must work the same way – End hosts should Use the same protocol stacks and applications Not be forced to run an additional protocol SEATTLE in a Slide • Flat addressing of end-hosts – Switches use hosts’ MAC addresses for routing – Ensures zero-configuration and backwards-compatibility (Obj # 5) • Automated host discovery at the edge – Switches detect the arrival/departure of hosts – Obviates flooding and ensures scalability (Obj #1, 5) • Hash-based on-demand resolution – Hash deterministically maps a host to a switch – Switches resolve end-hosts’ location and address via hashing – Ensures scalability (Obj #1, 2, 3) • Shortest-path forwarding between switches – Switches run link-state routing to maintain only switch-level topology (i.e., do not disseminate end-host information) – Ensures data-plane efficiency (Obj #4) How does it work? x Deliver to x Host discovery or registration C Optimized forwarding directly from D to A y Traffic to x A Hash (F(x) = B) Tunnel to egress node, A Entire enterprise (A large single IP subnet) Switches End-hosts Control flow Data flow Tunnel to relay switch, B LS core Notifying <x, A> to D Store B <x, A> at B D Hash (F(x) = B) E Terminology Dst x < x, A > shortest-path forwarding A y Src Ingress Egress D < x, A > Relay (for x) B < x, A > Ingress applies a cache eviction policy to this entry Responding to Topology Changes • The quality of hashing matters! h h A E h F h h B Consistent Hash minimizes re-registration overhead h h h D h h C 47 Single Hop Look-up y sends traffic to x y x A E Every switch on a ring is logically one hop away B F(x) D C 48 Responding to Host Mobility Old Dst x < x, G > < x, A > when shortest-path forwarding is used A y Src D < x, A > < x, G > Relay (for x) New Dst G B < x, G > < x, A > < x, G > 49 Unicast-based Bootstrapping: ARP • ARP – Ethernet: Broadcast requests – SEATTLE: Hash-based on-demand address resolution 4. Broadcast ARP req for a Owner of (IPa ,maca) b sb a 1. Host discovery sa 2. Hashing 6. Unicast ARP req to ra F(IPa) = ra 5. Hashing F(IPa) = ra 7. Unicast ARP reply (IPa , maca , sa) to ingress Switch End-host Control msgs ARP msgs ra 3. Storing (IPa ,maca , sa) Unicast Bootstrapping: DHCP • DHCP – Ethernet: Broadcast requests and replies – SEATTLE: Utilize DHCP relay agent (RFC 2131) Proxy resolution by ingress switches via unicasting 4. Broadcast DHCP discovery DHCP server (macd=0xDHCP) d 6. DHCP msg to r 8. Deliver DHCP msg to d 1. Host discovery sd 2. Hashing End-host Control msgs DHCP msgs sh 5. Hashing 7. DHCP msg to sd F(macd) = r Switch h r 3. Storing (macd , sd) F(0xDHCP) = r Prototype Implementation • Link-state routing: eXtensible Open Router Platform • Host information management and traffic forwarding: Click XORP Click Interface Networ k Map OSPF Daemon User/Kernel Click Routing Table Ring Manager Host Info Manager Link-state advertisements from other switches Host info. registration and notification messages SeattleSwitch Data Frames Data Frames