[ovsdb-dev] Marcelo - Unit test for the networking-odl L3

Flavio Fernandes ffernand at redhat.com
Thu Jul 9 03:36:33 UTC 2015

> On Jul 7, 2015, at 10:31 AM, Marcelo Amaral <marcelo.amaral at bsc.es> wrote:
> Hi Flavio,
> I am looking at you implementation of floating ip, since Swami asked me to understand and document it.
> I have some questions. Would you mind helping me?

[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!

> - When a tenant assign a floating IP to a VM, will the openstack neutron odl plugin request the odl controller to create snat rules into OVS? 
>     (Are all the virtual network configuration going through the controller?)

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:
>             1 -  adding floatingIPArp: create FloatIpData mapping with OVS port, floating ip and tenant vm ip. 
>                     - The name of the method let me think that it is going to create ARP rules for the floating ip.
>                         However, I don't know if I am missing something, but, It is not creating a rule (table 20 in case). Is it done in another step, or it is not related?

Yes, absolutely. The arp rules to handle floating ips are done here [5].

>             2 -  creating the Inbound rule (ovs br, of br, floating ip, tenant vm ip). Here is where the magic happens :)
>                     - Does it write a rule in table 30? Do you have an example how will be the rule in the end?

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 rule
>                     - Does it write a rule in table 100? Do you have an example how will be the rule in the end?

Yes, 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.


— flavio

> Best regards,
> Marcelo Amaral

[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= 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)

More information about the ovsdb-dev mailing list