group.of.nepali.translators team mailing list archive

[Christian Ehrhardt  <1805920@xxxxxxxxxxxxxxxxxx>]

To keep potential regressions even lower I'd for now only consider that for >=Bionic.
That also helps as if someone intentionally spawns an old type KVM machine (pre Bionic) on a >=Bionic host we don#t have to care about this too much (machine type, not release runnin IN the guest). That makes us able to ignore ipxe-qemu-256k-compat-efi-roms in regard to this issue.

** Also affects: ipxe-qemu-256k-compat (Ubuntu)
   Importance: Undecided
       Status: New

** Changed in: linux (Ubuntu)
       Status: Confirmed => Invalid

** Also affects: linux (Ubuntu Cosmic)
   Importance: Undecided
       Status: New

** Also affects: ipxe (Ubuntu Cosmic)
   Importance: Undecided
       Status: New

** Also affects: ipxe-qemu-256k-compat (Ubuntu Cosmic)
   Importance: Undecided
       Status: New

** Also affects: linux (Ubuntu Xenial)
   Importance: Undecided
       Status: New

** Also affects: ipxe (Ubuntu Xenial)
   Importance: Undecided
       Status: New

** Also affects: ipxe-qemu-256k-compat (Ubuntu Xenial)
   Importance: Undecided
       Status: New

** Also affects: linux (Ubuntu Disco)
   Importance: Undecided
       Status: Invalid

** Also affects: ipxe (Ubuntu Disco)
   Importance: Undecided
       Status: Fix Released

** Also affects: ipxe-qemu-256k-compat (Ubuntu Disco)
   Importance: Undecided
       Status: New

** Also affects: linux (Ubuntu Trusty)
   Importance: Undecided
       Status: New

** Also affects: ipxe (Ubuntu Trusty)
   Importance: Undecided
       Status: New

** Also affects: ipxe-qemu-256k-compat (Ubuntu Trusty)
   Importance: Undecided
       Status: New

** Also affects: linux (Ubuntu Bionic)
   Importance: Undecided
       Status: New

** Also affects: ipxe (Ubuntu Bionic)
   Importance: Undecided
       Status: New

** Also affects: ipxe-qemu-256k-compat (Ubuntu Bionic)
   Importance: Undecided
       Status: New

** No longer affects: linux (Ubuntu Trusty)

** No longer affects: linux (Ubuntu Xenial)

** No longer affects: linux (Ubuntu Bionic)

** No longer affects: linux (Ubuntu Cosmic)

** No longer affects: linux (Ubuntu Disco)

** Changed in: ipxe-qemu-256k-compat (Ubuntu Trusty)
       Status: New => Invalid

** Changed in: ipxe-qemu-256k-compat (Ubuntu Xenial)
       Status: New => Invalid

** No longer affects: ipxe-qemu-256k-compat (Ubuntu Trusty)

** No longer affects: ipxe-qemu-256k-compat (Ubuntu Xenial)

** No longer affects: ipxe-qemu-256k-compat (Ubuntu Bionic)

** No longer affects: ipxe-qemu-256k-compat (Ubuntu Cosmic)

** No longer affects: ipxe-qemu-256k-compat (Ubuntu Disco)

** Changed in: ipxe-qemu-256k-compat (Ubuntu)
       Status: New => Won't Fix

** Changed in: ipxe (Ubuntu Trusty)
       Status: New => Won't Fix

** Changed in: ipxe (Ubuntu Xenial)
       Status: New => Won't Fix

** Changed in: ipxe-qemu-256k-compat (Ubuntu)
       Status: Won't Fix => Invalid

** Changed in: ipxe (Ubuntu Bionic)
       Status: New => Triaged

** Changed in: ipxe (Ubuntu Cosmic)
       Status: New => Triaged

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1805920

Title:
  iPXE ignores vlan 0 traffic

Status in MAAS:
  Invalid
Status in ipxe package in Ubuntu:
  Fix Released
Status in ipxe-qemu-256k-compat package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Invalid
Status in ipxe source package in Trusty:
  Won't Fix
Status in ipxe source package in Xenial:
  Won't Fix
Status in ipxe source package in Bionic:
  Triaged
Status in ipxe source package in Cosmic:
  Triaged
Status in ipxe source package in Disco:
  Fix Released

Bug description:
  I have three MAAS rack/region nodes which are blades in a Cisco UCS
  chassis. This is an FCE deployment where MAAS has two DHCP servers,
  infra1 is the primary and infra3 is the secondary. The pod VMs on
  infra1 and infra3 PXE boot fine but the pod VMs on infra2 fail to PXE
  boot. If I reconfigure the subnet to provide DHCP on infra2 (either as
  primary or secondary) then the pod VMs on infra2 will PXE boot but the
  pod VMs on the demoted infra node (that no longer serves DHCP) now
  fail to PXE boot.

  While commissioning a pod VM on infra2 I captured network traffic with
  tcpdump on the vnet interface.

  Here is the dump when the PXE boot fails (no dhcp server on infra2):
  https://pastebin.canonical.com/p/THW2gTSv4S/

  Here is the dump when PXE boot succeeds (when infra2 is serving dhcp):
  https://pastebin.canonical.com/p/HH3XvZtTGG/

  The only difference I can see is that in the unsuccessful scenario,
  the reply is an 802.1q packet -- it's got a vlan tag for vlan 0.
  Normally vlan 0 traffic is passed as if it is not tagged and indeed, I
  can ping between the blades with no problem. Outgoing packets are
  untagged but incoming packets are tagged vlan 0 -- but the ping works.
  It seems vlan 0 is used as a part of 802.1p to set priority of
  packets. This is separate from vlan, it just happens to use that
  ethertype to do the priority tagging.

  Someone confirmed to me that, in the iPXE source, it drops all packets
  if they are vlan tagged.

  The customer is unable to figure out why the packets between blades is
  getting vlan tagged so we either need to figure out how to allow iPXE
  to accept vlan 0 or the customer will need to use different equipment
  for the MAAS nodes.

  I found a conversation on the ipxe-devel mailing list that suggested a
  commit was submitted and signed off but that was from 2016 so I'm not
  sure what became of it. Notable messages in the thread:

  http://lists.ipxe.org/pipermail/ipxe-devel/2016-April/004916.html
  http://lists.ipxe.org/pipermail/ipxe-devel/2016-July/005099.html

  Would it be possible to install a local patch as part of the FCE
  deployment? I suspect the patch(es) mentioned in the above thread
  would require some modification to apply properly.

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