subject:"\[openstack\-dev\] l2gw"

Re: [openstack-dev] l2gw

2017-10-12 Thread Lajos Katona


Hi,

I copy here the answer from Maruti Haridas Kamat (part of the team which 
originally designed networking-l2gw) to the question why this was 
originally designed this way (no update is possible if there is an 
active connection on the gw):

"

I understand your use case, and we thought about it when we were 
designing the solution.


 Consider you have an interface and a physical switch that is 
present inside a neutron logical l2gw, and create a connection, then you 
have already created VXLAN-to-VLAN bindings on that interface on the 
physical switch or OVS. If you allow a user to update the gateway to 
modify the interface or switch list, then we need to fiddle with the 
VXLAN-to-VLAN bindings on the switch (es).


Steps:

1. The user creates a logical gateway gw1 comprising of switch s1 and
   interface i1. No validation is performed here.
2. The user creates a connection VXLAN (1000) to physical VLAN (100)
   binding. This performs all the validation inside the DB where the
   specified switch s1 and interface i1 exist. Whether the specified
   binding already exists or not. Finally, the plugin communicates to
   the southbound (agent) that creates the binding 1000 <-> 100 on the
   interface i1 on the switch (OVS).
3. Consider that the user tries to add another interface i2 now to the
   same gateway gw1 using update gw1 command. It does not perform any
   validation. The entire validation we do in step 2 has to be moved to
   this step now. Also, the code (south bound) that makes changes on
   the OVS has to be introduced.
4. We avoided this because the user may try to add and remove the
   interfaces in one go in the same command. If we had to allow update
   connection command, then internally we have to perform binding of
   vxlan with vlan for interface i2 but we have to remove the binding
   from i1 (considering i1 has been removed from the gw1) at the same time.
5. It is not that it is not possible, but for the first version of L2gw
   in first six months, we thought of supporting basic framework of all
   these CLIs/REST APIs and enhance them later.

"
It will not give too much extra, but perhaps good to see the reasoning 
from another perspective.


Regards Lajos

On 2017-10-12 01:55, Dayavanti Gopal Kamath wrote:


Hi ricardo,

Since the l2gw connection semantics is applied on the l2gw object as a 
whole, we could assume any connections applied on the l2gw object can 
be retroactively applied to the ports that are affected by the the 
l2gw update. so, if a port is added to an existing l2gw, all existing 
l2gw connections get applied on that port, and if a port is deleted 
from an l2gw, all existing l2gw connections get removed from this port.


Thanks,

daya

*From:*Ricardo Noriega De Soto [mailto:rnori...@redhat.com]
*Sent:* Tuesday, October 10, 2017 6:14 AM
*To:* OpenStack Development Mailing List (not for usage questions) 

*Cc:* Gary Kotton ; Ihar Hrachyshka 
; arma...@gmail.com; miguel.lava...@huawei.com; 
Luis Tomas Bolivar ; maruti.ka...@radisys.com; 
Lajos Katona ; Dayavanti Gopal Kamath 
; George Offord 


*Subject:* Re: [openstack-dev] l2gw

I've been taking a look at the implementation and thinking about which 
cases update should be allowed.


At a first glance, I would say that we should allow updates:

·Add a new interface (neutron l2-gateway-update gw1 --device 
name=hwvtep,interface_names=eth0,*eth1*) being eth1 the new interface.


·Delete interface (neutron l2-gateway-update gw1 --device 
name=hwvtep,interface_names=eth0) removing eth1. In this case, we 
should check that the port has not any active connection.


However, in both cases there is a big issue, which is the granularity 
of the segmentation-ids per port, right?? You cannot add or remove an 
l2gw connection per port, which bring us to a dead end.


Let's say I add eth1 to an existing l2gw. How can I get a vlan tag to 
that interface?? There is not l2gw-connection-update command... and 
trying to create the same one will fail. Even if you try to update the 
l2gw instance specifying the seg-id per port, it won't be active until 
a new connection is created.


