The experiments are described in chronological order, starting with very elementary ones.
Your understanding of each experiment may rely on your having completed the previous one,
so if the explanation is not clear, check back to the previous experiment to get a starting point.
The VyOS router will be used in the first three experiments of Addressing, Routing, and Forwarding,
and also in the next section of ARIEL on SDN experiments.
It is more complex than the other router we will also download and use – Quagga –
but having set up VyOS for these experiments it will be ready to use for learning about SDN.
About VyOS (usually pronounced ‘VEE-oss’, but could also be ‘VIE-oss’).
https://en.wikipedia.org/wiki/VyOS:
VyOS is an open source network operating system based on Debian GNU/Linux.
VyOS provides a free routing platform that competes directly with other commercially available solutions from well known network providers.
Because VyOS is run on standard amd64 and i586 systems, it is able to be used as a router and firewall platform for cloud deployments.
After Brocade Communications stopped development of the Vyatta Core Edition of the Vyatta Routing software,
a small group of enthusiasts took the last Community Edition, and worked on building an Open Source fork to live on in place of the end of life VC.
https://wiki.vyos.net/wiki/User_Guide:
VyOS is a Linux-based network operating system that provides software-based network routing, firewall, and VPN functionality.
https://vyos.io/:
VyOS is an open source network operating system that can be installed on physical hardware or a virtual machine on your own server, or a cloud platform.
It is based on GNU/Linux and joins multiple applications such as Quagga, ISC DHCPD, OpenVPN, StrongS/WAN and others under a single management interface.
First, you should download and install VyOS, following direction available on the web at the GNS3 Marketplace.
VyOS runs on the Qemu emulator within GNS3.
IMPORTANT: after starting up VyOS from the iso file, you should login with the default userid and password (vyos / vyos) then enter the command: install system
Follow the default choices in the VyOS Wiki User Guide,
and decide on a password to use as administrator (“admin” is easy to remember).
Then, after the system is installed, enter the command: reboot
After VyOS has rebooted, login again, but this time use your administrator password that you set up during the install process.
Save your project with a suitable name. You will not need to install VyOS again – you can just open up your saved project.
Open your saved project including the VyOS router, then click and drag NAT into the workspace, and connect eth0 of VyOS to nat0 of NAT.
Then start the emulation and create a console. Wait for VyOS to boot, then login using your administrator password that you set when you installed VyOS.
VyOS has two modes: operational and configuration.
In operational mode you will see the prompt: vyos@vyos:~$.
Enter the command: show interfaces
You should see: Codes: S – State, L – Link, u – Up, D – Down, A – Admin Down
Interface
IP Address
S/L
Description
---------
-----------
---
-----------
eth0
-
u/u
eth1
-
u/u
eth2
-
u/u
eth3
127.0.0.1/8
u/u
::1/128
Then switch to configuration mode by entering the command: conf(TAB) since the TAB key causes VyOS to auto-complete your entry – a very useful feature!
The primary function of a router is to connect between the LAN and the WAN,
so our first configuration task will be to configure VyOS interface eth0 as a WAN port, and eth1 as a LAN port.
Enter the following commands (to save on typing you can use tab to auto-complete, or you can just copy and paste the commands below) at the prompt: vyos@vyos#.
I recommend executing just one command at a time. set interfaces ethernet eth0 address dhcp
set interfaces ethernet eth0 description WAN
set interfaces ethernet eth1 address 192.168.0.1/24
set interfaces ethernet eth1 description LAN
commit
save
run show interfaces
Note that the changes do not have any effect until the final “commit” command. Then the command “save”
stores that configuration in your GNS3 project. Observe from the last line above that you can
execute operational commands in configuration mode by preceding
them with the “run” command.
Alternatively, exit configuration mode, then show interfaces: exit show interfaces
Now you should see: Codes: S – State, L – Link, u – Up, D – Down, A – Admin Down
Interface
IP Address
S/L
Description
---------
-----------
---
-----------
eth0
192.168.122.78/24
u/u
WAN
eth1
192.168.0.1/24
u/u
LAN
eth2
-
A/D
eth3
127.0.0.1/8
u/u
::1/128
Interface eth0 has an address that was allocated by DHCP or Dynamic Host Control Protocol
(don’t be concerned about the details just yet, DHCP is the subject of the
next experiment), whilst eth1 has a static IPv4 address.
Discussion:
Would you agree considerable effort is needed to set up this emulation – starting with the initial installation of GNS3?
Several of the following “experiments” will be treated more as “demonstrations”,
because the main learning objective is focused on the principles of operation of the Internet,
rather than mastery of specific software.
Looking at the configuration, it appears that every appliance can reach every other appliance, and the Internet.
However, it is not possible to ping from, for example, VPCS-1 to VPCS-2. Why not – what is needed?
If the local network had hundreds of interfaces rather than just a handful,
would a lot of work be needed to fully configure it manually?
Explore the setup and configuration of the network to allow pings within the network and to the Internet.
No need to configure every interface, only the ones you need. Can you ping from the Internet back into the local network?
If not, why not.
If time permits, set up packet capture and explore the packet flows in the network.
In an IPv4 environment, Dynamic Host Configuration Protocol (DHCP) is used for configuring hosts when they are connected to a network.
The DHCP server allocates the client host its own IP address, on a temporary basis or “lease", and also sets up other parameters,
such as the address for the default gateway router, which is handy for accessing the rest of the world.
With IPv6, things are slightly different (patience, please). See https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol
Open your saved project containing the VyOS router, and
enter the following commands to enable its inbuilt DHCP server: set service dhcp-server disabled 'false'
set service dhcp-server shared-network-name LAN subnet 192.168.0.0/24 default-router '192.168.0.1'
set service dhcp-server shared-network-name LAN subnet 192.168.0.0/24 dns-server '192.168.0.1'
set service dhcp-server shared-network-name LAN subnet 192.168.0.0/24 domain-name 'internal-network'
set service dhcp-server shared-network-name LAN subnet 192.168.0.0/24 lease '86400'
set service dhcp-server shared-network-name LAN subnet 192.168.0.0/24 start 192.168.0.9 stop '192.168.0.254'
commit
save
Now spin up a few PCs, connect them all to the VyOS box, and configure them all with the command: ip dhcp
Check their IP addresses, and ping between them.
Discussion:
Would this be a much easier way to configure IP addresses for a large number of network interfaces?
Historically, what made it very desirable to use DHCP, and where in particular was it extremely useful (hint: recall dial-up Internet access)?
Why would anyone want a “static” IP address instead of a dynamically allocated one?
The time has come to explore the difference between private and public IPv4 addresses.
IPv4 addresses have just about run out.
It was clear for more than a decade that there would not be enough to go around.
One response was to allocate them much more flexibly using Classless Inter-Domain Routing (Google “CIDR”),
and another was re-use of the pool of available addresses.
Two technologies that achieve re-use of addresses are DHCP and NAT (Network Address Translation).
To understand how NAT works, we need to discuss the other, non-physical, type of “port”.
Layer 3 – using IP addressing and routing – allows for global communication between
network interfaces (recall the discussion about why Ethernet addresses are
not up to that task).
However, interface-to-interface communication would result in all the packets
intended for a host just being dumped at its network interface.
Layer 4 – the Transport Layer – adds another
level of addressing so that traffic flows from an application on one host
to an application on another host can be achieved. The additional address is a 16-bit port number.
Some port numbers are well-known, meaning they should be
used typically by servers offering a well-known service. Other port numbers are allocated dynamically
– a bit like the number you might pick from a roll of numbers at the delicatessen. The value of the dynamic
(or “ephemeral”) port number has no significance except for the time you are using it).
With 16 bits it is possible to count up to . . . . . . . . . . ,
which would seem to be a lot, compared with the number of separate traffic
flows you might need at any one time. This opens up an opportunity to use port numbers as address
extensions,
to help the finite pool of IPv4 addresses go further.
Within a LAN, it is possible to use a set of IP addresses
that will never be used for routing through the global Internet. These are called “local addresses”. They can be used in LANS around the world
without any confusion, because they are never taken outside the LAN.
Several address ranges are reserved for this
type of re-use in LANs:
10.0.0.0/8
192.168.0.0/16, and
(less commonly used) 172.16.0.0/12
The NAT server presents one (or perhaps a small number of)
public IP addresses to the rest of the world, on behalf of its Local Area
Network. Whenever a host in the LAN
wants to communicate with a host outside the LAN, it can use its own
private IP
address, and its own choice of port number. However, when the packet gets to the NAT it will translate the
local IP
address to its own public IP address, and assign some suitable port
number. The NAT server then
maintains a
table that allows it to translate back and forth between the private
IP/port
number and the public IP/port number.
Technically, the form of “NAT” described above is
defined as “Port Address Translation with Network Address Overloading” – sometimes just
called “PAT”. There are other forms of
NAT, which you may be interested in researching, but this is the most
common one.
There are two popular Transport layer protocols: TCP, and UDP. In principle, adding a
16-bit port number would allow a theoretical maximum of about 128 thousand identifiable
traffic flows – a fairly large number for most use cases, but still
finite. The NAT server therefore re-uses
port numbers that were allocated previously, and are no longer being used.
NAT is said to provide some security by concealing the
structure of the LAN from the outside world. In practice, a Firewall function is often bundled with a NAT
function,
though the two are separate functions.
Some users may need to advertise a unique static IP
address
to the outside world (for IPSec, for example). They need to bypass the NAT function, and possibly the Firewall
function
– a process described as “punching a hole” through those functions. For example, Google the term: “STUN”.
With the introduction of IPv6, with 128-bit addressing,
there are ample addresses available to allocate unique addresses to every
host
in the Milky Way Galaxy – in fact, many addresses each. This will be discussed later under “IPv6”.
NAT needs to be enabled on VyOS by entering the
commands
(see My Lab Environment v2.0, Part 2 – Router & Firewall at https://thomasvochten.com/archive/2015/03/labv2-part2/ ): set nat source rule 10 outbound-interface eth0
set nat source rule 10 source address 10.0.0.0/24
set nat source rule 10 translation address masquerade
set nat source rule 11 outbound-interface eth0
set nat source rule 11 source address 10.0.1.0/24
set nat source rule 11 translation address masquerade
Assuming you have already enabled DHCP, using a suitable
private address number range, you are now good to go. Drag and drop a NAT cloud into the workspace
and connect it to the VyOS router. Configure a static IP address for the router. Since VyOS connects to the rest of the world
through GNS3 NAT, its static address will in this experiment be a private
IP address, where in the real world it would normally be a public IP address.
Now ping between your virtual PCs and the outside world, in both directions.
Using a packet capture on the link between VyOS and NAT, and also on a link from a PC to NAT, you should be able to see NAT at work.
Discussion:
Do you feel safer knowing your LAN is hidden behind a NAT function as well as a Firewall?
Research what might happen with NAT after IPv6 becomes the dominant addressing scheme.
The Internet Protocol Suite began as a means of linking
supercomputers at elite research centres in the USA. While the Ethernet had already chosen 48 bits
for its address space – allowing many thousands per person on the planet –
the
Internet community settled on 32 bits. No-one would forecast more than four billion super-computing
centres,
after all. However, the
Internet went
commercial, Internet Service Providers started offering home Internet
access
(initially using dial-up modems), and shortly after that the world wide
web, and
search engines, were developed. Because
the
world wide web runs on the Internet, that network became the dominant
global network.
Once the Internet became a global network for everyone,
it
became clear that the 32-bit address range would run out sooner or later.
Had the Internet community back in the 1980’s settled
on 48
bits – as Ethernet had already done – IPv4 addresses would not yet be
close to
running out, and there probably would be no IPv6. Instead of opting for 48 bits, or the
equivalent of 15 decimal digits like E. 164 – the ITU numbering plan – or
even
64 bits, which would have multiplied the size of the IPv4 address pool by
4
billion, the Internet community opted for 128 bits.
Just consider hypothetically what would happen if every one of the possible 2128 addresses
were allocated to one physical device each.
Suppose each device had a mass of just one milligram – about the mass of a 4 mm square of 85 gsm paper.
Multiplying 1 mg by 2128 results in a mass of about 3.4 x1032 kg –
approximately 57 million times the mass of planet Earth.
Clearly there is no use-case envisaged that would actually require any significant percentage of 2128 addresses.
As another hypothetical example, if 10 billion addresses were allocated for every person on the planet
(assume 10 billion people, EACH ONE of whom has their own allocation of 10 billion addresses)
that would amount to about 0.000,000,000,000,000,03% of the total theoretically available address pool of 2128.
The IP protocol was designed to be flexible and robust.
Its range of possible use cases was not limited by any specific set of guidelines.
Originally it ran on infrastructure that was unreliable (largely because of being borrowed).
Considering all these factors,
IP was designed to operate in a “best-effort” network that was able to recover fromall manner of failures and outages,
from bit-errors to the loss of a major server or transmission line.
It was originally run by and for enthusiastic amateurs.
The Internet was more of a commodity than a highly differentiated commercial product.
For anyone who was expecting that IPv6 would fulfil the IETF Charter for next-generation Internet Protocol, IPv6 is a disappointment.
That is partly because the Charter was too ambitious, and partly because IPv6 does not really introduce many new benefits for users,
apart from solving the address run-out problem.