Just some notes from a discussion on #openstack-neutron kevinbenton: There is indeed multiple physnets. But, the single node running neutron services is not connected to more than 1 physnet. The nodes in the other physnets are baremetal machines, under Openstack Ironic. hjensas: that's fine, but when the ports are created for those ironic nodes, they should get associated with subnets on different segments kevinbenton: We need the single machine only connected to one physnet to provide DHCP for Ironic nodes on multiple physnets. The datacenter have the routing infrastructure, and dhcp-relay agents on the routers/ToR switches. kevinbenton: but I cannot create multiple segments without multiple physical-networks on the neutron node. hjensas: yes you can, just specify different physnets hjensas: that doesn't mean those physnets are on the neutron node kevinbenton: ah, so I don't need a bridge_mapping with the physnet? kevinbenton: I can create --physical-network foo ... hjensas: the bridge_mapping is just to tell which physnets a given node can access hjensas: in the neutron server config for [ml2_type_flat], you may need to add physnets there if it's not set to '*' kevinbenton: yes, I see. I can create multiple segments. hjensas: now the problem you may run into is getting the port actually bound to the correct segment hjensas: IIRC ironic ports are actually just left UNBOUND, right? hjensas: or do they have a mechanism driver loaded? kevinbenton: well, the next problem is that I get 1 DHCP namespace, with dhcp opts for 1 subnet. hjensas: well how many subnets do you have on the network? kevinbenton: 3 hjensas: and creating segments eliminated the other two? (in DHCP namespace) kevinbenton: I have 1 network, 3 segments with 1 subnet in each segment. - I get 1 DHCP namespace with 1 port in segment1 - subnet0, and opts for subnet0 only. hjensas: and dhcp is enabled on other 2, right? hjensas: oh, i see the issue hjensas: it looks like we have the assumption built into dhcp scheduler that it won't be able to service remote subnets hjensas: i don't think the dhcp relay use case was considered kevinbenton: http://paste.openstack.org/show/607919/ kevinbenton: but, I do have bridge_mappings for 2 segments. So we should see two namespaces? Or atleast opts for two subnets? hjensas: we should just see opts inside the one namespace hjensas: but that's being explicitly prevented right now hjensas: because of some logic that thinks there is no point in the dhcp agent trying to serve a network it's not attached to hjensas: https://github.com/openstack/neutron/blob/master/neutron/api/rpc/handlers/dhcp_rpc.py#L152-L155 hjensas: let me think about this for a bit, we may just want to remove that logic completely to consider dhcp relay kevinbenton: I created this earlier today: https://blueprints.launchpad.net/neutron/+spec/dhcp-remote-subnets-with-relay kevinbenton: it is an idea for relay. hjensas: so that wouldn't be needed if this use case is fixed up and I remove that logic above, right? hjensas: i.e. the dhcp agent will serve requests for any subnets on the network kevinbenton: The DHCP agent will by default create a port and the namespace get an IP address on each subnet. If the subnet is not local, it wont send responses back via the gateway. kevinbenton: sorry, let me rephrase. The DHCP agent think it is local to all subnets, since it has IP in each subnet, and wont send the response back via the gateway. hjensas: oh, right, forgot about the local IP hjensas: well we can still ensure the agent doesn't request a local IP from a segment it's not attached to hjensas: just as long as it sets up the reservations hjensas: would that work? hjensas: so agent sets up all reservations for a network regardless of segment hjensas: and then only requests IPs on the segment subnets it's attached to kevinbenton: But IP only on local segments. that should work. hjensas: ok, let me think about it a bit more, but I think that should be pretty easy to do hjensas: and would reduce code for us kevinbenton: sounds good. Let me know if you need anything, help testing etc. hjensas: will do Action items: 1. haleyb updates https://review.openstack.org/#/c/438171/ to not include on-link routes if subnets on network have a segment_id 2. haleyb changes port update logic requesting additional IPs 3. kevinbenton works on pulling out the server-side filtering of networks - https://review.openstack.org/#/c/459861/