Edge Virtual BridgingEdge Virtual Bridging
July 2009
Paul Congdon (HP ProCurve) [email protected] p g
AgendaAgenda• IEEE 802.1 history/background
Definition of EVB• Definition of EVB• Trends and market• Problems and environment• Problems and environment• Solutions− VEB− VEPA− VN-Tag
IEEE 802 1 St d di ti Di ti− IEEE 802.1 Standardization Direction• Status and likely future
IEEE 802 Overview and Architecture(Envisioned)( )
802.2 Logical Link
emen
t
Secu
rity
Data
802.1 Bridging
.1 M
ana
ge
802.1
0 S Data
Link
Layer
802.11802.5 802.6 802.12 802.16 802.17802.4802.3
802
Physical
Layer
802.22
Layer
3
IEEE 802 Overview and Architecture(Popular LAN Approaches)p pp
802.1 Bridging Data
Link
SNM
P
Link
Layer802.1AE
802.11802.3
S
802.11iPhysical
Layery
4
The State of IEEE 802.1 (July 2009)http://www ieee802 org/1/http://www.ieee802.org/1/~100 Voting Members
802 REV OA R i i 802 1X REV Port based Network 802.1AS - Timing and Synchronization 802.1Qau - Congestion Notification802-REV – OA – Revision
802.1AB-REV – LLDP – Revision
802.1H-REV - Recommended Practice for MAC Bridging of Ethernet in LANs
802.1AC - MAC Service
802.1aj - Two-port MAC Relay
802.1X-REV - Port-based NetworkAccess Control
802.1AR - Secure Device Identity
g y
802.1Qat - Stream Reservation Protocol
802.1Qav - Forwarding and Queuing Enhancements for Time-Sensitive Streams
802.1BA – Audio/Visual Bridge Systems
80 . Q u Co ges o No c o
802.1Qaz - Enhanced Transmission Selection
802.1Qbb - Priority-based Flow Control
802.3bd – MAC Control Frame
802.1aq - Shortest Path Bridging
802.1Qaw - Mgt of Data-Driven and Data-Dependent Connectivity Faults
802.1Qay - Provider Backbone Bridge Traffic Engineering
802.1Qbc – Remote Customer ServiceI t f
*802.1bg - Edge Virtual Bridging
5 19-Jul-09
Interface
802.1Qbe - MIRP
802.1Qbf – PBB-TE Infrastructure Protection
*802.1bh – Bridge Port Expansion
Traditional NetworkingTh d d b dThe end-station and bridge
Higher
MAC Client
Higher Layers
( ) ( )
Higher Layers(Bridge Protocol)
sw
MAC
( )MAC Relay
MACMAC
hw
6
Modern NetworkingThe end station and bridge
Routing Protocols Storage ProtocolsVirtual Virtual
The end-station and bridge
Traffic Monitoring
Access Control Lists
Routing Protocols, Storage Protocols,Availability Protocols, IDS/IPS, etc
MAC Client
Higher Layers
Machine
MAC Client
Higher Layers
Machine
Higher Layers(Bridge Protocol)
Port Mirroring
PAE MVRPLLDP SPB/MSTP
Higher Layers
MAC Client MAC Client
MAC
MAC Relay
( ) ( )MAC Client
( )
Relayswhw
MACMACMACSec MACSec
MAC
7
The Virtual Network Edge
8 19-Jul-09
Edge Virtual BridgingA DefinitionA Definition
Ed Vi l B id i (EVB) i h i Edge Virtual Bridging (EVB) is the environment where physical end stations, containing multiple virtual end stations all require the services of the virtual end stations, all require the services of the adjacent bridges forming a local area network.
h lNote: EVB environments are unique in that virtual NIC configuration information is available to EVB devices that is not normally available to an 802.1Q bridge.y g
9 19-Jul-09
Edge Virtual BridgingAt the edge, in the physical end stationAt the edge, in the physical end station
BridgeBridge
BladeSwitch
EdgeVirtual
Bridging
PhysicalEnd
Station
PhysicalEnd
Station
VirtualEnd
Station
VirtualEnd
Station
10 19-Jul-09
StationStation
Data Center Edge & Core Concept
Intelligent Edge DevicesImplements full suite of edge port features
• DCB: PFC, QCN, FCoE• Flex10• Virtual Switch Ports
Implements full suite of edge port features
HighPerformance • VID & Pri Translation
• ACLs, TCAM, pVLANs• LAGs across physical switches• Topology management
PerformanceFabric
Performance Fabric DevicesDoes not need to implement all intelligent edge port features
• DCB: PFC, QCN, FCoE• Connect Neutral
− Low-latency ‘Equal’− Bandwidth ‘Equal’
LAGH i S i h SR IOV NIC
Edge Virtual Bridging Access Provides coordinated network accessto virtual machines
11 19 July 2009
• LAGs• Topology management
• Hypervisor vSwitch or SR-IOV NICs• VEB (switching) mode or
VEPA (aggregating) mode
Edge Virtual Bridgingincludesincludes…
• Virtual Machine Environments (Virtual Switch)− VMware ESX Server− Microsoft HyperV− Citrix XEN− Linux KVM (linux-kvm.org)
• Proprietary offerings from HP IBM Sun Oracle Cisco etc• Proprietary offerings from HP, IBM, Sun, Oracle, Cisco, etc.
• NICs with multiple vNICs that share a single linkp g− PCI Single-root or Multiple-root IO Virtualization
(SR-IOV, MR-IOV)− Other multi-vNIC technologies
12 19-Jul-09
Other multi vNIC technologies
PCI Standards for IO VirtualizationPCI Standards for IO Virtualization• PCI Standards for
Single Root IO Virtualization (SR IOV)− Single Root IO Virtualization (SR-IOV)− Multiple Root IO Virtualization (MR-IOV)
• Allows for many PCI functions to be created • Allows for many PCI functions to be created… − That share a single physical device− That share a single physical uplink
Th t lti l t d i t th ti t− That appear as multiple, separate devices to the operating system− So each virtual machine has direct access to its own buffer
SR IOV NIC• SR-IOV NICs− Separate buffer for each virtual function (vNIC)− May implement hundreds of virtual functions (up to 64K)
ll ll l h h d l k
13 19-Jul-09
− Will usually implement 802.1 ETS queues at the shared link
SR-IOV DeviceSR-IOV Device
• Any type of I/O device y yp− Ethernet, Fibre Channel, Graphics, SAS, etc.
• PCI Express (PCIe) Device− 1-256 Physical Functions (PF)
T i ll 1 16 PF d i• Typically 1-16 PF per device• Full PCIe Function + SR-IOV capability• Owned by hypervisor• Device-specific management function and
control of shared resources e g Ethernet Portcontrol of shared resources, e.g. Ethernet Port− 1-64K Virtual Functions (VF)
• Typically 32-255 per device• Light-weight hardware resources to reduce cost
and device complexityp y• Owned by Virtual Machine (VM) Guest• Direct VM hardware access for data
movements – no hypervisor overhead− Infrequent configuration operations trap to
h i
PC
Ie P
ort
14 19-Jul-09
hypervisor− Typical device <= 256 PF+VF
Challenges At The Edge:Growth of VirtualizationGrowth of Virtualization
By 2012, over 50% of workloads will be run in workloads will be run in a virtualized environmentenvironment
15 19-Jul-09 hudson-vepa_seminar-20090514.pdf
Challenges at the Virtual EdgeChallenges at the Virtual Edge
• Visibility & ControlVisibility & Control−System admins own the physical end stations− Lack of network admin control can mean inadequate:Lack of network admin control can mean inadequate:
• Control of network access• Visibility of networking traffic
f d b k• Support for debugging network issues
• Limited Embedded Capability • Limited Embedded Capability − NICs have cost & complexity constraints (no TCAMs, no learning)− End-stations and bridges evolve independently
16 19-Jul-09
Getting traffic to flow the way you wantg y y
• If you prefer this… VM VMHigher Layers(Bridge Protocol)If you prefer this…
Relay
sw
hw
Relay
(Bridge Protocol)
Fine.. It’s called a “bridge” and we have standards for that, but standards for that, but it might be expensive
and complex
• If you prefer this
VM VMsw
hw
Higher Layers(Bridge Protocol)
New forwarding modes need to be
• If you prefer this…
Relay Relaymodes need to be defined, and the
topology is constrained
17
Approachesppge
VM
ge
VM
ge
VM
ehavi
or
Brid
g
VM
VM
Brid
g
VM
VM
Brid
g
VM
VM
multic
ast
be
Virtual Ethernet Bridge (VEB)Tagged VEPA orCisco VNTaggedTag-less VEPA
uses MAC+VID to steer frames uses new tag to steer framesuses MAC+VID to steer frames
• Emulates 802.1 Bridge• Works with all existing bridges• No changes to existing frame
format
• Exploits 802.1 Bridge• Works with many existing
bridgesNo changes to e isting frame
• Extends 802.1 Bridge• Works with few or no existing
bridges• Changes existing frame format
g
format.• Limited bridge visibility• Limited feature set• Best performance.
• No changes to existing frame format.
• Full bridge visibility• Access to bridge features
C t i d f
• Changes existing frame format.• Full bridge visibility• Access to bridge features• Constrained performance
18 19-Jul-09
• Will always be there • Constrained performance• Leverages VEB
• VNTag doesn’t leverage VEB
Tagging Schemesgg g
Objectives:1 Eliminate the need for a MAC Address Table1. Eliminate the need for a MAC Address Table2. Provide explicit indication of what VFs need to receive a packet3. Support generic downstream infrastructure ports
Note: If tagging scheme includes address encapsulation then topology need not be directly connected
Existing Candidates:Existing Candidates:1. MACSec Tag (aka SecTAG)2. 802.1Q Provider Tag (limited combinations)3 802 1ah Backbone Provider Tag (encapsulation)3. 802.1ah Backbone Provider Tag (encapsulation)
New Candidates1 Cisco VN-Tag (custom solution)
19
1. Cisco VN-Tag (custom solution)
Virtual Ethernet Bridges (VEBs)Virtual Ethernet Bridges (VEBs)
Th h t tThey are here to stay
2019-Jul-09
Virtual Ethernet BridgeA DefinitionA Definition
A Virtual Ethernet Bridge (VEB) is a frame relay g ( ) yservice within a physical end station that supports local bridging between multiple virtual end t ti d ( ti ll ) th t l b id i stations and (optionally) the external bridging
environment.
May be implemented in software as a virtual switch (vSwitch) or with embedded hardware.
Note: With VEBs, vNIC configuration information is available that is not normally available to an 802.1Q b id
21 19-Jul-09
bridge.
VEBs Are Here To StayVEBs Are Here To Stay• All hypervisor environments support some form of VEB
bilit t dcapability today.
• Local bridging with VEB is needed to allow hypervisors to:Local bridging with VEB is needed to allow hypervisors to:− Operate without external bridges attached− Operate with a broad range of Ethernet environments
M l l b d d h− Maximize local bandwidth− Minimize local latency− Minimize local packet lossp
• VEB capability will always be required for hypervisors and SR-IOV NICs
22 19-Jul-09
SR IOV NICs
Basic VEB Anatomy and Termsy
Virtual Machine,Vi t l E d St ti
vNICs can be configured for
ifi MACPhysical End Station
Virtual End Station
Apps Apps Apps Apps
Virtual NIC,Virtual Machine NIC
( NIC )
specific MACsor promiscuous
GOS
Apps
GOS
Apps
VEB, vSwitch, vmSwitch
GOS
Apps
GOS
Apps
GOS
Apps
GOS
Apps(vNIC, vmnic) Ingress Egress
VEB Port (vPort)*
expander
Software VEB
Physical NIC(pnic, vmnic)
VEB Uplink
NIC Team
Adjacent BridgeSwitch Port
VEB Uplink
23 19-Jul-09
Basic VEB Anatomy and TermsShowing Port GroupShowing Port Group
Physical End Station
Apps Apps Apps Apps Apps Apps
Port GroupA set of vPorts withsimilar configuration
VEB, vSwitch, vmSwitch
GOS
Apps
GOS
Apps
GOS
Apps
GOS
Apps
GOS
Apps
GOS
Appsg(such as VLAN ID)
Adjacent Bridge
24 19-Jul-09
VEB Loop-free Forwarding BehaviorVEB Loop-free Forwarding Behavior
• Forwards based on MAC address • Forwards based on MAC address (and port group or VLAN)
• Forwards vNIC vNICVM VM VM VM VM VM
Physical End Station
− vNIC vNIC− vNIC Uplink
• Does NOT forward from uplink to uplink
VM VM VM VM
VEB
VM VMA B C D E F
uplink− Single active logical uplink− Multiple uplinks may be ‘teamed’
(802 3ad and other algorithms)(802.3ad and other algorithms)
• Does not participate in (or affect) spanning tree
Adjacent Bridge1 2
25 19-Jul-09
Management & Config of VEB vPortsManagement & Config of VEB vPorts• General VLAN mode
/ S h h h M− VEB/vSwitch can terminate or pass VIDs through to VM − Tagged and/or untagged combinations exist for all ports in VEB
• Per-port VLAN Settings− vPort VLAN ID (PVID)− egress VLAN IDs (VIDs that can reach the port)
• MAC Address Security M C dd ess Secu y − Limit to assigned MAC− Allow guest-OS specific MACs− Promiscuous mode− Promiscuous mode
• Default priority and/or priority mapping per port• Traffic shaping & bandwidth management per port
26 19-Jul-09
Management & Config of VEB UplinksManagement & Config of VEB Uplinks• General VLAN mode
Same as any inter switch link − Same as any inter-switch link
• Uplinks (NICs) associated with a VEB• NIC Teaming Mode
− Fail-over− Transmit load-balancing− Bi-direction load-balancing (802.3ad, etc.)− Split Multi-Link Trunking
• DCBX Configuration− ETS QueuesETS Queues− Priority Flow Control
27 19-Jul-09
LLDP and DCBXLLDP and DCBX• LLDP & DCBX are between…
VEB uplink and− VEB uplink and− Adjacent bridge port− Uses MAC of physical NIC
LLDPVM VM VM VM VM VM
Physical End Station
• LLDP− Identifies physical NIC of the
physical end station
DCBX
VM VM VM VM
VEB
VM VMA B C D E F
• DCBX− Configures the physical NIC− Physical NIC ETS queues− Physical NIC PFC settings
• vNICs typically implement a single (lossless) queue
Adjacent Bridge1 2
28 19-Jul-09
Desired End-Station LLDP TransparencyDesired End-Station LLDP Transparency• LLDP between…
VM and− VM and− Adjacent bridge port− Uses MAC of VM
N d ifi d ti ti MACVM VM VM VM VM VM
Physical End Station
− Needs specific destination MAC
• LLDP− Identifies VM to Adjacent Bridge
VM VM VM VM
VEB
VM VMA B C D E F
− To propagate to Adjacent Bridge need ‘Nearest Customer Bridge’ destination address
Adjacent Bridge1 2
NOTE: This is unresolved today
29 19-Jul-09
VEB Address Table Managementg• VEBs typically don’t do learning
− Intended to be at the edge of the network not the middleIntended to be at the edge of the network, not the middle
• Instead, MAC addresses can be known by registrationH NIC d f l MAC dd− Hypervisors set vNIC default MAC address
− VMs register desired set of multicast addresses to receive− Hypervisors can intercept when a guest OS sets receive filters on a
NICvNIC• Locally Administered Address (LAA)• Multicast addresses
• VEB Address Table entries− Provide forwarding information
P id h i fil i f h NIC
30 19-Jul-09
− Provide the receive filtering for the vNICs− Provides multicast filtering without IGMP snooping
VEB Address Table Populated via MAC registrationPopulated via MAC registration
DST MAC VLAN Copy To(ABCDEF Up)
VEB Address Table
A 1 100000 0
B 2 010000 0
C 1 001000 0VM VM VM VM VM VM
Physical End Station
viaD 2 000100 0
E 1 000010 0
F 2 000001 0
VM VM VM VM
VEB
VM VMA B C D E* F
registration
Adjacent Bridge1 2
31 19-Jul-09
* Promiscuous vPort
VEB Address Table Broadcast entriesBroadcast entries
DST MAC VLAN Copy To(ABCDEF Up)
VEB Address Table
A 1 100000 0
B 2 010000 0
C 1 001000 0VM VM VM VM VM VM
Physical End Station
D 2 000100 0
E 1 000010 0
F 2 000001 0
B 1 101010 1
VM VM VM VM
VEB
VM VMA B C D E* F
B d Bcast 1 101010 1
Bcast 2 010101 1
Based onVLAN ID
(Port Groups)
Adjacent Bridge1 2
32 19-Jul-09
* Promiscuous vPort
VEB Address Table Multicast entriesMulticast entries
DST MAC VLAN Copy To(ABCDEF Up)
VEB Address Table
A 1 100000 0
B 2 010000 0
C 1 001000 0VM VM VM VM VM VM
Physical End Station
D 2 000100 0
E 1 000010 0
F 2 000001 0
B 1 101010 1
VM VM VM VM
VEB
VM VMA B C D E* F
Bcast 1 101010 1
Bcast 2 010101 1
MulticastC 1 101010 1
Unk Mcast 1 100010 1
C registersa multicast listen
C avoids Unk Mcast 1 100010 1
Unk Mcast 2 010101 1Adjacent Bridge1 2
C avoidsother multicasts
33 19-Jul-09
* Promiscuous vPort
VEB Address Table Unknown unicast entriesUnknown unicast entries
DST MAC VLAN Copy To(ABCDEF Up)
VEB Address Table
A 1 100000 0
B 2 010000 0
C 1 001000 0VM VM VM VM VM VM
Physical End Station
D 2 000100 0
E 1 000010 0
F 2 000001 0
B 1 101010 1
VM VM VM VM
VEB
VM VMA B C D E* F
Bcast 1 101010 1
Bcast 2 010101 1
MulticastC 1 101010 1
Unk Mcast 1 100010 1Unk Mcast 1 100010 1
Unk Mcast 2 010101 1
Unk Ucast 1 000010 1
Unk Ucast 2 000000 1
Adjacent Bridge1 2
Flooding of unknownunicast limited to
34 19-Jul-09
U Ucas 000000 unicast limited topromiscuous ports
and uplink* Promiscuous vPort
VEB Address Table ExampleLocal UnicastLocal Unicast
DST MAC VLAN Copy To(ABCDEF Up)
VEB Address TableSRC = A; DST = C
A 1 100000 0
B 2 010000 0
C 1 001000 0VM VM VM VM VM VM
Physical End Station
D 2 000100 0
E 1 000010 0
F 2 000001 0
B 1 101010 1
VM VM VM VM
VEB
VM VMA B C D E* F
Bcast 1 101010 1
Bcast 2 010101 1
MulticastC 1 101010 1
Unk Mcast 1 100010 1Unk Mcast 1 100010 1
Unk Mcast 2 010101 1
Unk Ucast 1 000010 1
Unk Ucast 2 000000 1
Adjacent Bridge1 2
35 19-Jul-09
U Ucas 000000
* Promiscuous vPort
VEB Address Table ExampleExternal UnicastExternal Unicast
DST MAC VLAN Copy To(ABCDEF Up)
VEB Address TableSRC = A; DST = Z
A 1 100000 0
B 2 010000 0
C 1 001000 0VM VM VM VM VM
Physical End Station
VMD 2 000100 0
E 1 000010 0
F 2 000001 0
B 1 101010 1
VM VM VM VM
VEB
VMA B C D F
VME*
Bcast 1 101010 1
Bcast 2 010101 1
MulticastC 1 101010 1
Unk Mcast 1 100010 1
DST Z is not in table since Unk Mcast 1 100010 1
Unk Mcast 2 010101 1
Unk Ucast 1 000010 1
Unk Ucast 2 000000 1
Adjacent Bridge1 2
in table since VEB typically
doesn’t do learning
36 19-Jul-09
U Ucas 000000
StationZ
* Promiscuous vPort
g
VEB Address Table ExampleMulticastMulticast
DST MAC VLAN Copy To(ABCDEF Up)
VEB Address TableSRC = A; DST = MulticastX, VLAN 1
A 1 100000 0
B 2 010000 0
C 1 001000 0VM VM VM VM VM VM
Physical End Station
D 2 000100 0
E 1 000010 0
F 2 000001 0
B 1 101010 1
VM VM VM VM
VEB
VM VMA B C D E* F
Bcast 1 101010 1
Bcast 2 010101 1
MulticastC 1 101010 1
Unk Mcast 1 100010 1Unk Mcast 1 100010 1
Unk Mcast 2 010101 1
Unk Ucast 1 000010 1
Unk Ucast 2 000000 1
Adjacent Bridge1 2
37 19-Jul-09
U Ucas 000000
* Promiscuous vPort
VM Migration Example
1 H i VM t t t
VM VM VM
Station 1
VM VM
Station 2
1
1. Hypervisors copy VM state to target destination.
2. Station 1 hypervisor halts VM & remo es address table VM
5VM VM VM
VEB
A B C
VM VM
VEB
X Y
& removes address table entries.
3. Station 2 hypervisor adds address table entries
VMC
000001 02F
000010 01E
000000 12Unk Ucast
000010 11Unk Ucast
DST MAC VLAN Copy To(ABCDEF Up)
A 1 100000 0
B 2 010000 0
C 1 001000 0
D 2 000100 0
Bcast 1 101010 1
Bcast 2 010101 1
MulticastC 1 101010 1
Unk Mcast 1 100010 1
Unk Mcast 2 010101 1
000001 02F
000010 01E
000000 12Unk Ucast
000010 11Unk Ucast
DST MAC VLAN Copy To(ABCDEF Up)
A 1 100000 0
B 2 010000 0
C 1 001000 0
D 2 000100 0
Bcast 1 101010 1
Bcast 2 010101 1
MulticastC 1 101010 1
Unk Mcast 1 100010 1
Unk Mcast 2 010101 1
VEB Address Table
000001 02F
000010 01E
000000 12Unk Ucast
000010 11Unk Ucast
DST MAC VLAN Copy To(ABCDEF Up)
A 1 100000 0
B 2 010000 0
C 1 001000 0
D 2 000100 0
Bcast 1 101010 1
Bcast 2 010101 1
MulticastC 1 101010 1
Unk Mcast 1 100010 1
Unk Mcast 2 010101 1
000001 02F
000010 01E
000000 12Unk Ucast
000010 11Unk Ucast
DST MAC VLAN Copy To(ABCDEF Up)
A 1 100000 0
B 2 010000 0
C 1 001000 0
D 2 000100 0
Bcast 1 101010 1
Bcast 2 010101 1
MulticastC 1 101010 1
Unk Mcast 1 100010 1
Unk Mcast 2 010101 1
VEB Address Table
2 3address table entries.
4. Station 2 hypervisor sends out gratuitous ARP to update external switch caches
4
Adjacent Bridge1
Adjacent Bridge1
external switch caches.
5. Station 2 activates VM.
38 19-Jul-09
Limitations of VEBs (today)
• Limited feature set compared to external switchesLi it d k t i (TCAM ACL )− Limited or no packet processing (TCAMs, ACLs, etc.)
− Limited support for security features (e.g., DHCP guard, ARP monitoring, source port filtering, dynamic ARP protection/inspection, etc.)
• Limited monitoring capabilities− Limited support for statistics and switch MIBs
− No NetFlow, sFlow, rmon, port mirroring, etc.
• Limited integration with external network management tsystems
• Limited support for promiscuous ports (typically no learning)
39 19-Jul-09
• Limited support for 802.1 protocols (e.g., STP, 802.1X, LLDP)
VEB References• Hypervisor vSwitches
− VMware• “VI3: Networking Concepts & Best Practices”, Session #TA2441, Guy Brunsdon, vmworld
2008• http://vmware.com/go/networking• VMware Infrastructure 3 Documentation
h // / / b / i b h lhttp://www.vmware.com/support/pubs/vi_pubs.html
− Microsoft− XEN
• htt // iki / iki/X N t ki• http://wiki.xensource.com/xenwiki/XenNetworking
• Hardware VEBs− Intel
htt //d l d i t l /d i / t k/d t ht /82576 D t h t df• http://download.intel.com/design/network/datashts/82576_Datasheet.pdf• http://download.intel.com/design/network/prodbrf/321731.pdf
− Broadcom− Neterion
40 19-Jul-09
− Neterion− Mellanox
Extending VEBs with Basic VEPAExtending VEBs with Basic VEPA
(Vi t l Eth t P t A t )(Virtual Ethernet Port Aggregator)
4119-Jul-09 HP Confidential - Not For Use With Customers
Basic, tag-less VEPA can address mostVEB limitations with minimal cost,
l N C h l b dminimal NIC changes, minimal bridge changes, no frame format changes, and
i i l IEEE ifi ti hminimal IEEE specification changes.
42 19-Jul-09
Virtual Ethernet Port AggregatorA DefinitionA Definition
A Vi t l Eth t P t A t (VEPA) i bilit ithi A Virtual Ethernet Port Aggregator (VEPA) is a capability within a physical end station that collaborates with an adjacent, external bridge to provide bridging support between multiple virtual end stations and external networks The VEPA collaborates by stations and external networks. The VEPA collaborates by forwarding all station-originated frames to the adjacent bridge for frame processing and frame relay (including ‘hairpin’ forwarding) and by steering and replicating frames received from the VEPA uplink to the appropriate destinations.
May be implemented in software or in conjunction with embedded hardwarehardware.
Note: As with the case of VEBs, VEPAs have access to vNIC configuration information that normally not available to an 802.1Q bridge.
43 19-Jul-09
Benefits VEPA adds to VEBBenefits VEPA adds to VEB• Gains access to external switch features
P k (TCAM ACL )− Packet processing (TCAMs, ACLs, etc.)− Security features such as: DHCP guard, ARP monitoring, source
port filtering, dynamic ARP protection/inspection, etc.
• Enhances monitoring capabilities− Statistics
NetFlow sFlow rmon port mirroring etc− NetFlow, sFlow, rmon, port mirroring, etc.
44 19-Jul-09
Basic VEPA Anatomy and TermsShowing Hardware + Software VEPAShowing Hardware + Software VEPA
Implementation can be split between software and hardware
Physical End Station
Apps Apps Apps Apps
GOS
Apps
GOS
Apps
Hardware VEPA
GOS
Apps
GOS
Apps
GOS
Apps
GOS
Apps
Ingress EgressSoftware VEPA*
expander
Adjacent Bridge
45 19-Jul-09
Basic VEPA Anatomy and TermsShowing Port GroupShowing Port Group
Physical End Station
Apps Apps Apps Apps Apps Apps
Port GroupA set of vPorts withsimilar configuration
VEPA
GOS
Apps
GOS
Apps
GOS
Apps
GOS
Apps
GOS
Apps
GOS
Appsg(such as VLAN ID)
Adjacent Bridge
46 19-Jul-09
Basic VEPA Anatomy and TermsKey constraint for basic tag less VEPA modeKey constraint for basic tag-less VEPA mode…
Physical End Station
Apps Apps Apps Apps Apps Apps
vNICs in basictag-less VEPA mode are NOT configured
VEPA
GOS
Apps
GOS
Apps
GOS
Apps
GOS
Apps
GOS
Apps
GOS
Appsare NOT configured for promiscuous
operation
This will be addressed in a
later section
Adjacent Bridge
later section
47 19-Jul-09
VEPA Loop-free Forwarding BehaviorVEPA Loop-free Forwarding Behavior
• Forwards based on MAC address • Forwards based on MAC address (and port group or VLAN)
• Forwards VM UplinkVM VM VM VM VM VM
Physical End Station
− VM Uplink• Never from VM to VM• Does NOT forward from uplink to
li k
VM VM VM VM
VEPA
VM VMA B C D E F
uplink− Single active logical uplink− Multiple uplinks may be ‘teamed’
(802 3ad and other algorithms)(802.3ad and other algorithms)
• Does not participate in (or affect) spanning tree
Adjacent Bridge1 2
48 19-Jul-09
Management & Config of VEPA vPortsis nearly identical to VEBis nearly identical to VEB
• General VLAN mode− VEB/vSwitch can terminate or pass VIDs through to VM − Tagged and/or untagged combinations exist for all ports in VEB
• Per-port VLAN Settingsp g− vPort VLAN ID (PVID)− egress VLAN IDs (VIDs that can reach the port)
• MAC Address Security • MAC Address Security − Limit to assigned MAC− Allow guest-OS specific MACs
P i d− Promiscuous mode
• Default priority and/or priority mapping per port• Traffic shaping & bandwidth management per port
49 19-Jul-09
Management & Config of VEPA Uplinksis nearly identical to VEBis nearly identical to VEB
• General VLAN mode− Same as any inter-switch link
• Uplinks (NICs) associated with a VEB• NIC Teaming ModeNIC Teaming Mode
− Fail-over− Transmit load-balancing
Bi direction load balancing (802 3ad etc )− Bi-direction load-balancing (802.3ad, etc.)− Split Multi-Link Trunking
• DCBX Configuration− ETS Queues− Priority Flow Control
• EVB Mode (VEB/VEPA)
50 19-Jul-09
LLDP and DCBXi i il t VEBis very similar to VEB
• LLDP & DCB are betweenVEB uplink and− VEB uplink and
− Adjacent bridge port− Uses MAC of physical NIC
LLDPVM VM VM VM VM VM
Physical End Station
• LLDP− Identifies physical NIC of the
physical end station
DCBX
VM VM VM VM
VEB
VM VMA B C D E F
• DCBX− Configures the physical NIC− Physical NIC ETS queues− Physical NIC PFC settings− Select EVB Mode (VEB/VEPA)
• vNICs typically implement a
Adjacent Bridge1 2
51 19-Jul-09
yp y psingle (lossless) queue
VEPA Address Table Managementi lik VEB Add T bl M tis like VEB Address Table Management
• VEPAs typically don’t do learning• VEPAs typically don t do learning− Intended to be at the edge of the network, not the middle
• Instead MAC addresses can be known by registration• Instead, MAC addresses can be known by registration− Hypervisors set vNIC default MAC address− Hypervisors can intercept when a guest OS sets receive filters on a
vNICvNIC• Locally Administered Address (LAA)• Multicast addresses
• VEPA Address Table entries− Provide the receive filtering for the vNICs
Provides multicast filtering without IGMP snooping
52 19-Jul-09
− Provides multicast filtering without IGMP snooping
VEPA Address Table Showing MAC multicast & unknown unicastShowing MAC, multicast, & unknown unicast
DST MAC VLAN Copy To(ABCDEF)
VEPA Address Table
A 1 100000
B 2 010000
C 1 001000VM VM VM VM VM VM
Physical End Station
viaD 2 000100
E 1 000010
F 2 000001
B 1 101010
VM VM VM VM
VEPA
VM VMA B C D E F
registration
Bcast 1 101010
Bcast 2 010101
MulticastC 1 101010
Unk Mcast 1 100010
C registersa multicast listen
C avoids Unk Mcast 1 100010
Unk Mcast 2 010101
Unk Ucast 1 000000
Unk Ucast 2 000000
Adjacent Bridge1 2
C avoidsother multicasts
53 19-Jul-09
U Ucas 000000
This example assume no promiscuous ports
Basic VEPA OperationUnicast to local addressUnicast to local address
DST MAC VLAN Copy To(ABCDEF)
VEPA Address TableSRC = A; DST = C
A 1 100000
B 2 010000
C 1 001000VM VM VM VM VM VM
Physical End Station
D 2 000100
E 1 000010
F 2 000001
B 1 101010
VM VM VM VM
VEPA
VM VMA B C D E F
3Bcast 1 101010
Bcast 2 010101
MulticastC 1 101010
Unk Mcast 1 100010
1
31. All ingress frames
forwarded to adjacent bridge
2 F f d d Unk Mcast 1 100010
Unk Mcast 2 010101
Unk Ucast 1 000000
Unk Ucast 2 000000
Adjacent Bridge1 2
2
2. Frame forwarded based on adj. bridge learning.
3. Frame forwarded b d d li
54 19-Jul-09
U Ucas 000000based on delivery mask generated from VEPA address table
Basic VEPA OperationMulticastMulticast
DST MAC VLAN Copy To(ABCDEF)
VEPA Address TableSRC = A; DST = MulticastC
A 1 100000
B 2 010000
C 1 001000VM VM VM VM VM VM
Physical End Station
D 2 000100
E 1 000010
F 2 000001
B 1 101010
VM VM VM VM
VEPA
VM VMA B C D E F
3
4
Bcast 1 101010
Bcast 2 010101
MulticastC 1 101010
Unk Mcast 1 100010
1 1. All ingress frames forwarded to adjacent bridge
2 Frame forwarded by Unk Mcast 1 100010
Unk Mcast 2 010101
Unk Ucast 1 000000
Unk Ucast 2 000000
Adjacent Bridge1
2
2. Frame forwarded by adjacent bridge.
3. Create delivery maskDST Lookup = 101010SRC L k 100000
55 19-Jul-09
U Ucas 000000
4. Deliver Frame Copies
SRC Lookup = 100000Delivery Mask = 001010
VEPA Address Table vPort on multiple VLANsvPort on multiple VLANs
DST MAC VLAN Copy To(ABCDEF)
VEPA Address Table
A 1 100000
B 1,2 010000
C 1 001000VM VM VM VM VM VM
Physical End Station
D 2 000100
E 1 000010
F 2 000001
B 1 111010
VM VM VM VM
VEPA
VM VMA CB D E F
Bcast 1 111010
Bcast 2 010101
MulticastC 1 111010
Unk Mcast 1 110010Unk Mcast 1 110010
Unk Mcast 2 010101
Unk Ucast 1 000000
Unk Ucast 2 000000
Adjacent Bridge1 2
56 19-Jul-09
U Ucas 000000
VEPA Address Table vPorts in Dual Listening ModevPorts in Dual Listening Mode
DST MAC VLAN Copy To(ABCDEF)
VEPA Address TableBoth Listening
for DST MAC H
A 1 100000
B 2 010000
C 1 001000VM VM VM VM VM VM
Physical End Station
D 2 000100
E 1 000010
F 2 000001
H 1 101000
VM VM VM VM
VEPA
VM VMA B C D E F
H 1 101000
Bcast 1 101010
Bcast 2 010101
MulticastC 1 101010Caused by VMs A & C registering MulticastC 1 101010
Unk Mcast 1 100010
Unk Mcast 2 010101
Unk Ucast 1 000000
Adjacent Bridge1 2
A & C registeringH as a listening MAC address (if allowed by hypervisor)
57 19-Jul-09
U Ucas 000000
Unk Ucast 2 000000hypervisor)
Enabling Adjacent Bridge Policyg j g y
VM Edge Switch Edge
VEB mode allows VM-to-VM traffic with limited policy
VM
VM VEB L2 net(s)
limited policy enforcement.
C i i i d b h
VM
VM
VM
ConnectionProfiles
vSwitch
Connection settings communicated to both VM Edge and Switch Edge.
VM
VM
VM
VEPA
VEPA mode forces all traffic to fully-capable
edge for full policy
L2 net(s)
VM policy
enforcement.
58 19-Jul-09
‘Basic VEPA’ LimitationsBasic VEPA Limitations
• Basic VEPA is challenged by promiscuous ports− Must have complete address table and learning is discouraged− Difficult to create proper destination mask to account for promiscuous ports− Useful to support transparent services
• Want mix of VEPA and VEB ports on single physical link− Allow for optimized performance configuration
59 19-Jul-09
Problem with Dynamic AddressesSRC = Z; DST = MulticastC
DST MAC VLAN Copy To(ABCDEF)
VEPA Address Table
SRC = Z; DST = MulticastC
A 1 100000
B 2 010000
C 1 001000
Physical End Station
*
D 2 000100
E 1 000010
F 2 000001
B 1 101010
VM VM VM
VEPA
VM VMA B C D E F
TS
Bcast 1 101010
Bcast 2 010101
MulticastC 1 101010
Unk Mcast 1 100010Unk Mcast 1 100010
Unk Mcast 2 010101
Unk Ucast 1 000000
Unk Ucast 2 000000
Adjacent Bridge1
60 19-Jul-09
U Ucas 000000
EVB Acceptable Constraintsp
• Primary use model is the connection of individual yvirtual end-stations
• Individual Virtual Machine vNIC configuration is gknown a head of time.
• VEPAs can be cascaded in software to increase i f dd bl d b f bl size of address tables and number of supportable
VMsP i i ti d l i th th b t • Primary communication model is north-south, but optimized east-west traffic can be combined using same resources.
61 19-Jul-09
Tagging Schemes to the Rescuegg g
• Filtering problem is eliminated by ‘isolating’ the • Filtering problem is eliminated by isolating the vPorts
• Tagging schemes provide a virtual port indication Tagging schemes provide a virtual port indication for the adjacent bridge
• Normal bridge learning and flooding are g g gextended can be extended to vPorts
• New problems arise…
62 19-Jul-09
Tagging Schemes Create Virtual Portsgg g
Bridge
PhysicalPhysical
Virtualizer(VEPA)
y
Station
y
StationVirtual
Machine
Virtual
Machine
Expanding Switch Ports with p gInterface Virtualizers andVN TVN-Tags
64 19-Jul-09 hudson-vepa_seminar-20090514.pdf
The VN Tag approach addresses VEB The VN-Tag approach addresses VEB limitations by inventing a new device, the Interface Virtualizer – this requires the Interface Virtualizer this requires significant changes to NICs, significant changes to switches, a new frame g ,format, and significant changes to IEEE specifications.
65 19-Jul-09
Interface VirtualizerA DefinitionA Definition
An Interface Virtualizer (IV) is a new networking device that operates as an extension to a centralized controlling bridge and expands the
b f it h t t f l i l 802 1Q li t number of switch ports to form a larger single 802.1Q compliant bridge (i.e. a line card on a rope). The IV tunnels packets back to the controlling bridge using a new frame format that defines a VNTag. The IV is responsible for replicating multicast traffic to multiple The IV is responsible for replicating multicast traffic to multiple downstream ports.
May be implemented in software or in conjunction with embedded h d ( N 1000 d 2000 )hardware (e.g Nexus 1000v and 2000v)
66 19-Jul-09
Basic IV Anatomy and TermsShowing Hardware + Software IVShowing Hardware + Software IV
Implementation can be split between software and hardwarePhysical Machine
Physical PortExtension
Blade SystemGOS
Apps
GOS
Apps
between software and hardwarePhysical Machine,Virtual Machine,
Bridge
Extension
GOS
Apps
GOS
Apps
GOS
Apps
Ingress EgressSoftware IVVirtual InterfaceIdentifier (VIF)
Hardware IV
IV Uplink Port
IV Downlink Port
C ll B d
IV Capable Bridge Port
p
IVs resemble a
67 19-Jul-09
Controlling BridgeVirtual Interface
IVs resemble a remote line card
IV Forwarding BehaviorIV Forwarding Behavior
• Forwards based on VNTag• Forwards based on VNTag• Forwards
− VM UplinkN f VM VM
Port Expander / Interface Virtualizer
• Never from VM to VM• Does NOT forward from uplink to
uplinkIV
A B C D E F
− Single active logical uplink− Multiple uplinks may be ‘teamed’
(802.3ad and other algorithms)
D ( ff ) • Does not participate in (or affect) spanning treeControlling Bridge
1 2
68 19-Jul-09
VNTag Proposalg p
Ethertype d p Dvif_id or vif_list_idl r ver Svif idl r ver Svif_id
Ethertype: TBD, identifies the VNTag
d: Direction, 0 indicates that the frame is traveling from the IV to the bridge. 1 indicates the , g gframe is traveling from the bridge to the IV
p: Pointer: 1 indicates that a vif_list_id is included in the tag. 0 indicates that a Dvif_id is included in the frame
vif_list_id: Pointer to a list of downlink ports to which this frame is to be forwarded (replicated)
Dvif_id: Destination vif_id of the port to which this frame is to be forwarded. Two most significant bits are reserved.
Note: the Dvif_id / vif_list_id field is reserved if d is 0.
l: Looped: 1 indicates that this is a multicast frame that was forwarded out the bridge port on which it was received. In this case, the IV must check the Svif_id and filter the frame from the corresponding port
r: reserved
ver: Version of this tag, set to 0
Svif_id The vif_id of the downlink port that received this frame from the VNIC (i.e. the port that added the VNTag). This field is reserved if d=1 and l=0.
Source Cisco: IEEE 802.1 Interim – New Orleans – Jan 15, 2009
Frame FormatsFrame FormatsMay or may not be present
Original(vPort <-> Port Expander)
Original+VN-Tag(CB <-> Port Expander)(CB < > Port Expander)
EthertypedpDvif_id or vif_list_idl r ver Svif_id
70 19-Jul-09
IV Table Managementi NOTHING lik VEB Add T bl M tis NOTHING like VEB Address Table Management
• IVs do not have an address table − IVs do not look at MAC Addresses− All forwarding is based upon the VNTag− VNTag to port mapping table is a new hardware structure
• VNTag represents a new name space− Each downlink interface has a 12-bit Virtual Interface Identifier− The scope of the tag is determined by the controlling bridge− Unique tags determine packet replication (e.g multicast and flooding)
l d bl• A new protocol is required to manage tables− IVs know how many ports they have− IVs are told about tags for replication
71 19-Jul-09
IV Forwarding Table Showing VNTag and Port Replication EntryShowing VNTag and Port Replication Entry
Example: IV Port Replication Ta
SRC = A; DST = C
VIF-ID VIF Mask
1 100000000000
2 010000000000
Port ExpanderExample: IV Port Replication Ta
3 001000000000
4 000100000000
5 000010000000
0000000X0000
Interface Virtualizer
A B C D E F apriori IVassigned
5 … 0000000X0000
N 000000000001
…
M-2 (M1 V1) 101000000000controlling bridge assigned (based upon VLANs
1
5
M-1 (M1 V2) 010000000000
M (M2 V2) 010100000000
(based upon VLANs, Mcasts, ACLs, etc)
3
24
72 19-Jul-09
Controlling Bridge3
IV Forwarding Table Showing VNTag and Port Replication EntryShowing VNTag and Port Replication Entry
Example: IV Port Replication Table
SRC = A; DST = Broadcast
Port Expander VIF-ID VIF Mask
1 100000000000
2 010000000000
Example: IV Port Replication Table
Interface Virtualizer
A B C D E F apriori IVassigned
3 001000000000
4 000100000000
5 000010000000
0000000X000056
… 0000000X0000
N 000000000001
…
M-2 (M1 V1) 101010000000
1
51. All ingress frames are
tagged and forwardedto controlling bridge
2 T d M-1 (M1 V2) 010000000000
M (M2 V2) 01010000000024
2. Tag removed, ingressvirtual bridge port
3. Flood to all ports in VLAN
4. Identify unique tag for group of virtual interfacesControlling Bridge
73 19-Jul-09
3
. de y u que ag o g oup o v ua e aces
5. Calculate delivery mask from tag
6. Remove tag and deliver frame copies
Issues with VNTag Approach• Using a hierarchy of interface virtualizers…
− Significantly limits the network cross-sectional bandwidth− Increases congestionIncreases congestion− Often increases the number of links traversed
• Constrains innovations in distributed computing− Blocks advantages of locality in distributed systemsBlocks advantages of locality in distributed systems
• Distributed storage solutions, nearby caching servers, etc.
− Blocks benefits of increased end-station capabilities over time
• VNTags increases hardware complexity to end stationsg− Significantly different than already-required VEB− New forwarding and frame replication mechanisms
• VNTags require significant new standards efforts− New tag format− Management of remote frame replication
• VNTags will not work with any switch not specifically designed for it
74 19-Jul-09
− Adds significant cost and complexity to controlling bridge− Constrains other bridges to be remote line cards for controlling bridge
Issues with VNTag:Performance Choke PointPerformance Choke Point
• Total switching capacity of Total switching capacity of − N physical end stations and − N*M virtual servers
Controlling Bridge
is constrained to the speed of the uplink to the controlling bridge.
Port Expander
• Introduces additional latency.
B k di ib d i
Port Expander
VM VM• Breaks distributed computing
approaches that can exploit physical proximity.
VM
Physical End Station
VM
75 19-Jul-09
VN-Tag + IV + Hardware VEBVN-Tag + IV + Hardware VEB
• The Interface Virtualizer is an unnatural addition to a HW VEB
−New hardware tables and structures−New packet modifications−New configuration protocols
76 19 July 2009
A History of Proprietary SolutionsProprietary Open
Routing EIGRP RIP/OSPF
Spanning Tree PVST+ 802.1s
VLANs ISL 802.1Q
Link Aggregation FEC 802.3ad (LACP)Link Aggregation FEC 802.3ad (LACP)
Discovery CDPPDA - Phone Discovery Algorithm
802.1AB (LLDP)LLDP-MED
Power Cisco PoE 802 3afPower Cisco PoE 802.3af
Roaming WLCPP 802.11(fast roaming)
Security LEAP 802.1X
Client Access Cisco NAC Trusted Network Connect (TNC/TCG)
Wireless Cisco Compatible Extensions (CCX) 802.11i
Virtualization VNTag VN Link 802 1bg 802 1bh
77
Virtualization VNTag, VN-Link 802.1bg, 802.1bh
802.1 Standardization
Converging Proposals
78 19-Jul-09 HP Confidential - Not For Use With Customers a
Benefits of VEB/VEPA Solution/• VEPA is a simple extension to VEB
− Similar port configurationSimilar port configuration− Similar address table− Minor changes to frame forwarding behavior
• VEPA solves nearly all of the issues with VEBs• Allows easy migration between VEB and VEPA modes
ll i lt ti f VEB d VEPA− allows simultaneous operation of VEB and VEPA
• Requires minimal 802.1 standards effort− Configuration of hair-pin modeg p
• Basic mode is easiest to implement− Can be implemented in many existing switches with a firmware
d t
79 19-Jul-09
update− Simple extension to existing vSwitches/VEBs
VEPA Open Source ImplementationVEPA Open Source Implementation• Patches available for VEPA and hairpin mode:−net/bridge: base 2.6.30 kernel, Xen’s 2.6.18.8 Dom0−bridge-utils: brctl commands to enable/disable modes
l l l− tools: Xen tools equivalent
• Very minor changes requiredf−37 lines of code in VEPA data path
−2 lines of code for hairpin mode
T d i KVM d X• Tested in KVM and Xen• Tested against 3rd party switch with hairpin mode
80 19-Jul-09
Specification Needs for Basic VEPA OperationOperation
DST MAC VLAN Copy To(ABCDEF)
Static VEPA Address Table
A 1 100000
B 2 010000
C 1 001000VM VM VM VM VM VM
Physical End Station
D 2 000100
E 1 000010
F 2 000001
B 1 101010
VM VM VM VM
VEPA
VM VMA B C D E F
Bcast 1 101010
Bcast 2 010101
MulticastC 1 101010
Unk Mcast 1 100010Unk Mcast 1 100010
Unk Mcast 2 010101
Unk Ucast 1 000000
Unk Ucast 2 000000
Adjacent Bridge1
81 19-Jul-09
U Ucas 000000
VEPA+MultiChannel is a simple extension that allows basic VEPAs,
d l d hVEBs, and isolated vPorts to share a single physical port.
82 19-Jul-09
VEPA+MultiChannelA DefinitionA Definition
VEPA M ltiCh l (Vi t l Eth t P t A t Pl VEPA+MultiChannel (Virtual Ethernet Port Aggregator Plus MultiChannel Ethernet) is a capability that uses S-VIDs to identify multiple virtual switch ports on a single physical switch port. Each virtual switch port may then be associated with a VEB basic VEPA or virtual switch port may then be associated with a VEB, basic VEPA, or an isolated vPort within the physical station.
This capability is enabled by an S-Component within the physical t ti t id tif th t t ti id l t (VEB b i station to identify the separate station-side elements (VEBs, basic
VEPAs, or isolated vPorts) and a corresponding S-Component in the adjacent bridge that maps those elements to virtual switch ports in the adjacent bridgeadjacent bridge.
The MultiChannel capability leverages the existing 802.1 standard components for Provider Bridging
83 19-Jul-09
VEPA+MultiChannelNew Anatomy and Terms
Physical End Station
VM VM VM VM VM VM Virtualization Port (vPort)
vBridge Layer(VEB, VEPA, etc.)
May be hardware,software, or mix.
VEPA-BasicVEB
S-ComponentA B C D E F
h l d
Virtual Uplink
S Component
Adjacent Bridge
Physical End StationS-Component
S-ComponentA B C D E F
S-Component
Virtual Bridge Port
84 19-Jul-09
g(may be VEPA-enabled)
VEPA+MultiChannelNew Anatomy and Terms
Physical End Station
VM VM VM VM VM VM Virtualization Port (vPort)
vBridge Layer(VEB, VEPA, etc.)
May be hardware,software, or mix.
VEPA-BasicVEB
S-ComponentA B C D E F
h l d
Virtual Uplink
S Component
Adjacent Bridge
Physical End StationS-Component
S-ComponentA B C D E F
S-Component
Virtual Bridge Port
85 19-Jul-09
g(may be VEPA-enabled)
VEPA+MultiChannel ApproachIsolation vPort
Physical End Station
VM VM VM VM VM VM
PVID set at vPortVEPA-BasicVEB
S-ComponentA B C D E FSVID set at vUplink S Component
S-ComponentA B C D E F
SVID removed
Placed on network identified by C-VID set at the vPort (or VM) or
86 19-Jul-09
by the default PVID for virtual bridge port
VEPA+MultiChannel ApproachExample: Basic VEB Unicast to Local VM
Physical End Station
VM VM VM VM VM VM
VEPA-BasicVEB
S-ComponentA B C D E F
S Component
S-ComponentA B C D E F
87 19-Jul-09
VEPA+MultiChannel ApproachExample: Basic VEPA Unicast to Local VM
Physical End Station 1. VEPA ingress frame from VM forwarded out VEPA uplink to S C
VM VM VM VM VM VMS-Component
2. Station S-Component adds SVID (F)
3. Bridge S-Component removes VEPA-BasicVEB
S-ComponentA B C D E F
1
26
7
3. Bridge S Component removes SVID (F)
4. Bridge Virtual Port is configured for VEPA mode, so it forwards based on bridge forwarding S Component g gtable (unblocked on virtual switch port F).
5. Bridge S-Component adds SVID (F)
S-ComponentA B C D E F3 5
( )
6. Station S-Component removes SVID (F)
7. VEPA forwards frame based on its VEPA address table
88 19-Jul-09
4its VEPA address table.
VEPA+MultiChannel ApproachExample: Using Transparent Service Separating Blue & Purple VLANs
Physical End Station
7
1. VEPA ingress frame from VM forwarded out VEPA uplink to S-Component
VM VM VM VM VM VM7
p
2. Station S-Component adds SVID (F)
3. Bridge S-Component removes SVID (F)
VEPA-BasicVEB
S-ComponentA B C D E F
1
26
4. Forwards based on bridge forwarding table to virtual switch port E.
5. Bridge S-Component adds SVID (D)8S Component
6. Station S-Component removes SVID (D)
7. Transparent service bridges across to purple VLAN
S-ComponentA B C D E F
35
purple VLAN.
8. Station S-Component adds SVID (C)
9. Bridge S-Component removes SVID (C)
9
89 19-Jul-09
4 10. Bridge forwards frame on purple VLAN.10
A Port Expanderwith adjacent bridge multicast replicationwith adjacent bridge multicast replication
Physical End Stations
S C tA B C D E F
Port Expander
S-Component
S-ComponentA B C D E F Controlling Bridge
90 19-Jul-09
Adjacent Bridge Replicates As Neededj g p
Physical End Stations
S C tA B C D E F
Port Expander
S-Component
S-ComponentA B C D E F Controlling Bridge
91 19-Jul-09
Discussion of Remote Replication Services• VEPA+Multichannel standardization can be covered by a
‘hairpin’ standard and leveraging existing S-ComponentsP E d i h d li i ld b • Port Expander without downstream replication could be covered by existing S-Components
• Non-address based downstream replication is the only Non address based downstream replication is the only remaining ‘unique’ item within VN-Tag proposal− NOTE: This, however, may be harder to solve than it sounds
• Both explicit Ingress+Egress indicators are only needed to • Both explicit Ingress+Egress indicators are only needed to support downstream replication (broadcast/multicast/flood)
• A new bridge ‘component’ could be envisaged to solve the g p gproblem.− NOTE: There may be other choices, this is just an idea
• A new ‘tag’ is required but can be layered on the existing A new tag is required, but can be layered on the existing tag structure.
92 19-Jul-09
Port Expanderwith Downstream Replicationp
Physical End Station
NOTE: new tag required (new
ethertype mif list)
S-ComponentA B C D E F
A B C D E F
ethertype, mif_list), original S-VID tag
left on
M-Component
M Component
A B C D E F
S-ComponentA B C D E F
M-ComponentA B C D E F
93 19-Jul-09
M-Component Collects and Replicatesp p
Physical End Station
NOTE: new tag required (new
ethertype mif list)
S-ComponentA B C D E F
A B C D E F
ethertype, mif_list), original S-VID tag
left on
M-Component
M Component
A B C D E F
S-ComponentA B C D E F
M-ComponentA B C D E F
94 19-Jul-09
Frame FormatsFrame Formats
Original
May or may not be present
Original(vPort <-> Port Expander)
Original+MultiChannel(CB <-> Port Expander) S-Tag:
•Src vPort (PE -> CB) OR
Original+
v ( )•Dst vPort (CB -> PE)•Flags
M-Tag:MIF l ID
S-Tag:S P
OriginalMultiChannel+MultiCast(CB -> Port Expander)
95 19-Jul-09
•MIF_list_ID•Flags
•Src vPort•Flags
Roadmap to Convergencep g
• Proposed – 802.1bg – Edge Virtual Bridging− Enables hairpin forwarding on a per-port basis when VEPA is
directly attached− Defines a MultiChannel service to remote ports
VEPA BasicMultichannel
• Proposed – 802.1bh – Bridge Port Expansion− Defines a tag to represent a group of remote ports for which a
frame is to be replicated
Multichannel
frame is to be replicated− Requires a protocol to communicate tag definitions− Dependent upon Edge Virtual Bridging
f h l dReplication Tag
− Most important for physical port expandersp g
96 19-Jul-09
SummarySu a y
• The success of virtualization will depend upon d d b d l k
p popen, standards based virtual networking
• Ease of migration and time-to-market are i t t f t t idimportant factors to consider
• A balance between performance, functionality and manageabilit is neededand manageability is needed
• Current 802.1 proposals are the least intrusive and provide the most flexibility and choiceand provide the most flexibility and choice.
97 19-Jul-09
Thank YouThank You
© 2009 Hewlett-Packard Development Company, L.P.The information contained herein is subject to change without notice