W3·A4 — Split the network

Time: 30 min

Needs: One Ethernet Switch + 4 VPCS, one OL9 Switch, one OL9 PC

GNS3 project: w03-a4-vlans

Build it

• Drag an Ethernet Switch on to the canvas and cable 4 VPCs to it.
• Assign addresses in the 192.168.10.x range
• Run some pings to ensure all PCs can each the other three
• Record which PC is cabled to which port on the switch, then:
  • Right-click on the switch -> Configure
  • put PC1 and PC4 in VLAN 10
  • put PC2 and PC3 in VLAN 20
• Start a capture on PC4 cable
• Run the same pings as before.

What just happened

• After configuring the VLANs, the network is no longer universally reachable. PC1 can only reach PC4, and PC2 can only reach PC3.
• Broadcasts are no longer delivered to everybody on the network, but only to those in the same VLAN.
• You changed who can hear whom without changing the physical network

Do this - Add another switch

• Add a second Ethernet Switch and re-cable PC3 and PC4 to the second switch
• Put PC3 and PC4 in the same VLANs as before
• Run a cable between the two switches and note the ports on either end of this cable
• On each switch, right-click -> Configure, find the SW1-SW2 port and change it type to dot1q
• Start a capture on SW1-SW2 cable
• Run the same pings as before and ensure PC4 can still hear PC1 and PC3 can still hear PC2.

What just happened

• VLANs work across switches.
• The switch-to-switch cable must carry VLAN information to ensure the other switch know how to deliver the frame.
  • Frames that carry VLAN information are called Tagged Frames and the tags are injected into the frames by the switch
  • The port on the switch that carries tagged frames is called a trunk port (which is what the dot1q type was in the configuration step above).
  • The ports that deliver the frames to end hosts are called access ports. They do not carry tagged frames. The switch removes the tags before delivering it to the recipient.

Do this - Build it by hand

Replace SW2 with an OL9 Switch and record which ports are connected to what:

Configure similar to how you configured the bridge in A1. Then:

nmcli con mod br0 bridge.vlan-filtering yes bridge.vlan-default-pvid 0

The following assumes PC3 is connected to port-eth1, PC4 on port-eth2 and SW1 on port-eth0. If your setup is different, adjust the commands accordingly:

nmcli con mod port-eth1 bridge-port.vlans "20 pvid untagged"

nmcli con mod port-eth2 bridge-port.vlans "10 pvid untagged"

nmcli con mod port-eth0 bridge-port.vlans "10,20"

bridge vlan show

Run the pings as before and ensure the topology behaves the same.

What just happened

• You built a VLAN-enabled switch by hand.
• vlan-filtering tells the bridge to filter traffic based on VLAN ids
• vlan-default-pvid ensure the bridge ports are not placed in a VLAN by default. The default is 1, which tells the port to carry all VLANs
• An access port is defined by setting its ID with pvid untagged because access ports don't carry tagged frames
• Unline the built-in switch, a Linux bridge requires you to specify all VLAN IDs a trunk port is expected to carry.

Do this - Add a management lane

A management VLAN is an administrative channel allowing you to access devices you need to manage (switches, routers, servers, firewalls, etc) while keeping them inaccessible by other users on the network.

We will use this to manage SW2 remotely.

We will use VLAN 99 for management.

First, configure the management PC.

• Add an OL9 PC node to SW1, rename it PC-MGMT and put it in VLAN 99

Now, we have to tell the trunk port on SW2 to carry VLAN 99 too:

nmcli con mod port-eth0 bridge-port.vlans "10,20,99"

bridge vlan show

Give SW1 an IP address so that it can be reached remotely. This is a two-step dance.

First you have to tell the bridge that it's in VLAN 99 itself:

nmcli con mod br0 bridge.vlans "99"
nmcli con up br0

bridge vlan show

But we can't assign the IP address to the bridge itself, otherwise the frames it sends won't be tagged. br0 with an address behaves just like any other host, and hosts don't tag; only switches do. So instead, we create a VLAN interface on the bridge and assign the address to it:

nmcli con add type vlan ifname br0.99 con-name mgmt dev br0 id 99
nmcli con mod mgmt ipv4.method manual ipv4.addresses 192.168.10.200/24 ipv6.method disabled

nmcli con up mgmt

On PC-MGMT:

ping -c1 192.168.10.200

Make sure the ping succeeds before continuing.

On PC-MGMT, create SSH keys and upload the public key to SW2:

ssh-keygen -t ed25519 -C "Management keys" -f ~/.ssh/mgmt-ed25519

ssh-copy-id -i ~/.ssh/mgmt-ed25519.pub admin@192.168.10.200

Edit ~/.ssh.config on PC-MGMT and add the following content:

Host *
    User admin
    IdentityFile ~/.ssh/mgmt-ed25519

Host sw1
    HostName 192.168.10.200

Run a management command. On PC-MGMT:

ssh sw1 "bridge vlan show"

What just happened

• The management VLAN is a separate lane reserved for administrative remote access. Nobody else is allowed in this VLAN
• We needed to use an OL9 Switch to demonstrate accessing a switch remotely, as the built-in Ethernet Switch does not expose a management interface
• The SSH configuration is important. Remote access is almost always achieved this way, not just because it is convenient, but because it is more secure as well. You don't have to worry as much about compromised passwords (but you should probably rotate your keys). This is industry standard.

Record

If it went wrong