Add CT353 Network & Data Communications II
|
After Width: | Height: | Size: 78 KiB |
|
After Width: | Height: | Size: 385 KiB |
|
After Width: | Height: | Size: 124 KiB |
|
After Width: | Height: | Size: 87 KiB |
|
After Width: | Height: | Size: 158 KiB |
|
After Width: | Height: | Size: 132 KiB |
|
After Width: | Height: | Size: 86 KiB |
|
After Width: | Height: | Size: 42 KiB |
@ -0,0 +1,167 @@
|
||||
%! TeX program = lualatex
|
||||
\documentclass[a4paper]{article}
|
||||
|
||||
% packages
|
||||
\usepackage{microtype} % Slightly tweak font spacing for aesthetics
|
||||
\usepackage[english]{babel} % Language hyphenation and typographical rules
|
||||
\usepackage[final, colorlinks = false, urlcolor = cyan]{hyperref}
|
||||
\usepackage{changepage} % adjust margins on the fly
|
||||
|
||||
\usepackage{fontspec}
|
||||
\setmainfont{EB Garamond}
|
||||
\setmonofont[Scale=MatchLowercase]{Deja Vu Sans Mono}
|
||||
|
||||
\usepackage{minted}
|
||||
\usepackage{xcolor}
|
||||
|
||||
\usepackage{pgfplots}
|
||||
\pgfplotsset{width=\textwidth,compat=1.9}
|
||||
|
||||
\usepackage{caption}
|
||||
\newenvironment{code}{\captionsetup{type=listing}}{}
|
||||
% \captionsetup[listing]{font=small, skip=0pt}
|
||||
% \setlength{\abovecaptionskip}{0pt}
|
||||
% \setlength{\belowcaptionskip}{5pt}
|
||||
|
||||
\usepackage[yyyymmdd]{datetime}
|
||||
\renewcommand{\dateseparator}{--}
|
||||
|
||||
\usepackage{titlesec}
|
||||
% \titleformat{\section}{\LARGE\bfseries}{}{}{}[\titlerule]
|
||||
% \titleformat{\subsection}{\Large\bfseries}{}{0em}{}
|
||||
% \titlespacing{\subsection}{0em}{-0.7em}{0em}
|
||||
%
|
||||
% \titleformat{\subsubsection}{\large\bfseries}{}{0em}{$\bullet$ }
|
||||
% \titlespacing{\subsubsection}{1em}{-0.7em}{0em}
|
||||
|
||||
% margins
|
||||
\addtolength{\hoffset}{-2.25cm}
|
||||
\addtolength{\textwidth}{4.5cm}
|
||||
\addtolength{\voffset}{-3.25cm}
|
||||
\addtolength{\textheight}{5cm}
|
||||
\setlength{\parskip}{0pt}
|
||||
\setlength{\parindent}{0in}
|
||||
% \setcounter{secnumdepth}{0}
|
||||
|
||||
\begin{document}
|
||||
\hrule \medskip
|
||||
\begin{minipage}{0.295\textwidth}
|
||||
\raggedright
|
||||
\footnotesize
|
||||
Name: Andrew Hayes \\
|
||||
E-mail: \href{mailto://a.hayes18@universityofgalway.ie}{\texttt{a.hayes18@universityofgalway.ie}} \hfill\\
|
||||
ID: 21321503 \hfill
|
||||
\end{minipage}
|
||||
\begin{minipage}{0.4\textwidth}
|
||||
\centering
|
||||
\vspace{0.4em}
|
||||
\Large
|
||||
\textbf{CT3531} \\
|
||||
\end{minipage}
|
||||
\begin{minipage}{0.295\textwidth}
|
||||
\raggedleft
|
||||
\today
|
||||
\end{minipage}
|
||||
\medskip\hrule
|
||||
\begin{center}
|
||||
\normalsize
|
||||
Assignment 01: Expand the VLAN-Based Network
|
||||
\end{center}
|
||||
\hrule
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=0.8\textwidth]{./images/one.png}
|
||||
\caption{Network Topology}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=0.635\textwidth]{./images/router_conf.png}
|
||||
\caption{Router Configuration}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=0.6\textwidth]{./images/switch_conf.png}
|
||||
\caption{Configuration of the New IT101 Switch}
|
||||
\end{figure}
|
||||
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=0.45\textwidth]{./images/five.png}
|
||||
\caption{Verifying that The New VPC Devices in the Accounts VLAN Can Ping Each Other}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=0.5\textwidth]{./images/six.png}
|
||||
\caption{Running a Trace from a VPC to Another VPC in the Same VLAN (Same VPCs as in Above Figure)}
|
||||
\end{figure}
|
||||
|
||||
When we run a trace from Accounts-PC1 to Accounts-PC2 (which are both on VLAN150), we can see that it only takes one hop to get from Accounts-PC1 to Accounts-PC2.
|
||||
Because these devices are in the same VLAN, they do not need to go through the router to address each other, and can reach other directly.
|
||||
When devices share a VLAN, they can communicate directly at the Data Link Layer.
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=0.9\textwidth]{./images/seven.png}
|
||||
\caption{Running a Trace from a VPC to Another VPC in Different VLANs}
|
||||
\end{figure}
|
||||
|
||||
When we run a trace from Accounts-PC1 to Support-PC1 (which are on different VLANs), we can see that it takes two hops to get from Accounts-PC1 to Support-PC1.
|
||||
Communication between separate VLANs requires routing, and therefore communicating between two devices on two different VLANs requires that the packets go through a
|
||||
router.
|
||||
The first IP in the trace is that of the router: \verb|192.168.150.1| (or rather the IP of the gateway of VLAN150 on the router).
|
||||
The second IP in the trace is that of Support-PC1: \verb|192.168.200.254|.
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=\textwidth]{./images/eight.png}
|
||||
\caption{Packet Capture on the Link Connecting the Switch \& the Router During a Ping between VPCs on Different VLANs}
|
||||
\end{figure}
|
||||
|
||||
The general outline of what happened in this packet capture is as follows:
|
||||
\begin{enumerate}
|
||||
\item An ICMP ping is sent from Accounts-PC1 (which is on VLAN150) to Support-PC1 (which is on VLAN200).
|
||||
Ethernet frames that travel between VLANs need a tag that identifies the VLAN as per the 802.1Q protocol.
|
||||
However, the 802.1Q is not added by the VPC sending the ping; instead, the tag is added by the first switch that the frame passes through, in this case
|
||||
the IT101 switch.
|
||||
The IT101 switch will have encapsulated the packet with an 802.1Q header and added the VLAN information, including the priority bits, the VLAN ID of the
|
||||
VLAN to which the packet belongs, \& the Canonical Format Indicator which indicates the canonical format of the MAC address.
|
||||
Therefore, by the time the packet reaches the Switch1-Floor2 switch, the VLAN tag has already been added to the frame.
|
||||
|
||||
\item The Switch1-Floor2 switch then forwards the encapsulated packet which now contains the 802.1Q header to the Office-Router router.
|
||||
This can be seen in the first ICMP packet that we captured going from \verb|192.168.150.254| (Accounts-PC1) to \verb|192.168.200.254| (Support-PC1):
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=0.9\textwidth]{./images/dot1q_tag.png}
|
||||
\caption{ICMP Packet Containing the 802.1Q Tag}
|
||||
\end{figure}
|
||||
|
||||
\item We can tell what links require an 802.1Q header by checking whether they are trunks or access links: trunks expect packets to have an 802.1Q header so
|
||||
that the switches or routers that they are linking can know which VLAN they belong to.
|
||||
Access links do not expect an 802.1Q header, as the ports which access links join are specified to belong to a certain VLAN when the switch is configured.
|
||||
Therefore every packet traversing one of the trunk links, i.e. IT101 {\leftrightarrow} Switch1-Floor2, Switch1-Floor2 {\leftrightarrow} Office-Router,
|
||||
\& Switch1-Floor2 {\leftrightarrow} Switch2-Floor2, requires a 802.1Q header.
|
||||
The last switch (Switch2-Floor2) before the destination VPC (Support-PC1) will remove the 802.1Q header, extracting the original ICMP echo request packet, and send it
|
||||
down the access link to Support-PC1.
|
||||
|
||||
\item The router is needed to facilitate the inter-VLAN communication;
|
||||
although, in purely physical terms, data could be transferred via the switches from Accounts-PC1 to Support-PC1 without having to go to the router, the
|
||||
router is needed to facilitate inter-VLAN communication over IP, as the VLANs have separate broadcast domains and the individual VPCs do not know which
|
||||
VLAN they belong to, if any.
|
||||
The router forwards the packets to the switch Switch1-Floor2, which passes them to Switch2-Floor2.
|
||||
|
||||
\item When the ICMP packets reach Switch2-Floor2, the 802.1Q header is stripped from them, as they have now traversed the last trunk link that they need to
|
||||
and are now going to pass over an access port to Support-PC1.
|
||||
Since we are capturing the packets over the trunk link between a Switch1-Floor2 \& Office-Router, we will never see a packet without an 802.1Q header,
|
||||
although they are in use for this ping.
|
||||
|
||||
\item When the echo request reaches Support-PC1, it send back an echo reply via Switch2-Floor2.
|
||||
The 802.1Q header will be added at Switch2-Floor2, and the process will repeat to route the packet across the trunks to the router, and then to the
|
||||
IT101 switch, where the 802.1Q header will be stripped and the packet forwarded back to Accounts-PC1, completing the ping.
|
||||
\end{enumerate}
|
||||
|
||||
\end{document}
|
||||
|
After Width: | Height: | Size: 78 KiB |
|
After Width: | Height: | Size: 385 KiB |
|
After Width: | Height: | Size: 124 KiB |
|
After Width: | Height: | Size: 87 KiB |
|
After Width: | Height: | Size: 158 KiB |
|
After Width: | Height: | Size: 132 KiB |
|
After Width: | Height: | Size: 86 KiB |
|
After Width: | Height: | Size: 42 KiB |
@ -0,0 +1,2 @@
|
||||
These are all the image files shown in the PDF document found in the directory above this one.
|
||||
They would likely be more easily understood with the context the document provides.
|
||||
|
After Width: | Height: | Size: 74 KiB |
|
After Width: | Height: | Size: 26 KiB |
|
After Width: | Height: | Size: 68 KiB |
|
After Width: | Height: | Size: 88 KiB |
|
After Width: | Height: | Size: 87 KiB |
|
After Width: | Height: | Size: 35 KiB |
|
After Width: | Height: | Size: 66 KiB |
|
After Width: | Height: | Size: 29 KiB |
|
After Width: | Height: | Size: 69 KiB |
|
After Width: | Height: | Size: 34 KiB |
|
After Width: | Height: | Size: 141 KiB |
|
After Width: | Height: | Size: 19 KiB |
|
After Width: | Height: | Size: 20 KiB |
|
After Width: | Height: | Size: 222 KiB |
|
After Width: | Height: | Size: 70 KiB |
|
After Width: | Height: | Size: 19 KiB |
|
After Width: | Height: | Size: 43 KiB |
|
After Width: | Height: | Size: 58 KiB |
|
After Width: | Height: | Size: 25 KiB |
@ -0,0 +1,361 @@
|
||||
%! TeX program = lualatex
|
||||
\documentclass[a4paper]{article}
|
||||
|
||||
% packages
|
||||
\usepackage{microtype} % Slightly tweak font spacing for aesthetics
|
||||
\usepackage[english]{babel} % Language hyphenation and typographical rules
|
||||
\usepackage[final, colorlinks = false, urlcolor = cyan]{hyperref}
|
||||
\usepackage{changepage} % adjust margins on the fly
|
||||
|
||||
\usepackage{fontspec}
|
||||
\setmainfont{EB Garamond}
|
||||
\setmonofont[Scale=MatchLowercase]{Deja Vu Sans Mono}
|
||||
|
||||
\usepackage{minted}
|
||||
\usepackage{xcolor}
|
||||
|
||||
\usepackage{pgfplots}
|
||||
\pgfplotsset{width=\textwidth,compat=1.9}
|
||||
|
||||
\usepackage{caption}
|
||||
\newenvironment{code}{\captionsetup{type=listing}}{}
|
||||
% \captionsetup[listing]{font=small, skip=0pt}
|
||||
% \setlength{\abovecaptionskip}{0pt}
|
||||
% \setlength{\belowcaptionskip}{5pt}
|
||||
|
||||
\usepackage[yyyymmdd]{datetime}
|
||||
\renewcommand{\dateseparator}{--}
|
||||
|
||||
\usepackage{titlesec}
|
||||
% \titleformat{\section}{\LARGE\bfseries}{}{}{}[\titlerule]
|
||||
% \titleformat{\subsection}{\Large\bfseries}{}{0em}{}
|
||||
% \titlespacing{\subsection}{0em}{-0.7em}{0em}
|
||||
%
|
||||
% \titleformat{\subsubsection}{\large\bfseries}{}{0em}{$\bullet$ }
|
||||
% \titlespacing{\subsubsection}{1em}{-0.7em}{0em}
|
||||
|
||||
% margins
|
||||
\addtolength{\hoffset}{-2.25cm}
|
||||
\addtolength{\textwidth}{4.5cm}
|
||||
\addtolength{\voffset}{-3.25cm}
|
||||
\addtolength{\textheight}{5cm}
|
||||
\setlength{\parskip}{0pt}
|
||||
\setlength{\parindent}{0in}
|
||||
% \setcounter{secnumdepth}{0}
|
||||
|
||||
\begin{document}
|
||||
\hrule \medskip
|
||||
\begin{minipage}{0.295\textwidth}
|
||||
\raggedright
|
||||
\footnotesize
|
||||
Name: Andrew Hayes \\
|
||||
E-mail: \href{mailto://a.hayes18@universityofgalway.ie}{\texttt{a.hayes18@universityofgalway.ie}} \hfill\\
|
||||
ID: 21321503 \hfill
|
||||
\end{minipage}
|
||||
\begin{minipage}{0.4\textwidth}
|
||||
\centering
|
||||
\vspace{0.4em}
|
||||
\Large
|
||||
\textbf{CT3531} \\
|
||||
\end{minipage}
|
||||
\begin{minipage}{0.295\textwidth}
|
||||
\raggedleft
|
||||
\today
|
||||
\end{minipage}
|
||||
\medskip\hrule
|
||||
\begin{center}
|
||||
\normalsize
|
||||
Assignment 02: Build \& Test OSPF Routed Network
|
||||
\end{center}
|
||||
\hrule
|
||||
|
||||
\section{Network Topology}
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=\textwidth]{./images/topology.png}
|
||||
\caption{Network Topology}
|
||||
\end{figure}
|
||||
|
||||
Note that the Internet device is linked to the CoreRouter device via the \verb|enp7s0f3u1u4| interface.
|
||||
This is because I am running the simulation locally on my GNU/Linux laptop without any virtualisation -- \verb|enp7s0f3u1u4| is the name of the Ethernet interface on
|
||||
my laptop.
|
||||
|
||||
\section{Routers Pinging Each Other}
|
||||
The following screenshots show each of the routers pinging each each router that they are directly linked to:
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=\textwidth]{./images/eng-core.png}
|
||||
\caption{\texttt{EngBuilding} {\leftrightarrow} \texttt{CoreRouter}}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=\textwidth]{./images/eng-it.png}
|
||||
\caption{\texttt{EngBuilding} {\leftrightarrow} \texttt{ITBuilding}}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=\textwidth]{./images/core-it.png}
|
||||
\caption{\texttt{CoreRouter} {\leftrightarrow} \texttt{ITBuilding}}
|
||||
\end{figure}
|
||||
|
||||
\section{Routers Pinging Each Other's Loopback Addresses}
|
||||
The following screenshots show each router pinging the loopback addresses of each of the other routers:
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=0.8\textwidth]{./images/eng_ping_loopback.png}
|
||||
\caption{\texttt{EngBuilding} Pinging the Loopback Addresses of the Other Routers}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=0.8\textwidth]{./images/it_ping_loopback.png}
|
||||
\caption{\texttt{ITBuilding} Pinging the Loopback Addresses of the Other Routers}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=0.8\textwidth]{./images/core_ping_loopback.png}
|
||||
\caption{\texttt{CoreRouter} Pinging the Loopback Addresses of the Other Routers}
|
||||
\end{figure}
|
||||
|
||||
\section{VPCs Pinging Each Other}
|
||||
The following screenshot shows the two PCs pinging each other:
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=0.45\textwidth]{./images/ping_pcs.png}
|
||||
\caption{\texttt{PC1-VLAN101} {\leftrightarrow} \texttt{PC2-VLAN202}}
|
||||
\end{figure}
|
||||
|
||||
\section{Verify that the Internet is Reachable from All Devices}
|
||||
I encountered some difficulty reaching the Internet from my devices as I was running the simulations locally on
|
||||
my GNU/Linux laptop, and my packets were getting blocked at some point by the University's firewall, both from my
|
||||
simulated devices such as the VPCs \& MikroTik routers, and when I ran a \verb|traceroute| directly from my
|
||||
laptop.
|
||||
However, the traces from my routers \& VPCs got stuck at the same IP address as the \verb|traceroute| from my real
|
||||
laptop did, which indicates to me that the Internet was reachable and operational from my network simulation, at
|
||||
least to the same extent as it was reachable from my laptop.
|
||||
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=0.6\textwidth]{./images/pc1_ping_internet.png}
|
||||
\caption{Trace to \texttt{8.8.8.8} from \texttt{PC1-VLAN101}}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=0.6\textwidth]{./images/pc2_ping_internet.png}
|
||||
\caption{Trace to \texttt{8.8.8.8} from \texttt{PC2-VLAN202}}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=0.8\textwidth]{./images/core_ping_internet.png}
|
||||
\caption{Trace to \texttt{8.8.8.8} from \texttt{CoreRouter}}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=0.8\textwidth]{./images/eng_ping_internet.png}
|
||||
\caption{Trace to \texttt{8.8.8.8} from \texttt{EngBuilding}}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=0.8\textwidth]{./images/it_ping_internet.png}
|
||||
\caption{Trace to \texttt{8.8.8.8} from \texttt{ITBuilding}}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=0.7\textwidth]{./images/laptop_ping_internet.png}
|
||||
\caption{Trace to \texttt{8.8.8.8} Directly from My Laptop}
|
||||
\end{figure}
|
||||
|
||||
\section{\texttt{CoreRouter}'s Routing Table}
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=0.7\textwidth]{./images/routing_table.png}
|
||||
\caption{\texttt{CoreRouter}'s Routing Table}
|
||||
\end{figure}
|
||||
|
||||
Each entry in the routing table has a route number denoted \verb|#|, a flag, a destination address denoted \verb|DST-ADDRESS|,
|
||||
a preferred source denoted \verb|PREF-SRC|, a gateway denoted \verb|GATEWAY|, \& an OSPF routing distance denoted
|
||||
\verb|DISTANCE|.
|
||||
|
||||
The explanation of each entry is as follows:
|
||||
\begin{enumerate}
|
||||
\setcounter{enumi}{-1}
|
||||
\item This entry has a destination of \verb|0.0.0.0/0|, a gateway of \verb|10.226.144.1|, a flag of \verb|ADS| meaning
|
||||
that it is \textbf{A}ctive, \textbf{D}ynamic (the route is dynamically learned through the routing protocol), \&
|
||||
\textbf{S}tatic (the route is statically configured), \& a distance of 1, which means that the route is highly preferred.
|
||||
It has no preferred source.
|
||||
This entry has the destination address of \verb|0.0.0.0/0| which represents the default route -- this is where any
|
||||
destination address that doesn't match a specific route in the routing table is sent.
|
||||
Any traffic that matches this default destination route will be forwarded to the gateway, which sends it out to
|
||||
the Internet.
|
||||
|
||||
\item This entry has a destination of \verb|10.0.1.0/24|, a preferred source of \verb|10.0.1.2|, a gateway of
|
||||
\verb|ether3|, \& a distance of 0.
|
||||
This destination address is that of the \verb|EngBuilding| network, and the gateway is the link from
|
||||
\verb|CoreRouter| to \verb|EngBuilding|.
|
||||
Its preferred source is the IP of the gateway to the \verb|EngBuilding| router on \verb|ether3|.
|
||||
Its flag is \verb|ADC| which means that it is \textbf{A}ctive, \textbf{D}ynamic, \& \textbf{C}onnected, i.e.
|
||||
the route represents a directly connected network (that of \verb|EngBuilding|).
|
||||
It has a cost of 1, which is quite low, showing that it is highly preferred.
|
||||
|
||||
\item This entry has a destination of \verb|10.0.2.0/24|, no preferred source, a gateway of
|
||||
\verb|10.0.1.1| or \verb|10.0.3.1|, \& a distance of 110.
|
||||
The destination is that of the \verb|ITBuilding| network, and the two potential gateways are that of the
|
||||
\verb|EngBuilding| router and the \verb|CoreRouter| router, indicating that the network can be reached from
|
||||
either router.
|
||||
Its flag is \verb|ADo|, where the ``o'' represents that the route was discovered through the \textbf{O}SPF
|
||||
protocol.
|
||||
It has a high cost of \verb|110|, which shows that it is not preferred.
|
||||
|
||||
\item This entry has a destination of \verb|10.0.3.0/24|, a preferred source of \verb|10.0.3.2|, a gateway of
|
||||
\verb|ether2|, \& a distance of 0.
|
||||
This is the route to the \verb|ITBuilding| network and its preferred source is from within that network.
|
||||
Its flag is \verb|ADC| meaning that it is active, dynamic, \& connected and the distance of 0 indicates it is
|
||||
highly preferred, likely because it is directly connected to the router.
|
||||
|
||||
\item This entry has a destination of \verb|10.10.10.1/32|, no preferred source, a gateway of
|
||||
\verb|10.0.1.1|, \& a distance of 110.
|
||||
The destination is the loopback address of the \verb|EngBuilding| router and the gateway is that of the link
|
||||
that joins \verb|EngBuilding| \& \verb|CoreRouter|.
|
||||
Its flag is \verb|ADo| indicating that it was discovered via the OSPF protoocl and the distance of 110
|
||||
indicates that it is not preferred.
|
||||
|
||||
\item This entry has a destination of \verb|10.10.10.3/32|, a preferred source of \verb|10.10.10.3|, a gateway of
|
||||
\verb|Loopback|, \& a distance of 0.
|
||||
The destination is the loopback address of the \verb|CoreRouter| and the gateway is also the loopback address.
|
||||
Its flag is \verb|ADo| indicating that it was discovered via the OSPF protoocl and the distance of 0
|
||||
indicates that it is highly preferred, likely because it is literally the same device.
|
||||
|
||||
\item This entry has a destination of \verb|10.10.10.4/32|, no preferred source, a gateway of
|
||||
\verb|10.0.3.1|, \& a distance of 110.
|
||||
The destination is the loopback address of the \verb|ITBuilding| router and the gateway is that of the link
|
||||
that joins \verb|ITBuilding| \& \verb|CoreRouter|.
|
||||
Its flag is \verb|ADo| indicating that it was discovered via the OSPF protoocl and the distance of 110
|
||||
indicates that it is not preferred.
|
||||
|
||||
\item This entry has a destination of \verb|10.226.128.0/32|, a preferred source of \verb|10.226.130.218|, a
|
||||
gateway of \verb|ether1|, \& a distance of 0.
|
||||
The destination address is the same IP as the gateway of route \verb|0|, as this is the address out onto the
|
||||
internet, via a University router.
|
||||
Its flag is \verb|ADC| indicating that it is directly connected to \verb|CoreRouter| and the distance of 0
|
||||
indicates that it is highly preferred, likely because it is directly connected.
|
||||
|
||||
\item This entry has a destination of \verb|192.168.100.0/24|, no preferred source, a
|
||||
gateway of \verb|10.0.1.1|, \& a distance of 110.
|
||||
The destination address is that of \verb|VLAN101|, and its gateway is the address of the link between
|
||||
\verb|CoreRouter| \& \verb|EngBuilding|, as \verb|VLAN101| is only accessible through \verb|EngBuilding|.
|
||||
Its flag is \verb|ADo| indicating that it was discovered via the OSPF protocol and the distance of 110
|
||||
indicates that it is not preferred.
|
||||
|
||||
\item This entry has a destination of \verb|192.168.200.0/24|, no preferred source, a
|
||||
gateway of \verb|10.0.3.1|, \& a distance of 110.
|
||||
The destination address is the IP of \verb|VLAN202|, and its gateway is the address of the link between
|
||||
\verb|CoreRouter| \& \verb|ITBuilding|, as \verb|VLAN202| is only accessible through \verb|ITBuilding|.
|
||||
Its flag is \verb|ADo| indicating that it was discovered via the OSPF protocol and the distance of 110
|
||||
indicates that it is not preferred.
|
||||
\end{enumerate}
|
||||
|
||||
\section{What if Each Router Wasn't Set Up to Redistribute Connected Networks?}
|
||||
If each router was not set up to redistribute connected networks, the other routers would not be aware of the networks
|
||||
that were directly connected to the other routers, and therefore \verb|ITBuilding| \& \verb|CoreRouter| would not be aware
|
||||
of the existence of \verb|VLAN101|, and \verb|EngBuilding| \& \verb|CoreRouter| would not be aware of the existence of
|
||||
\verb|VLAN202|.
|
||||
This would mean that these networks would not be included in the routing tables of the routers that are not directly
|
||||
connected to them and therefore they would not be reachable from these routers using OSPF routing.
|
||||
This would prevent the VPCs from being able to ping each other: if \verb|PC1-VLAN101| tried to ping \verb|PC2-VLAN202|,
|
||||
\verb|EngBuilding| would not know where to route the traffic next, as \verb|ITBuilding| wouldn't have told \verb|EngBuilding|
|
||||
that it was connected to \verb|VLAN202|.
|
||||
The inverse would also be true if \verb|PC2-VLAN202| tried to ping \verb|PC1-VLAN101|.
|
||||
|
||||
\section{Traceroute from \texttt{PC1-VLAN101} to \texttt{PC2-VLAN202}}
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=\textwidth]{./images/trace_pcs.png}
|
||||
\caption{Trace from \texttt{PC1-VLAN101} to \texttt{PC2-VLAN202}}
|
||||
\end{figure}
|
||||
|
||||
\subsection{Explanation of the Route Taken}
|
||||
The trace from \verb|PC1-VLAN101| to \verb|PC2-VLAN202| takes three hops:
|
||||
\begin{enumerate}
|
||||
\item \verb|192.168.100.1|: the gateway to \verb|VLAN101| on the \verb|EngBuilding| router.
|
||||
Any traffic entering or exiting \verb|VLAN101| must pass through this gateway.
|
||||
|
||||
\item \verb|10.0.2.2|: the gateway to the \verb|ITBuilding| router on its \verb|ether1| interface, which links
|
||||
\verb|EngBuilding| to \verb|ITBuilding|.
|
||||
|
||||
\item \verb|192.168.200.254|: the VPC \verb|PC2-VLAN202| itself, which is naturally the final destination in a
|
||||
successful trace to this device.
|
||||
\end{enumerate}
|
||||
|
||||
\section{Long Ping from \texttt{PC1-VLAN101} to \texttt{PC2-VLAN202}}
|
||||
Below is the output of a 30 seconds-long ping that was made from \verb|PC1-VLAN101| to \verb|PC2-VLAN202|.
|
||||
While this ping was running, the link from the \verb|EngBuilding| router to the \verb|ITBuilding| router was suspended.
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=0.8\textwidth]{./images/long_ping.png}
|
||||
\caption{Long Ping from \texttt{PC1-VLAN101} to \texttt{PC2-VLAN202}}
|
||||
\end{figure}
|
||||
|
||||
The \verb|EngBuilding| {\leftrightarrow} \verb|ITBuilding| link was suspended just before the 8\textsuperscript{th} packet
|
||||
was sent, resulting in this packet being dropped as it was sent along a route that no longer existed.
|
||||
OSPF kicked in very quickly and the traffic was re-routed after just one lost packet.
|
||||
It is quite obvious from looking at the network topology that the only other way the traffic could have been routed was
|
||||
from \verb|EngBuilding| {\rightarrow} \verb|CoreRouter| {\rightarrow} \verb|ITBuilding|, which requires an extra hop.
|
||||
This path, being longer \& not direct, would have not been preferred by OSPF when there was a link between \verb|EngBuilding|
|
||||
\& \verb|ITBuilding|, but now that it's the best possible option, it will make use of it.
|
||||
We can see why this route was not preferred by the OSPF protocol, as it usually takes noticeably longer than the original route.
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=0.8\textwidth]{./images/redo_trace.png}
|
||||
\caption{Trace from \texttt{PC1-VLAN101} to \texttt{PC2-VLAN202} After Suspending the \texttt{EngBuilding} {\leftrightarrow} \texttt{ITBuilding} Link}
|
||||
\end{figure}
|
||||
|
||||
Comparing the above trace to the one ran previously, we can see that there is one extra hop now that the
|
||||
\verb|EngBuilding| {\leftrightarrow} \verb|ITBuilding| link has been suspended and that it does not go through the
|
||||
\verb|10.0.2.2| gateway it did when we first ran the ping.
|
||||
That gateway was the one between \verb|EngBuilding| \& \verb|ITBuilding|, which is of course now gone.
|
||||
Instead, the traffic travels over the link between \verb|EngBuilding| \& \verb|CoreRouter| (\verb|10.0.1.2|) and then over
|
||||
the link between \verb|CoreRouter| \& \verb|ITBuilding| (\verb|10.0.3.1|), as expected.
|
||||
|
||||
\section{Packet Capture on Link from \texttt{EngBuilding} to \texttt{CoreRouter}}
|
||||
I ran a packet capture on the link from \texttt{EngBuilding} to \texttt{CoreRouter} and restored the link from
|
||||
\verb|EngBuilding| to \verb|CoreRouter|, then stopped the packet capture after around 30 seconds to ensure that OSPF had
|
||||
detected the topology changed and re-converged.
|
||||
Nine LSA packets were captured:
|
||||
\begin{enumerate}
|
||||
\item The first two packets are LS Update packets originating from \verb|EngBuilding| \& \verb|ITBuilding|.
|
||||
The first originated from \verb|10.0.1.2| advertising \verb|10.10.10.4| (\verb|ITBuilding|) while the second originated
|
||||
from \verb|10.0.10.1| advertising \verb|10.10.10.1| (\verb|EngBuilding|).
|
||||
This is the routers announcing that they can be reached over this new topology.
|
||||
|
||||
\item The next two packets are LS Acknowledgements, originating from the same two routers, each acknowledging the
|
||||
other router's update.
|
||||
|
||||
\item The next packet is an LS Update originating from \verb|10.0.1.1| advertising \verb|10.10.10.1| (\verb|EngBuilding|)
|
||||
again.
|
||||
Another packet from the same origin then advertised \verb|10.10.10.4| (\verb|ITBuilding|).
|
||||
This being the IP address which originally advertised \verb|EngBuilding| shows that it has learnt that \verb|ITBuilding|
|
||||
is reachable to it from its advertisement.
|
||||
\verb|10.0.1.2| then sent a packet advertising \verb|ITBuilding| again.
|
||||
|
||||
\item \verb|10.0.1.1| acknowledged \verb|10.0.1.2|'s advertisement of \verb|10.10.10.4|, and \verb|10.0.1.2|
|
||||
acknowledged \verb|10.0.1.1|'s advertisement of \verb|EngBuilding|.
|
||||
\end{enumerate}
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\includegraphics[width=\textwidth]{./images/pcap.png}
|
||||
\caption{OSPF Packets Captured on the \texttt{EngBuilding} {\leftrightarrow} \texttt{CoreRouter} Link}
|
||||
\end{figure}
|
||||
|
||||
|
||||
\end{document}
|
||||
|
After Width: | Height: | Size: 74 KiB |
|
After Width: | Height: | Size: 26 KiB |
|
After Width: | Height: | Size: 68 KiB |
|
After Width: | Height: | Size: 88 KiB |
|
After Width: | Height: | Size: 87 KiB |
|
After Width: | Height: | Size: 35 KiB |
|
After Width: | Height: | Size: 66 KiB |
|
After Width: | Height: | Size: 29 KiB |
|
After Width: | Height: | Size: 69 KiB |
|
After Width: | Height: | Size: 34 KiB |
|
After Width: | Height: | Size: 141 KiB |
|
After Width: | Height: | Size: 19 KiB |
|
After Width: | Height: | Size: 20 KiB |
|
After Width: | Height: | Size: 222 KiB |
|
After Width: | Height: | Size: 70 KiB |
|
After Width: | Height: | Size: 19 KiB |
|
After Width: | Height: | Size: 43 KiB |
|
After Width: | Height: | Size: 58 KiB |
|
After Width: | Height: | Size: 25 KiB |
@ -0,0 +1,17 @@
|
||||
11: Verify that the internet is reachable from all devices and explain the meaning of each entry in the routing table of the CoreRouter.
|
||||
|
||||
12: Explain what would happen if each router was not setup to redistribute connected networks, this was done in Step 7.
|
||||
|
||||
13: Do a trace (using ICMP) from PC1-VLAN101 to PC2-VLAN202 and explain the route that is taken.
|
||||
|
||||
14: Run a long ping (for 30 seconds) from the PC1-VLAN101 to PC2-VLAN202 and while this is running suspend the link (right click on the link to see this option) from the EngBuilding router to the ITBuilding router.
|
||||
|
||||
15: Are any pings dropped after the link is suspended? How long does it take for the ping to work again? Redo the trace, done in Step 13, and explain the results.
|
||||
|
||||
16: Run a packet capture on the link from the EngBuilding router to the CoreRouter, this should launch Wireshark on your computer.
|
||||
|
||||
17: Resume the link from the EngBuilding router to the ITBuilding router and wait about 30 seconds to ensure that OSPF has detected the topology change and reconverged.
|
||||
|
||||
18: Stop the packet capture and apply a display filter in Wireshark to only display OSPF packets. Explain the contents of any Link State Announcement (LSA) packets captured
|
||||
|
||||
Submit your work in a single zip file using the name format assignment2_firstname_lastname.zip - other file formats will NOT be accepted and email submission will NOT be accepted. Include related screen shots of your GNS3 simulation, the router configurations, as well as screen shots of your testing, results and related answers into a single document, this document (in Word or PDF format) can then be included in the zip file for submission. Please note that you do not need to submit the GNS3 project files. If you submit more than one attempt then only the last attempt will be marked.
|
||||