Transcript [email protected]   Recap the proposal Questions from last meeting and answers M bit: 1 = migrated VDP request 0 = newly started VDP request M.

[email protected]


Recap the proposal
Questions from last meeting and answers
M bit:
1 = migrated VDP request
0 = newly started VDP request
M

to facilitate switch port configuration and
restore the states
◦ DHCP snooping based filtering
◦ Multicast group join

Problems: ToR port snoops DHCPACK and binds IP/MAC/port
to filter the following traffic. When VM moves, VM won’t
resend DHCP request and hence new port won’t listen any
DHCPACK. Therefore filter won’t be enabled on new port.
6
VM
NIC
1. DHCP request
4. DHCP Snooping
and set up IP/MAC
/port filter
2
3
DHCP Server
VM
vSwitch
Server
2. DHCP Request
migration
VM
vSwitch
5. DHCPACK
1
VM
6. VM migration.
Server
NIC
5
4
TOR
7
7. DHCP Snooping
based filter on new
port. How?
DCN
3. DHCP Ack
Note：DHCP Discover and
DHCP Offer exchanges are
ignored in picture

With M bit: trigger some standard DHCP in-band mechanism to be
used. E.g. DHCP leasequery
1
VM
Server
migration
VM
1. VM migration.
VM
VM
vSwitch
vSwitch
NIC
NIC
2. VDP request
w/ M bit 2
TOR
3. DHCP leasequery
DHCP Server
3
4
Server
6
5
4. DHCP Ack
6。VDP response
5. DHCP Snoops ACK
and set up IP/MAC
/port filter

Problems: VM1 sends IGMP join so that ToR would have a multicast
membership list including VM1 on certain port for certain multicast
group address. After migration, VM1 won’t resend IGMP join as it
has no awareness of movement of itself. Multicast membership list
won’t have VM1’s info enabled on new port until vm1 receives and
responds the general IGMP query from IGMP querier.
3
Server
VM
2
3、vm
migration
VM
Server
VM
VM
vSwitch
vSwitch
NIC
NIC
2、multicast
group
traffic
1
1、IGMP JOIN
4. New port joins VM’s
multicast groups. How?
TOR
TOR
GW
GW
IGMP
IGMP
查询器
querier

With M bit: trigger some standard IGMP in-band mechanism
to be used. E.g. new ToR port fakes IGMP query to VM
1
1.VM
migration
Server
VM
Server
VM
VM
vSwitch
VM
vSwitch
NIC
2
2. VDP request
w/ M bit
NIC
3
4
4. IGMP report
3. IGMP query
TOR
TOR
GW
GW
IGMP
IGMP
查询器
querier


Q: Without M bit, we can still use standard VDP
associate to trigger the DHCP/IGMP behavior we
want.
A: No, because of the timing. M bit (migration
completes) is a signal to do the triggering at the
right time. Conventional VDP is not strictly coupled
to VM’s state. (see next slide). Wrong timing
implies the high possibility to get wrong
information.
‘old’ EVB
Station
‘old’ EVB
Bridge
‘new’
EVB
Bridge
assoc_req
Uncertain
time
duration
VSI
power
on
‘new’
EVB
Station
assoc_rsp
Dataframe
Start
migration
Dataframe
Dataframe
Migration
completes
VSI can still join/leave
multicast group and
update its DHCP lease
assoc_req
assoc_rsp
Trigger DHCP/IGMP procedures assoc_req w/ M-bit
assoc_rsp
Uncertain
time
duration
Conclusion:
• M-bit indicates the completion of the migration which is the right time to trigger DHCP/IGMP procedures described
before
• pre-assoc/assoc can be sent at any time, it is not coupled to the migration state of VSI. And it is also used for
keepalive.


Q: Can hypervisor perform like DHCP relay/IGMP
relay to send the DHCP leasequery and IGMP query
instead of bridge?
A: Hypervisor could do that but we believe it would
be better to put all the functions on adjacent
bridge for the following reason
◦ Bridges have already implemented the features like DHCP
relay or IGMP relay/proxy. There is little extra functions
required. While hypervisors are not.
◦ There may come more real time configurations/provisions
other than DHCP/IGMP in future. It is tedious to have
hypervisor add features on demands of network
requirements every time.


Q: Can hypervisor know the state of VM?
A: Yes. Take VMWare’s vSphere as example. It has
the event to indicate the start and end of a
migration with event type
VmBeingHotMigratedEvent and VmMigratedEvent.
Hence it is considered implementation practical for
hypervisor being able to set M bit at right time.