Operating System: All
Platform: All

Attachment karaf.log has been added with description: karaf log

Attachment controller_ovs.txt has been added with description: Ovs information from the controller node

Attachment compute_ovs.txt has been added with description: Compute ovs information

Please use bpvpn-router-assoc-create * commands.

Since you have subnets associated to routers, associate these routers to the same vpn and then try out ping between instances.

Thanks,
Abhinav

Please allow me to correct myself here.

1. As per the current implementation, we can associate only one router to a VPN.

2. For your use-case, upon router-create for each of the routers, internal VPNs will be created. So, upon doing a “bgpvpn-net-assoc-create” after that, you are essentially indicating for this network to be a part of:

a. The internal VPN previously created
AND
b. The new VPN it is being associated to.
This is rightfully not allowed, hence you do not see the ping to be successful.

So, either:

1. add both of the subnets to router via “router-interface-add” and then do a “bgpvpn-router-assoc-create”
OR
2. create networks with subnets and instances, then the VPNs, followed by “bgpvpn-net-assoc-create”. DO NOT add these subnets to the router via “router-interface-add”.

Hope this clarifies.

(In reply to Abhinav Gupta from comment #5)
> Please allow me to correct myself here.
>
> 1. As per the current implementation, we can associate only one router to a
> VPN.
>
> 2. For your use-case, upon router-create for each of the routers, internal
> VPNs will be created. So, upon doing a “bgpvpn-net-assoc-create” after that,
> you are essentially indicating for this network to be a part of:
>
> a. The internal VPN previously created
> AND
> b. The new VPN it is being associated to.
> This is rightfully not allowed, hence you do not see the ping to be
> successful.
> So, either:
>
> 1. add both of the subnets to router via “router-interface-add” and then do
> a “bgpvpn-router-assoc-create”
> OR

>
> Hope this clarifies.

I understand your points, but the openstack documentation states it like so:
Associating a BGPVPN to a Network can be done for both BGPVPN of type l2 and of type l3. For type L3, the semantic is that all Subnets bound to the Network will be interconnected with the BGP VPN (and thus between themselves).
http://docs.openstack.org/developer/networking-bgpvpn/api.html#network-association

It seems to me that limiting the network association depending on whether subnets have been added to routers breaks the semantics of net-assoc.
What I mean is that openstack promises that net-assoc will bind all the subnets to the VPN, but due to opendaylight constraints, this will fail silently, i.e. this bug.

Further down in the openstack docs however:
To avoid any ambiguity on semantics in particular the context of processing associated to a Router (e.g. NAT or FWaaS), if a said Subnet in a Network is bound to a Router, this API does not allow to both associate the Network to an L3 BGPVPN and the Router to the same or to a distinct L3 BGPVPN.

This is indeed in some way what you're saying, but not exactly. Network assoc should not happen if there is a router assoc. For opendaylight there is an internal router assoc so having a router means that network assoc will always fail.

I think that this same paragraph that explains the mutual exclusion of network and router association implies that network assoc should work for subnets attached to routers that don't participate in assocs, which is the gist of this bug.

> 2. create networks with subnets and instances, then the VPNs, followed by
> “bgpvpn-net-assoc-create”. DO NOT add these subnets to the router via
> “router-interface-add”.
Yes, if we do not create routers this case works for Boron.

(In reply to Romanos Skiadas from comment #6)
> (In reply to Abhinav Gupta from comment #5)
> > Please allow me to correct myself here.
> >
> > 1. As per the current implementation, we can associate only one router to a
> > VPN.
> >
> > 2. For your use-case, upon router-create for each of the routers, internal
> > VPNs will be created. So, upon doing a “bgpvpn-net-assoc-create” after that,
> > you are essentially indicating for this network to be a part of:
> >
> > a. The internal VPN previously created
> > AND
> > b. The new VPN it is being associated to.
> > This is rightfully not allowed, hence you do not see the ping to be
> > successful.
> > So, either:
> >
> > 1. add both of the subnets to router via “router-interface-add” and then do
> > a “bgpvpn-router-assoc-create”
> > OR
>
> >
> > Hope this clarifies.
>
> I understand your points, but the openstack documentation states it like so:
> Associating a BGPVPN to a Network can be done for both BGPVPN of type l2 and
> of type l3. For type L3, the semantic is that all Subnets bound to the
> Network will be interconnected with the BGP VPN (and thus between
> themselves).
> http://docs.openstack.org/developer/networking-bgpvpn/api.html#network-
> association
>
> It seems to me that limiting the network association depending on whether
> subnets have been added to routers breaks the semantics of net-assoc.
> What I mean is that openstack promises that net-assoc will bind all the
> subnets to the VPN, but due to opendaylight constraints, this will fail
> silently, i.e. this bug.
>
> Further down in the openstack docs however:
> To avoid any ambiguity on semantics in particular the context of processing
> associated to a Router (e.g. NAT or FWaaS), if a said Subnet in a Network is
> bound to a Router, this API does not allow to both associate the Network to
> an L3 BGPVPN and the Router to the same or to a distinct L3 BGPVPN.
>
> This is indeed in some way what you're saying, but not exactly. Network
> assoc should not happen if there is a router assoc. For opendaylight there
> is an internal router assoc so having a router means that network assoc will
> always fail.
>
> I think that this same paragraph that explains the mutual exclusion of
> network and router association implies that network assoc should work for
> subnets attached to routers that don't participate in assocs, which is the
> gist of this bug.
>
> > 2. create networks with subnets and instances, then the VPNs, followed by
> > “bgpvpn-net-assoc-create”. DO NOT add these subnets to the router via
> > “router-interface-add”.
> Yes, if we do not create routers this case works for Boron.

I totally agree with you. Due to ODL limitations, we are restricting ourselves here.
All along the implementation for Openstack/REST support for router/network(s) associations to VPN(s), this assumption was always taken into account.
I believe with this bug, we should look at enabling both:
a. L3 forwarding across subnets associated to the router.
b. L3 forwarding across network(s) associated to this VPN

Also, for associations/dissociations via REST APIs, we send out explicit detailed error logs, but for BGPVPN APIs, no error is being propagated. This also needs to be fixed.

Do we have progress on this bug?

(In reply to Nikolas Hermanns from comment #8)
> Do we have progress on this bug?

I don't think so, this was in unassigned state until today, and today has been assigned to me.
I don't see any fixes having gone in to take care of this..

Ah ok, that is now problem. But thanks that you look into that!

Hello, is there any news from this bug?

Old bug, will reopen if seen again