Edge Virtual Bridging - Home | Internet2 Virtual Bridging July 2009 Paul Congdon (HP ProCurve) [email protected] Agenda • IEEE 802.1 history/background • Definition of EVB

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


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


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


− 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


• 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


− 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


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


VEB Address Table

A 1 100000 0

B 2 010000 0



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


VEB Address Table

A 1 100000 0

B 2 010000 0



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


VEB Address Table

A 1 100000 0

B 2 010000 0



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


Unk Mcast 1 100010 1Unk Mcast 1 100010 1


Unk Ucast 1 000010 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


VEB Address TableSRC = A; DST = C

A 1 100000 0

B 2 010000 0



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






Adjacent Bridge1 2

35 19-Jul-09

U Ucas 000000

* Promiscuous vPort

VEB Address Table ExampleExternal UnicastExternal Unicast


VEB Address TableSRC = A; DST = Z

A 1 100000 0

B 2 010000 0

C 1 001000 0VM VM VM VM VM


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



DST Z is not in table since Unk Mcast 1 100010 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


VEB Address TableSRC = A; DST = MulticastX, VLAN 1

A 1 100000 0

B 2 010000 0



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






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


A 1 100000 0

B 2 010000 0

C 1 001000 0

D 2 000100 0

Bcast 1 101010 1

Bcast 2 010101 1




000001 02F

000010 01E

000000 12Unk Ucast

000010 11Unk Ucast


A 1 100000 0

B 2 010000 0

C 1 001000 0

D 2 000100 0

Bcast 1 101010 1

Bcast 2 010101 1




VEB Address Table

000001 02F

000010 01E

000000 12Unk Ucast

000010 11Unk Ucast


A 1 100000 0

B 2 010000 0

C 1 001000 0

D 2 000100 0

Bcast 1 101010 1

Bcast 2 010101 1




000001 02F

000010 01E

000000 12Unk Ucast

000010 11Unk Ucast


A 1 100000 0

B 2 010000 0

C 1 001000 0

D 2 000100 0

Bcast 1 101010 1

Bcast 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


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



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…



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


− 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


• 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


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


VEPA Address TableSRC = A; DST = C

A 1 100000

B 2 010000



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


VEPA Address TableSRC = A; DST = MulticastC

A 1 100000

B 2 010000



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


VEPA Address Table

A 1 100000

B 1,2 010000



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


VEPA Address TableBoth Listening

for DST MAC H

A 1 100000

B 2 010000



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


VEPA Address Table

SRC = Z; DST = MulticastC

A 1 100000

B 2 010000

C 1 001000


*

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


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


Static VEPA Address Table

A 1 100000

B 2 010000



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


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-Component

Virtual Bridge Port

84 19-Jul-09

g(may be VEPA-enabled)

VEPA+MultiChannelNew Anatomy and Terms


VM VM VM VM VM VM Virtualization Port (vPort)

vBridge Layer(VEB, VEPA, etc.)

May be hardware,software, or mix.

VEPA-BasicVEB


h l d

Virtual Uplink

S Component

Adjacent Bridge

Physical End StationS-Component


S-Component

Virtual Bridge Port

85 19-Jul-09

g(may be VEPA-enabled)

VEPA+MultiChannel ApproachIsolation vPort


VM VM VM VM VM VM

PVID set at vPortVEPA-BasicVEB

S-ComponentA B C D E FSVID set at vUplink S Component


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


VM VM VM VM VM VM

VEPA-BasicVEB


S Component


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


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


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


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


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


NOTE: new tag required (new

ethertype mif list)


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


M-ComponentA B C D E F

93 19-Jul-09

M-Component Collects and Replicatesp p


NOTE: new tag required (new

ethertype mif list)


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


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

Documents

Edge Virtual Bridging - Home | Internet2 Virtual Bridging July 2009 Paul Congdon (HP ProCurve) [email protected] Agenda • IEEE 802.1 history/background • Definition of EVB