niab demo tutorial
lab
Lab diagram
Lab aim
This is the first of five labs that make up the niab tutorial. To
complete
the tutorial, it is recommended that you follow the lab-guides in this
order.
demo-lab-guide: Introduction to using
niab.
<< You are here !
ospf-lab-guide: OSPF tutorial.
bgp-lab-guide: BGP tutorial.
ent1-lab-guide: DNS, email, web tutorial.
isp1-lab-guide: Use external lab connections.
Used as the first lab to be run by new users of niab. Teaches
users how to
start, stop and view the status of a lab. Also covers the basics
of running
the OSPF routing protocol.
Lab overview
View the lab diagram 'demo.png' supplied with this lab.
2 routers, r01 and r02 are joined by a single ethernet link. The
OSPF routing
protocol is running between the two routers. The dummy0 virtual
interfaces on
each router are each assigned an IP addresses which is advertised via
OSPF.
Lab instructions
1) Start the
lab
----------------
- move to the
lab directory
[ncarter:~]>cd
niab-labs/tutorial/demo/
- start the
lab
[ncarter:~/niab-labs/tutorial/demo]>niab
start
[ncarter:~/niab-labs/tutorial/demo]>
2) View the
nodes booting
-------------------------
[ncarter:~/niab-labs/tutorial/demo]>tail
-f log/r01.log
...
Starting
system log daemon: syslogd.
Starting
kernel log daemon: klogd.
Starting
internet superserver: inetd.
Starting
deferred execution scheduler: atd.
Starting
periodic command scheduler: cron. << When you see this,
node is up.
3) Check the
nodes have successfully booted
-------------------------------------------
- check the
node boot logs show node has booted up to starting cron.
[ncarter:~/niab-labs/tutorial/demo]>tail
log/*.log
==>
r01.log <==
...
Starting
deferred execution scheduler: atd.
Starting
periodic command scheduler: cron. << Good
==>
r02.log <==
...
Starting
deferred execution scheduler: atd.
Starting
periodic command scheduler: cron. << Good
- check the
state of the nodes
[ncarter:~/niab-labs/tutorial/demo]>niab
nodes
Host
Processes for lab: demo
UID
PID PPID C STIME TTY
STAT TIME CMD
ncarter
10389 1 0 23:10 pts/3
S 0:02 /usr/bin/linux-niab-0-1-0
ncarter
10395 1 0 23:10 pts/3
S 0:02 /usr/bin/linux-niab-0-1-0
Nodes in lab:
demo
Name
Host TCP-Port PID
Kernel
Filesystem
r01
lilburn 50001 10389
linux-niab-0-1-0
niab-0-1-0.ext2
r02
lilburn 50002 10395
linux-niab-0-1-0
niab-0-1-0.ext2
<< from
the output above we can see
* We have 2
host processes for our lab, one for each router, which is correct.
* We have 2
nodes in the lab, one for each router, which is correct.
* node r01
tty's (consoles) are bound to tcp port 5001, and r02 to port 5002.
4) Restore
the nodes configuration files
Labs are
shipped with the node configuration files stored under node-configs
[ncarter:~/niab-labs/tutorial/demo]>ls
-l node-configs
drwxr-xr-x
3 ncarter
500 4096 Jun 15
15:39 r01
drwxr-xr-x
3 ncarter
500 4096 Jun 15
15:39 r02
nodes are not
shipped preconfigured as then we would require a seperate node
filesystem
file (around 260MB) for each node. This would make lab downloads
very large
and would not scale well on the host system. Instead node
configurations
are shipped as plain text and then restored to each node.
- Restore
node configuration files from host system hard drive to node
filesystem.
[ncarter:~/niab-labs/tutorial/demo]>niab
restore
niab: node
'r01' config restored from ./node-configs/r01
niab: node
'r02' config restored from ./node-configs/r02
[ncarter:~/niab-labs/tutorial/demo]>
5) Activate
the nodes new configuration
- Stop the lab
[ncarter:~/niab-labs/tutorial/demo]>niab
stop
[ncarter:~/niab-labs/tutorial/demo]>
(Wait for the
nodes to stop. Until I have implemented some node signalling,
you will have
to watch your hosts CPU usage / processes to see when the nodes
have
stopped. This will take quite a few minutes on a PC thats a few
years
old.)
- Start the
lab
NB: Do not
restart the lab until you are sure all the nodes have stopped.
[ncarter:~/niab-labs/tutorial/demo]>niab
start
[ncarter:~/niab-labs/tutorial/demo]>
The nodes
will now boot, using there newly restored configuration files.
6) Connect to
node r01
If you are
running X-Windows:
[ncarter:~/niab-labs/tutorial/demo]>niab
term r01
[ncarter:~/niab-labs/tutorial/demo]>
An xterm
connected to r01, displaying a login prompt, will appear.
If you are
not running X-Windows:
- use 'niab
nodes' command to find out which tcp port is bound to r01
[ncarter:~/niab-labs/tutorial/demo]>niab
nodes
...
Name
Host TCP-Port PID
Kernel
Filesystem
r01
lilburn 50003 12063
linux-niab-0-1-0
niab-0-1-0.ext2
r02
lilburn 50004 12069
linux-niab-0-1-0
niab-0-1-0.ext2
- telnet to
the tcp port
[ncarter:~/niab-labs/tutorial/demo]>telnet
localhost 50003
Trying
127.0.0.1...
Connected to
lilburn.
Escape
character is '^]'.
Debian
GNU/Linux 3.0 lilburn
Debian
GNU/Linux 3.0 r01 tty4
r01 login:
7) login to
r01 as root
(By default
nodes come with no password on the root account.)
r01 login:
root
...
r01:~#
8) View r01's
kernel route table
r01:~#
netstat -r
Kernel IP
routing table
Destination
Gateway
Genmask
Flags MSS Window irtt Iface
r02
10.128.2.2 255.255.255.255
UGH 0
0 0 eth0
10.128.2.0
*
255.255.255.248 U 0
0 0 eth0
<< We
can see r02 (the dummy0 address on r02) has an entry in the route table,
which is
good. This route has been sent to the kernel by the zebra routing
daemon, which
in turn has learn't the route from the ospfd daemon. More on
this later !
9) Check
connectivity between r01 and r02 dummy0 address
r01:~# ping
-c 3 r02
PING r02
(10.128.0.2): 56 data bytes
64 bytes from
10.128.0.2: icmp_seq=0 ttl=64 time=1.6 ms
64 bytes from
10.128.0.2: icmp_seq=1 ttl=64 time=1.6 ms
64 bytes from
10.128.0.2: icmp_seq=2 ttl=64 time=1.7 ms
--- r02 ping
statistics ---
3 packets
transmitted, 3 packets received, 0% packet loss
round-trip
min/avg/max = 1.6/1.6/1.7 ms
r01:~#
10) View
r01's zebra route table
- telnet to
the zebra daemon
r01:~# telnet
localhost zebra
Trying
127.0.0.1...
...
Password:
zebra
demo-r01-zebra>
- show the ip
route table
demo-r01-zebra>
sh ip route
Codes: K -
kernel route, C - connected, S - static, R - RIP, O - OSPF,
B - BGP, > - selected route, * - FIB route
O
10.128.0.1/32 [110/10] is directly connected, dummy0, 00:16:26
C>*
10.128.0.1/32 is directly connected, dummy0
O>*
10.128.0.2/32 [110/20] via 10.128.2.2, eth0, 00:15:40 <<
This one !
O
10.128.2.0/29 [110/10] is directly connected, eth0, 00:16:26
C>*
10.128.2.0/29 is directly connected, eth0
C>*
127.0.0.0/8 is directly connected, lo
<< We
can see that the route to r02 dummy0 [10.128.0.2/32] is learn't via ospf
[O], has an
administrative distance of 110 (as all ospf routes do) and has a
cost of
20. Default cost is 10, so this destination is 2 hops away.
One hop
over the
ethernet link and one hop to the dummy0 interface on r02.
- Disconnect
from the zebra daemon
demo-r01-zebra>
exit
Connection
closed by foreign host.
r01:~#
11) View OSPF
on r01
- telnet to
the ospfd daemon
r01:~# telnet
localhost ospfd
Trying
127.0.0.1...
...
Password:
zebra
demo-r01-ospfd>
- view an
overview of the ospf process
demo-r01-ospfd>
sh ip ospf
OSPF
Routing Process, Router ID: 10.128.2.1
Supports
only single TOS (TOS0) routes
This
implementation conforms to RFC2328
RFC1583Compatibility
flag is disabled
SPF
schedule delay 5 secs, Hold time between two SPFs 10 secs
Refresh
timer 10 secs
Number
of external LSA 0
Number
of areas attached to this router: 1
Area
ID: 0.0.0.0 (Backbone)
Number of interfaces in this area: Total: 2, Active: 4
Number of fully adjacent neighbors in this area: 1
Area has no authentication
SPF algorithm executed 3 times
Number of LSA 3
<< Here
we can see our router id is 10.128.2.1. All the routers
interfaces are
in ospf area
0 (the backbone area) and we have 3 LSA's in the database. We
have one
fully adjacent neighbour.
- view ospf
neighbours
demo-r01-ospfd>
sh ip ospf neigh
Neighbor
ID Pri
State Dead
Time Address Interface
10.128.2.2
1 Full/DR
00:00:35 10.128.2.2 eth0:10.128.2.1
demo-r01-ospfd>
<< We
can see that the neighbourship to r02 is 'Full' and that r02 has been
elected the
DR (Designated Router). The interface we originate this
neighbourship
from is eth0 with address 10.128.2.1
- view ospf
database
demo-r01-ospfd>
sh ip ospf database
OSPF Router with ID (10.128.2.1)
Router Link States (Area (0.0.0.0))
Link
ID ADV
Router Age
Seq# CkSum Link count
10.128.2.1
10.128.2.1 190 0x80000004 0x92d7 2
10.128.2.2
10.128.2.2 191 0x80000004 0xa6bf 2
Net Link States (Area (0.0.0.0))
Link
ID ADV
Router Age
Seq# CkSum
10.128.2.2
10.128.2.2 196 0x80000002 0x3beb
<< We
can see we have 3 LSA's. 2 x type-1 LSA's, one from each router
and 1 x
type-2 LSA,
advertised by the DR for that network = r02
- view ospf
LSA
demo-r01-ospfd>
sh ip ospf database network 10.128.2.2
OSPF Router with ID (10.128.2.1)
Net Link States (Area (0.0.0.0))
LS
age: 508
Options: 2
LS
Type: network-LSA
Link
State ID: 10.128.2.2 (address of Designated Router)
Advertising Router: 10.128.2.2
LS Seq
Number: 80000002
Checksum: 0x3beb
Length: 32
Network Mask: /29
Attached Router: 10.128.2.1
Attached Router: 10.128.2.2
<< we
can see this is the LSA for the ethernet subnet that joins r01 and r02.
The network
mask is /29 [255.255.255.248] and we have 2 attached routers,
10.128.2.1 =
r01-eth0 and 10.128.2.2 = r02-eth0
- disconnect
from ospfd
demo-r01-ospfd>
exit
Connection
closed by foreign host.
r01:~#
12) Have a
play ! If you completely break the lab, you can easily restore the
original
setting using the 'niab restore' command on the host system.
NB: To exit
an xterm / telnet connection hold down the Ctrl key and press the
close square
bracket key ']'. Sometimes written as ^]
r01:~#<ctrl>
+ ']'
telnet>close
13) Stop the
lab
[ncarter:~/niab-labs/tutorial/demo]>niab
stop
[ncarter:~/niab-labs/tutorial/demo]>
A word about
node configurations
--------------------------------
Each nodes
configurations are stored in a <node-name>.cow file
[ncarter:~/niab-labs/tutorial/demo]>ls
-l *.cow
-rw-r--r--
1 ncarter 500 262295552 Jun 16
00:24 r01.cow
-rw-r--r--
1 ncarter 500 262295552 Jun 16
00:24 r02.cow
The cow (Copy
On Write) file holds the differences between the node filesystem
file that is
shared between all nodes and the actual filesystem the node thinks
its
using. If you delete a cow file you will lose the nodes
configuration.
You can
backup node configurations, so that if the cow file is corrupted, you
have not lost
your lab configuration. This however is beyond the scope of this
lab
guide. See the niab-how-to if you are interested in more details
on
backing up
node configurations.
14) Move on
to the next tutorial lab (ospf)