Hi Flavio,

Thank you very much!
I am carefully reading those references, and I will attempt to document them in the code.

Best,
Marcelo

On 09/07/15 05:36, Flavio Fernandes wrote:

On Jul 7, 2015, at 10:31 AM, Marcelo Amaral <marcelo.amaral@...> 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.

Best,

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

WARNING / LEGAL TEXT: This message is intended only for the use of the
individual or entity to which it is addressed and may contain
information which is privileged, confidential, proprietary, or exempt
from disclosure under applicable law. If you are not the intended
recipient or the person responsible for delivering the message to the
intended recipient, you are strictly prohibited from disclosing,
distributing, copying, or in any way using this message. If you have
received this communication in error, please notify the sender and
destroy and delete any copies you may have received.

http://www.bsc.es/disclaimer