[ovs-discuss] OVN: MAC_Binding entries not getting updated leads to unreachable destinations

[Daniel Alvarez Sanchez]

Hi all,

While analyzing a problem in OpenStack I think I have found out a
severe bug in OVN when it comes to reuse floating IPs (which is a very
common use case in OpenStack and Kubernetes). Let me explain the
scenario, issue and possible solutions:

* Three logical switches  (Neutron networks) LS1, LS2, LS3
* LS3 has external connectivity (localnet port to a provider bridge).
* Two logical routers LR1 and LR2.
* LS1 and LS3 connected to LR1
* LS2 and LS3 connected to LR2.
* VM1 in LS1 with a FIP (dnat_and_snat NAT entry) in LS3 CIDR
* VM2 in LS2 with a FIP (dnat_and_snat NAT entry) in LS3 CIDR
* Ping from VM1 to VM2 FIP and viceversa works.

Echo requests from VM1 reach to VM2 and VM2 responds to the FIP of VM1.
First time, ovn-controller will insert the ARP responder and add a new
entry to MAC_Binding table like:

_uuid   : 447eaf43-119a-43b2-a821-0c79d8885d68
datapath: 07a76c72-6896-464a-8683-3df145d02434
ip  : "172.24.5.13"
logical_port: "lrp-82af833f-f78b-4f45-9fc8-719db0f9e619"
mac : "fa:16:3e:22:6c:0a"

|binding|INFO|cr-lrp-198e5576-b654-4605-80c0-b9cf6d21ea2b: Claiming
fa:16:3e:22:6c:0a 172.24.5.4/24

The problem happens when VM1, LS1, LR1 entry are deleted and recreated
again. If the FIP (172.24.5.13) is reused, the MAC_Binding entry won't
get updated and VM2 will be now unable to respond to pings coming from
VM1 as it'll attempt to do it to fa:16:3e:22:6c:0a.

If I manually delete the MAC_Binding entry, a new one will then
correctly be recreated by ovn-controller with the right MAC address
(the one of the new cr-lrp).

|00126|binding|INFO|cr-lrp-f09b2186-1cb2-4e50-99a5-587f680db8ad:
Claiming fa:16:3e:14:48:20 172.24.5.6/24

_uuid   : dae11bdb-47d3-471e-8826-9aefb8572700
datapath: 07a76c72-6896-464a-8683-3df145d02434
ip  : "172.24.5.13"
logical_port: "lrp-82af833f-f78b-4f45-9fc8-719db0f9e619"
mac : "fa:16:3e:14:48:20"


Possible solutions:

1) Make ovn-controller (or ovn.-northd?) to update the MAC_Binding
entries whenever a new NAT row is created.

2) Send GARPs (I guess we're not doing this yet) whenever a LRP gets
bound to a chassis for all the nat_addresses that it has configured.

For 2), I guess that it would make MAC_Binding entries getting updated
automatically?

How does this sound?

Thanks a lot,
Daniel Alvarez
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] 40 Gbit Traffic Test Problem

[Ian Stokes]

On 10/25/2018 12:05 PM, Mehmet Yaren wrote:

Hi Ian,

We are using XL710 as below

argela@dsfc-ovs:~$ lspci

...

08:00.0 Ethernet controller: Intel Corporation Ethernet Controller XL710 
for 40GbE QSFP+ (rev 02)


08:00.1 Ethernet controller: Intel Corporation Ethernet Controller XL710 
for 40GbE QSFP+ (rev 02) ...




Ok, I assume its the XL710-QDA2 as that has 2 x 40Gb ports.

Have you tried the ports with another DPDK application such as Testpmd? 
Do you see 40Gb traffic being processed on the ports or is it still 
~10Gb in that DPDK application also?


From reading the tech docs on the card it seems the QSFP can be 
configured to run as 10Gb per port or 40 Gb per port so I'd like to 
clarify this first.


Our test setup is simple phy to phy test. We are using Trex to send 
traffic into our DPDK based OvS with XL710. It is a basic loopback 
setup. We can see ~10Gbps at most on OvS even though our CPUs usage are 
below than %25. OvS drops remaining traffic after ~10Gb. In addition, 
even if we use just one CPU in OvS, we see the same traffic ~10Gb. Why 
does more CPU count not increase our traffic handling?  Our 
configuration is as follows:


Out of interest, what is the profile of  the test traffic?

Thanks
Ian


