richardlawley opened a new issue #3409: RvR Services should be provided on VIP instead of VR IP URL: https://github.com/apache/cloudstack/issues/3409 <!-- Verify first that your issue/request is not already reported on GitHub. Also test if the latest release and master branch are affected too. Always add information AFTER of these HTML comments, but no need to delete the comments. --> ##### ISSUE TYPE <!-- Pick one below and delete the rest --> * Bug Report ##### COMPONENT NAME <!-- Categorize the issue, e.g. API, VR, VPN, UI, etc. --> ~~~ Redundant VRs ~~~ ##### CLOUDSTACK VERSION <!-- New line separated list of affected versions, commit ID for issues on master branch. --> ~~~ 4.11.2 ~~~ ##### CONFIGURATION <!-- Information about the configuration if relevant, e.g. basic network, advanced networking, etc. N/A otherwise --> Advanced Networking, possibly also VPCs ##### OS / ENVIRONMENT <!-- Information about the environment if relevant, N/A otherwise --> N/A ##### SUMMARY <!-- Explain the problem/feature briefly --> Redundant VRs provide their services on their own internal IP rather than the Virtual IP. This leads to a number of problems, mostly triggered around VRs failing over after a VM has booted: * DHCP server is run on VR IP, which means VM cannot renew its IP. Once the renew + expire times run out, the VM attempts to discover a new DHCP server (this causes additional problems with secondary IPs being removed). * Userdata services only listen on VR IP, so accessing this data requires checking the DHCP lease info to find the VR's IP. If the VR has failed over, userdata cannot be accessed. * Hairpin static NAT connections appear to come from the VR's IP, and since that can change it may confuse end clients ##### STEPS TO REPRODUCE <!-- For bugs, show exactly how to reproduce the problem, using a minimal test-case. Use Screenshots if accurate. For new features, show how the feature would be used. --> Build a redundant advanced network with guest range 10.1.1.0/24, deploy a Linux VM. * Observe DHCP server * Check userdata (curl http://VRIP/latest/instance-id) * Add a static NAT rule ##### EXPECTED RESULTS <!-- What did you expect to happen when running the steps above? --> * DHCP server should be 10.1.1.1 * Userdata should be accessible on http://10.1.1.1 * POSTROUTING rules on nat table should use 10.1.1.1 as the source ##### ACTUAL RESULTS <!-- What actually happened? --> * DHCP server is the unique VR IP from the internal range * Userdata is only accessible at VR's IP, not 10.1.1.1 * POSTROUTING rules on nat table (hairpin nat) use the VR IP <!-- Paste verbatim command output between quotes below --> ~~~ ~~~
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
