Advanced Internetworking:

ISP Project: KISSNET

Wouter Veugelen
Tom Gilis
Ben Boogaerts
Kerem Kocaer
Ahmad Bijairimi Abdul Awal

Introduction
According to us, the purpose of the project was to introduce the students with the practical
side (implementation) of dynamic routing, more specific OSPF, using a given realistic theme
like:Starting an ISP.
For this, we had to implement some mandatory services and one optional service. The main
focus was however the OSPF interaction. We had to assure that our clients, during a
change in the network topology, experienced minimal repercussion on the reachability of
the services. The network had to be flexible enough to repair itself.
Next to this, it was also mandatory that the other existent ISPs could connect to our network,
using for example a webbrowser on their client machines to connect to our webserver.
This report discusses: the choice we made in picking our optional service, the
implementation of the services, the setup we used, the problems that occurred, the testing
procedure that was applied and our conclusion.

Services to implement
OSPF
OSPF is a link-state routing protocol. It maintains the state of every link in our domain, has
to assure that all the routers receive the same information for their link-state database and is
responsible to produce a shortest-path tree.
The implementation of OSPF and not another routing protocol was mandatory.

DNS
DNS is a name-resolution service using a database of host names and IP-addresses.
Like we know DNS is organized in a hierarchical tree structure, it consists of multiple levels
of domains (root top second sub host).
For our ISP we took KISSNET.LAB. as domain name. Therefore the FQDN for one of our
service-providing hosts (e.g. webserver) would be WWW.KISSNET.LAB.

DHCP
Each client (host) connecting via our ISP has to be given a Layer-3 IP address, so that it can
communicate with the network and with the outside world. The client also has to know about
the DNS server and the main gateway that it has to use. These informations have to be
communicated to the client with some protocol. DHCP which is also used today for the
Internet - is the protocol that we used to implement dynamic address assignment.

VOIP
A service a lot of ISPs are starting to offer to their customers is VoIP. Different standardised
protocols are available to implement VoIP: H323, SIP, MGCP. We chose to implement SIP,
since this protocol is the most known and supported protocol used today for VoIP.

WWW
Every ISP requires a web server , not only for the publication and announcing their own
services but also allow their customers to set up small websites for their own . We set up a
web server and made a small website so when the customers surf to WWW.KISSNET.LAB
theyll see our website and read about our services.

Setup
Topology
Because of the limited hardware resources, we based ourselves on the possible setup,
described in the ISP Demonstration document. We are aware that this is not comparable
with a real-life scenario, but as stated in the introduction, the focus lays on the
implementation and usage of OSPF.
We received a /16-network: 10.4.0.0/16 and were free to subnet it to our needs. Therefore
we decided to split it up in three /24-networks, one for our clients, one for some of our
services (DNS) and the last for the rest of our services (WWW / VOIP).
We also received a /24-address for our top router: 10.0.0.104 that was in direct connection
with the top routers of the other ISPs.

Physical Setup
We used 5 Linux machines in our setup:

Machine 1: Top Router Web Server VOIP Server

CentOS 3.5 / Linux kernel 2.6

Machine 2: DNS1 (Master DNS) OSPF Router

FreeBSD

Machine 3: DNS2 OSPF Router

VMWare v5.0 Virtual Machine (128MB RAM / 4GB HD)

Debian GNU/Linux kernel 2.4.27-2-386

Machine 4: DHCP OSPF Router

Fedora Core 4 / Linux kernel 2.6 (512MB RAM / 5GB HD)

Machine 5 & 6: Host1 Host2

Dell laptops provided during the lab.

Four Switches
We used 4 switches in our topology.
The toprouter connected on one interface (10.0.0.104) to the switch on which all ISPs
were connected to.
The toprouter connected with his other interface to a switch (10.4.1.1) on which DNS1
and DNS2 were connected to.
DNS1 and DNS2 used their other interface to connect to a switch that was also used
by our DHCP (10.4.2.4).
The other interface of the DHCP (10.4.3.4) connected to a switch, also used by the
clients

Implemented Services
Mandatory
Master DNS (DNS1):
IP: 10.4.1.2/24
IP: 10.4.2.2/24
In this project two DNS servers have been setup, one as a Primary DNS server (master) and
the other one as a Secondary DNS server (slave). Here we use BIND version 9.3 for the
DNS server's software, installed and configured on the machines running FreeBSD and
Linux. Each servers Master and Slave are acting as a router and both of them are running
ospfd daemon.
In the beginning we configured both of the DNS server's interfaces as a host address in the
resource record. As an example, ns1.kissnet.lab has 10.4.1.2 and 10.4.2.2 as it's IP address
of the interface eth0 and eth1. In the db.kissnet.lab we declared both IP address as a A
record of ns1.kissnet.lab.
For a while it seems that everything is ok, but when one interface goes down we faced with
the intermittent problem which we can't ping ns1.kissnet.lab. We stop the pinging and we try
to ping again and the process is successful. Then we try to ping again and it's unreachable!.
Later we realized that when we ping ns1.kissnet.lab, first the system will ping 10.4.1.2 and
then if we start to ping again, the system will ping the second interface 10.4.2.2. So, it's
interchangeable. Thus we decided to set only one interface as an A record.

Slave DNS (DNS2):

IP: 10.4.1.3/24
IP: 10.4.2.3/24
We had one Slave DNS server that obtained its read-only zone files from the Master DNS.
The configuration was rather straightforward, defining the zone (KISSNET.LAB) and reverse
lookup zone (4.10.in-addr.arpa) as slave in the named.conf file of BIND, configuring for both
the 10.4.1.2 address of the MASTER DNS.
As soon as we were sure that the master was online and reachable, we started the Slave
DNS and the read-only files arrived as expected, in the /etc/bind/slave directory of our
system. We defined the resolv.conf file of the server to point to itself for name resolving, with
the master as secondary nameserver.
Along with the webserver, this was by far the easiest server to set up.

Top Router:
Internal Router (DNS1 DNS2 DHCP):
To setup routing between the different network cards on the machines, only 1 configuration
change is needed:
sysctl w net.ipv4.ip_forward=1
When configuring it like this, after a reboot the command has to be executed again. To make
this configuration change permanent, this option can be configured in the file
/etc/sysctl.conf
After that, Zebra / Quagga has to be installed .
It could be configured using following commands:
Router : telnet localhost 2601

OSPF: telnet localhost 2604

The internal OSPF router has to know about to which subnet(s) its directly connected to and
to which area the connected subnet(s) belongs to. (define IP in Zebra config, define
responsible subnets + area in OSPF config).

