Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA
I was reminded that scapy is under GPLv2 license so we cannot make it as the dependency of Neutron. There are also some IPv6 utilities from ryu.lib.packet which can be leveraged to send out neighbor advertisement. Is it OK to make ryu as a dependency and make this as a binary and call it from namespace? Thanks, Xu Han On 09/26/2014 10:08 AM, Vishvananda Ishaya wrote: You are going to have to make this as a separate binary and call it via rootwrap ip netns exec. While it is possible to change network namespaces in python, you aren't going to be able to do this consistently without root access, so it will need to be guarded by rootwrap anyway. Vish On Sep 25, 2014, at 7:00 PM, Xu Han Peng pengxu...@gmail.com mailto:pengxu...@gmail.com wrote: Sending unsolicited NA by scapy is like this: from scapy.all import send, IPv6, ICMPv6ND_NA, ICMPv6NDOptDstLLAddr target_ll_addr = ICMPv6NDOptDstLLAddr(lladdr = mac_address) unsolicited_na=ICMPv6ND_NA(R=1, S=0, O=1, tgt=target) packet=IPv6(src=source)/unsolicited_na/target_ll_addr *send(packet, iface=interface_name, count=10, inter=0.2)* It's not actually a python script but a python method. Any ideas? On 09/25/2014 06:20 PM, Kevin Benton wrote: Does running the python script with ip netns exec not work correctly? On Thu, Sep 25, 2014 at 2:05 AM, Xu Han Pengpengxu...@gmail.com wrote: Hi, As we talked in last IPv6 sub-team meeting, I was able to construct and send IPv6 unsolicited neighbor advertisement for external gateway interface by python tool scapy: http://www.secdev.org/projects/scapy/ http://www.idsv6.de/Downloads/IPv6PacketCreationWithScapy.pdf However, I am having trouble to send this unsolicited neighbor advertisement in a given namespace. All the current namespace operations leverage ip netns exec and shell command. But we cannot do this to scapy since it's python code. Can anyone advise me on this? Thanks, Xu Han On 09/05/2014 05:46 PM, Xu Han Peng wrote: Carl, Seem so. I think internal router interface and external gateway port GARP are taken care by keepalived during failover. And if HA is not enable, _send_gratuitous_arp is called to send out GARP. I think we will need to take care IPv6 for both cases since keepalived 1.2.0 support IPv6. May need a separate BP. For the case HA is enabled externally, we still need unsolicited neighbor advertisement for gateway failover. But for internal router interface, since Router Advertisement is automatically send out by RADVD after failover, we don't need to send out neighbor advertisement anymore. Xu Han On 09/05/2014 03:04 AM, Carl Baldwin wrote: Hi Xu Han, Since I sent my message yesterday there has been some more discussion in the review on that patch set. See [1] again. I think your assessment is likely correct. Carl [1]https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py On Thu, Sep 4, 2014 at 3:32 AM, Xu Han Pengpengxu...@gmail.com wrote: Carl, Thanks a lot for your reply! If I understand correctly, in VRRP case, keepalived will be responsible for sending out GARPs? By checking the code you provided, I can see all the _send_gratuitous_arp_packet call are wrapped by if not is_ha condition. Xu Han On 09/04/2014 06:06 AM, Carl Baldwin wrote: It should be noted that send_arp_for_ha is a configuration option that preceded the more recent in-progress work to add VRRP controlled HA to Neutron's router. The option was added, I believe, to cause the router to send (default) 3 GARPs to the external gateway if the router was removed from one network node and added to another by some external script or manual intervention. It did not send anything on the internal network ports. VRRP is a different story and the code in review [1] sends GARPs on internal and external ports. Hope this helps avoid confusion in this discussion. Carl [1]https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py On Mon, Sep 1, 2014 at 8:52 PM, Xu Han Pengpengxu...@gmail.com wrote: Anthony, Thanks for your reply. If HA method like VRRP are used for IPv6 router, according to the VRRP RFC with IPv6 included, the servers should be auto-configured with the active router's LLA as the default route before the failover happens and still remain that route after the failover. In other word, there should be no need to use two LLAs for default route of a subnet unless load balance is required. When the backup router become the master router, the backup router should be responsible for sending out an unsolicited ND neighbor advertisement with the associated LLA (the previous master's LLA) immediately to update the bridge learning state and sending out router advertisement with the same options with the previous master to maintain the route and bridge learning. This is shown inhttp://tools.ietf.org/html/rfc5798#section-4.1 and the actions backup router should take after failover is documented here:
Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA
Hi, As we talked in last IPv6 sub-team meeting, I was able to construct and send IPv6 unsolicited neighbor advertisement for external gateway interface by python tool *scapy*: http://www.secdev.org/projects/scapy/ http://www.idsv6.de/Downloads/IPv6PacketCreationWithScapy.pdf However, I am having trouble to send this unsolicited neighbor advertisement in a given namespace. All the current namespace operations leverage ip netns exec and shell command. But we cannot do this to scapy since it's python code. Can anyone advise me on this? Thanks, Xu Han On 09/05/2014 05:46 PM, Xu Han Peng wrote: Carl, Seem so. I think internal router interface and external gateway port GARP are taken care by keepalived during failover. And if HA is not enable, _send_gratuitous_arp is called to send out GARP. I think we will need to take care IPv6 for both cases since keepalived 1.2.0 support IPv6. May need a separate BP. For the case HA is enabled externally, we still need unsolicited neighbor advertisement for gateway failover. But for internal router interface, since Router Advertisement is automatically send out by RADVD after failover, we don't need to send out neighbor advertisement anymore. Xu Han On 09/05/2014 03:04 AM, Carl Baldwin wrote: Hi Xu Han, Since I sent my message yesterday there has been some more discussion in the review on that patch set. See [1] again. I think your assessment is likely correct. Carl [1] https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py On Thu, Sep 4, 2014 at 3:32 AM, Xu Han Peng pengxu...@gmail.com wrote: Carl, Thanks a lot for your reply! If I understand correctly, in VRRP case, keepalived will be responsible for sending out GARPs? By checking the code you provided, I can see all the _send_gratuitous_arp_packet call are wrapped by if not is_ha condition. Xu Han On 09/04/2014 06:06 AM, Carl Baldwin wrote: It should be noted that send_arp_for_ha is a configuration option that preceded the more recent in-progress work to add VRRP controlled HA to Neutron's router. The option was added, I believe, to cause the router to send (default) 3 GARPs to the external gateway if the router was removed from one network node and added to another by some external script or manual intervention. It did not send anything on the internal network ports. VRRP is a different story and the code in review [1] sends GARPs on internal and external ports. Hope this helps avoid confusion in this discussion. Carl [1] https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py On Mon, Sep 1, 2014 at 8:52 PM, Xu Han Peng pengxu...@gmail.com wrote: Anthony, Thanks for your reply. If HA method like VRRP are used for IPv6 router, according to the VRRP RFC with IPv6 included, the servers should be auto-configured with the active router's LLA as the default route before the failover happens and still remain that route after the failover. In other word, there should be no need to use two LLAs for default route of a subnet unless load balance is required. When the backup router become the master router, the backup router should be responsible for sending out an unsolicited ND neighbor advertisement with the associated LLA (the previous master's LLA) immediately to update the bridge learning state and sending out router advertisement with the same options with the previous master to maintain the route and bridge learning. This is shown in http://tools.ietf.org/html/rfc5798#section-4.1 and the actions backup router should take after failover is documented here: http://tools.ietf.org/html/rfc5798#section-6.4.2. The need for immediate messaging sending and periodic message sending is documented here: http://tools.ietf.org/html/rfc5798#section-2.4 Since the keepalived manager support for L3 HA is merged: https://review.openstack.org/#/c/68142/43. And keepalived release 1.2.0 supports VRRP IPv6 features ( http://www.keepalived.org/changelog.html, see Release 1.2.0 | VRRP IPv6 Release). I think we can check if keepalived can satisfy our requirement here and if that will cause any conflicts with RADVD. Thoughts? Xu Han On 08/28/2014 10:11 PM, Veiga, Anthony wrote: Anthony and Robert, Thanks for your reply. I don't know if the arping is there for NAT, but I am pretty sure it's for HA setup to broadcast the router's own change since the arping is controlled by send_arp_for_ha config. By checking the man page of arping, you can find the arping -A we use in code is sending out ARP REPLY instead of ARP REQUEST. This is like saying I am here instead of where are you. I didn't realized this either until Brain pointed this out at my code review below. That’s what I was trying to say earlier. Sending out the RA is the same effect. RA says “I’m here, oh and I’m also a router” and should supersede the need for an unsolicited NA. The only thing to consider here is that RAs are from LLAs. If you’re doing IPv6
Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA
Does running the python script with ip netns exec not work correctly? On Thu, Sep 25, 2014 at 2:05 AM, Xu Han Peng pengxu...@gmail.com wrote: Hi, As we talked in last IPv6 sub-team meeting, I was able to construct and send IPv6 unsolicited neighbor advertisement for external gateway interface by python tool scapy: http://www.secdev.org/projects/scapy/ http://www.idsv6.de/Downloads/IPv6PacketCreationWithScapy.pdf However, I am having trouble to send this unsolicited neighbor advertisement in a given namespace. All the current namespace operations leverage ip netns exec and shell command. But we cannot do this to scapy since it's python code. Can anyone advise me on this? Thanks, Xu Han On 09/05/2014 05:46 PM, Xu Han Peng wrote: Carl, Seem so. I think internal router interface and external gateway port GARP are taken care by keepalived during failover. And if HA is not enable, _send_gratuitous_arp is called to send out GARP. I think we will need to take care IPv6 for both cases since keepalived 1.2.0 support IPv6. May need a separate BP. For the case HA is enabled externally, we still need unsolicited neighbor advertisement for gateway failover. But for internal router interface, since Router Advertisement is automatically send out by RADVD after failover, we don't need to send out neighbor advertisement anymore. Xu Han On 09/05/2014 03:04 AM, Carl Baldwin wrote: Hi Xu Han, Since I sent my message yesterday there has been some more discussion in the review on that patch set. See [1] again. I think your assessment is likely correct. Carl [1] https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py On Thu, Sep 4, 2014 at 3:32 AM, Xu Han Peng pengxu...@gmail.com wrote: Carl, Thanks a lot for your reply! If I understand correctly, in VRRP case, keepalived will be responsible for sending out GARPs? By checking the code you provided, I can see all the _send_gratuitous_arp_packet call are wrapped by if not is_ha condition. Xu Han On 09/04/2014 06:06 AM, Carl Baldwin wrote: It should be noted that send_arp_for_ha is a configuration option that preceded the more recent in-progress work to add VRRP controlled HA to Neutron's router. The option was added, I believe, to cause the router to send (default) 3 GARPs to the external gateway if the router was removed from one network node and added to another by some external script or manual intervention. It did not send anything on the internal network ports. VRRP is a different story and the code in review [1] sends GARPs on internal and external ports. Hope this helps avoid confusion in this discussion. Carl [1] https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py On Mon, Sep 1, 2014 at 8:52 PM, Xu Han Peng pengxu...@gmail.com wrote: Anthony, Thanks for your reply. If HA method like VRRP are used for IPv6 router, according to the VRRP RFC with IPv6 included, the servers should be auto-configured with the active router's LLA as the default route before the failover happens and still remain that route after the failover. In other word, there should be no need to use two LLAs for default route of a subnet unless load balance is required. When the backup router become the master router, the backup router should be responsible for sending out an unsolicited ND neighbor advertisement with the associated LLA (the previous master's LLA) immediately to update the bridge learning state and sending out router advertisement with the same options with the previous master to maintain the route and bridge learning. This is shown in http://tools.ietf.org/html/rfc5798#section-4.1 and the actions backup router should take after failover is documented here: http://tools.ietf.org/html/rfc5798#section-6.4.2. The need for immediate messaging sending and periodic message sending is documented here: http://tools.ietf.org/html/rfc5798#section-2.4 Since the keepalived manager support for L3 HA is merged: https://review.openstack.org/#/c/68142/43. And keepalived release 1.2.0 supports VRRP IPv6 features ( http://www.keepalived.org/changelog.html, see Release 1.2.0 | VRRP IPv6 Release). I think we can check if keepalived can satisfy our requirement here and if that will cause any conflicts with RADVD. Thoughts? Xu Han On 08/28/2014 10:11 PM, Veiga, Anthony wrote: Anthony and Robert, Thanks for your reply. I don't know if the arping is there for NAT, but I am pretty sure it's for HA setup to broadcast the router's own change since the arping is controlled by send_arp_for_ha config. By checking the man page of arping, you can find the arping -A we use in code is sending out ARP REPLY instead of ARP REQUEST. This is like saying I am here instead of where are you. I didn't realized this either until Brain pointed this out at my code review below. That’s what I was trying to say earlier. Sending out the RA is the same effect. RA
Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA
Sending unsolicited NA by scapy is like this: from scapy.all import send, IPv6, ICMPv6ND_NA, ICMPv6NDOptDstLLAddr target_ll_addr = ICMPv6NDOptDstLLAddr(lladdr = mac_address) unsolicited_na=ICMPv6ND_NA(R=1, S=0, O=1, tgt=target) packet=IPv6(src=source)/unsolicited_na/target_ll_addr *send(packet, iface=interface_name, count=10, inter=0.2)* It's not actually a python script but a python method. Any ideas? On 09/25/2014 06:20 PM, Kevin Benton wrote: Does running the python script with ip netns exec not work correctly? On Thu, Sep 25, 2014 at 2:05 AM, Xu Han Peng pengxu...@gmail.com wrote: Hi, As we talked in last IPv6 sub-team meeting, I was able to construct and send IPv6 unsolicited neighbor advertisement for external gateway interface by python tool scapy: http://www.secdev.org/projects/scapy/ http://www.idsv6.de/Downloads/IPv6PacketCreationWithScapy.pdf However, I am having trouble to send this unsolicited neighbor advertisement in a given namespace. All the current namespace operations leverage ip netns exec and shell command. But we cannot do this to scapy since it's python code. Can anyone advise me on this? Thanks, Xu Han On 09/05/2014 05:46 PM, Xu Han Peng wrote: Carl, Seem so. I think internal router interface and external gateway port GARP are taken care by keepalived during failover. And if HA is not enable, _send_gratuitous_arp is called to send out GARP. I think we will need to take care IPv6 for both cases since keepalived 1.2.0 support IPv6. May need a separate BP. For the case HA is enabled externally, we still need unsolicited neighbor advertisement for gateway failover. But for internal router interface, since Router Advertisement is automatically send out by RADVD after failover, we don't need to send out neighbor advertisement anymore. Xu Han On 09/05/2014 03:04 AM, Carl Baldwin wrote: Hi Xu Han, Since I sent my message yesterday there has been some more discussion in the review on that patch set. See [1] again. I think your assessment is likely correct. Carl [1] https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py On Thu, Sep 4, 2014 at 3:32 AM, Xu Han Peng pengxu...@gmail.com wrote: Carl, Thanks a lot for your reply! If I understand correctly, in VRRP case, keepalived will be responsible for sending out GARPs? By checking the code you provided, I can see all the _send_gratuitous_arp_packet call are wrapped by if not is_ha condition. Xu Han On 09/04/2014 06:06 AM, Carl Baldwin wrote: It should be noted that send_arp_for_ha is a configuration option that preceded the more recent in-progress work to add VRRP controlled HA to Neutron's router. The option was added, I believe, to cause the router to send (default) 3 GARPs to the external gateway if the router was removed from one network node and added to another by some external script or manual intervention. It did not send anything on the internal network ports. VRRP is a different story and the code in review [1] sends GARPs on internal and external ports. Hope this helps avoid confusion in this discussion. Carl [1] https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py On Mon, Sep 1, 2014 at 8:52 PM, Xu Han Peng pengxu...@gmail.com wrote: Anthony, Thanks for your reply. If HA method like VRRP are used for IPv6 router, according to the VRRP RFC with IPv6 included, the servers should be auto-configured with the active router's LLA as the default route before the failover happens and still remain that route after the failover. In other word, there should be no need to use two LLAs for default route of a subnet unless load balance is required. When the backup router become the master router, the backup router should be responsible for sending out an unsolicited ND neighbor advertisement with the associated LLA (the previous master's LLA) immediately to update the bridge learning state and sending out router advertisement with the same options with the previous master to maintain the route and bridge learning. This is shown in http://tools.ietf.org/html/rfc5798#section-4.1 and the actions backup router should take after failover is documented here: http://tools.ietf.org/html/rfc5798#section-6.4.2. The need for immediate messaging sending and periodic message sending is documented here: http://tools.ietf.org/html/rfc5798#section-2.4 Since the keepalived manager support for L3 HA is merged: https://review.openstack.org/#/c/68142/43. And keepalived release 1.2.0 supports VRRP IPv6 features ( http://www.keepalived.org/changelog.html, see Release 1.2.0 | VRRP IPv6 Release). I think we can check if keepalived can satisfy our requirement here and if that will cause any conflicts with RADVD. Thoughts? Xu Han On 08/28/2014 10:11 PM, Veiga, Anthony wrote: Anthony and Robert, Thanks for your reply. I don't know if the arping is there for NAT, but I am pretty sure it's for HA setup to broadcast the router's own change since the arping is
Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA
You are going to have to make this as a separate binary and call it via rootwrap ip netns exec. While it is possible to change network namespaces in python, you aren’t going to be able to do this consistently without root access, so it will need to be guarded by rootwrap anyway. Vish On Sep 25, 2014, at 7:00 PM, Xu Han Peng pengxu...@gmail.com wrote: Sending unsolicited NA by scapy is like this: from scapy.all import send, IPv6, ICMPv6ND_NA, ICMPv6NDOptDstLLAddr target_ll_addr = ICMPv6NDOptDstLLAddr(lladdr = mac_address) unsolicited_na=ICMPv6ND_NA(R=1, S=0, O=1, tgt=target) packet=IPv6(src=source)/unsolicited_na/target_ll_addr send(packet, iface=interface_name, count=10, inter=0.2) It's not actually a python script but a python method. Any ideas? On 09/25/2014 06:20 PM, Kevin Benton wrote: Does running the python script with ip netns exec not work correctly? On Thu, Sep 25, 2014 at 2:05 AM, Xu Han Peng pengxu...@gmail.com wrote: Hi, As we talked in last IPv6 sub-team meeting, I was able to construct and send IPv6 unsolicited neighbor advertisement for external gateway interface by python tool scapy: http://www.secdev.org/projects/scapy/ http://www.idsv6.de/Downloads/IPv6PacketCreationWithScapy.pdf However, I am having trouble to send this unsolicited neighbor advertisement in a given namespace. All the current namespace operations leverage ip netns exec and shell command. But we cannot do this to scapy since it's python code. Can anyone advise me on this? Thanks, Xu Han On 09/05/2014 05:46 PM, Xu Han Peng wrote: Carl, Seem so. I think internal router interface and external gateway port GARP are taken care by keepalived during failover. And if HA is not enable, _send_gratuitous_arp is called to send out GARP. I think we will need to take care IPv6 for both cases since keepalived 1.2.0 support IPv6. May need a separate BP. For the case HA is enabled externally, we still need unsolicited neighbor advertisement for gateway failover. But for internal router interface, since Router Advertisement is automatically send out by RADVD after failover, we don't need to send out neighbor advertisement anymore. Xu Han On 09/05/2014 03:04 AM, Carl Baldwin wrote: Hi Xu Han, Since I sent my message yesterday there has been some more discussion in the review on that patch set. See [1] again. I think your assessment is likely correct. Carl [1] https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py On Thu, Sep 4, 2014 at 3:32 AM, Xu Han Peng pengxu...@gmail.com wrote: Carl, Thanks a lot for your reply! If I understand correctly, in VRRP case, keepalived will be responsible for sending out GARPs? By checking the code you provided, I can see all the _send_gratuitous_arp_packet call are wrapped by if not is_ha condition. Xu Han On 09/04/2014 06:06 AM, Carl Baldwin wrote: It should be noted that send_arp_for_ha is a configuration option that preceded the more recent in-progress work to add VRRP controlled HA to Neutron's router. The option was added, I believe, to cause the router to send (default) 3 GARPs to the external gateway if the router was removed from one network node and added to another by some external script or manual intervention. It did not send anything on the internal network ports. VRRP is a different story and the code in review [1] sends GARPs on internal and external ports. Hope this helps avoid confusion in this discussion. Carl [1] https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py On Mon, Sep 1, 2014 at 8:52 PM, Xu Han Peng pengxu...@gmail.com wrote: Anthony, Thanks for your reply. If HA method like VRRP are used for IPv6 router, according to the VRRP RFC with IPv6 included, the servers should be auto-configured with the active router's LLA as the default route before the failover happens and still remain that route after the failover. In other word, there should be no need to use two LLAs for default route of a subnet unless load balance is required. When the backup router become the master router, the backup router should be responsible for sending out an unsolicited ND neighbor advertisement with the associated LLA (the previous master's LLA) immediately to update the bridge learning state and sending out router advertisement with the same options with the previous master to maintain the route and bridge learning. This is shown in http://tools.ietf.org/html/rfc5798#section-4.1 and the actions backup router should take after failover is documented here: http://tools.ietf.org/html/rfc5798#section-6.4.2. The need for immediate messaging sending and periodic message sending is documented here: http://tools.ietf.org/html/rfc5798#section-2.4 Since the keepalived manager support for L3 HA is merged: https://review.openstack.org/#/c/68142/43. And keepalived release 1.2.0
Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA
Carl, Seem so. I think internal router interface and external gateway port GARP are taken care by keepalived during failover. And if HA is not enable, _send_gratuitous_arp is called to send out GARP. I think we will need to take care IPv6 for both cases since keepalived 1.2.0 support IPv6. May need a separate BP. For the case HA is enabled externally, we still need unsolicited neighbor advertisement for gateway failover. But for internal router interface, since Router Advertisement is automatically send out by RADVD after failover, we don't need to send out neighbor advertisement anymore. Xu Han On 09/05/2014 03:04 AM, Carl Baldwin wrote: Hi Xu Han, Since I sent my message yesterday there has been some more discussion in the review on that patch set. See [1] again. I think your assessment is likely correct. Carl [1] https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py On Thu, Sep 4, 2014 at 3:32 AM, Xu Han Peng pengxu...@gmail.com wrote: Carl, Thanks a lot for your reply! If I understand correctly, in VRRP case, keepalived will be responsible for sending out GARPs? By checking the code you provided, I can see all the _send_gratuitous_arp_packet call are wrapped by if not is_ha condition. Xu Han On 09/04/2014 06:06 AM, Carl Baldwin wrote: It should be noted that send_arp_for_ha is a configuration option that preceded the more recent in-progress work to add VRRP controlled HA to Neutron's router. The option was added, I believe, to cause the router to send (default) 3 GARPs to the external gateway if the router was removed from one network node and added to another by some external script or manual intervention. It did not send anything on the internal network ports. VRRP is a different story and the code in review [1] sends GARPs on internal and external ports. Hope this helps avoid confusion in this discussion. Carl [1] https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py On Mon, Sep 1, 2014 at 8:52 PM, Xu Han Peng pengxu...@gmail.com wrote: Anthony, Thanks for your reply. If HA method like VRRP are used for IPv6 router, according to the VRRP RFC with IPv6 included, the servers should be auto-configured with the active router's LLA as the default route before the failover happens and still remain that route after the failover. In other word, there should be no need to use two LLAs for default route of a subnet unless load balance is required. When the backup router become the master router, the backup router should be responsible for sending out an unsolicited ND neighbor advertisement with the associated LLA (the previous master's LLA) immediately to update the bridge learning state and sending out router advertisement with the same options with the previous master to maintain the route and bridge learning. This is shown in http://tools.ietf.org/html/rfc5798#section-4.1 and the actions backup router should take after failover is documented here: http://tools.ietf.org/html/rfc5798#section-6.4.2. The need for immediate messaging sending and periodic message sending is documented here: http://tools.ietf.org/html/rfc5798#section-2.4 Since the keepalived manager support for L3 HA is merged: https://review.openstack.org/#/c/68142/43. And keepalived release 1.2.0 supports VRRP IPv6 features ( http://www.keepalived.org/changelog.html, see Release 1.2.0 | VRRP IPv6 Release). I think we can check if keepalived can satisfy our requirement here and if that will cause any conflicts with RADVD. Thoughts? Xu Han On 08/28/2014 10:11 PM, Veiga, Anthony wrote: Anthony and Robert, Thanks for your reply. I don't know if the arping is there for NAT, but I am pretty sure it's for HA setup to broadcast the router's own change since the arping is controlled by send_arp_for_ha config. By checking the man page of arping, you can find the arping -A we use in code is sending out ARP REPLY instead of ARP REQUEST. This is like saying I am here instead of where are you. I didn't realized this either until Brain pointed this out at my code review below. That’s what I was trying to say earlier. Sending out the RA is the same effect. RA says “I’m here, oh and I’m also a router” and should supersede the need for an unsolicited NA. The only thing to consider here is that RAs are from LLAs. If you’re doing IPv6 HA, you’ll need to have two gateway IPs for the RA of the standby to work. So far as I know, I think there’s still a bug out on this since you can only have one gateway per subnet. http://linux.die.net/man/8/arping https://review.openstack.org/#/c/114437/2/neutron/agent/l3_agent.py Thoughts? Xu Han On 08/27/2014 10:01 PM, Veiga, Anthony wrote: Hi Xuhan, What I saw is that GARP is sent to the gateway port and also to the router ports, from a neutron router. I’m not sure why it’s sent to the router ports (internal network). My understanding for arping to the gateway port is that it is needed for proper NAT operation. Since we are
Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA
Carl, Thanks a lot for your reply! If I understand correctly, in VRRP case, keepalived will be responsible for sending out GARPs? By checking the code you provided, I can see all the _send_gratuitous_arp_packet call are wrapped by if not is_ha condition. Xu Han On 09/04/2014 06:06 AM, Carl Baldwin wrote: It should be noted that send_arp_for_ha is a configuration option that preceded the more recent in-progress work to add VRRP controlled HA to Neutron's router. The option was added, I believe, to cause the router to send (default) 3 GARPs to the external gateway if the router was removed from one network node and added to another by some external script or manual intervention. It did not send anything on the internal network ports. VRRP is a different story and the code in review [1] sends GARPs on internal and external ports. Hope this helps avoid confusion in this discussion. Carl [1] https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py On Mon, Sep 1, 2014 at 8:52 PM, Xu Han Peng pengxu...@gmail.com wrote: Anthony, Thanks for your reply. If HA method like VRRP are used for IPv6 router, according to the VRRP RFC with IPv6 included, the servers should be auto-configured with the active router's LLA as the default route before the failover happens and still remain that route after the failover. In other word, there should be no need to use two LLAs for default route of a subnet unless load balance is required. When the backup router become the master router, the backup router should be responsible for sending out an unsolicited ND neighbor advertisement with the associated LLA (the previous master's LLA) immediately to update the bridge learning state and sending out router advertisement with the same options with the previous master to maintain the route and bridge learning. This is shown in http://tools.ietf.org/html/rfc5798#section-4.1 and the actions backup router should take after failover is documented here: http://tools.ietf.org/html/rfc5798#section-6.4.2. The need for immediate messaging sending and periodic message sending is documented here: http://tools.ietf.org/html/rfc5798#section-2.4 Since the keepalived manager support for L3 HA is merged: https://review.openstack.org/#/c/68142/43. And keepalived release 1.2.0 supports VRRP IPv6 features ( http://www.keepalived.org/changelog.html, see Release 1.2.0 | VRRP IPv6 Release). I think we can check if keepalived can satisfy our requirement here and if that will cause any conflicts with RADVD. Thoughts? Xu Han On 08/28/2014 10:11 PM, Veiga, Anthony wrote: Anthony and Robert, Thanks for your reply. I don't know if the arping is there for NAT, but I am pretty sure it's for HA setup to broadcast the router's own change since the arping is controlled by send_arp_for_ha config. By checking the man page of arping, you can find the arping -A we use in code is sending out ARP REPLY instead of ARP REQUEST. This is like saying I am here instead of where are you. I didn't realized this either until Brain pointed this out at my code review below. That’s what I was trying to say earlier. Sending out the RA is the same effect. RA says “I’m here, oh and I’m also a router” and should supersede the need for an unsolicited NA. The only thing to consider here is that RAs are from LLAs. If you’re doing IPv6 HA, you’ll need to have two gateway IPs for the RA of the standby to work. So far as I know, I think there’s still a bug out on this since you can only have one gateway per subnet. http://linux.die.net/man/8/arping https://review.openstack.org/#/c/114437/2/neutron/agent/l3_agent.py Thoughts? Xu Han On 08/27/2014 10:01 PM, Veiga, Anthony wrote: Hi Xuhan, What I saw is that GARP is sent to the gateway port and also to the router ports, from a neutron router. I’m not sure why it’s sent to the router ports (internal network). My understanding for arping to the gateway port is that it is needed for proper NAT operation. Since we are not planning to support ipv6 NAT, so this is not required/needed for ipv6 any more? I agree that this is no longer necessary. There is an abandoned patch that disabled the arping for ipv6 gateway port: https://review.openstack.org/#/c/77471/3/neutron/agent/l3_agent.py thanks, Robert On 8/27/14, 1:03 AM, Xuhan Peng pengxu...@gmail.com wrote: As a follow-up action of yesterday's IPv6 sub-team meeting, I would like to start a discussion about how to support l3 agent HA when IP version is IPv6. This problem is triggered by bug [1] where sending gratuitous arp packet for HA doesn't work for IPv6 subnet gateways. This is because neighbor discovery instead of ARP should be used for IPv6. My thought to solve this problem turns into how to send out neighbor advertisement for IPv6 routers just like sending ARP reply for IPv4 routers after reading the comments on code review [2]. I searched for utilities which can do this and only find a utility called ndsend [3] as part of
Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA
Hi Xu Han, Since I sent my message yesterday there has been some more discussion in the review on that patch set. See [1] again. I think your assessment is likely correct. Carl [1] https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py On Thu, Sep 4, 2014 at 3:32 AM, Xu Han Peng pengxu...@gmail.com wrote: Carl, Thanks a lot for your reply! If I understand correctly, in VRRP case, keepalived will be responsible for sending out GARPs? By checking the code you provided, I can see all the _send_gratuitous_arp_packet call are wrapped by if not is_ha condition. Xu Han On 09/04/2014 06:06 AM, Carl Baldwin wrote: It should be noted that send_arp_for_ha is a configuration option that preceded the more recent in-progress work to add VRRP controlled HA to Neutron's router. The option was added, I believe, to cause the router to send (default) 3 GARPs to the external gateway if the router was removed from one network node and added to another by some external script or manual intervention. It did not send anything on the internal network ports. VRRP is a different story and the code in review [1] sends GARPs on internal and external ports. Hope this helps avoid confusion in this discussion. Carl [1] https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py On Mon, Sep 1, 2014 at 8:52 PM, Xu Han Peng pengxu...@gmail.com wrote: Anthony, Thanks for your reply. If HA method like VRRP are used for IPv6 router, according to the VRRP RFC with IPv6 included, the servers should be auto-configured with the active router's LLA as the default route before the failover happens and still remain that route after the failover. In other word, there should be no need to use two LLAs for default route of a subnet unless load balance is required. When the backup router become the master router, the backup router should be responsible for sending out an unsolicited ND neighbor advertisement with the associated LLA (the previous master's LLA) immediately to update the bridge learning state and sending out router advertisement with the same options with the previous master to maintain the route and bridge learning. This is shown in http://tools.ietf.org/html/rfc5798#section-4.1 and the actions backup router should take after failover is documented here: http://tools.ietf.org/html/rfc5798#section-6.4.2. The need for immediate messaging sending and periodic message sending is documented here: http://tools.ietf.org/html/rfc5798#section-2.4 Since the keepalived manager support for L3 HA is merged: https://review.openstack.org/#/c/68142/43. And keepalived release 1.2.0 supports VRRP IPv6 features ( http://www.keepalived.org/changelog.html, see Release 1.2.0 | VRRP IPv6 Release). I think we can check if keepalived can satisfy our requirement here and if that will cause any conflicts with RADVD. Thoughts? Xu Han On 08/28/2014 10:11 PM, Veiga, Anthony wrote: Anthony and Robert, Thanks for your reply. I don't know if the arping is there for NAT, but I am pretty sure it's for HA setup to broadcast the router's own change since the arping is controlled by send_arp_for_ha config. By checking the man page of arping, you can find the arping -A we use in code is sending out ARP REPLY instead of ARP REQUEST. This is like saying I am here instead of where are you. I didn't realized this either until Brain pointed this out at my code review below. That’s what I was trying to say earlier. Sending out the RA is the same effect. RA says “I’m here, oh and I’m also a router” and should supersede the need for an unsolicited NA. The only thing to consider here is that RAs are from LLAs. If you’re doing IPv6 HA, you’ll need to have two gateway IPs for the RA of the standby to work. So far as I know, I think there’s still a bug out on this since you can only have one gateway per subnet. http://linux.die.net/man/8/arping https://review.openstack.org/#/c/114437/2/neutron/agent/l3_agent.py Thoughts? Xu Han On 08/27/2014 10:01 PM, Veiga, Anthony wrote: Hi Xuhan, What I saw is that GARP is sent to the gateway port and also to the router ports, from a neutron router. I’m not sure why it’s sent to the router ports (internal network). My understanding for arping to the gateway port is that it is needed for proper NAT operation. Since we are not planning to support ipv6 NAT, so this is not required/needed for ipv6 any more? I agree that this is no longer necessary. There is an abandoned patch that disabled the arping for ipv6 gateway port: https://review.openstack.org/#/c/77471/3/neutron/agent/l3_agent.py thanks, Robert On 8/27/14, 1:03 AM, Xuhan Peng pengxu...@gmail.com wrote: As a follow-up action of yesterday's IPv6 sub-team meeting, I would like to start a discussion about how to support l3 agent HA when IP version is IPv6. This problem is triggered by bug [1] where sending gratuitous arp packet for HA
Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA
It should be noted that send_arp_for_ha is a configuration option that preceded the more recent in-progress work to add VRRP controlled HA to Neutron's router. The option was added, I believe, to cause the router to send (default) 3 GARPs to the external gateway if the router was removed from one network node and added to another by some external script or manual intervention. It did not send anything on the internal network ports. VRRP is a different story and the code in review [1] sends GARPs on internal and external ports. Hope this helps avoid confusion in this discussion. Carl [1] https://review.openstack.org/#/c/70700/37/neutron/agent/l3_ha_agent.py On Mon, Sep 1, 2014 at 8:52 PM, Xu Han Peng pengxu...@gmail.com wrote: Anthony, Thanks for your reply. If HA method like VRRP are used for IPv6 router, according to the VRRP RFC with IPv6 included, the servers should be auto-configured with the active router's LLA as the default route before the failover happens and still remain that route after the failover. In other word, there should be no need to use two LLAs for default route of a subnet unless load balance is required. When the backup router become the master router, the backup router should be responsible for sending out an unsolicited ND neighbor advertisement with the associated LLA (the previous master's LLA) immediately to update the bridge learning state and sending out router advertisement with the same options with the previous master to maintain the route and bridge learning. This is shown in http://tools.ietf.org/html/rfc5798#section-4.1 and the actions backup router should take after failover is documented here: http://tools.ietf.org/html/rfc5798#section-6.4.2. The need for immediate messaging sending and periodic message sending is documented here: http://tools.ietf.org/html/rfc5798#section-2.4 Since the keepalived manager support for L3 HA is merged: https://review.openstack.org/#/c/68142/43. And keepalived release 1.2.0 supports VRRP IPv6 features ( http://www.keepalived.org/changelog.html, see Release 1.2.0 | VRRP IPv6 Release). I think we can check if keepalived can satisfy our requirement here and if that will cause any conflicts with RADVD. Thoughts? Xu Han On 08/28/2014 10:11 PM, Veiga, Anthony wrote: Anthony and Robert, Thanks for your reply. I don't know if the arping is there for NAT, but I am pretty sure it's for HA setup to broadcast the router's own change since the arping is controlled by send_arp_for_ha config. By checking the man page of arping, you can find the arping -A we use in code is sending out ARP REPLY instead of ARP REQUEST. This is like saying I am here instead of where are you. I didn't realized this either until Brain pointed this out at my code review below. That’s what I was trying to say earlier. Sending out the RA is the same effect. RA says “I’m here, oh and I’m also a router” and should supersede the need for an unsolicited NA. The only thing to consider here is that RAs are from LLAs. If you’re doing IPv6 HA, you’ll need to have two gateway IPs for the RA of the standby to work. So far as I know, I think there’s still a bug out on this since you can only have one gateway per subnet. http://linux.die.net/man/8/arping https://review.openstack.org/#/c/114437/2/neutron/agent/l3_agent.py Thoughts? Xu Han On 08/27/2014 10:01 PM, Veiga, Anthony wrote: Hi Xuhan, What I saw is that GARP is sent to the gateway port and also to the router ports, from a neutron router. I’m not sure why it’s sent to the router ports (internal network). My understanding for arping to the gateway port is that it is needed for proper NAT operation. Since we are not planning to support ipv6 NAT, so this is not required/needed for ipv6 any more? I agree that this is no longer necessary. There is an abandoned patch that disabled the arping for ipv6 gateway port: https://review.openstack.org/#/c/77471/3/neutron/agent/l3_agent.py thanks, Robert On 8/27/14, 1:03 AM, Xuhan Peng pengxu...@gmail.com wrote: As a follow-up action of yesterday's IPv6 sub-team meeting, I would like to start a discussion about how to support l3 agent HA when IP version is IPv6. This problem is triggered by bug [1] where sending gratuitous arp packet for HA doesn't work for IPv6 subnet gateways. This is because neighbor discovery instead of ARP should be used for IPv6. My thought to solve this problem turns into how to send out neighbor advertisement for IPv6 routers just like sending ARP reply for IPv4 routers after reading the comments on code review [2]. I searched for utilities which can do this and only find a utility called ndsend [3] as part of vzctl on ubuntu. I could not find similar tools on other linux distributions. There are comments in yesterday's meeting that it's the new router's job to send out RA and there is no need for neighbor discovery. But we didn't get enough time to
Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA
Sounds impressive! :-D On 1 September 2014 23:52, Xu Han Peng pengxu...@gmail.com wrote: Anthony, Thanks for your reply. If HA method like VRRP are used for IPv6 router, according to the VRRP RFC with IPv6 included, the servers should be auto-configured with the active router's LLA as the default route before the failover happens and still remain that route after the failover. In other word, there should be no need to use two LLAs for default route of a subnet unless load balance is required. When the backup router become the master router, the backup router should be responsible for sending out an unsolicited ND neighbor advertisement with the associated LLA (the previous master's LLA) immediately to update the bridge learning state and sending out router advertisement with the same options with the previous master to maintain the route and bridge learning. This is shown in http://tools.ietf.org/html/rfc5798#section-4.1 and the actions backup router should take after failover is documented here: http://tools.ietf.org/html/rfc5798#section-6.4.2. The need for immediate messaging sending and periodic message sending is documented here: http://tools.ietf.org/html/rfc5798#section-2.4 Since the keepalived manager support for L3 HA is merged: https://review.openstack.org/#/c/68142/43. And keepalived release 1.2.0 supports VRRP IPv6 features ( http://www.keepalived.org/changelog.html, see Release 1.2.0 | VRRP IPv6 Release). I think we can check if keepalived can satisfy our requirement here and if that will cause any conflicts with RADVD. Thoughts? Xu Han On 08/28/2014 10:11 PM, Veiga, Anthony wrote: Anthony and Robert, Thanks for your reply. I don't know if the arping is there for NAT, but I am pretty sure it's for HA setup to broadcast the router's own change since the arping is controlled by send_arp_for_ha config. By checking the man page of arping, you can find the arping -A we use in code is sending out ARP REPLY instead of ARP REQUEST. This is like saying I am here instead of where are you. I didn't realized this either until Brain pointed this out at my code review below. That’s what I was trying to say earlier. Sending out the RA is the same effect. RA says “I’m here, oh and I’m also a router” and should supersede the need for an unsolicited NA. The only thing to consider here is that RAs are from LLAs. If you’re doing IPv6 HA, you’ll need to have two gateway IPs for the RA of the standby to work. So far as I know, I think there’s still a bug out on this since you can only have one gateway per subnet. http://linux.die.net/man/8/arping https://review.openstack.org/#/c/114437/2/neutron/agent/l3_agent.py Thoughts? Xu Han On 08/27/2014 10:01 PM, Veiga, Anthony wrote: Hi Xuhan, What I saw is that GARP is sent to the gateway port and also to the router ports, from a neutron router. I’m not sure why it’s sent to the router ports (internal network). My understanding for arping to the gateway port is that it is needed for proper NAT operation. Since we are not planning to support ipv6 NAT, so this is not required/needed for ipv6 any more? I agree that this is no longer necessary. There is an abandoned patch that disabled the arping for ipv6 gateway port: https://review.openstack.org/#/c/77471/3/neutron/agent/l3_agent.py thanks, Robert On 8/27/14, 1:03 AM, Xuhan Peng pengxu...@gmail.com wrote: As a follow-up action of yesterday's IPv6 sub-team meeting, I would like to start a discussion about how to support l3 agent HA when IP version is IPv6. This problem is triggered by bug [1] where sending gratuitous arp packet for HA doesn't work for IPv6 subnet gateways. This is because neighbor discovery instead of ARP should be used for IPv6. My thought to solve this problem turns into how to send out neighbor advertisement for IPv6 routers just like sending ARP reply for IPv4 routers after reading the comments on code review [2]. I searched for utilities which can do this and only find a utility called ndsend [3] as part of vzctl on ubuntu. I could not find similar tools on other linux distributions. There are comments in yesterday's meeting that it's the new router's job to send out RA and there is no need for neighbor discovery. But we didn't get enough time to finish the discussion. Because OpenStack runs the l3 agent, it is the router. Instead of needing to do gratuitous ARP to alert all clients of the new MAC, a simple RA from the new router for the same prefix would accomplish the same, without having to resort to a special package to generate unsolicited NA packets. RAs must be generated from the l3 agent anyway if it’s the gateway, and we’re doing that via radvd now. The HA failover simply needs to start the proper radvd process on the secondary gateway and resume normal operation. Can you comment your thoughts about how to solve this problem in this
Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA
Anthony, Thanks for your reply. If HA method like VRRP are used for IPv6 router, according to the VRRP RFC with IPv6 included, the servers should be auto-configured with the active router's LLA as the default route before the failover happens and still remain that route after the failover. In other word, there should be no need to use two LLAs for default route of a subnet unless load balance is required. When the backup router become the master router, the backup router should be responsible for sending out an unsolicited ND neighbor advertisement with the associated LLA (the previous master's LLA) immediately to update the bridge learning state and sending out router advertisement with the same options with the previous master to maintain the route and bridge learning. This is shown in http://tools.ietf.org/html/rfc5798#section-4.1 and the actions backup router should take after failover is documented here: http://tools.ietf.org/html/rfc5798#section-6.4.2. The need for immediate messaging sending and periodic message sending is documented here: http://tools.ietf.org/html/rfc5798#section-2.4 Since the keepalived manager support for L3 HA is merged: https://review.openstack.org/#/c/68142/43. And keepalived release 1.2.0 supports VRRP IPv6 features ( http://www.keepalived.org/changelog.html, see Release 1.2.0 | VRRP IPv6 Release). I think we can check if keepalived can satisfy our requirement here and if that will cause any conflicts with RADVD. Thoughts? Xu Han On 08/28/2014 10:11 PM, Veiga, Anthony wrote: Anthony and Robert, Thanks for your reply. I don't know if the arping is there for NAT, but I am pretty sure it's for HA setup to broadcast the router's own change since the arping is controlled by send_arp_for_ha config. By checking the man page of arping, you can find the arping -A we use in code is sending out ARP REPLY instead of ARP REQUEST. This is like saying I am here instead of where are you. I didn't realized this either until Brain pointed this out at my code review below. That's what I was trying to say earlier. Sending out the RA is the same effect. RA says I'm here, oh and I'm also a router and should supersede the need for an unsolicited NA. The only thing to consider here is that RAs are from LLAs. If you're doing IPv6 HA, you'll need to have two gateway IPs for the RA of the standby to work. So far as I know, I think there's still a bug out on this since you can only have one gateway per subnet. http://linux.die.net/man/8/arping https://review.openstack.org/#/c/114437/2/neutron/agent/l3_agent.py Thoughts? Xu Han On 08/27/2014 10:01 PM, Veiga, Anthony wrote: Hi Xuhan, What I saw is that GARP is sent to the gateway port and also to the router ports, from a neutron router. I'm not sure why it's sent to the router ports (internal network). My understanding for arping to the gateway port is that it is needed for proper NAT operation. Since we are not planning to support ipv6 NAT, so this is not required/needed for ipv6 any more? I agree that this is no longer necessary. There is an abandoned patch that disabled the arping for ipv6 gateway port: https://review.openstack.org/#/c/77471/3/neutron/agent/l3_agent.py thanks, Robert On 8/27/14, 1:03 AM, Xuhan Peng pengxu...@gmail.com mailto:pengxu...@gmail.com wrote: As a follow-up action of yesterday's IPv6 sub-team meeting, I would like to start a discussion about how to support l3 agent HA when IP version is IPv6. This problem is triggered by bug [1] where sending gratuitous arp packet for HA doesn't work for IPv6 subnet gateways. This is because neighbor discovery instead of ARP should be used for IPv6. My thought to solve this problem turns into how to send out neighbor advertisement for IPv6 routers just like sending ARP reply for IPv4 routers after reading the comments on code review [2]. I searched for utilities which can do this and only find a utility called ndsend [3] as part of vzctl on ubuntu. I could not find similar tools on other linux distributions. There are comments in yesterday's meeting that it's the new router's job to send out RA and there is no need for neighbor discovery. But we didn't get enough time to finish the discussion. Because OpenStack runs the l3 agent, it is the router. Instead of needing to do gratuitous ARP to alert all clients of the new MAC, a simple RA from the new router for the same prefix would accomplish the same, without having to resort to a special package to generate unsolicited NA packets. RAs must be generated
Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA
Anthony and Robert, Thanks for your reply. I don't know if the arping is there for NAT, but I am pretty sure it's for HA setup to broadcast the router's own change since the arping is controlled by send_arp_for_ha config. By checking the man page of arping, you can find the arping -A we use in code is sending out ARP REPLY instead of ARP REQUEST. This is like saying I am here instead of where are you. I didn't realized this either until Brain pointed this out at my code review below. http://linux.die.net/man/8/arping https://review.openstack.org/#/c/114437/2/neutron/agent/l3_agent.py Thoughts? Xu Han On 08/27/2014 10:01 PM, Veiga, Anthony wrote: Hi Xuhan, What I saw is that GARP is sent to the gateway port and also to the router ports, from a neutron router. I'm not sure why it's sent to the router ports (internal network). My understanding for arping to the gateway port is that it is needed for proper NAT operation. Since we are not planning to support ipv6 NAT, so this is not required/needed for ipv6 any more? I agree that this is no longer necessary. There is an abandoned patch that disabled the arping for ipv6 gateway port: https://review.openstack.org/#/c/77471/3/neutron/agent/l3_agent.py thanks, Robert On 8/27/14, 1:03 AM, Xuhan Peng pengxu...@gmail.com mailto:pengxu...@gmail.com wrote: As a follow-up action of yesterday's IPv6 sub-team meeting, I would like to start a discussion about how to support l3 agent HA when IP version is IPv6. This problem is triggered by bug [1] where sending gratuitous arp packet for HA doesn't work for IPv6 subnet gateways. This is because neighbor discovery instead of ARP should be used for IPv6. My thought to solve this problem turns into how to send out neighbor advertisement for IPv6 routers just like sending ARP reply for IPv4 routers after reading the comments on code review [2]. I searched for utilities which can do this and only find a utility called ndsend [3] as part of vzctl on ubuntu. I could not find similar tools on other linux distributions. There are comments in yesterday's meeting that it's the new router's job to send out RA and there is no need for neighbor discovery. But we didn't get enough time to finish the discussion. Because OpenStack runs the l3 agent, it is the router. Instead of needing to do gratuitous ARP to alert all clients of the new MAC, a simple RA from the new router for the same prefix would accomplish the same, without having to resort to a special package to generate unsolicited NA packets. RAs must be generated from the l3 agent anyway if it's the gateway, and we're doing that via radvd now. The HA failover simply needs to start the proper radvd process on the secondary gateway and resume normal operation. Can you comment your thoughts about how to solve this problem in this thread, please? [1] https://bugs.launchpad.net/neutron/+bug/1357068 [2] https://review.openstack.org/#/c/114437/ [3] http://manpages.ubuntu.com/manpages/oneiric/man8/ndsend.8.html Thanks, Xu Han -Anthony ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA
Anthony and Robert, Thanks for your reply. I don't know if the arping is there for NAT, but I am pretty sure it's for HA setup to broadcast the router's own change since the arping is controlled by send_arp_for_ha config. By checking the man page of arping, you can find the arping -A we use in code is sending out ARP REPLY instead of ARP REQUEST. This is like saying I am here instead of where are you. I didn't realized this either until Brain pointed this out at my code review below. That’s what I was trying to say earlier. Sending out the RA is the same effect. RA says “I’m here, oh and I’m also a router” and should supersede the need for an unsolicited NA. The only thing to consider here is that RAs are from LLAs. If you’re doing IPv6 HA, you’ll need to have two gateway IPs for the RA of the standby to work. So far as I know, I think there’s still a bug out on this since you can only have one gateway per subnet. http://linux.die.net/man/8/arping https://review.openstack.org/#/c/114437/2/neutron/agent/l3_agent.py Thoughts? Xu Han On 08/27/2014 10:01 PM, Veiga, Anthony wrote: Hi Xuhan, What I saw is that GARP is sent to the gateway port and also to the router ports, from a neutron router. I’m not sure why it’s sent to the router ports (internal network). My understanding for arping to the gateway port is that it is needed for proper NAT operation. Since we are not planning to support ipv6 NAT, so this is not required/needed for ipv6 any more? I agree that this is no longer necessary. There is an abandoned patch that disabled the arping for ipv6 gateway port: https://review.openstack.org/#/c/77471/3/neutron/agent/l3_agent.py thanks, Robert On 8/27/14, 1:03 AM, Xuhan Peng pengxu...@gmail.commailto:pengxu...@gmail.com wrote: As a follow-up action of yesterday's IPv6 sub-team meeting, I would like to start a discussion about how to support l3 agent HA when IP version is IPv6. This problem is triggered by bug [1] where sending gratuitous arp packet for HA doesn't work for IPv6 subnet gateways. This is because neighbor discovery instead of ARP should be used for IPv6. My thought to solve this problem turns into how to send out neighbor advertisement for IPv6 routers just like sending ARP reply for IPv4 routers after reading the comments on code review [2]. I searched for utilities which can do this and only find a utility called ndsend [3] as part of vzctl on ubuntu. I could not find similar tools on other linux distributions. There are comments in yesterday's meeting that it's the new router's job to send out RA and there is no need for neighbor discovery. But we didn't get enough time to finish the discussion. Because OpenStack runs the l3 agent, it is the router. Instead of needing to do gratuitous ARP to alert all clients of the new MAC, a simple RA from the new router for the same prefix would accomplish the same, without having to resort to a special package to generate unsolicited NA packets. RAs must be generated from the l3 agent anyway if it’s the gateway, and we’re doing that via radvd now. The HA failover simply needs to start the proper radvd process on the secondary gateway and resume normal operation. Can you comment your thoughts about how to solve this problem in this thread, please? [1] https://bugs.launchpad.net/neutron/+bug/1357068 [2] https://review.openstack.org/#/c/114437/ [3] http://manpages.ubuntu.com/manpages/oneiric/man8/ndsend.8.html Thanks, Xu Han -Anthony ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA
Hi Xuhan, What I saw is that GARP is sent to the gateway port and also to the router ports, from a neutron router. I’m not sure why it’s sent to the router ports (internal network). My understanding for arping to the gateway port is that it is needed for proper NAT operation. Since we are not planning to support ipv6 NAT, so this is not required/needed for ipv6 any more? There is an abandoned patch that disabled the arping for ipv6 gateway port: https://review.openstack.org/#/c/77471/3/neutron/agent/l3_agent.py thanks, Robert On 8/27/14, 1:03 AM, Xuhan Peng pengxu...@gmail.commailto:pengxu...@gmail.com wrote: As a follow-up action of yesterday's IPv6 sub-team meeting, I would like to start a discussion about how to support l3 agent HA when IP version is IPv6. This problem is triggered by bug [1] where sending gratuitous arp packet for HA doesn't work for IPv6 subnet gateways. This is because neighbor discovery instead of ARP should be used for IPv6. My thought to solve this problem turns into how to send out neighbor advertisement for IPv6 routers just like sending ARP reply for IPv4 routers after reading the comments on code review [2]. I searched for utilities which can do this and only find a utility called ndsend [3] as part of vzctl on ubuntu. I could not find similar tools on other linux distributions. There are comments in yesterday's meeting that it's the new router's job to send out RA and there is no need for neighbor discovery. But we didn't get enough time to finish the discussion. Can you comment your thoughts about how to solve this problem in this thread, please? [1] https://bugs.launchpad.net/neutron/+bug/1357068 [2] https://review.openstack.org/#/c/114437/ [3] http://manpages.ubuntu.com/manpages/oneiric/man8/ndsend.8.html Thanks, Xu Han ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA
Hi Xuhan, What I saw is that GARP is sent to the gateway port and also to the router ports, from a neutron router. I’m not sure why it’s sent to the router ports (internal network). My understanding for arping to the gateway port is that it is needed for proper NAT operation. Since we are not planning to support ipv6 NAT, so this is not required/needed for ipv6 any more? I agree that this is no longer necessary. There is an abandoned patch that disabled the arping for ipv6 gateway port: https://review.openstack.org/#/c/77471/3/neutron/agent/l3_agent.py thanks, Robert On 8/27/14, 1:03 AM, Xuhan Peng pengxu...@gmail.commailto:pengxu...@gmail.com wrote: As a follow-up action of yesterday's IPv6 sub-team meeting, I would like to start a discussion about how to support l3 agent HA when IP version is IPv6. This problem is triggered by bug [1] where sending gratuitous arp packet for HA doesn't work for IPv6 subnet gateways. This is because neighbor discovery instead of ARP should be used for IPv6. My thought to solve this problem turns into how to send out neighbor advertisement for IPv6 routers just like sending ARP reply for IPv4 routers after reading the comments on code review [2]. I searched for utilities which can do this and only find a utility called ndsend [3] as part of vzctl on ubuntu. I could not find similar tools on other linux distributions. There are comments in yesterday's meeting that it's the new router's job to send out RA and there is no need for neighbor discovery. But we didn't get enough time to finish the discussion. Because OpenStack runs the l3 agent, it is the router. Instead of needing to do gratuitous ARP to alert all clients of the new MAC, a simple RA from the new router for the same prefix would accomplish the same, without having to resort to a special package to generate unsolicited NA packets. RAs must be generated from the l3 agent anyway if it’s the gateway, and we’re doing that via radvd now. The HA failover simply needs to start the proper radvd process on the secondary gateway and resume normal operation. Can you comment your thoughts about how to solve this problem in this thread, please? [1] https://bugs.launchpad.net/neutron/+bug/1357068 [2] https://review.openstack.org/#/c/114437/ [3] http://manpages.ubuntu.com/manpages/oneiric/man8/ndsend.8.html Thanks, Xu Han -Anthony ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron][IPv6] Neighbor Discovery for HA
As a follow-up action of yesterday's IPv6 sub-team meeting, I would like to start a discussion about how to support l3 agent HA when IP version is IPv6. This problem is triggered by bug [1] where sending gratuitous arp packet for HA doesn't work for IPv6 subnet gateways. This is because neighbor discovery instead of ARP should be used for IPv6. My thought to solve this problem turns into how to send out neighbor advertisement for IPv6 routers just like sending ARP reply for IPv4 routers after reading the comments on code review [2]. I searched for utilities which can do this and only find a utility called ndsend [3] as part of vzctl on ubuntu. I could not find similar tools on other linux distributions. There are comments in yesterday's meeting that it's the new router's job to send out RA and there is no need for neighbor discovery. But we didn't get enough time to finish the discussion. Can you comment your thoughts about how to solve this problem in this thread, please? [1] https://bugs.launchpad.net/neutron/+bug/1357068 [2] https://review.openstack.org/#/c/114437/ [3] http://manpages.ubuntu.com/manpages/oneiric/man8/ndsend.8.html Thanks, Xu Han ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
