[ovs-discuss] [ovs-dev] Problem with fake bridges

Ben Pfaff blp at nicira.com
Thu May 10 18:25:14 UTC 2012


On Thu, May 10, 2012 at 08:19:54PM +0200, Daniele Milani wrote:
> > Date: Thu, 10 May 2012 10:23:58 -0700
> > From: blp at nicira.com
> > To: dano1988 at hotmail.it
> > CC: discuss at openvswitch.org; paolo.smiraglia at polito.it; roberto.sassu at polito.it
> > Subject: Re: [ovs-dev] Problem with fake bridges
> > 
> > On Thu, May 10, 2012 at 07:15:52PM +0200, Daniele Milani wrote:
> > > > [adding the list back, please don't drop it again]
> > > > 
> > > > On Thu, May 10, 2012 at 06:17:33PM +0200, Daniele Milani wrote:
> > > > > > Date: Thu, 10 May 2012 09:07:29 -0700
> > > > > > From: blp at nicira.com
> > > > > > To: dano1988 at hotmail.it
> > > > > > CC: dev at openvswitch.org; roberto.sassu at polito.it; paolo.smiraglia at polito.it
> > > > > > Subject: Re: [ovs-dev] Problem with fake bridges
> > > > > > 
> > > > > > On Thu, May 10, 2012 at 05:25:51PM +0200, Daniele Milani wrote:
> > > > > > > I have the following situation:
> > > > > > > -I created two fake bridges on the same real bridge (br1 with tag=1 and br2 with tag=2);
> > > > > > > -I created two virtual machines (vm1 and vm2);
> > > > > > > -I attached the VM1 interface (vnet1) to br1, and the VM2 interface (vnet2) to br2;
> > > > > > > -I set br1 as default route of VM1 and br2 as default route of VM2;
> > > > > > > -if I run "$ ovs-vsctl show " I see that vnet1 tag is 1 and vnet2 is 2.
> > > > > > > 
> > > > > > > The problem is that, if I ping VM1 from VM2, or VM2 from VM1, the
> > > > > > > ping succeed.
> > > > > > 
> > > > > > What does "ovs-vsctl show" display?
> > > > > 
> > > > > This is the output I obtain:
> > > > > 
> > > > >     Bridge realbridge
> > > > >         Port "br2"
> > > > >             tag: 2
> > > > >             Interface "br2"
> > > > >                 type: internal
> > > > >         Port "vnet2"
> > > > >             tag: 2
> > > > >             Interface "vnet2"
> > > > >         Port "vnet1"
> > > > >             tag: 1
> > > > >             Interface "vnet1"
> > > > >         Port realbridge
> > > > >             Interface realbridge
> > > > >                 type: internal
> > > > >         Port "br1"
> > > > >             tag: 1
> > > > >             Interface "br1"
> > > > >                 type: internal
> > > > 
> > > > I agree that vnet1 and vnet2 should not be able to reach each other.
> > > > 
> > > > Run "ovs-dpctl show" and show us the output.  Then start a "ping"
> > > > between them, with little other traffic, and while it's going run
> > > > "ovs-dpctl dump-flows realbridge".  Also it'd be helpful to see the
> > > > output of "route -n" and "ifconfig".
> > > > 
> > > > Thanks,
> > > > 
> > > > Ben.
> > > 
> > > This is the output I obtain:
> > 
> > Your output doesn't match up with the "ovs-vsctl show" output you
> > showed previously.
> 
> Real bridge: br2
> Fake bridges: alpha-nic, beta-nic
> VM Ports: vnet0, vnet1
> 
> Output:
> ovs-vsctl show
> c17c73e1-649a-4daa-b323-9baf76e8b628
>     Bridge "br2"
>         Port alpha-nic
>             tag: 1
>             Interface alpha-nic
>                 type: internal
>         Port "vnet0"
>             tag: 1
>             Interface "vnet0"
>         Port beta-nic
>             tag: 2
>             Interface beta-nic
>                 type: internal
>         Port "br2"
>             Interface "br2"
>                 type: internal
>         Port "vnet1"
>             tag: 2
>             Interface "vnet1"
> 
> ovs-dpctl show
> system at br2:
>     lookups: hit:33 missed:29 lost:0
>     flows: 0
>     port 0: br2 (internal)
>     port 1: alpha-nic (internal)
>     port 2: beta-nic (internal)
>     port 3: vnet0
>     port 4: vnet1
> 
> ovs-dpctl dump-flows br2
> in_port(2),eth(src=b6:af:6b:c6:86:20,dst=52:94:00:09:f7:1e),eth_type(0x0800),ipv4(src=192.168.1.206,dst=192.168.2.166,proto=1,tos=0,ttl=63,frag=no),icmp(type=0,code=0), packets:27, bytes:2646, used:0.736s, actions:4
> in_port(2),eth(src=b6:af:6b:c6:86:20,dst=52:94:00:09:f7:1e),eth_type(0x0806),arp(sip=192.168.2.1,tip=192.168.2.166,op=1,sha=b6:af:6b:c6:86:20,tha=00:00:00:00:00:00), packets:0, bytes:0, used:never, actions:4
> in_port(1),eth(src=22:0b:79:ef:a0:7d,dst=52:94:00:02:c7:1e),eth_type(0x0800),ipv4(src=192.168.1.1,dst=192.168.1.206,proto=1,tos=0,ttl=63,frag=no),icmp(type=8,code=0), packets:27, bytes:2646, used:0.736s, actions:3
> in_port(4),eth(src=52:94:00:09:f7:1e,dst=b6:af:6b:c6:86:20),eth_type(0x0800),ipv4(src=192.168.2.166,dst=192.168.1.206,proto=1,tos=0,ttl=64,frag=no),icmp(type=8,code=0), packets:27, bytes:2646, used:0.736s, actions:2
> in_port(2),eth(src=b6:af:6b:c6:86:20,dst=01:00:5e:00:00:fb),eth_type(0x0800),ipv4(src=192.168.2.1,dst=224.0.0.251,proto=17,tos=0,ttl=255,frag=no),udp(src=5353,dst=5353), packets:0, bytes:0, used:never, actions:push_vlan(vid=2,pcp=0),0,pop_vlan,4
> in_port(3),eth(src=52:94:00:02:c7:1e,dst=22:0b:79:ef:a0:7d),eth_type(0x0806),arp(sip=192.168.1.206,tip=192.168.1.1,op=1,sha=52:94:00:02:c7:1e,tha=00:00:00:00:00:00), packets:0, bytes:0, used:never, actions:1
> in_port(4),eth(src=52:94:00:09:f7:1e,dst=b6:af:6b:c6:86:20),eth_type(0x0806),arp(sip=192.168.2.166,tip=192.168.2.1,op=2,sha=52:94:00:09:f7:1e,tha=b6:af:6b:c6:86:20), packets:0, bytes:0, used:never, actions:2
> in_port(1),eth(src=22:0b:79:ef:a0:7d,dst=01:00:5e:00:00:fb),eth_type(0x0800),ipv4(src=192.168.1.1,dst=224.0.0.251,proto=17,tos=0,ttl=255,frag=no),udp(src=5353,dst=5353), packets:0, bytes:0, used:never, actions:push_vlan(vid=1,pcp=0),0,pop_vlan,3
> in_port(3),eth(src=52:94:00:02:c7:1e,dst=22:0b:79:ef:a0:7d),eth_type(0x0800),ipv4(src=192.168.1.206,dst=192.168.1.1,proto=1,tos=0,ttl=64,frag=no),icmp(type=0,code=0), packets:27, bytes:2646, used:0.736s, actions:1
> in_port(1),eth(src=22:0b:79:ef:a0:7d,dst=52:94:00:02:c7:1e),eth_type(0x0806),arp(sip=192.168.1.1,tip=192.168.1.206,op=2,sha=22:0b:79:ef:a0:7d,tha=52:94:00:02:c7:1e), packets:0, bytes:0, used:never, actions:3

OK, the problem is becoming clearer, but can you give "ifconfig" and
"route -n" for the host instead for the VMs?  That output should
settle it.

Thanks,

Ben.



More information about the discuss mailing list