DHCP:
IP: 10.4.2.4/24
IP: 10.4.3.4/24
The DHCP Server has for its goal to dynamically assign Layer-3 IP addresses to clients
(hosts) that connect to our ISP. As the clients are situated on our LAN-3 (see figure
backbone) within our backbone, they will receive IP addresses like 10.4.3.X. Our DHCP
Server has the static IP 10.4.3.4, so for simplicity X will be between 5 and 254.
The DHCP Server of our ISP has been implemented with the ISC DHCP distribution that we
downloaded from the products web site (http://www.isc.org).
After a clean installation, the first thing that had to be done was to configure the dhcpd.conf
configuration file of the DHCP Server. The content of this file is as below :
ddns-update-style none;
option domain-name "kissnet.lab";
subnet 10.4.3.0 netmask 255.255.255.0 {
option routers
option subnet-mask

10.4.3.4;
255.255.255.0;

option domain-name-servers

10.4.2.2,10.4.2.3;

range 10.4.3.5 10.4.3.254;

default-lease-time 21600;
max-lease-time 43200;
}

Some notes about this file :

Line 3 specifies the subnet for which the information follows in bracket. In this case, it
is 10.4.3.0/24 as we said before.

option routers specifies the main gateway for the clients. In this case, it is the
address of the DHCP Server, who also acts as a forwarding router for the clients.

option domain-name-servers specifies the DNS addresses that the clients should
use. As we have two DNS Servers in our ISP, we inform their addresses with this
line.

range 10.4.3.5 10.4.3.254 specifies the range of IP addresses that can be assigned
to clients. Note that we could also have assigned addresses 10.4.3.1-10.4.3.3 by
simply adding another line range 10.4.3.1 10.4.3.3. (10.4.3.4 is reserved for the
DHCP server itself)

default-lease-time and max-lease-time define values for address leasing. We used

the default values.
As seen above, the DNS and default gateway addresses are and have to be also
informed to the clients by the DHCP Server during the dynamic address assignment.

Webserver:
IP : 10.4.1.1/24
IP : 10.0.0.104/16
We used Apache software for the web server . Apache is one of the most popular web server
software for linux. When apache is installed he makes a directory www in the /var/ directory.
When somebody asks for a webpage Apache is going to look for the page in that directory.
The default webpage is index.html , so we made such a file with our company information
and put it into the /var/www directory. When somebody surf to www.kissnet.lab he looks for
an entry in the DNS where www points to 10.0.0.104. So hell open the default webpage and
see our company information.

Optional service:
VOIP:
IP : 10.4.1.1/24
We implemented the Asterisk open source VoIP PBX. After installation, changes to the
configuration files can be done in the folder /etc/asterisk/ . This PBX is by default configured
to be used with the SIP protocol, but configuring it for using H323 is also possible.
In sip.conf , some SIP configuration parameters are found. In sip_additional.conf, additional
phonenumbers can be added/configured. Also authentication parameters for each phone
can be added there. Beware that in the extensions_additional.conf file, you also need to
configure your newly added phonenumbers .
We found an very interesting add-on for Asterisk, Asterisk Management Portal. This is a
management portal where it is possible to configure all options by using a webbrowser
instead of editing all configuration files manually:
Asterisk : http://www.asterisk.org/
Asterisk Management Portal: http://sourceforge.net/projects/amportal

Testing procedure
Connection :
Before we could try our services we tried if everybody could reach each other. Through the
ping command we could easily find this out. In case of problems we used traceroute and
ethereal to see where the packets are send out and what the destination and source of them
are. When we noticed that even the DHCP clients could ping the top router we were sure that
the OSPF protocol was doing his work.

OSPF :
To fully test the right functioning of the OSPF protocol we disconnected one router of the two
duplicate routers at a time. By doing this and up serving the behaviour of the OSPF routing
table on the other routers we could see if the designated router changes and their fore
automatically select a different route to send the packets on. It sometime took a while , about
an minute , for the changes to become effective but eventually it always did an the network
was fully operational again.

DNS :
All the PCs in our network are configured with our 2 DNS server in their resolv.conf.
Therefore if one gets down, we still can do name resolving and continue using our services.
To check if the name resolving (and reverse lookup) works we used the command nslookup.
By running nslookup ns1.kissnet.lab we could be able to resolve that to 10.4.2.2 . The
same worked for reverse lookup. Of course this wasnt the hard part. Because other ISPs
should be able to contact us (and of course we should be able to contact them) we also tried

to resolve some hosts on the others ISPs. We also used nslookup for this checking. In our
own ISP we were able to resolve some hosts on other ISPs but that didnt mean that our
configuration was good. To check whether we made the right changes on the top .LAB
nameserver we logged on to it and tried to resolve a few hosts. When we got a positive result
from that we new that the top level nameserver passed his kissnet.lab queries onto our
nameserver.

DHCP :
Having configured the server properly, we can run it by typing dhcpd eth2 start, eth2
specifying on which interface it has to act as a DHCP server. Here, the clients are connected
on the interface eth2 (with ip address 10.4.3.4), so we specify eth2. The host can now obtain
their address by running dhclient. After assigning an IP to a host, we tested to see that it
was now part of our network and thus could ping every other computer, as well as other
hosts within and outside our ISP.

DHCP :
For testing if VoIP was working, 23 VoIP clients had to be configured. We used X-Ten
Eyebeam on 1 windows PC, and kphone on another Linux PC. As sip registrar address we
had to configure voip.kissnet.lab , and a username/password on each phone, that we
previously had configured on the Asterisk server. After configuration of the clients,
registration at the SIP server takes place, and we were able to setup calls.

Problems
The biggest problem we experienced, had to do with IP configuration and routing. After
configuring OSPF, no changes to the IP or routing table in Linux could cannot be made
anymore. You have to configure the IP addresses of your network interfaces in Linux to
0.0.0.0 first, and then configure your IPs and routing in Zeba / Quagga. Testing procedures
(VoIP)

Results
During the demonstration, we were able to verify every mandatory service that we had to
provide, including two DNS servers, one DHCP server, one Web Server and OSPF dynamic
routing. We could successfully test them within our network with topology changes, ping
and traceroute experiments, as well as with the other Spidernet and Innovanet ISPs.
Moreover, we were able to verify our VoIP service by testing voice communication between
two hosts connected to our ISP. We could not test to communicate over VoIP with other
ISPs, because we did not know what we had to configure extra for that. However, that
seemed not a very difficult task; we have to add SRV records to our DNS server
configuration files and our VoIP servers should then be able to communicate with each other
and be able to successfully authenticate with each other.

Conclusion
We all found this an very interesting project to participate. We are now able to setup and
troubleshoot the major services an ISP offers. This project also improved our knowledge of
working with the Linux operating system.

Appendix
Secondary DNS
Files in /etc/bind/slave directory on Slave DNS

DNS Zone-file for KISSNET.LAB on Slave DNS

DNS Zone-file for 4.10.in-addr.arpa on Slave DNS

IFCONFIG on Slave DNS (2 network interfaces)

Routetable on Slave DNS

OSPF
OSPF Route on Internal OSPF Router

OSPF Running Config on Internal OSPF Router

VoIP
Configuration of the phonenumbers in sip_additional.conf located in /etc/asterisk/

Writing credits
Ben Boogaerts :

Introduction
Services to implement (OSPF/DNS)
Setup : topology , physical setup (DNS2)
Implemented services : DNS2

Tom Gilis :

Services to implement (WWW)

Testing procedures (Connection , OSPF , DNS)

Kerem Kocaer:

Services to implement (DHCP)

Testing procedures (DHCP)
Results

Wouter Veugelen : Services to implement (VoIP)

Services to implement (Routing)
Testing procedures (VoIP)
Testing Problems
Bin Abdul Awal
Ahmad Bijairimi :

Services to implement (DNS1, Routing - OSPF)