1. No category

University of Rome “Sapienza”
NETWORK INFRASTRUCTURES
A.A. 2010 - 2011
PRACTICAL EXCERCISES ON
NETKIT
Eng. Angelo Coiro
(coiro@infocom.uniroma1.it)
LESSON IV
BRIDGING: HOW TO CONFIGURE
A NETWORK SWITCH
(references: http://wiki.netkit.org/)
[ 2 | 34 ]
NETWORK INFRASTRUCTURES – Practical exercises on Netkit – Lesson IV
1
SUGGESTION
• To better understand this part, you can download
from the Netkit’s site…
http://wiki.netkit.org/index.php/Labs_Official
…the lab associated to it, namely:
Bridging
to practically perform the different steps explained in
the next slides.
[ 3 | 34 ]
NETWORK INFRASTRUCTURES – Practical exercises on Netkit – Lesson IV
STEP 1 – NETWORK TOPOLOGY
• All the MAC addresses are in the form: 00:00:00:00:XX:YY
• A B C are the collision domains
[ 4 | 34 ]
NETWORK INFRASTRUCTURES – Practical exercises on Netkit – Lesson IV
2
STEP 2 – STARTING THE LAB
• The started lab is made up of
•
3 virtual machines that implement the pcs
•
2 virtual machines that implement the switches
• automatically configured to perform switching
•
[ 5 | 34 ]
all the virtual machines and their network interfaces
are automatically configured
NETWORK INFRASTRUCTURES – Practical exercises on Netkit – Lesson IV
STEP 3 – CONFIGURING NETWORK
INTERFACES (1/6)
• Real network interfaces have a wired in mac
address
•
•
the first three bytes make up the Organizationally
Unique Identifier (OUI), a sequence that matches the
vendor of the nic
the remaining three bytes are the interface serial
number
• Mac address of an interface card manufactured
by Asustek inc.:
[ 6 | 34 ]
NETWORK INFRASTRUCTURES – Practical exercises on Netkit – Lesson IV
3
STEP 3 – CONFIGURING NETWORK
INTERFACES (2/6)
• Virtual network interfaces are automatically
assigned a mac address
•
[ 7 | 34 ]
Depending on the version of netkit in use, the mac
address might be derived from the ip address
NETWORK INFRASTRUCTURES – Practical exercises on Netkit – Lesson IV
STEP 3 – CONFIGURING NETWORK
INTERFACES (3/6)
• The mac address of a virtual network interface
can be forcedly configured in the following way:
[ 8 | 34 ]
NETWORK INFRASTRUCTURES – Practical exercises on Netkit – Lesson IV
4
STEP 3 – CONFIGURING NETWORK
INTERFACES (4/6)
[ 9 | 34 ]
NETWORK INFRASTRUCTURES – Practical exercises on Netkit – Lesson IV
STEP 3 – CONFIGURING NETWORK
INTERFACES (5/6)
[ 10 | 34 ] NETWORK INFRASTRUCTURES –
Practical exercises on Netkit – Lesson IV
5
STEP 3 – CONFIGURING NETWORK
INTERFACES (6/6)
• The mac address of a virtual network interface
can be forcedly configured in the following way:
[ 11 | 34 ] NETWORK INFRASTRUCTURES –
Practical exercises on Netkit – Lesson IV
STEP 4 – BRIDGING CAPABILITIES (1/2)
• The command brctl allows to check and
configure the settings of the bridging capabilities of
a virtual machine
[ 12 | 34 ] NETWORK INFRASTRUCTURES –
Practical exercises on Netkit – Lesson IV
6
STEP 4 – BRIDGING CAPABILITIES (2/2)
• A virtual machine may enable several bridging
processes (on different network interfaces)
• Once configured, a bridge is visible as a network
interface that must be brought up in order to
function properly
[ 13 | 34 ] NETWORK INFRASTRUCTURES –
Practical exercises on Netkit – Lesson IV
STEP 5 – INVESTIGATING SOURCE ADDRESS
TABLES (1/3)
• If the pcs do not generate any traffic, the source
address tables only contain information about local
ports
[ 14 | 34 ] NETWORK INFRASTRUCTURES –
Practical exercises on Netkit – Lesson IV
7
STEP 5 – INVESTIGATING SOURCE ADDRESS
TABLES (2/3)
• Depending on the configuration, a machine may
generate traffic even
broadcast packets)
•
•
if
not
solicited
(e.g.,
the source address tables of switch1 and switch2
may already contain non-local entries
hard to prevent
• Ports (=interfaces) are numbered according to
the 802.1d standard
•
the correspondence between kernel interface
numbering (ethX) and 802.1d numbering can be
obtained by using brctl showstp
[ 15 | 34 ] NETWORK INFRASTRUCTURES –
Practical exercises on Netkit – Lesson IV
STEP 5 – INVESTIGATING SOURCE ADDRESS
TABLES (3/3)
[ 16 | 34 ] NETWORK INFRASTRUCTURES –
Practical exercises on Netkit – Lesson IV
8
STEP 6 – EVOLUTION OF THE ADDRESS
TABLES (1/12)
• Start a sniffer on pc3:
• Generate traffic between pc2 and pc3:
[ 17 | 34 ] NETWORK INFRASTRUCTURES –
Practical exercises on Netkit – Lesson IV
STEP 6 – EVOLUTION OF THE ADDRESS
TABLES (2/12)
[ 18 | 34 ] NETWORK INFRASTRUCTURES –
Practical exercises on Netkit – Lesson IV
9
STEP 6 – EVOLUTION OF THE ADDRESS
TABLES (3/12)
• pc3 sees the traffic exchanged on its collision
domain (C)
[ 19 | 34 ] NETWORK INFRASTRUCTURES –
Practical exercises on Netkit – Lesson IV
STEP 6 – EVOLUTION OF THE ADDRESS
TABLES (4/12)
[ 20 | 34 ] NETWORK INFRASTRUCTURES –
Practical exercises on Netkit – Lesson IV
10
STEP 6 – EVOLUTION OF THE ADDRESS
TABLES (5/12)
[ 21 | 34 ] NETWORK INFRASTRUCTURES –
Practical exercises on Netkit – Lesson IV
STEP 6 – EVOLUTION OF THE ADDRESS
TABLES (6/12)
[ 22 | 34 ] NETWORK INFRASTRUCTURES –
Practical exercises on Netkit – Lesson IV
11
STEP 6 – EVOLUTION OF THE ADDRESS
TABLES (7/12)
[ 23 | 34 ] NETWORK INFRASTRUCTURES –
Practical exercises on Netkit – Lesson IV
STEP 6 – EVOLUTION OF THE ADDRESS
TABLES (8/12)
[ 24 | 34 ] NETWORK INFRASTRUCTURES –
Practical exercises on Netkit – Lesson IV
12
STEP 6 – EVOLUTION OF THE ADDRESS
TABLES (9/12)
[ 25 | 34 ] NETWORK INFRASTRUCTURES –
Practical exercises on Netkit – Lesson IV
STEP 6 – EVOLUTION OF THE ADDRESS
TABLES (10/12)
[ 26 | 34 ] NETWORK INFRASTRUCTURES –
Practical exercises on Netkit – Lesson IV
13
STEP 6 – EVOLUTION OF THE ADDRESS
TABLES (11/12)
[ 27 | 34 ] NETWORK INFRASTRUCTURES –
Practical exercises on Netkit – Lesson IV
STEP 6 – EVOLUTION OF THE ADDRESS
TABLES (12/12)
• switch2 knows the positions of pc2 and pc3
since it has seen their traffic
• switch1 does not know the position of pc3
since pc3’s traffic has been filtered out by
switch2
• The two switches are not aware of pc1
[ 28 | 34 ] NETWORK INFRASTRUCTURES –
Practical exercises on Netkit – Lesson IV
14
STEP 7 – FILTERING IN ACTION (1/6)
• Clear the address tables by setting the lifetime
(ageing) of the entries to 10 seconds:
• After 10 seconds of “silence” only the local
interfaces remain in the source address tables
[ 29 | 34 ] NETWORK INFRASTRUCTURES –
Practical exercises on Netkit – Lesson IV
STEP 7 – FILTERING IN ACTION (2/6)
• Repeat the ping experiment with a 3 seconds
interval and place a sniffer on pc1:
[ 30 | 34 ] NETWORK INFRASTRUCTURES –
Practical exercises on Netkit – Lesson IV
15
STEP 7 – FILTERING IN ACTION (3/6)
[ 31 | 34 ] NETWORK INFRASTRUCTURES –
Practical exercises on Netkit – Lesson IV
STEP 7 – FILTERING IN ACTION (4/6)
• Since the switches filter traffic, only broadcast
packets can reach pc1:
[ 32 | 34 ] NETWORK INFRASTRUCTURES –
Practical exercises on Netkit – Lesson IV
16
STEP 7 – FILTERING IN ACTION (5/6)
• Keep the ping active and reduce the lifetime of the
entries of the source address table:
• In this way, the entries expire after each echo request has
been sent (echo requests are sent every 3 seconds)
•
•
every time pc2 generates an echo request:
• switch2 does not know about pc3, hence performs flooding
• switch1 does not know about pc3, hence performs flooding
• as a consequence, pc1 sees the echo request sent by pc2
every time pc3 generates an echo reply:
• switch2 knows about pc2 (thanks to the echo request) and
filters traffic
• as a consequence, neither switch1 nor pc1 see the echo
reply
• note that echo replies are sent within the 1 second lifetime
[ 33 | 34 ] NETWORK INFRASTRUCTURES –
Practical exercises on Netkit – Lesson IV
STEP 7 – FILTERING IN ACTION (6/6)
• pc1 only sees the echo requests:
•
•The arp reply sent by pc3 to pc2 is filtered because
switch2 knows about pc2 (thanks to the arp request)
• The first echo request is also filtered because immediately
after the arp exchange switch2 still knows about pc3
[ 34 | 34 ] NETWORK INFRASTRUCTURES –
Practical exercises on Netkit – Lesson IV
17