Contents

0.1

0.2

0.3

0.1
0.1.1

Linux Switch . . .
0.1.1 Introduction
0.1.2 Practical . .
(*) VLANs . . . .
0.2.1 Introduction
0.2.2 802.1q . .
0.2.3 Practical . .
Switching Practices

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

1
1
1
2
2
3
3
4

Linux Switch
Introduction

Linux systems can be used to build a bridge with multiple NICs (also called switch). An Ethernet bridge/switch is a
device used to connect different Ethernet segments. Each of the Ethernet segments being connected corresponds to
one physical interface in the bridge.

0.1.2

Practical

In Linux, the command brctl is used to set up, maintain, and inspect the Ethernet bridge configuration in the Kernel.
In a Linux APT system (like Debian), we can type the following command to install the utilities for configuring the
Linux Ethernet bridge:
# apt-get install bridge-utils

To create a bridge:
# brctl addbr br1

To remove a bridge:
# brctl delbr br1

Each bridge has a number of ports attached to it. Network traffic coming in any of these ports will be forwarded
to the other ports transparently, so that the bridge is invisible to the rest of the network. To add a port (interface) to a
bridge:
# brctl addif br1 eth0
# brctl addif br1 eth1
# brctl addif br1 eth3

To remove an interface from a bridge:

# brctl delif br1 eth3

To show some information about a bridge and its attached ports:

# brctl show br1

On the other hand, the bridge keeps track of Ethernet addresses seen on each port (MAC learning). When it needs
to forward a frame, and it happens to know on which port the destination Ethernet address (specified in the frame)
is located, it can forward the frame to that port only. However, the Ethernet address location data is not static data.
Devices can move to other ports, network cards can be replaced (which changes the machines Ethernet address), etc.
In this context, we can use the following commands. To show the list of learned MAC addresses by a bridge:
# brctl showmacs br1

To set the Ethernet (MAC) address ageing time, in seconds:

# brctl setageing br1 20

With the previous command, after 20 seconds of not having seen a frame coming from a certain address, the bridge
will time out (delete) that address from the Forwarding Database (FDB).
Finally, to activate the bridge it is mandatory to assing an IP (L3) address to it:
# ifconfig br1 192.168.0.1
br1: port 2(eth1) entered forwarding state
br1: port 1(eth0) entered forwarding state

0.2

(*) VLANs

0.2.1

Introduction

Virtual LANs or VLANs are used to separate hosts that should not be able to access each other and create multiple
distinct L2 broadcast domains. VLANs are implemented on a switch device. Simpler devices only support partitioning
on a port level, so sharing VLANs across devices requires running dedicated cabling for each VLAN. More sophisticated switches can mark frames through tagging, which allows a VLAN span more than one switch without dedicated
links (see Figure 1). When a link is used to transport data for various VLANs it is called a trunk. For example, in
the sample switching topology of Figure 1 there are two trunks.

SW1
Port1

eth0

alice

vlan10

eth1

trunk2 (vlan10,vlan20)

eth0

Port2

SW2
Port3

Port1

eth2

trunk1 (vlan10,vlan20)

eth0

Port2

eth1
eth0

Port3

eth2
eth0

SW3
Port1

eth0

Port2

eth1

Port3

eth2

eth0

carla

vlan10

eth0

eric

vlan20

Port4

eth3
eth0

frank

vlan20

Figure 1: A Sample Switching Topology

There are two types of frames on a VLAN, these are tagged and untagged:
2

bob

david

vlan10

vlan20

 The untagged frame is a regular frame and looks just like a frame that exists on a regular network. Untagged
frames are the most common type on a VLAN. The decision of which VLAN an untagged frame belongs to is
made by the switch because a switch can be configured to assign specific ports to specific VLANs.
A switch can also be configured to receive and switch tagged frames. Then, the output ports are determined
using the VLAN tag.

0.2.2

802.1q

