evolving enterprise network architecture

1 @arubanetworks@arubanetworks

Where are we going?

2

Some of the forces driving WLAN (re)design

Migration to IPv6Consumer devices

in the enterprise

Migration to the

cloud

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…

4


• 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

5

Moving WLANs to IPv6 – SLAAC

VLAN 1

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

RS

RS

RA RS

RA

RS Router Solicitation

RA Router Advertisement

SLAAC Stateless Address Auto-Configuration

DAD Duplicate Address Detection

ND, NS, NA Neighbor Discovery, Solicitation, Advertisement

MACAddress

Network Identifier

64 bits

Interface Identifier

64 bits

2001:0db8:1010:61ab:0219:71ff:fe64:3f00

• IPv6 address discovery with SLAAC

(State-Less Address Auto

Configuration, RFC 4862)

• Routers send unsolicited Router

Advertisements (RA) periodically (~

minutes)

• RA includes the „network‟ stub for the

address, device adds a unique interface

identifier to construct an address in a

stateless protocol

• But more often, a device requests an

address by sending a Router Solicitation

(RS) to the well-known „all routers‟

address

• 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

6

Moving WLANs to IPv6 – RAs meet wireless

VLAN 1



router lifetime 1800s



RA

RA

MACMACAddress list Address list

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.

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.

• IPv6 address discovery with

