This group is locked. No changes can be made to the group while it is locked.
Re: Marcelo - Unit test for the networking-odl L3
Flavio Fernandes <ffernand@...>
On Jul 7, 2015, at 10:31 AM, Marcelo Amaral <marcelo.amaral@...> wrote:[ccing ovsdb-dev, Anil & Hideyuki] Hello Marcelo, As you probably know, it is my intention to write part 3 of the blog to talk about DNAT’s implementation in odl’s L3 obvsd netvirt. I just need to bump it in the priority list; your email and Hideyuki’s question on irc have been a good motivators. ;) Thanks! - When the method updateExternalRouterMac is invoked? In which context?That is part of work Anil is wrapping up for ‘bug’ 3378 [1]. In the near future, a tracker like service written by Anil will call ‘updateExternalRouterMac’ so mac of nexthop gateway out of br-ex is known. Very good question. ;) A cheesy and cheap stop gap until then is to provide that mac address via ovsdb.l3gateway.mac (in custom.properties). Not for long! Yes, a neutron message regarding the floating ip association is sent to odl via ml2. An example of how that message looks like can be seen here [2]. If you use postman, I shared a collection with the messages would would expect to see from ml2 to create/associate floating ips here [3]. By the way, you can ‘spy’ on all that ml2 communication. :) For details on doing that, look here [4]. In this case, the method handleNeutronFloatingIPEvent() is invoked to handle a floating ip creation:Yes, absolutely. The arp rules to handle floating ips are done here [5]. That is correct. An example of how table 30 looks like is here [6]. As you can see, we use REG3 to keep track of the segmentation id that goes with the tenant associated with the floating ip. That is later on used in table 60 as part of the match [7]. I will — hopefully — do a better job showing that when I get a complete working example in the blog. 3 - creating the outbound ruleYes, that is right. An example of that rule would look like this [8]. To connect to br-ex from br-int, we use a patch-port. On table 100, we use the priority to weed out the floating ips from the rest of the internal tenant’s subnets. The gist [8] shows that floating ips in table 100 are checked after since their priority is lower. - How does it know the target host to configure the OVS?That is done with the help of ovs’s port external id. When nova creates an ovs port/interface to be used by a tenant vm, is puts some bread crumbs in the external_ids of the interface. That value is the neutron port uuid. Once we know how to map the ovs interface with the neutron port, we can pinpoint which bridge/node (dpid) is the home of the floating ip address, just by connecting the dots. I talk a bit about the matching of ovs interface with neutron port in part 1 of the blog [9]. Since ovs is co-located with the compute node, we can infer where all the tenant’s ports are. Best, — flavio Best regards,[1]: https://bugs.opendaylight.org/show_bug.cgi?id=3378 [2]: https://gist.github.com/36bd41daa237d7ab780e [3]: https://www.getpostman.com/collections/1e316aebd6cbb1991b25 [4]: https://wiki.opendaylight.org/view/NeutronNorthbound:Help_Us_Help_You [5]: programFlowsForFloatingIPArpAdd —> https://github.com/opendaylight/ovsdb/blob/stable/lithium/openstack/net-virt/src/main/java/org/opendaylight/ovsdb/openstack/netvirt/impl/NeutronL3Adapter.java#L367 [6]: https://gist.github.com/103de83f5dd04af41b25 [7]: table=60 … ip,reg3=0x429,nw_dst=10.2.0.0/24 actions=set_field:fa:16:3e:4b:f8:4f->eth_src,dec_ttl,set_field:0x429->tun_id,goto_table:70 [8]: https://gist.github.com/0257eaf97c82a7feca31 [9]: http://www.flaviof.com/blog/work/how-to-odl-with-openstack-part1.html (look for external_ids) |
|