[ovs-discuss] Vlan & OVS basic concepts

Ben benoitne at gmail.com
Sat Dec 27 10:19:05 UTC 2014


Hi Flavio,

Many thanks for your quick reply.

> -I can ping the tap0 and vswitch-trust interfaces from my linux box, but 
> my main issue is that if I don't put an IP address on my vswitch-trust 
> interface then I am unable to access to my tap0 IP address.

This indicates your Linux is forwarding packets between vswitch-trust and
tap0 and it's not using the bridge for that.

I think this is the main issue where all others my questions are related as well.
How can I test and be sure that it is my Linux which is forwarding and not my bridge?
Is it a conflit between my kernel & ovs? I tried to unactivate linux ipv4 forwarding but it is the same story..

Many thanks

On 26 déc. 2014, at 15:24, Flavio Leitner <fbl at sysclose.org> wrote:

> On Wednesday, December 24, 2014 11:27:06 AM Ben wrote:
> Hi OVS!
> 
> I am newbie in OVS and I try for a couple of days to make it work and I 
> am on a point where I would be more than happy to receive some help..
> In fact, I am not sure now if I have a problem on my system/kernel 
> support (ArchLinux 3.17.6) & my OVS version (2.3.1) or if I don’t 
> understand correctly the concept behind OVS..
> I have followed the Vlan configuration Cookbook 
> (http://openvswitch.org/support/config-cookbooks/vlan-configuration-cookbook/) 
> and I am not able to make it work as I expect...
> 
> My configuration is very simple (only bold part are interesting now):
> 
> -vswitch-trust & vswitch-untrust : two OVS bridges
> -eth1 : will be conncected to ppp link / now not a problem
> *-eth2 : port connected to my internal network**
> **-tap0 : interface test for **future VM deployement on the server*
> 
>  ovs-vsctl show
> 269b9f98-edee-41b5-815e-d12e3bcbb5d2
>     Bridge vswitch-untrust
>         Port vswitch-untrust
>             Interface vswitch-untrust
>                 type: internal
>         Port "eth1"
>             Interface "eth1"
> *    Bridge vswitch-trust**
> **        Port vswitch-trust**
> **            Interface vswitch-trust**
> **                type: internal**
> **        Port "eth2"**
> **            Interface "eth2"**
> **        Port "wlan0"**
> **            Interface "wlan0"**
> **        Port "tap0"**
> **            tag: 5**
> **            Interface "tap0"**
> **                type: tap*
> 
> ip addr
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
> group default
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     inet 127.0.0.1/8 scope host lo
>        valid_lft forever preferred_lft forever
>     inet6 ::1/128 scope host
>        valid_lft forever preferred_lft forever
> 2: *eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master 
> ovs-system state UP group default qlen 1000**
> **    link/ether 00:01:c0:15:8f:e8 brd ff:ff:ff:ff:ff:ff**
> **    inet6 fe80::201:c0ff:fe15:8fe8/64 scope link **
> **       valid_lft forever preferred_lft forever*
> 3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop master ovs-system 
> state DOWN group default qlen 1000
>     link/ether ac:7b:a1:4d:ff:67 brd ff:ff:ff:ff:ff:ff
> 4: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop master ovs-system 
> state DOWN group default qlen 1000
>     link/ether 00:01:c0:15:8f:dd brd ff:ff:ff:ff:ff:ff
> 5: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN 
> group default
>     link/ether 02:c5:bf:71:bf:c9 brd ff:ff:ff:ff:ff:ff
> 6: *vswitch-trust: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc 
> noqueue state UNKNOWN group default **
> **    link/ether 00:01:c0:15:8f:e8 brd ff:ff:ff:ff:ff:ff**
> **    inet 10.20.8.5/24 scope global vswitch-trust**
> **       valid_lft forever preferred_lft forever**
> **    inet6 2001:910:117b:8:201:c0ff:fe15:8fe8/64 scope global 
> mngtmpaddr dynamic **
> **       valid_lft 86327sec preferred_lft 14327sec**
> **    inet6 fe80::201:c0ff:fe15:8fe8/64 scope link **
> **       valid_lft forever preferred_lft forever*
> 7:*tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel 
> master ovs-system state UNKNOWN group default qlen 500**
> **    link/ether d6:fc:f5:7f:20:c4 brd ff:ff:ff:ff:ff:ff**
> **    inet 10.20.8.10/24 scope global tap0**
> **       valid_lft forever preferred_lft forever**
> **    inet6 fe80::d4fc:f5ff:fe7f:20c4/64 scope link **
> **       valid_lft forever preferred_lft forever*
> 8: vswitch-untrust: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN 
> group default
>     link/ether 00:01:c0:15:8f:dd brd ff:ff:ff:ff:ff:ff
> 
> To make my test I connected to the eth2 a linux box where I can play 
> with vlan / addressing..
> 
> My questions :
> 
> -I realized that even if I put my tap0 interface into vlan5 I am able to 
> access to it from my linux box without any vlan tag interface.
> I read that this can occur because of the way linux is doing a weak 
> verification compared to BSD and it needs to be done via iptables, is it 
> correct?
> I see that vswitch-trust interface is actually responding to me when I 
> tried to ping 10.20.8.10 (tap0)

When you set the interface to be an access port  using tag=, then any
packet coming with a different tag should not pass through. 

Ports without tag= works as trunk ports.

> -I can ping the tap0 and vswitch-trust interfaces from my linux box, but 
> my main issue is that if I don't put an IP address on my vswitch-trust 
> interface then I am unable to access to my tap0 IP address.

This indicates your Linux is forwarding packets between vswitch-trust and
tap0 and it's not using the bridge for that.

> I realized that it is only vswitch-trust interface who is responding to ARP.
> Which confirm the first point above.
> I would expect to see my tap0 to be able to respond to ARP as well, is 
> there a way to do that?

If you put the IP addresses in the same subnet and vlan, it should work as
any switch out there by default.

fbl
_______________________________________________
discuss mailing list
discuss at openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20141227/cb00166b/attachment-0002.html>


More information about the discuss mailing list