++doc ++helper scripts
This commit is contained in:
Nico Schottelius
parent
0dedb40ca7
commit
b50c46970f
8 changed files with 91 additions and 62 deletions
18
bin/benchmark-prepare-jool.sh
Executable file
18
bin/benchmark-prepare-jool.sh
Executable file
|
|
@ -0,0 +1,18 @@
|
|||
#!/bin/sh
|
||||
|
||||
set -x
|
||||
|
||||
sudo /etc/init.d/tayga stop
|
||||
|
||||
sudo sysctl -w net.ipv4.conf.all.forwarding=1
|
||||
sudo sysctl -w net.ipv6.conf.all.forwarding=1
|
||||
sudo modprobe jool_siit
|
||||
sudo jool_siit instance add "example" --iptables
|
||||
sudo jool_siit -i example eamt add 2001:db8:42::/120 10.0.1.0/24
|
||||
sudo ip6tables -t mangle -A PREROUTING -s 2001:db8:42::/120 -d 2001:db8:23::/120 -j JOOL_SIIT --instance example
|
||||
sudo iptables -t mangle -A PREROUTING -s 10.0.0.0/24 -d 10.0.1.0/24 -j JOOL_SIIT --instance example
|
||||
|
||||
sudo ip addr add 2001:db8:42::77/64 dev eth2
|
||||
sudo ip link set eth2 up
|
||||
sudo ip addr add 10.0.0.77/24 dev eth1
|
||||
sudo ip l s eth1 up
|
||||
7
bin/benchmark-prepare-software-esprimo.sh
Executable file
7
bin/benchmark-prepare-software-esprimo.sh
Executable file
|
|
@ -0,0 +1,7 @@
|
|||
#!/bin/sh
|
||||
|
||||
set -x
|
||||
|
||||
# Required for NAT64 going into the other side
|
||||
sudo ip route add 10.0.1.0/24 via 10.0.0.77
|
||||
sudo ip route add 2001:db8:23::/96 via 2001:db8:42::77
|
||||
|
|
@ -3,50 +3,52 @@
|
|||
% document. What are the highlights of your work.
|
||||
% It should conclude by a conclusion.
|
||||
|
||||
Sum up what you have done and recapitulate your key findings.
|
||||
|
||||
p4 potential
|
||||
Many possibilities
|
||||
Protocol independent
|
||||
Easy architecture
|
||||
|
||||
NDP parsing support
|
||||
|
||||
Can be deployed using the netpfga. Or Barefoot or Arista.
|
||||
|
||||
OUTLOOK What are the consequences of your work for future work?
|
||||
|
||||
Different HW
|
||||
|
||||
Speed only limited to line speed. Could be running at 100 Gbit/s
|
||||
without modifications.
|
||||
|
||||
PMTU
|
||||
handling error cases
|
||||
% General / Review
|
||||
The objective of implementing high speed NAT64 in P4 has been
|
||||
achieved. The implementation at hand has been shown to be portable
|
||||
between 2 different P4 targets. It should be portable with minor
|
||||
target specific changes to faster hardware to support NAT64 at much
|
||||
higher line speeds, without any logic changes.
|
||||
|
||||
Our algorithm uses the IPv4-Compatible IPv6 Address\cite{rfc4291} to
|
||||
embed IPv4 addresses. However RFC6052\cite{rfc6052} defines different
|
||||
embeddings depending on the prefix size. A future version should
|
||||
support these schemes to be compatible to other implementations.
|
||||
|
||||
PMTU
|
||||
handling error cases
|
||||
No fragmentation
|
||||
No address / mac learning
|
||||
|
||||
**** No DNS64
|
||||
has already been solved in a different domain - could even do
|
||||
transparent / in network modification. DNSSEC.
|
||||
supporting migration to IPv6 only networks
|
||||
|
||||
**** Incomplete NDP
|
||||
Very limited option support
|
||||
% P4
|
||||
P4 has been proven for us as a suitable programming language for
|
||||
network equipment with great potential. However in the current state
|
||||
the tooling and frameworks are still immature and need significant
|
||||
work to become usable for solving day-to-day challenges or supporting
|
||||
large scale projects. Even with the current state drawbacks, P4 is a
|
||||
very convincing language that has wide range of applications due to
|
||||
its protocol independence and easy to understand architecture.
|
||||
|
||||
No resolution of hardware addresses
|
||||
% NetPFGA
|
||||
The NetFGPA platform is a good showcase for the capabilities of
|
||||
P4, demonstrating almost line speed P4 programs.
|
||||
However the supporting code immaturity, logging ambiguity
|
||||
and enormous complexity of the development process.
|
||||
|
||||
Very time intensive development due to usability problems and
|
||||
uncertainty of functionality (compare sections
|
||||
\ref{results:netpfga:usability} and \ref{results:netpfga:stability}).
|
||||
|
||||
While the port to NetPFGA was significantly more effort then expected,
|
||||
the learnings of the different layers were very much appreciated / liked
|
||||
|
||||
It was a
|
||||
% Outlook OUTLOOK What are the consequences of your work for future work?
|
||||
The availability of protocol independent programmable network
|
||||
equipment opens up many possibilities for in network
|
||||
programming. While this thesis focused on NAT64, the accompying
|
||||
technologie DNS64\cite{rfc6147} could also be implemented in P4, thus
|
||||
completing the translation mechanism.
|
||||
|
||||
NetFGPA - conclusion here
|
||||
Very time intensive development due to usability problems and
|
||||
uncertainty of functionality (compare sections
|
||||
\ref{results:netpfga:usability} and \ref{results:netpfga:stability}).
|
||||
Proxies / higher level protocols could be next level
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ Tayga & 3.36 & 3.29 & 3.11 \\
|
|||
\hline
|
||||
Jool & 8.24 & 8.26 & 8.29\\
|
||||
\hline
|
||||
P4 / NetPFGA & 8.43 & 9.29 & 9.29\\
|
||||
P4 / NetPFGA & 9.28 & 9.29 & 9.29\\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\end{minipage}
|
||||
|
|
@ -160,6 +160,17 @@ table entries.
|
|||
|
||||
Jool and tayga are supported by
|
||||
|
||||
Trace files
|
||||
\begin{verbatim}
|
||||
create mode 100644 pcap/tcp-udp-delta-2019-07-17-1555-h1.pcap
|
||||
create mode 100644 pcap/tcp-udp-delta-2019-07-17-1555-h3.pcap
|
||||
create mode 100644 pcap/tcp-udp-delta-2019-07-17-1557-h1.pcap
|
||||
create mode 100644 pcap/tcp-udp-delta-2019-07-17-1558-h3.pcap
|
||||
|
||||
|
||||
\end{verbatim}
|
||||
|
||||
|
||||
% ----------------------------------------------------------------------
|
||||
\section{\label{results:netpfga}NetFPGA}
|
||||
The reduced feature set of the NetPFGA implementation is due to two
|
||||
|
|
@ -382,15 +393,6 @@ Renaming variables in the declaration of the parser or deparser lead
|
|||
to compilation errors. Function syntax is not supported. For this
|
||||
reason our implementation uses \texttt{\#define} statements instead of functions.
|
||||
|
||||
Trace files
|
||||
\begin{verbatim}
|
||||
create mode 100644 pcap/tcp-udp-delta-2019-07-17-1555-h1.pcap
|
||||
create mode 100644 pcap/tcp-udp-delta-2019-07-17-1555-h3.pcap
|
||||
create mode 100644 pcap/tcp-udp-delta-2019-07-17-1557-h1.pcap
|
||||
create mode 100644 pcap/tcp-udp-delta-2019-07-17-1558-h3.pcap
|
||||
|
||||
|
||||
\end{verbatim}
|
||||
|
||||
\begin{verbatim}
|
||||
*** DONE 2019-07-21: Proof of v6->v4 working delta based
|
||||
|
|
@ -490,34 +492,34 @@ Integration with iptables
|
|||
|
||||
% ----------------------------------------------------------------------
|
||||
\section{\label{results:p4}P4}
|
||||
All planned features could be realised with P4 and a controller.
|
||||
The language has some limitations on where if/switch statements can be
|
||||
used.\footnote{In general, if and switch statements in actions lead to
|
||||
errors, but not all constellations are forbidden.}
|
||||
|
||||
For this thesis the parsing capabilities of P4 were adequate. However
|
||||
P4 at the time of writing cannot parse ICMP6 options, as the upper
|
||||
level protocol does not specify the number of options that follow and
|
||||
parsing of 64 bit blocks is required.
|
||||
|
||||
P4/BMV2 does not support for multiple LPM keys in a table, however it
|
||||
supports multiple keys with ternary matching.
|
||||
|
||||
When developing P4 programs, the reason for incorrect behaviour was
|
||||
most often found in checksum problems. If frame checksum errors where
|
||||
displayed by tcpdump, usually the effective length of the packet was
|
||||
incorrect.
|
||||
|
||||
|
||||
NDP parsing problem
|
||||
|
||||
checksumming a frequent problem and helper
|
||||
|
||||
|
||||
if in action limitations
|
||||
|
||||
switch cannot be used in actions
|
||||
|
||||
python2 only - unicode errors
|
||||
|
||||
IPv6: NDP: not easy to parse, as unknown number of following fields
|
||||
|
||||
No support for multiple LPM keys in a table, can be solved with
|
||||
ternary matching.
|
||||
|
||||
if things don't work, often a checksum problem.
|
||||
|
||||
if frame checksum, then length of packet is broken
|
||||
|
||||
\begin{verbatim}
|
||||
p4c --target bmv2 --arch v1model --std p4-16 "../p4src/static-mapping.p4" -o "/home/p4/master-thesis/p4src"
|
||||
../p4src/static-mapping.p4(366): error: Program is not supported by this target, because table MyIngress.v6_networks has multiple successors
|
||||
table v6_networks {
|
||||
^^^^^^^^^^^
|
||||
|
||||
\end{verbatim}
|
||||
|
||||
\begin{verbatim}
|
||||
ipaddress.ip_network("2001:db8:61::/64")
|
||||
IPv6Network(u'3230:3031:3a64:6238:3a36:313a:3a2f:3634/128')
|
||||
|
|
@ -536,7 +538,6 @@ or missing features (\cite{schottelius:github745},
|
|||
Hitting expression bug
|
||||
|
||||
|
||||
|
||||
retrieving information from tables
|
||||
\begin{verbatim}
|
||||
Key and mask for matching destination is in table. We need this
|
||||
|
|
|
|||
BIN
doc/Thesis.pdf
BIN
doc/Thesis.pdf
Binary file not shown.
|
|
@ -1,6 +1,6 @@
|
|||
\documentclass[10pt,final,a4paper,twoside]{book}
|
||||
|
||||
\newcommand{\watermark}{DRAFT} % a watermark is included on all pages if \watermark is defined here
|
||||
%\newcommand{\watermark}{DRAFT} % a watermark is included on all pages if \watermark is defined here
|
||||
|
||||
%** preamble.tex: here all the document-wide settings
|
||||
% are defined
|
||||
|
|
|
|||
|
|
@ -3355,6 +3355,7 @@ https://en.wikipedia.org/wiki/IPv4_header_checksum
|
|||
CLOSED: [2019-08-13 Tue 10:36]
|
||||
*** DONE Setup / Benchmark tayga
|
||||
CLOSED: [2019-08-13 Tue 10:36]
|
||||
*** Redo Jool
|
||||
* TODO Thesis documentation
|
||||
** Introduction
|
||||
*** Related work
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue