Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1193224 - [RFE] Allow MAC Anti-Spoofing per interface instead of globally
Summary: [RFE] Allow MAC Anti-Spoofing per interface instead of globally
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: RFEs
Version: 3.4.0
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: ovirt-4.0.0-beta
: 4.0.0
Assignee: Alona Kaplan
QA Contact: Michael Burman
URL: https://www.ovirt.org/Features/Networ...
Whiteboard:
: 1255568 (view as bug list)
Depends On: 1317441
Blocks: 1164397 1254972 1255558
TreeView+ depends on / blocked
 
Reported: 2015-02-16 22:12 UTC by Robert McSwain
Modified: 2019-12-16 04:39 UTC (History)
22 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
With this update, the network filter has been enhanced to allow the administrator the ability to manage the network packet traffic to and from virtual machines. The required filter can now be specified on the vNIC profile via the web interface or the REST API. If no filter is specified and the 'EnableMACAntiSpoofingFilterRules' is enabled via engine-config tool the vNIC profile will use 'Enable MAC Anti Spoofing' as the default filter
Clone Of:
: 1317441 (view as bug list)
Environment:
Last Closed: 2016-08-23 20:22:49 UTC
oVirt Team: Network
Target Upstream Version:
sherold: Triaged+
mburman: testing_plan_complete+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2016:1743 0 normal SHIPPED_LIVE Red Hat Virtualization Manager 4.0 GA Enhancement (ovirt-engine) 2016-09-02 21:54:01 UTC
oVirt gerrit 51184 0 'None' MERGED engine: Introduce Network Filter Dao 2020-03-23 16:01:50 UTC
oVirt gerrit 51450 0 'None' MERGED restapi: Integrate network filter 2020-03-23 16:01:50 UTC
oVirt gerrit 52768 0 'None' MERGED engine: change VmInfoBuilder network filter logic 2020-03-23 16:01:50 UTC
oVirt gerrit 52770 0 'None' MERGED rest+engine: add default network filter id 2020-03-23 16:01:50 UTC
oVirt gerrit 52832 0 'None' MERGED engine: add network filter id validation 2020-03-23 16:01:50 UTC
oVirt gerrit 52906 0 'None' MERGED restapi: Integrate network filter id to vnic profile 2020-03-23 16:01:50 UTC
oVirt gerrit 56937 0 'None' MERGED api-model: Adding networkFilter to VnicProfile 2020-03-23 16:01:51 UTC
oVirt gerrit 57041 0 'None' MERGED engine: Adding 'network_filter_name' to vnic_profile_view 2020-03-23 16:01:51 UTC
oVirt gerrit 57042 0 'None' MERGED webadmin: adding 'network filter id' to add/edit vnic profile and table 2020-03-23 16:01:51 UTC
oVirt gerrit 57087 0 'None' MERGED engine: remove unused 'GetMinimalSupportedVersionByNetworkFilterName' 2020-03-23 16:01:51 UTC

Description Robert McSwain 2015-02-16 22:12:35 UTC
1. Proposed title of this feature request  
      [RFE] EnableMACAntiSpoofingFilterRules for virtual interfaces
      
     
    3. What is the nature and description of the request?  
      We use several pfsense boxes on RHEV to as Firewalls between our VLANs. It would be nice to use CARP. I know it is possible to use CARP with EnableMACAntiSpoofingFilterRules = True but I only would like to activate it for the interfaces of the virtual Firewalls, not globally. 

    4. Why does the customer need this? (List the business requirements here)  
      The pfsense machines are virtual machines on RHEV. Their purpose is to separate/manage the access between machines in different vlans (all on RHEV). The idea behind all this is to separate lab-machines from production and so on. I don't want to enable MacSpoofing for all the Machines nor any physical Interface on the Hypervisors but only for the virtual interface CARP should work over (lets say vm:pfsense0[1|2] interface:vlan1000_pfsync for example).
    5. How would the customer like to achieve this? (List the functional requirements here)  
      For example a checkbox in the "Edit Network Interfaces" mask of a virtual machine
    6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.  
      when checked --> EnableMACAntiSpoofingFilterRules = True
      else EnableMACAntiSpoofingFilterRules = False
    7. Is there already an existing RFE upstream or in Red Hat Bugzilla?  
      No      
    8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?  
      
    9. Is the sales team involved in this request and do they have any additional input?  
      No
   10. List any affected packages or components.  
       rhevm, vdsm
   11. Would the customer be able to assist in testing this functionality if implemented?  
       yes

Comment 2 Fabian Deutsch 2015-02-17 05:38:40 UTC
Moving this to vdsm, as it takes over network configuration after registration.

Comment 3 Dan Kenigsberg 2015-03-27 13:54:37 UTC
It seems that the customer asks to allow mac spoofing on particular VMs/devices. Is that correct? If not, please explain the request better.

This can be implemented today by:
- install vdsm-hook-macspoof on all hosts
- sudo engine-config -s "CustomDeviceProperties={type=interface;prop={$PREVIOUS_PROPERTIES;ifacemacspoof=^(true|false)$}}"
   to enable the ifacemacspoof custom property