argela@dsfc-ovs:~$ sudo ovs-ofctl dump-flows br0  cookie=0x0, 
duration=135.441s, table=0, n_packets=38181256, n_bytes=6251887265, 
priority=50,ip,in_port=dpdk0,nw_dst=10.0.0.0/16 
actions=mod_dl_dst:3c:fd:fe:a8:23:e0,output:dpdk1 



  cookie=0x0, duration=128.913s, table=0, n_packets=14099677, 
n_bytes=8482650942, priority=50,ip,in_port=dpdk1,nw_dst=10.0.0.0/16 
actions=mod_dl_dst:3c:fd:fe:a8:23:e1,output:dpdk0 



argela@dsfc-ovs:~$ sudo ovs-vsctl show

0ce5f427-33c6-4d79-a67c-b2a1c588c3e9

     Bridge "br0"

     Port "dpdk0"

Interface "dpdk0"

type: dpdk

options: {dpdk-devargs=":08:00.0", n_rxq="4"}

     Port "br0"

Interface "br0"

type: internal

     Port "dpdk1"

Interface "dpdk1"

type: dpdk

options: {dpdk-devargs=":08:00.1", n_rxq="4"}

argela@dsfc-ovs:~$ sudo ovs-appctl dpif-netdev/pmd-rxq-show pmd thread 
numa_id 0 core_id 0:


   isolated : true

   port: dpdk0 queue-id:  0  pmd usage: 25 %

pmd thread numa_id 1 core_id 1:

   isolated : true

   port: dpdk0 queue-id:  1  pmd usage: 25 %

pmd thread numa_id 0 core_id 2:

   isolated : true

   port: dpdk0 queue-id:  2  pmd usage: 23 %

pmd thread numa_id 1 core_id 3:

   isolated : true

   port: dpdk0 queue-id:  3  pmd usage: 26 %

pmd thread numa_id 0 core_id 4:

   isolated : true

   port: dpdk1 queue-id:  0  pmd usage:  9 %

pmd thread numa_id 1 core_id 5:

   isolated : true

   port: dpdk1 queue-id:  1  pmd usage: 10 %

pmd thread numa_id 0 core_id 6:

   isolated : true

   port: dpdk1 queue-id:  2  pmd usage:  9 %

pmd thread numa_id 1 core_id 7:

   isolated : true

   port: dpdk1 queue-id:  3  pmd usage: 10 %

Regards,
Mehmet.

Ian Stokes mailto:ian.sto...@intel.com>>, 24 Eki 
2018 Çar, 17:23 tarihinde şunu yazdı:


On 10/23/2018 1:02 PM, mehmetyaren wrote:
 > Hi,
 >
 > We want to send 40 Gbit traffic with t-rex traffic generator, we are
 > using 40 Gbit supported DPDK NIC, but when we generate traffic as 40
 > Gbit, it can not transmit all traffics just 10 Gbit traffic is
 > transmitted by DPDK NIC. We are using Open vSwitch 2.10.0 version
and
 > DPDK 17.11.2 version.

What type of NICs are being used in your setup?

 >
 > We made some configuration to increasing core number for dpdk
ports with
 > below commands;
 >
 > ovs-vsctl set interface dpdk0 options:n_rxq=4
 > other_config:pmd-rxq-affinity="0:0,1:1,2:2,3:3"
 >
 > ovs-vsctl set interface dpdk1 options:n_rxq=4
 > other_config:pmd-rxq-affinity="0:4,1:5,2:6,3:7"
 >
 > And we have seen all pmd capacities are not used by dpdk ports as
seen
 > below results;
 >
 > sudo ovs-appctl dpif-netdev/pmd-rxq-show pmd thread numa_id 0
core_id 0:
 >
 >    isolated : true
 >
 >    port: dpdk0 queue-id:  0  pmd usage: 19 %
 >
 > pmd thread numa_id 1 core_id 1:
 >
 >    isolated : true
 >
 >    port: dpdk0 queue-id:  1  pmd usage: 20 %
 >
 > pmd thread numa_id 0 core_id 2:
 >
 >    isolated : true
 >
 >    port: dpdk0 queue-id:  2  pmd usage: 20 %
 >
 > pmd thread numa_id 1 core_id 3:
 >
 >    isolated : true
 >
 >    port: dpdk0 queue-id:  3  pmd usage: 21 %
 >
 > pmd thread numa_id 0 core_id 4:
 >
 >    isolated : true
 >
 >    port: dpdk1 queue-id:  0  pmd usage: 13 %
 >
 > pmd thread numa_id 1 core_id 5:
 >
 >    isolated : tr

