On Thu, May 22, 2014 at 05:53:56PM +0200, Dani Camps wrote: > I think the problem I am having is that the "ARP request to controller" > hidden rule is not matching. This is what happens: > > 1) In the switch (192.168.56.203) connected to the controller > (192.168.56.103) I see ARP Requests coming from the other switch: > > # tcpdump -i s3-eth0 > 19:47:32.818889 ARP, Request who-has 192.168.56.103 tell 192.168.56.202, > length 28 > 19:47:33.816421 ARP, Request who-has 192.168.56.103 tell 192.168.56.202, > length 28 > ... > > 2) However when I dump the status of the hidden flows in the switch > connected to the controller I get this: > > duration=485s, n_packets=851, n_bytes=924434, > priority=180007,tcp,nw_dst=192.168.56.103,tp_dst=6633,actions=NORMAL > duration=485s, n_packets=1, n_bytes=60, > priority=180006,arp,arp_spa=192.168.56.103,arp_op=1,actions=NORMAL > duration=485s, n_packets=0, n_bytes=0, > priority=180005,arp,arp_tpa=192.168.56.103,arp_op=2,actions=NORMAL > duration=485s, n_packets=860, n_bytes=63226, > priority=180008,tcp,nw_src=192.168.56.103,tp_src=6633,actions=NORMAL > duration=485s, n_packets=1, n_bytes=60, > priority=180001,arp,dl_dst=f6:b8:41:3c:d6:45,arp_op=2,actions=NORMAL > duration=478s, n_packets=0, n_bytes=0, > priority=180003,arp,dl_dst=08:00:27:a9:08:16,arp_op=2,actions=NORMAL > duration=485s, n_packets=0, n_bytes=0, > priority=180000,udp,in_port=LOCAL,dl_src=f6:b8:41:3c:d6:45,tp_src=68,tp_dst=67,actions=NORMAL > duration=485s, n_packets=1, n_bytes=42, > priority=180002,arp,dl_src=f6:b8:41:3c:d6:45,arp_op=1,actions=NORMAL > duration=478s, n_packets=0, n_bytes=0, > priority=180004,arp,dl_src=08:00:27:a9:08:16,arp_op=1,actions=NORMAL > table_id=254, duration=486s, n_packets=0, n_bytes=0, > priority=0,reg0=0x3,actions=drop > table_id=254, duration=486s, n_packets=320, n_bytes=30696, > priority=0,reg0=0x1,actions=controller(reason=no_match) > table_id=254, duration=486s, n_packets=0, n_bytes=0, > priority=0,reg0=0x2,actions=drop > > > Where specially the following rule is interesting: > > duration=485s, n_packets=0, n_bytes=0, > priority=180005,arp,arp_tpa=192.168.56.103,arp_op=2,actions=NORMAL > > I understand that this rule is saying that there are no matches on ARP > Request to the controller from other switches. But this is wrong because we > are seeing the ARP Request on the interface. As I said in my previous > email, eventually something changes and the rules starts to match. > > Is this behavior correct?
Without thinking about what you specifically are pointing at, normally it should only take a few seconds to connect to a controller, even through a second Open vSwitch running in in-band mode. Now, one thing I've noticed over the last few weeks is that I've been having some trouble with the in-band setup in my own set of test VMs. I haven't had a chance to fully investigate, but along with your report, I wonder whether there's been some regression in the in-band control implementation. What version of Open vSwitch are you using? (I normally test the latest from the master branch.) _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
