De La Salle University Manila

Gokongwei College of Engineering

Title : LBYEC57 Project

Date Submitted : April 15, 2017

Instructor : Engr. Jose Antonio Catalan

Group Number : 2

Subject / Section : LBYEC57 / EL1

Members :
Chan, Zion
Domingo, Vernice
Kang, Ivan
Regino, Carl
Sy, Shaun

Total : __________________

Remarks :
__________________________________________________________________
__________________________________________________________________

Instructor’s Signature : ________________

1
 Table of Contents

I. Abstract 3

II. Design Consideration 3-6

A. Individual Contributions 5-6

III. Methodology

A. VLAN Implementation 6-7

B. DHCP assignment 7-9

C. InterVLAN routing 9-10

IV. Data and Result 11-17

V. Conclusion/Summary 17

2
I. Abstract

The project is all about the implementation of VLANs in a network. VLANs are important
especially in business mainly because it allows for segmentation in a network. For example, a
subnet can be given solely for Department A and another can be given solely for Department B.
Subnetting for a subgroup inside a supernet can be done using VLANs. However, these
departments still needs to communicate and this contradicts with the feature of VLAN that only
allows interconnection of hosts within a VLAN. This project shows the interconnection of VLANs
or InterVLAN connectivity enabled using a group of routers that can act as the DHCP server as
well as the routing mechanism of the InterVLAN connection.

II. Design Consideration

Table 1.1. VLSM Subnetting

VLAN Number Allocation Network First Host Last Host Broadcast
of Hosts (hosts) Address Address Address Address

VLAN58 16 30 10.3.24.0/27 10.3.24.1 10.3.24.30 10.3.24.31

VLAN60 18 30 10.3.24.32/27 10.3.24.33 10.3.24.62 10.3.24.63

VLAN57 12 30 10.3.24.64/27 10.3.24.65 10.3.24.94 10.3.24.95

VLAN59 22 14 10.3.24.96/28 10.3.24.97 10.3.24.110 10.3.24.111

VLAN61 9 14 10.3.24.112/2 10.3.24.113 10.3.24.126 10.3.24.127

8

VLAN1 5 6 10.3.24.128/2 10.3.24.129 10.3.24.134 10.3.24.135

9

*VLAN1 is the sixth VLAN used by the group to enable routing between the routers. The sole members of
VLAN1 are the five routers used in the project - that is R1 to R5.

The project is composed of 5 subnets each consisting of 4 VPCS each and a XP VM

where each PC such as the 1st PC of subnet 1, the 2nd PC of subnet 2 and so on belongs to the
same VLAN with a total of 5 VLANS. This is done by setting up the connections using GNS3 for
each VM and configuring the router and switch by the specifications given in Table 1.1.
However, there are a lot of problems that needs to be solved such as that the connection of the
host and VM aren’t connected. This could be done by using a bridge adapter. Connecting the
VM to one another in the same laptop can be easily done as the bridged connection in between
VMs are shared, therefore can be considered as connected already. However, since the
requirement is that only a maximum of 2 subnets per laptop are allowed, we need to connect
the VM together by other means, as in this case a router.

3
 Figure 1.1. A sample subnet to be implemented in the project (5 needs to be implemented)

To connect the VM located in a different device, a cloud must first be configured. The
cloud has only one IP address that is, the IP Address assigned by the external router to the
Bridged Connection. As shown in Figure 1.1, a Cisco3600 router ISO is set-up labeled as R1.
The R1 would act as the DHCP server for a certain VLAN. Each VPCS/XPVM must also be a
member of a different VLAN. The router must be able to assign IP Addresses only to the
members of the VLAN specified when requested. A laptop would have a maximum of two
networks in it, each network running in its own GNS3 network simulation in its own Virtual
Machine. Essentially, a successful communication between three laptops (for five connections)
is needed to completely assign an IP Address to all VPCS/XPVMs. The assignment of VLANs
as well as the renaming of the VPCS/XPVMs is shown below:

Table 1.2. VLAN Assignments

VLAN Assigned to

57 Zion Chan

58 Ivan Kang

59 Vernice Domingo

60 Carl Regino

61 Shaun Sy

VLAN Membership Summary

4
 Zion Chan
