Bug 1660256
| Summary: | Open vSwitch LOCAL Mac address of internal interface gets overwritten by external MAC in OVS FDB | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Andreas Karis <akaris> |
| Component: | openvswitch | Assignee: | Eelco Chaudron <echaudro> |
| Status: | CLOSED DEFERRED | QA Contact: | qding |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 7.7 | CC: | akaris, atragler, fleitner, ovs-qe, qding, tredaelli |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-02-19 14:26:56 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1597752 | ||
| Bug Blocks: | |||
|
Description
Andreas Karis
2018-12-17 23:58:54 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 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. 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). 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 (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. |