Layer 2
This information describes configuring Layer 2 using Linux commands and includes VLAN bridging, spanning-tree provisioning (STP), link layer discovery protocol (LLDP), and MAC address forwarding database (FDB). You can also write applications that access the CPS API to configure Layer 2.
You can configure Layer 2 MAC addresses and VLAN learning and forwarding properties in support of Layer 2 bridging. The device learns unicast MAC addresses to avoid flooding the packets to all the ports in a bridge domain.
If the bridge receives a control protocol data unit (PDU) which does not have a corresponding protocol configured, the control PDU is considered as an unknown multicast data packet, and the packets are flooded across all ports that are part of the same bridge domain. If the bridge has the protocol corresponding to the PDU configured, the control PDU is considered as a control packet and is processed by the routing engine.
OPX supports Layer 2 VLAN bridging by modeling each VLAN as a separate Linux bridge instance. Each physical or LAG port that is a VLAN member is modeled by adding its corresponding Linux interface to the bridge instance. See VLAN application examples for more information.
Creating a VLAN using the Linux bridge command is a two-step process — create the bridge instance, and then add a tagged member to the new bridge instance. The OPX software determines the VLAN ID associated with each bridge instance using the VLAN ID of the first tagged member port assigned to the bridge instance.
The VLAN is created only after you add the first tagged member to a new bridge instance; otherwise the Linux kernel will not generate NETLINK messages to create/update the bridge on the NPU. To create a VLAN consisting of only untagged members, use the
opx-config-vlantool to configure the bridge on the NPU via the CPS API.
1. Create a bridge instance for the VLAN — br100 is the name of the bridge instance used to model a VLAN. The software does not derive the VLAN ID from the name.
$ brctl addbr br100
2. Add a tagged port to the VLAN — ensure that the Linux interface mapped to the port being added to the VLAN does not have an IP address.
$ ifconfig e101-001-0
e101-001-0 Link encap:Ethernet HWaddr 90:b1:1c:f4:9d:3c
inet addr:1.1.1.1 Bcast:1.1.1.255 Mask:255.255.255.0
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:2221 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 B) TX bytes:523446 (511.1 KiB)
If the interface already has an IP address, remove the IP address before continuing.
$ ip addr flush dev e101-001-0
3. Create a tagged virtual link — a Linux interface can only belong to a single bridge instance. To add the same interface to multiple VLAN domains, create a separate Linux virtual link for each VLAN in which the port is a member. Create a virtual tagged link for the e101-001-0 Linux interface in VLAN 100 — the .100 suffix in the Linux interface name indicates that the interface is VLAN tagged.
$ ip link add link e101-001-0 name e101-001-0.100 type vlan id 100
4. Add the tagged virtual link to the VLAN — add the newly created virtual link to the Linux bridge instance. The software creates the VLAN and adds the physical port mapped to the e101-001-0 Linux interface as a tagged member of the VLAN.
$ brctl addif br100 e101-001-0.100**
5. Verify the VLAN configuration.
$ brctl show
bridge name bridge id STP enabled interfaces
br100 8000.90b11cf49d3c no e101-001-0.100
1. Add a Linux interface directly to a Linux bridge as an untagged member without creating a separate VLAN-specific virtual link. The interface does not have the .100 suffix, which means the interface is an untagged VLAN member.
$ brctl addif br100 e101-002-0
2. Verify the VLAN configuration — a physical port can be an untagged member of only a single VLAN, and you can add a physical port as a tagged member of multiple VLANs.
$ brctl show
bridge name bridge id STP enabled interfaces
br100 8000.90b11cf49d3c no e101-001-0.100
1. To add the same port to a second VLAN, create another VLAN tagged virtual link on the e101-001-0 interface and add the new virtual link to the Linux bridge instance.
$ brctl addbr br200**
$ ip link add link e101-001-0 name e101-001-0.200 type vlan id 200**
$ brctl addif br200 e101-001-0.200**
All interfaces in a bridge instance must be either untagged or have the same tagged VLAN ID. You cannot configure e101-001-0.100 and e101-002-0.200 in the same Linux bridge instance.
2. Verify the VLAN configuration.
$ brctl show
bridge name bridge id STP enabled interfaces
br100 8000.90b11cf49d3c no e101-001-0.100
e101-002-0
br200 8000.90b11cf49d3c no e101-001-0.200
Add a Linux bond interface to a VLAN domain — bond1 is a Linux interface that maps to a LAG port in the NPU. Add the LAG port to the VLAN associated with the bridge instance in the NPU.
$ ip link add link bond1 name bond1.200 type vlan id 200
$ brctl addif br200 bond1.200
$ brctl delif br200 e101-001-0.100
$ brctl delbr br200
OPX supports the Linux link layer discovery protocol (LLDP) daemon on Linux interfaces. The example shows sample output from the Linux LLDP daemon:
$ lldpcli show neighbors
-------------------------------------------------------------------------------
LLDP neighbors:
-------------------------------------------------------------------------------
Interface: e101-003-0, via: LLDP, RID: 3, Time: 0 day, 01:17:18
Chassis:
ChassisID: mac 90:b1:1c:f4:9d:3b
SysName: OS10
Capability: Repeater, on
Capability: Bridge, on
Capability: Router, on
Port:
PortID: ifalias ethernet1/1/3
-------------------------------------------------------------------------------
OPX supports spanning-tree provisioning using the CPS API:
- Create a new spanning-tree group
- Add VLANs to a spanning-tree group
- Remove VLANs from a spanning-tree group
- Change the STP state of ports mapped to a spanning-tree group
- Delete a spanning-tree group
You can run spanning-tree protocols (STPs) including rapid spanning-tree protocol (RSTP), per-VLAN spanning-tree (PVST), and multiple spanning-tree (MST).
STP is not supported on a bridge which has multiple member interfaces with different VLAN IDs.
See the dell-base-stp.yang model for the supported STP parameters. See CPS application templates for information about how to configure the system using YANG models and the CPS API.
Linux STP does not support spanning-tree groups. You can enable spanning-tree independently in each bridge instance using Linux. The software treats STP enabled in a bridge instance as a separate spanning-tree group for each VLAN. If a Linux bridge contains only untagged ports, the software does not support STP on the bridge.
Create a VLAN in the Linux bridge, enable STP on the bridge, then view the configuration.
$ brctl stp br100 on
$ brctl show br100
bridge name bridge id STP enabled interfaces
br100 8000.90b11cf4a918 yes e101-001-0.100
$ brctl showstp br100
br100
bridge id 8000.90b11cf4a918
designated root 8000.90b11cf4a918
root port 0 path cost 0
max age 20.00 bridge max age 20.00
hello time 2.00 bridge hello time 2.00
forward delay 15.00 bridge forward delay 15.00
ageing time 300.00
hello timer 0.00 tcn timer 0.00
topology change timer 0.00 gc timer 0.00
flags
e101-001-0.100 (1)
port id 8001 state disabled
designated root 8000.90b11cf4a918 path cost 100
designated bridge 8000.90b11cf4a918 message age timer 0.00
designated port 8001 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
$ brctl stp br100 off
$ brctl show br100
bridge name bridge id STP enabled interfaces
br100 8000.90b11cf4a918 no e101-001-0.100
When you enable STP in a Linux bridge which has tagged VLAN interfaces, the system creates a new spanning-tree group and associates the VLAN ID of the bridge with the newly created spanning-tree group. When you delete a bridge from the Linux kernel, the corresponding spanning-tree group is deleted.
OPX does not support RSTP, MSTP, and RPVST in a Linux bridge due to a Linux kernel limitation. STP is not supported on a bridge which has multiple member interfaces with different VLAN IDs.
The OPX software provides a CPS API/data model for configuring and managing the MAC forwarding database using the CPS API. See CPS application templates for an example of how to access and configure the MAC address forwarding database.
The OPX software implementation does not support Linux commands to configure the MAC address FDB.