Report: Added experiment 3 and conclusions

report/report.tex

@@ -153,6 +153,13 @@
 \newcommand{\arpDecodedUrl}{\repoGithub/blob/HEAD/exercise/results/exp2-arp/arp-decoded.txt}
 \newcommand{\arpPcapUrl}{\repoGithub/blob/HEAD/exercise/results/exp2-arp/arp.pcap}
 
+% Experiment 3
+\newcommand{\routingExecutionUrl}{\repoGithub/blob/HEAD/exercise/results/exp3-routing/execution.txt}
+\newcommand{\icmpAPcapUrl}{\repoGithub/blob/HEAD/exercise/results/exp3-routing/icmp-A.pcap}
+\newcommand{\icmpBPcapUrl}{\repoGithub/blob/HEAD/exercise/results/exp3-routing/icmp-B.pcap}
+\newcommand{\icmpADecodedUrl}{\repoGithub/blob/HEAD/exercise/results/exp3-routing/icmp-A-decoded.txt}
+\newcommand{\icmpBDecodedUrl}{\repoGithub/blob/HEAD/exercise/results/exp3-routing/icmp-B-decoded.txt}
+
 \begin{document}
 	
 \InsertTitle
@@ -1156,20 +1163,343 @@ Reply 192.168.1.131 is-at 4a:6f:2a:18:f4:80
 Παρόλα αυτά το γεγονός ότι υπήρχε δεύτερο ζεύγος μας προβλημάτισε ιδιαίτερα μέχρι να ανακαλύψουμε τον λόγο ύπαρξής του!
 
 
+% ========================= Πείραμα 3  =========================
+
+\section{Πείραμα 3 -- Δρομολόγηση L3 και αλλαγή MAC}
+
+\subsection{Σκοπός και πειραματική διαδικασία}
+
+Σκοπός του τρίτου πειράματος είναι η παρατήρηση της προώθησης ενός IP πακέτου μεταξύ δύο διαφορετικών
+υποδικτύων μέσω του δρομολογητή \texttt{r0}.
+Ειδικότερα, εξετάζεται ο τρόπος με τον οποίο ο \texttt{h1} αποφασίζει ότι ο \texttt{h3} βρίσκεται σε διαφορετικό
+υποδίκτυο, καθώς και οι μεταβολές των MAC διευθύνσεων και του TTL κατά τη διέλευση από τον router.
+
+Το πείραμα εκτελέστηκε στην ήδη ενεργή τοπολογία, στην οποία ο \texttt{h1} είχε αποκτήσει μέσω DHCP τη διεύθυνση
+\texttt{192.168.1.131/24}, ενώ ο \texttt{h3} χρησιμοποιούσε τη στατική διεύθυνση
+\texttt{192.168.2.10/24}.
+Πριν από την καταγραφή εκκαθαρίστηκαν οι neighbor tables των δύο hosts και του router, ώστε να απομακρυνθεί
+προϋπάρχουσα κατάσταση ARP.
+
+Οι πρώτες εντολές της εκτέλεσης ήταν:
+
+\begin{minted}{bash}
+    mininet> h1 ip neigh flush all
+    mininet> h3 ip neigh flush all
+    mininet> r0 ip neigh flush all
+    
+    mininet> h1 ip -4 -br addr
+    mininet> h1 ip route
+    
+    mininet> r0 ip -4 -br addr
+    mininet> r0 ip route
+    
+    mininet> h3 ip -4 -br addr
+    mininet> h3 ip route
+\end{minted}
+
+Η κατάσταση διευθυνσιοδότησης και δρομολόγησης που επιβεβαιώθηκε ήταν:
+
+\begin{minted}{text}
+h1:
+192.168.1.131/24
+default via 192.168.1.1 dev h1-eth0
+
+r0:
+r0-eth0: 192.168.1.1/24
+r0-eth1: 192.168.2.1/24
+
+h3:
+192.168.2.10/24
+default via 192.168.2.1 dev h3-eth0
+\end{minted}
+
+Στη συνέχεια ξεκίνησαν \textbf{δύο ταυτόχρονες καταγραφές ICMP}, μία στο Subnet A μέσω του \texttt{h1} και μία
+στο Subnet B μέσω του \texttt{h3}.
+Έτσι, το ίδιο ICMP Echo Request μπορούσε να παρατηρηθεί πριν και μετά την προώθησή του από τον \texttt{r0}.
+
+\begin{minted}{bash}
+    mininet> h1 rm -f /tmp/icmp-A.pcap
+    mininet> h3 rm -f /tmp/icmp-B.pcap
+    
+    mininet> h1 tcpdump -i h1-eth0 -n icmp -w /tmp/icmp-A.pcap &
+    mininet> h3 tcpdump -i h3-eth0 -n icmp -w /tmp/icmp-B.pcap &
+    
+    mininet> h1 ps aux | grep tcpdump
+    mininet> h3 ps aux | grep tcpdump
+    
+    mininet> h1 ping -c 1 192.168.2.10
+    
+    mininet> h1 pkill -INT tcpdump
+    mininet> h3 pkill -INT tcpdump
+\end{minted}
+
+Το ping ολοκληρώθηκε επιτυχώς:
+
+\begin{minted}{text}
+64 bytes from 192.168.2.10: icmp_seq=1 ttl=63 time=1.66 ms
+
+1 packets transmitted, 1 received, 0% packet loss
+\end{minted}
+
+Μετά την καταγραφή εμφανίστηκαν οι MAC διευθύνσεις των τεσσάρων interfaces που συμμετέχουν στη διαδρομή και
+διαβάστηκαν τα δύο αρχεία \texttt{pcap} με εμφάνιση των Ethernet headers:
+
+\begin{minted}{bash}
+    mininet> h1 ip link show h1-eth0
+    mininet> h3 ip link show h3-eth0
+    mininet> r0 ip link show r0-eth0
+    mininet> r0 ip link show r0-eth1
+    
+    mininet> h1 tcpdump -n -e -vv -r /tmp/icmp-A.pcap
+    mininet> h3 tcpdump -n -e -vv -r /tmp/icmp-B.pcap
+\end{minted}
+
+Η πλήρης συνεδρία της εκτέλεσης βρίσκεται στο \href{\routingExecutionUrl}{\texttt{execution.txt}}.
+Οι αρχικές καταγραφές διατίθενται στα \href{\icmpAPcapUrl}{\texttt{icmp-A.pcap}} και
+\href{\icmpBPcapUrl}{\texttt{icmp-B.pcap}}, ενώ οι αποκωδικοποιημένες μορφές τους βρίσκονται στα
+\href{\icmpADecodedUrl}{\texttt{icmp-A-decoded.txt}} και \href{\icmpBDecodedUrl}{\texttt{icmp-B-decoded.txt}}.
+
+\subsection{Απόφαση δρομολόγησης μέσω bitwise AND -- Ζητούμενο 3.1}
+
+Ο \texttt{h1} πρέπει αρχικά να αποφασίσει αν η διεύθυνση προορισμού \texttt{192.168.2.10} ανήκει στο ίδιο
+υποδίκτυο με τη δική του διεύθυνση \texttt{192.168.1.131/24}.
+Για τον σκοπό αυτό εφαρμόζεται bitwise AND μεταξύ κάθε διεύθυνσης και της μάσκας
+\texttt{255.255.255.0}.
+
+Για τη διεύθυνση του \texttt{h1} προκύπτει:
+
+\[
+192.168.1.131
+\mathbin{\&}
+255.255.255.0
+=
+192.168.1.0
+\]
+
+ενώ για τη διεύθυνση προορισμού:
+
+\[
+192.168.2.10
+\mathbin{\&}
+255.255.255.0
+=
+192.168.2.0
+\]
+
+Η διαφορά φαίνεται ήδη στο τρίτο octet:
+
+\begin{minted}{text}
+h1:
+    00000001
+AND 11111111
+  = 00000001
+
+h3:
+    00000010
+AND 11111111
+  = 00000010
+\end{minted}
+
+Εφόσον \texttt{192.168.1.0} και \texttt{192.168.2.0} είναι διαφορετικές network addresses, ο \texttt{h1}
+συμπεραίνει ότι ο προορισμός \textbf{δεν βρίσκεται στο τοπικό του subnet}.
+Συμβουλεύεται επομένως τον πίνακα δρομολόγησης και χρησιμοποιεί την προεπιλεγμένη διαδρομή:
+
+\begin{minted}{text}
+default via 192.168.1.1 dev h1-eth0
+\end{minted}
+
+Το IP packet εξακολουθεί να έχει ως τελικό προορισμό την \texttt{192.168.2.10}, αλλά το Ethernet frame που
+δημιουργεί ο \texttt{h1} αποστέλλεται στη MAC διεύθυνση του gateway \texttt{r0-eth0}.
+
+\subsection{Σύγκριση του ICMP Echo Request στα δύο υποδίκτυα -- Ζητούμενο 3.2}
+
+Οι MAC διευθύνσεις των interfaces που συμμετέχουν στη διαδρομή καταγράφηκαν πριν από την ανάλυση των πακέτων.
+Οι τιμές που προέκυψαν κατά τη συγκεκριμένη εκτέλεση ήταν:
+
+\begin{table}[H]
+    \centering
+    \begin{tabular}{lll}
+        \textbf{Interface} & \textbf{IPv4}          & \textbf{MAC} \\ \hline
+        \texttt{h1-eth0}   & \texttt{192.168.1.131} & \texttt{4a:6f:2a:18:f4:80} \\
+        \texttt{h3-eth0}   & \texttt{192.168.2.10}  & \texttt{2e:ef:81:65:2c:c9} \\
+        \texttt{r0-eth0}   & \texttt{192.168.1.1}   & \texttt{ea:2e:7b:6d:78:82} \\
+        \texttt{r0-eth1}   & \texttt{192.168.2.1}   & \texttt{7e:41:8e:cb:65:05} \\
+        
+    \end{tabular}
+    \caption{Διευθύνσεις των interfaces που συμμετέχουν στη δρομολόγηση.}
+\end{table}
+
+Στο Subnet A το ICMP Echo Request καταγράφηκε στη διεπαφή \texttt{h1-eth0} ως:
+
+\begin{minted}{text}
+4a:6f:2a:18:f4:80 > ea:2e:7b:6d:78:82
+ttl 64
+192.168.1.131 > 192.168.2.10
+ICMP echo request, id 4650, seq 1
+\end{minted}
+
+Η source MAC είναι επομένως η MAC του \texttt{h1-eth0}, ενώ η destination MAC είναι εκείνη του
+\texttt{r0-eth0}.
+Το Ethernet frame στο Subnet A παραδίδεται δηλαδή από τον \texttt{h1} στην τοπική διεπαφή του gateway.
+
+Μετά την προώθηση του IP packet από τον \texttt{r0}, το ίδιο Echo Request καταγράφηκε στη διεπαφή
+\texttt{h3-eth0} του Subnet B ως:
+
+\begin{minted}{text}
+7e:41:8e:cb:65:05 > 2e:ef:81:65:2c:c9
+ttl 63
+192.168.1.131 > 192.168.2.10
+ICMP echo request, id 4650, seq 1
+\end{minted}
+
+Στο δεύτερο subnet η source MAC είναι πλέον η MAC του \texttt{r0-eth1}, ενώ η destination MAC είναι η MAC του
+\texttt{h3-eth0}.
+Ο router έχει επομένως δημιουργήσει νέο Ethernet frame για το επόμενο Layer-2 τμήμα της διαδρομής.
+
+Οι δύο καταγραφές επιτρέπουν την άμεση σύγκριση των πεδίων του ίδιου ICMP Echo Request:
+
+\begin{table}[H]
+    \centering
+    \small
+    \begin{tabularx}{\textwidth}{
+            >{\raggedright\arraybackslash}p{3.0cm}
+            >{\raggedright\arraybackslash}X
+            >{\raggedright\arraybackslash}X
+        }
+        \textbf{Πεδίο}  & \textbf{Subnet A}      & \textbf{Subnet B} \\ \hline
+        Source IP       & \texttt{192.168.1.131} & \texttt{192.168.1.131} \\
+        Destination IP  & \texttt{192.168.2.10}  & \texttt{192.168.2.10} \\
+        
+        Source MAC      & \texttt{4a:6f:2a:18:f4:80} (\texttt{h1-eth0}) & \texttt{7e:41:8e:cb:65:05} (\texttt{r0-eth1}) \\
+        Destination MAC & \texttt{ea:2e:7b:6d:78:82} (\texttt{r0-eth0}) & \texttt{2e:ef:81:65:2c:c9} (\texttt{h3-eth0}) \\
+        
+        TTL             & \texttt{64}            & \texttt{63} \\
+    \end{tabularx}
+    \caption{Σύγκριση του ICMP Echo Request στα δύο υποδίκτυα.}
+\end{table}
+
+Η διαδρομή του Ethernet frame μπορεί επομένως να αποδοθεί συνοπτικά ως:
+
+\begin{minted}{text}
+Subnet A ---- → |            r0             | ← ---- Subnet Β
+      h1-eth0 → [r0-eth0 → routing → r0-eth1] → h3-eth0 
+\end{minted}
+
+Οι IP διευθύνσεις, το ICMP identifier \texttt{4650} και το sequence number \texttt{1} επιβεβαιώνουν ότι οι δύο
+καταγραφές αφορούν το \textbf{ίδιο ICMP Echo Request}.
+Οι IP διευθύνσεις παραμένουν ίδιες, ενώ οι MAC διευθύνσεις αντικαθίστανται από εκείνες των interfaces που
+συμμετέχουν στο εκάστοτε Layer-2 segment.
+
+Παράλληλα, το TTL μειώνεται από \texttt{64} σε \texttt{63}.
+Η μεταβολή αυτή αποτελεί άμεση ένδειξη ότι το IP packet προωθήθηκε από έναν router, καθώς το TTL μειώνεται κατά
+μία μονάδα σε κάθε Layer-3 hop.
+
+\subsection{Μεταβολή των MAC διευθύνσεων και διατήρηση των IP}
+
+Η διαφορετική συμπεριφορά των IP και MAC διευθύνσεων οφείλεται στο διαφορετικό πεδίο ισχύος των δύο επιπέδων.
+Οι IP διευθύνσεις χαρακτηρίζουν τους \textbf{τελικούς endpoints της επικοινωνίας}, ενώ οι MAC διευθύνσεις
+χρησιμοποιούνται για την παράδοση ενός Ethernet frame μέσα σε ένα συγκεκριμένο Layer-2 δίκτυο.
+
+Στο Subnet A ο \texttt{h1} δημιουργεί ένα IP packet με source \texttt{192.168.1.131} και destination
+\texttt{192.168.2.10}.
+Επειδή ο προορισμός βρίσκεται σε διαφορετικό subnet, το packet τοποθετείται σε Ethernet frame με destination
+τη MAC του \texttt{r0-eth0}, δηλαδή τη MAC της διεπαφής του gateway που βρίσκεται στο ίδιο subnet με τον
+\texttt{h1}.
+
+Ο \texttt{r0} παραλαμβάνει το Ethernet frame από το \texttt{r0-eth0}, αφαιρεί το Layer-2 header και εξετάζει
+το IP packet.
+Με βάση τον πίνακα δρομολόγησής του επιλέγει ως εξερχόμενη διεπαφή το \texttt{r0-eth1}, μειώνει το TTL κατά μία
+μονάδα και δημιουργεί \textbf{νέο Ethernet frame} για το Subnet B.
+Στο νέο frame source MAC είναι η MAC του \texttt{r0-eth1} και destination MAC η MAC του \texttt{h3-eth0}.
+
+Η διαδικασία αποτυπώνεται στις πραγματικές τιμές της καταγραφής ως:
+
+\begin{minted}{text}
+Subnet A:
+4a:6f:2a:18:f4:80  ->  ea:2e:7b:6d:78:82
+h1-eth0                r0-eth0
+IP:  192.168.1.131  ->  192.168.2.10
+TTL: 64
 
 
+Subnet B:
+7e:41:8e:cb:65:05  ->  2e:ef:81:65:2c:c9
+r0-eth1                h3-eth0
+IP:  192.168.1.131  ->  192.168.2.10
+TTL: 63
+\end{minted}
+
+Επομένως, οι MAC διευθύνσεις έχουν \emph{hop-by-hop} σημασία και αλλάζουν όταν το IP packet προωθείται από τον
+δρομολογητή σε διαφορετικό Layer-2 δίκτυο.
+Αντίθετα, οι IP διευθύνσεις έχουν \emph{end-to-end} σημασία και παραμένουν ίδιες από τον αρχικό αποστολέα μέχρι
+τον τελικό προορισμό, καθώς στην τοπολογία δεν πραγματοποιείται μετάφραση διευθύνσεων NAT.
+
+Η ίδια συμπεριφορά παρατηρείται και στην αντίστροφη κατεύθυνση.
+Στο Subnet B το ICMP Echo Reply καταγράφηκε ως:
+
+\begin{minted}{text}
+2e:ef:81:65:2c:c9 > 7e:41:8e:cb:65:05
+ttl 64
+192.168.2.10 > 192.168.1.131
+ICMP echo reply, id 4650, seq 1
+\end{minted}
+
+Μετά την προώθησή του από τον \texttt{r0}, το ίδιο Reply εμφανίζεται στο Subnet A ως:
+
+\begin{minted}{text}
+ea:2e:7b:6d:78:82 > 4a:6f:2a:18:f4:80
+ttl 63
+192.168.2.10 > 192.168.1.131
+ICMP echo reply, id 4650, seq 1
+\end{minted}
+
+Η αντίστροφη πορεία επιβεβαιώνει το ίδιο αποτέλεσμα: οι IP διευθύνσεις παραμένουν σταθερές, οι MAC διευθύνσεις
+προσαρμόζονται στο εκάστοτε Layer-2 segment και το TTL μειώνεται κατά μία μονάδα κατά τη διέλευση από τον
+\texttt{r0}.
 
 
+\section{Συμπεράσματα}
 
+Στην παρούσα εργασία υλοποιήθηκε ένας γενικός builder δικτυακών τοπολογιών για το Mininet, βασισμένος σε μία
+δηλωτική γλώσσα περιγραφής σε JSON.
+Η σχεδίαση της DSL βασίστηκε στον διαχωρισμό της επιθυμητής τοπολογίας από τις λεπτομέρειες της εκτέλεσης και
+στην αντιστοίχιση των αφαιρέσεων της γλώσσας σε συγκεκριμένες δυνατότητες του Mininet και του Linux.
 
+Η υλοποίηση οργανώθηκε με \textbf{compiler-like αρχιτεκτονική}, στην οποία η αρχική περιγραφή περνά διαδοχικά
+από τα στάδια φόρτωσης, parsing, validation, planning και rendering.
+Ο διαχωρισμός αυτός επέτρεψε κάθε στάδιο να έχει σαφή ευθύνη, ενώ το \texttt{ExecutionPlan} λειτουργεί ως
+πλήρως επιλυμένη ενδιάμεση αναπαράσταση πριν από την παραγωγή του τελικού κώδικα.
+Το παραγόμενο \texttt{topology.generated.py} αποτελεί την εκτελέσιμη ``assembly'' της DSL και ταυτόχρονα ένα
+ανθρώπινα αναγνώσιμο artifact, το οποίο μπορεί να επιθεωρηθεί ανεξάρτητα πριν από την πραγματική εκτέλεση.
 
+Η τοπολογία της εργασίας δημιουργήθηκε αποκλειστικά από το αντίστοιχο \texttt{topology.json}, χωρίς να απαιτείται
+ειδική λογική στον builder για το συγκεκριμένο δίκτυο.
+Η ίδια περιγραφή χρησιμοποιήθηκε για την αυτόματη δημιουργία των hosts, switches και links, την παραμετροποίηση
+του router και την εκκίνηση της υπηρεσίας DHCP.
 
+Τα τρία πειράματα επέτρεψαν την παρατήρηση της λειτουργίας του δικτύου σε διαφορετικά επίπεδα.
+Στο πρώτο πείραμα καταγράφηκε η διαδικασία D.O.R.A. του DHCP και επιβεβαιώθηκε η απόκτηση δυναμικής διεύθυνσης
+από τον \texttt{h1}, καθώς και η broadcast φύση του αρχικού DHCP Request.
+Στο δεύτερο πείραμα παρατηρήθηκε η επίλυση μιας IPv4 διεύθυνσης σε MAC μέσω ARP, με broadcast Request και
+unicast Reply.
+Τέλος, στο τρίτο πείραμα καταγράφηκε το ίδιο ICMP Echo Request στις δύο πλευρές του router και επιβεβαιώθηκε
+πειραματικά ότι οι IP διευθύνσεις παραμένουν σταθερές end-to-end, ενώ οι MAC διευθύνσεις μεταβάλλονται
+hop-by-hop και το TTL μειώνεται κατά μία μονάδα κατά τη δρομολόγηση.
 
-\subsection{Συμπεράσματα}
+Ιδιαίτερη σημασία είχε το γεγονός ότι οι πραγματικές καταγραφές δεν περιορίστηκαν πάντα στην ελάχιστη
-...
+θεωρητική ακολουθία μηνυμάτων.
+Στο DHCP, για παράδειγμα, παρατηρήθηκε επαναμετάδοση του Discover πριν από την ολοκλήρωση της διαδικασίας, ενώ
+στο ARP εμφανίστηκε επιπλέον ανταλλαγή σχετική με τη διαχείριση του neighbor cache.
+Οι παρατηρήσεις αυτές δείχνουν τη διαφορά ανάμεσα στην αφαιρετική περιγραφή ενός πρωτοκόλλου και στη συμπεριφορά
+ενός πραγματικού δικτυακού stack.
 
-\section{Σύνοψη}
+Συνολικά, η εργασία συνέδεσε δύο διαφορετικά επίπεδα αφαίρεσης: από τη μία τη δηλωτική περιγραφή και αυτόματη
+κατασκευή της υποδομής και από την άλλη την παρατήρηση των πραγματικών πακέτων που παράγονται κατά τη λειτουργία
+της.
+Ο διαχωρισμός αυτός καθιστά τον builder επαναχρησιμοποιήσιμο για διαφορετικές τοπολογίες, ενώ παράλληλα
+διατηρεί τη δυνατότητα λεπτομερούς ελέγχου της συμπεριφοράς του δικτύου μέσω των συνηθισμένων εργαλείων Linux.
+Η ίδια αρχιτεκτονική μπορεί να επεκταθεί με νέα είδη services, περισσότερες παραμέτρους συνδέσμων ή διαφορετικά
+backend-specific settings, χωρίς να απαιτείται αλλαγή της βασικής ροής του builder.
 
-Τέλος, ...
 	
 \end{document}