14:02:41 #startmeeting neutron_ipv6 14:02:42 Meeting started Tue Aug 26 14:02:41 2014 UTC and is due to finish in 60 minutes. The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:43 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:45 The meeting name has been set to 'neutron_ipv6' 14:04:26 hello 14:04:30 First off, I want to say that everyone has done a hell of a job this development cycle 14:04:58 If I am not mistaken, since xuhanp's review for dnsmasq got merged, we have completed all ipv6 blueprints for the Juno development cycle 14:05:14 plus, we got everything in before the mad rush for the deadline of J-3 14:05:37 sc68cal: is that the stateful dhcp mode setting review? got a link? 14:05:49 yeah let me dig it up 14:05:58 no rush, and congrats :) 14:06:10 https://review.openstack.org/106299 14:08:55 sc68cal, We will need this fix to make DHCPv6 security group work: https://review.openstack.org/#/c/103811/ 14:08:55 but I think we are close to merge 14:09:20 perfect, that was going to be my next question - if there is anything we need to get core attention on 14:09:25 Hi, I have a question concerning the ipv6-radvd-ra spec. Wasnt there a problem with two default routes on the neutron router when there are RAs send from within the router namespace for the tenant network and also RAs from an upstream router for the external network? I only saw an abandoned patch from randy tuttle. 14:10:36 paraa: do you have the link to the patch in gerrit? 14:10:47 paraa: This is the limitation that router ports can only have 1 IP address, either IPv4 or v6, not both? 14:11:04 https://review.openstack.org/#/c/77471/ 14:11:20 That's not an IPv6 limitation. IPv6 can have multiple addresses on a port. 14:12:01 paraa FJB: I don't think we currently support multiple RAs from different nodes at this point 14:12:14 FJB: Right, there's a blueprint up for review that tries to address neutron concerns with multiple v6 addresses 14:12:29 I don't think randy tuttle has been active lately, so paraa - if you can get a good bug report to help identify the issue we can probably get a fix 14:13:06 I think right now that info is in people's heads - bug report would be good to help share info 14:13:26 or a BP - as dane_leblanc mentioned :) 14:13:52 sc68cal: Check out the BP, it at least tries to address this 14:14:35 dane_leblanc: yeah, as soon as they create the Kilo directory - get ready for your BP to be high priority for us 14:14:42 sc68cal the fix is already part of the patch. I will try to get a clean bug report together and grep the fix from the patch. 14:15:02 sc68cal: Yes, can't wait! Thanks 14:15:44 paraa: awesome. That'll help give context - plus we can get bug fixes in quicker than bp's ;) 14:16:09 speaking of. 14:16:11 https://bugs.launchpad.net/neutron/+bugs?field.tag=ipv6 14:17:18 So I want to discuss this bug 14:17:21 https://bugs.launchpad.net/neutron/+bug/1358297 14:17:23 Launchpad bug 1358297 in neutron "Port doesn't receive IP SLAAC in subnets with Router advertisements without dnsmasq" [Medium,Incomplete] 14:17:36 We have some differences that have been showing up in the tables that we filed for each IPv6 spec 14:17:56 frankly, I want to remove these differences between the specs and just pick one, and copy and paste it into all three 14:18:04 having different tables in each spec is leading to confusion 14:22:23 anyone have an opinion on what I've said? 14:23:20 I don't think there's disagreement, only a need for volunteer to do it? 14:25:28 dane_leblanc: agreed 14:25:41 We also need to probably collect all the DocImpact bugs and start working on some documentation 14:29:59 sc68cal, agree. I need to document the dnsmasq version check somewhere 14:30:22 I think it might be good to have a page or section that explains configurations 14:30:29 since that's been such a heated topic of debate 14:33:36 agreed 14:35:13 Anyone else have any topics to discuss? 14:35:31 sc68cal, I have a topic to discuss if you finish this one? 14:35:37 xuhanp: all yours 14:36:17 https://review.openstack.org/#/c/114437 14:36:47 I am work on a bug to find the replacement for gratuitous ARP in IPv6 form 14:36:52 For HA 14:36:56 Who gets pinged? 14:37:47 xuhanp: reading now 14:37:47 that depends on what you're looking for 14:38:03 there's a multicast address for each type of device 14:38:11 all-nodes, all-routers, etc 14:38:58 A ping to "all nodes" sounds, um, "interesting". 14:39:11 but if the HA is using something like HSRP or VRRP, you just need to send an NS for the gateway 14:39:36 yes 14:39:46 xuhanp: so currently we need to find a way to inject ND packets in a way that works in multiple distros, instead of just ubuntu? 14:39:50 as in ::0 14:40:18 It's for HA backup router who takes over to advertise ARP reply 14:40:18 for IPv6, we need to send out unsolicited neighbor advertisement. 14:40:18 I found a ubuntu software ndsend who can do this. 14:40:19 but not on other platforms. 14:40:20 anyone have any ideas on this? 14:40:22 Brian Haley commented: There is no equivalent command to send a Neighbour Advertisement, it will simply be done when Duplicate Address Detection is run. 14:40:40 xuhanp: actually, just issue a new RA 14:40:45 no need for the NS 14:41:06 since it's being sent from the router, it should take over the RA job from the primary 14:41:22 let the old RA timeout (your timers are already short, right?) then takeover from the new node 14:41:38 you can set the priority higher to let it takeover instantly 14:41:39 it should come from the source LLA anyway, so no need for ND to happen 14:41:51 paraa: priority is ignored by almost all linux distros currently :/ 14:44:30 xuhanp: my other question about that change was why are we doing proxy ndp when there's not NAT, but is this for HA? 14:46:39 haleyb: I think xuhanp missed your line 14:46:54 I got disconnected. sorry about that. 14:47:48 i'll paste it again 14:47:49 xuhanp: my other question about that change was why are we doing proxy ndp when there's not NAT, but is this for HA? 14:48:22 yes. this is for HA cause the ARP of IPv4 is for HA 14:48:51 and there is a bug reported since ARP doesn't work for IPv6 14:53:09 sc68cal, since we don't get an conclusion here, may I take this to the ML? Or I missed the answer during my disconnection? 14:53:35 ML is probably good - you didn't miss an answer during your disconnect 14:53:45 sounds great 14:54:13 xuhanp: sorry, got distracted, but yes, if you can find some utility to send these that would be ok with me 14:54:39 haleyb, my problem is I only find one for ubuntu. not for other platforms. 14:54:44 but i would assume that configuring the address would send an NS 14:55:10 i.e. when DAD is run 14:55:27 again, you shouldn't have to send a new NS 14:55:43 since it's a router, sending a new RA should trigget that whole procedure for you 14:55:51 trigger* 14:56:16 xuhanp: yeah it's kind of odd, that util you found is part of the openvz package, according to manpage. Probably an odd dependency to add for Neutron 14:56:28 sc68cal, right. 14:56:47 Maybe the ML or that review is a good place to comment since we're almost out of time 14:57:05 markmcclain and I had a wacky idea to write some neutron code that would inject ICMPv6 RA packets directly. Might be another use case ;) 14:57:21 sc68cal: I second this for unicasting RAs for floats :-P 14:57:35 and when I say markmcclain and I had a wacky idea, mostly mark said it to me and I liked it because it's awesome - he had the idea 14:58:35 sc68cal: you mean using a library to inject an AF_PACKET packet? 14:58:58 yeah, trying to remember the name of that python lib for packet processing 14:59:01 scapy 14:59:06 aveiga, do we need to trigger to send RA when backup turns into master in HA conf? 14:59:25 xuhanp: if the device is acting as a router, it needs to send an RA anyway 14:59:30 shouldn't need to trigger anything 14:59:50 Sounds like we need a thread on the ML :) 14:59:53 we're out of time 15:00:12 I will send out an email 15:00:19 xuhanp: awesome 15:00:28 Thanks everyone for attending, see everyone on the ML or #openstack-neutron! 15:00:32 #endmeeting