** Tags added: cscc
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1805920
Title:
iPXE ignores vlan 0 traffic
To manage notifications about this bug go to:
This bug was fixed in the package ipxe - 1.0.0+git-20180124.fbe8c52d-
0ubuntu2.2
---
ipxe (1.0.0+git-20180124.fbe8c52d-0ubuntu2.2) bionic; urgency=medium
* d/p/0005-strip-802.1Q-VLAN-0-priority-tags.patch: Strip 802.1Q VLAN 0
priority tags; Fixes PXE when VLAN tag is 0. (LP:
This bug was fixed in the package ipxe - 1.0.0+git-20180124.fbe8c52d-
0ubuntu4.1
---
ipxe (1.0.0+git-20180124.fbe8c52d-0ubuntu4.1) cosmic; urgency=medium
* d/p/0005-strip-802.1Q-VLAN-0-priority-tags.patch: Strip 802.1Q VLAN 0
priority tags; Fixes PXE when VLAN tag is 0. (LP:
I have two nodes, bionic and cosmic.
I enabled the proposed repo on each.
I installed ipxe:
apt install ipxe ipxe-qemu grub-ipxe
On bionic, this gave me:
# apt list --installed ipxe-qemu grub-ipxe ipxe
Listing... Done
grub-ipxe/bionic-proposed,bionic-proposed,now
As negative confirmation: I tested a PXE boot with
1.0.0+git-20180124.fbe8c52d-0ubuntu2.1 on bionic and
1.0.0+git-20180124.fbe8c52d-0ubuntu4 on cosmic.
As expected, the VMs failed to successfully PXE boot.
** Tags removed: verification-needed-bionic verification-needed-cosmic
** Tags added:
Any update on testing?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1805920
Title:
iPXE ignores vlan 0 traffic
To manage notifications about this bug go to:
s/Not/Note/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1805920
Title:
iPXE ignores vlan 0 traffic
To manage notifications about this bug go to:
Yes, sorry. I will try to test tonight (in a few hours) when I'm back at
the hotel. Not that I only have bionic and xenial to test with. I can
try to upgrade one of those to cosmic.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
@Vern - ping please test to unblock this from bionic-/cosmic-proposed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1805920
Title:
iPXE ignores vlan 0 traffic
To manage notifications about this
@Vern - if there is any ETA when you will get to the real SRU
verifications that were requested by Brian a week ago let us know
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1805920
Title:
iPXE
Hello Vern, or anyone else affected,
Accepted ipxe into bionic-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/ipxe/1.0.0+git-20180124.fbe8c52d-
0ubuntu2.2 in a few hours, and then in the -proposed repository.
Please help us by testing this new
Hello Vern, or anyone else affected,
Accepted ipxe into cosmic-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/ipxe/1.0.0+git-20180124.fbe8c52d-
0ubuntu4.1 in a few hours, and then in the -proposed repository.
Please help us by testing this new
Ok, thanks for the precheck Vern.
Now that we know that you will be able to SRU-verify this I have uploaded it to
the SRU queue.
Once accepted by the SRU Team there will be updates here asking for
verification. Please do that for Bionic and Cosmic then - if you need any help
let us know.
After realizing there are packages in the ci build [1] I installed the
following version from there:
1.0.0+git-20180124.fbe8c52d-0ubuntu4.1
I redefined the testipxe vm from the above test, and it also
successfully pxe booted.
[1]: https://launchpad.net/~ci-train-ppa-
I have run a test on cosmic. The test involved MAAS 2.4.3 installed on
bionic on 3 of the blades of the UCS chassis in the customer's data
center. I installed cosmic, 18.10 on a 4th blade and installed libvirt
and qemu-kvm and defined a VM similar to how maas defines VMs. with this
xml:
Ok, once you know you'll be able to verify it on Cosmic as well (by
successfully testing from the PPA) let me know.
We will then upload it as a real SRU which needs verification per [1].
[1]: https://wiki.ubuntu.com/StableReleaseUpdates
--
You received this bug notification because you are a
I was able to verify the fix works for bionic using maas 2.4.3. Am about
to install cosmic on the customer hardware to verify the fix there too.
I have run into a maybe-related issue with maas 2.5.0 filed separately
here: https://bugs.launchpad.net/maas/+bug/1811021
--
You received this bug
NO response yet, we really want to fix it but need some way to verify it.
Sorry to ask once again, but we need to get this unblocked.
@Vern - can you use the setup to verify the two planned uploads for Bionic and
Cosmic?
--
You received this bug notification because you are a member of Ubuntu
I'll upload once I get a confirmation that it will be tested on both
releases on the affected HW.
** Description changed:
[Impact]
* VLAN 0 is special (for QoS actually, not a real VLAN)
* Some components in the stack accidentally strip it, so does ipxe in
this case.
* Fix by
Thanks for the Details, but that means that even the MAAS Team might
have enough systems, but not the right special HW.
Therefore @Vern could you do the pre-checks with your associated
customer that you can verify the bug on their setup before we push it
as SRU?
As I said, you only need to have
FWIW, Cisco documentation here states that priority tagging is enabled
by default:
https://www.cisco.com/c/en/us/td/docs/switches/connectedgrid/cg-switch-
sw-master/software/configuration/guide/vlan0/b_vlan_0.html
"Default Settings
VLAN 0 priority tagging is enabled by default."
--
You
It seems an important component to the failure scenario is the hardware.
The customer equipment is a Cisco UCS chassis and the MAAS nodes are
blades in that chassis. Even though we cannot find anything in
configuration that specifically adds the vlan-0 tag (or priority tag),
traffic between the
TL;DR:
- I really really tried, but failed to recreate yout case on a single system
- I need your real setup as the VLAN-Tag-0 addition in your case seems to be
different
- That makes my request to one of you committing (and checking to be able to)
to verify this even more important - see
virt stack tests are successful on 1.0.0+git-20180124.fbe8c52d-0ubuntu2.2 and
1.0.0+git-20180124.fbe8c52d-0ubuntu4.1 from the PPA.
Including various others tests, but mostly related migrations and upgrades
between those versions.
Everything fine on that end ...
--
You received this bug
Thank Vern for outlining your testcase.
@Vern
Doesn't that also have to include some component that does QoS management
adding the VLAN-0 tag?
I don't have the systems to verify this case on Bionic and Cosmic.
As I read it from Vern he can only test Bionic at the Customer and is unsure he
can
The customer has bionic installed on 3 of the blades and I have
installed MAAS 2.4.3 on them using the Foundation Cloud Engine. I don't
have access to do the OS install myself. I could request a pair of
blades installed with cosmic but I'm unsure if I need all 3 or if I can
get by with just 2.
FYI: virt stack regression tests started but will still take a while.
To make it very very clear, this is incomplete until some path to test was
provided.
Marking the bug that way, waiting on that.
Worst case (and only then) describe the test setup that you have on the
customer site and
Prepped for Bionic and Cosmic in a PPA [1] for Bileto ticket [2]
Depending autopkgtests queued.
I'll run usual virtualization regression checks on that over night and
into tomorrow.
MPs are up for review at [3][4], but since Andeas change applies on all
these as-is there isn't much difference.
** Merge proposal linked:
https://code.launchpad.net/~paelzer/ubuntu/+source/ipxe/+git/ipxe/+merge/360678
** Merge proposal linked:
https://code.launchpad.net/~paelzer/ubuntu/+source/ipxe/+git/ipxe/+merge/360679
--
You received this bug notification because you are a member of Ubuntu
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
This bug was fixed in the package ipxe - 1.0.0+git-20180124.fbe8c52d-
0ubuntu5
---
ipxe (1.0.0+git-20180124.fbe8c52d-0ubuntu5) disco; urgency=medium
* d/p/0005-strip-802.1Q-VLAN-0-priority-tags.patch: Strip 802.1Q VLAN 0
priority tags; Fixes PXE when VLAN tag is 0. (LP:
[1] seems reasonable, I'll give it a try with and without the PPA of Andres.
It needs a slight modification, to not conflict with the default portal.
Install libvirt with all else it usually brings (for the bridge and dhcp on the
bridge):
$ sudo install libvirt-daemon-system
So use these
On Fri, Dec 7, 2018 at 8:21 PM Mike Pontillo
wrote:
...
> So iPXE's iSCSI functionality wouldn't be exercised in this case.
So MAAS itself is no good test for that, thanks Mike for the
clarification!
So the question is does anyone have a iscsi IPXE case for the last bit
of confidence for
Sorry for the confusion.
To be clear, the idea of using MAAS on Xenial was in order to test if
the newly-modified iPXE (on Bionic) can support iSCSI boot.
But come to think of it, I don't think that's a good test. If I remember
correctly, MAAS used TFTP to transfer the kernel and initrd, /then/
Just to clarify the above statements as it has been source of confusion.
MAAS 2.3+ (which is the latest available in Xenial), no longer uses nor
supports iSCSI. While the option to fallback to old behavior does exist,
it is not enabled by default, its obscured and, given that is not
supported, it
Yes, MAAS 2.3 (the last revision of MAAS supported on Xenial) can
support iSCSI when it is placed in backward compatibility mode; how to
do this is documented in the changelog as follows:
maas $PROFILE maas set-config name=http_boot value=False
MAAS 2.2 and earlier (no longer supported) used
> Unfortunately, a modern MAAS no longer uses iSCSI; it will fetch all
> necessary data over HTTP.
Yeah that matches what I heard, used in the past but no more.
But you certainly still have the best knowledge how to set it up from
the past when it did.
Checking that pre/post an upgrade to that
Unfortunately, a modern MAAS no longer uses iSCSI; it will fetch all
necessary data over HTTP.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1805920
Title:
iPXE ignores vlan 0 traffic
To manage
I'm glad that the ipxe in the PPA seems to make it work.
I now read the discussions and all questions that came up for me while
doing so were asked and clarified already in later comments.
Therefore I just reviewed the proposed change and it looks good to me
(other than the version string but
Success.
I installed ipxe-qemu from andreserl's ppa and was able to PXE boot a Pod VM
from the infra node that wasn't running dhcpd.
# add-apt-repository ppa:andreserl/maas
# apt update
# apt install ipxe-qemu
# virsh list --all
# virsh start elastic-3
I watched the console of the VM and it
FWIW, I patched ipxe with the CentOS patch as a test, which Vern was going to
test:
https://launchpadlibrarian.net/400355423/ipxe_1.0.0+git-20180124.fbe8c52d-0ubuntu2_1.0.0+git-20180124.fbe8c52d-0ubuntu2.2~18.04.1.diff.gz
--
You received this bug notification because you are a member of Ubuntu
Setting to 'Confirmed' in the kernel, although it's not clear what the
actual fix would entail. It would certainly be nice to be able to tell a
Linux virtual bridge to transparently strip off priority tags before L2
forwarding occurs. That would prevent the issue with iPXE.
** Changed in: linux
Seems other users in other distros experiencing the same, and a kernel
update fixes the issues? https://serverfault.com/questions/497391/
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs,
I think the issue is that removing the tag could be seen as a bug, not a
feature, since by removing it, you would be potentially stripping off a
priority tag that could be used further up the stack. (For example, if
the machine was deployed with a virtual bridge that was capable of
manipulating
I have not tried Centos6 VMs.
The customer reported that he deployed Centos7 to the baremetal blades
and saw, in ping traffic that incoming packets were vlan 0 tagged.
Then he deployed Centos6 to two baremetal blades and, in a ping test,
did not see any vlan tags.
If this is true, it suggests
@vhart, can you clarify that last comment? Do you mean that the CentOS 6
VMs exhibit the issue caused by the VLAN 0 tags and the CentOS 7 tags do
not? Or are you saying the tags are filtered elsewhere in the stack on
CentOS 6 (such as the NIC driver, 8021q driver, or virtual bridge)?
--
You
Sorry, I got that wrong. A deployment of a pair of Centos6 hosts to the
blades did not have vlan 0 tags. The Centos7 deployments did have vlan 0
tags.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
The Centos7 deployments were to other blades in the UCS chassis and
pings between the two Centos7 machines did not have vlan 0 tags.
I'll add your ppa and update to your ipxe and test pod VM booting.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Hi Vern,
Could you confirm something to us. WHen you say that the customer
deployed centos 7 and were able to see the issue there, did you mean
that they saw the issue in the packets themselves? In other words,
CentOS7 deployed successfully but the packets still had the VLAN tag?
The reason I
Interesting developments. I agree that it doesn't seem like `bridge-nf-
filter-vlan-tagged` is what we want, unless there is a special case not
filter packets tagged on VID 0. It might be worth trying this out on the
bridge used to boot the pod VMs.
The frustrating thing about this bug report is
Some interesting observations. The customer deployed a pair of Centos7
machines and confirmed the vlan0 tag issue existed there as well. That
wasn't too surprising.
However, they deployed a pair of Centos6 machines and they do NOT have
the vlan0 tag issue.
This seems to confirm that the issue is
Marking Invalid for MAAS since this is unrelated to MAAS itself.
** Changed in: maas
Status: Incomplete => Opinion
** Changed in: maas
Status: Opinion => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I did some digging, and it seems that:
1. Upstream has not accepted a patch from redhat to strip the priority tags [1]
2. RHEL (and consequently centos) are patching ipxe directly [2], [3].
Based on this, I think this patch could potentially be ported into ipxe
in Ubuntu, however, I think there
53 matches
Mail list logo
