[ovs-discuss] Question on tunnel interfaces

Padmanabhan Krishnan kprad1 at yahoo.com
Mon Apr 27 19:44:10 UTC 2015


Thanks a lot Ben and Jesse.

Just wanted to clarify, from your statements:

“OVS simply hands the packet over to the kernel IP stack.”

"After encapsulation, OVS turns the packet over to the kernel TCP/IP
Stack"

Is the above (handling the frame to kernel to do the routing) a special functionality of the tunnel bridge/port?

For example, if a VM connected to a regular OVS bridge (br-int) sends a frame destined to a 173.x.. subnet (attached to eth2), i assume OVS will bridge the frame and not hand it over to the kernel, right? 

More information below:

Lab-135:~/devstack/devstack$ sudo ovs-dpctl --version
ovs-dpctl (Open vSwitch) 2.0.2
Compiled Aug 15 2014 14:31:02

Lab-135:~/devstack/devstack$ sudo ovs-vsctl show
78e151e6-ca8b-4338-8b62-a0fee0c1c24f
    Bridge br-tun
        Port br-tun
            Interface br-tun
                type: internal
        Port "vxlan-ad24f10f"
            Interface "vxlan-ad24f10f"
                type: vxlan
                options: {df_default="true", in_key=flow, local_ip="173.36.241.17", out_key=flow, remote_ip="173.36.241.15"}
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}


Lab-135:~/devstack/devstack$ sudo ovs-dpctl show
system at ovs-system:
        lookups: hit:188973 missed:16649 lost:0
        flows: 4
        port 0: ovs-system (internal)
        port 1: br-int (internal)
        port 2: br-tun (internal)
        port 3: br-ethd (internal)
        port 4: vxlan_sys_4789 (vxlan: df_default=false, ttl=0)
        port 5: qvoaeac2bb5-70

Ben, you asked for the above output. Even, with a "-m" it returned only the above.


Lab-135:~/devstack/devstack$ sudo ovs-dpctl dump-flows
skb_priority(0),in_port(5),eth(src=fa:16:3e:04:30:4e,dst=fa:16:3e:d6:37:1f),eth_type(0x0800),ipv4(src=44.50.12.4/0.0.0.0,dst=44.50.12.2/0.0.0.0,proto=1/0,tos=0/0x3,ttl=64/0,frag=no/0xff), packets:257, bytes:25186, used:0.972s, actions:set(tunnel(tun_id=0x3eb,src=173.36.241.17,dst=173.36.241.15,tos=0x0,ttl=64,flags(df,key))),4
skb_priority(0),tunnel(tun_id=0x3eb,src=173.36.241.15,dst=173.36.241.17,tos=0x0,ttl=64,flags(key)),in_port(4),skb_mark(0),eth(src=fa:16:3e:d6:37:1f,dst=fa:16:3e:04:30:4e),eth_type(0x0800),ipv4(src=44.50.12.2/0.0.0.0,dst=44.50.12.4/0.0.0.0,proto=1/0,tos=0/0,ttl=64/0,frag=no/0xff), packets:258, bytes:25284, used:0.968s, actions:5

 Thanks,Padmanabhan


     On Monday, April 27, 2015 8:38 AM, Ben Pfaff <blp at nicira.com> wrote:
   

 On Sat, Apr 25, 2015 at 06:12:54AM +0000, Padmanabhan Krishnan wrote:
> Hello,My question is related to the sending (encap) side of the OVS tunnel bridge.
> After the tunnel bridge (say br-tun) does the encapsulation (VXLAN or GRE), i assume it uses the host routing table to route the packet. So, when a frame is received by the br-tun from an in_port, after performing the necessary encapsulation does OVS send it over to kernel routing module to forward the frame on the right interface (routing)?
> In my example below, the end point 173 subnet is attached to say, eth2. The physical port 'eth2' is _not_ connected to OVS bridge 'br-tun'. But, depending on the 'remote_ip', the frame gets forwarded to the right interface.
> I will be obliged, if someone can explain, in terms of flow, as how forwarding happens after the frame gets encapsulated (br-tun)? Does routing of the frame fall under the scope of OVS?Is it a special functionality of the 'set_tunnel' action?

After encapsulation, OVS turns the packet over to the kernel TCP/IP
stack, which routes it appropriately.  OVS doesn't have control over how
exactly that happens, other than by controlling addressing.

The set_tunnel action just sets the tunnel key (e.g. in GRE the GRE key,
in VXLAN the VNI).

> Dumping the flow on br-tun using ofctl, i assume the below line is responsible for the encap:"
>  cookie=0x0, duration=14723.832s, table=22, n_packets=22, n_bytes=1826, idle_age=14704, dl_vlan=1 actions=strip_vlan,set_tunnel:0x3eb,output:2
> "
> Port 2 is vxlan-ad24f10f below.

I'd expect to see more information than just the tunnel key.  Check the
"ovs-dpctl show" output for port 2.


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20150427/68ba8e1d/attachment-0002.html>


More information about the discuss mailing list