I had no concept how convoluted VLANs might get till I attempted to implement them in netsim-tools. We’re not completed but – we now have entry VLANs, VLAN trunks (together with native VLAN help), and VLAN (SVI) interfaces, however we’re nonetheless lacking routed VLAN subinterfaces – however we now have sufficient performance to point out you just a few VLAN examples.
We’ll begin with the only choice: a single VLAN stretched throughout two bridges switches with two Linux hosts related to it. netsim-tools can configure VLANs on Arista EOS, Cisco IOSv, VyOS, Dell OS10, and Nokia SR Linux. We’ll use the quickest (deployment-wise) choice: Arista EOS on containerlab.
We’ll use teams within the lab topology file to outline our units. Members of the hosts group can be Linux containers, members of the switches group can be Arista EOS containers utilizing vlan configuration module:
Defining nodes and teams
supplier: clab
nodes: [ h1, h2, s1, s2 ]
teams:
hosts:
members: [ h1, h2 ]
gadget: linux
switches:
members: [ s1, s2 ]
module: [ vlan ]
gadget: eos
Subsequent step: defining VLANs. All we now have to do is to outline the VLAN identify. 802.1q tag and VXLAN VNI are assigned robotically.
Defining purple VLAN
vlans:
purple:
Lastly, we now have to specify the hyperlinks in our lab. We’ll set the entry VLAN identify with vlan.entry
attribute. On the switch-to-host hyperlinks, we now have to specify the entry VLAN on the change interface. On the inter-switch hyperlink we are able to set vlan.entry
as a hyperlink attribute – will probably be propagated to all switches related to the hyperlink.
Hyperlinks in our lab topology
hyperlinks:
- h1:
s1:
vlan.entry: purple
- s1:
s2:
vlan.entry: purple
- s2:
vlan.entry: purple
h2:
VLAN configuration on s1 and s2 is carried out robotically as a part of the netlab up course of. Right here’s the VLAN-related configuration from s1:
VLAN purple configuration on s1 working Arista cEOS
vlan 1000
identify purple
!
interface Ethernet1
mac-address 52:dc:ca:fe:03:01
switchport entry vlan 1000
!
interface Ethernet2
mac-address 52:dc:ca:fe:03:02
switchport entry vlan 1000
!
interface Vlan1000
description VLAN purple (1000) -> [h1,s2,h2]
ip handle 172.16.0.3/24
Right here’s the corresponding configuration on Cisco IOSv:
VLAN purple configuration on Cisco IOSv
bridge irb
!
interface GigabitEthernet0/1
bridge-group 1
!
interface GigabitEthernet0/2
bridge-group 1
!
interface BVI1
description VLAN purple (1000) -> [h1,s2,h2]
ip handle 172.16.0.3 255.255.255.0
!
bridge 1 protocol ieee
bridge 1 route ip
VLAN IP Addressing
A VLAN section outlined in netsim-tools is a single subnet; the IPv4 and IPv6 prefixes are allotted from the lan
handle pool. All bodily hyperlinks and VLAN interfaces belonging to the identical entry VLAN use the identical IP subnet. The IPv4 addresses in our lab are thus arrange as follows:
Node | IP handle in purple VLAN |
---|---|
h1 | 172.16.0.1 |
h2 | 172.16.0.2 |
s1 | 172.16.0.3 |
s2 | 172.16.0.4 |
The Linux hosts (OK, containers) can ping the IPv4 addresses assigned to the change VLAN interfaces, however not the loopback IP addresses of each switches – the Linux hosts have a default route pointing to one of many switches, and there’s no routing configured between the switches:
Pinging from Linux container
$ netlab join h1
Connecting to container clab-vlan-access-stretch-h1, beginning bash
h1:/# ping -c 5 -q h2
PING h2 (172.16.0.2): 56 information bytes
--- h2 ping statistics ---
5 packets transmitted, 5 packets obtained, 0% packet loss
round-trip min/avg/max = 3.261/3.475/3.598 ms
h1:/# ping -c 5 -q s1
PING s1 (10.0.0.3): 56 information bytes
--- s1 ping statistics ---
5 packets transmitted, 5 packets obtained, 0% packet loss
round-trip min/avg/max = 1.616/1.734/1.823 ms
h1:/# ping -c 5 -q s2
PING s2 (10.0.0.4): 56 information bytes
--- s2 ping statistics ---
5 packets transmitted, 0 packets obtained, 100% packet loss
h1:/# ping -c 5 -q 172.16.0.4
PING 172.16.0.4 (172.16.0.4): 56 information bytes
--- 172.16.0.4 ping statistics ---
5 packets transmitted, 5 packets obtained, 0% packet loss
round-trip min/avg/max = 3.040/3.232/3.363 ms
Subsequent time, we’ll repair IP routing and add OSPF routing course of to the switches. You would additionally do it by yourself: