Implement the topology with fully functional routers (i.e.

network connecting the two

VyOS routers).
The network topology components are the configured within an interface environment
with the virtual software is mapped to the respective physical interface via ethernet bridges
that form a link between a virtual network environment interface and the physical
counterpart.
A custom link topology with a routing protocol has a one routing table with one entry
for “the best route” to all destinations in a network domain (or several of the best routes for
load balancing purposes). The best route is calculated based on the chosen metric, e.g.,
shortest path first (SPF) or lowest cost, where the cost parameter can be established based on
any set of link parameters.
Wireless Routers in Parallel – This setup gets a little more complicated, but it is
basically two copies of the flat network setup. It involves a separate wireless router for both
the home network and guest network. Each router has the default NAT, DHCP, and firewall
configuration that would come with your typical consumer wireless router. The two networks
are then allowed out to the internet through a third router device. It doesn’t matter if this is
wireless or not since you wouldn’t be using the wireless capability in this scenario. The
networks are segmented because, from the point of view of each of the wireless routers,
anything on the other side (your third router) is treated just like internet traffic. There are a
whole bunch of ways you can tweak this setup and it can start to get more complicated. I
won’t go into any more details, but my point is you could take some basic gear you find at
rummage sales or have laying around, plug it in, and with very little configuration it will just
work.
One other exciting aspect of Vyatta is that it can run in a Virtual Machine
environment with VMware or XenSource. This means that complex network topology can be
modeled in a fully simulated environment to optimize the design and test phases of
networking.  I've already been testing Vyatta in VMware and will probably be testing in XEN
as well in the near future. Since proprietary routers won't run in a virtualized world, it gives
Vyatta a unique advantage to spread its market share.  If Vyatta succeeds, it will help bring
new competition and innovation in to the proprietary world of networking.
Routing Implementation
We have implemented the Multi-Topology support for OSPFv3 and OSPFv2, as well as
“MANET OSPFv3 MANET Designated R
outers (MDR)” into the Vyatta 6.3 (Napa version) [27] Linux distribution. This is based on
 the Quagga [28] open source routing application running on a Debian system with Linux
kernel 2.6.37 (ATOW). The MANET OSPFv3 base protocol was fetched from [29]. The
router implementation allows easy configuration of OSPFv2-MT and OSPFv3-MT
information. Metrics can be set up for each topology on each interface. The Linux platform is
set up to utilize multiple forwarding tables and Quagga's interface towards forwarding tables
in Linux has been adjusted to allow the use of multiple routing tables.
In addition to OSPFv2-MT and OSPFv3-MT routing, the implementation also
supports configuration of static MT-routes. A flexible import and redistribution of routes
from other routing protocols via the main routing table is supported, as well as customized
export of MT-routes to the main routing table to make the routes available for redistribution
in other routing protocols. Due to experienced instabilities in the MANET OSPFv3-MT
protocol (RFC 5614), OSPFv3MT was used in the CoNSIS field experiment.
It should also be noted that the expanded encoding of the OSPF Options described in the draft
[3] is in conflict with bits allocated by OSPF Link-Local Signaling [30]. Link-Local
Signaling is also part of the MANET OSPFv3 implementation.

Routing Process
• IPtables [32] was used to make rules to associate a label (mark) with a packet. One label also
exists for each topology forwarding table. To bind these two operations, the label associated
with a specific traffic class must be the label of the topology table that should be used for that
traffic class. Linux only allows packets with a matching label to do lookup in a routing table
that has an assigned label. All packets can do lookup in tables without labels assigned (Catch-
all).
• The main routing table was given very low priority (a high number). The other routing tables
were given higher priority. The mutual order of the higher priority tables was not important.
• A default black hole entry was configured in each routing table to block traffic to destinations
that did not have a routing entry in the routing table. A black hole route is a routing table
entry that goes nowhere. This entry captured traffic that could not be routed via the other
entries in the routing table and dropped this traffic. This enforced that only one forwarding
table (the one with the correct label) was used to look for routes to the destination for a
packet.
Transfer of Packets
The IP address of the recipient, which is a part of the packet header, determines how
the packet is routed. If this address includes the network number of the local network, the
 packet goes directly to the host with that IP address. If the network number is not the local
