SlideShare ist ein Scribd-Unternehmen logo
1 von 32
Where are we going?

1

@arubanetworks
@arubanetworks
Some of the forces driving WLAN (re)design

Consumer devices
in the enterprise

Migration to the
cloud

2

Migration to IPv6
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
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
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
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
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
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
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
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
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
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
Some of the forces driving WLAN (re)design

Consumer devices in
the enterprise

Migration to the
cloud

13

Migration to
IPv6
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
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
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
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
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
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
‘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)
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)
Some of the forces driving WLAN (re)design

Consumer devices
in the enterprise

Migration to
the cloud

22

Migration to
IPv6
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
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
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
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
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
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
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
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
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
Where we are going

32

@arubanetworks
@arubanetworks

Weitere ähnliche Inhalte

Was ist angesagt?

Networking 101 part 2 for ai
Networking 101 part 2 for aiNetworking 101 part 2 for ai
Networking 101 part 2 for aiursus006
 
1 wireless fundamentals
1 wireless fundamentals1 wireless fundamentals
1 wireless fundamentalsVenudhanraj
 
1 wireless fundamentals
1 wireless fundamentals1 wireless fundamentals
1 wireless fundamentalsVenudhanraj
 
Dante Audio Networking Fundamentals
Dante Audio Networking FundamentalsDante Audio Networking Fundamentals
Dante Audio Networking FundamentalsrAVe [PUBS]
 
6 understanding aruba rf issues
6 understanding aruba rf issues6 understanding aruba rf issues
6 understanding aruba rf issuesVenudhanraj
 
ARUBA 2014 : 802.11ac Wi-Fi fundamentals v2
ARUBA 2014 : 802.11ac Wi-Fi fundamentals v2ARUBA 2014 : 802.11ac Wi-Fi fundamentals v2
ARUBA 2014 : 802.11ac Wi-Fi fundamentals v2Marcello Marchesini
 
RF planning for high-densities of mobile devices and bandwidth-hungry mobile ...
RF planning for high-densities of mobile devices and bandwidth-hungry mobile ...RF planning for high-densities of mobile devices and bandwidth-hungry mobile ...
RF planning for high-densities of mobile devices and bandwidth-hungry mobile ...Aruba, a Hewlett Packard Enterprise company
 
16.) layer 3 (basic tcp ip routing)
16.) layer 3 (basic tcp ip routing)16.) layer 3 (basic tcp ip routing)
16.) layer 3 (basic tcp ip routing)Jeff Green
 

Was ist angesagt? (20)

2012 ah vegas wlan design for voice video
2012 ah vegas   wlan design for voice video2012 ah vegas   wlan design for voice video
2012 ah vegas wlan design for voice video
 
Networking 101 part 2 for ai
Networking 101 part 2 for aiNetworking 101 part 2 for ai
Networking 101 part 2 for ai
 
2012 ah vegas rf fundamentals
2012 ah vegas   rf fundamentals2012 ah vegas   rf fundamentals
2012 ah vegas rf fundamentals
 
Air heads rio 2010 outdoor wla-ns
Air heads rio 2010   outdoor wla-nsAir heads rio 2010   outdoor wla-ns
Air heads rio 2010 outdoor wla-ns
 
Enabling AirPrint & AirPlay on Your Network
Enabling AirPrint & AirPlay on Your NetworkEnabling AirPrint & AirPlay on Your Network
Enabling AirPrint & AirPlay on Your Network
 
1 wireless fundamentals
1 wireless fundamentals1 wireless fundamentals
1 wireless fundamentals
 
1 wireless fundamentals
1 wireless fundamentals1 wireless fundamentals
1 wireless fundamentals
 
Dante Audio Networking Fundamentals
Dante Audio Networking FundamentalsDante Audio Networking Fundamentals
Dante Audio Networking Fundamentals
 
DHCP
DHCPDHCP
DHCP
 
Aruba webinar dorm wi fi design v4
Aruba webinar   dorm wi fi design v4Aruba webinar   dorm wi fi design v4
Aruba webinar dorm wi fi design v4
 
11ac and client match for the awo ash chowdappa
11ac and client match for the awo ash chowdappa11ac and client match for the awo ash chowdappa
11ac and client match for the awo ash chowdappa
 
Roaming behavior and Client Troubleshooting
Roaming behavior and Client TroubleshootingRoaming behavior and Client Troubleshooting
Roaming behavior and Client Troubleshooting
 
6 understanding aruba rf issues
6 understanding aruba rf issues6 understanding aruba rf issues
6 understanding aruba rf issues
 