Router – R1 Ivan Kang
VPCS1a – VLAN57 Router – R3
VPCS1b – VLAN58 VPCS3a – VLAN60
VPCS1c – VLAN59 VPCS3b – VLAN61
VPCS1d – VLAN60 VPCS3c – VLAN57
XPVM – VLAN61 VPCS3d – VLAN58
XPVM-B – VLAN59
Vernice Domingo
Router – R2 Carl Regino
VPCS2a – VLAN61 Router – R4
VPCS2b – VLAN57 VPCS4a – VLAN59
VPCS2c – VLAN58 VPCS4b – VLAN60
VPCS2d – VLAN59 VPCS4c – VLAN61
XPVM-A – VLAN60 VPCS4d – VLAN57
XPVM-C – VLAN58

Shaun Sy
Router – R5
VPCS5a – VLAN58
VPCS5b – VLAN59
VPCS5c – VLAN60
VPCS5d – VLAN61
XPVM-D – VLAN57

After a successful DHCP assignment, each VPCS/VPVM must be able to ping ALL
OTHER VPCS/XVPMs. Also, XPVMs must be able to establish a TCP NCAT or TELNET
connection to the other XPVM, taking into account that these XPVM is essentially a member of
a different VLAN. If one thinks about it, a VPCS/XPVM can only communicate to those who are
members of the same VLAN. This however needs to be bypassed using routing, implemented in
the routers.

Individual Contributions
● Carl Regino is the one who did the VLSM subnetting as well as outlined the
VPCS/XPVM renaming and VLAN assignments. His laptop is also going to be used in
the demonstration - handling the VLAN subnets of his own and Ivan Kang’s. Worked
hand-in-hand with Zion Chan to figure out many of the codes to input into the router from
VLAN implementation to DHCP assignments to InterVLAN networking.
● Zion Chan is the one responsible for another laptop to be used in the demonstration -
handling the VLAN subnets of his own and Vernice Domingo’s. Worked hand-in-hand
with Carl Regino to figure out many of the router configuration codes from VLAN
implementation to DHCP assignments to InterVLAN networking.

5
 ● Ivan Kang is the one responsible for the fifth subnet and is responsible for its
configuration.
● Shaun Sy provided the third laptop that will be used; as Ivan Kang’s laptop cannot run
Virtual Box. Mr. Kang’s project files will be run using Shaun Sy’s laptop in the project
presentation.
● Vernice Domingo provided the external router that is to be used for the project.

III. Methodology

First, the set-up of the Virtual Machine must be explained. In this case, the Virtual
Machine would need to have two active adapters - an internal network and bridged network.
The internal network is the one that is used to connect the Host GNS3 to the network switch
therefore integrating the Virtual Machine to the GNS3 circuit. The bridged network would be the
one that would connect the GNS3 implementation to the external router. This would need to be
done five times, one per VM for a total of 5 VMs.

There are three things that needs to be addressed in the network set-up: implementation
of VLAN, DHCP assignment per VLAN and InterVLAN routing. The methodology will be broken
down into those three parts.

A. VLAN Implementation
The implementation of VLAN is done per router. The router would only support the
VLANs assigned to it and will ignore the others. In essence, there are going to be 5 routers all in
all each supporting one VLAN. This VLAN would be assigned with a specific DHCP pool that is
based on the VLSM subnetting in Table 1.1. First, the VPCS will be assigned to nodes as
summarized in the VLAN Membership Summary above. The VPCS are going to be assigned by
virtue of the network switch configuration by right clicking the network switch and assigning the
respective VLANs to the nodes. This would effectively make the node a member of that VLAN.
Also, the node must be set to “access” not “dot1q” even though dot1q is the one supporting
VLAN. This is because dot1q cannot be read by end nodes, only by the middle nodes like the
routers - and in lieu of that the node connecting to the router would be a member of VLAN1 (as
per the note in Table 1.1) as well as set to “dot1q” to allow VLAN trunking. VLAN trunking is
essential for InterVLAN routing that will be explained in the last section. A cloud will be
implemented connected to the switch effectively making the router a “stick-router”, a router that
acts as a gateway but only has one connection. The cloud will be connected to the bridged
connection of the VM and is therefore the external connection of the GNS3 to the external
router. When the bridged connection does not work, a UDP tunnel can be configured in the
cloud effectively making a UDP tunnel that can be used as an alternative if bridged networking
would not work. The final per-subnet topology is found in Figure 2.1.

6
 Figure 2.1. A sample subnet topology with cloud implementation

B. DHCP Assignment
DHCP assignment to the 5 VLANs is designated by each router that acts as a DHCP
server in each GNS3 per assigned VM which only assigns DHCP IP assignments to their
respective VLANs as shown in Table 1.2. The router must be configured by opening the console
of the Cisco3640 router and adding the necessary and essential DHCP Pool for the VLAN
assigned for the router by going in global configuration mode and enabling the dhcp by entering
“service dhcp” and assigning the dhcp addresses that it will serve by typing “ip dhcp pool <IP
addresses of the network covered with its respective subnet mask>” and configuring the default
router of the network by entering “default-router <router IP inside the network>”. VLSM was
used to determine the correct subnet masks and the number of hosts for each VLAN network
based from the assigned number of hosts that are assigned as shown in Table 1.1.
After configuring all of the routers by enabling DHCP and configuring the right DHCP
pool network that it covers, the next step is to check if the VPCS and the Host PC in each GNS3
instance from the three different laptops can be assigned an automatic IP address that is based
on their VLAN network. The success of this step depends on the right configuration of the
routers and the connectivity between the three different laptops that uses “Bridged Connection”
or UDP port tunneling to enable communication and allow the routers to communicate to the
VPCS and Host PCs outside their GNS3 to other GNS3 instances and give them an IP address
by typing “dhcp” in the console of the VPCS while the Host PCs are automatically assigned an
IP address since it automatically requests an IP address if DHCP is readily available.
After assigning IP addresses to the VPCS, pinging the VPCS with other VPCS with the
same respective VLANs can be used to check if the network is correct and connected up to this
point.

7
 The DHCP configuration per-router is done by inputting a series of codes that would tell
the router what to do. The following codes are used:
**VLAN Database Introduction**
R1#vlan database Enter VLAN database mode

R1(vlan)#vlan 60 Introduce VLAN 60

R1(vlan)#apply Saves VLAN60 to the database

R1(vlan)#exit Exits VLAN database mode

**VLAN Interfacing**
R1#conf t Enter global configuration mode

R1(config)#int vlan0060 Specify that vlan0060 is the

interface to be modified

R1(config-if)#ip addr <VLAN IP Address> Assign an IP address to the VLAN

<Mask> 60

R1(config-if)#no shutdown Assures that the setting will hold

R1(config-if)#exit Exits interface mode

R1(config)#exit Exits global configuration mode

**Port Interface**
R1#conf t Enter global configuration mode

R1(config)#int f0/0 Specify that interface f0/0 is to

be modified

R1(config-if)#switchport trun encap Modify to have dot1q protocol

dot1

R1(config-if)#switchport mode trunk Enable trunk mode

R1(config-if)#no shutdown Assures that the setting will hold

R1(config-if)#exit Exits interface mode

R1(config)#exit Exits global configuration mode

**DHCP Pool Allocation**

R1#conf t Enters global configuration mode

R1(config)#service dhcp Enable DHCP configuration mode

8
 R1(config)#ip dhcp pool vlan0060 Specify which interface the dhcp
pool will be assigned

R1(dhcp-config)#network <Network Specify the network address of the

Address> /<Mask> DHCP pool

R1(dhcp-config)#default-router <VLAN IP Specify the address of the

Address> interface at which it will be
assigned. In this case, this is the
IP Address of the VLAN.

R1(dhcp-config)#exit Exits DHCP configuration mode

R1(config)#exit Exits global configuration mode

C. InterVLAN Routing
VLANs normally don’t allow other networks with different VLANs to connect with each
other. To alleviate this problem and allow every node to ping with each other, configuring all the
Cisco3600 router in each GNS3 instance to allow RIPv2 in the assigned supernetwork
“10.0.0.0” and the assigned network by the router for example “192.168.0.0” but it depends on
the assignment of the external router that the group is going to use to allow networking between
the three laptops as assigned earlier in the clouds in the configuration of DHCP assignments.
RIPv2 must be used and not RIP only because the latter does not support interVLAN sharing of
routing tables.

RIPv2 can be configured using the series of codes below:

**RIPv2 Router Configuration**

R1#conf t Enter global configuration mode

R1(config)#router rip Enter RIP routing configuration

R1(config-router)#version 2 Specify version (Version 2 supports

InterVLAN connection)

R1(config-router)#network 10.0.0.0 Specify first network in router’s

routing table to be passed. This is
the network of all subnets.

R1(config-router)#network 192.168.1.0 Specify second network in router’s

routing table to be passed. This is
the network of the physical router
used.

R1(config-router)#exit Exits RIP routing configuration

R1(config)#exit Exits global configuration mode

9
 After configuring the routers in each GNS3 instance in the network, the RIPv2
functionality may be checked by typing “show ip route” in the console of the Cisco3600 router
and a list showing the connected routers with ‘R’ as indication that the RIPv2 is working properly
and is sharing the routing tables with the other Cisco routers in the network. Figure 2.2. shows
an example of what the console must display when RIPv2 is working as intended.

Figure 2.2. Console output of RIPv2 Routing between two GNS3 instances in different VMs.

With InterVLAN networking being already allowed and functional, ncat server tunnels
can now be done between Host PCs and port connections may be established which in turn
would enable the usage of telnet between the two connected Host PCs in different VLANs and
GNS3 instances.

IV. Data and Results

A. Carl Regino’s Results

10
 SW4 Configuration SW3 Configuration
Table 3.1. DHCP Allocation Status
Name Assigned IP Address Membership Conforme with VLAN Subnet?

XPVM-B 10.3.24.34 VLAN60 YES

XPVM-C 10.3.24.2 VLAN58 YES

VPCS4b 10.3.24.35 VLAN60 YES

VPCS3d 10.3.24.3 VLAN58 YES

Figure 3.1. XPVM-B DHCP Allocation

Figure 3.2. XPVM-C DHCP Allocation

Figure 3.3. VPCS4b DHCP Allocation

Figure 3.4. VPCS3d DHCP Allocation

11
 Table 3.2. Ping Status Table
From To Status

XPVM-B XPVM-C SUCCESS

VPCS3d SUCCESS

VPCS4b SUCCESS

XPVM-C XPVM-B SUCCESS

VPCS3d SUCCESS

VPCS4b SUCCESS

VPCS3d XPVM-B SUCCESS

XPVM-C SUCCESS

VPCS4b SUCCESS

VPCS4b XPVM-B SUCCESS

XPVM-C SUCCESS

VPCS3d SUCCESS

Figure 3.5. XPVM-B to XPVM-C Ping Results

Figure 3.6. XPVM-B to VPCS3d Ping Results

12
Figure 3.7. XPVM-B to VPCS4b Ping Results

Figure 3.8. XPVM-C to XPVM-C Ping Results

Figure 3.9. XPVM-C to VPCS3d Ping Results

Figure 3.10. XPVM-C to VPCS4b Ping Results

Figure 3.11. VPCS3d to XPVM-B Ping Results

13
 Figure 3.12. VPCS3d to XPVM-C Ping Results

Figure 3.13. VPCS3d to VPCS4d Ping Results

Figure 3.14. VPCS4b to XPVM-B Ping Results

Figure 3.15. VPCS4b to XPVM-C Ping Results

Figure 3.16. VPCS4b to VPCS3d Results

**Wireshark Capture Files are also provided attached to this report**

14
Figure 3.17. NCAT Session screenshot using UDP pipe (XPVM-B [L] is listening to XPVM-C [R])

B. Ivan Kang’s Results

Figure 3.18 - switch 5 configuration

Figure 3.19 - sho run results showing the router configurations

Figure 3.20 - VPCS5d DHCP Allocation

15
 Figure 3,21 - wireshark capture of the dhcp command

Figure 3.22- dhcp discover packet frame

Figure 3.23 - dhcp offer packet frame

V. Conclusion/Summary
For this paper, testing is done individually. Mr. Regino and Mr. Chan tested with two
VMs and Mr. Kang with a single VM on their respective laptops. Due to the unavailability of Mr.
Chan because of a premeditated holy week family affair, the group is unable to physically test
the network using the external connection connecting the three laptops. The group explored the

16
possibility of using Hamachi but GNS3 does not recognize it as a physical connection so remote
connection over the Internet is not possible. The group decided that it will show that the network
is capable of having interVM DHCP assignment as well as interVLAN network connection. The
group also has successfully executed an ncat session, although using a UDP connection - not
TCP.
In testing for the DHCP, it is seen that for it to work the code in the Methodology section
must be executed. This would allow DHCP allocation for the VPCS/XPVMs as long as it is on
the same VLAN that the router can allocate. Since ncat requires XPVMs to connection with
each other and XPVMs are expected to be on different VLANs, InterVLAN networking must be
used to establish connection between them. This is done using RIPv2 and is configured as
detailed in the methodology. Successful NCAT session is established as seen in Figure 3.17.
However, the NCAT session is only possible using a UDT pipe so the group is unable to
establish a TCP connection hence not have a TELNET session established. The server NCAT
(the one that listens) shuts down when set-up using TCP but is stable when set-up using UDP.
The group is able to show in this paper that InterVLAN connectivity and DHCP
assignment is possible. The connection between the five physical laptops using the external
router will be shown during the project presentation.

17