1. when i installed 2.3.1, i had the build script run all the self tests and they passed.
2. i created a low priority rule (to send to controller) and put in table 0. the 'n_packets' does increment for my rule and the drop rule in table 254 but the ping with reactive forwarding still does not work in 2.3.0. sudo ovs-appctl bridge/dump-flows s1 duration=886s, n_packets=377, n_bytes=66379, priority=0,actions=CONTROLLER:6633 << i added this rule; it doesn't help table_id=254, duration=1132s, n_packets=0, n_bytes=0, priority=1,actions=drop table_id=254, duration=1132s, n_packets=0, n_bytes=0, priority=0,reg0=0x3,actions=drop table_id=254, duration=1132s, n_packets=2, n_bytes=168, priority=0,reg0=0x1,actions=controller(reason=no_match) table_id=254, duration=1132s, n_packets=29, n_bytes=5077, priority=0,reg0=0x2,actions=drop table_id=254, duration=1132s, n_packets=0, n_bytes=0, priority=2,recirc_id=0,actions=resubmit(,0) 3. i have seen people mention this problem (packet_in does not work in 2.3.0) in the google group for floodlight SDN controller and the mail list for mininet. On 2014-12-10 16:33, Ben Pfaff wrote: > No, not intentionally at any rate. We have tests that should check > that packet-ins > work. > > What if you add a low-priority catch-all rule with a controller action? > > Has anyone else on the list noticed some kind of change in packet-in behavior? > > On Wed, Dec 10, 2014 at 2:30 PM, Rod N. Melton <[email protected]> wrote: > >> using OF 1.0 with OpenDaylight, ubuntu 14.04 packet_in worked correctly (for >> reactive forwarding) in 2.1.0 but not in 2.3.0 (or 2.3.1). Were there >> changes made in 2.3.0 which would prevent the packet_in (for >> reason=no_match) from being sent to controller? thx, Rod On 2014-12-10 >> 14:59, Ben Pfaff wrote: On Wed, Dec 10, 2014 at 02:22:42PM -0600, Rod N. >> Melton wrote: when using ovs 2.1.0 with mininet 2.1.0+ and i could count on >> packet_in/packet_out to make ping work when i had not put flow rules in the >> switch. 1. i noticed that with 2.1.0 there were these default rules in table >> 254 sudo ovs-appctl bridge/dump-flows s1 table_id=254, duration=344s, >> n_packets=0, n_bytes=0, priority=0,reg0=0x3,actions=drop table_id=254, >> duration=344s, n_packets=187, n_bytes=34082, >> priority=0,reg0=0x1,actions=controller(reason=no_match) table_id=254, >> duration=344s, N_PACKETS=0, n_bytes=0, priority=0,reg0=0x2,actions=drop and >> the 'n_packet' count stays at 0. 2. when i move to ovs 2.3.0 (or 2.3.1) (w ith same mininet) and build according to INSTALL.Debian file: h1 ping -c 1 h2 does not work. the switch(es) does not send up packet_in messages and the drop rules are INCREMENTING. sudo ovs-appctl bridge/dump-flows s1 table_id=254, duration=796s, n_packets=0, n_bytes=0, priority=1,actions=drop table_id=254, duration=796s, n_packets=0, n_bytes=0, priority=0,reg0=0x3,actions=drop table_id=254, duration=796s, n_packets=3, n_bytes=250, priority=0,reg0=0x1,actions=controller(reason=no_match) table_id=254, duration=796s, N_PACKETS=398, n_bytes=72307, priority=0,reg0=0x2,actions=drop table_id=254, duration=796s, n_packets=0, n_bytes=0, priority=2,recirc_id=0,actions=resubmit(,0) I think this drop rule is eating all my reactive routing and preventing the ping from working. Can anyone explain when this doesn't work as in ovs 2.1.0? These rules are an implementation detail. They are a symptom of the problem you're seeing, not the cause of it. You will have to look further to find the cause. _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss [1] Links: ------ [1] http://openvswitch.org/mailman/listinfo/discuss
_______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
