<div dir="ltr">Sounds impressive!   :-D</div><div class="gmail_extra"><br><br><div class="gmail_quote">On 1 September 2014 23:52, Xu Han Peng <span dir="ltr"><<a href="mailto:pengxuhan@gmail.com" target="_blank">pengxuhan@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    Anthony,<br>
    <br>
    Thanks for your reply. <br>
    <br>
    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. <br>
    <br>
    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. <br>
    <br>
    This is shown in
    
    <a href="http://tools.ietf.org/html/rfc5798#section-4.1" target="_blank">http://tools.ietf.org/html/rfc5798#section-4.1</a>
    and the actions backup router should take after failover is
    documented here: 
    
    <a href="http://tools.ietf.org/html/rfc5798#section-6.4.2" target="_blank">http://tools.ietf.org/html/rfc5798#section-6.4.2</a>.
    The need for immediate messaging sending and periodic message
    sending is documented here:
    
    <a href="http://tools.ietf.org/html/rfc5798#section-2.4" target="_blank">http://tools.ietf.org/html/rfc5798#section-2.4</a><br>
    <br>
    Since the keepalived manager support for L3 HA is merged:
    
    <a href="https://review.openstack.org/#/c/68142/43" target="_blank">https://review.openstack.org/#/c/68142/43</a>.
    And keepalived release 1.2.0 supports VRRP IPv6 features (
    
    
    <a href="http://www.keepalived.org/changelog.html" target="_blank">http://www.keepalived.org/changelog.html</a>,
    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. <br>
    <br>
    Thoughts?<br>
    <br>
    Xu Han<div><div class="h5"><br>
    <br>
    <div>On 08/28/2014 10:11 PM, Veiga, Anthony
      wrote:<br>
    </div>
    </div></div><blockquote type="cite"><div><div class="h5">
      
      <div><br>
      </div>
      <div><br>
      </div>
      <span>
        <blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
          <div>
            <div bgcolor="#FFFFFF" text="#000000">Anthony and Robert,<br>
              <br>
              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.
            </div>
          </div>
        </blockquote>
      </span>
      <div><br>
      </div>
      <div>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.</div>
      <div><br>
      </div>
      <span>
        <blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
          <div>
            <div bgcolor="#FFFFFF" text="#000000"><br>
              <br>
              <a href="http://linux.die.net/man/8/arping" target="_blank">http://linux.die.net/man/8/arping</a><br>
              <br>
              <a href="https://review.openstack.org/#/c/114437/2/neutron/agent/l3_agent.py" target="_blank">https://review.openstack.org/#/c/114437/2/neutron/agent/l3_agent.py</a><br>
              <br>
              Thoughts?<br>
              <br>
              Xu Han<br>
              <br>
              <br>
              <div>On 08/27/2014 10:01 PM,
                Veiga, Anthony wrote:<br>
              </div>
              <blockquote type="cite">
                <span>
                  <blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
                    <div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
                      <div><br>
                        Hi Xuhan,</div>
                      <div><br>
                      </div>
                      <div>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?</div>
                    </div>
                  </blockquote>
                </span>
                <div><br>
                </div>
                <div>I agree that this is no longer necessary.</div>
                <div><br>
                </div>
                <span>
                  <blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
                    <div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
                      <div><br>
                      </div>
                      <div>There is an abandoned patch that disabled the
                        arping for ipv6 gateway port:  <a href="https://review.openstack.org/#/c/77471/3/neutron/agent/l3_agent.py" target="_blank">https://review.openstack.org/#/c/77471/3/neutron/agent/l3_agent.py</a></div>


                      <div><br>
                      </div>
                      <div>thanks,</div>
                      <div>Robert</div>
                      <div><br>
                      </div>
                      <span>
                        <div>
                          <div>On 8/27/14, 1:03 AM, "Xuhan Peng" <<a href="mailto:pengxuhan@gmail.com" target="_blank">pengxuhan@gmail.com</a>>
                            wrote:</div>
                        </div>
                        <div><br>
                        </div>
                        <blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
                          <div>
                            <div>
                              <div dir="ltr">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. 
                                <div><br>
                                </div>
                                <div>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.</div>
                                <div><br>
                                </div>
                                <div>My thought to solve this
                                  problem turns into how to send out<font color="#000000" face="sans-serif"> neighbor
                                    advertisement for IPv6 routers just
                                    like sending ARP reply for IPv4
                                    routers after reading the comments
                                    on code review [2].</font></div>
                                <div><font color="#000000" face="sans-serif"><br>
                                  </font></div>
                                <div><font color="#000000" face="sans-serif">I searched for
                                    utilities which can do this and only
                                    find a utility called ndsend [3] as
                                    part of vzctl </font><span style="color:rgb(0,0,0);font-family:sans-serif">on
                                    ubuntu. I could not find similar
                                    tools on other linux distributions. </span></div>
                                <div><br>
                                </div>
                                <div>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. </div>
                              </div>
                            </div>
                          </div>
                        </blockquote>
                      </span></div>
                  </blockquote>
                </span>
                <div><br>
                </div>
                <div>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.</div>
                <div><br>
                </div>
                <span>
                  <blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
                    <div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
                      <span>
                        <blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
                          <div>
                            <div>
                              <div dir="ltr">
                                <div><br>
                                </div>
                                <div>Can you comment your
                                  thoughts about how to solve this
                                  problem in this thread, please?</div>
                                <div><br>
                                </div>
                                <div>[1] <a href="https://bugs.launchpad.net/neutron/+bug/1357068" target="_blank">https://bugs.launchpad.net/neutron/+bug/1357068</a></div>
                                <div><br>
                                </div>
                                <div>[2] <a href="https://review.openstack.org/#/c/114437/" target="_blank">https://review.openstack.org/#/c/114437/</a></div>
                                <div><br>
                                </div>
                                <div>[3] <a href="http://manpages.ubuntu.com/manpages/oneiric/man8/ndsend.8.html" target="_blank">
http://manpages.ubuntu.com/manpages/oneiric/man8/ndsend.8.html</a></div>
                                <div><br>
                                </div>
                                <div>Thanks,</div>
                                <div>Xu Han </div>
                              </div>
                            </div>
                          </div>
                        </blockquote>
                      </span></div>
                  </blockquote>
                </span>
                <div><br>
                </div>
                <div><br>
                </div>
                <div>-Anthony</div>
                <br>
                <fieldset></fieldset>
                <br>
                <pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></pre>


              </blockquote>
              <br>
            </div>
          </div>
        </blockquote>
      </span>
      <br>
      <fieldset></fieldset>
      <br>
      </div></div><div class=""><pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </div></blockquote>
    <br>
  </div>

<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>