• Like

Evolving Enterprise Network Architecture

  • 501 views
Uploaded on

The enterprise network is being transformed by cloud computing, BYOD, multimedia over IP and pervasive Wi-Fi. These technologies are still relatively early in the adoption cycle, but we can see the …

The enterprise network is being transformed by cloud computing, BYOD, multimedia over IP and pervasive Wi-Fi. These technologies are still relatively early in the adoption cycle, but we can see the direction they are taking. But other, arguably more fundamental changes in network architecture are in the pipeline, driven by the adoption of IPv6, very-high-speed Wi-Fi, the increased penetration of consumer technologies and software-defined network architectures. This talk will touch on these areas, drawing on the experiences of early-adopters of new WLANs with a dash of medium-term vision. It will pose questions for network architects looking out several years, and hopefully provide some of the answers.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
501
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
10
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Where are we going? 1 @arubanetworks @arubanetworks
  • 2. Some of the forces driving WLAN (re)design Consumer devices in the enterprise Migration to the cloud 2 Migration to IPv6
  • 3. Why do we need VLANs? • VLANs split up L2 subnets to control excessive broadcast & multicast traffic • We sometimes use VLANs to segregate traffic for security • VLANs can help us manage geographically distributed networks (addresses imply location) • We sometimes use VLANs to segregate services and QoS • We‟ve always done it this way • VLAN pooling has been a widely-used (and useful) feature… 3
  • 4. Why do we need VLANs? • VLANs split up L2 subnets to control excessive broadcast & multicast traffic • We sometimes use VLANs to segregate traffic for security • VLANs can help us manage geographically distributed networks (addresses imply location) • We sometimes use VLANs to segregate services and QoS • We‟ve always done it this way • VLAN pooling has been a widely-used (and useful) feature… But… • VLAN pooling causes inefficient address usage • And IPv6 (SLAAC) VLANs don‟t mix well with WLANs • And managing multiple VLANs across a large network is challenging 4
  • 5. Moving WLANs to IPv6 – SLAAC • IPv6 address discovery with SLAAC (State-Less Address Auto Configuration, RFC 4862) • • • • • Routers send unsolicited Router Advertisements (RA) periodically (~ minutes) RS Router Solicitation RA Router Advertisement SLAAC Stateless Address Auto-Configuration DAD Duplicate Address Detection ND, NS, NA Neighbor Discovery, Solicitation, Advertisement 2001:0db8:1010:61ab:0219:71ff:fe64:3f00 VLAN 1 RA includes the „network‟ stub for the address, device adds a unique interface identifier to construct an address in a stateless protocol RA Network Identifier 64 bits RS Interface Identifier 64 bits RS But more often, a device requests an address by sending a Router Solicitation (RS) to the well-known „all routers‟ address RA RS Controller assigns device to a pooled VLAN and forwards the RS to only the appropriate router Address MAC On receipt of an RS, the router sends an RA to the all-nodes multicast address 5 1. RS to ff02::2 ICMPv6 type 133 (RS) 2. RA to ff02::1 ICMPv6 type 134 (RA) router lifetime 1800s preferred lifetime = 7d, valid lifetime = 30d
  • 6. Moving WLANs to IPv6 – RAs meet wireless • IPv6 address discovery with SLAAC (State-Less Address Auto Configuration, RFC 4862) • Controller assigns device to a pooled VLAN and forwards the RS to only the appropriate router • On receipt of an RS, the router sends an RA to the all-nodes multicast address • RAs multicasts are limited within their VLAN by switches…But 802.11 has no concept of VLANs or multicast, only broadcast to all associated devices. Controller forwards the multicast RS to all APs with a member of that multicast group • VLAN 1 So an RA for a device on one VLAN is received by devices on other VLANs. This affects BSSs serving devices from more than one VLAN, which comes about after mobility events or through VLAN pooling. RA RA RAs are broadcast over the air, all associated devices receive them 1. RS to ff02::2 ICMPv6 type 133 (RS) 2. RA to ff02::1 ICMPv6 type 134 (RA) router lifetime 1800s preferred lifetime = 7d, valid lifetime = 30d Address list 6 Address list MAC MAC
  • 7. Consumer devices in the enterprise • Several scenarios result in clients from multiple VLANs associating to the same AP • This sows the seeds of the VLAN‟s demise • Mixed VLAN clients on one AP: i. Through VLAN pooling, by design ii. From mobility events, where devices move from one AP to another iii. Where VLANs are used to segregate, or manage traffic and clients are using different services 7
  • 8. Moving WLANs to IPv6 – multiple VLANs • IPv6 address discovery with SLAAC (State-Less Address Auto Configuration, RFC 4862) • Controller assigns device to a pooled VLAN and forwards the RS to only the appropriate router • On receipt of an RS, the router sends an RA to the all-nodes multicast address • Controller forwards the multicast RS to all APs with a member of that multicast group • With IPv6, devices construct multiple addresses, one per distinct RA received, by adding its MAC address to the RA global_routing_prefix + subnet_id. A device may choose to use any address from its list as its source address. RAs are broadcast over the air, all associated devices receive them and build multiple addresses VLAN 1 VLAN 2 RA RA RA RA 2. RA to ff02::1 ICMPv6 type 134 (RA) router lifetime 1800s, preferred lifetime = 7d, valid lifetime = 30d Address list 8 Address list MAC MAC MAC MAC MAC MAC
  • 9. Moving WLANs to IPv6 – confused addressing The network learns VLAN assignments and check for incorrect source address as a security measure (e.g. anti-spoofing). • IPv6 address discovery with SLAAC (RFC 4862) • Controller assigns device to a pooled VLAN and forwards the RS to only the appropriate router • On receipt of an RS, the router sends an RA to the all-nodes multicast address • Devices build multiple IPv6 addresses based on heard & overheard RAs VLAN 2 RAs are broadcast over the air, all devices receive them • VLAN 1 • RA RA RA 1. RS to ff02::2 ICMPv6 type 133 (RS) 2. RA to ff02::1 ICMPv6 type 134 (RA) router lifetime 1800s, preferred lifetime = 7d, valid lifetime = 30d RA When a device starts to transmit, only one of its IPv6 addresses matches the controller‟s VLAN mask. Packets with mismatched source addresses are dropped. Address list 9 Address list MAC MAC MAC MAC MAC MAC
  • 10. Moving to IPv6 – Solving mismatched IPv6 VLAN 1 VLAN 2 VLAN 3 • IPv6 SLAAC with VLAN pooling • Where APs serve clients with mixed VLANs, some percentage of devices use the wrong address and traffic is dropped • • Solution: turn downstream multicast to unicast VLAN 1 But devices still hear all RAs on the VLAN, regardless of where the RS came from. This can be a significant amount of extra traffic VLAN 2 RA RA RA Address list MAC 10 RA Address list MAC
  • 11. Moving to IPv6 – Unicast vs Multicast • Multicast-to-unicast of IPv6 SLAAC RAs results in noticeably faster battery drain • And extra transmit operations to send frames required to retrieve buffered downlink and return to sleep mode beacon TIM multicast This appears to be a combination of the client radio staying in receive mode for longer periods (stays awake till it can contend for an uplink trigger frame)… • Multicast downlink frames time client radio in receive mode Multicast to unicast downlink frames beacon TIM multicast unicast data trigger client radio in receive mode 11 ack & sleep client transmits time
  • 12. Moving to IPv6 – Solving mismatched IPv6 • IPv6 SLAAC with VLAN pooling VLAN 1 VLAN 2 VLAN 3 • Where APs serve clients with mixed VLANs, some percentage of devices use the wrong address and traffic is dropped • Solution: turn downstream multicast to unicast • But now devices still hear all RAs on the VLAN, regardless of where the RS came from. This can be a significant amount of extra traffic … and this unicast traffic is a significant drain on battery life VLAN 1 VLAN 2 RA RA • What to do? Either… i. Prune RA traffic to only those devices that have outstanding RSs? ii. Make sure we don‟t mix VLANs on an AP? RA RA iii. Try making Wi-Fi VLAN-compliant? Address list MAC iv. Other ideas? 12 Address list MAC
  • 13. Some of the forces driving WLAN (re)design Consumer devices in the enterprise Migration to the cloud 13 Migration to IPv6
  • 14. Consumer devices in the enterprise • Consumer devices on a home network • Reference model is a small L2 network i. Not many devices, plentiful bandwidth ii. Devices use multicast to discover each other, and services by Type and Name iii. … through mDNS / DNS-SN / Bonjour 14
  • 15. mDNS and DNS-SD mDNS Advertisement - serviceType (e.g.PTR) - domain mDNS Query App advertises service - serviceType (e.g.PTR) - domain mDNS Response - serviceName (e.g. AlphaPrinter) mDNS Response L2 network mDNS Response - serviceName (e.g. GammaPrinter) App requests service Announcements ServiceType : Name ServiceType : Name ServiceType : Name ServiceType : Name - serviceName (e.g. BetaPrinter) Queries Responses Announcements Some DNS-SD Service Types http://www.dns-sd.org/ServiceTypes.html http http ipp printer appletv Apple TV home-sharing iTunes Home Sharing RFC 6762 Multicast DNS RFC 6763 DNS-based service discovery DNS Domain Name Service When a new service instance starts, it advertises the service to a multicast address with serviceType and serviceName. Listening devices add the service to their cached list. When an app requests a service by serviceType queries the OS-cached list for optional mDNS Query for the serviceType. When an app wants to use a service, mDNS Queries resolve the chosen serviceName to a hostName and IP address + port 15
  • 16. mDNS & DNS-SD VLAN 3 • mDNS & DNS-SD i. Every service instance publishes/advertises when it comes up and responds to queries on multicast. ii. Within a given service, all instances have visibility of all other instances… iii. … except across VLAN or L2 boundaries VLAN 2 VLAN 1 iv. Default is to flood packets 16
  • 17. mDNS-participating network architecture • mDNS & DNS-SD with network participation i. „Network‟ learns groupings by service and device ii. When a service instance transmits (on multicast mDNS), the network swallows the transmission iii. Network responds to mDNS DNSSD Queries on behalf of service instances iv. v. When other devices in the group are in different VLANs, packets are forwarded across VLAN boundaries Default may be to block mDNS per-service • Network intercepts mDNS service advertisements • Transmits advertisements to selected devices on any VLAN • Responds to service queries by sending selected responses VLAN 1 VLAN 2 (ethersphere) #show airgroup status AirGroup Service Information ---------------------------Service Status -----------airplay Enabled airprint Enabled itunes Disabled allowall Disabled (ethersphere) #show airgroup blocked-queries AirGroup dropped Query IDs -------------------------_touch-remote._tcp _sleep-proxy._udp _vnc._tcp _mediatest._udp _mediatest._tcp 17 81834 2 1819 91 22 Rules to determine control forwarding (examples) • Allow X service on the network • Allow device/instance Y to see service instance X because - They are instances of the same service - They are on the same AP - They are in the same building - They „owned‟ by the same userid - Y has been „authorized‟ by the „owner‟ of X - They are instances of an „uncontrolled‟ service - X has been designated a „shared‟ instance
  • 18. Consumer devices in the enterprise • mDNS & DNS-SD with network participation, network must be capable of: i. Identifying whether a service type is allowed ii. Identifying the „group‟ which should have visibility of each service instance 18 @arubanetworks
  • 19. Subnets, VLANs and multicast control Multicast control: similar to VLANs but works across subnets VLANs: network controls what a port can see Subnets: L2 domains require a router to connect, breaks multicast 19
  • 20. ‘Proxy’ multicast architecture is not new • ARP RFC 826 Multicast query Unicast response Proxy ARP has been a feature of over-the-air WLANs for years, to limit traffic and provide security • Concept extends to multicast control • Over here, mate! Also extends to IPv6 duplicate address discovery, neighbor discovery ARP proxy (802.11v, u e.g. ARP) Who has A.B.C.D? Multicast filtering (802.11v FBMS e.g. VRRP) 20 A.B.C.D IPv6 Neighbor Discovery Proxy (e.g. NDP, ND, DAD)
  • 21. mDNS-participating network architecture • mDNS & DNS-SD with network participation i. ii. Network takes the role of service directory away from the distributed mDNS model External Configuration for groupings, permissions Network can add and advertise its own services Internal policy decisions Policy layer applies rules, e.g. “this device or service instance is part of group X including these other members” mDNS proxy Traffic forwarding layer Identifies, synthesizes and forwards specific packets mDNS Advertisement - 21 serviceType domain mDNS Query mDNS Response - - serviceType domain serviceName (e.g. AlphaPrinter)
  • 22. Some of the forces driving WLAN (re)design Consumer devices in the enterprise Migration to the cloud 22 Migration to IPv6
  • 23. Monitoring and control at the network edge • Monitoring and managing corporate activity from remote locations to cloud-resident applications i. „Conventional‟ model brings traffic to the data center from campus APs ii. Functions performed at the network edge: Radio configuration, monitoring and management… Authentication Firewall rules Traffic shaping and QoS Monitoring & reporting Access for troubleshooting And remote APs (VPN model over Internet) iii. As corporate locations become more distributed, and apps & services become cloud-resident, network managers become blind to corporate traffic iv. The only touch point for network managers will be an IT-supplied and managed AP 23
  • 24. Some of the forces driving WLAN (re)design Consumer devices in the enterprise Migration to the cloud Migration to IPv6 • New WLAN features in response to specific problems • Multicast control (filtering & forwarding) is a powerful new technology • An opportunity to re-think network design 24
  • 25. Why do we need VLANs? IPv6 IPv4 VLANVLANVLAN 3 1 2 Increase the size, reduce the number of VLANs to solve IPv6 issues • VLANs split up L2 subnets to control excessive broadcast & multicast traffic • Solved by network multicast control • We sometimes use VLANs for security • Solved (as well as it was by VLANs) • VLANs can help us manage geographically distributed networks (addresses imply location) • Mobility-aware network does this better • We sometimes use VLANs to segregate services and QoS Single-VLAN networks can be an IPv6 overlay over existing IPv4 designs… Or an opportunity to simplify the whole network 25
  • 26. Software Defined Networking (SDN) • Software-defined networking decouples network control (routing and switching traffic) from the physical network topology • Network intelligence and state are centralized, network topology is abstracted and virtualized • The Open Networking Foundation consortium is leading standardization efforts • https://www.opennetworking.org/ • OpenFlow is a protocol that facilitates communication between SDN Controllers and SDN capable network elements. * https://www.opennetworking.org/images/stories/downloads/white-papers/wp-sdn-newnorm.pdf SDN Benefits Centralized management and control of networking devices from multiple vendors Increased network reliability, security, uniform policy enforcement, and fewer configuration errors Granular network control with the ability to apply comprehensive and wide-ranging policies at the session, user, device, and application levels Better end-user experience as applications exploit centralized network state information to seamlessly adapt network behavior to user needs. 26
  • 27. Abstracting the network model • Abstract the network model to a policy layer • Policy layer interfaces to external APIs, OpenFlow • External APIs export sensing information, accept reconfiguration Security / Remediation Server Voice / Video Server Required action (response) Can‟t do this one, try again New device alert Internal policy decisions Policy layer applies rules, e.g. “this device or service instance is part of group X including these other members” Traffic forwarding layer identifies, synthesizes and forwards specific packets Connection setup alert Move to another AP 27 New ACL / firewall Adjust QoS per stream
  • 28. Sensing at the network edge • Only at the edge can the network sense • Device radio characteristics • Device authentication status • Unassociated devices radio • All intrusion attempts 802.11 L2 traffic mgmt & services L3 traffic & services 802.11 connected device Radio information - Signal level - SNR 802.11 management - Associated - Data rate - Frame error rate - MAC - Sleeping Mobility awareness - Origin & location - Roaming history - AP load - Neighbor APs Authenticati on - Status - Identity - Role - Blacklist 28 L2 - ARP - VLAN - mDNS IP - DHCP - IP address Multicast L4-7 - IGMP - Sessions & - MC protocols Neighbors - Destinations, ports - Rates - QoS
  • 29. Control at the network edge • Only at the edge can the network control all aspects of association, authentication, discovery and connectivity • e.g. blacklist association based on traffic protocol • e.g. move APs based on a new session Blacklist association Move to „best‟ AP Devices & services discovery Determine Reachability Synthesize responses Apply or change QoS 802.11 connected (or unconnected) device Radio information 802.11 management - Signal level - Associated - SNR - Data rate - Frame error rate - MAC - Sleeping Mobility awareness - Origin & location - Roaming history - AP load - Neighbor APs L2 IP Multicast L4-7 - ARP - DHCP - IGMP - Sessions & protocols - VLAN - IP address - MC Neighbors Destinations, ports - mDNS - Rates - QoS 29
  • 30. A better way to think about architecture SDN policy decision layer reconfigure network to allow for changes and coordinate outside the wireless edge Local policy decision layer Abstract the wireless network model and make decisions for authentication, service whitelisting, load balancing… Policy enforcement layer apply authentication rules, firewall rules, QoS policy, multicast service manipulation Sensing layer report radio state, 802.11 state, authentication, multicast services, traffic 30
  • 31. Some of the forces driving WLAN (re)design Consumer devices in the enterprise Migration to the cloud Migration to IPv6 • The network hollows out • The edge is used for sensing and reporting • Policy definitions allow the network to dynamically reconfigure in response to traffic & external events • SDN APIs allow the network to dynamically reconfigure in response to external requirements 31
  • 32. Where we are going 32 @arubanetworks @arubanetworks