[Yahoo-eng-team] [Bug 1903342] Re: Neutron – port creation should fail when used network has no subnet associated
This is still invalid, there are good reasons to create a port without a
fixed_ip. You might want to discuss with nova whether they want to make
step 4 invalid, but step 2 is correct and should not be changed.
** Changed in: neutron
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1903342
Title:
Neutron – port creation should fail when used network has no subnet
associated
Status in neutron:
Invalid
Bug description:
### Scenario ###
1) openstack network create net_a
2) port create --network net_a port_a
### Actual Result ###
Port is successfully created:
(openstack) port show port_a -f json
{
"admin_state_up": true,
"allowed_address_pairs": [],
"binding_host_id": "",
"binding_profile": {},
"binding_vif_details": {},
"binding_vif_type": "unbound",
"binding_vnic_type": "normal",
"created_at": "2020-11-05T15:21:22Z",
"data_plane_status": null,
"description": "",
"device_id": "",
"device_owner": "",
"dns_assignment": [],
"dns_domain": null,
"dns_name": "",
"extra_dhcp_opts": [],
"fixed_ips": [],
"id": "65753162-f5ce-4b19-9b63-c1756cc31c4a",
"location": {
"cloud": "",
"region_name": "regionOne",
"zone": null,
"project": {
"id": "4bda515a91d143c5a62863cb87b6ec81",
"name": "admin",
"domain_id": null,
"domain_name": "Default"
}
},
"mac_address": "fa:16:3e:16:a0:a7",
"name": "port_a",
"network_id": "ab0c613f-fcbf-41c4-8366-a7d0d32d6583",
"port_security_enabled": true,
"project_id": "4bda515a91d143c5a62863cb87b6ec81",
"propagate_uplink_status": null,
"qos_policy_id": null,
"resource_request": null,
"revision_number": 1,
"security_group_ids": [
"f711e6d6-7998-4864-ae1b-0998c0ea068a"
],
"status": "DOWN",
"tags": [],
"trunk_details": null,
"updated_at": "2020-11-05T15:21:22Z"
}
### Expected Result ###
Port creation should fail with appropriate Error/Warning message.
The reason for that is that when such a port is used to create the VM,
created VM will be created without "ip_address" and this is a problem.
Openstack administrator should'n do that (creating port before subnet), but
they can as nothing prevents them to do so.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1903342/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1889454] Re: br-int has an unpredictable MTU
[Expired for neutron because there has been no activity for 60 days.] ** Changed in: neutron Status: Incomplete => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1889454 Title: br-int has an unpredictable MTU Status in neutron: Expired Bug description: We have an environment where users can plug their VMs both to tenant and provider networks on the hypervisor. This environment does not have jumbo frames. The MTU for VMs plugged directly into provider networks is 1500 (physical network) however it is 1450 for tneant networks (VXLAN). https://github.com/openstack/neutron/blob/2ac52607c266e593700be0784ebadc77789070ff/neutron/agent/common/ovs_lib.py#L299-L319 The code which creates the br-int bridge does not factor in an MTU, which means depending on what gets plugged in first, you could end up with 1500 MTU interfaces connected to br-int, which would give things like this in the system logs: br-int: dropped over-mtu packet: 1500 > 1458 I'm not sure what the best solution inside Neutron to do. Should we perhaps set br-int to the MTU of the largest physical network attachable on the agent? I'm happy to pick up the work. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1889454/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1903433] [NEW] The duplicate route in l3 router namespace results in North-South traffic breaking
Public bug reported: Reproduction steps： 1. Create an external network and create two subnet base on the network, this subnet cidrs as below: ext-subnet01: 172.24.4.0/24 ext-subnet02: 10.20.30.0/24 2. Create a router and set external gateway on the external network for the router. Now, in the router's namespace the routes as below: # ip netns exec qrouter-d91e7918-b511-4dd8-9f8f-4db0dacbfb4d ip r default via 172.24.4.1 dev qg-38d2f0b6-96 proto static 10.20.30.0/24 dev qg-38d2f0b6-96 proto static scope link 172.24.4.0/24 dev qg-38d2f0b6-96 proto kernel scope link src 172.24.4.32 3. Create a tenant network, and create a subnet base on the tenant network, the ssubnet cidr as below: tenant-subnet: 10.20.30.0/24 (It's same with the ext-subnet02's cidr) 4. Add the tenant-subnet to the router which created at step 2. Then, in the router's namespace the routes as below: # ip netns exec qrouter-d91e7918-b511-4dd8-9f8f-4db0dacbfb4d ip r default via 172.24.4.1 dev qg-38d2f0b6-96 proto static 10.20.30.0/24 dev qg-38d2f0b6-96 proto static scope link 10.20.30.0/24 dev qr-7b3f8319-45 proto kernel scope link src 10.20.30.1 172.24.4.0/24 dev qg-38d2f0b6-96 proto kernel scope link src 172.24.4.32 The duplicate routes (10.20.30.0/24) will disturb the North-South packets' forward, result the traffic breaking. ** 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/1903433 Title: The duplicate route in l3 router namespace results in North-South traffic breaking Status in neutron: New Bug description: Reproduction steps： 1. Create an external network and create two subnet base on the network, this subnet cidrs as below: ext-subnet01: 172.24.4.0/24 ext-subnet02: 10.20.30.0/24 2. Create a router and set external gateway on the external network for the router. Now, in the router's namespace the routes as below: # ip netns exec qrouter-d91e7918-b511-4dd8-9f8f-4db0dacbfb4d ip r default via 172.24.4.1 dev qg-38d2f0b6-96 proto static 10.20.30.0/24 dev qg-38d2f0b6-96 proto static scope link 172.24.4.0/24 dev qg-38d2f0b6-96 proto kernel scope link src 172.24.4.32 3. Create a tenant network, and create a subnet base on the tenant network, the ssubnet cidr as below: tenant-subnet: 10.20.30.0/24 (It's same with the ext-subnet02's cidr) 4. Add the tenant-subnet to the router which created at step 2. Then, in the router's namespace the routes as below: # ip netns exec qrouter-d91e7918-b511-4dd8-9f8f-4db0dacbfb4d ip r default via 172.24.4.1 dev qg-38d2f0b6-96 proto static 10.20.30.0/24 dev qg-38d2f0b6-96 proto static scope link 10.20.30.0/24 dev qr-7b3f8319-45 proto kernel scope link src 10.20.30.1 172.24.4.0/24 dev qg-38d2f0b6-96 proto kernel scope link src 172.24.4.32 The duplicate routes (10.20.30.0/24) will disturb the North-South packets' forward, result the traffic breaking. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1903433/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