ARUBA 2014 : 802.11ac Wi-Fi fundamentals v2
ARUBA 2014 : 802.11ac Wi-Fi fundamentals v2ARUBA 2014 : 802.11ac Wi-Fi fundamentals v2
ARUBA 2014 : 802.11ac Wi-Fi fundamentals v2
 
Best Practices on Migrating to 802.11ac Wi-Fi #AirheadsConf Italy
Best Practices on Migrating to 802.11ac Wi-Fi #AirheadsConf ItalyBest Practices on Migrating to 802.11ac Wi-Fi #AirheadsConf Italy
Best Practices on Migrating to 802.11ac Wi-Fi #AirheadsConf Italy
 
RF planning for high-densities of mobile devices and bandwidth-hungry mobile ...
RF planning for high-densities of mobile devices and bandwidth-hungry mobile ...RF planning for high-densities of mobile devices and bandwidth-hungry mobile ...
RF planning for high-densities of mobile devices and bandwidth-hungry mobile ...
 
16.) layer 3 (basic tcp ip routing)
16.) layer 3 (basic tcp ip routing)16.) layer 3 (basic tcp ip routing)
16.) layer 3 (basic tcp ip routing)
 
Base Designs Lab Setup for Validated Reference Design
Base Designs Lab Setup for Validated Reference DesignBase Designs Lab Setup for Validated Reference Design
Base Designs Lab Setup for Validated Reference Design
 
Advanced RF Design & Troubleshooting #AirheadsConf Italy
Advanced RF Design & Troubleshooting #AirheadsConf ItalyAdvanced RF Design & Troubleshooting #AirheadsConf Italy
Advanced RF Design & Troubleshooting #AirheadsConf Italy
 
High-Density Wireless Networks for Auditoriums
High-Density Wireless Networks for AuditoriumsHigh-Density Wireless Networks for Auditoriums
High-Density Wireless Networks for Auditoriums
 

Andere mochten auch

DNS-SD
DNS-SDDNS-SD
DNS-SDnetvis
 
Bonjour protocol
Bonjour protocolBonjour protocol
Bonjour protocolSalah Amean
 
Ad-Hoc Networking in Linux with Avahi
Ad-Hoc Networking in Linux with AvahiAd-Hoc Networking in Linux with Avahi
Ad-Hoc Networking in Linux with Avahisinchume
 

Andere mochten auch (20)

DNS-SD
DNS-SDDNS-SD
DNS-SD
 
Bonjour protocol
Bonjour protocolBonjour protocol
Bonjour protocol
 
Ad-Hoc Networking in Linux with Avahi
Ad-Hoc Networking in Linux with AvahiAd-Hoc Networking in Linux with Avahi
Ad-Hoc Networking in Linux with Avahi
 
DNS-SD Extentions
DNS-SD ExtentionsDNS-SD Extentions
DNS-SD Extentions
 
IP Multicasting
IP MulticastingIP Multicasting
IP Multicasting
 
Bonjour for Java
Bonjour for JavaBonjour for Java
Bonjour for Java
 
Deploying Microsoft Lync over Wi-Fi #AirheadsConf Italy
Deploying Microsoft Lync over Wi-Fi #AirheadsConf ItalyDeploying Microsoft Lync over Wi-Fi #AirheadsConf Italy
Deploying Microsoft Lync over Wi-Fi #AirheadsConf Italy
 
IDC Aruba Webinar - 3 Feb 15
IDC Aruba Webinar - 3 Feb 15IDC Aruba Webinar - 3 Feb 15
IDC Aruba Webinar - 3 Feb 15
 
Adaptive Trust Security
Adaptive Trust SecurityAdaptive Trust Security
Adaptive Trust Security
 
Make Your Own Meridian Mobile App Workshop #AirheadsConf Italy
Make Your Own Meridian Mobile App Workshop #AirheadsConf ItalyMake Your Own Meridian Mobile App Workshop #AirheadsConf Italy
Make Your Own Meridian Mobile App Workshop #AirheadsConf Italy
 
Breakout - Airheads Macau 2013 - Cloud WiFi
Breakout - Airheads Macau 2013 - Cloud WiFiBreakout - Airheads Macau 2013 - Cloud WiFi
Breakout - Airheads Macau 2013 - Cloud WiFi
 
