On Mon, Sep 9, 2013 at 5:14 AM, Andrei Andone <andrei.and...@softvision.ro>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 on tunnel 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?
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss