Report: Added experiment 3 and conclusions
This commit is contained in:
+334
-4
@@ -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}
|
||||
|
||||
Reference in New Issue
Block a user