VLANs on SR Linux and Arista/Cisco#
In the recent VLANs on SR Linux blog post we dived deep into the world of VLANs on SR Linux where we saw that VLAN handling in SR Linux is not quite like what we used to see on Cisco/Arista systems.
As a sequel to the original post we decided to mix SR Linux with another popular Network OS - Arista EOS. By mixing different vendor implementations we wanted to provide clear guidance on how to interop between distinct VLAN implementations and help new SR Linux to map existing VLAN concepts to the SR Linux model.
Main differences#
Before we start, you can review the core concepts of SR Linux VLAN handling:
Core concepts
VLAN handling on SR Linux is nothing like Cisco and is based on the following core concepts:
- VLAN IDs (aka dot1q tags) are locally significant within the scope of a subinterface.
- VLAN IDs are configured on a subinterface level and define the action to be taken on the incoming/outgoing traffic -
pop/pushandaccept/drop. - The actual switching is powered by the network instances of type
mac-vrfand one SR Linux instance can have multiple network instances of this type.
For visuals, here is a diagram that shows how VLANs are configured on SR Linux:
And you can also check the following table that summarizes the SR Linux operation for the different configuration modes:
| Operation mode | Config | Actions |
|---|---|---|
| VLAN tagging disabled |
| no push/pop actions applied to the frames (tagged or untagged) |
| Single-tagged VLAN |
| pop push |
| Single-tagged VLAN |
| no push/pop actions applied to the frames (tagged or untagged) |
| Single-tagged VLAN range |
| no push/pop actions applied to the frames within low-high vlan range On ingress, drop frames outside the low-high vlan range On egress, no push/pop actions to frames outside the low-high vlan range |
| Untagged VLAN |
| no push/pop actions applied to the untagged frames On ingress, drop frames with VLAN tag being present On egress, no push/pop actions applied to the frames with VLAN tag being present |
Probably the most notable difference between SR Linux and IOS-like systems is that there is no notion of a mac-vrf (a.k.a broadcast domain) instance in Cisco/Arista implementations and VLANs are defined globally for a whole system.
In SR Linux MAC addresses belong to the layer 2 bridge domains called mac-vrfs, they are like virtual switching instances. For a frame to be classified to a certain mac-vrf a user of SR Linux configures VLAN tagging on a subinterface and associates it with the mac-vrf network instance.
This flexible classification and mapping technique makes it possible to have mac-vrfs network instances that connects network segments with different VLAN tags. For example, a host that sends frames tagged with VLAN 10 can communicate with another host that sends frames tagged with VLAN 11 if they have been classified to the same mac-vrf instance.
In Arista/Cisco VLANs are a global property of the switch. When MAC addresses are learned, they are registered in the mac-table together with the information of the vlan and port of the incoming frames. Layer 2 communication is only possible withing the same VLAN bridge domain.
The following diagram shows this major difference between SR Linux and EOS/IOS:
Interfaces and VLAN encapsulation#
Let's do a quick review of how Arista handles VLAN encapsulation. Before that, you may want to revisit how SR Linux does it to get the basic concepts refreshed.
If you have played with Cisco/Arista devices, you may be tempted to say: "switchport access" works on untagged links and "switchport trunk" on tagged ones, but the reality is a bit more complicated.
When ports are configured in "bridging" operation (switchport), they can be configured in two modes 1:
switchport mode access: untagged frames are accepted. MACs are registered in the mac-table with the vlan referenced in theswitchport access vlan <vlan-id>config of the port. Tagged frames are also accepted, but only if they use the<vlan-id>configured.switchport mode trunk: both tagged and untagged frames are accepted. Untagged frames are learned under the vlan referenced in theswitchport trunk native vlan <vlan-id>config of the port. Tagged frames are learned with the corresponding vlan tag of the frame. The allowed range of vlans is configured with the commandswitchport trunk allowed vlan <vlan-id>-<vlan-id>
Lab#
Nothing beats some practical exercises, so have built a lab to support this blog post: srl-labs/srlinux-eos-vlan-handling-lab. It's quite similar to the lab we built in the previous post, but in this case we are mixing SR Linux and EOS devices:
For this lab to work you need to have the cEOS image available; check containerlab docs on how to get it.
The two clients are connected to the ethernet-1/1 and Ethernet1 interface of the respective SR Linux and Arista switches and have five interfaces configured on them:
| Interface | VLAN ID | IP address | MAC address |
|---|---|---|---|
eth1 | - | 10.1.0.${ID}/30 | aa:c1:ab:00:00:0${ID} |
eth1.1 | 1 | 10.1.1.${ID}/30 | aa:c1:ab:00:01:0${ID} |
eth1.10 | 10 | 10.1.10.${ID}/30 | aa:c1:ab:00:10:0${ID} |
eth1.11 | 11 | 10.1.11.${ID}/30 | aa:c1:ab:00:11:0${ID} |
eth1.12.13 | 12.132 | 10.1.12.${ID}/30 | aa:c1:ab:00:12:0${ID} |
where ${ID} is the client ID (1 or 2).
Deploy the lab:
Containerlab will clone the repository in your current working directory and deploy the lab topology. All is ready for us to get started with our practical exercises.
To automate the configuration of the different scenarios we leverage gnmic.
packet captures
As we go through the lab scenarios, we will be running ping tests between the clients and see how different VLAN configurations affect the traffic. But if you want to see the actual frames, you can run packet captures on any interface of the client or SR Linux nodes, see the Packet Captures video where Roman explains how to do it. Or this one that shows how to use Edgeshark, if you like having a Web UI for the packet capturing activities.
Scenario 1: Disabled VLAN tagging#
In this scenario SR Linux are configured with the vlan-tagging false option. With this option, all incoming frames are forwarded without any modifications.
SR Linux Configuration
# no vlan tagging configured
/ interface ethernet-1/1 {
admin-state enable
subinterface 0 {
type bridged
admin-state enable
}
}
/ interface ethernet-1/10 {
admin-state enable
subinterface 0 {
type bridged
admin-state enable
}
}
# bridge domain is like a L2 switch instance
/ network-instance bridge-1 {
type mac-vrf
admin-state enable
interface ethernet-1/1.0 {
}
interface ethernet-1/10.0 {
}
}
There is no straightforward configuration in EOS/IOS that would make transparent forwarding of tagged and untagged frames. If we want to get as close as possible to the operation in SR Linux, we will have to configure the port in Arista EOS as trunks and allow all the VLAN IDs. In EOS, by default, ports are configured in access mode and associated with the VLAN 1:
EOS Configuration
To apply this configuration we run these two commands:
Let's see how this configuration affects the traffic between the clients by running our pinger script:
❯ ./ping-from-cli1.sh all
+ Ping to 10.1.0.2 (no tag) was successful.
- Ping to 10.1.1.2 (single tag VID: 1) failed.
+ Ping to 10.1.10.2 (single tag VID: 10) was successful.
+ Ping to 10.1.11.2 (single tag VID: 11) was successful.
+ Ping to 10.1.12.2 (double tag outer VID: 12, inner VID: 13) was successful.
Ping in VLAN 1 fails. Why?
Remember the native VLAN? By default, in EOS, ports send native VLAN traffic with untagged frames. The default native VLAN is ID 1.
As we are sending traffic with this tag ID, EOS will remove VLAN ID 1 tag when traffic enters through port Eth1.
SR Linux forwards the traffic transparently and deliver the ethernet frames to the client2. If you capture the traffic at client2, you will see that, although ARP traffic is received untagged, the Linux host is replying with eth1.1 MAC address via eth1 interface. This may seem odd, but it's a standard Linux kernel behavior. You can modify this setting with arp_announce and arp_ignore kernel parameters.
Once ARP reply is received at client1, the Linux kernel will ignore the frame because we performed the ARP request using eth1.1 interface but received the answer via eth1.
This is the visual representation of what's happening:
If we want the traffic in VLAN 1 to work, we can configure switchport trunk native vlan tag on EOS interfaces; with this configuration in effect, EOS sends native VLAN traffic as tagged frames. The side effect of this configuration is that the untagged traffic will be discarded entirely.
You can test this alternate configuration with the following command:
Scenario 2: Single-tagged VLAN#
In this scenario we are only allowing clients to send tagged traffic with VLAN tag 10.
In SR Linux we configure the interface with VLAN tagging enabled and create subinterfaces for each specific dot1q tag. The SR Linux node will drop frames with dot1q tags that were not specifically configured on its subinterfaces. SR Linux performs Pop and Push operations on the frames ingressing and egressing from the mac-vrf.
This is the configuration on SR Linux:
SR Linux Configuration
# vlan tagging enabled
interface ethernet-1/1 {
admin-state enable
vlan-tagging true
subinterface 10 {
type bridged
admin-state enable
vlan {
encap {
single-tagged {
vlan-id 10
}
}
}
}
}
interface ethernet-1/10 {
admin-state enable
vlan-tagging true
subinterface 10 {
type bridged
admin-state enable
vlan {
encap {
single-tagged {
vlan-id 10
}
}
}
}
}
network-instance bridge-1 {
type mac-vrf
admin-state enable
interface ethernet-1/1.10 {
}
interface ethernet-1/10.10 {
}
}
And this is the required config for EOS:
EOS Configuration
To apply this configuration we run these two commands:
Let's run the pinger to see how this affects our setup:
❯ ./ping-from-cli1.sh all
- Ping to 10.1.0.2 (no tag) failed.
- Ping to 10.1.1.2 (single tag VID: 1) failed.
+ Ping to 10.1.10.2 (single tag VID: 10) was successful.
- Ping to 10.1.11.2 (single tag VID: 11) failed.
- Ping to 10.1.12.2 (double tag outer VID: 12, inner VID: 13) failed.
As per the single-tagged VLAN section of the original blog post:
- Untagged frames are dropped, since they don't have a VLAN tag present.
- Single tagged frames with
VLAN 1tag are dropped, since they don't match the configuredVLAN 10. - Tagged frames with
VLAN 10tag are accepted; on SR Linux side VLAN tag is popped on ingress and pushed on egress. - Single tagged frames with
VLAN 11tag are dropped, since they don't match the configuredVLAN 10. - Double tagged frames with outer
VLAN 12tag are dropped, since the outer tag doesn't match the configuredVLAN 10.
This is the visual representation of the packet flow for this scenario:
Scenario 3: Single-tagged-range VLAN#
Whenever we want the subinterfaces to accept frames with a range of VLAN IDs, we can configure the single-tagged-range encapsulation type in SR Linux.
This mode doesn't pop any VLAN tags on ingress, nor it adds them on ingress. Subinterface will just filter the frames that have VLAN ID within the configured range and pass them through without any modifications.
In Arista, this scenario is similar to the previous one, the only difference is that we will increase the range of allowed vlans.
This is the configuration for SR Linux:
SR Linux Configuration
# vlan tagging enabled
interface ethernet-1/1 {
admin-state enable
vlan-tagging true
subinterface 10 {
type bridged
admin-state enable
vlan {
encap {
single-tagged-range {
low-vlan-id 10 {
high-vlan-id 15
}
}
}
}
}
}
interface ethernet-1/10 {
admin-state enable
vlan-tagging true
subinterface 0 {
type bridged
admin-state enable
vlan {
encap {
single-tagged {
vlan-id any #(1)!
}
}
}
}
}
network-instance bridge-1 {
type mac-vrf
admin-state enable
interface ethernet-1/1.10 {
}
interface ethernet-1/10.0 {
}
}
- For a change, we configure
ethernet-1/10.0subinterface with thevlan-id anyencapsulation. This encapsulation will ensure that we have the same vlan transparency as with thevlan-tagging falseoption, but it allows us to configure VLANs on the other subinterfaces under theethernet-1/10interface.
And this is the configuration in EOS:
EOS Configuration
To apply this configuration we run these two commands:
And let's run the pinger:
❯ ./ping-from-cli1.sh all
- Ping to 10.1.0.2 (no tag) failed.
- Ping to 10.1.1.2 (single tag VID: 1) failed.
+ Ping to 10.1.10.2 (single tag VID: 10) was successful.
+ Ping to 10.1.11.2 (single tag VID: 11) was successful.
+ Ping to 10.1.12.2 (double tag outer VID: 12, inner VID: 13) was successful.
As per our single-tagged-range VLAN section of the original blog post:
- Untagged frames are dropped, since they don't have a VLAN tag present.
- Single tagged frames with
VLAN 1are dropped, since they don't match the configuredVLAN 10. - Single tagged frames with
VLAN 10are accepted. At the SRL switch, frames are forwarded transparently. - Single tagged frames with
VLAN 11are accepted. At the SRL switch, frames are forwarded transparently. - Double tagged frames with outer
VLAN 12are accepted. At the SRL switch, frames are forwarded transparently.
This is the visual representation of what's happening:
Scenario 4: Untagged VLAN#
In Arista, ports that only accept untagged frames are configured in access mode. We could also use the configuration of the first scenario to allow untagged traffic, but we would also allow the tagged one.
As we have seen, in EOS/IOS systems, every MAC address needs to be associated with a VLAN. Even if we configure the port to accept untagged frames, we still need to define the VLAN that will be associated. We do it with the switchport access vlan <vlan-id>.
In SR Linux we will use the untagged vlan encapsulation type.
This scenario has different possible outcomes depending on how we configure the port between the EOS and the SR Linux switch and the VLAN we select:
| EOS | EOS | Actions |
|---|---|---|
|
|
| Frames are untagged |
|
(the native vlan) |
| Frames are untagged because we use the native VLAN |
|
(the native vlan) |
| EOS pushes VLAN |
|
|
| EOS pushes VLAN |
As you can see, the usage of the native VLAN introduces many variations. For our ping tests we will stick to the last configuration, where EOS tags VLAN 10 between both switches.
This is the configuration for SR Linux:
SR Linux Configuration
# vlan tagging enabled
interface ethernet-1/1 {
admin-state enable
vlan-tagging true
subinterface 10 {
type bridged
admin-state enable
vlan {
encap {
untagged {
}
}
}
}
}
interface ethernet-1/10 {
admin-state enable
vlan-tagging true
subinterface 10 {
type bridged
admin-state enable
vlan {
encap {
single-tagged {
vlan-id 10
}
}
}
}
}
network-instance bridge-1 {
type mac-vrf
admin-state enable
interface ethernet-1/1.10 {
}
interface ethernet-1/10.10 {
}
}
And this is the configuration in EOS:
EOS Configuration
vlan 10
!
interface Ethernet1 #(1)!
switchport access vlan 10
switchport mode access
!
interface Ethernet10
switchport mode trunk
switchport trunk allowed vlan 10
!
- You can apply the default configuration for a port by applying
default interface Eth1
To apply this configuration we run these two commands:
Let's run the pinger and see the results:
❯ ./ping-from-cli1.sh all
+ Ping to 10.1.0.2 (no tag) was successful.
- Ping to 10.1.1.2 (single tag VID: 1) failed.
- Ping to 10.1.10.2 (single tag VID: 10) failed.
- Ping to 10.1.11.2 (single tag VID: 11) failed.
- Ping to 10.1.12.2 (double tag outer VID: 12, inner VID: 13) failed.
And the visual representation of what's happening:
You can see that EOS device still forwards VLAN 10 traffic. This is because access port accepts untagged and tagged traffic of the VLAN ID configured.
Summary#
We have seen how a simple concept as a VLAN can keep us busy for quite a long time. The flexibility of SR Linux VLAN handling provides many options to handle all the different scenarios.
If we had to summarize the key concepts about working with VLAN on SR Linux and IOS-like platforms, here are a few takeaways:
- Always consider that in EOS the
nativeVLAN can be tagged or untagged depending on the switchport configuration. - In SR Linux, ports do push/pop VLAN tags only when VLAN tagging is enabled and configured with specific single-tagged VLAN IDs. This option is great if you want fine-grained control per VLAN/subinterface.
- In SR Linux, With
vlan-tagging false,single-tagged vlan-id anyorsingle-tagged-rangeframe's tags won't be modified in any way. With this option it's very easy to transport atrunkof vlans from one port to another. Quite handy for thoseswitchport trunk allowed vlan 1-4000configurations.
Hopefully, this blog post has given you an in-depth view on the vlan switching operation for both SR Linux and EOS. The Lab is at your disposal to try more scenarios and see how the different configurations affect the traffic.