Cloud-init now prefers dhcpcd over dhclient, which includes RFC 5227
support. Closing.
** Changed in: cloud-init (Ubuntu)
Status: Incomplete => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad
I'm marking this bug as incomplete for MAAS, since it's not clear what
actually needs to be fixed in MAAS. It seems like this needs to be fixed
at a lower level.
** Changed in: maas
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, wh
** Also affects: maas
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1677668
Title:
no GARPs during ephemeral boot
To manage notifications about this bug
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: isc-dhcp (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1677668
Title:
n
This causes problems for me as well during maas re-imaging wiht maas
2.9.2. see https://discourse.maas.io/t/changing-ips-and-lack-of-
gratuitous-arp-and-the-pain-it-causes/4800
Ideally when pxebooting, pxelinux.0 should send a gratuitous arp and in
theory it should solve the issue. Perhaps I'm
First of all thanks Jay for the great in depth extra-insight!
As Sam added, Cloud-Init can't do a lot here since it doesn't get a config to
this stage.
The only thing it could consider to do is unconditionally always trigger a GARP.
But that would be:
1. offending the cloud-init design which is
In our case, we don't need GARP on every boot. Only during MaaS Deploy
stage, where MaaS ephemeral boot image is trying to communicate with
MaaS region controller (in a different VLAN).
The irony is, even if there was a way to add our own GARP instructions
in cloud-init config, the region control
Sam / Christian,
This sort of issue is not unheard of in cases where an IP address moves
from interface to interface, or between hosts. Most situations that
expect this type of issue (e.g., bonding link failover) already issue
gratuitous ARPs in order to update L2 peers.
I think the bottom line
** Tags added: sts
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1677668
Title:
no GARPs during ephemeral boot
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+sourc
Hi Chris, Yes you are correct, and attached updated pic.
Although I don't disagree the PXE/DHCP client should be sending GARPs,
but shouldn't any OS that binds to an IP send a GARP as part of its TCP
stack initialization? That is, shouldn't the ephemeral boot image
itself send a GARP (independent
Hi Sam,
so in your picture we should add a RACK controller on Switch A and DHCP/TFTP
goes there right?
The DHCP on this RACK controller is it who hands out the 10.1.1.11
(again) right?
Of your description in comment #3 that now looks like:
# I added a RACK controller with 10.1.1.100 - please con
attached pic
** Attachment added: "ascii-art.png"
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1677668/+attachment/4851597/+files/ascii-art.png
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.ne
+---+
++ | ARP CACHE |
|| | (expires 4 hours) |
|| | 10.1.1.11 22:22 |
| ROUTER | | 10.1.2.100 33:33 |
|| | |
I forgot to mention, the TFTP conversation is happening between the
Region Controller (DHCP/TFTP) and the Machine which both live on the
same subnet, so the router's ARP Cache is not a factor.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ub
yikes! that did not format well...and I can't edit my own comment. Let
me try again...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1677668
Title:
no GARPs during ephemeral boot
To manage notific
I forgot to mention, Region and Rack Controllers are in separate VLANs.
So the TFTP conversation is happening between the RACK Controller
(DHCP/TFTP) and the Machine which both live on the same subnet, so the
router's ARP Cache is not a factor.
--
You received this bug notification because you ar
Hi Chris,
Some new clarifications are in order. Please disregard the "ARP
Inspection" claim. That feature wasn't even enabled.
Here's a very simplified drawing of the setup.
+---+
Hi Sam,
to get this right it correctly PXE boots and starts the ephemeral with
cloud-init to eventually produce the message.
So with the wrong arp in place, how did it get that far?
That is important to consider where the fix should be implemented.
PXE is essentially DHCP + tftp info, so it gets
Forgot to mention that we didn't want to "Static assign" IPs in MaaS.
We prefer using "Auto assign" but observed that MaaS will sometimes
reuse a previously used IP from a different MaaS machine. But using
"Static assign" we can reliably workaround the issue (or in this ticket
case, force a failur
19 matches
Mail list logo
