Thank you for your attention to this matter. I finally find source of the problem! After you show me how to approach, i look over all the thing with the greatest care. Mac address of two VM were same, And it caused all problem. Weird things about this problem was that there were ARP responses at host2, but host1 can't get ARP response from ovs bridge1. i figured out the cause from doing ovs-dpctl dump-flows on host1
[host1] ovs-dpctl dump-flows in_port(6),eth(src=d2:0d:45:a3:92:ea,dst=d2:0d:45:a3:92:ea),eth_type(0x0800),ipv4(src=10.123.123.20,dst=10.123.123.21,proto=1,tos=0,ttl=64,frag=no),icmp(type=8,code=0), packets:24, bytes:2352, used:0.337s, actions:drop I don't know what other action means(other have integer number i don't understand), but anyway this rule says it dropping icmp path through 20 to 21. i didn't do something on open-flow and it has weird src,dst mac! Again, i owe you a real debt of gratitude for your help. 2013/7/10 Alex Wang <al...@nicira.com> > Hey JinHwan, > > Thanks for providing more info, > > Seem to me that you captured those flow dumps and tcpdump at different > time, so they may not correspond to each other. > > I'll spend some time and try implementing this and see if I have the same > issue. You used KVM, right? > > Below are my observations from your given output. Hope they are helpful. > > What i got from host2. dump-flows seems like almost empty. I did >> dump-flows to each br0 and br1 at host1 and hos2, They only have NXST_FLOW >> reply. I expected basically all operation i did above(creating and connect >> bridge, port, gre) would handle GRE connection. Should i have to directly >> deal with open-flow flows? >> > > *"ovs-ofctl dump-flows" output on br0 and br1 are correct. The 'normal' > flow subjects packet to the device's normal L2/L3 processing. Or, in other > words, it acts as a mac-learning switch.* > * > * > *From you previous output:* > > [host1]# ovs-dpctl dump-flow > >> >> in_port(6),eth(src=d2:0d:45:a3:92:ea,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=10.123.123.20,tip=10.123.123.21,op=1,sha=d2:0d:45:a3:92:ea,tha=00:00:00:00:00:00), >>>>>> packets:38, bytes:1596, used:1.192s, actions* >>>>>> :set(tunnel(tun_id=0x0,src=0.0.0.0,dst=192.168.100.21,tos=0x0,ttl=64,flags(df))),4,5 >>>>>> * >>>>>> >>>>> > > *This shows that the ARP request is sent through tunnel to host2 (with > correct tunnel configuration).* > > > [host1]# tcpdump -i vnet0 > >> 10:20:34.565313 IP 10.123.123.20 > 10.123.123.21: ICMP echo request, >>>>>> id 56071, seq 40, length 64 >>>>>> 10:20:35.566074 ARP, Request who-has 10.123.123.21 tell >>>>>> 10.123.123.20, length 28 >>>>>> 10:20:36.569006 ARP, Request who-has 10.123.123.21 tell >>>>>> 10.123.123.20, length 28 >>>>>> 10:20:37.566082 ARP, Request who-has 10.123.123.21 tell >>>>>> 10.123.123.20, length 28 >>>>>> 10:20:37.566710 ARP, Reply 10.123.123.21 is-at d2:0d:45:a3:92:ea (oui >>>>>> Unknown), length 28 >>>>>> >>>>> > > *This shows that the MAC address is resolved and received by vm on host1.* > > > [host2]# ovs-dpctl dump-flows > >> >> in_port(2),eth(src=00:01:e8:9a:74:e6,dst=01:00:5e:00:00:05),eth_type(0x0800),ipv4(src=182.162.143.2,dst=224.0.0.5,proto=89,tos=0xc0,ttl=1,frag=no), >>>>>> packets:0, bytes:0, used:never, actions:3,1 >>>>>> in_port(2),eth(src=d0:67:e5:a7:6f:ab,dst=01:80:c2:00:00:00), >>>>>> packets:130005, bytes:8320320, used:0.232s, actions:3,1 >>>>>> in_port(2),eth(src=f4:ce:46:bf:f2:21,dst=d4:be:d9:ac:f0:cf),eth_type(0x0800),ipv4(src=182.162.104.10,dst=182.162.104.21,proto=6,tos=0x8,ttl=64,frag=no),tcp(src=38555,dst=22), >>>>>> packets:15873, bytes:2071730, used:0.025s, flags:P., actions:1 >>>>>> in_port(2),eth(src=84:2b:2b:fb:ed:2e,dst=01:00:5e:7f:ff:fd),eth_type(0x0800),ipv4(src=182.162.104.4,dst=239.255.255.253,proto=2,tos=0xc0,ttl=1,frag=no), >>>>>> packets:0, bytes:0, used:never, actions:3,1 >>>>>> in_port(2),eth(src=00:01:e8:9a:74:e6,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=182.162.104.2,tip=182.162.104.111,op=1,sha=00:01:e8:9a:74:e6,tha=00:00:00:00:00:00), >>>>>> packets:0, bytes:0, used:never, actions:3,1 >>>>>> skb_priority(0x2),in_port(1),eth(src=d4:be:d9:ac:f0:cf,dst=f4:ce:46:bf:f2:21),eth_type(0x0800),ipv4(src=182.162.104.21,dst=182.162.104.10,proto=6,tos=0x8,ttl=64,frag=no),tcp(src=22,dst=38555), >>>>>> packets:14029, bytes:3356410, used:0.066s, flags:P., actions:2 >>>>>> in_port(2),eth(src=00:00:5e:00:01:37,dst=01:00:5e:00:00:12),eth_type(0x0800),ipv4(src=182.162.143.2,dst=224.0.0.18,proto=112,tos=0xc0,ttl=255,frag=no), >>>>>> packets:253989, bytes:68069052, used:0.529s, actions:3,1 >>>>>> in_port(2),eth(src=00:01:e8:9a:74:e6,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=117.52.91.2,tip=117.52.91.38,op=1,sha=00:01:e8:9a:74:e6,tha=00:00:00:00:00:00), >>>>>> packets:1, bytes:60, used:2.510s, actions:3,1 >>>>>> >>>>> > > *Here, there is no datapath flow of receiving tunnel packets, or ICMP > packets.* > > > [host2]# tcpdump -i tep0 > >> 10:32:16.294882 IP 192.168.100.20 > 192.168.100.21: GREv0, length 46: >>>>>> ARP, Request who-has 10.123.123.21 tell 10.123.123.20, length 28 >>>>>> 10:32:17.294506 IP 192.168.100.20 > 192.168.100.21: GREv0, length >>>>>> 46: ARP, Request who-has 10.123.123.21 tell 10.123.123.20, length 28 >>>>>> 10:32:17.294925 IP 192.168.100.21 > 192.168.100.20: GREv0, length >>>>>> 46: ARP, Reply 10.123.123.21 is-at d2:0d:45:a3:92:ea (oui Unknown), >>>>>> length >>>>>> 28 >>>>>> >>>>> 10:32:19.293615 IP 192.168.100.20 > 192.168.100.21: GREv0, length > 102: IP 10.123.123.20 > 10.123.123.21: ICMP echo request, id 56071, seq > 687, length 64 > > *However, here, it showed tunnel ARP request/reply packets captured. And > the ICMP echo request was received.* > > >
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
