Perhaps somebody could give me the contents of their quantum node's "ovs-ofctl dump-flows br-tun" and I could figure out what mine *should* look like?
On Tue, Mar 12, 2013 at 4:24 PM, The King in Yellow <yellowk...@gmail.com>wrote: > Okay, I have worked around my problem-- but I don't quite understand it, > and hope somebody can help me. It appears to be a problem with the Open > vSwitch flows in br-tun on both compute and network. Here are the flows as > they are now, working. I have manually added the priority=5 lines. > Without those added manually on both sides, traffic from the guest's > doesn't work properly. > > root@os-network:~# ovs-ofctl dump-flows br-tun > NXST_FLOW reply (xid=0x4): > cookie=0x0, duration=5331.934s, table=0, n_packets=1111, n_bytes=171598, > priority=3,tun_id=0x1,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 > actions=mod_vlan_vid:1,output:1 > cookie=0x0, duration=3.119s, table=0, n_packets=6, n_bytes=496, > priority=5,dl_vlan=1 actions=NORMAL > cookie=0x0, duration=10.759s, table=0, n_packets=0, n_bytes=0, > priority=4,in_port=1,dl_vlan=1 actions=set_tunnel:0x1,NORMAL > cookie=0x0, duration=5331.725s, table=0, n_packets=0, n_bytes=0, > priority=3,tun_id=0x1,dl_dst=fa:16:3e:36:2e:54 actions=mod_vlan_vid:1,NORMAL > cookie=0x0, duration=5331.898s, table=0, n_packets=0, n_bytes=0, > priority=3,tun_id=0x1,dl_dst=fa:16:3e:e2:38:da actions=mod_vlan_vid:1,NORMAL > cookie=0x0, duration=5332.499s, table=0, n_packets=3502, n_bytes=286312, > priority=1 actions=drop > root@os-network:~# > > root@os-compute-01:~# ovs-ofctl dump-flows br-tun > NXST_FLOW reply (xid=0x4): > cookie=0x0, duration=22348.618s, table=0, n_packets=20165, > n_bytes=991767, > priority=3,tun_id=0x1,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 > actions=mod_vlan_vid:1,output:1 > cookie=0x0, duration=177.949s, table=0, n_packets=151, n_bytes=21830, > priority=5,dl_vlan=1 actions=NORMAL > cookie=0x0, duration=411.826s, table=0, n_packets=80, n_bytes=9566, > priority=4,in_port=1,dl_vlan=1 actions=set_tunnel:0x1,NORMAL > cookie=0x0, duration=22348.567s, table=0, n_packets=1111, n_bytes=252718, > priority=3,tun_id=0x1,dl_dst=fa:16:3e:ee:9e:b2 actions=mod_vlan_vid:1,NORMAL > cookie=0x0, duration=22348.128s, table=0, n_packets=1107, n_bytes=123234, > priority=3,tun_id=0x1,dl_dst=fa:16:3e:8d:6d:13 actions=mod_vlan_vid:1,NORMAL > cookie=0x0, duration=22348.353s, table=0, n_packets=1494, n_bytes=124036, > priority=3,tun_id=0x1,dl_dst=fa:16:3e:95:94:9c actions=mod_vlan_vid:1,NORMAL > cookie=0x0, duration=22347.912s, table=0, n_packets=3334, n_bytes=425776, > priority=3,tun_id=0x1,dl_dst=fa:16:3e:7b:e3:ee actions=mod_vlan_vid:1,NORMAL > cookie=0x0, duration=22349.47s, table=0, n_packets=879, n_bytes=75279, > priority=1 actions=drop > root@os-compute-01:~# > > Here is a sample packet that would have been blocked, sniffed in GRE. The > yellow background (if you can see the color) is the GRE header. Inside the > GRE payload, MAC (red) is1272.590f.cf56, and MAC (orange) is fa16.3e7b.e3ee > are exchanging ping packets. > > 0000 00 50 56 81 44 e7 00 50 56 81 25 73 08 00 45 00 .PV.D..PV.%s..E. > 0010 00 82 64 93 40 00 40 2f ad a3 0a 0a 0a 02 0a 0a ..d.@.@/........ > 0020 0a 01 20 00 65 58 00 00 00 00 12 72 59 0f cf 56 .. .eX.....rY..V > 0030 fa 16 3e 95 94 9c 81 00 00 01 08 00 45 00 00 54 ..>.........E..T > 0040 00 00 40 00 40 01 1d 00 0a 05 05 04 0a 2a 04 77 ..@.@........*.w > 0050 08 00 00 9f 0e 17 00 08 17 87 3f 51 00 00 00 00 ..........?Q.... > 0060 d3 96 00 00 00 00 00 00 10 11 12 13 14 15 16 17 ................ > 0070 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 ........ !"#$%&' > 0080 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 ()*+,-./01234567 > > 0000 00 50 56 81 25 73 00 50 56 81 44 e7 08 00 45 00 .PV.%s.PV.D...E. > 0010 00 82 95 e3 40 00 40 2f 7c 53 0a 0a 0a 01 0a 0a ....@.@/|S...... > 0020 0a 02 20 00 65 58 00 00 00 00 fa 16 3e 95 94 9c .. .eX......>... > 0030 12 72 59 0f cf 56 81 00 00 01 08 00 45 00 00 54 .rY..V......E..T > 0040 1e 24 00 00 3e 01 40 dc 0a 2a 04 77 0a 05 05 04 .$..>.@..*.w.... > 0050 00 00 08 9f 0e 17 00 08 17 87 3f 51 00 00 00 00 ..........?Q.... > 0060 d3 96 00 00 00 00 00 00 10 11 12 13 14 15 16 17 ................ > 0070 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 ........ !"#$%&' > 0080 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 ()*+,-./01234567 > > The source MAC does match the MAC for his gateway, 10.5.5.1: > > root@os-network:~# ovs-ofctl show br-int > OFPT_FEATURES_REPLY (xid=0x1): ver:0x1, dpid:0000862cf391d546 > > n_tables:255, n_buffers:256 > features: capabilities:0xc7, actions:0xfff > 1(qr-9f9041ce-65): addr:12:72:59:0f:cf:56 > config: 0 > state: 0 > : > > ...which is the understandable problem. That MAC address is not > specifically entered in the OVS bridge br-tun. Any clue why? This is > across reboots, service restarts, etc... I guess it is the > /etc/openswitch/conf.db that is corrupted? > > What I don't understand at this point is why removing the priority 5 flow > on the compute br-tun stops everything as well. fa16.3e95.949c *IS* > specified in the computer br-tun's flows. Here, you can the flows on > compute's br-tun. It did not begin to allow packets until I added the > priority flow 5 back in. > > root@os-compute-01:~# ovs-ofctl del-flows br-tun --strict > 'priority=5,dl_vlan=1' > root@os-compute-01:~# ovs-ofctl dump-flows br-tun > NXST_FLOW reply (xid=0x4): > cookie=0x0, duration=22143.277s, table=0, n_packets=20165, > n_bytes=991767, > priority=3,tun_id=0x1,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 > actions=mod_vlan_vid:1,output:1 > cookie=0x0, duration=206.485s, table=0, n_packets=50, n_bytes=6130, > priority=4,in_port=1,dl_vlan=1 actions=set_tunnel:0x1,NORMAL > cookie=0x0, duration=22143.226s, table=0, n_packets=1111, n_bytes=252718, > priority=3,tun_id=0x1,dl_dst=fa:16:3e:ee:9e:b2 actions=mod_vlan_vid:1,NORMAL > cookie=0x0, duration=22142.787s, table=0, n_packets=1107, n_bytes=123234, > priority=3,tun_id=0x1,dl_dst=fa:16:3e:8d:6d:13 actions=mod_vlan_vid:1,NORMAL > cookie=0x0, duration=22143.012s, table=0, n_packets=1494, n_bytes=124036, > priority=3,tun_id=0x1,dl_dst=fa:16:3e:95:94:9c actions=mod_vlan_vid:1,NORMAL > cookie=0x0, duration=22142.571s, table=0, n_packets=3334, n_bytes=425776, > priority=3,tun_id=0x1,dl_dst=fa:16:3e:7b:e3:ee actions=mod_vlan_vid:1,NORMAL > cookie=0x0, duration=22144.129s, table=0, n_packets=846, n_bytes=73761, > priority=1 actions=drop > root@os-compute-01:~# ovs-ofctl add-flow br-tun 'priority=5,dl_vlan=1 > actions=NORMAL' > root@os-compute-01:~# > > Return traffic on the compute node should his this flow, correct? So, it > looks to me like both sides are good...I'm not sure what I'm missing there. > > Thirdly, why is br-tun locked down so with such specific flows? > Especially when br-int is acting as a normal switch > > root@os-network:~# ovs-ofctl dump-flows br-int > NXST_FLOW reply (xid=0x4): > cookie=0x0, duration=4509.278s, table=0, n_packets=9128, n_bytes=977139, > priority=1 actions=NORMAL > root@os-network:~# > > Is this some requirement with the OVS GRE tunnels? > > > Would these questions be better suited for another list? > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
