Re: [openstack-dev] [Neutron] ARP spoofing in VLAN aware VMs

[Bence Romsics]

Hi Kuba,

On Fri, Sep 30, 2016 at 3:38 PM, Jakub Libosvar  wrote:
> The issue was with subports having different MAC addresses
> than MAC address of the parent port. Packets leaving virtual instance via
> VLAN interfaces (e.g. eth0.1) have always source MAC address of VLAN parent
> interface (e.g. eth0).

Despite that being the default behavior do you consider that valid
use? I mean I would consider either (a) valid or (b) valid, but not
their combinations:

(a)
create port0
create port1 with same mac
create trunk with parent port0 and subport port1
boot instance with port0
bring up subport vlan interfaces only specifying vlan ids

(b)
create port0
create port1 with autoallocated (almost always different) mac
create trunk with parent port0 and subport port1
boot instance with port0
bring up subport vlan interfaces specifying vlan ids *and mac addresses*

Cheers,
Bence

ps. For being more specific please see the beginning of this CLI
example: https://wiki.openstack.org/wiki/Neutron/TrunkPort#CLI_usage_example

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] ARP spoofing in VLAN aware VMs

[Jakub Libosvar]

Hi all,

I promised Armando a braindump of this issue so here it comes:
During my work on fullstack test for VLAN aware VMs I ran into issues 
with ARP spoofing. The issue was with subports having different MAC 
addresses than MAC address of the parent port. Packets leaving virtual 
instance via VLAN interfaces (e.g. eth0.1) have always source MAC 
address of VLAN parent interface (e.g. eth0).


This doesn't play nice when arp spoofing from OVS agent is used.

For example here parent port has MAC fa:16:3e:8d:4d:45 and VLAN 
interface has fa:16:3e:8d:5d:13. Trunk patch port is port 2 and subport 
patch port is 3. Tagged outgoing packet from VM will have source MAC set 
to fa:16:3e:8d:4d:45 but will come to integration bridge from port 3. 
And thus marked rule below won't get matched.


 cookie=0xa849678518c226b1, duration=545.317s, table=24, n_packets=2, 
n_bytes=92, idle_age=530, priority=2,arp,in_port=3,arp_spa=192.168.0.11 
actions=resubmit(,25)
 cookie=0xa849678518c226b1, duration=545.080s, table=24, n_packets=4, 
n_bytes=168, idle_age=531, priority=2,arp,in_port=2,arp_spa=10.0.0.3 
actions=resubmit(,25)
 cookie=0xa849678518c226b1, duration=554.554s, table=24, n_packets=5, 
n_bytes=230, idle_age=525, priority=0 actions=drop


 cookie=0xa849678518c226b1, duration=545.437s, table=25, n_packets=0, 
n_bytes=546, idle_age=530, priority=2,in_port=3,dl_src=fa:16:3e:8d:5d:13 
actions=NORMAL<--- This rule won't be matched.
 cookie=0xa849678518c226b1, duration=545.204s, table=25, n_packets=19, 
n_bytes=1430, idle_age=520, 
priority=2,in_port=2,dl_src=fa:16:3e:8d:4d:45 actions=NORMAL



The current fullstack test creates all ports attached to VM with the 
same MAC addresses and it works fine. But this doesn't work fine when 
OVS firewall is used as it contains a bug [1][2] where there can't be 
two same MAC addresses from different network used on a single hypervisor.



There was a second issue with port binding race but that turned up to be 
PEBKAC as update_port() was called before OVS port has been created.


Kuba

[1] https://bugs.launchpad.net/neutron/+bug/1626010
[2] https://bugs.launchpad.net/neutron/+bug/1593760

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev