-----Original Message----- From: Justin Pettit [mailto:[email protected]] Sent: Tuesday, September 17, 2013 2:37 PM To: Crasta Denis-B22176 Cc: '[email protected]' Subject: Re: [ovs-discuss] Too granular megaflows
On Sep 17, 2013, at 1:23 PM, Crasta Denis-B22176 <[email protected]> wrote: > This situation is observed with traffic between hosts on same network. The > test setup is as follows: > * Openvswitch with megaflow support in openstack/neutron environment > * Created a private network with 3 VMs on that network > * Create traffic between them and observe megaflows pushed to datapath > > The relevant openflow rule was this: > stack@openstk-x86-compute:~/devstack$ sudo ovs-ofctl dump-flows br-int > NXST_FLOW reply (xid=0x4): > cookie=0x0, duration=41004.845s, table=0, n_packets=908, > n_bytes=102701, idle_age=1, priority=1 actions=NORMAL > > When we start traffic from VM1 to VM2, we observe the following ipv4 flows in > the datapath. > stack@openstk-x86-compute:~/devstack$ sudo ovs-dpctl dump-flows > skb_priority(0),in_port(4),eth(src=fa:16:3e:73:c5:22,dst=fa:16:3e:e1:e > 9:eb),eth_type(0x0800),ipv4(src=11.1.1.2/0.0.0.0,dst=11.1.1.5/0.0.0.0, > proto=1/0,tos=0/0,ttl=64/0,frag=no/0xff), packets:1998, bytes:195804, > used:0.896s, actions:6 > skb_priority(0),in_port(6),eth(src=fa:16:3e:e1:e9:eb,dst=fa:16:3e:73:c > 5:22),eth_type(0x0800),ipv4(src=11.1.1.5/0.0.0.0,dst=11.1.1.2/0.0.0.0, > proto=1/0,tos=0/0,ttl=64/0,frag=no/0xff), packets:1998, bytes:195804, > used:0.896s, actions:4 > > Similar set of flows is created for every communicating pair of VMs. This is > because of not having wildcards on Ethernet addresses in the pushed flow. > When there are a large number of communicating nodes on the same network, > this can give rise to large number of datapath flows. > > Is it possible to remove unwildcarding for this case? I'm not sure how that would be possible. If you select the "normal" action, then OVS is doing mac learning. We have to un-wildcard the destination Ethernet address in order to properly determine where to send the packet. We un-wildcard the source Ethernet address because we want to learn MAC addresses. If you're very worried about the number of flows and you know where all the addresses are, I suppose you could manually program the userspace flow table and not use the "normal" action, but you'll also need to handle things like BUM traffic properly. [denis.crasta] OK, now I understand. Unwildcarding is necessary if learning and switching are performed using 1 openflow table. I did try adding my own rules without "normal" action, so that traffic destined to a VM was sent on appropriate port. These rules had a mask on eth_src to allow any src mac; eth_dst was hardcoded to the VMs MAC address. For the 3 VM case, 3 rules added were: sudo ovs-ofctl add-flow br-int table=0,priority=101,dl_src=fa:16:3e:00:00:00/ff:ff:ff:00:00:00,dl_dst=fa:16:3e:73:c5:22,dl_type=0x800,nw_src=11.1.1.0/24,nw_dst=11.1.1.0/24,action=4 sudo ovs-ofctl add-flow br-int table=0,priority=102,dl_src=fa:16:3e:00:00:00/ff:ff:ff:00:00:00,dl_dst=fa:16:3e:f0:c3:b8,dl_type=0x800,nw_src=11.1.1.0/24,nw_dst=11.1.1.0/24,action=5 sudo ovs-ofctl add-flow br-int table=0,priority=103,dl_src=fa:16:3e:00:00:00/ff:ff:ff:00:00:00,dl_dst=fa:16:3e:e1:e9:eb,dl_type=0x800,nw_src=11.1.1.0/24,nw_dst=11.1.1.0/24,action=6 where the VM/eth0 ip addresses were 11.1.1.2, 11.1.1.4, 11.1.1.5, ovs ports were 4,5,6, and mac addresses were fa:16:3e:73:c5:22, fa:16:3e:f0:c3:b8, fa:16:3e:e1:e9:eb With these rules, the flow pushed to DP had action as drop as shown below. skb_priority(0),in_port(4),eth(src=fa:16:3e:73:c5:22/ff:ff:ff:00:00:00,dst=fa:16:3e:e1:e9:eb/ff:ff:ff:ff:ff:ff),eth_type(0x0800),ipv4(src=11.1.1.2/255.255.255.0,dst=11.1.1.5/255.255.255.0,proto=1/0,tos=0/0,ttl=64/0,frag=no/0xff), packets:29, bytes:2842, used:0.600s, actions:drop <== observed when ping initiated from 11.1.1.2 => 11.1.1.5 skb_priority(0),in_port(6),eth(src=fa:16:3e:e1:e9:eb/ff:ff:ff:00:00:00,dst=fa:16:3e:73:c5:22/ff:ff:ff:ff:ff:ff),eth_type(0x0800),ipv4(src=11.1.1.5/255.255.255.0,dst=11.1.1.2/255.255.255.0,proto=1/0,tos=0/0,ttl=64/0,frag=no/0xff), packets:19, bytes:1862, used:0.336s, actions:drop <== observed when ping initiated from 11.1.1.5 => 11.1.1.2 If I change the ofctl action in the added rules to normal, then traffic passes normally. Any quick hints you can provide will help us understand what is happening. Denis --Justin _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