SLAAC (State-Less Address Auto




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

• RAs are broadcast over the air, all

associated devices receive them

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

8

Moving WLANs to IPv6 – multiple VLANs

VLAN 1 VLAN 2


router lifetime 1800s,



RA

RA

RA

RA

MAC

MACMAC

MAC

MACMAC

Address list Address list

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.


(State-Less Address Auto




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

• RAs are broadcast over the air, all

associated devices receive them and

build multiple addresses

9


(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 are broadcast over the air, all devices

receive them

• Devices build multiple IPv6 addresses based

on heard & overheard RAs

• 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.

Moving WLANs to IPv6 – confused addressing

VLAN 1 VLAN 2



router lifetime 1800s,



RA

RA

RA

RA

MAC

MACMAC

MAC

MACMAC


The network learns VLAN assignments and check for incorrect source

address as a security measure (e.g. anti-spoofing).

10

• 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

• 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

Moving to IPv6 – Solving mismatched IPv6

VLAN 1 VLAN 2 VLAN 3

VLAN 1 VLAN 2

RA

RA

RA

RA

MACMAC


11

• Multicast-to-unicast of IPv6 SLAAC

RAs results in noticeably faster battery

drain

• 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)…

• And extra transmit operations to send

frames required to retrieve buffered

downlink and return to sleep mode

Moving to IPv6 – Unicast vs Multicast

beacon TIM multicast

client radio in receive mode

beacon TIM multicast

client radio in receive mode

unicast

client transmits

trigger

data ack

&

sleep

time

time

Multicast downlink frames

Multicast to unicast downlink frames

12

• 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

• 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

Moving to IPv6 – Solving mismatched IPv6

VLAN 1 VLAN 2 VLAN 3

VLAN 1 VLAN 2

RA

RA

RA

RA

MACMAC


• 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?

iii. Try making Wi-Fi VLAN-compliant?

iv. Other ideas?

13


Consumer devices in

the enterprise

Migration to

IPv6

Migration to the

cloud

14


• 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

15

mDNS and DNS-SD

mDNS Query- serviceType (e.g.PTR)

- domain mDNS Response- serviceName (e.g. GammaPrinter)

mDNS Response- serviceName (e.g. BetaPrinter)

mDNS Response- serviceName (e.g. AlphaPrinter)

RFC 6762 Multicast DNS

RFC 6763 DNS-based

service discovery

DNS Domain Name Service

L2 network

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

Some DNS-SD Service Types

http://www.dns-sd.org/ServiceTypes.html

http http

ipp printer

appletv Apple TV

home-sharing iTunes Home Sharing

ServiceType : NameServiceType : NameServiceType : NameServiceType : Name

App

advertises

serviceApp

requests

service

Announcements

Queries

Responses

Announcements

mDNS Advertisement- serviceType (e.g.PTR)

- domain

16

• 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

iv. Default is to flood

packets

mDNS & DNS-SD

VLAN 1

VLAN 3

VLAN 2

17

• 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 DNS-

SD Queries on behalf of service

instances

iv. When other devices in the group

are in different VLANs, packets

are forwarded across VLAN

boundaries

v. Default may be to block mDNS

per-service

mDNS-participating network architecture

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

(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 81834

_sleep-proxy._udp 2

_vnc._tcp 1819

_mediatest._udp 91

_mediatest._tcp 22

• 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

18 @arubanetworks


• 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

19

Subnets, VLANs and multicast control

VLANs: network controls what a port can see Subnets: L2 domains require a router to connect, breaks

multicast

Multicast control: similar to VLANs but works across subnets

20

‘Proxy’ multicast architecture is not new

• Proxy ARP has been a feature

of over-the-air WLANs for

years, to limit traffic and

provide security

• Concept extends to multicast

control

• Also extends to IPv6 duplicate

address discovery, neighbor

discovery

Who has

A.B.C.D?A.B.C.D

Over here,

mate!

ARP RFC 826

Multicast query

Unicast response

ARP proxy

(802.11v, u

e.g. ARP)

Multicast filtering

(802.11v FBMS

e.g. VRRP)

IPv6 Neighbor Discovery

Proxy

(e.g. NDP, ND, DAD)

21

Traffic forwarding layer

Policy layer

Identifies, synthesizes and forwards

specific packets

applies rules, e.g. “this device or service

instance is part of group X including these

other members”

• mDNS & DNS-SD with network

participation

i. Network takes the role of service directory away

from the distributed mDNS model

ii. Network can add and advertise its own services

mDNS-participating network architecture

mDNS Query- serviceType

- domain

mDNS Response- serviceName

- (e.g. AlphaPrinter)

mDNS

Advertisement- serviceType

- domain

mDNS

proxy

External Configuration for

groupings, permissions

Internal policy

decisions

22


Migration to

the cloud

Consumer devices

in the enterprise

Migration to

IPv6

23

• 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. 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

Monitoring and control at the network edge

Functions performed at the network edge:

Radio configuration, monitoring and management…

Authentication

Firewall rules

Traffic shaping and QoS

Monitoring & reporting

Access for troubleshooting

24


Migration to

IPv6

Consumer devices in

the enterprise

Migration to

the cloud

• New WLAN features in response to specific problems

• Multicast control (filtering & forwarding) is a powerful new technology

• An opportunity to re-think network design

25

Increase the size, reduce the

number of VLANs to solve IPv6

issues


• Solved by network multicast

control

• Solved (as well as it was by

VLANs)

• Mobility-aware network does this

better

Single-VLAN networks can be an IPv6 overlay

over existing IPv4 designs…

Or an opportunity to simplify the whole network

VLAN 1VLAN 2VLAN 3

IPv4 IPv6

• VLANs split up L2 subnets to control

excessive broadcast & multicast traffic

• We sometimes use VLANs for security

• VLANs can help us manage geographically

distributed networks (addresses imply

location)

• We sometimes use VLANs to segregate

services and QoS

26

Software Defined Networking (SDN)

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.

• 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

https://www.opennetworking.org/images/stories/downloads/white-papers/wp-sdn-newnorm.pdf

27

Traffic forwarding layer

Policy layer

identifies, synthesizes and forwards specific

packets

applies rules, e.g. “this device or service

instance is part of group X including these

other members”

• Abstract the network

model to a policy layer

• Policy layer interfaces to

external APIs, OpenFlow

• External APIs export

sensing information,

accept reconfiguration

Abstracting the network model

Move to

another

AP

Internal policy

decisions

Voice / Video Server

Connection

setup alert

Security / Remediation Server

New device alert

Required action

(response)

New

ACL /

firewall

Adjust

QoS per

stream

Can‟t do this

one, try again

28

Sensing at the network edge

• Only at the edge can the

network sense

• Device radio characteristics

• Device authentication status

• Unassociated devices

• All intrusion attempts

Radio

information

- Signal level

- SNR

radio 802.11

mgmt

802.11

management

- Associated

- Data rate

- Frame error

rate

- MAC

- Sleeping

Authenticati

on

- Status

- Identity

- Role

- Blacklist

L2

- ARP

- VLAN

- mDNS

IP

- DHCP

- IP

address

Multicast

- IGMP

- MC

Neighbors

L4-7

- Sessions &

protocols

- Destinations,

ports

- Rates

- QoS

Mobility

awareness

- Origin &

location

- Roaming

history

- AP load

- Neighbor APs

L2 traffic

& services

L3 traffic

& services

802.11 connected device

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

Radio information

- Signal level

- SNR

802.11 management

- Associated

- Data rate

- Frame error rate

- MAC

- Sleeping

L2

- ARP

- VLAN

- mDNS

IP

- DHCP

- IP address

Multicast

- IGMP

- MC Neighbors

L4-7

- Sessions & protocols

- Destinations, ports

- Rates

- QoS

Mobility awareness

- Origin & location

- Roaming history

- AP load

- Neighbor APs

802.11 connected (or unconnected) device

Blacklist

association

Apply or

change

QoS

Devices &

services

discovery

Determine

Reachability

Synthesize

responsesMove to

„best‟ AP

30

A better way to think about architecture

Sensing layer

Policy enforcement layer

Local policy decision layer

SDN policy decision layer

report radio state, 802.11 state,

authentication, multicast services, traffic

apply authentication rules, firewall rules,

QoS policy, multicast service manipulation

Abstract the wireless network model and make decisions

for authentication, service whitelisting, load balancing…

reconfigure network to allow for changes and coordinate

outside the wireless edge

31


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

Consumer devices in

the enterprise

Migration to

the cloud

32 @arubanetworks@arubanetworks

Where we are going

evolving enterprise network architecture

Documents

security vlans

multicast rs

multiple vlans

concept of vlans

ra router lifetime

ipv6 slaac vlans dont

address auto configuration

router solicitation