-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathreport.tex
238 lines (228 loc) · 14.5 KB
/
report.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
\documentclass{article}
\usepackage{graphicx}
\usepackage{listings}
%\usepackage[comma, authoryear]{natbib}
\begin{document}
\begin{titlepage}
\vspace*{\stretch{1.0}}
\begin{center}
\Large\textbf{Routing using Quagga: An example with OSPF`}\\
A technical report\\
\textit{by}\\
\large\textit{Adithya K \\ Abhishek Balaji}
\end{center}
\vspace{2cm}
\begin{figure}[ht!]
\centering
\includegraphics[width=40mm]{Quagga.jpg}
\end{figure}
\vspace*{\stretch{2.0}}
\end{titlepage}
\tableofcontents
\clearpage
\section{Introduction}
\pagenumbering{arabic}
\begin{figure}[ht!]
\centering
\includegraphics[width=10cm]{BasicRouter.jpg}
\caption{Basic representation of a Routing stack}
\label{fig:basicrouter}
\end{figure}
Network Routing refers to the action of an electronic network in transferring data
from one part of the network to another in an efficient and an optimized way.
The Network typically consists of a bunch of forwarding elements (Hardware) which
perform the actual transmission, receiving of data and a software sitting on top of them,
which co-ordinate and take decisions on which next hardware element the piece of data
should be given to. Figure~ \ref{fig:basicrouter} presents a basic structure
of a single routing element.\\
\textbf{Quagga} is one such software, a Network Routing Software. It runs on \textit{Unix}-like systems
(GNU/Linux, Solaris, FreeBSD, NetBSD). Quagga is a Software Suite, having implementations
of the famous routing protocols of the Internet viz. \textbf{Routing Information Protocol (RIP),
Open Shortest Path First (OSPF), Border Gateway Protocol (BGP)} and also support for
BABEL, OLSR (Wireless Mesh Routing Protocols). Quagga is a open-source-licenced (GPLv2) stack.\\
Quagga had its origins in the Zebra project. Quagga was forked off Zebra in order to provide a
more community based approach to it. Zebra currently in the form of ZebOS is currently being
deployed by a company IP Infusion. \cite{zebraipinfusion}. Quagga is currently being maintained
by NetDEF \cite{netdef} as a OpenSourceRouting project.
\subsection{Architecture}
The Quagga architecture consists of a core daemon, \textit{zebra}, which acts as an abstraction
layer to the underlying Unix kernel and presents the \textbf{Zserv API} over a Unix or TCP stream
to Quagga clients. It is these Zserv clients which typically implement a routing protocol
and communicate routing updates to the zebra daemon.\cite{quaggaofficial} \\
\begin{figure}[ht!]
\centering
\includegraphics[width=10cm]{QuaggaArchitecture.jpg}
\caption{Architecture of Quagga Software Stack}
\label{fig:quaggaarchitecture}
\end{figure}
Referring Figure~ \ref{fig:quaggaarchitecture}, we can see that Zebra is an IP routing manager.
It provides kernel routing table updates, interface lookups, and redistribution of routes between
different routing protocols. Zebra acts as a dedicated server. It exchanges routing information with
other routers using routing protocols and updates the kernel’s routing table based on the information exchanged.
Zebra daemon is the core of quagga that manage the interaction of kernel routing table and the daemons for
individual routing protocols. Each daemon has its own config file in /etc/quagga directory and their own
virtual terminal interface or vty. As mentioned before, the individual routing protocol daemons communicate
with the Zebra daemon over a TCP stream. A custom routing protocol may also be written to interface with the
Zebra daemon using the ZServ API \cite{zservdocs}.
\subsection{Usecases and Alternatives}
As mentioned by a chief maintainer of the Quagga software \cite{martininterview}, Quagga's
primary use-case is for anybody who needs an open-source implementation of the routing protocols
as a base for trying out new one. Quagga is used both in data centers and in the academic community.
Quagga also is seen as a software which is very useful and widely used, but rarely acknowledged by the corporate community.\\
The main alternative for the Quagga routing software is the BIRD Internet Routing Daemon \cite{bird}.
Developed from scratch as an academic project mainly for BGP route-reflector for Internet exchange points,
it is actively maintained and supported till date supporting multiple protocols including OSPF.
\clearpage
%\section{OSPF}
%Do we need this???
%\clearpage
\section{Testbed Description}
Our goal is to display the working of a routing protocol using the Quagga software stack.
We have chosen Open-Shortest-Path-First protocol as it is the most common routing protocol
within an Autonomous System. We propose to show how the routing tables are built,
how link-state information is utilized and how an alternate path is established in case of a link failure.\\
We use, two physical machines each running 12.04 Ubuntu LTS, with Intel x86-64 bit architectures with
32 GB of RAM. We run in each of these, two virtual machines which are directly connected to the host machine,
and also via an internal network between them.\\
\begin{figure}[ht!]
\centering
\includegraphics[width=10cm]{QuaggaTopo.jpg}
\caption{Network Topology chosen for the experiments}
\label{fig:networktopo}
\end{figure}
Figure~\ref{fig:networktopo} presents the network topology that was chosen. Every node (virtual or a physical
entity) has Quagga running on it and functions as a router. For practical reasons, we did not add individual nodes
but used our Router nodes for running basic connectivity and path measurements. We perform two experiments, and
further capture the connectivity and path measurements using the \textit{ping} and \textit{traceroute} commands
available on standard Ubuntu distributions.
\subsection{Quagga Setup}
\label{sec:quaggasetup}
This section describes the configuration changes that were made to implement OSPF using Quagga.
The first step before proceeding is to install Quagga. We used the standard Ubuntu repositories to install Quagga similar to \cite{quaggaubuntuinstall}.
If you use a different Linux distribution or would like to install Quagga from source, follow \cite{quaggainstall}.\\
Now, that we have installed Quagga, the next step is to make sure it is configured in a correct way.
We need to specify to Quagga, the various routing protocol daemons that we need running, and
then specify the configurations for those protocols. Configurations are to be described in separate configuration
files for individual routing protocols. These configurations are typically specified in the `/etc/quagga' folder
\footnote{May vary if you build from source and specify different installation paths}\\
The steps that we performed are captured below.
\begin{enumerate}
\item Create/Edit the `daemons' file to specify that you will be needing Zebra
and Ospf daemons running. \footnote{Zebra is default daemon that should always
be run irrespective of what routing software you employ}
\item Create/Edit the `zebra.conf' file, to specify about your network configuration.
This will contain the network interfaces (eth1, eth2 etc.) that your router has,
the IP addresses assigned on those interfaces (ipv4/ipv6 addressing).
See Appendix Section \ref{sec:appendix} for a sample file.
\item Create/Edit the `ospfd.conf' file, to specify the configurations related to OSPF,
the area configuration and the IP addresses of the individual networks.
See Appendix Section \ref{sec:appendix} for a sample file.
\item Start Quagga in the CLI by typing in \# `/etc/init.d/quagga start'
\footnote{In case Quagga is already running, you need to type restart, to stop the running daemon before starting it again}
\footnote{This case assumes you have the OS setup as Ubuntu, in case of a different flavor of Linux, kindly consult the user-doc on how to run applications}
\item Verify Quagga is running by checking the process tree. We use the \#`ps aux|grep quagga' command.
In our case, it shows two daemons running, the Zebra daemon and the OSPF daemon. Each routing protocol has its own seperate daemon process spawned.
\end{enumerate}
Now, we have seen how to start a specific routing protocol in Quagga. In the next section we will see how OSPF is running within Quagga and verify it.
%\subsection{Experiment 1}
%In the first experiment, we simply start the Quagga routing software with a OSPF daemon on each of the nodes
%and verify the routing table generated.
%\subsection{Experiment 2}
%Tear down a link and display how packets are re-routed along with the new routing table
\clearpage
\section{Performance Measurement Results}
We conduct two experiments, capture the connectivity and path metrics and also show the routing table generated.
The first experiment presents a stable state, after simply starting the Quagga routing software suite on all the routers as described in
Fig \ref{fig:networktopo} (See Section \ref{sec:quaggasetup} to see the setup)
We show the routing table generated, the ping and traceroute results from two distinct nodes in the network.\\
In Experiment 2, we remove the link between two nodes which is used in the routing table, and show how the network re-routes traffic
after routing protocol adds an alternate path.
\subsection{Experiment 1}
As described before, experiment 1 will describe the steady state routing table and we will verify the path
computation.\\
\begin{figure}[ht!]
\centering
\includegraphics[width=13cm]{results/exp1-quagga-rt.png}
\caption{Routing Table via Quagga CLI at Node 3}
\label{fig:exp1-quagga-rt}
\end{figure}
Figure~ \ref{fig:exp1-quagga-rt} shows the routing table at Node 3. (See Figure~ \ref{fig:networktopo} for the topology).
This is the routing table displayed after logging into the zebra CLI via the telnet client.
Quagga provides a CLI interface running on port 2601 on the host machine.
As is evident from the screenshot, it displays the Kernel generated routes(K), Directly connected routes(C)
and the OSPF generated routes (O). We are mainly interested in the routes generated by the OSPF protocol.
The networks 192.168.56.0/24 and 192.168.58.0/24 are discovered and updated in the routing table and the
next hop is correctly identified as eth1, which is the direct link to Node 4.\\
\begin{figure}[ht!]
\centering
\includegraphics[width=11cm]{results/exp1-vbox-ping_tr.png}
\caption{Ping and Traceroute results from Node 1 to Node 6}
\label{fig:exp1-vbox-ping_tr}
\end{figure}
\begin{figure}[ht!]
\centering
\includegraphics[width=11cm]{results/exp1-vboxab-rt.png}
\caption{Routing Table on Node 6}
\label{fig:exp1-vboxab-rt}
\end{figure}
\begin{figure}[ht!]
\centering
\includegraphics[width=11cm]{results/exp1-vboxab-tr.png}
\caption{Traceroute results from Node 6 to Node 3}
\label{fig:exp1-vboxab-tr}
\end{figure}
This can further be verified by doing a ping and traceroute from Node 1 to Node 6.
Figure~ \ref{fig:exp1-vbox-ping_tr} shows the ping statistics and the traceroute path. The traceroute
path goes as follows: Node 1 -\textgreater Node 3 -\textgreater Node 4 -\textgreater Node 6.\\
Now, we shall look at a return path from Node 6 to Node 3.\\
Figure~ \ref{fig:exp1-vboxab-rt} shows the routing table on Node 6 and the ping result to Node 3,
while Figure~ \ref{fig:exp1-vboxab-tr} traces the path to Node 3.
In the next experiment, we shall look at how OSPF reacts to a link failure.\\
\subsection{Experiement 2}
\begin{figure}[ht!]
\centering
\includegraphics[width=13cm]{results/exp2-vbox-ping_tr.png}
\caption{Ping and Traceroute from Node 1 to Node 5 after OSPF has an alternate path established}
\label{fig:exp2-vbox-ping_tr}
\end{figure}
We break down two links, which are expected to be used as the default path as derived by OSPF.
We obtained this path information by looking at the routing tables at the nodes as described in
Experiment 1. We break down link between Node 1 and Node 3 and simulataneously, the link between
Node 4 and Node 5. We expected the packet from Node 1 to reach Node 5 without any issues, as
alternate paths existed. Figure~ \ref{fig:exp2-vbox-ping_tr} validates that argument, by proving
both the reachability by the ping, and the path computation by the traceroute command.
The routing protocol had converged on a new path, and a new path existed with 5 hops (2 more than
previous route). The new path was Node 1 -\textgreater Node 2 -\textgreater Node 3 -\textgreater Node 4 -\textgreater Node 6 -\textgreater Node 5.\\
%The above two experiments simply perform bare minimum validations of functioning of the Quagga
%routing stack.
\clearpage
\section{Conclusions and Suggestions}
Quagga Routing software is able to demonstrate and prove that a simple machine running
Linux can definitely be used as a custom-enterprise grade router. Also, after evolving
from the Zebra software, it provides an easy mechanism for any new protocol to be built
on top of it. Sadly, it could never really continue and be a market changer, because,
Network component manufacturers (viz. Cisco, Juniper) built their own software stacks for
tighter integration with their hardware systems. But today, Networking in general has
evolved, and market is moving in the direction of dividing the routing software (control plane)
with the forwarding component (Data plane). Quagga has adjusted to this and provides
support for this. What remains to be seen is whether the new players entering the market
are willing to adopt a proven open, enterprise-grade alternative to a purely proprietary version.
\clearpage
%\bibliographystyle{plain}
%\bibliography{abbr_long, ref_links}
\section{Appendix}
\label{sec:appendix}
\lstinputlisting{zebra.conf}
\lstinputlisting{ospfd.conf}
\clearpage
\begin{thebibliography}{9}
\bibitem{quaggaofficial}The official website of the quagga software provided by the GNU foundation http://www.nongnu.org/quagga/
\bibitem{zebraipinfusion}GNU Zebra project implemented as ZebOS at IP Infusion http://en.wikipedia.org/wiki/GNU\textunderscore Zebra
\bibitem{netdef} Network Device Education Foundation, Non-profit company http://www.netdef.org/
\bibitem{martininterview} Quagga: A Success, and Yet a Failure, of Open-Source In Networking? Interview with Martin Winter,NetDEF https://www.sdncentral.com/education/quagga-project-martin-winter-interview/2014/02/
\bibitem{bird} BIRD Internet Routing Daemon http://bird.network.cz/
\bibitem{quaggaubuntuinstall} Installing Quagga in Ubuntu https://wiki.ubuntu.com/JonathanFerguson/Quagga
\bibitem{quaggainstall} Official guide to build and install Quagga http://www.nongnu.org/quagga/docs/docs-info.html\#Installation
\bibitem{zservdocs} Zebra protocol, packet format and ZServ APIs http://www.nongnu.org/quagga/docs/docs-info.html\#Zebra-Protocol
\end{thebibliography}
\end{document}