Folks, based on your experience, what's your take on this??

IMHO, there is no easy way of solving this but with a big re-architecture.

On Fri, Sep 29, 2017 at 1:46 PM, Lajos Katona 
mailto:lajos.kat...@ericsson.com>> wrote:


Hi Ricardo,

That is the exception which gives us the trouble.

If you have ideas as you mentioned in which case a gw should be
updated, and in what not, that would be really nice.
Actually now we have a kind of development environment with
devstack and vtep emulator
(http://docs.openvswitch.org/en/latest/howto/vtep/) on the same
host, what do you think is that enough to go on with this problem?
I am not so sure if with vtep emulator we can cover all the good
and bad (I mean when we mustn't do the update for example) scenarios.

Rega

Re: [openstack-dev] l2gw

2017-10-10 Thread Ricardo Noriega De Soto

I've been taking a look at the implementation and thinking about which
cases update should be allowed.

At a first glance, I would say that we should allow updates:


   - Add a new interface (neutron l2-gateway-update gw1 --device
   name=hwvtep,interface_names=eth0,*eth1*) being eth1 the new interface.
   - Delete interface (neutron l2-gateway-update gw1 --device
   name=hwvtep,interface_names=eth0) removing eth1. In this case, we should
   check that the port has not any active connection.

However, in both cases there is a big issue, which is the granularity of
the segmentation-ids per port, right?? You cannot add or remove an l2gw
connection per port, which bring us to a dead end.

Let's say I add eth1 to an existing l2gw. How can I get a vlan tag to that
interface?? There is not l2gw-connection-update command... and trying to
create the same one will fail. Even if you try to update the l2gw instance
specifying the seg-id per port, it won't be active until a new connection
is created.

Folks, based on your experience, what's your take on this??

IMHO, there is no easy way of solving this but with a big re-architecture.

On Fri, Sep 29, 2017 at 1:46 PM, Lajos Katona 
wrote:

> Hi Ricardo,
>
> That is the exception which gives us the trouble.
>
> If you have ideas as you mentioned in which case a gw should be updated,
> and in what not, that would be really nice.
> Actually now we have a kind of development environment with devstack and
> vtep emulator (http://docs.openvswitch.org/en/latest/howto/vtep/) on the
> same host, what do you think is that enough to go on with this problem?
> I am not so sure if with vtep emulator we can cover all the good and bad
> (I mean when we mustn't do the update for example) scenarios.
>
> Regards
> Lajos
>
>
> On 2017-09-28 14:12, Ricardo Noriega De Soto wrote:
>
> I see the exception now Lajos:
>
> class L2GatewayInUse(exceptions.InUse):
> message = _("L2 Gateway '%(gateway_id)s' still has active mappings "
> "with one or more neutron networks.")
>
> :-)
>
> On Wed, Sep 27, 2017 at 6:40 PM, Ricardo Noriega De Soto <
> rnori...@redhat.com> wrote:
>
>> Hey Lajos,
>>
>> Is this the exception you are encountering?
>>
>> (neutron) l2-gateway-update --device name=hwvtep,interface_names=eth0,eth1
>> gw1
>> L2 Gateway 'b8ef7f98-e901-4ef5-b159-df53364ca996' still has active
>> mappings with one or more neutron networks.
>> Neutron server returns request_ids: ['req-f231dc53-cb7d-4221-ab74-
>> fa8715f85869']
>>
>> I don't see the L2GatewayInUse exception you're talking about, but I
>> guess it's the same situation.
>>
>> We should discuss in which case the l2gw instance could be updated, and
>> in which cases it shouldn't.
>>
>> Please, let me know!
>>
>>
>>
>> On Wed, Aug 16, 2017 at 11:14 AM, Lajos Katona > > wrote:
>>
>>> Hi,
>>>
>>> We faced an issue with l2-gw-update, which means that actually if there
>>> are connections for a gw the update will throw an exception
>>> (L2GatewayInUse), and the update is only possible after deleting first the
>>> connections, do the update and add the connections back.
>>>
>>> It is not exactly clear why this restriction is there in the code (at
>>> least I can't find it in docs or comments in the code, or review).
>>> As I see the check for network connections was introduced in this patch:
>>> https://review.openstack.org/#/c/144097 (https://review.openstack.org/
>>> #/c/144097/21..22/networking_l2gw/db/l2gateway/l2gateway_db.py)
>>>
>>> Could you please give me a little background why the update operation is
>>> not allowed on an l2gw with network connections?
>>>
>>> Thanks in advance for the help.
>>>
>>> Regards
>>> Lajos
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> --
>> Ricardo Noriega
>>
>> Senior Software Engineer - NFV Partner Engineer | Office of Technology
>>  | Red Hat
>> irc: rnoriega @freenode
>>
>>
>
>
> --
> Ricardo Noriega
>
> Senior Software Engineer - NFV Partner Engineer | Office of Technology  |
> Red Hat
> irc: rnoriega @freenode
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Ricardo Noriega

Senior Software Engineer - NFV Partner Engineer | Office of Technology  |
Red Hat
irc: rnoriega @fre

Re: [openstack-dev] l2gw

2017-09-29 Thread Lajos Katona


Hi Ricardo,

That is the exception which gives us the trouble.

If you have ideas as you mentioned in which case a gw should be updated, 
and in what not, that would be really nice.
Actually now we have a kind of development environment with devstack and 
vtep emulator (http://docs.openvswitch.org/en/latest/howto/vtep/) on the 
same host, what do you think is that enough to go on with this problem?
I am not so sure if with vtep emulator we can cover all the good and bad 
(I mean when we mustn't do the update for example) scenarios.


Regards
Lajos

On 2017-09-28 14:12, Ricardo Noriega De Soto wrote:

I see the exception now Lajos:

class L2GatewayInUse(exceptions.InUse):
    message = _("L2 Gateway '%(gateway_id)s' still has active mappings "
                "with one or more neutron networks.")

:-)

On Wed, Sep 27, 2017 at 6:40 PM, Ricardo Noriega De Soto 
mailto:rnori...@redhat.com>> wrote:


Hey Lajos,

Is this the exception you are encountering?

(neutron) l2-gateway-update --device
name=hwvtep,interface_names=eth0,eth1 gw1
L2 Gateway 'b8ef7f98-e901-4ef5-b159-df53364ca996' still has active
mappings with one or more neutron networks.
Neutron server returns request_ids:
['req-f231dc53-cb7d-4221-ab74-fa8715f85869']

I don't see the L2GatewayInUse exception you're talking about, but
I guess it's the same situation.

We should discuss in which case the l2gw instance could be
updated, and in which cases it shouldn't.

Please, let me know!



On Wed, Aug 16, 2017 at 11:14 AM, Lajos Katona
mailto:lajos.kat...@ericsson.com>> wrote:

Hi,

We faced an issue with l2-gw-update, which means that actually
if there are connections for a gw the update will throw an
exception (L2GatewayInUse), and the update is only possible
after deleting first the connections, do the update and add
the connections back.

It is not exactly clear why this restriction is there in the
code (at least I can't find it in docs or comments in the
code, or review).
As I see the check for network connections was introduced in
this patch:
https://review.openstack.org/#/c/144097


(https://review.openstack.org/#/c/144097/21..22/networking_l2gw/db/l2gateway/l2gateway_db.py

)

Could you please give me a little background why the update
operation is not allowed on an l2gw with network connections?

Thanks in advance for the help.

Regards
Lajos


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





-- 
Ricardo Noriega


Senior Software Engineer - NFV Partner Engineer | Office of
Technology  | Red Hat
irc: rnoriega @freenode




--
Ricardo Noriega

Senior Software Engineer - NFV Partner Engineer | Office of Technology 
 | Red Hat

irc: rnoriega @freenode



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] l2gw

2017-09-28 Thread Ricardo Noriega De Soto

I see the exception now Lajos:

class L2GatewayInUse(exceptions.InUse):
message = _("L2 Gateway '%(gateway_id)s' still has active mappings "
"with one or more neutron networks.")

:-)

On Wed, Sep 27, 2017 at 6:40 PM, Ricardo Noriega De Soto <
rnori...@redhat.com> wrote:

> Hey Lajos,
>
> Is this the exception you are encountering?
>
> (neutron) l2-gateway-update --device name=hwvtep,interface_names=eth0,eth1
> gw1
> L2 Gateway 'b8ef7f98-e901-4ef5-b159-df53364ca996' still has active
> mappings with one or more neutron networks.
> Neutron server returns request_ids: ['req-f231dc53-cb7d-4221-ab74-
> fa8715f85869']
>
> I don't see the L2GatewayInUse exception you're talking about, but I guess
> it's the same situation.
>
> We should discuss in which case the l2gw instance could be updated, and in
> which cases it shouldn't.
>
> Please, let me know!
>
>
>
> On Wed, Aug 16, 2017 at 11:14 AM, Lajos Katona 
> wrote:
>
>> Hi,
>>
>> We faced an issue with l2-gw-update, which means that actually if there
>> are connections for a gw the update will throw an exception
>> (L2GatewayInUse), and the update is only possible after deleting first the
>> connections, do the update and add the connections back.
>>
>> It is not exactly clear why this restriction is there in the code (at
>> least I can't find it in docs or comments in the code, or review).
>> As I see the check for network connections was introduced in this patch:
>> https://review.openstack.org/#/c/144097 (https://review.openstack.org/
>> #/c/144097/21..22/networking_l2gw/db/l2gateway/l2gateway_db.py)
>>
>> Could you please give me a little background why the update operation is
>> not allowed on an l2gw with network connections?
>>
>> Thanks in advance for the help.
>>
>> Regards
>> Lajos
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Ricardo Noriega
>
> Senior Software Engineer - NFV Partner Engineer | Office of Technology  |
> Red Hat
> irc: rnoriega @freenode
>
>


-- 
Ricardo Noriega

Senior Software Engineer - NFV Partner Engineer | Office of Technology  |
Red Hat
irc: rnoriega @freenode
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] l2gw

2017-09-27 Thread Ricardo Noriega De Soto

Hey Lajos,

Is this the exception you are encountering?

(neutron) l2-gateway-update --device name=hwvtep,interface_names=eth0,eth1
gw1
L2 Gateway 'b8ef7f98-e901-4ef5-b159-df53364ca996' still has active mappings
with one or more neutron networks.
Neutron server returns request_ids:
['req-f231dc53-cb7d-4221-ab74-fa8715f85869']

I don't see the L2GatewayInUse exception you're talking about, but I guess
it's the same situation.

We should discuss in which case the l2gw instance could be updated, and in
which cases it shouldn't.

Please, let me know!

On Wed, Aug 16, 2017 at 11:14 AM, Lajos Katona 
wrote:

> Hi,
>
> We faced an issue with l2-gw-update, which means that actually if there
> are connections for a gw the update will throw an exception
> (L2GatewayInUse), and the update is only possible after deleting first the
> connections, do the update and add the connections back.
>
> It is not exactly clear why this restriction is there in the code (at
> least I can't find it in docs or comments in the code, or review).
> As I see the check for network connections was introduced in this patch:
> https://review.openstack.org/#/c/144097 (https://review.openstack.org/
> #/c/144097/21..22/networking_l2gw/db/l2gateway/l2gateway_db.py)
>
> Could you please give me a little background why the update operation is
> not allowed on an l2gw with network connections?
>
> Thanks in advance for the help.
>
> Regards
> Lajos
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

-- 
Ricardo Noriega

Senior Software Engineer - NFV Partner Engineer | Office of Technology  |
Red Hat
irc: rnoriega @freenode
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] l2gw

2017-08-16 Thread Lajos Katona


Hi,

We faced an issue with l2-gw-update, which means that actually if there 
are connections for a gw the update will throw an exception 
(L2GatewayInUse), and the update is only possible after deleting first 
the connections, do the update and add the connections back.


It is not exactly clear why this restriction is there in the code (at 
least I can't find it in docs or comments in the code, or review).

As I see the check for network connections was introduced in this patch:
https://review.openstack.org/#/c/144097 
(https://review.openstack.org/#/c/144097/21..22/networking_l2gw/db/l2gateway/l2gateway_db.py)


Could you please give me a little background why the update operation is 
not allowed on an l2gw with network connections?


Thanks in advance for the help.

Regards
Lajos

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [l2gw] How to handle correctly unknown-dst traffic

2017-08-15 Thread Saverio Proto

> The ucast-mac-remote table is filled with information that don't match
> your comments. In my environment, I have created only one neutron
> network, one l2gw instance and one l2gw connection. However, the mac
> reflected in that table corresponds to the dhcp port of the Neutron
> network (I've checked the mac on the dhcp namespace and it's the same).
> I've created several VMs in different compute nodes and there is only
> one line there. Could you check again the MAC address?

Hello,

I confirm I have one line per VM

root@l2gw-0:/# vtep-ctl list-remote-macs
ee87db33-1b3a-42e9-bc09-02747f8a0ad5
ucast-mac-remote
  fa:16:3e:6b:6e:d1 -> vxlan_over_ipv4/10.1.1.161
  fa:16:3e:7f:18:77 -> vxlan_over_ipv4/10.1.0.126
  fa:16:3e:90:7f:f9 -> vxlan_over_ipv4/10.1.1.177
  fa:16:3e:c2:7b:da -> vxlan_over_ipv4/10.1.1.167
  fa:16:3e:ca:ad:c6 -> vxlan_over_ipv4/10.1.0.126
  fa:16:3e:f0:21:01 -> vxlan_over_ipv4/10.1.1.175

I have the indication of the mac address of the VM, and the IP address
of the hypervisor where it is hosted.


> In my setup I get this automatically:
> 
> mcast-mac-remote
>   unknown-dst -> vxlan_over_ipv4/192.0.2.6 
> 
> If you're using the agent, it might be a bug.

I am running Openstack Newton, on what version is based your PoC ?

thank you

Saverio


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [l2gw] Adding TripleO CI jobs as part of networking-l2gw checks

2017-07-10 Thread Ricardo Noriega De Soto

Please L2GWers, review the following  patch:

https://review.openstack.org/#/c/480641/

It seems we can benefit from TripleO coverage to have L2GW service plugin
deployed in production-like deployments.

Cheers

-- 
Ricardo Noriega

Senior Software Engineer - NFV Partner Engineer | Office of Technology  |
Red Hat
irc: rnoriega @freenode
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [l2gw] [neutron] [qa] Networking-l2gw Tempest plugin split out

2017-07-06 Thread Ricardo Noriega De Soto

Hello L2GWers!

Following the community goal for Queens to split in-tree tempest plugins to
a separate repo, I will perform this task in the following days. So please,
if anyone has got any concern, reply this email.

Cheers

-- 
Ricardo Noriega

Senior Software Engineer - NFV Partner Engineer | Office of Technology  |
Red Hat
irc: rnoriega @freenode
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [l2gw] How to handle correctly unknown-dst traffic

2017-06-23 Thread Ricardo Noriega De Soto

Hi Saverio,

Comments and questions inline:

First of all, which backend are you using? the l2gateway agent? or
something like OpenDaylight?? I'm currently testing an L2GW scenario with
ODL.


On Mon, May 29, 2017 at 4:54 PM, Saverio Proto 
wrote:

> Hello,
>
> I have a question about the l2gw. I did a deployment, I described the
> steps here:
> https://review.openstack.org/#/c/453209/
>
> The unicast traffic works fine, but I dont understand what is the idea
> behind the handling of the broadcast traffic.
>
> Looking at openvswitch:
>
> I obtain the uuid with `vtep-ctl list-ls`
>
> vtep-ctl list-remote-macs 
>
> In this output I get an entry for each VM that has an interface in the
> L2 network I am bridging:
>
> 
> # vtep-ctl list-remote-macs 
> ucast-mac-remote
>   fa:16:3e:c2:7b:da -> vxlan_over_ipv4/10.1.1.167
>
> mcast-mac-remote
> -
>

The ucast-mac-remote table is filled with information that don't match your
comments. In my environment, I have created only one neutron network, one
l2gw instance and one l2gw connection. However, the mac reflected in that
table corresponds to the dhcp port of the Neutron network (I've checked the
mac on the dhcp namespace and it's the same).
I've created several VMs in different compute nodes and there is only one
line there. Could you check again the MAC address?


>
> The ucast-mac-remote entry is created by Openstack when I start a VM.
> (Also it is never removed when I delete the instance, is this a bug ? )
> Note that 10.1.1.167 is the IP address of the hypervisor where the VM is
> running.
>
> But mcast-mac-remote is empty. So this means that ARP learning for
> example works only in 1 way. The VM in openstack does not receive any
> broadcast traffic, unless I do manually:
>
> vtep-ctl add-mcast-remote ee87db33-1b3a-42e9-bc09-02747f8a0ad5
> unknown-dst  10.1.1.167
>
> This creates an entry in the table mcast-mac-remote and everything works
> correctly.
>

In my setup I get this automatically:

mcast-mac-remote
  unknown-dst -> vxlan_over_ipv4/192.0.2.6

If you're using the agent, it might be a bug.


>
>
> Now I read here http://networkop.co.uk/blog/2016/05/21/neutron-l2gw/
> about sending add-mcast-remote to the network nodes and then doing some
> magic I dont really understand. But I am confused because in my setup
> the tenant does not have a L3 router, so there is not a qrouter
> namespace for this network, I was planning to keep the network node out
> of the game.
>
> Is anyone running this in production and can shed some light ?
>

No production sorry, just PoC mode :-)

>
> thanks
>
> Saverio
>
>
>
>
>
>
>
>
>
>
>
> --
> SWITCH
> Saverio Proto, Peta Solutions
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
> phone +41 44 268 15 15, direct +41 44 268 1573
> saverio.pr...@switch.ch, http://www.switch.ch
>
> http://www.switch.ch/stories
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Ricardo Noriega

Senior Software Engineer - NFV Partner Engineer | Office of Technology  |
Red Hat
irc: rnoriega @freenode
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [l2gw] How to handle correctly unknown-dst traffic

2017-06-19 Thread Saverio Proto

Hello,

I try again. Any l2gw plugin user that wants to comment on my email ?

thank you

Saverio


On 29/05/17 16:54, Saverio Proto wrote:
> Hello,
> 
> I have a question about the l2gw. I did a deployment, I described the
> steps here:
> https://review.openstack.org/#/c/453209/
> 
> The unicast traffic works fine, but I dont understand what is the idea
> behind the handling of the broadcast traffic.
> 
> Looking at openvswitch:
> 
> I obtain the uuid with `vtep-ctl list-ls`
> 
> vtep-ctl list-remote-macs 
> 
> In this output I get an entry for each VM that has an interface in the
> L2 network I am bridging:
> 
> 
> # vtep-ctl list-remote-macs 
> ucast-mac-remote
>   fa:16:3e:c2:7b:da -> vxlan_over_ipv4/10.1.1.167
> 
> mcast-mac-remote
> -
> 
> The ucast-mac-remote entry is created by Openstack when I start a VM.
> (Also it is never removed when I delete the instance, is this a bug ? )
> Note that 10.1.1.167 is the IP address of the hypervisor where the VM is
> running.
> 
> But mcast-mac-remote is empty. So this means that ARP learning for
> example works only in 1 way. The VM in openstack does not receive any
> broadcast traffic, unless I do manually:
> 
> vtep-ctl add-mcast-remote ee87db33-1b3a-42e9-bc09-02747f8a0ad5
> unknown-dst  10.1.1.167
> 
> This creates an entry in the table mcast-mac-remote and everything works
> correctly.
> 
> 
> Now I read here http://networkop.co.uk/blog/2016/05/21/neutron-l2gw/
> about sending add-mcast-remote to the network nodes and then doing some
> magic I dont really understand. But I am confused because in my setup
> the tenant does not have a L3 router, so there is not a qrouter
> namespace for this network, I was planning to keep the network node out
> of the game.
> 
> Is anyone running this in production and can shed some light ?
> 
> thanks
> 
> Saverio
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 


-- 
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 1573
saverio.pr...@switch.ch, http://www.switch.ch

http://www.switch.ch/stories

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [l2gw] How to handle correctly unknown-dst traffic

2017-05-29 Thread Saverio Proto

Hello,

I have a question about the l2gw. I did a deployment, I described the
steps here:
https://review.openstack.org/#/c/453209/

The unicast traffic works fine, but I dont understand what is the idea
behind the handling of the broadcast traffic.

Looking at openvswitch:

I obtain the uuid with `vtep-ctl list-ls`

vtep-ctl list-remote-macs 

In this output I get an entry for each VM that has an interface in the
L2 network I am bridging:


# vtep-ctl list-remote-macs 
ucast-mac-remote
  fa:16:3e:c2:7b:da -> vxlan_over_ipv4/10.1.1.167

mcast-mac-remote
-

The ucast-mac-remote entry is created by Openstack when I start a VM.
(Also it is never removed when I delete the instance, is this a bug ? )
Note that 10.1.1.167 is the IP address of the hypervisor where the VM is
running.

But mcast-mac-remote is empty. So this means that ARP learning for
example works only in 1 way. The VM in openstack does not receive any
broadcast traffic, unless I do manually:

vtep-ctl add-mcast-remote ee87db33-1b3a-42e9-bc09-02747f8a0ad5
unknown-dst  10.1.1.167

This creates an entry in the table mcast-mac-remote and everything works
correctly.


Now I read here http://networkop.co.uk/blog/2016/05/21/neutron-l2gw/
about sending add-mcast-remote to the network nodes and then doing some
magic I dont really understand. But I am confused because in my setup
the tenant does not have a L3 router, so there is not a qrouter
namespace for this network, I was planning to keep the network node out
of the game.

Is anyone running this in production and can shed some light ?

thanks

Saverio











-- 
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 1573
saverio.pr...@switch.ch, http://www.switch.ch

http://www.switch.ch/stories

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] l2gw

Re: [openstack-dev] l2gw

Re: [openstack-dev] l2gw

Re: [openstack-dev] l2gw

Re: [openstack-dev] l2gw

[openstack-dev] l2gw

Re: [openstack-dev] [l2gw] How to handle correctly unknown-dst traffic

[openstack-dev] [l2gw] Adding TripleO CI jobs as part of networking-l2gw checks

[openstack-dev] [l2gw] [neutron] [qa] Networking-l2gw Tempest plugin split out

Re: [openstack-dev] [l2gw] How to handle correctly unknown-dst traffic

Re: [openstack-dev] [l2gw] How to handle correctly unknown-dst traffic

[openstack-dev] [l2gw] How to handle correctly unknown-dst traffic

12 matches

Site Navigation

Mail list logo

Footer information