yahoo-eng-team team mailing list archive

[Ramu Ramamurthy <ramu.ramamurthy@xxxxxxxxxx>]

Public bug reported:


Scenario:
      MultiNic VM -----eth0 (192.168.100.44)
                               -----eth1 (192.168.0.10)
                               -----eth2 (192.168.20.10)

Test:
    Ping 192.168.0.10 does not work
    Ping 192.168.100.44 works

RootCause:
    default route on VM is pointing to eth0
    Ping requests arrive at VM on eth1, but the Ping responses go out of eth0
    Security AntiSpoofing rule drops this ping response, because, the IP address does not match

Fix:
    Provide a configurable knob in Security Groups or PortSecurity Extension to disable just the anti-spoofing rules,
     but keep the other ingress/egress filters.
    We dont want to disable security-groups entirely on such VMs

Notes:
    Workarounds include:  multiple default routes in the guest VM via linux route tables (works only on linux)

Any other ideas for a fix or a workaround ?

** 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/1417699

Title:
  Security Groups anti-spoofing rule blocks traffic on multi-nic VMs

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  
  Scenario:
        MultiNic VM -----eth0 (192.168.100.44)
                                 -----eth1 (192.168.0.10)
                                 -----eth2 (192.168.20.10)

  Test:
      Ping 192.168.0.10 does not work
      Ping 192.168.100.44 works

  RootCause:
      default route on VM is pointing to eth0
      Ping requests arrive at VM on eth1, but the Ping responses go out of eth0
      Security AntiSpoofing rule drops this ping response, because, the IP address does not match

  Fix:
      Provide a configurable knob in Security Groups or PortSecurity Extension to disable just the anti-spoofing rules,
       but keep the other ingress/egress filters.
      We dont want to disable security-groups entirely on such VMs

  Notes:
      Workarounds include:  multiple default routes in the guest VM via linux route tables (works only on linux)

  Any other ideas for a fix or a workaround ?

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