Use the IP from allow address pair to launch VM will cause issue if the ip in the same subnet

Bug #1697334 reported by zhaobo
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
New
Undecided
zhaobo

Bug Description

repro
------------
1. net with a subnet '10.0.0.0/26'
2. specify a IP address(10.0.0.10) in 'allowed_address_pairs' fields to create a port with the net. called Port1
3. specify the same IP address(10.0.0.10) in 'fixed_ip' fields to create another port with the net. called Port2
4. launch VMs with both of the ports. Port1 -- VM1 Port2 -- VM2.

Now VM1 and VM2 will use the same IP address(10.0.0.10) to access the external enviroment, VM2 is OK, but VM1 is not.
Just an example, if we set interface in a router, the default gateway of this subnet is 10.0.0.1. We can find the '10.0.0.10' ARP entry of the router namespace is VM2's port. So VM2 ping gateway is OK, but VM1 not. And the packets on gateway port'qr-XXXXX' we can see. All the Ping request packets which use 10.0.0.10 as Src ip from VM1 are accepted, but the qrouter namespace will send the Ping resp to VM2. I don't think this is a valid case.

The reproduce step is in comment #5. And the test env is DVR

zhaobo (zhaobo6)
Changed in neutron:
assignee: nobody → zhaobo (zhaobo6)
Revision history for this message
Trevor McCasland (twm2016) wrote :

Can you update your step by step instructions to have more detail? I can recreate the bug from the description but I'm not sure if it is the same approach as you. See my attempt below:

openstack port create port1 --allowed-address ip-address=10.0.0.10 --network private

# use subnet id for '10.0.0.0/26' subnet in the following command

$ openstack port create port2 --fixed-ip subnet=2e3b3133-7e67-4a3b-9b1d-6d25238788d2,ip-address=10.0.0.10 --network private

$ ip netns
qrouter-0cd4817d-d5f6-44b8-96a8-752e23c20b99
qdhcp-025b4428-9de1-4a58-9494-349dc58b7475

$ sudo ip netns exec qrouter-0cd4817d-d5f6-44b8-96a8-752e23c20b99 arp
Address HWtype HWaddress Flags Mask Iface
172.24.4.1 ether fe:61:c0:e7:f6:45 C qg-ce281ff3-54
10.0.0.10 # port 2 ether fa:16:3e:5b:ca:25 C qr-9930c08b-8e
10.0.0.9 # port 1 ether fa:16:3e:57:28:bf C qr-9930c08b-8e
10.0.0.2 ether fa:16:3e:67:74:47 C qr-9930c08b-8e

$ openstack security group rule create a1ff40db-0bee-4b2a-ad26-829dc58a28d3 --protocol tcp --dst-port 22:22 --remote-ip 0.0.0.0/0

$ openstack security group rule create a1ff40db-0bee-4b2a-ad26-829dc58a28d3 --protocol icmp --dst-port 22:22 --remote-ip 0.0.0.0/0

$ sudo ip netns exec qrouter-0cd4817d-d5f6-44b8-96a8-752e23c20b99 ssh cirros@10.0.0.9
cirros@10.0.0.9's password:

$ ping -4 -c 1 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes
64 bytes from 10.0.0.1: seq=0 ttl=64 time=0.398 ms

--- 10.0.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.398/0.398/0.398 ms
$ exit

$ sudo ip netns exec qrouter-0cd4817d-d5f6-44b8-96a8-752e23c20b99 ssh cirros@10.0.0.10
cirros@10.0.0.10's password:

$ ping -4 -c 1 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes
64 bytes from 10.0.0.1: seq=0 ttl=64 time=1.656 ms

--- 10.0.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 1.656/1.656/1.656 ms
$ exit

# I tried using the -I option for ping but was not successful.
$ ping 10.0.0.1 -I 10.0.0.10
PING 10.0.0.1 (10.0.0.1) from 10.0.0.10: 56 data bytes
ping: can't set multicast source interface

Changed in neutron:
status: New → Incomplete
Revision history for this message
zhaobo (zhaobo6) wrote :

Thanks for care about this.

Your reproduce steps is the same with I said.

Revision history for this message
Trevor McCasland (twm2016) wrote :

Did you notice how I couldn't ping from source IP 10.0.0.10 ? Can you update your bug to reflect that?
"All the Ping request packets which use 10.0.0.10 as Src ip from VM1 are accepted" - This is not true.

Revision history for this message
Trevor McCasland (twm2016) wrote :

Ok maybe it is correct. If that is not supposed to be true. I think I was just using the ping command incorrectly at the end there.

I'm just having a hard time understanding what the bug is. "but the qrouter namespace will send the Ping resp to VM2"

can you show what you mean by this?

Revision history for this message
zhaobo (zhaobo6) wrote :
Download full text (11.3 KiB)

The end cmd PING is correct. But I think you didn't set the ip address in the vm to simulate the scenario of allowed-address-pair
I will show the details about that in devstack.

1.neutron port-create private --name port1 --allowed-address-pair ip_address=10.0.0.20
+-----------------------+-------------------------------------------------------------------------------------------------------------+
| Field | Value |
+-----------------------+-------------------------------------------------------------------------------------------------------------+
| admin_state_up | True |
| allowed_address_pairs | {"ip_address": "10.0.0.20", "mac_address": "fa:16:3e:6c:b8:a9"} |
| binding:host_id | |
| binding:profile | {} |
| binding:vif_details | {} |
| binding:vif_type | unbound |
| binding:vnic_type | normal |
| created_at | 2017-06-14T06:25:24Z |
| description | |
| device_id | |
| device_owner | |
| extra_dhcp_opts | |
| fixed_ips | {"subnet_id": "5b81483d-f2cb-4ebf-b283-db6a85253808", "ip_address": "10.0.0.6"} |
| | {"subnet_id": "0908db76-619d-44dd-a7b9-b144498303c3", "ip_address": "fd67:fab0:e3b1:0:f816:3eff:fe6c:b8a9"} |
| id | f953e147-004e-4bd5-9010-2fd46adf524b |
| mac_address | fa:16:3e:6c:b8:a9 |
| name | port1 |
| network_id | 18f6a39e-60f8-4045-b152-9803b7571779 |
| port_security_enabled | True ...

description: updated
Changed in neutron:
status: Incomplete → New
zhaobo (zhaobo6)
description: updated
Revision history for this message
Kevin Benton (kevinbenton) wrote :

What is it that is broken? allowed_address_pairs is a flexible tool that allows you to duplicate addresses if that's what you want to do (you can even allow 0.0.0.0/0).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.