Advanced Aruba Mobility Access Switch Workshop #AirheadsConf Italy
Advanced Aruba Mobility Access Switch Workshop #AirheadsConf ItalyAdvanced Aruba Mobility Access Switch Workshop #AirheadsConf Italy
Advanced Aruba Mobility Access Switch Workshop #AirheadsConf Italy
 
Aruba Technical Webinar: Unplugging the Last Cord
Aruba Technical Webinar:  Unplugging the Last CordAruba Technical Webinar:  Unplugging the Last Cord
Aruba Technical Webinar: Unplugging the Last Cord
 
Enabling the Virtual Enterprise
Enabling the Virtual EnterpriseEnabling the Virtual Enterprise
Enabling the Virtual Enterprise
 
Meridian APPs and ALE at WFD6
Meridian APPs and ALE at WFD6Meridian APPs and ALE at WFD6
Meridian APPs and ALE at WFD6
 
E Rate Modernization Overview
E Rate Modernization Overview E Rate Modernization Overview
E Rate Modernization Overview
 
Aruba Networks at WFD6
Aruba Networks at WFD6 Aruba Networks at WFD6
Aruba Networks at WFD6
 
Shanghai Breakout: Access Management with Aruba ClearPass
Shanghai Breakout: Access Management with Aruba ClearPassShanghai Breakout: Access Management with Aruba ClearPass
Shanghai Breakout: Access Management with Aruba ClearPass
 
Shanghai Breakout: 802.11ac Wi-Fi Fundamentals
Shanghai Breakout: 802.11ac Wi-Fi FundamentalsShanghai Breakout: 802.11ac Wi-Fi Fundamentals
Shanghai Breakout: 802.11ac Wi-Fi Fundamentals
 
Customer Keynote - Microsoft Lync
Customer Keynote - Microsoft LyncCustomer Keynote - Microsoft Lync
Customer Keynote - Microsoft Lync
 

Ähnlich wie Evolving Enterprise Network Architecture

Routing and OSPF
Routing and OSPFRouting and OSPF
Routing and OSPFarpit
 
Class notes fhrp,hsrp
Class notes  fhrp,hsrpClass notes  fhrp,hsrp
Class notes fhrp,hsrpSagarR24
 
Class notes fhrp,hsrp,vrrp
Class notes fhrp,hsrp,vrrpClass notes fhrp,hsrp,vrrp
Class notes fhrp,hsrp,vrrpSagarR24
 
APNIC Hackathon IPv4 & IPv6 security & threat comparisons
APNIC Hackathon IPv4 & IPv6 security & threat comparisonsAPNIC Hackathon IPv4 & IPv6 security & threat comparisons
APNIC Hackathon IPv4 & IPv6 security & threat comparisonsSiena Perry
 
APNIC Hackathon IPv4 & IPv6 security & threat comparisons
APNIC Hackathon IPv4 & IPv6 security & threat comparisonsAPNIC Hackathon IPv4 & IPv6 security & threat comparisons
APNIC Hackathon IPv4 & IPv6 security & threat comparisonsAPNIC
 
ccna summer training ppt ( Cisco certified network analysis) ppt. by Traun k...
ccna summer training ppt ( Cisco certified network analysis) ppt.  by Traun k...ccna summer training ppt ( Cisco certified network analysis) ppt.  by Traun k...
ccna summer training ppt ( Cisco certified network analysis) ppt. by Traun k...Tarun Khaneja
 
Gohil-Network layer & Address Resolution Protocol.pptx
Gohil-Network layer & Address Resolution Protocol.pptxGohil-Network layer & Address Resolution Protocol.pptx
Gohil-Network layer & Address Resolution Protocol.pptxJuvil2
 
Chapter 25. implementing i pv6 routing
Chapter 25. implementing i pv6 routingChapter 25. implementing i pv6 routing
Chapter 25. implementing i pv6 routingVishnu Vardhan
 
Solving QoS multicast routing problem using aco algorithm
Solving QoS multicast routing problem using aco algorithm Solving QoS multicast routing problem using aco algorithm
Solving QoS multicast routing problem using aco algorithm Abdullaziz Tagawy
 
Mikrotik link redundancy solution
Mikrotik link redundancy solution Mikrotik link redundancy solution
Mikrotik link redundancy solution S M Tipu
 
Training Day Slides
Training Day SlidesTraining Day Slides
Training Day Slidesadam_merritt
 
5. transistion mechanisum 1
5. transistion mechanisum 15. transistion mechanisum 1
5. transistion mechanisum 1rajataro
 
LoRa Architecture for internet of things.pptx
LoRa Architecture for internet of things.pptxLoRa Architecture for internet of things.pptx
LoRa Architecture for internet of things.pptxkirtanchoudhary333
 

Ähnlich wie Evolving Enterprise Network Architecture (20)

Routing and OSPF
Routing and OSPFRouting and OSPF
Routing and OSPF
 
Class notes fhrp,hsrp
Class notes  fhrp,hsrpClass notes  fhrp,hsrp
Class notes fhrp,hsrp
 
Class notes fhrp,hsrp,vrrp
Class notes fhrp,hsrp,vrrpClass notes fhrp,hsrp,vrrp
Class notes fhrp,hsrp,vrrp
 
Vrrp Alp
Vrrp AlpVrrp Alp
Vrrp Alp
 
APNIC Hackathon IPv4 & IPv6 security & threat comparisons
APNIC Hackathon IPv4 & IPv6 security & threat comparisonsAPNIC Hackathon IPv4 & IPv6 security & threat comparisons
APNIC Hackathon IPv4 & IPv6 security & threat comparisons
 
APNIC Hackathon IPv4 & IPv6 security & threat comparisons
APNIC Hackathon IPv4 & IPv6 security & threat comparisonsAPNIC Hackathon IPv4 & IPv6 security & threat comparisons
APNIC Hackathon IPv4 & IPv6 security & threat comparisons
 
ccna summer training ppt ( Cisco certified network analysis) ppt. by Traun k...
ccna summer training ppt ( Cisco certified network analysis) ppt.  by Traun k...ccna summer training ppt ( Cisco certified network analysis) ppt.  by Traun k...
ccna summer training ppt ( Cisco certified network analysis) ppt. by Traun k...
 
Gohil-Network layer & Address Resolution Protocol.pptx
Gohil-Network layer & Address Resolution Protocol.pptxGohil-Network layer & Address Resolution Protocol.pptx
Gohil-Network layer & Address Resolution Protocol.pptx
 
Osp fv3 cs
Osp fv3 csOsp fv3 cs
Osp fv3 cs
 
Chapter 25. implementing i pv6 routing
Chapter 25. implementing i pv6 routingChapter 25. implementing i pv6 routing
Chapter 25. implementing i pv6 routing
 
Network Layer
Network LayerNetwork Layer
Network Layer
 
Solving QoS multicast routing problem using aco algorithm
Solving QoS multicast routing problem using aco algorithm Solving QoS multicast routing problem using aco algorithm
Solving QoS multicast routing problem using aco algorithm
 
Mikrotik link redundancy solution
Mikrotik link redundancy solution Mikrotik link redundancy solution
Mikrotik link redundancy solution
 
Chapter14ccna
Chapter14ccnaChapter14ccna
Chapter14ccna
 
Training Day Slides
Training Day SlidesTraining Day Slides
Training Day Slides
 
CCNA 1
CCNA 1CCNA 1
CCNA 1
 
CCNA FUNDAMENTAL
CCNA FUNDAMENTALCCNA FUNDAMENTAL
CCNA FUNDAMENTAL
 
5. transistion mechanisum 1
5. transistion mechanisum 15. transistion mechanisum 1
5. transistion mechanisum 1
 
LoRa Architecture for internet of things.pptx
LoRa Architecture for internet of things.pptxLoRa Architecture for internet of things.pptx
LoRa Architecture for internet of things.pptx
 
Network Layer Protocol.pptx
Network Layer Protocol.pptxNetwork Layer Protocol.pptx
Network Layer Protocol.pptx
 

Mehr von Aruba, a Hewlett Packard Enterprise company

Mehr von Aruba, a Hewlett Packard Enterprise company (20)

Airheads Tech Talks: Cloud Guest SSID on Aruba Central
Airheads Tech Talks: Cloud Guest SSID on Aruba CentralAirheads Tech Talks: Cloud Guest SSID on Aruba Central
Airheads Tech Talks: Cloud Guest SSID on Aruba Central
 
Airheads Tech Talks: Understanding ClearPass OnGuard Agents
Airheads Tech Talks: Understanding ClearPass OnGuard AgentsAirheads Tech Talks: Understanding ClearPass OnGuard Agents
Airheads Tech Talks: Understanding ClearPass OnGuard Agents
 
Airheads Tech Talks: Advanced Clustering in AOS 8.x
Airheads Tech Talks: Advanced Clustering in AOS 8.xAirheads Tech Talks: Advanced Clustering in AOS 8.x
Airheads Tech Talks: Advanced Clustering in AOS 8.x
 
EMEA Airheads_ Advance Aruba Central
EMEA Airheads_ Advance Aruba CentralEMEA Airheads_ Advance Aruba Central
EMEA Airheads_ Advance Aruba Central
 
EMEA Airheads_ Aruba AppRF – AOS 6.x & 8.x
EMEA Airheads_ Aruba AppRF – AOS 6.x & 8.xEMEA Airheads_ Aruba AppRF – AOS 6.x & 8.x
EMEA Airheads_ Aruba AppRF – AOS 6.x & 8.x
 
EMEA Airheads- Switch stacking_ ArubaOS Switch
EMEA Airheads- Switch stacking_ ArubaOS SwitchEMEA Airheads- Switch stacking_ ArubaOS Switch
EMEA Airheads- Switch stacking_ ArubaOS Switch
 
EMEA Airheads- LACP and distributed LACP – ArubaOS Switch
EMEA Airheads- LACP and distributed LACP – ArubaOS SwitchEMEA Airheads- LACP and distributed LACP – ArubaOS Switch
EMEA Airheads- LACP and distributed LACP – ArubaOS Switch
 
Introduction to AirWave 10
Introduction to AirWave 10Introduction to AirWave 10
Introduction to AirWave 10
 
EMEA Airheads- Virtual Switching Framework- Aruba OS Switch
EMEA Airheads- Virtual Switching Framework- Aruba OS SwitchEMEA Airheads- Virtual Switching Framework- Aruba OS Switch
EMEA Airheads- Virtual Switching Framework- Aruba OS Switch
 
EMEA Airheads- Aruba Central with Instant AP
EMEA Airheads- Aruba Central with Instant APEMEA Airheads- Aruba Central with Instant AP
EMEA Airheads- Aruba Central with Instant AP
 
EMEA Airheads- AirGroup profiling changes across 8.1 & 8.2 – ArubaOS 8.x
EMEA Airheads- AirGroup profiling changes across 8.1 & 8.2 – ArubaOS 8.xEMEA Airheads- AirGroup profiling changes across 8.1 & 8.2 – ArubaOS 8.x
EMEA Airheads- AirGroup profiling changes across 8.1 & 8.2 – ArubaOS 8.x
 
EMEA Airheads- Getting Started with the ClearPass REST API – CPPM
EMEA Airheads-  Getting Started with the ClearPass REST API – CPPMEMEA Airheads-  Getting Started with the ClearPass REST API – CPPM
EMEA Airheads- Getting Started with the ClearPass REST API – CPPM
 
EMEA Airheads - AP Discovery Logic and AP Deployment
EMEA Airheads - AP Discovery Logic and AP DeploymentEMEA Airheads - AP Discovery Logic and AP Deployment
EMEA Airheads - AP Discovery Logic and AP Deployment
 
EMEA Airheads- Layer-3 Redundancy for Mobility Master - ArubaOS 8.x
EMEA Airheads- Layer-3 Redundancy for Mobility Master - ArubaOS 8.xEMEA Airheads- Layer-3 Redundancy for Mobility Master - ArubaOS 8.x
EMEA Airheads- Layer-3 Redundancy for Mobility Master - ArubaOS 8.x
 
EMEA Airheads- Manage Devices at Branch Office (BOC)
EMEA Airheads- Manage Devices at Branch Office (BOC)EMEA Airheads- Manage Devices at Branch Office (BOC)
EMEA Airheads- Manage Devices at Branch Office (BOC)
 
EMEA Airheads - What does AirMatch do differently?v2
 EMEA Airheads - What does AirMatch do differently?v2 EMEA Airheads - What does AirMatch do differently?v2
EMEA Airheads - What does AirMatch do differently?v2
 
Airheads Meetups: 8400 Presentation
Airheads Meetups: 8400 PresentationAirheads Meetups: 8400 Presentation
Airheads Meetups: 8400 Presentation
 
Airheads Meetups: Ekahau Presentation
Airheads Meetups: Ekahau PresentationAirheads Meetups: Ekahau Presentation
Airheads Meetups: Ekahau Presentation
 
Airheads Meetups- High density WLAN
Airheads Meetups- High density WLANAirheads Meetups- High density WLAN
Airheads Meetups- High density WLAN
 
Airheads Meetups- Avans Hogeschool goes Aruba
Airheads Meetups- Avans Hogeschool goes ArubaAirheads Meetups- Avans Hogeschool goes Aruba
Airheads Meetups- Avans Hogeschool goes Aruba
 

Evolving Enterprise Network Architecture

  • 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