Re: [ovs-discuss] 40 Gbit Traffic Test Problem

[Gowrishankar Muthukrishnan]

On 10/25/18 4:35 PM, Mehmet Yaren wrote:
>
> Hi Ian,
>
>  
>
> We are using XL710 as below
>
>  
>
> argela@dsfc-ovs:~$ lspci
>
> ...
>
> 08:00.0 Ethernet controller: Intel Corporation Ethernet Controller
> XL710 for 40GbE QSFP+ (rev 02)
>
> 08:00.1 Ethernet controller: Intel Corporation Ethernet Controller
> XL710 for 40GbE QSFP+ (rev 02) ...
>
>  
>
> Our test setup is simple phy to phy test. We are using Trex to send
> traffic into our DPDK based OvS with XL710. It is a basic loopback
> setup. We can see ~10Gbps at most on OvS even though our CPUs usage
> are below than %25. OvS drops remaining traffic after ~10Gb. In
> addition, even if we use just one CPU in OvS, we see the same traffic
> ~10Gb. Why does more CPU count not increase our traffic handling?  Our
> configuration is as follows:
>
In your trex, are you sending multistream traffic (with L3/L4 header
variations) ?

Check if it helps throttling more packets into datapath by phy PMD (RSS).

Thanks.

-- 
Regards,
Gowrishankar M
gmuth...@redhat.com



pEpkey.asc
Description: application/pgp-keys
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Ovs DPDK VXLAN performance issue

[Ali KIRCA]

Hi,

I have a performance issue on vxlan tunnelling at dpdk built ovs platform. 
Bridge and port structure and other system informations  of both sides are 
shown below.

Our scenario is iperf load test between VM's, which are connected to br-int 
switches at both sides. Firstly I have route the traffic over vxlan tunnel 
ports then load test result is limited at ~100Mb/Sec. After that, I have 
changed the scenario by eliminating the vxlan tunnelling and routing the 
traffic directly to dpdk port by patch ports, then traffic goes up to 
~950Mb/Sec.

I think the problem points on the vxlan port behaviour of ovs switch. When the 
traffic is routed to vxlan port, system search's appropriate interface at 
kernel space then direct the packet dpdk ovs switch at user space. I guess, 
that flow consumes time and system resources.

Do you have an idea for overcoming that problem, may be some parameters or 
architectural changes.

Ovs structure :

Bridge "br-ex2"
Port "br-ex2-to-br-int"
Interface "br-ex2-to-br-int"
type: patch
options: {peer=br-int-to-lte}
Port "dpdk2"
Interface "dpdk2"
type: dpdk
Port "br-ex2"
Interface "br-ex2"
type: internal
Bridge br-int
Controller "tcp:192.168.10.187:6633"
is_connected: true
fail_mode: secure
Port br-int-to-lte
Interface br-int-to-lte
type: patch
options: {peer="br-ex2-to-br-int"}
Port br-int-to-adsl
Interface br-int-to-adsl
type: patch
options: {peer=br-ex-to-br-int}
Port vxlan-lte
Interface vxlan-lte
type: vxlan
options: {dst_port="4790", exts=gpe, "in_nshc1"=flow, 
"in_nshc2"=flow, "in_nshc3"=flow, "in_nshc4"=flow, in_nsi=flow, in_nsp=flow, 
key=flow, local_ip="192.168.10.112", "out_nshc1"=flow, "out_nshc2"=flow, 
"out_nshc3"=flow, "out_nshc4"=flow, out_nsi=flow, out_nsp=flow, remote_ip=flow}
Port br-int
Interface br-int
Port pf-wan-tab
Interface pf-wan-tab
Port pf-lan-tab
Interface pf-lan-tab
Port "dpdk0"
Interface "dpdk0"
type: dpdk

Huge Pages :

AnonHugePages:221184 kB
HugePages_Total:   2
HugePages_Free:1
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:1048576 kB

03:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection 
(rev 03)
04:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection 
(rev 03)
06:00.0 Ethernet controller: Intel Corporation Device 15e4 (rev 11)
06:00.1 Ethernet controller: Intel Corporation Device 15e4 (rev 11)
07:00.0 Ethernet controller: Intel Corporation Device 15e5 (rev 11)
07:00.1 Ethernet controller: Intel Corporation Device 15e5 (rev 11)

Operating System : Ubuntu 16.04 64bit server

Thank you

Ali Kırca


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] packet_type=legacy_l3 gre tunnel does not work

[Gregory Rose]

On 10/17/2018 6:06 AM, Yousong Zhou wrote:

On Wed, 17 Oct 2018 at 21:01, Yousong Zhou  wrote:
...

ovs-vsctl add-port br0 tun0 -- set interface tun0 type=gre
options:remote_ip=flow options:key=flow options:packet_type=legacy_l2
ofport_request=2

Pasted the wrong line.  packet_type=legacy_l3 works.
packet_type=legacy_l3 did not.

ovs-vsctl add-port br0 tun0 -- set interface tun0 type=gre
options:remote_ip=flow options:key=flow options:packet_type=legacy_l3
ofport_request=2

I also tried substitute type=gre with vxlan, stt, geneve, with
packet_type=legacy_l3 unchanged, they all just silently dropped the
traffic.


What is generating the layer 3 traffic?  I looked at scapy but it seems 
to insist on adding L2 Ethernet

headers and I haven't found a way around that.

Thanks,

- Greg



 yousong
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] packet_type=legacy_l3 gre tunnel does not work

[Gregory Rose]

On 10/26/2018 10:26 AM, Gregory Rose wrote:

On 10/17/2018 6:06 AM, Yousong Zhou wrote:
On Wed, 17 Oct 2018 at 21:01, Yousong Zhou  
wrote:

...

ovs-vsctl add-port br0 tun0 -- set interface tun0 type=gre
options:remote_ip=flow options:key=flow options:packet_type=legacy_l2
ofport_request=2

Pasted the wrong line.  packet_type=legacy_l3 works.
packet_type=legacy_l3 did not.

ovs-vsctl add-port br0 tun0 -- set interface tun0 type=gre
options:remote_ip=flow options:key=flow options:packet_type=legacy_l3
ofport_request=2

I also tried substitute type=gre with vxlan, stt, geneve, with
packet_type=legacy_l3 unchanged, they all just silently dropped the
traffic.


What is generating the layer 3 traffic?  I looked at scapy but it 
seems to insist on adding L2 Ethernet

headers and I haven't found a way around that.


Nevermind - I figured that out.  This is a bug but I think it's a bug 
only in the Linux kernel datapath because
OVS never sends the netlink message to set the netlink parm for 
IFLA_GRE_COLLECT_METADATA.
Instead, the metadata flag is just set on creation and then that's it.  
Even though the code explicitly

indicates that for metadata mode tunnels the type should be ARPHRD_NONE.

I think the userspace datapath would work but I haven't had time to 
check it.


Thanks for finding this bug!!  We appreciate it when someone takes the 
time to help us out and find

problems in OVS.

I'll begin investigating a fix.

I'm working on the master branch which is OVS 2.10.  The solution for 
2.10 might not be the same for
the 2.8.4 release you're working with so it will probably take 
additional backporting to fix that release.

But at least we know what the problem is.

Thanks again!

- Greg



Thanks,

- Greg



 yousong
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss




___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] ovs openflow question

[Bo Yu]

Hi,

How to easily add a flow to block port 1 to port 2 traffic assuming 
there are 5 ports ? Do I have to explicitly specify 'actions=3,4,5' ?


How to easily add a flow for a 'NOT EQUAL' logic ? I am very surprised 
that 'inverse logic' is not supported in any openflow spec and ovs 
extension.


We are migrating from ebtables rules to ovs openflow but a lot of headache.

Thanks.

Bo



Ce courriel et les documents qui lui sont joints sont, sauf mention contraire, 
présumés de nature confidentielle et destinées à l'usage exclusif du ou des 
destinataire(s) mentionné(s). Si vous n'êtes pas le ou les destinataire(s), 
vous êtes informé(e) que toute divulgation, reproduction, distribution, toute 
autre diffusion ou utilisation de cette communication ou de tout ou partie de 
ces informations est strictement interdite, sauf accord préalable de 
l’expéditeur. Si ce message vous a été transmis par erreur, merci 
d’immédiatement en informer l'expéditeur et supprimer de votre système 
informatique ce courriel ainsi que tous les documents qui y sont attachés. En 
vous remerciant de votre  coopération.


This email and any attached documents are, unless otherwise stated, presumed to 
be confidential and intended for the exclusive use of the recipient(s) 
mentioned. If you are not the recipient(s), you are informed that any 
disclosure, reproduction, distribution, any other dissemination or use of this 
communication or all or part of this information is strictly prohibited, unless 
agreed beforehand by the sender. If you have received this e-mail in error, 
please immediately advise the sender and delete this e-mail and all the 
attached documents from your computer system. Thanking you for your cooperation.

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Why 10 Mbps?

[Sterdnot Shaken]

Why is it that vnic ports show as having a speed of 10 Mbps under the
command ovs-ofctl dump-ports-desc ?

I've done many tests and the 10 Mbps value obviously has no implications on
actual throughput for the OVS bridges. I was just curious why 10 Mbps...
It's a default apparently? How would I change that if I wanted too?

Thanks in advance!

Steve
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Problems executing decap(eth)+encap(eth) actions

[Gregory Rose]

On 10/19/2018 1:39 AM, Jaime Caamaño Ruiz wrote:

Hello

When using nsh encapsulation, it's useful to normalize your pipeline to
packet_type=nsh, poping an ethernet header on input if necessary and
pushing an ethernet header again if required before output.

But it seems to be problematic:

---
2018-10-18T13:10:59.196Z|00010|dpif(handler3)|WARN|system@ovs-system:
execute pop_eth,push_eth(src=fe:16:3e:c1:9e:87,dst=fa:16:3e:c1:9e:87),5
failed (Invalid argument) on packet
vlan_tci=0x,dl_src=fa:16:3e:c2:e6:68,dl_dst=fe:16:3e:c2:e6:68,dl_ty
pe=0x894f,nsh_flags=0,nsh_ttl=63,nsh_mdtype=1,nsh_np=3,nsh_spi=0x1a,nsh
_si=254,nsh_c1=0xc0a82a01,nsh_c2=0x3,nsh_c3=0x0,nsh_c4=0x9100,nw_pr
oto=0,nw_tos=0,nw_ecn=0,nw_ttl=0
  with metadata
skb_priority(0),tunnel(tun_id=0x0,src=192.168.42.1,dst=192.168.42.3,ttl
=64,tp_src=47656,tp_dst=4789,flags(key)),skb_mark(0),in_port(4) mtu 0
---

Looking at the code datapath/flow_netlink.c @ __ovs_nla_copy_actions:

 case OVS_ACTION_ATTR_PUSH_ETH:
 /* Disallow pushing an Ethernet header if one
  * is already present */
 if (mac_proto != MAC_PROTO_NONE)
 return -EINVAL;
 mac_proto = MAC_PROTO_NONE;
 break;

 case OVS_ACTION_ATTR_POP_ETH:
 if (mac_proto != MAC_PROTO_ETHERNET)
 return -EINVAL;
 if (vlan_tci & htons(VLAN_TAG_PRESENT))
 return -EINVAL;
 mac_proto = MAC_PROTO_ETHERNET;
 break;


Isn't the mac_proto set inverted here, should'nt it look like this?


 case OVS_ACTION_ATTR_PUSH_ETH:
 /* Disallow pushing an Ethernet header if one
  * is already present */
 if (mac_proto != MAC_PROTO_NONE)
 return -EINVAL;
 mac_proto = MAC_PROTO_ETHERNET;
 break;

 case OVS_ACTION_ATTR_POP_ETH:
 if (mac_proto != MAC_PROTO_ETHERNET)
 return -EINVAL;
 if (vlan_tci & htons(VLAN_TAG_PRESENT))
 return -EINVAL;
 mac_proto = MAC_PROTO_NONE;
 break;


Jaime,

I am looking into this and at first sight this does look inverted but we 
have no other reported bugs
in this area so I want to be careful that we don't break anything else 
while fixing this.  Have you tried
building OVS with this code change and been able to verify that this 
change works?


I'll be working on setting up a test bed to check this - hopefully by 
early next week I can report back so

stay tuned please.

Thanks,

- Greg



BR
Jaime.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Why 10 Mbps?

[Ben Pfaff]

On Fri, Oct 26, 2018 at 04:42:29PM -0600, Sterdnot Shaken wrote:
> Why is it that vnic ports show as having a speed of 10 Mbps under the
> command ovs-ofctl dump-ports-desc ?
> 
> I've done many tests and the 10 Mbps value obviously has no implications on
> actual throughput for the OVS bridges. I was just curious why 10 Mbps...
> It's a default apparently? How would I change that if I wanted too?

10 Mbps was a common speed for physical ports back in 2007 when we wrote
the code.

