yahoo-eng-team team mailing list archive

[sean mooney <smooney@xxxxxxxxxx>]

Public bug reported:


as part of resolving https://bugs.launchpad.net/nova/+bug/1370348
https://github.com/openstack/nova/commit/386e38198d63cf2dc45507ca7e4dc82f0bcd9bb9
incorrectly asserted that 

# The ip utility doesn't accept the MAC 00:00:00:00:00:00.
# Therefore, keep the MAC unchanged.  Later operations on
# the same VF will not be affected by the existing MAC.

while it may have beent true that at one point the ip utility did
not support setting MAC 00:00:00:00:00:00 i has supported it for some
time. That however is not the issue. setting the mac of the vf back to the
the vm mac was never correct as it introduce a new bug.

By configuring a mac on a vf, in this case the vm mac the mac filter on the 
PF will nologer allow a packet with the vm mac as a destiation to leave the host.
This is part of the PF loop prevention mechanium and create a possible network partition.

if for example the vm is deleted on host A and the neutron port is
reused to spawn a new vm on a different host B, packet on host A will be
able to be transmitted to the vm on Host b.

This also means if the vm is cold/live migrated or resized the same partitioning will occur
between the source and dest node.

in the event of a converged deployment where the pf is used by ovs if that first host
ran the neutron l3 or dhcp agent then it would futher degread connectivity as any unicast packet that was transmisted to the removte vm either in responce to a dhcp request or as a result of floating-ip/snat translation or routing will be dropped.

** Affects: nova
     Importance: High
     Assignee: sean mooney (sean-k-mooney)
         Status: Confirmed


** Tags: libvirt sriov

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1808252

Title:
  libvirt: unplug_hw_veb incorrectly set vm mac on vf

Status in OpenStack Compute (nova):
  Confirmed

Bug description:
  
  as part of resolving https://bugs.launchpad.net/nova/+bug/1370348
  https://github.com/openstack/nova/commit/386e38198d63cf2dc45507ca7e4dc82f0bcd9bb9
  incorrectly asserted that 

  # The ip utility doesn't accept the MAC 00:00:00:00:00:00.
  # Therefore, keep the MAC unchanged.  Later operations on
  # the same VF will not be affected by the existing MAC.

  while it may have beent true that at one point the ip utility did
  not support setting MAC 00:00:00:00:00:00 i has supported it for some
  time. That however is not the issue. setting the mac of the vf back to the
  the vm mac was never correct as it introduce a new bug.

  By configuring a mac on a vf, in this case the vm mac the mac filter on the 
  PF will nologer allow a packet with the vm mac as a destiation to leave the host.
  This is part of the PF loop prevention mechanium and create a possible network partition.

  if for example the vm is deleted on host A and the neutron port is
  reused to spawn a new vm on a different host B, packet on host A will
  be able to be transmitted to the vm on Host b.

  This also means if the vm is cold/live migrated or resized the same partitioning will occur
  between the source and dest node.

  in the event of a converged deployment where the pf is used by ovs if that first host
  ran the neutron l3 or dhcp agent then it would futher degread connectivity as any unicast packet that was transmisted to the removte vm either in responce to a dhcp request or as a result of floating-ip/snat translation or routing will be dropped.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1808252/+subscriptions