Access Switch Port Discovery for Bare Metal
In case of multi-tenancy, tenant network isolation relies on traffic mapping to/from tenant VLAN(s) in the virtual or physical switch where the instance is connected to. For bare metal instances, VLAN mapping can be enforced by TOR/EOR switches. Traffic mapping configuration in the switch ports requires mapping between the physical NIC(s) of nodes and the TOR switch ports where they are connected to (cabling), i.e. Neutron ports need to be bound to the respective TOR ports.
This blueprint proposes a method to support access switch port discovery for bare metal nodes. To secure authenticity, access switch port discovery is executed by Ironic agent running on the bare metal node while the node is in maintenance mode. The Ironic discovery agent image is extended with a simple LLDPv2 library (agent) for transmitting and receiving LLDPv2 messages. During discovery period, the LLDPv2 agent is activated, and incoming LLDPv2 messages from the adjacent switch are captured. Connectivity-
The port entity on Ironic API is extended with a new switch_port element, that follows LLDPv2 "System Name", "Chassis ID" and "Port ID" TLV conventions. For instance, it uses the
following JSON representation:
"ports": [
{
"switch_port" : {
"port_id" : "33"
}
}
]
The connectivity information is exposed on the Ironic API, and can provide an input for switch port mapping configuration in the Neutron plugin, and can also be used for connectivity verification and troubleshooting purposes.
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- Gergely Matefi
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
- Jim Rollenhagen
Related branches
Related bugs
Sprints
Whiteboard
This functionality connects fairly well with a Neutron blueprint we have proposed for managing VLAN memberships on physical switches, and I wonder if there is common ground:
https:/
As I see, there could be several different ways to configure network isolation. While this BP covers only a component in the game, my interest is in a highly integrated solution with other Openstack projects. Just in short:
1) Having a Neutron API for requesting Neutron ports binding directly to TOR/EOR ports rather than to vSwitch ports. This could be needed both for SR-IOV and bare metal NICs. Usage of the new binding:vnic_type attribute seems to be an attractive option.
2) Having a method across Ironic, Nova and Neutron to signal a unique identifier of the selected NIC to Neutron.
3) Neutron ML2 plugins to support TOR port mapping for directly attached NICs. I.e. if port create is received with binding:vnic_type = VNIC_DIRECT, then plugin to perform <nic_identifier> to <TOR id, switch port id> look-up (rather than the usual <host_id> lookup).
4) Having an automated and secure method to build <nic_identifier> -> <TOR id, port id> mapping database
This BP is aiming to support point 4) by listening for LLDP on switch ports while a trusted Ironic agent is running.
How does it sound to you?
-- Gergely, 2014-04-28
ironic-discoverd project essentially does LLDP discovery IIRC (though not with upstream ramdisk).
-- dtantsur, 2015-05-20
Hi Gergely, this functionality should be part of ironic-inspector. Please re-propose this blueprint there. I'm marking this as obsolete here. https:/
// jroll, 2015-10-15