network, the packet goes to the router on the local network.
The routers maintain routing information in routing tables. These tables contain the IP
address of the hosts and routers on the networks to which the router is connected. The tables
also contain pointers to these networks. When a router receives a packet, the router checks its
routing table to determine if the table lists the destination address in the header. If the table
does not contain the destination address, the router forwards the packet to another router that
is listed in its routing table.

Figure 1: Network Topology & Transfer of Packets

Router R1 connects networks 192.9.200 and 192.9.201. Router R2 connects
networks 192.9.201 and 192.9.202.
If Host A on network 192.9.200 sends a message to Host B on network 192.9.202, the
following events occur:
1. Host A sends a packet out over network 192.9.200. The packet header contains the
IPv4 address of the recipient Host B, 192.9.202.10.
2. None of the machines on network 192.9.200 has the IPv4 address 192.9.202.10.
Therefore, Router R1 accepts the packet.
3. Router R1 examines its routing tables. No machine on network 192.9.201 has the
address 192.9.202.10. However, the routing tables do list Router R2.
4. R1 then selects R2 as the “next hop” Router. R1 sends the packet to R2.
5. Because R2 connects network 192.9.201 to 192.9.202, R2 has routing information for
Host B. Router R2 then forwards the packet to network 192.9.202, where Host B accepts the
packet.
We then configured some multiple routing protocols in a single access server to connect
networks that use different routing protocols. You can, for example, run RIP on one
subnetted network, IGRP on another subnetted network, and exchange routing information
between them in a controlled fashion. The available routing protocols were not designed to
interoperate with one another, so each protocol collects different types of information and
reacts to topology changes in its own way. For instance, the RIP in question uses a hop-count
metric and IGRP uses a five-element vector of metric information. In the case where routing
information is being exchanged between different networks that use different routing
protocols, there are many configuration options that allow you to filter the exchange of
routing information.
Our access servers can handle simultaneous operation of up to 30 dynamic IP routing
processes. The combination of routing processes on an access server can consist of the
following protocols (with the limits noted).
The router global configuration command starts an IP Enhanced IGRP routing
process. The network router configuration command specifies that network 192.168.0.0 (the
regional network) is to send and receive IP Enhanced IGRP routing information.
The redistribute router configuration command specifies that RIP-derived routing information
be advertised in the routing updates. The default-metric router configuration command
assigns an IP Enhanced IGRP metric to all RIP-derived routes. The distribute-list router
configuration command instructs the router to use access list 10 (not defined in this example)
to limit the entries in each outgoing update. The access list prevents unauthorized advertising
of university routes to the regional network.

Configuration, testing, and demonstration of the VPN Operation

