Chapter 10. Configure physical switches for OpenStack Networking
This chapter documents the common physical switch configuration steps required for OpenStack Networking. Vendor-specific configuration is included for the popular switch vendors, including Cisco, Extreme Networks, and Juniper.
10.1. Planning your physical network environment
The physical network adapters in your OpenStack nodes can be expected to carry different types of network traffic, such as instance traffic, storage data, or authentication requests. The type of traffic these NICs will carry affects how their ports are configured on the physical switch.
As a first step, you will need to decide which physical NICs on your Compute node will carry which types of traffic. Then, when the NIC is cabled to a physical switch port, that switch port will need to be specially configured to allow trunked or general traffic.
For example, this diagram depicts a Compute node with two NICs, eth0 and eth1. Each NIC is cabled to a Gigabit Ethernet port on a physical switch, with eth0 carrying instance traffic, and eth1 providing connectivity for OpenStack services:
This diagram does not include any additional redundant NICs required for fault tolerance.
10.2. Configure a Cisco Catalyst switch
10.2.1. Configure trunk ports
OpenStack Networking allows instances to connect to the VLANs that already exist on your physical network. The term trunk is used to describe a port that allows multiple VLANs to traverse through the same port. As a result, VLANs can span across multiple switches, including virtual switches. For example, traffic tagged as VLAN110 in the physical network can arrive at the Compute node, where the 8021q module will direct the tagged traffic to the appropriate VLAN on the vSwitch.
10.2.1.1. Configure trunk ports for a Cisco Catalyst switch
If using a Cisco Catalyst switch running Cisco IOS, you might use the following configuration syntax to allow traffic for VLANs 110 and 111 to pass through to your instances. This configuration assumes that your physical node has an ethernet cable connected to interface GigabitEthernet1/0/12 on the physical switch.
These values are examples only. Simply copying and pasting into your switch configuration without adjusting the values first will likely result in an unexpected outage to something, somewhere.
interface GigabitEthernet1/0/12 description Trunk to Compute Node spanning-tree portfast trunk switchport trunk encapsulation dot1q switchport mode trunk switchport trunk native vlan 2 switchport trunk allowed vlan 2,110,111
These settings are described below:
| Field | Description |
|---|---|
|
| This is the switch port that the node’s NIC is plugged into. This is just an example, so it is important to first verify that you are configuring the correct port here. You can use the show interface command to view a list of ports. |
|
| The description that appears when listing all interfaces using the show interface command. Should be descriptive enough to let someone understand which system is plugged into this port, and what the connection’s intended function is. |
|
| Assuming your environment uses STP, tells Port Fast that this port is used to trunk traffic. |
|
| Enables the 802.1q trunking standard (rather than ISL). This will vary depending on what your switch supports. |
|
| Configures this port as a trunk port, rather than an access port, meaning that it will allow VLAN traffic to pass through to the virtual switches. |
|
| Setting a native VLAN tells the switch where to send untagged (non-VLAN) traffic. |
|
| Defines which VLANs are allowed through the trunk. |
10.2.2. Configure access ports
Not all NICs on your Compute node will carry instance traffic, and so do not need to be configured to allow multiple VLANs to pass through. These ports require only one VLAN to be configured, and might fulfill other operational requirements, such as transporting management traffic or Block Storage data. These ports are commonly known as access ports and usually require a simpler configuration than trunk ports.
10.2.2.1. Configure access ports for a Cisco Catalyst switch
To continue the example from the diagram above, this example configures GigabitEthernet1/0/13 (on a Cisco Catalyst switch) as an access port for eth1. This configuration assumes that your physical node has an ethernet cable connected to interface GigabitEthernet1/0/12 on the physical switch.
These values are examples only. Simply copying and pasting into your switch configuration without adjusting the values first will likely result in an unexpected outage to something, somewhere.
interface GigabitEthernet1/0/13 description Access port for Compute Node switchport mode access switchport access vlan 200 spanning-tree portfast
These settings are described below:
| Field | Description |
|---|---|
|
| This is the switch port that the node’s NIC is plugged into. The interface value is just an example, so it is important to first verify that you are configuring the correct port here. You can use the show interface command to view a list of ports. |
|
| The description that appears when listing all interfaces using the show interface command. Should be descriptive enough to let someone understand which system is plugged into this port, and what the connection’s intended function is. |
|
| Configures this port as an access port, rather than a trunk port. |
|
| Configures the port to allow traffic on VLAN 200. Your Compute node should also be configured with an IP address from this VLAN. |
|
| If using STP, this tells STP not to attempt to initialize this as a trunk, allowing for quicker port handshakes during initial connections (such as server reboot). |
10.2.3. Configure LACP port aggregation
LACP allows you to bundle multiple physical NICs together to form a single logical channel. Also known as 802.3ad (or bonding mode 4 in Linux), LACP creates a dynamic bond for load-balancing and fault tolerance. LACP must be configured at both physical ends: on the physical NICs, and on the physical switch ports.
10.2.3.1. Configure LACP on the physical NIC
1. Edit the /home/stack/network-environment.yaml file:
- type: linux_bond
name: bond1
mtu: 9000
bonding_options:{get_param: BondInterfaceOvsOptions};
members:
- type: interface
name: nic3
mtu: 9000
primary: true
- type: interface
name: nic4
mtu: 9000
2. Configure the Open vSwitch bridge to use LACP:
BondInterfaceOvsOptions:
"mode=802.3ad"For information on configuring network bonds, see the Director Installation and Usage guide.
10.2.3.2. Configure LACP on a Cisco Catalyst switch
In this example, the Compute node has two NICs using VLAN 100:
1. Physically connect the Compute node’s two NICs to the switch (for example, ports 12 and 13).
2. Create the LACP port channel:
interface port-channel1 switchport access vlan 100 switchport mode access spanning-tree guard root
3. Configure switch ports 12 (Gi1/0/12) and 13 (Gi1/0/13):
sw01# config t Enter configuration commands, one per line. End with CNTL/Z. sw01(config) interface GigabitEthernet1/0/12 switchport access vlan 100 switchport mode access speed 1000 duplex full channel-group 10 mode active channel-protocol lacp interface GigabitEthernet1/0/13 switchport access vlan 100 switchport mode access speed 1000 duplex full channel-group 10 mode active channel-protocol lacp
4. Review your new port channel. The resulting output lists the new port-channel Po1, with member ports Gi1/0/12 and Gi1/0/13:
sw01# show etherchannel summary <snip> Number of channel-groups in use: 1 Number of aggregators: 1 Group Port-channel Protocol Ports ------+-------------+-----------+----------------------------------------------- 1 Po1(SD) LACP Gi1/0/12(D) Gi1/0/13(D)
Remember to apply your changes by copying the running-config to the startup-config: copy running-config startup-config.
10.2.4. Configure MTU settings
Certain types of network traffic might require that you adjust your MTU size. For example, jumbo frames (9000 bytes) might be suggested for certain NFS or iSCSI traffic.
MTU settings must be changed from end-to-end (on all hops that the traffic is expected to pass through), including any virtual switches. For information on changing the MTU in your OpenStack environment, see Chapter 11, Configure MTU Settings.
10.2.4.1. Configure MTU settings on a Cisco Catalyst switch
This example enables jumbo frames on your Cisco Catalyst 3750 switch.
1. Review the current MTU settings:
sw01# show system mtu System MTU size is 1600 bytes System Jumbo MTU size is 1600 bytes System Alternate MTU size is 1600 bytes Routing MTU size is 1600 bytes
2. MTU settings are changed switch-wide on 3750 switches, and not for individual interfaces. This command configures the switch to use jumbo frames of 9000 bytes. If your switch supports it, you might prefer to configure the MTU settings for individual interfaces.
sw01# config t Enter configuration commands, one per line. End with CNTL/Z. sw01(config)# system mtu jumbo 9000 Changes to the system jumbo MTU will not take effect until the next reload is done
Remember to save your changes by copying the running-config to the startup-config: copy running-config startup-config.
3. When possible, reload the switch to apply the change. This will result in a network outage for any devices that are dependent on the switch.
sw01# reload Proceed with reload? [confirm]
4. When the switch has completed its reload operation, confirm the new jumbo MTU size. The exact output may differ depending on your switch model, where System MTU might apply to non-Gigabit interfaces, and Jumbo MTU might describe all Gigabit interfaces.
sw01# show system mtu System MTU size is 1600 bytes System Jumbo MTU size is 9000 bytes System Alternate MTU size is 1600 bytes Routing MTU size is 1600 bytes
10.2.5. Configure LLDP discovery
The ironic-python-agent service listens for LLDP packets from connected switches. The collected information can include the switch name, port details, and available VLANs. Similar to Cisco Discovery Protocol (CDP), LLDP assists with the discovery of physical hardware during director’s introspection process.
10.2.5.1. Configure LLDP on a Cisco Catalyst switch
1. Use lldp run to enable LLDP globally on your Cisco Catalyst switch:
sw01# config t Enter configuration commands, one per line. End with CNTL/Z. sw01(config)# lldp run
2. View any neighboring LLDP-compatible devices:
sw01# show lldp neighbor
Capability codes:
(R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
(W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
Device ID Local Intf Hold-time Capability Port ID
DEP42037061562G3 Gi1/0/11 180 B,T 422037061562G3:P1
Total entries displayed: 1
Remember to save your changes by copying the running-config to the startup-config: copy running-config startup-config.
10.3. Configure a Cisco Nexus switch
10.3.1. Configure trunk ports
OpenStack Networking allows instances to connect to the VLANs that already exist on your physical network. The term trunk is used to describe a port that allows multiple VLANs to traverse through the same port. As a result, VLANs can span across multiple switches, including virtual switches. For example, traffic tagged as VLAN110 in the physical network can arrive at the Compute node, where the 8021q module will direct the tagged traffic to the appropriate VLAN on the vSwitch.
10.3.1.1. Configure trunk ports for a Cisco Nexus switch
If using a Cisco Nexus you might use the following configuration syntax to allow traffic for VLANs 110 and 111 to pass through to your instances. This configuration assumes that your physical node has an ethernet cable connected to interface Ethernet1/12 on the physical switch.
These values are examples only. Simply copying and pasting into your switch configuration without adjusting the values first will likely result in an unexpected outage to something, somewhere.
interface Ethernet1/12 description Trunk to Compute Node switchport mode trunk switchport trunk allowed vlan 2,110,111 switchport trunk native vlan 2 end
10.3.2. Configure access ports
Not all NICs on your Compute node will carry instance traffic, and so do not need to be configured to allow multiple VLANs to pass through. These ports require only one VLAN to be configured, and might fulfill other operational requirements, such as transporting management traffic or Block Storage data. These ports are commonly known as access ports and usually require a simpler configuration than trunk ports.
10.3.2.1. Configure access ports for a Cisco Nexus switch
To continue the example from the diagram above, this example configures Ethernet1/13 (on a Cisco Nexus switch) as an access port for eth1. This configuration assumes that your physical node has an ethernet cable connected to interface Ethernet1/13 on the physical switch.
These values are examples only. Simply copying and pasting into your switch configuration without adjusting the values first will likely result in an unexpected outage to something, somewhere.
interface Ethernet1/13 description Access port for Compute Node switchport mode access switchport access vlan 200
10.3.3. Configure LACP port aggregation
LACP allows you to bundle multiple physical NICs together to form a single logical channel. Also known as 802.3ad (or bonding mode 4 in Linux), LACP creates a dynamic bond for load-balancing and fault tolerance. LACP must be configured at both physical ends: on the physical NICs, and on the physical switch ports.
10.3.3.1. Configure LACP on the physical NIC
1. Edit the /home/stack/network-environment.yaml file:
- type: linux_bond
name: bond1
mtu: 9000
bonding_options:{get_param: BondInterfaceOvsOptions};
members:
- type: interface
name: nic3
mtu: 9000
primary: true
- type: interface
name: nic4
mtu: 9000
2. Configure the Open vSwitch bridge to use LACP:
BondInterfaceOvsOptions:
"mode=802.3ad"For information on configuring network bonds, see the Director Installation and Usage guide.
10.3.3.2. Configure LACP on a Cisco Nexus switch
In this example, the Compute node has two NICs using VLAN 100:
1. Physically connect the Compute node’s two NICs to the switch (for example, ports 12 and 13).
2. Confirm that LACP is enabled:
(config)# show feature | include lacp lacp 1 enabled
3. Configure ports 1/12 and 1/13 as access ports, and as members of a channel group. Depending on your deployment, you might deploy to use trunk interfaces rather than access interfaces. For example, for Cisco UCI the NICs are virtual interfaces, so you might prefer to set up all access ports. In addition, there will likely be VLAN tagging configured on the interfaces.
interface Ethernet1/13 description Access port for Compute Node switchport mode access switchport access vlan 200 channel-group 10 mode active interface Ethernet1/13 description Access port for Compute Node switchport mode access switchport access vlan 200 channel-group 10 mode active
10.3.4. Configure MTU settings
Certain types of network traffic might require that you adjust your MTU size. For example, jumbo frames (9000 bytes) might be suggested for certain NFS or iSCSI traffic.
MTU settings must be changed from end-to-end (on all hops that the traffic is expected to pass through), including any virtual switches. For information on changing the MTU in your OpenStack environment, see Chapter 11, Configure MTU Settings.
10.3.4.1. Configure MTU settings on a Cisco Nexus 7000 switch
MTU settings can be applied to a single interface on 7000-series switches. These commands configure interface 1/12 to use jumbo frames of 9000 bytes:
interface ethernet 1/12 mtu 9216 exit
10.3.5. Configure LLDP discovery
The ironic-python-agent service listens for LLDP packets from connected switches. The collected information can include the switch name, port details, and available VLANs. Similar to Cisco Discovery Protocol (CDP), LLDP assists with the discovery of physical hardware during director’s introspection process.
10.3.5.1. Configure LLDP on a Cisco Nexus 7000 switch
LLDP can be enabled for individual interfaces on Cisco Nexus 7000-series switches:
interface ethernet 1/12 lldp transmit lldp receive no lacp suspend-individual no lacp graceful-convergence interface ethernet 1/13 lldp transmit lldp receive no lacp suspend-individual no lacp graceful-convergence
Remember to save your changes by copying the running-config to the startup-config: copy running-config startup-config.
10.4. Configure a Cumulus Linux switch
10.4.1. Configure trunk ports
OpenStack Networking allows instances to connect to the VLANs that already exist on your physical network. The term trunk is used to describe a port that allows multiple VLANs to traverse through the same port. As a result, VLANs can span across multiple switches, including virtual switches. For example, traffic tagged as VLAN110 in the physical network can arrive at the Compute node, where the 8021q module will direct the tagged traffic to the appropriate VLAN on the vSwitch.
10.4.1.1. Configure trunk ports for a Cumulus Linux switch
If using a Cumulus Linux switch, you might use the following configuration syntax to allow traffic for VLANs 100 and 200 to pass through to your instances. This configuration assumes that your physical node has transceivers connected to switch ports swp1 and swp2 on the physical switch.
These values are examples only. Simply copying and pasting into your switch configuration without adjusting the values first will likely result in an unexpected outage to something, somewhere.
auto bridge iface bridge bridge-vlan-aware yes bridge-ports glob swp1-2 bridge-vids 100 200
10.4.2. Configure access ports
Not all NICs on your Compute node will carry instance traffic, and so do not need to be configured to allow multiple VLANs to pass through. These ports require only one VLAN to be configured, and might fulfill other operational requirements, such as transporting management traffic or Block Storage data. These ports are commonly known as access ports and usually require a simpler configuration than trunk ports.
10.4.2.1. Configuring access ports for a Cumulus Linux switch
To continue the example from the diagram above, this example configures swp1 (on a Cumulus Linux switch) as an access port. This configuration assumes that your physical node has an ethernet cable connected to the interface on the physical switch. Cumulus Linux switches use eth for management interfaces and swp for access/trunk ports.
These values are examples only. Simply copying and pasting into your switch configuration without adjusting the values first will likely result in an unexpected outage to something, somewhere.
auto bridge iface bridge bridge-vlan-aware yes bridge-ports glob swp1-2 bridge-vids 100 200 auto swp1 iface swp1 bridge-access 100 auto swp2 iface swp2 bridge-access 200
10.4.3. Configure LACP port aggregation
LACP allows you to bundle multiple physical NICs together to form a single logical channel. Also known as 802.3ad (or bonding mode 4 in Linux), LACP creates a dynamic bond for load-balancing and fault tolerance. LACP must be configured at both physical ends: on the physical NICs, and on the physical switch ports.
10.4.3.1. Configure LACP on the physical NIC
There is no need to configure the physical NIC in Cumulus Linux.
10.4.3.2. Configure LACP on a Cumulus Linux switch
To configure the bond, edit /etc/network/interfaces and add a stanza for bond0:
auto bond0 iface bond0 address 10.0.0.1/30 bond-slaves swp1 swp2 swp3 swp4
Remember to apply your changes by reloading the updated configuration: sudo ifreload -a
10.4.4. Configure MTU settings
Certain types of network traffic might require that you adjust your MTU size. For example, jumbo frames (9000 bytes) might be suggested for certain NFS or iSCSI traffic.
MTU settings must be changed from end-to-end (on all hops that the traffic is expected to pass through), including any virtual switches. For information on changing the MTU in your OpenStack environment, see Chapter 11, Configure MTU Settings.
10.4.4.1. Configure MTU settings on a Cumulus Linux switch
This example enables jumbo frames on your Cumulus Linux switch.
auto swp1 iface swp1 mtu 9000
Remember to apply your changes by reloading the updated configuration: sudo ifreload -a
10.4.5. Configure LLDP discovery
By default, the LLDP service, lldpd, runs as a daemon and starts when the switch boots.
To view all LLDP neighbors on all ports/interfaces:
cumulus@switch$ netshow lldp Local Port Speed Mode Remote Port Remote Host Summary ---------- --- --------- ----- ----- ----------- -------- eth0 10G Mgmt ==== swp6 mgmt-sw IP: 10.0.1.11/24 swp51 10G Interface/L3 ==== swp1 spine01 IP: 10.0.0.11/32 swp52 10G Interface/L ==== swp1 spine02 IP: 10.0.0.11/32
10.5. Configure an Extreme Networks EXOS switch
10.5.1. Configure trunk ports
OpenStack Networking allows instances to connect to the VLANs that already exist on your physical network. The term trunk is used to describe a port that allows multiple VLANs to traverse through the same port. As a result, VLANs can span across multiple switches, including virtual switches. For example, traffic tagged as VLAN110 in the physical network can arrive at the Compute node, where the 8021q module will direct the tagged traffic to the appropriate VLAN on the vSwitch.
10.5.1.1. Configure trunk ports on an Extreme Networks EXOS switch
If using an X-670 series switch, you might refer to the following example to allow traffic for VLANs 110 and 111 to pass through to your instances. This configuration assumes that your physical node has an ethernet cable connected to interface 24 on the physical switch. In this example, DATA and MNGT are the VLAN names.
These values are examples only. Simply copying and pasting into your switch configuration without adjusting the values first will likely result in an unexpected outage to something, somewhere.
#create vlan DATA tag 110 #create vlan MNGT tag 111 #configure vlan DATA add ports 24 tagged #configure vlan MNGT add ports 24 tagged
10.5.2. Configure access ports
Not all NICs on your Compute node will carry instance traffic, and so do not need to be configured to allow multiple VLANs to pass through. These ports require only one VLAN to be configured, and might fulfill other operational requirements, such as transporting management traffic or Block Storage data. These ports are commonly known as access ports and usually require a simpler configuration than trunk ports.
10.5.2.1. Configure access ports for an Extreme Networks EXOS switch
To continue the example from the diagram above, this example configures 10 (on a Extreme Networks X-670 series switch) as an access port for eth1. you might use the following configuration to allow traffic for VLANs 110 and 111 to pass through to your instances. This configuration assumes that your physical node has an ethernet cable connected to interface 10 on the physical switch.
These values are examples only. Simply copying and pasting into your switch configuration without adjusting the values first will likely result in an unexpected outage to something, somewhere.
create vlan VLANNAME tag NUMBER configure vlan Default delete ports PORTSTRING configure vlan VLANNAME add ports PORTSTRING untagged
For example:
#create vlan DATA tag 110 #configure vlan Default delete ports 10 #configure vlan DATA add ports 10 untagged
10.5.3. Configure LACP port aggregation
LACP allows you to bundle multiple physical NICs together to form a single logical channel. Also known as 802.3ad (or bonding mode 4 in Linux), LACP creates a dynamic bond for load-balancing and fault tolerance. LACP must be configured at both physical ends: on the physical NICs, and on the physical switch ports.
10.5.3.1. Configure LACP on the physical NIC
1. Edit the /home/stack/network-environment.yaml file:
- type: linux_bond
name: bond1
mtu: 9000
bonding_options:{get_param: BondInterfaceOvsOptions};
members:
- type: interface
name: nic3
mtu: 9000
primary: true
- type: interface
name: nic4
mtu: 9000
2. Configure the Open vSwitch bridge to use LACP:
BondInterfaceOvsOptions:
"mode=802.3ad"For information on configuring network bonds, see the Director Installation and Usage guide.
10.5.3.2. Configure LACP on an Extreme Networks EXOS switch
In this example, the Compute node has two NICs using VLAN 100:
enable sharing MASTERPORT grouping ALL_LAG_PORTS lacp configure vlan VLANNAME add ports PORTSTRING tagged
For example:
#enable sharing 11 grouping 11,12 lacp #configure vlan DATA add port 11 untagged
You might need to adjust the timeout period in the LACP negotiation script. For more information, see https://gtacknowledge.extremenetworks.com/articles/How_To/LACP-configured-ports-interfere-with-PXE-DHCP-on-servers
10.5.4. Configure MTU settings
Certain types of network traffic might require that you adjust your MTU size. For example, jumbo frames (9000 bytes) might be suggested for certain NFS or iSCSI traffic.
MTU settings must be changed from end-to-end (on all hops that the traffic is expected to pass through), including any virtual switches. For information on changing the MTU in your OpenStack environment, see Chapter 11, Configure MTU Settings.
10.5.4.1. Configure MTU settings on an Extreme Networks EXOS switch
The example enables jumbo frames on any Extreme Networks EXOS switch, and supports forwarding IP packets with 9000 bytes:
enable jumbo-frame ports PORTSTRING configure ip-mtu 9000 vlan VLANNAME
For example:
# enable jumbo-frame ports 11 # configure ip-mtu 9000 vlan DATA
10.5.5. Configure LLDP discovery
The ironic-python-agent service listens for LLDP packets from connected switches. The collected information can include the switch name, port details, and available VLANs. Similar to Cisco Discovery Protocol (CDP), LLDP assists with the discovery of physical hardware during director’s introspection process.
10.5.5.1. Configure LLDP settings on an Extreme Networks EXOS switch
The example allows configuring LLDP settings on any Extreme Networks EXOS switch. In this example, 11 represents the port string:
enable lldp ports 11
10.6. Configure a Juniper EX Series switch
10.6.1. Configure trunk ports
OpenStack Networking allows instances to connect to the VLANs that already exist on your physical network. The term trunk is used to describe a port that allows multiple VLANs to traverse through the same port. As a result, VLANs can span across multiple switches, including virtual switches. For example, traffic tagged as VLAN110 in the physical network can arrive at the Compute node, where the 8021q module will direct the tagged traffic to the appropriate VLAN on the vSwitch.
10.6.1.1. Configure trunk ports on the Juniper EX Series switch
If using a Juniper EX series switch running Juniper JunOS, you might use the following configuration to allow traffic for VLANs 110 and 111 to pass through to your instances. This configuration assumes that your physical node has an ethernet cable connected to interface ge-1/0/12 on the physical switch.
These values are examples only. Simply copying and pasting into your switch configuration without adjusting the values first will likely result in an unexpected outage to something, somewhere.
ge-1/0/12 {
description Trunk to Compute Node;
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members [110 111];
}
native-vlan-id 2;
}
}
}10.6.2. Configure access ports
Not all NICs on your Compute node will carry instance traffic, and so do not need to be configured to allow multiple VLANs to pass through. These ports require only one VLAN to be configured, and might fulfill other operational requirements, such as transporting management traffic or Block Storage data. These ports are commonly known as access ports and usually require a simpler configuration than trunk ports.
10.6.2.1. Configure access ports for a Juniper EX Series switch
To continue the example from the diagram above, this example configures ge-1/0/13 (on a Juniper EX series switch) as an access port for eth1. This configuration assumes that your physical node has an ethernet cable connected to interface ge-1/0/13 on the physical switch.
These values are examples only. Simply copying and pasting into your switch configuration without adjusting the values first will likely result in an unexpected outage to something, somewhere.
ge-1/0/13 {
description Access port for Compute Node
unit 0 {
family ethernet-switching {
port-mode access;
vlan {
members 200;
}
native-vlan-id 2;
}
}
}10.6.3. Configure LACP port aggregation
LACP allows you to bundle multiple physical NICs together to form a single logical channel. Also known as 802.3ad (or bonding mode 4 in Linux), LACP creates a dynamic bond for load-balancing and fault tolerance. LACP must be configured at both physical ends: on the physical NICs, and on the physical switch ports.
10.6.3.1. Configure LACP on the physical NIC
1. Edit the /home/stack/network-environment.yaml file:
- type: linux_bond
name: bond1
mtu: 9000
bonding_options:{get_param: BondInterfaceOvsOptions};
members:
- type: interface
name: nic3
mtu: 9000
primary: true
- type: interface
name: nic4
mtu: 9000
2. Configure the Open vSwitch bridge to use LACP:
BondInterfaceOvsOptions:
"mode=802.3ad"For information on configuring network bonds, see the Director Installation and Usage guide.
10.6.3.2. Configure LACP on a Juniper EX Series switch
In this example, the Compute node has two NICs using VLAN 100:
1. Physically connect the Compute node’s two NICs to the switch (for example, ports 12 and 13).
2. Create the port aggregate:
chassis {
aggregated-devices {
ethernet {
device-count 1;
}
}
}
3. Configure switch ports 12 (ge-1/0/12) and 13 (ge-1/0/13) to join the port aggregate ae1:
interfaces {
ge-1/0/12 {
gigether-options {
802.3ad ae1;
}
}
ge-1/0/13 {
gigether-options {
802.3ad ae1;
}
}
}
For Red Hat OpenStack Platform director deployments, in order to PXE boot from the bond, you need to set one of the bond members as lacp force-up. This will ensure that one bond member only comes up during introspection and first boot. The bond member set with lacp force-up should be the same bond member that has the MAC address in instackenv.json (the MAC address known to ironic must be the same MAC address configured with force-up).
4. Enable LACP on port aggregate ae1:
interfaces {
ae1 {
aggregated-ether-options {
lacp {
active;
}
}
}
}
5. Add aggregate ae1 to VLAN 100:
interfaces {
ae1 {
vlan-tagging;
native-vlan-id 2;
unit 100 {
vlan-id 100;
}
}
}
6. Review your new port channel. The resulting output lists the new port aggregate ae1 with member ports ge-1/0/12 and ge-1/0/13:
> show lacp statistics interfaces ae1 Aggregated interface: ae1 LACP Statistics: LACP Rx LACP Tx Unknown Rx Illegal Rx ge-1/0/12 0 0 0 0 ge-1/0/13 0 0 0 0
Remember to apply your changes by running the commit command.
10.6.4. Configure MTU settings
Certain types of network traffic might require that you adjust your MTU size. For example, jumbo frames (9000 bytes) might be suggested for certain NFS or iSCSI traffic.
MTU settings must be changed from end-to-end (on all hops that the traffic is expected to pass through), including any virtual switches. For information on changing the MTU in your OpenStack environment, see Chapter 11, Configure MTU Settings.
10.6.4.1. Configure MTU settings on a Juniper EX Series switch
This example enables jumbo frames on your Juniper EX4200 switch.
The MTU value is calculated differently depending on whether you are using Juniper or Cisco devices. For example, 9216 on Juniper would equal to 9202 for Cisco. The extra bytes are used for L2 headers, where Cisco adds this automatically to the MTU value specified, but the usable MTU will be 14 bytes smaller than specified when using Juniper. So in order to support an MTU of 9000 on the VLANs, the MTU of 9014 would have to be configured on Juniper.
1. For Juniper EX series switches, MTU settings are set for individual interfaces. These commands configure jumbo frames on the ge-1/0/14 and ge-1/0/15 ports:
set interfaces ge-1/0/14 mtu 9216 set interfaces ge-1/0/15 mtu 9216
Remember to save your changes by running the commit command.
2. If using a LACP aggregate, you will need to set the MTU size there, and not on the member NICs. For example, this setting configures the MTU size for the ae1 aggregate:
set interfaces ae1 mtu 9216
10.6.5. Configure LLDP discovery
The ironic-python-agent service listens for LLDP packets from connected switches. The collected information can include the switch name, port details, and available VLANs. Similar to Cisco Discovery Protocol (CDP), LLDP assists with the discovery of physical hardware during director’s introspection process.
10.6.5.1. Configure LLDP on a Juniper EX Series switch
You can enable LLDP globally for all interfaces, or just for individual ones:
1. For example, to enable LLDP globally on your Juniper EX 4200 switch:
lldp {
interface all{
enable;
}
}
}
2. Or, enable LLDP just for the single interface ge-1/0/14:
lldp {
interface ge-1/0/14{
enable;
}
}
}
Remember to apply your changes by running the commit command.