You could change it by editing the source code.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovs openflow question

[Ben Pfaff]

On Sat, Oct 27, 2018 at 12:31:25AM +0200, Bo Yu wrote:
> How to easily add a flow to block port 1 to port 2 traffic assuming there
> are 5 ports ? Do I have to explicitly specify 'actions=3,4,5' ?

That's a typical way to do it.

> How to easily add a flow for a 'NOT EQUAL' logic ? I am very surprised that
> 'inverse logic' is not supported in any openflow spec and ovs extension.

Read the "Matching" section in ovs-fields(7).
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Why 10 Mbps?

[Sterdnot Shaken]

Lightning quick with your answers as always Ben!

I appreciate ya taking the time!


On Fri, Oct 26, 2018 at 4:55 PM Ben Pfaff  wrote:

> On Fri, Oct 26, 2018 at 04:42:29PM -0600, Sterdnot Shaken wrote:
> > Why is it that vnic ports show as having a speed of 10 Mbps under the
> > command ovs-ofctl dump-ports-desc ?
> >
> > I've done many tests and the 10 Mbps value obviously has no implications
> on
> > actual throughput for the OVS bridges. I was just curious why 10 Mbps...
> > It's a default apparently? How would I change that if I wanted too?
>
> 10 Mbps was a common speed for physical ports back in 2007 when we wrote
> the code.
>
> You could change it by editing the source code.
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Basic OVS - VLAN translations

[Fred Licht via discuss]

Hey,
   I am not able to find a basic document or instruction on how to best 
configure VLAN translation with OVS.  I would be using the LTS OVS 2.5.5.  Can 
someone point me to some good examples or provide one.

A basic setup would be two OVS bridges with a Patch interface between them.  
The Patch interface is trunking VLAN 10,11,12,13 to the second switch.  I then 
wish to convert VLAN 10 to VLAN 110 for the attached interface to a (Virtual) 
host’s NIC.

Thanks in advance.
Fred Licht
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Basic OVS - VLAN translations

[Raymond Burkholder]

On 2018-10-26 7:26 p.m., Fred Licht via discuss wrote:

I am not able to find a basic document or instruction on how to best configure 
VLAN translation with OVS.  I would be using the LTS OVS 2.5.5.  Can someone 
point me to some good examples or provide one.
It comes down to these two lines for cli'ing the forward and reverse 
directions (should be relatively easy to decipher the important bits):


ovs-ofctl add-flow {{ bridge.name }} 
priority=100,in_port=${VLANA},dl_vlan={{ mapping.a.vlan 
}},actions=mod_vlan_vid:{{ mapping.z.vlan }},output:${VLANZ}
ovs-ofctl add-flow {{ bridge.name }} 
priority=100,in_port=${VLANZ},dl_vlan={{ mapping.z.vlan 
}},actions=mod_vlan_vid:{{ mapping.a.vlan }},output:${VLANA}



In the bigger context, these lines are pulled from one of my 
repositories, it is a SaltStack templated bash script (use with caution):


#!/bin/bash
{% set mapvlans = salt['pillar.get']( 'mapvlans' ) %}
{% if mapvlans is defined %}{% if mapvlans.one2one is defined %}
{% set bridges = mapvlans.one2one %}
{% for bridge in bridges %}
ovs-ofctl del-flows {{ bridge.name }}
{% set mappings = bridge.mappings %}{% for mapping in mappings %}
VLANA=$(ovs-vsctl get Interface {{ mapping.a.port }} ofport)
VLANZ=$(ovs-vsctl get Interface {{ mapping.z.port }} ofport)
ovs-ofctl add-flow {{ bridge.name }} 
priority=100,in_port=${VLANA},dl_vlan={{ mapping.a.vlan 
}},actions=mod_vlan_vid:{{ mapping.z.vlan }},output:${VLANZ}
ovs-ofctl add-flow {{ bridge.name }} 
priority=100,in_port=${VLANZ},dl_vlan={{ mapping.z.vlan 
}},actions=mod_vlan_vid:{{ mapping.a.vlan }},output:${VLANA}

{% endfor %}{# mapping #}
ovs-ofctl add-flow {{ bridge.name }} priority=0,actions=NORMAL
{% endfor %}{# bridges #}
{% endif %}{# one2one #}{% endif %}{# mapvlans #}
exit 0

Raymond Burkholder
https://blog.raymond.burkholder.net





___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss