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@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 <[email protected]> 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.
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss
