1. Messages
  2. rough agenda for L3 meeting

Re: rough agenda for L3 meeting

Keith Burns <alagalah@...>
 

Thanks mate! Yes, we do care about the routerID and saw it in the port create message too, so thanks for confirming.

We are leveraging our existing virtual router code from helium with some enhancements, more inline w associating a router with a VRF, but it wouldn't be hard to extend that to multiple routers, but you have to draw a line in the first integration somewhere :)

This is one of those OFP things where we have implemented similar functionality, so when I come up for air I'll publish same and we can compare approaches.

Thank you very much again!

Do you have any indication why we aren't doing the neutron API as a pass through as it was originally described? Ie security group, router CRUD? Ports should have UUID references to their neutron objects and not the objects themselves as described in the API documentation?

On Apr 15, 2015 6:35 AM, "Flavio Fernandes" <ffernand@...> wrote:


Hello folks,

Just wanted to give a follow up on the topic of creation of OVS port/interface for router interfaces: It is _not_ created at all. 

In other words, while Neutron ports are created to represent each of the interfaces of the router, when using ODL to perform L3 fwd we
do not create/use corresponding port/interfaces  on the OVS side. The router interface is ‘abstracted’ on each Openstack node by the
creation of openFlow1.3 rules that match on the prefix and rewrites the L2 mac and subnet (aka segmentation id, tunnId). For an example
of such, look at table 60 (lines 28-30) in this [1] example. That particular table is maintained by the RoutingService [2] in net-virt. 

It is my intention to publish info on the pipeline logic used in odl-ovsdb; so it is better known by the community; stay tuned. ;)

Just to be clear, this is only the case for router interfaces; not tenant vms. And this in the context of odl l3 fwd; not l3-agent that is used by
Openstack by default.

— flavio

PS: 
@Ed: @Keith: the ovsdb l3 fwd implementation does not care about mutiple routers for the same tenant, but it seems that what you are
planning to do does. For that sake, consider using the “device_id” field in the Neutron port to distinguish the router the interface belongs to.
Similar to SG groups, all the info needed is embedded in the Neutron port objects. I have no plans to chase after the missing router
add/remove events from Neutron in the near future.
Join {z.archive.ovsdb-dev@lists.opendaylight.org to automatically receive all group messages.