The figure below shows the physical elements of the scenario. The Internet provides
the core interconnecting fabric between the headquarters and remote office routers. Both the
headquarters and remote office are using a Cisco IOS VPN gateway (a Cisco 7200 series with
an Integrated Service Adaptor (ISA)
 Configuration of the Tunnel VPN Operation
Tunnelling provides a way to encapsulate packets inside of a transport protocol.
Tunneling is implemented as a virtual interface to provide a simple interface for
configuration. The tunnel interface is not tied to specific "passenger" or "transport" protocols,
but rather, it is an architecture that is designed to provide the services necessary to implement
any standard point-to-point encapsulation scheme. Because tunnels are point-to-point links,
you must configure a separate tunnel for each link.
Tunneling has the following three primary components:
• Passenger protocol, which is the protocol you are encapsulating (AppleTalk, Banyan
VINES, Connectionless Network Service [CLNS], DECnet, IP, or Internetwork Packet
Exchange [IPX]).
• Carrier protocol, such as the generic routing encapsulation (GRE) protocol or IPSec
protocol.
• Transport protocol, such as IP, which is the protocol used to carry the encapsulated
protocol.
Configuration and Testing
 Demonstration of the Operation

1. Using a VPN connection helps protect confidential network data and resources.
2. Provides convenience and accessibility for remote workers or corporate employees
since they will be able to easily access the main office without having to be physically
present and yet, still maintain the security of the private network and its resources.
3. Communication using a VPN connection provides a higher level of security compared
to other methods of remote communication. Advanced level of technology nowadays makes
this possible, thus, protecting the private network from unauthorized access.
4. Actual geographic locations of the users are protected and not exposed to the public or
shared networks like the Internet.
5. Adding new users or group of users to the network is easy since VPNs are very
adjustable. It is possible to make the network grow without the need for additional new
components or complicated configurations.

Captured Traffic
In client version of the above-mentioned VPN service, it was observed that once
enabled, the service uses standard port 443 for HTTPS connections but generally connects to
only one server. All the traffic may it be multisite traffic uses the same active connection.
Figure 1 shows the connection details for current user activity against Hotspot Shield.
Hotspot Shield uses fake well-known server name in SSL certificate to bypass the traffic
from server name-based filters over the network, if any, as shown in Figure 2 below.

Figure 2: Wireshark: Hotspot Shield client.

 Figure 3: Wireshark: Hotspot Shield TCP stream
The server does not generate any DNS entry for such server name. The NetworkMiner
tool shows us the connection details in Figure 3. We can see that eight unique connections
were made; in this case, it generally means eight unique web pages were open. Requests of
all these web pages were managed by the server whose IP is 136.0.99.219. Certificate details
can also be seen against this server IP which were received. Total 20,708 packets were sent in
this activity, and 116,84 packets were received.

Figure 4: Hotspot Shield connection details.

 Figure 5: no DNS information found for 136.0.99.219.

Figure 6: Hotspot Shield add-on.

The figure above shows that no DNS activity for such host name was found during the
communication. We can see all the DNS generated by the user while using Hotspot Shield
client.
Traffic Generation
Across multiple systems inside the network, multiple clients of the abovementioned
VPN services were installed and configured. These clients were enabled, and network activity
was generated by surfing the Internet. The activity was monitored by VPN detector, and
alerts were generated once the VPN activity was detected.
Traffic Classification Alert. The alerts generated above for different VPN services were of
different types depending upon the activities performed by the users. The generated alerts by
five of these users are shown in Table 3. The alerts shown in Table 3 show the traffic
classification of each type of VPN service used with respect to its unique characteristics as
discussed in Table 2. Mostly, VPNs may be classified with the help of DNS activity which
enable the user to access such services. The results shown in Table 3 show that the system
classified 400 out of 729 active connections as potential VPN connections. Once the system
is deployed, any new connection activity in the network is monitored. Each system connected
to Internet manages its on DNS cache to reuse.
Demonstration:
 VYoS Configuration
Now it is time for restoring the VyOS configuration file on a newly deployed VyOS
appliance.
Preparation:
1. Deploy a new VyOS appliance and make sure that the virtual networks are connected
to the correct adapter.
2. Verify and/or change the MAC addresses were needed. The MAC addresses should
align between the configuration file and the new virtual appliance:
 Option 01: Change the virtual network card MAC address to the ones that
were used on the old appliance.
 Option 02: Change the MAC addresses in the configuration file that is used
for the restore. The MAC address should align with the newly deployed VyOS appliance.
3. Create an ISO file with your latest configuration on it. I used the following
opensource tooling as displayed below. Link to IsoCreator.

Creating an ISO file with

VyOS Configuration
Procedure:
1. Open your vSphere Infrastructure and navigate to the Virtual Machine. This would be
in my case “LAB-FW01“.
2. Assign the newly created ISO file to the Virtual Machine. You connect the ISO file to
the CD-ROM drive.
3. Power-on the Virtual Machine.
4. Make sure you select in the GRUB bootloader the following mode to startup from:
“VyOS 1.1.8 linux (USB console)”.
5. When VyOS is booted, log in with the following default credentials:
 Username: vyos
 Password: vyos
 You are now logged in into the Linux Shell.
6. Now it’s time to mount the connected CD-ROM media:
 sudo mount /dev/cdrom /mnt
7. To make sure my configuration is available. I list the directory content with the
following command:
 ls -l /mnt
8. Now it is time to copy my old configuration to the startup configuration location of
VyOS. Use the following command to perform this action (keep in mind: My configuration is
called “2018-06-05-vyos.config.boot”): 
 cp /mnt/2018-06-05-vyos.config.boot /config/config.boot
9. To verify the copy action, I run the following command to display my hostname that
is  listed in the configuration file:
 cat /config/config.boot | grep LAB-FW01
10. Now it is time to reboot the VyOS appliance. At the next boot, the old configuration
will be loaded and everything should be restored. The following commands are required for
rebooting VyOS:
 reboot
 yes
11. After the reboot is completed you should log in with your old credentials that belong
to the restored configuration.
12. To verify that the configuration is loaded correctly I run the following command to
display all my interfaces and sub-interfaces:
 show interfaces
13. From this point, everything should be working.

Illustrates, a data center deploying VMware SDDC is independent from the

previously acquired hardware. This frees data center architects to use solutions from multiple
vendors simultaneously. In such scenario, the data center infrastructure becomes a
geographically agnostic shared pool of resources that can be sliced up automatically.
VMware SDDC also drastically reduces the number of operation tasks as each virtualization
platform - vSphere, NSX, and vSAN - entirely abstracts the number of distinct servers,
network, and storage solutions. Such a situation brings agility and flexibility to a data center
infrastructure, facilitating automation, management, monitoring, governance, and business
insight. This is especially evident when these functions are provided by the vRealize Suite,
which is fully integrated with all three VMware virtualization platforms.
 As an important outcome for organizations going through a digital transformation,
VMware SDDC shifts personnel resources toward innovations and business growth while
helping data center architects deliver secure, elastic and resilient infrastructure services. To
effectively support the SDDC objectives, NSX enables the creation of networks that are
entirely decoupled from physical devices and can fully service modern applications. NSX
provides network virtualization, which can be succinctly defined as the creation of complete
virtual networks that are entirely autonomous from the data center physical infrastructure.
As Figure 2-6 clarifies, VXLAN encapsulates Ethernet frames inside UDP datagrams,
which in theory require IP routing to be delivered between VXLAN Tunnel End Points
(VTEPs). In the case of Figures 2-4 and 2-5, Host1 and Host2 are software VTEPs that use
their VMkernel addresses - IP1 and IP2, respectively - to encapsulate and decapsulate
VXLAN packets. A VXLAN control plane establishes how each VTEP discovers the MAC
addresses associated with other VTEPs to correctly forward traffic.
Although RFC 7348 states IP multicast routing as its method of choice for such
discovery process, the network industry has developed innovative control plane techniques
for overlay protocols. Because of its stark simplicity, the vast majority of NSX deployments
use the NSX Controllers to perform control plane functions for overlay protocols.
As these elements gather and distribute information to all VTEPs, only IP unicast routing is
actually required from the underlay network. In addition, NSX can also deploy multicast-
based VXLAN - per logical switch or transport zone - to allow smooth compatibility with
existing network configurations already in place.
In summary, configuring the virtual servers will also take a bit of time. First, check
the default values for the virtual machine to ensure it will suffice for your purposes. You’ll
need to choose what guest operating system you want to run, where the virtual machine’s
files will be stored, and the types of network connection you want to set up for the virtual
machine. In addition, you need to decide whether to allocate all the disk space for the virtual
machine when you create it, or whether you want it to take disk space dynamically as needed.
Essentially, you can configure three types of virtual machine resources when you create the
machine, or after it has been created: hardware it has access to, power management and
operating system options, and resource configuration such as CPU configuration,
hyperthreading, disk settings, and memory.