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 confirm if that matches and refresh your pic. 1) Assuming Machine #2 was last deployed and then released within the past 4 hours, using the IP 10.1.1.11. Thus the router already has an ARP entry in its cache matching 10.1.1.11 to MAC 22:22. 2) Machine #1 is starting Deployment and happens to receive 10.1.1.11 by DHCP from RACK Controller to use for ephemeral PXE IP. 3) TFTP communication is with RACK controller on 10.1.1.100 and works 3) Machine #1 sends packet to 10.1.2.100:5240 for websocket feedback 4) REGION Controller sees pack from 10.1.1.11 5) REGION Controller responds to 10.1.1.11 6) Machine #1 never sees the response packet Is that a proper summary now? Also I thought that most dhcp clients already send a GARP when receiving a IP via DHCP. In your setup the DHCP client in some way is PXE+Boot into cloud-init - I wonder if that is what we miss here. Never the less without knowing otherwise I'd expect the PXE bit to be responsible sending them in this scenario. If not that then the DHCP server who "knows" it just changed something. We might force-fix it with cloud-init but I at least want to understand why there is no GARP of the other more obvious sources. -- 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/+source/cloud-init/+bug/1677668/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
