If you want inter-vlan communications, it would be more generic to define a
patch-port between the two vlans modifying the vlan on the way through:
what you have at the start is:
________ vlan:100 vlan:100 ________
| red1 | ----------> <----------> | red2 |
-------- | | 100,200 | | --------
| s1 | <-------> | s2 |
________ vlan:200 | | | | vlan:200 _________
| blue1 | ----------> <----------> | blue2 |
-------- ---------
And what you want is effectively:
________ vlan:100 vlan:100
________
| red1 | ----------> <----------> <----->
| red2 |
-------- | | 100,200 | | | |
--------
| s1 | <-------> | s2 | | s3 |
________ vlan:200 | | | | vlan:200 | |
_________
| blue1 | ----------> <----------> <----->
| blue2 |
--------
---------
You need to split 100 and 200 into separate ports here so that you can
treat them as access ports to effectively bridge vlan 100 and 200 in s3.
You could cut out s2 if you could modify s1, but I'm guessing the point of
this is to demonstrate 'transparently' bridging valns from a trunk port.
Also if you could modify s1 the solution would be to put all the hosts on
the same vlan since that's what you're doing anyway :)
In this case, you would define a new switch s3 on the same host as s2:
ovs-vsctl add-br s3
And then define patch ports between the two switches where the port appears
as an access port on s2 and a general port on s3:
ovs-vsctl -- add-port s2 patch-s3-100 tag=100 -- set interface patch-s3-100
type=patch options:peer=patch-s2-100 -- add-port s3 patch-s2-100 -- set
interface patch-s2-100 type=patch options:peer=patch-s3-100
ovs-vsctl -- add-port s2 patch-s3-200 tag=200 -- set interface patch-s3-200
type=patch options:peer=patch-s2-200 -- add-port s3 patch-s2-200 -- set
interface patch-s2-200 type=patch options:peer=patch-s3-200
Then you would place red2 and blue2 directly into s3 as general ports (no
vlan).
You could do this without an additional switch by looping patch-ports from
s2 back to s2, but conceptually it would be the same thing, and using a
separate switch makes it easier to visualize and debug.
On the other hand, if you're trying to manually implement the switch MAC
address to port mapping table in flow rules, your problem is with this rule:
cookie=0x0, duration=732.817s, table=0, n_packets=14, n_bytes=612,
idle_age=201, arp,dl_dst=ff:ff:ff:ff:ff:ff,arp_op=1 actions=NORMAL
The normal behavior of the switch here will be to isolate the packet to the
VLAN its already on. So red system ARP packets will not cross over to the
blue systems. Instead you could try actions = mod_vlan_vid:100,output:1,
mod_vlan_vid:200,output:1,strip_vlan,output:2,output:3 so that ARPs are
always sent everywhere (even the port they come in on). Don't do the same
thing on s1 though or it will create a loop.
On Wed, Jun 25, 2014 at 3:30 PM, shruti rao <shrutira...@gmail.com> wrote:
> Hi Andrew and Ben,
>
> Thanks for your responses.
>
> Following your suggestions, I modified the flow rules.
>
>
> mininet> sh ovs-ofctl dump-flows s1
> NXST_FLOW reply (xid=0x4):
> cookie=0x0, duration=1456.805s, table=0, n_packets=0, n_bytes=0,
> idle_age=1456,
> icmp,dl_src=00:00:00:00:00:03,dl_dst=00:00:00:00:00:02,nw_src=10.0.0.3,nw_dst=10.0.0.2,icmp_type=8
> actions=mod_vlan_vid:200,output:3
> cookie=0x0, duration=1456.805s, table=0, n_packets=0, n_bytes=0,
> idle_age=1456,
> icmp,dl_src=00:00:00:00:00:02,dl_dst=00:00:00:00:00:03,nw_src=10.0.0.2,nw_dst=10.0.0.3,icmp_type=0
> actions=strip_vlan,output:1
> cookie=0x0, duration=1456.805s, table=0, n_packets=3, n_bytes=306,
> idle_age=321,
> icmp,dl_src=00:00:00:00:00:04,dl_dst=00:00:00:00:00:03,nw_src=10.0.0.4,nw_dst=10.0.0.3,icmp_type=0
> actions=strip_vlan,output:1
> cookie=0x0, duration=1456.805s, table=0, n_packets=3, n_bytes=294,
> idle_age=321,
> icmp,dl_src=00:00:00:00:00:03,dl_dst=00:00:00:00:00:04,nw_src=10.0.0.3,nw_dst=10.0.0.4,icmp_type=8
> actions=mod_vlan_vid:100,output:3
> cookie=0x0, duration=723.716s, table=0, n_packets=14, n_bytes=588,
> idle_age=196, arp,dl_dst=ff:ff:ff:ff:ff:ff,arp_op=1 actions=NORMAL
> cookie=0x0, duration=367.527s, table=0, n_packets=1, n_bytes=42,
> idle_age=321,
> arp,dl_dst=00:00:00:00:00:03,arp_spa=10.0.0.4,arp_tpa=10.0.0.3,arp_op=2
> actions=output:1
> cookie=0x0, duration=201.576s, table=0, n_packets=0, n_bytes=0,
> idle_age=201,
> arp,dl_dst=00:00:00:00:00:03,arp_spa=10.0.0.2,arp_tpa=10.0.0.3,arp_op=2
> actions=output:1
>
> mininet> sh ovs-ofctl dump-flows s2
> NXST_FLOW reply (xid=0x4):
> cookie=0x0, duration=1537.392s, table=0, n_packets=3, n_bytes=294,
> idle_age=325,
> icmp,dl_src=00:00:00:00:00:04,dl_dst=00:00:00:00:00:03,icmp_type=0
> actions=mod_vlan_vid:100,output:1
> cookie=0x0, duration=1537.392s, table=0, n_packets=3, n_bytes=306,
> idle_age=325,
> icmp,dl_src=00:00:00:00:00:03,dl_dst=00:00:00:00:00:04,icmp_type=8
> actions=strip_vlan,output:2
> cookie=0x0, duration=1537.391s, table=0, n_packets=0, n_bytes=0,
> idle_age=1537,
> icmp,dl_src=00:00:00:00:00:02,dl_dst=00:00:00:00:00:03,icmp_type=0
> actions=mod_vlan_vid:100,output:1
> cookie=0x0, duration=1537.392s, table=0, n_packets=0, n_bytes=0,
> idle_age=1537,
> icmp,dl_src=00:00:00:00:00:03,dl_dst=00:00:00:00:00:02,icmp_type=8
> actions=strip_vlan,output:3
> cookie=0x0, duration=732.817s, table=0, n_packets=14, n_bytes=612,
> idle_age=201, arp,dl_dst=ff:ff:ff:ff:ff:ff,arp_op=1 actions=NORMAL
> cookie=0x0, duration=369.775s, table=0, n_packets=1, n_bytes=42,
> idle_age=325,
> arp,dl_dst=00:00:00:00:00:03,arp_spa=10.0.0.4,arp_tpa=10.0.0.3,arp_op=2
> actions=output:1
> cookie=0x0, duration=207.948s, table=0, n_packets=0, n_bytes=0,
> idle_age=207,
> arp,dl_dst=00:00:00:00:00:03,arp_spa=10.0.0.2,arp_tpa=10.0.0.3,arp_op=2
> actions=output:1
>
>
> I am now able to ping red2 from red1.
>
> But, I am still not able to establish communication between the red1 and
> blue2. In fact, I could see in the wireshark, no ARP response is generated.
>
> mininet> red1 ping -c1 blue2
>
> PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
> From 10.0.0.3 icmp_seq=1 Destination Host Unreachable
>
> --- 10.0.0.2 ping statistics ---
> 1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
>
> Any suggestions on making the inter VLAN communication work.
>
> Thanks,
> Shruti
>
>
> On Tue, Jun 24, 2014 at 11:53 AM, Andrew Mann <and...@divvycloud.com>
> wrote:
>
>> I'm still learning OVS, but I'll take a stab:
>>
>> 1) Before the ping starts, an ARP request will be sent which will be
>> broadcast. It won't match the destination MAC because the purpose of the
>> ARP is to find out what the MAC is. Normally the VLAN would take care of
>> broadcasting the packet out to all hosts on the VLAN, but I think your
>> manual flows have effectively torn down the VLAN handling. To make this
>> work you could try adding a flow that matches dest mac ff:ff:ff:ff:ff:ff
>> and send the packets out to all ports. Be sure to strip the vlan tag as
>> well before sending the packets out of the access ports (at least I think
>> that's necessary).
>>
>> 2) Add strip_vlan to your first flow rule on your second switch.
>>
>> 3) Ping is a round-trip, so you need the reverse path as well. You need
>> to tag vlan 100 or 200 in traffic going from S2 back to S1 as is
>> appropriate for the host you're trying to reach. If you didn't want to make
>> traffic work across VLANs you could just forward the packets as-is
>>
>> In this configuration having the VLANs configured on S1 just gets in your
>> way.
>>
>>
>>
>> On Tue, Jun 24, 2014 at 12:08 PM, shruti rao <shrutira...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I am new to Open vSwitch and am trying to create a VLAN with two
>>> switches (s1, s2) having 2 hosts (s1 having red1 and blue1 and s2 having
>>> red2 and blue2) each and no controller. My configuration is as mentioned
>>> below:
>>>
>>> mininet> net
>>> s1 lo: s1-eth1:red1-eth0 s1-eth2:blue1-eth0 s1-eth3:s2-eth1
>>> s2 lo: s2-eth1:s1-eth3 s2-eth2:red2-eth0 s2-eth3:blue2-eth0
>>> blue1 blue1-eth0:s1-eth2
>>> blue2 blue2-eth0:s2-eth3
>>> red1 red1-eth0:s1-eth1
>>> red2 red2-eth0:s2-eth2
>>>
>>> I have created VLAN by assigning tag ids as below
>>>
>>> mininet> sh ovs-vsctl show
>>> de0d6311-08a0-4eba-aad8-d91ae2df8483
>>> Bridge "s1"
>>> Controller "ptcp:6634"
>>> fail_mode: secure
>>> Port "s1-eth3"
>>> trunks: [100, 200]
>>> Interface "s1-eth3"
>>> Port "s1-eth2"
>>> tag: 200
>>> Interface "s1-eth2"
>>> Port "s1"
>>> Interface "s1"
>>> type: internal
>>> Port "s1-eth1"
>>> tag: 100
>>> Interface "s1-eth1"
>>> Bridge "s2"
>>> Controller "ptcp:6635"
>>> fail_mode: secure
>>> Port "s2-eth1"
>>> trunks: [100, 200]
>>> Interface "s2-eth1"
>>> Port "s2"
>>> Interface "s2"
>>> type: internal
>>> Port "s2-eth3"
>>> tag: 200
>>> Interface "s2-eth3"
>>> Port "s2-eth2"
>>> tag: 100
>>> Interface "s2-eth2"
>>> mininet> sh ovs-ofctl show s1
>>> OFPT_FEATURES_REPLY (xid=0x2): dpid:0000000000000001
>>> n_tables:254, n_buffers:256
>>> capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
>>> actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC
>>> SET_DL_DST SET_NW_SRC SET_NW_DST SET_NW_TOS SET_TP_SRC SET_TP_DST ENQUEUE
>>> 1(s1-eth1): addr:56:eb:cf:57:2c:f2
>>> config: 0
>>> state: 0
>>> current: 10GB-FD COPPER
>>> speed: 10000 Mbps now, 0 Mbps max
>>> 2(s1-eth2): addr:ae:1b:e0:f8:63:7e
>>> config: 0
>>> state: 0
>>> current: 10GB-FD COPPER
>>> speed: 10000 Mbps now, 0 Mbps max
>>> 3(s1-eth3): addr:72:e7:6a:a3:cd:92
>>> config: 0
>>> state: 0
>>> current: 10GB-FD COPPER
>>> speed: 10000 Mbps now, 0 Mbps max
>>> LOCAL(s1): addr:ba:7c:3d:45:92:4c
>>> config: 0
>>> state: 0
>>> speed: 0 Mbps now, 0 Mbps max
>>> OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
>>> mininet> sh ovs-ofctl show s2
>>> OFPT_FEATURES_REPLY (xid=0x2): dpid:0000000000000002
>>> n_tables:254, n_buffers:256
>>> capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
>>> actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC
>>> SET_DL_DST SET_NW_SRC SET_NW_DST SET_NW_TOS SET_TP_SRC SET_TP_DST ENQUEUE
>>> 1(s2-eth1): addr:ae:84:0c:3d:74:42
>>> config: 0
>>> state: 0
>>> current: 10GB-FD COPPER
>>> speed: 10000 Mbps now, 0 Mbps max
>>> 2(s2-eth2): addr:ba:3b:f5:9d:47:01
>>> config: 0
>>> state: 0
>>> current: 10GB-FD COPPER
>>> speed: 10000 Mbps now, 0 Mbps max
>>> 3(s2-eth3): addr:52:45:27:b8:d5:96
>>> config: 0
>>> state: 0
>>> current: 10GB-FD COPPER
>>> speed: 10000 Mbps now, 0 Mbps max
>>> LOCAL(s2): addr:16:7f:2d:db:99:40
>>> config: 0
>>> state: 0
>>> speed: 0 Mbps now, 0 Mbps max
>>> OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
>>>
>>> When I install flow rule giving *actions=normal* in s1 and s2, the
>>> functionality works as expected. Red1 can ping Red2 but cannot reach Blue1
>>> and Blue2 and vice versa.
>>> Then I am deleting these flow rules and am adding a flow rules based on
>>> the MAC Address and it is not working.
>>>
>>> mininet> sh ovs-ofctl dump-flows s1
>>> NXST_FLOW reply (xid=0x4):
>>> cookie=0x0, duration=160.318s, table=0, n_packets=0, n_bytes=0,
>>> idle_age=160, actions=NORMAL
>>> mininet> sh ovs-ofctl dump-flows s2
>>> NXST_FLOW reply (xid=0x4):
>>> cookie=0x0, duration=50.296s, table=0, n_packets=0, n_bytes=0,
>>> idle_age=50, in_port=1,dl_dst=ba:3b:f5:9d:47:01 actions=output:2
>>> cookie=0x0, duration=12.639s, table=0, n_packets=0, n_bytes=0,
>>> idle_age=12, in_port=1,dl_dst=52:45:27:b8:d5:96 actions=strip_vlan,output:3
>>> mininet> red1 ping red2
>>> PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
>>> From 10.0.0.3 icmp_seq=1 Destination Host Unreachable
>>> From 10.0.0.3 icmp_seq=2 Destination Host Unreachable
>>> From 10.0.0.3 icmp_seq=3 Destination Host Unreachable
>>> ^C
>>> --- 10.0.0.4 ping statistics ---
>>> 5 packets transmitted, 0 received, +3 errors, 100% packet loss, time
>>> 4024ms
>>> pipe 3
>>> mininet> red1 ping blue2
>>> PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
>>> From 10.0.0.3 icmp_seq=1 Destination Host Unreachable
>>> From 10.0.0.3 icmp_seq=2 Destination Host Unreachable
>>> From 10.0.0.3 icmp_seq=3 Destination Host Unreachable
>>> ^C
>>> --- 10.0.0.2 ping statistics ---
>>> 5 packets transmitted, 0 received, +3 errors, 100% packet loss, time
>>> 4000ms
>>> pipe 3
>>>
>>> Where am I going wrong while adding the flow rule?
>>>
>>> Is it possible to install a flow rule that would enable Red1 to
>>> communicate with Blue2?
>>>
>>> Any help on this would really be appreciated.
>>>
>>> Thanks,
>>> Shruti
>>>
>>> _______________________________________________
>>> discuss mailing list
>>> discuss@openvswitch.org
>>> http://openvswitch.org/mailman/listinfo/discuss
>>>
>>>
>>
>>
>> --
>> Andrew Mann
>> DivvyCloud Inc.
>> www.divvycloud.com
>>
>
>
--
Andrew Mann
DivvyCloud Inc.
www.divvycloud.com
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
