RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1660256 - Open vSwitch LOCAL Mac address of internal interface gets overwritten by external MAC in OVS FDB
Summary: Open vSwitch LOCAL Mac address of internal interface gets overwritten by exte...
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: openvswitch
Version: 7.7
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: rc
: ---
Assignee: Eelco Chaudron
QA Contact: qding
URL:
Whiteboard:
Depends On: 1597752
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-12-17 23:58 UTC by Andreas Karis
Modified: 2022-03-13 16:32 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-02-19 14:26:56 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Andreas Karis 2018-12-17 23:58:54 UTC 
Description of problem:
Open vSwitch LOCAL Mac address of internal interface gets overwritten by external MAC in OVS FDB

This may be on purpose, but it looks totally odd. Also, the LOCAL MAC address in the FDB times out, which seems odd to me, as well. I'd expect the LOCAL MAC address to be fix in the FDB and to have higher priority than frames from external ports coming in with the same MAC address.

This becomes problematic in network environments with loops in the external network. If OVS sends a frame from the internal port, and that frame gets looped somehow within the external network, then OVS's own FDB will overwrite the entry in the FDB.

Version-Release number of selected component (if applicable):
openvswitch-2.9.0-56.el7fdp.x86_64

Additional info:

Configure OVS and namespaces:
~~~
yum install openvswitch -y
systemctl start openvswitch
ovs-vsctl add-br br0  -- set bridge br0 other_config:hwaddr=00:11:22:33:44:55
ip link set dev br0 up
ip a a dev br0 192.168.123.10/24
ip link add ovs-if0 type veth peer name lx-if0
ip link set dev ovs-if0 up
ip netns add kernel
ip link set dev lx-if0 netns kernel
ip netns exec kernel ip link set dev lo up
ip netns exec kernel ip link set dev lx-if0 up
ovs-vsctl add-port br0 ovs-if0
~~~

Install scapy:
~~~
yum install python-virtualenv
virtualenv scapy
source scapy/bin/activate
pip install scapy
ip netns exec kernel scapy
~~~

Broadcast ping from br0 internal interface:
~~~
ping 192.168.123.255 -b
~~~

Verify FDB:
~~~
[root@rhel7 ~]# ovs-appctl fdb/show br0
 port  VLAN  MAC                Age
LOCAL     0  00:11:22:33:44:55    2
~~~

Send frame with same MAC from scapy:
~~~
>>> sendp(Ether(src="00:11:22:33:44:55",dst="ff:ff:ff:ff:ff")/IP(dst="255.255.255.255"), iface="lx-if0")
WARNING: No route found (no default route?)
.
Sent 1 packets.
>>> 
~~~

Show FDB:
~~~
[root@rhel7 ~]# ovs-appctl fdb/show br0
 port  VLAN  MAC                Age
    1     0  00:11:22:33:44:55   17
~~~
Comment 2 Flavio Leitner 2018-12-31 16:07:02 UTC 
AFAIK, OVS does not match with port's MAC when processing FDB, which means it will blindly assume that if the packet is received, then the MAC address is correct and so it could be learned.

It sounds like it could be fixed, but not sure because OVS might have a flow table changing MAC addresses and at some later point use ACTION NORMAL. Then we might break some existing environments. Just a quick though.

On another hand, I am quite sure Linux Bridge does match with port's MAC.

fbl
Comment 3 Eelco Chaudron 2019-02-05 13:06:40 UTC 
1) Looking at this, the simple solution would be to add some drop rules for the other physical ports in the bridge. This assumes there are only a limited set of ports in the bridge.

2) The other solution is to support static FDB entries, this way a rule could be added for this specific bridge/vlan based on the scenario. There is already a BZ open for this, BZ1597752. Not sure if this will be accepted upstream, as static FDB entries have been discussed before but where always declined as not needed.

3) A fully automated solution would at least require support for static FDB entries (so that's why I set the dependency for this BZ). But we can not just install the entries on the creation of the bridge. This because the bridge can support up to 4K VLANs, and each VLAN needs its own entry. A solution would be to install it once the MAC is begin learned, however, this implies we need to compare the bridge MAC for each FDB addition we do. In addition, we need to clear all static entries if the bridge MAC changes, "ovs-vsctl set bridge ovs_pvp_br0 other_config:hwaddr=..."

We can move this BZ forward based on your feedback...

If 1 and/or 2 are enough, please close this BZ. If you think 3 should be the way forward, please change this BZ to an RFE which will depend on BZ1597752. Once this BZ gets approved upstream we can start working on this one.
Comment 4 Andreas Karis 2019-02-18 21:24:31 UTC 
The associated case was closed and wasn't blocked due to this. I told the customer to check for network loops.

It's just something that I noticed and found (and still find) odd if I take into consideration how "normal" hardware switches work.

Let's keep this open, very low prio, blocked on 1597752

If the feature sounds too odd / unfeasible, feel free to close this out. I'm good with a closed BZ as well, given that it'll remain visible and as such documents the "issue" (if there even is one).
Comment 5 Andreas Karis 2019-02-18 21:25:30 UTC 
I suppose at the same time that adding a flow as suggested in https://bugzilla.redhat.com/show_bug.cgi?id=1597752 should work as well, correct?

ovs-ofctl add-flow br0 dl_dst=$MAC,actions=$PORT
Comment 6 Eelco Chaudron 2019-02-19 09:50:55 UTC 
(In reply to Andreas Karis from comment #5)
> I suppose at the same time that adding a flow as suggested in
> https://bugzilla.redhat.com/show_bug.cgi?id=1597752 should work as well,
> correct?
> 
> ovs-ofctl add-flow br0 dl_dst=$MAC,actions=$PORT

Yes this will also work if it has a higher priority than the NORMAL rule.
Note You need to log in before you can comment on or make changes to this bug.