- restart engine to make configuration effective
- there's a network you want to connect to, with mac spoofing. Define a vNIC profile on top of it, and set ifacemacspoof=true
- attach the vNIC profile to a vNIC. This vNIC is now allow to carry spoofed traffic


It would be a bit nicer to solve this request natively, with no hooks involved. This could be done by allowing the user to choose a filter name per vNIC profile.

Comment 4 Lior Vernia 2015-04-01 14:43:06 UTC
MAC spoofing can already be turned on/off on a per-profile basis, by following Dan's instructions and setting the ifacemacspoof property via the custom properties widget in the vNIC profile dialog.

Please re-open if it turns out I misunderstood your needs and this doesn't satisfy them...

Comment 10 Robert McSwain 2015-12-31 14:34:04 UTC
Dan,

While this bug is open for 3.4, my customer got a chance to try your suggestion and it worked until 3.5 came out. Since the he's said this

[In RHEV 3.5] the Syntax seems to be wrong:

[root@engine ~]# engine-config -s "CustomDeviceProperties={type=interface;prop={$PREVIOUS_PROPERTIES;ifacemacspoof=^(true|false)$}}"
Please select a version:
1. 3.0
2. 3.1
3. 3.2
4. 3.3
5. 3.5
6. 3.4
5
Cannot set value {type=interface;prop={;ifacemacspoof=^(true|false)$}} to key CustomDeviceProperties. Invalid syntax, custom device properties specification should conform to \{type=(disk|interface|video|sound|controller|balloon|channel|redir|console|rng|smartcard|watchdog);prop=\{((([a-z_A-Z0-9])+)=(([^;])*)(;(([a-z_A-Z0-9])+)=(([^;])*))*;?)?\}\}[;]?

We updated to RHEV 3.5 now... did the Syntax change?

Comment 11 Dan Kenigsberg 2015-12-31 16:04:47 UTC
You should set the value of the PREVIOUS_PROPERTIES shell variable prior to using it

PREVIOUS_PROPERTIES=`engine-config -g CustomDeviceProperties --cver=3.5`

if it ends up empty (as it seems from you comment) you should drop the semicolon following it.

Does this help?

Comment 12 Robert McSwain 2016-01-04 22:58:02 UTC
Dan,

Is this the proper way to do this?


[root@engine ~]# PREVIOUS_PROPERTIES=`engine-config -g CustomDeviceProperties --cver=3.5`
[root@engine ~]# engine-config -s "CustomDeviceProperties={type=interface prop={$PREVIOUS_PROPERTIES;ifacemacspoof=^(true|false)$}}"
Please select a version:
1. 3.0
2. 3.1
3. 3.2
4. 3.3
5. 3.5
6. 3.4
5
Cannot set value {type=interface prop={{type=interface;prop={SecurityGroups=^(?:(?:[0-9a-fA-F]{8}-(?:[0-9a-fA-F]{4}-){3}[0-9a-fA-F]{12}, *)*[0-9a-fA-F]{8}-(?:[0-9a-fA-F]{4}-){3}[0-9a-fA-F]{12}|)$}};ifacemacspoof=^(true|false)$}} to key CustomDeviceProperties. Invalid syntax, custom device properties specification should conform to \{type=(disk|interface|video|sound|controller|balloon|channel|redir|console|rng|smartcard|watchdog);prop=\{((([a-z_A-Z0-9])+)=(([^;])*)(;(([a-z_A-Z0-9])+)=(([^;])*))*;?)?\}\}[;]?
[root@engine ~]# engine-config -s "CustomDeviceProperties={type=interface prop={$PREVIOUS_PROPERTIES ifacemacspoof=^(true|false)$}}"
Please select a version:
1. 3.0
2. 3.1
3. 3.2
4. 3.3
5. 3.5
6. 3.4
5
Cannot set value {type=interface prop={{type=interface;prop={SecurityGroups=^(?:(?:[0-9a-fA-F]{8}-(?:[0-9a-fA-F]{4}-){3}[0-9a-fA-F]{12}, *)*[0-9a-fA-F]{8}-(?:[0-9a-fA-F]{4}-){3}[0-9a-fA-F]{12}|)$}} ifacemacspoof=^(true|false)$}} to key CustomDeviceProperties. Invalid syntax, custom device properties specification should conform to \{type=(disk|interface|video|sound|controller|balloon|channel|redir|console|rng|smartcard|watchdog);prop=\{((([a-z_A-Z0-9])+)=(([^;])*)(;(([a-z_A-Z0-9])+)=(([^;])*))*;?)?\}\}[;]?

Comment 13 Yaniv Lavi 2016-01-06 13:43:28 UTC
*** Bug 1255568 has been marked as a duplicate of this bug. ***

Comment 15 Mike McCune 2016-03-28 23:08:19 UTC
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions

Comment 16 Michael Burman 2016-06-27 08:51:26 UTC
Verified on 4.0.0.6-0.1.el7ev

Comment 18 errata-xmlrpc 2016-08-23 20:22:49 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2016-1743.html


Note You need to log in before you can comment on or make changes to this bug.