yahoo-eng-team team mailing list archive

[Ridsai <1787908@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

Release:  Pike
Environment:  Ubuntu 16.04
Neutron ML2 Plugin:  Linux Bridge Vlan
Problem:  cannot turn off arp_spoofing on linuxbridge ml2

Background:
According to Pike release notes linuxbridge agent parameter “prevent_arp_spoofing” has been depreciated.  Instead, in order to disable arp_spoofing (ebtables) on the Port, the Port’s attribute “port_security_enabled” should be set to false and no security group is on that port.    Further, the Pike documentation says that the Network (and Port) “port_security_enabled” is True by default and the Port’s value if not explicitly set will default to the Networks value”.  

Problem:
Given the linuxBridge_agent config below and the Network and Port attribute “port_security_enabled” set to False, with no security group arp_spoofing is being established on the port.    Further we are finding that the default “port_security_enabled” value for Networks and Ports are actually set to “false” contrary to the documentation.   

Diagnostics:
We’ve been able to trace the port’s “port_security_enabled” value through the plugin and we’ve found that at some point that we haven’t identified yet the value is being set from false to true.    In the module, arp_protect.py::setup_arp_spoofing_proteciton() we’ve printed out the port’s value and have prior to the if statement and have found that the value has been previously set to True, which at this point drops through the if statement to enable ebtables values on the port.  We’ve tried to trace the value back up the stack but have not found where it is being reset.    Any thoughts?   Is this a bug or are we missing a configuration somewhere?  As a work-around we will set the value to false in our environment.   


++ linuxbridge_agent.ini
[linux_bridge]
physical_interface_mappings=physnet1:eth2,physnet2:eth1,physnet3:eth3

[vxlan]
enable_vxlan=false

[agent]
prevent_arp_spoofing=false

[ml2_type_vlan]
network_vlan_ranges=physnet1:55:55,physnet2:50:50,physnet3:210:215

[ml2]
type_drivers=vlan, local
mechanism_drivers=linuxbridge

[securitygroup]
enable_security_group=false
firewall_driver = neutron.agent.firewall.NoopFirewallDriver

** Affects: neutron
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1787908

Title:
  ARP_spoofing on linuxbridge ml2

Status in neutron:
  New

Bug description:
  Release:  Pike
  Environment:  Ubuntu 16.04
  Neutron ML2 Plugin:  Linux Bridge Vlan
  Problem:  cannot turn off arp_spoofing on linuxbridge ml2

  Background:
  According to Pike release notes linuxbridge agent parameter “prevent_arp_spoofing” has been depreciated.  Instead, in order to disable arp_spoofing (ebtables) on the Port, the Port’s attribute “port_security_enabled” should be set to false and no security group is on that port.    Further, the Pike documentation says that the Network (and Port) “port_security_enabled” is True by default and the Port’s value if not explicitly set will default to the Networks value”.  

  Problem:
  Given the linuxBridge_agent config below and the Network and Port attribute “port_security_enabled” set to False, with no security group arp_spoofing is being established on the port.    Further we are finding that the default “port_security_enabled” value for Networks and Ports are actually set to “false” contrary to the documentation.   

  Diagnostics:
  We’ve been able to trace the port’s “port_security_enabled” value through the plugin and we’ve found that at some point that we haven’t identified yet the value is being set from false to true.    In the module, arp_protect.py::setup_arp_spoofing_proteciton() we’ve printed out the port’s value and have prior to the if statement and have found that the value has been previously set to True, which at this point drops through the if statement to enable ebtables values on the port.  We’ve tried to trace the value back up the stack but have not found where it is being reset.    Any thoughts?   Is this a bug or are we missing a configuration somewhere?  As a work-around we will set the value to false in our environment.   


  ++ linuxbridge_agent.ini
  [linux_bridge]
  physical_interface_mappings=physnet1:eth2,physnet2:eth1,physnet3:eth3

  [vxlan]
  enable_vxlan=false

  [agent]
  prevent_arp_spoofing=false

  [ml2_type_vlan]
  network_vlan_ranges=physnet1:55:55,physnet2:50:50,physnet3:210:215

  [ml2]
  type_drivers=vlan, local
  mechanism_drivers=linuxbridge

  [securitygroup]
  enable_security_group=false
  firewall_driver = neutron.agent.firewall.NoopFirewallDriver

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1787908/+subscriptions