Hello,Host 2 is configured with options:remote_ip=192.168.56.142 (host 1 IP). But I don't think that host 2 is the problem since on host 1 I can see the arp reply packets coming in on br-eth0 and on eth0. I do not see the reply packet being forwarded to the vm's port (vnet0).
I'm attaching to this email the wireshark captures on host 1 for remote_ip=192.168.56.143 (file "arp-reply-with-ip") and remote_ip=flow ("arp-reply-with-flow"). Please ignore the arp packets between "192.168.100.1" and "192.168.100.33". As you can see in the attached captures there are two identical requests (one captured on br-eth0 and one on eth0) for both captures. As for the replies, both captures have two GRE encapsulated arp responses (one on br-eth0 and one on eth0) and only the remote_ip=IP version has the reply that is not GRE encapsulate (capture on the vm port).
This is why I think that when I use remote_ip=flow the tunnel somehow doesn't get identified by the br-eth0 bridge and packets are not being forwarded to it.
Thanks, Andrei On 09/09/2013 11:56 PM, Jesse Gross wrote:
On Mon, Sep 9, 2013 at 5:14 AM, Andrei Andone <[email protected] <mailto:[email protected]>> wrote:Hello Jesse, I tried what you said and to only deal with the br-vnet bridge. I also switched to GRE tunnels for ease of viewing packets. Here's how it went: First config (host h1): [root@localhost ~]# ovs-vsctl show 0383aece-fb49-47ab-b9d2-c1ee13c16a89 Bridge br-vnet Port "vnet0" Interface "vnet0" Port gre-tun Interface gre-tun type: gre options: {key="10", remote_ip="192.168.56.143"} Port br-vnet Interface br-vnet type: internal Bridge "br-eth0" Port "eth0" Interface "eth0" Port "br-eth0" Interface "br-eth0" type: internal ovs_version: "2.0.0" [root@localhost ~]# ovs-dpctl show system@ovs-system: lookups: hit:1475183 missed:278182 lost:608 flows: 137 port 0: ovs-system (internal) port 1: br-eth0 (internal) port 2: br-vnet (internal) port 3: eth0 port 4: gre_system (gre: df_default=false, ttl=0) port 5: vnet0 [root@localhost ~]# ovs-ofctl show br-vnet OFPT_FEATURES_REPLY (xid=0x2): dpid:000052fead266b48 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(vnet0): addr:fe:54:00:1d:28:97 config: 0 state: 0 current: 10MB-FD COPPER speed: 10 Mbps now, 0 Mbps max 3(gre-tun): addr:06:b5:22:a0:e5:86 config: 0 state: 0 speed: 0 Mbps now, 0 Mbps max LOCAL(br-vnet): addr:52:fe:ad:26:6b:48 config: 0 state: 0 speed: 0 Mbps now, 0 Mbps max OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0 [root@localhost ~]# ovs-ofctl dump-flows br-vnet NXST_FLOW reply (xid=0x4): cookie=0x0, duration=9750.473s, table=0, n_packets=5067, n_bytes=212814, idle_age=19, arp,in_port=1 actions=load:0xc0a8388f->NXM_NX_TUN_IPV4_DST[],output:3 # for sending from the vm through the tunnel cookie=0x0, duration=9667.699s, table=0, n_packets=0, n_bytes=0,idle_age=9667, arp,in_port=3 actions=output:1 # hardcoded for receiving ontunnel and sending to the vm cookie=0x0, duration=19879.453s, table=0, n_packets=4642, n_bytes=313094, idle_age=13, priority=0 actions=NORMAL ** I also added the flows that set the IP (192.168.56.143 - host 2 IP) to the tun_dst these shouldn't interfere ** Here's how the datapath flows look-like while I'm successfully arping-ing from the local vm to the remote one: [root@localhost ~]# ovs-appctl dpif/dump-flows br-vnet skb_priority(0),tunnel(tun_id=0xa,src=192.168.56.143,dst=192.168.56.142,tos=0x0,ttl=64,flags(key)),in_port(4),skb_mark(0),eth_type(0x0806), packets:1, bytes:42, used:0.490s, actions:5 skb_priority(0),in_port(5),eth_type(0x0806), packets:297, bytes:12474, used:0.491s, actions:set(tunnel(tun_id=0xa,src=0.0.0.0,dst=192.168.56.143,tos=0x0,ttl=64,flags(df,key))),4 [root@localhost ~]# ** As you can see, both flows for sending and receiving exist and are being used ** I then use `ovs-vsctl set Interface gre-tun options:remote_ip=flow` (all other configs remain unchanged event the arping command). Here's the datapath flow output: [root@localhost ~]# ovs-appctl dpif/dump-flows br-vnet skb_priority(0),in_port(5),eth_type(0x0806), packets:376, bytes:15792, used:0.016s, actions:set(tunnel(tun_id=0xa,src=0.0.0.0,dst=192.168.56.143,tos=0x0,ttl=64,flags(df,key))),4 [root@localhost ~]# ** I can only see the flow for sending being used, not the one for receiving ** I assume I am missing a flow (or something else) that sends packages from my physical interface (eth0) to my tunnel. Do you have any idea what I am missing?I would guess that the problem is on the receiving side since the transmitter looks the same to me. What happens if you keep the side the same while you change the transmitter to use flow-based tunneling? Can you send the same information that you gave here for the receiver?
-- Andrei Andone SOFTVISION | 57 Republicii Street, 400489 Cluj-Napoca, RomaniaEmail: [email protected] <mailto:[email protected]> | Web: www.softvision.ro <http://www.softvision.ro>
The content of this communication is classified as SOFTVISION Confidential and Proprietary Information.
arp-reply-with-ip
Description: Binary data
arp-reply-with-flow
Description: Binary data
_______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