The IEEE 802.1q standard defines the VLAN tag. 802.1q does not actually encapsulate the original frame. Instead,
for Ethernet frames, it adds a 32-bit field (4 bytes) between the source MAC address and the Type/Length fields of the
original frame. This leaves the minimum frame size unchanged at 64 bytes (octets) but extends the maximum frame
size from 1,518 bytes to 1,522 bytes.
A VLAN is assigned a specific id. The standard defines a 12-bit field for the VLAN id and several fields for
Quality of Service (QoS). The VLAN id can be anything between 1 and 4094. VLAN 1 is most commonly used for
management so this should not be used.

0.2.3

Practical

In a Linux APT system (like Debian), we can type the following command to install the user mode programs to manage
VLANs on Ethernet devices:
$ sudo apt-get install vlan

Then, we have to load the 8021q module into the kernel.

# modprobe 8021q

On the other hand, the files in /proc/sys/net/bridge (Debian) are used to filter frames on the bridge devices. In
general, the default configuration is correct but if you want to avoid any filtering you can set them all to 0:
#
#
#
#
#

echo
echo
echo
echo
echo

0
0
0
0
0

>
>
>
>
>

/proc/sys/net/bridge/bridge-nf-call-ip6tables
/proc/sys/net/bridge/bridge-nf-call-iptables
/proc/sys/net/bridge/bridge-nf-call-arptables
/proc/sys/net/bridge/bridge-nf-filter-pppoe-tagged
/proc/sys/net/bridge/bridge-nf-filter-vlan-tagged

You can create/remove a new interface that is a member of a specific VLAN using the commands:
# vconfig add eth1 10
# vconfig rem eth1.10

The first of the previous commands creates a VLAN interface called eth1.10 (VLAN id=10). The existing
configuration of eth1 will not be affected. You can check that the VLANs have been correctly setup by running the
command:
# cat /proc/net/vlan/conf

You can create bridges that contain VLAN interfaces. In this case, tagged traffic received through VLAN interfaces
is stripped of its VLAN header, and presented untagged to the bridge.
For example, next we create a bridge (br1) that includes three interfaces: eth0.10 (VLAN id 10), eth1 and
eth2. Tagged and untagged (native) traffic might enter on eth0. The traffic tagged with VLAN id 10 will be stripped
of its VLAN header and presented untagged to eth1 and eth2. On the other way it happens the reserse operation,
untagged traffic comming from eth1 or eth2 is sent through eth0 with a tag (VLAN id 10). The commands for
this example are:
3

#
#
#
#
#
#
#

vconfig add eth0 10

ifconfig eth0.10 up
brctl addbr br1
brctl addif br1 eth0.10
brctl addif br1 eth1
brctl addif br1 eth2
ifconfig br1 192.168.0.1

On the other hand, we can create also VLAN subinterfaces of a bridge interface. The difference is that when
VLAN subinterfaces are defined on an interface, which is added to a bridge, Linux will strip the VLAN tag. However,
when VLAN subinterfaces are defined on a bridge interface, the VLAN tags are kept. For example:
#
#
#
#
#
#
#
#

brctl addbr br1

brctl addif br1 eth1
brctl addif br1 eth2
vconfig add br1 10
vconfig add br1 20
ifconfig br1.10 up
ifconfig br1.20 up
ifconfig br1 192.168.0.1

In the previous example tagged traffic is presented directly to eth1 and eth2 (with the VLAN tagging intact).
This is the typical configuration for trunk links. Notice that if the bridge does not have a particular VLAN subinterface,
that VLAN traffic will be dropped (e.g VLAN 30 in our example).
In practice, there are also protocols to manage VLANs like VLAN Trunking Protocol (VTP) and Multiple Registration Protocol (MRP).

0.3

Switching Practices

Switch

Switch

B
(a) One Chat.

(b) Two Chats.

Figure 2: LLC1 Chats.

Exercise1 The goal of this practice is to test a LLC over Ethernet transmission with physical equipment (hosts and
switches). In particular, we will use a simple client/server chat using LLC1.
As server, we use the application server-chatllc.py:
# ./server-chatllc.py -h
Server for chat with LLC1
Version 1.0 by JLM
Options:
[-h, --help]
[-i, --iface] <listening interface> by defalut eth0
[--sap <sap>] <listening SAP>
by default 0x88

As client, we use the application client-chatllc.py:

# ./client-chatllc.py -h
Client for chat with LLC1
Version 1.0 beta by JLM
Options:
[-h, --help]
-d, --dst_mac <destination mac>
[-o, --outif] <ouput interface>
[--ssap <ssap>]
[--dsap <dsap>]

by default eth0
by default 0x88
by default 0x88

1. As shown in Figure 2a, create a chat between two hosts using the parameters that you consider necessary.
Capture traffic, exchange 5 o 6 text messages in the chat and explain the protocol fields of the traffic captured
(MAC addresses, etc.).
Explain also how the chat works.
2. Using three hosts, create two chats as shown in Figure 2b.
Explain the parameters that you have used.
For the rest of the exercises we use an emulated scenario with virtual equipment (that works exactly the same as
physical equipment). To start the simulation scenario of Figure 3, execute on your phyhost the following command:
phyhost:~# simctl switching start

SW1
Port1

eth0

Port2

eth1

SW2
Port3

Port1

eth2

tap2

tap0
eth0
tap1

alice

eth0

Port2

eth1
tap3
eth0

Port3

eth2
tap4
eth0

SW3
Port1

eth0

Port2

eth1

Port3

eth2

tap5
eth0

carla

tap6
eth0

eric

Port4

eth3

bob

david

tap7
eth0

frank

Figure 3: Scenario for testing Switching

Exercise2 The goal of this practice is to test a LLC over Ethernet transmission with emulated equipment (hosts and
switches). In particular, we will use the simple LLC1 client/server chat. The commands for the client and the server
are in the directory /tmp of the virtual machines.
1. Using alice and bob, create a chat between these hosts as shown in Figure 2a using the parameters that you
consider necessary.
Capture traffic with wireshark in tap2 in the phyhost and set the display filter: !ipv6 and !igmp
Exchange 5 o 6 text messages in the chat and explain the protocol fields of the traffic captured (MAC addresses,
etc.).
5

2. Using alice, bob and carla, create two chats as shown in Figure 2b.
Explain the parameters that you have used.
Exercise3 The goal of this practice is to study the MAC learning process of switches using the emulated scenario.
To do so, we are going to use a simple application called send-frame.py that you can find in the directory /tmp.
This application can be used to send LLC1 frames (use the -h option to see how it works).
1. Get a console of SW1 (which is a Linux box used to build a switch with 3 ports) and type the following
command:
root@SW1:~# watch -n 5 brctl showmacs br1

The previous command shows the MAC table of the switch every 5 seconds. Remember that the MAC table
contains the MAC addresses learned by the switch. On the other hand, the ageing in the switches is set to
1 minute.
Capture in tap1 and tap2 and send a frame from alice to bob using send-frame.py.
Explain the traffic captured in each Tap and the time evolution of the MAC addresses of alice and bob (only
these) in the MAC table of SW1.
2. Wait for a minute and repeat the experiment sending:
One frame from alice to bob.
Before 60 seconds of the previous transmission, send another frame from alice to bob.
Before 60 seconds of the previous transmission, send another frame from bob to alice.
Explain the traffic captured in each Tap and the time evolution of the MAC addresses of alice and bob (only
these) in the MAC table of SW1.
3. Increase the ageing in all the switches to 10 minutes. Using alice, bob and carla, create two chats as shown in
Figure 2b. Capture traffic in tap2 and tap1, exchange 5 or 6 text messages in each chat and explain the traffic
that you observe in each Tap.
Exercise4 (*) The goal of this practice is to study and test VLANs.
1. In SW3, create one LAN for the ports 1 and 3 and another LAN for the ports 2 and 4.
Explain your configuration. Do you need any VLAN id? Test your configuration with our LLC1 chat application.
2. Create a configuration in the switches in which, hosts send untagged frames but they belong to the following
VLANs:
VLAN 10: alice, bob and carla.
VLAN 20: david, eric and frank.
Explain your configuration.
Capture traffic in trunk interfaces (tap1 and tap2) and in the host tap interfaces that you consider useful.
Then, test your configuration appropriately with send-frame.py and the L2 broadcast address.
Discuss the results and the format of the VLAN frames.