yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #84218
[Bug 1897637] Re: ovs firewall: mac learning of dest VM mac not working
Reviewed: https://review.opendev.org/754867
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=8fc80b7e132031d18c787b5be582c146d262de74
Submitter: Zuul
Branch: master
commit 8fc80b7e132031d18c787b5be582c146d262de74
Author: Moshe Levi <moshele@xxxxxxxxxxxx>
Date: Tue Sep 29 00:58:54 2020 +0300
ovs firewall: fix mac learning on the ingress rule table when ovs offload enabled
In RULES_INGRESS_TABLE table 82 there is a rule for allow established and
related connections. The current rule sends the packet directly to the dest
port without doing a mac learning. This is causing ovs to age out the dest mac
of the remote VM and causing the rule to be changed in flood rule. For the normal
case it fine as they try to avoid high cpu. ovs hardware offload reduce cpu usage
by moving some of the packet processing to nic and flood rule is not offloaded,
therefore it prefre to use the NORMAL action to avoid the flood rule.
We also keep the same logic as today when using explicitly_egress_direct=True
which avoid NORMAL action in the entire pipeline.
Closes-Bug: #1897637
Change-Id: I9b611d62be5d0529e8b35e3d8280baa5be54bc2b
** Changed in: neutron
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1897637
Title:
ovs firewall: mac learning of dest VM mac not working
Status in neutron:
Fix Released
Bug description:
I have using neutron master with ovs firewall driver and ovs 2.13
I have 2 compute nodes and VM on each one of them
both VM configure security groups which allow ingress and egress of tcp traffic
I running iperf testing for tcp connection tracking
we traffic start I see the following rule:
ufid:58ea9ecf-9fe5-4662-ae46-be4b7540d9c5,
skb_priority(0/0),skb_mark(0/0),ct_state(0x2/0x2),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),recirc_id(0x15),dp_hash(0/0),in_port(p4p2_11),packet_type(ns=0/0,id=0/0),eth(src=fa:16:3e:9e:77:5c,dst=fa:16:3e:35:c0:68),eth_type(0x0800),ipv4(src=0.0.0.0/0.0.0.0,dst=0.0.0.0/0.0.0.0,proto=0/0,tos=0/0x3,ttl=0/0,frag=no),
packets:7151296, bytes:64459680961, used:0.420s, offloaded:yes, dp:tc,
actions:set(tunnel(tun_id=0x1,src=172.16.0.148,dst=172.16.0.147,ttl=64,tp_dst=4789,flags(key))),vxlan_sys_4789
This is the fdb table of the br-int with "ovs-appctl fdb/show br-int"
port VLAN MAC Age
5 3 fa:16:3e:35:c0:68 97
6 3 fa:16:3e:9e:77:5c 0
As you can see the dest mac of the remote VM is Age increasing and
when it get to 300s which is the default age time in the ovs the mac
will disappear and the rule above will changed to flood rule.
ufid:b2967a14-aa26-433a-8df1-1cc00ef662e7,
skb_priority(0/0),skb_mark(0/0),ct_state(0x2/0x2),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),recirc_id(0x12),dp_hash(0/0),in_port(p4p2_11),packet_type(ns=0/0,id=0/0),eth(src=fa:16:3e:9e:77:5c,dst=fa:16:3e:35:c0:68),eth_type(0x0800),ipv4(src=0.0.0.0/0.0.0.0,dst=0.0.0.0/0.0.0.0,proto=0/0,tos=0/0x3,ttl=0/0,frag=no),
packets:23004560, bytes:204398890734, used:0.000s, dp:tc,
actions:push_vlan(vid=1,pcp=0),br-
int,set(tunnel(tun_id=0x1,src=172.16.0.148,dst=172.16.0.147,ttl=64,tp_dst=4789,flags(key))),pop_vlan,vxlan_sys_4789
This is the fdb table of the br-int with "ovs-appctl fdb/show br-int"
port VLAN MAC Age
9 1 fa:16:3e:9e:77:5c 0
The flood rule is breaking the offload.
see like RULES_INGRESS_TABLE table 82 is output the dest port without doing the Normal action. if we change the openflow of this table from:
table=82, n_packets=147206831, n_bytes=11772233989, priority=50,ct_state=+est-rel+rpl,ct_zone=1,ct_mark=0,reg5=0x9 actions=output:"p4p2_11"
to:
cookie=0x1e1cc3048de6c562, duration=196.708s, table=82, n_packets=145661342, n_bytes=11670250023, priority=50,ct_state=+est-rel+rpl,ct_zone=1,ct_mark=0,reg5=0x9 actions=mod_vlan_vid:1,NORMAL
the problem will be solved.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1897637/+subscriptions
References