Διπλωματική Εργασία του φοιτητή του Τμήματος Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών της Πολυτεχνικής Σχολής του Πανεπιστημίου Πατρών

Transcript

1 ΠΑΝΕΠΙΣΤΗΜΙΟ ΠΑΤΡΩΝ ΤΜΗΜΑ ΗΛΕΚΤΡΟΛΟΓΩΝ ΜΗΧΑΝΙΚΩΝ ΚΑΙ ΤΕΧΝΟΛΟΓΙΑΣ ΥΠΟΛΟΓΙΣΤΩΝ ΤΟΜΕΑΣ:ΤΗΛΕΠΙΚΟΙΝΩΝΙΩΝ & ΤΕΧΝΟΛΟΓΙΑΣ ΠΛΗΡΟΦΟΡΙΑΣ ΕΡΓΑΣΤΗΡΙΟ ΕΝΣΥΡΜΑΤΗΣ ΤΗΛΕΠΙΚΟΙΝΩΝΙΑΣ ΤΗΣ Διπλωματική Εργασία του φοιτητή του Τμήματος Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών της Πολυτεχνικής Σχολής του Πανεπιστημίου Πατρών Ταρναρά Γεώργιου του Δημητρίου Αριθμός Μητρώου: 7388 Θέμα «Υλοποίηση και εκτέλεση αλγορίθμου βέλτιστης δρομολόγησης σε L2 δίκτυο με τεχνικές προγραμματιζόμενων δικτύων SDN» Επιβλέπων Επίκουρος Καθηγητής Σπύρος Δενάζης Αριθμός Διπλωματικής Εργασίας: Πάτρα, Σεπτέμβρης 2015

2 ΠΙΣΤΟΠΟΙΗΣΗ Πιστοποιείται ότι η Διπλωματική Εργασία με θέμα «Υλοποίηση και εκτέλεση αλγορίθμου βέλτιστης δρομολόγησης σε L2 δίκτυο με SDN τεχνικές» Του φοιτητή του Τμήματος Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών Ταρναρά Γεώργιου του Δημητρίου Αριθμός Μητρώου: 7388 Παρουσιάστηκε δημόσια και εξετάστηκε στο Τμήμα Ηλεκτρολόγων Μηχανικών και Τεχνολογίας Υπολογιστών στις.../../ Ο Επιβλέπων: Ο Διευθυντής του Τομέα: κ. Σπύρος Δενάζης Eπίκουρος Καθηγητής κ. Νικόλαος Φακωτάκης Καθηγητής 2

3 Αριθμός Διπλωματικής Εργασίας: Θέμα: «Υλοποίηση και εκτέλεση αλγορίθμου βέλτιστης δρομολόγησης σε L2 δίκτυο με SDN τεχνικές» Φοιτητής: Επιβλέπων: 3

4 Ευχαριστώ ιδιαίτερα, Τον καθηγητή μου κ.σ.δενάζη για την αμέριστη βοήθεια που μου παρείχε το χρονικό διάστημα εκπόνησης της διπλωματικής μου εργασίας. Τον διδακτορικό ερευνητή Ε.Χαλεπλίδη για την καθοδήγηση, υπομονή και στήριξή του απέναντι μου. Την Οικογένειά μου και την Κωνσταντίνα για την πίστη τους και την συμπαράστασή τους καθ'όλη την διάρκεια των σπουδών μου και κατά την εκπόνηση της διπλωματικής μου εργασίας. 4

5 ΠΕΡΊΛΗΨΗ Ένα από τα προβλήματα σε ένα layer 2 δίκτυο λόγω της χρήσης του Spanning Tree Protocol (STP) είναι η μη χρησιμοποίηση όλων των διαθέσιμων συνδέσεων μεταξύ των δικτυακών συσκευών για την αποφυγή κλειστών βρόγχων. Τελευταία υπάρχει μία ραγδαία εξέλιξη των προγραμματιζόμενων δικτύων με έναν νέο τίτλο, αυτόν του Software-Defined Networking (SDN), που προτείνει ένα καινοτόμο πλαίσιο δημιουργίας δικτύων, αποσυνδέοντας την διαδικασία της μετακίνησης των πακέτων από την διαδικασία της απόφασης δρομολόγησης. 'Ήδη αρκετοί οργανισμοί έχουν ξεκινήσει να ακολουθούν αυτήν την τεχνολογία σε μια προσπάθεια κεντρικοποιημένης προσέγγισης στην υλοποίηση των δικτύων τους. Σε SDN δίκτυα, η δυναμική και βέλτιστη ανακάλυψη της τοπολογίας είναι πρωταρχικής σημασίας, έτσι ώστε η ολοένα και αυξανόμενη κίνηση να μπορεί να διαχειριστεί αποδοτικότερα. Το OpenFlow που αποτελεί το επικρατέστερο πρωτόκολλο στο SDN μέχρι σήμερα υιοθετεί μια υποβέλτιστη λύση στην ανακάλυψη της τοπολογίας του δικτύου, ανταλλάσσοντας περιοδικά LLDP μηνύματα μεταξύ των στοιχείων ελέγχου και προώθησης. Σκοπός αυτής της διπλωματικής είναι να υπαγορεύσουμε σε προγραμματιζόμενα switches ενός τοπικού δικτύου βέλτιστες δρομολογήσεις πακέτων, χρησιμοποιώντας ευρέως διαδεδομένους αλγορίθμους δρομολόγησης (π.χ. Dijkstra) δημιουργώντας παράλληλα μια εφαρμογή για την διαχείρισή τους. Για την επίτευξη αυτού του στόχου δημιουργήθηκε ένας βέλτιστος αλγόριθμος για την ανακάλυψη της τοπολογίας του δικτύου κάνοντας χρήση του πρωτοκόλλου LLDP διαφορετικά από το OpenFlow, ώστε η δρομολόγηση να γίνεται δυναμικά. Η εφαρμογή βασισμένη σε SDN τεχνικές θα ενημερώνεται από τα switches για τους γείτονές τους και θα δημιουργεί μία τοπολογία του δικτύου την οποία θα χρησιμοποιούν οι όποιοι αλγόριθμοι δρομολόγησης, χωρίς την ανάγκη να αποκόπτονται ζεύξεις για την αποφυγή κλειστών βρόχων. Με τον τρόπο αυτό επιτυγχάνεται πλήρη εποπτεία και αποδοτική χρησιμοποίηση των διαθέσιμων πόρων του δικτύου αυξάνοντας σημαντικά όχι μόνο την απόδοση, αλλά και λειτουργικότητά του. 5

6 ABSTRACT One problem of a layer 2 network using the Spanning Tree Protocol (STP) is not using all the available nodes for avoiding the creation of closed loops. Software-defined Networking proposes an alternative paradigm on network programmability based on the separation of the control and forwarding planes. Many leading organizations have already adopted such techniques, based on OpenFlow or other protocols, to efficiently modify and determine their traffic datapath in a centralized fashion. Discovering network elements in a dynamic and optimized manner, able to cope with the ever-growing network traffic is a key requirement for SDN networks, in order to ensure a data center's robustness and manageability. OpenFlow's approach for creating the topology map is by periodically exchanging LLDP frames between the controller and the forwarding elements. However, a better method may be implemented so as to efficiently and faster acquire any topology changes and the topology map in general. This thesis proposes an optimal usage of LLDP by taking advantage of the existing hardware capabilities so as to extract information directly from the data plane. Those information are then being transferred towards the Control Plane in order to construct the topology map and to apply a dynamic and automatic topology discovery algorithm. Having defined the topology map and using the IETF's ForCES Framework, we managed to model a generic method for updating and extracting the required topology information from the datapath to the controller. Afterwards, an application capable controlling these programmable switches is able to dictate them optimal routes using some well known routing algorithms. 6

7 Πίνακας Περιεχομένων... 1 Περίληψη... 5 Abstract... 6 Εισαγωγή ΕΝΌΤΗΤΑ Προαπαιτούμενες γνώσεις ROUTING & SWITCHING...14 OSI Layers Switch ή Μεταγωγέας Δομή και λειτουργία του switch:...17 Τοπολογίες με Switches Εφεδρεία και επάρκεια πόρων (Redundancy)...19 Spanning Tree Protocol Λειτουργία-δυνατότητες Μειονεκτήματα Router ή Δρομολογητής Η διαδικασία της δρομολόγησης...23 Φάσεις λειτουργίας Κλασσικοί αλγόριθμοι δρομολόγησης...25 Κατηγορίες πρωτοκόλλων δρομολόγησης...25 Dijkstra's Algorithm Bellman-Ford Algorithm SOFTWARE-DEFINED NETWORKING...28 Η άνοδος του Cloud computing έξυπνες συσκευές...28 Προγραμματιζόμενα δίκτυα Ορισμός προγραμματιζόμενων δικτύων ή SDN...30 NEIGHBOR DISCOVERY PROTOCOLS

8 Ορισμός τοπολογίας δικτύου...32 Μέθοδοι & πρωτόκολλα κατασκευής τοπολογίας...33 Link Layer Discovery Protocol LLDP...35 Frame structure Δομή TLV Πληροφορίες που συλλέγουμε Εφαρμογές του LLDP OpenFlow Protocol OpenFlow switch OpenFlow tables OpenFlow topology discovery...45 ForCES ForCES Framework Δομικά στοιχεία του ForCES...47 ForCES model Logical Function Blocks Metadata LFB Outputs & Inputs Core LFBs Logical Function Blocks Definitions...53 ForCES Protocol Καταστάσεις λειτουργίας ForCES...57 ΕΝΌΤΗΤΑ Αλγόριθμος βέλτιστης ανακάλυψης τοπολογίας σε δίκτυο sdn με χρήση του forces Βέλτιστη ανακάλυψη τοπολογίας με την χρήση του ForCES...60 Προτεινόμενη μέθοδος

9 Διαδικασία ανακάλυψης νέου κόμβου...62 Διάγραμμα ροής Αποτελέσματα προτεινόμενης μεθόδου...69 Επαναπροσδιορισμός των δρομολογήσεων...70 Συμπεράσματα & Μελλοντική Έρευνα...71 ΕΝΌΤΗΤΑ Παράθεση και επεξήγηση κώδικα υλοποίησης...72 Συνοπτική επεξήγηση κώδικα...73 Οπτική του fe Οπτική του controller...74 ForCES model To ForCES model που χρησιμοποιήθηκε...75 Υλοποίηση του Controller Υλοποίηση κύριας συνάρτησης και χειρισμός συνδέσεων...78 Υλοποίηση του μηχανισμού των events μεταξύ CE-FE...81 Ηeader αρχείο που περιέχει απαραίτητες μεταβλητές και πίνακες...85 Υλοποίηση του cli με την δυνατότητα εισαγωγής εντολών...88 Υλοποίηση των συναρτήσεων εντολών...91 Υλοποίηση των δρομολογήσεων και της κατασκευής της τοπολογίας Υλοποίηση του fe Εκκίνηση ελέγχου εισερχόμενης κίνηση από τα NIC Υλοποίηση του interface του FE Ηeader αρχείο που περιέχει απαραίτητες μεταβλητές και πίνακες Υλοποίηση συναρτήσεων αλληλεπίδρασης με το CE Συναρτήσεις χειρισμού εντολών και αποθήκευσης τοπικών στατιστικών ΠΑΡΆΡΤΗΜΑ

10 Α. Εικονικοποίηση Λειτουργιών Δικτύου - Network Function Virtualization Β. Εικονική μηχανή Virtual Machine Πηγές Βιβλιογραφία

11 ΕΙΣΑΓΩΓΉ Η παρούσα διπλωματική εργασία εκπονήθηκε στο εργαστήριο Αρχιτεκτονικής και Διαχείρισης Δικτύων του τμήματος Ηλεκτρολόγων Μηχανικών & Τεχνολογίας Υπολογιστών της Πολυτεχνικής σχολής του Πανεπιστημίου Πατρών. Στόχος της εργασίας είναι η υλοποίηση και ο σχεδιασμός μιας εφαρμογής η οποία επιτρέπει την βέλτιστη ανακάλυψη της τοπολογίας του δικτύου και της δρομολόγησης των πακέτων σε ένα layer 2 δίκτυο που χρησιμοποιεί προγραμματιζόμενα switches. Το κείμενο έχει χωριστεί σε 3 ενότητες. Στην πρώτη ενότητα παρέχεται το θεωρητικό υπόβαθρο που χρειάζεται ο αναγνώστης για να κατανοήσει την νέα αυτή αρχιτεκτονική των προγραμματιζόμενων δικτύων ή SDN. Στην δεύτερη ενότητα, που ασχολείται με την μεθοδολογία, την διαδικασία και την λογική που ακολουθήθηκε ώστε να επιτευχθεί το ζητούμενο, και την τρίτη ενότητα, όπου εξηγείται αναλυτικά ο κώδικας και το μοντέλο που χρησιμοποιήθηκε για την υλοποίηση. Ακολουθεί μια σύντομη περιγραφή των περιεχομένων της πρώτης ενότητας. Στην πρώτη ενότητα αρχικά γίνεται παρουσίαση των βασικών εννοιών της δρομολόγησης με κάποια παραδείγματα και πως μπορούν να προσαρμοστούν σε δίκτυα SDN λογικής. Ειδικότερη αναφορά γίνεται στον αλγόριθμο Dijkstra, τον οποίο και χρησιμοποιήσαμε για να επιτύχουμε βέλτιστες δρομολογήσεις σε ένα προγραμματιζόμενο δίκτυο. Ο αναγνώστης εισάγεται στον νέο τρόπο διαχείρισης και κατασκευής δικτύων, αυτόν των προγραμματιζόμενων και ενεργών στοιχείων. Γίνεται μια σύντομη ιστορική αναδρομή και περιγράφονται οι ανάγκες που ουσιαστικά οδήγησαν σε αυτόν τον νέο σχεδιασμό. Περνώντας στο σήμερα περιγράφονται βασικοί ορισμοί και πλεονεκτήματα που καθιστούν αυτή την τεχνολογία σημαντική και παρουσιάζονται απαραίτητες έννοιες για την κατανόηση της ανακάλυψης τοπολογίας ενός δικτύου και του σχεδιασμού της εφαρμογής που δημιουργήθηκε στην παρούσα εργασία. Στο τέλος αναφέρονται τα πρωτόκολλα OpenFlow και ForCES το οποίο και χρησιμοποιήσαμε. Περιγράφονται πλεονεκτήματα και μειονεκτήματα κάθε πρωτοκόλλου και αναλύεται η διαδικασία ανακάλυψης της τοπολογίας ανά περίπτωση. Στην δεύτερη ενότητα παρουσιάζεται αναλυτικά η διαδικασία επίλυσης του προβλήματος. Περιγράφονται τα βήματα του αλγορίθμου που δημιουργήθηκε καθώς γίνεται και η επίδειξη της εφαρμογής μέσω της οποίας μπορούμε να ελέγξουμε τα switches. Παρουσιάζονται τέλος τα συμπεράσματα 11

12 στα οποία προβήκαμε ύστερα από την διαδικασία εκτέλεσης μετρήσεων σε ένα δίκτυο μικρής κλίμακας. Υπάρχουν αξιόλογα αποτελέσματα στον χρόνο που το δίκτυο αντιλαμβάνεται τις αλλαγές στην τοπολογία και ενημερώνει κατάλληλα τα switches για να τροποποιήσουν τις διαδρομές τους όσον αφορά το μονοπάτι των δεδομένων. Κλείνοντας την ενότητα θίγονται τα πλεονεκτήματα που μπορούμε να έχουμε ακολουθώντας μια παρόμοια φιλοσοφία ανακάλυψης τοπολογίας δικτύου σε σχέση με τις υπάρχουσες τεχνικές, και γίνεται αναφορά σε μελλοντικές προτάσεις για έρευνα. Στην τρίτη και τελευταία ενότητα γίνεται παράθεση και περιγραφή του κώδικα που χρησιμοποιήσαμε για να υλοποιήσουμε τον προτεινόμενο αλγόριθμο καθώς επίσης και του μοντέλου που χρησιμοποιήθηκε. 12

13 ΕΝΌΤΗΤΑ 1 ΠΡΟΑΠΑΙΤΟΎΜΕΝΕΣ ΓΝΏΣΕΙΣ 13

14 ROUTING & SWITCHING Η δρομολόγηση αποτελεί την πιο κοινή λειτουργιά αλλά και την πιο αναγκαία για να μπορέσει ένα δίκτυο (ανεξαρτήτου κλίμακας) να λειτουργήσει και οι χρήστες του να είναι σε θέση να επικοινωνήσουν. Αυτή η ανάγκη, που δημιουργήθηκε για την ορθή προώθηση των πακέτων που στέλνουμε στους τελικούς χρήστες ή σε άλλα δίκτυα, οδήγησε στην εφαρμογή και ανάπτυξη διάφορων αλγορίθμων ικανών να προσαρμόζονται κάθε φορά στις εκάστοτε ανάγκες. Στο παρελθόν ο όρος δρομολόγηση σήμαινε απλά την προώθηση της κίνησης από ένα δίκτυο σε ένα άλλο, το γνωστό πλέον forwarding (προώθηση). Σαν λειτουργία υπήρχε και χρησιμοποιείτο από τις πρώτες μορφές δικτύων, κλασσικών (circuit switched) ή σύγχρονων(packet switched). OSI Layers Πριν αναφερθούμε ειδικότερα στους αλγόριθμους δρομολόγησης και τα διάφορα δομικά στοιχεία που απαρτίζουν ένα δίκτυο ας παρουσιάσουμε κάποιες βασικές έννοιες όσον αφορά τα επίπεδα του δικτύου ώστε να κατανοήσουμε πλήρως που λαμβάνει χώρα κάθε λειτουργία του δικτύου. Η σύνηθες περιγραφή γίνεται με το μοντέλο αναφοράς OSI (Open Systems Interconnection model) ή αλλιώς μοντέλο αναφοράς Ανοικτής Διασύνδεσης Συστημάτων. Το μοντέλο OSI αποτελείται από 7 διασυνδεδεμένα μεταξύ τους επίπεδα με την μορφή μιας στοίβας όπως περιγράφεται στην εικόνα 1 παρακάτω. Εικόνα 1 Τα επίπεδα του OSI 14

15 Αναφορικά τα 7 αυτά επίπεδα σε μια προσέγγιση από κάτω προς τα πάνω είναι τα εξής : 1. Φυσικό - Physical 2. Ζεύξης Δεδομένων - Data link 3. Δικτύου - Network 4. Μεταφοράς - Transport 5. Συνόδου - Session Παρουσίασης - Presentation Εφαρμογών - Application Οι λειτουργίες που μας ενδιαφέρουν όσον αφορά τις λειτουργίες δρομολόγησης και μεταγωγής υφίστανται μέχρι το 3ο επίπεδο, δηλαδή το επίπεδο δικτύου (μεσαίο επίπεδο του σχήματος). Συγκεκριμένα η λειτουργία μεταγωγής switching εκτελείται στο δεύτερο επίπεδο, αυτό της ζεύξης δεδομένων. Η δρομολόγηση αποτελεί λειτουργία τρίτου επιπέδου και οι όποιοι αλγόριθμοι και πρωτόκολλα που σχετίζονται με αυτήν την λειτουργία υλοποιούνται σε αυτό το επίπεδο. Υπάρχουν βέβαια και κάποια switches τα οποία μπορούν να επεμβαίνουν και να εκτελούν λειτουργίες επιπέδου 3 στο OSI. Η βασική διαφορά αυτών με τους δρομολογητές είναι ότι χρησιμοποιούν υλικό ειδικού σκοπού (applicationspecific integrated circuit - ASIC) για την υλοποίηση αυτών των λειτουργιών αντί για λογισμικό που τρέχει πάνω από έναν μικροεπεξεργαστή. 15

16 Switch ή Μεταγωγέας Είναι μια L2 δικτυακή συσκευή που χρησιμοποιείται στα δίκτυα υπολογιστών για την δημιουργία τοπικών δικτύων LAN προκειμένου να προωθούνται τα πακέτα σε διάφορους προορισμούς (τερματικές συσκευές, άλλα δίκτυα κλπ.). Συνδέει δηλαδή δύο ή περισσότερα τμήματα LAN (LAN segments) και παίρνει αποφάσεις για το αν θα προωθήσει την κίνηση από το ένα segment στο άλλο. Ουσιαστικά είναι μια τεχνολογία η οποία συνδυάζει τεχνολογίες που επεκτείνουν τις τεχνολογίες των γεφυρών (bridges). To πρώτο Ethernet switch κατασκευάστηκε από την εταιρεία Kalpana, που έδρευε στη SiliconValley το H ίδια εταιρεία δημιούργησε και την τεχνολογία EtherChannel η οποία επιτρέπει την αύξηση του εύρους ζώνης των εσωτερικών συνδέσεων του switch τρέχοντας παράλληλα πολλαπλά link. Για την ιστορία η εταιρεία αυτή εξαγοράστηκε από την Cisco το Σαν συσκευή, το switch περιέχει περισσότερη δικτυακή ευφυΐα από το hub καθώς είναι σε θέση να εκτελεί κάποια βασική επεξεργασία των frames και να πραγματοποιεί matching μεταξύ της mac διεύθυνσης της συσκευής που είναι προσαρτημένη πάνω σε κάποιο port αυτού. Με τον τρόπο αυτό ένα switch δεν χρειάζεται να κάνει broadcast όλα τα πακέτα που περνάνε από τα interfaces του μειώνοντας τα collision domains και αυξάνοντας ταυτόχρονα το διαθέσιμο εύρος ζώνης στον τελικό χρήστη. Αξίζει να σημειωθεί ότι ορισμένα switch έχουν και την δυνατότητα εκτέλεσης λειτουργιών δρομολόγησης επιπέδου 3 στο OSI Μοdel. Αυτά είναι γνωστά και σαν πολυεπίπεδα switches ή όπως συνηθίζεται multilayer switches και η χρήση τους συναντάται κυρίως σε περιβάλλοντα SOHO και περεταίρω. 16

17 Μια σημαντική διαφορά τους με τα κλασσικά router που θα αναλύσουμε αργότερα είναι ότι εκτελούν τις διαδικασίες της δρομολόγησης χρησιμοποιώντας hardware ειδικού σκοπού γνωστού και ως ASIC (applicationspecific integrated circuit), ενώ ένας router εκτελεί την δρομολόγηση μέσω software που τρέχει πάνω σε έναν microprocessor. Aς δούμε όμως αναλυτικότερα την δομή και την λειτουργία ενός κλασσικού switch (Εικόνα 2). Εικόνα 2 Interfaces ενός δρομολογητή Δομή και λειτουργία του switch: Όπως ήδη αναφέραμε ο μεταγωγέας μπορεί να αναλυθεί στα δομικά του στοιχεία ως μια γέφυρα με πολλές πόρτες (multiport bridge). Αναφορικά γέφυρες είναι ηλεκτρονικές συσκευές που υλοποιούν τη διασύνδεση και επικοινωνία μεταξύ τοπικών δικτύων υπολογιστών στο επίπεδο σύνδεσης L2 ή data link layer. Ένας δικτυακός μεταγωγέας (switch) αποτελεί τον κορμό του δικτύου και εκτελεί κάποιες πιο σύνθετες λειτουργίες αφού είναι σε θέση να επεξεργάζεται και εκτελεί τις εξής λειτουργίες, δηλαδή filtering, forwarding και flooding όσον αφορά πλαίσια Ethernet. Για αυτές τις διαδικασίες βασίζεται στην διεύθυνση προορισμού που περιέχεται στην κεφαλίδα του πλαισίου κάθε φορά. Έπειτα με βάση έναν πίνακα διευθύνσεων MAC προωθεί στα αντίστοιχα ports τα πακέτα. Ποια είναι όμως η λειτουργία που επιτρέπει σε ένα switch να μαθαίνει τις διευθύνσεις; 17

18 Εικόνα 3 Αντιστοίχηση Host με Interfaces Η διαδικασία είναι απλή. Το switch κάθε φορά που ένα πακέτο στέλνεται σε οποιαδήποτε από τις πόρτες του, εξετάζει την κεφαλίδα του πλαισίου όπου περιγράφεται η MAC του αποστολέα και της διεύθυνσης προορισμού. Όταν μια νέα διεύθυνση συναντάται, ο πίνακας ανανεώνεται δυναμικά αποθηκεύοντας την νέα διεύθυνση κάνοντας παράλληλα την απαραίτητη συσχέτιση με την πόρτα από όπου ήρθε το πακέτο. Με αυτόν τον τρόπο το switch μαθαίνει γρήγορα όλες τις L2 διευθύνσεις των hosts που είναι προσαρτημένοι πάνω του. Στο παρακάτω σχήμα (4) φαίνεται ένας τυπικός πίνακας (mac table) που συναντάμε σε ένα switch. Σχήμα 4 Tυπικός πίνακας MAC δ/νσεων Έχοντας δημιουργήσει τον πίνακα διευθύνσεων μπορούμε πλέον να εκτελέσουμε και κάποιες πρόσθετες λειτουργίες στα πλαίσια (frames) που διαχειριζόμαστε. Για παράδειγμα μπορούμε να μπλοκάρουμε διευθύνσεις τις οποίες δεν αναγνωρίζουμε στον πίνακα που έχουμε κλπ. 18

19 Τοπολογίες με Switches Εφεδρεία και επάρκεια πόρων (Redundancy) Στην πράξη κάθε φορά που εγκαθιστούμε ένα δίκτυο χρησιμοποιούμε πάντα (η τουλάχιστον θα έπρεπε πάντα) ζεύγη από συσκευές. Με τον τρόπο αυτό θωρακίζουμε το δίκτυό μας από πιθανά προβλήματα και διακοπές που μπορούν να προκύψουν, εξασφαλίζοντας παράλληλα υψηλή αξιοπιστία (high availability) στην υπηρεσία που παρέχεται στον τελικό χρήστη. Η σύνδεση αυτή που επιτρέπει τον πλεονασμό των δικτυακών συσκευών συνηθίζεται να αποκαλείται redundant topology και είναι πολύ σημαντική στον σχεδιασμό οποιοδήποτε δικτύου. Υπάρχει όμως ένα σημαντικό μειονέκτημα σε αυτή την συνδεσμολογία, αφού αυτό το extra link, πρακτικά δημιουργεί ένα κλειστό βρόχο με το γειτονικό του switch και μπορεί να οδηγήσει τα πακέτα να κινούνται ατέρμονα μεταξύ των switches (switching loops). Μια τέτοια κατάσταση είναι πολύ επιβλαβής για το δίκτυο αφού σταδιακά τα πακέτα που είναι σε loop θα καταναλώσουν το 100% του διαθέσιμου εύρου ζώνης (bandwidth) καθιστώντας ασύμφορο το δίκτυο. Ένα ακόμα πρόβλημα που μπορούμε να έχουμε σε switched-based δίκτυα είναι τα μηνύματα πολυεκπομπής (multicast) που πρέπει να προωθηθούν σε όλους τους κόμβους μέσα στο δίκτυο. Όταν ένα switch λάβει ένα μήνυμα broadcast είναι υποχρεωμένο να το προωθήσει σε όλες τις πόρτες του. Αυτή η διαδικασία θα εκτελεστεί σε όλα τα διαδοχικά συνδεδεμένα switches και λόγω του κλειστού βρόχου που υπάρχει (redundant loop) ένα μόνο broadcast frame θα είναι ικανό να δημιουργήσει τεράστια και μη διαχειρίσιμη κίνηση στο δίκτυο. Σχήμα 5 Η περίπτωση του broadcast storm 19

20 Προσεγγίζοντας το πρόβλημα με την κλασσική λογική των δικτύων, οφείλουμε να εφαρμόσουμε ένα πρωτόκολλο που λέγεται Spanning Tree Protocol και ουσιαστικά αποτρέπει τα πακέτα να δημιουργήσουν ατέρμονους βρόχους στο δίκτυο. Η λύση αυτή αν και συνηθίζεται στα σημερινά δίκτυα, δεν είναι βέλτιστη αφού δεν αξιοποιούμε αποδοτικά όλους τους διαθέσιμους πόρους του δικτύου μας. Η λύση σε αυτό το πρόβλημα αποτέλεσε και το έναυσμα για την εκπόνηση αυτής της διπλωματικής εργασίας. Αφού λοιπόν αναλύσουμε τον τρόπο λειτουργίας του STP και καταδείξουμε τα μειονεκτήματά του θα παρουσιαστεί έπειτα η λύση που δόθηκε στην παρούσα διπλωματική χρησιμοποιώντας μια SDN λογική αξιοποιώντας όλους τους διαθέσιμους πόρους αλλά και μειώνοντας το αυξημένο overhead από την συνεχή χρήση του πρωτοκόλλου. Spanning Tree Protocol Το STP όπως ήδη έχουμε αναφέρει είναι ένα πρωτόκολλο το οποίο εξασφαλίζει την αποφυγή κλειστών βρόχων μέσα σε ένα οποιοδήποτε switched-based Ethernet δίκτυο. H ιδέα του πρωτοκόλλου ανήκει στην Dr.Radia Perlman, μηχανικό της Sun Microsystems. Η Perlman επινόησε μια μέθοδο με την οποία τα bridges σε ένα L2 μπορούν να αποκτήσουν δυνατότητες δρομολόγησης. Η ιδέα στηριζόταν σε ένα επεκταμένο δέντρο όπου κάθε γέφυρα (bridge) μπορεί να κρατάει στην μνήμη της στοιχεία που αφορούν βέλτιστες και προβληματικές διαδρομές προώθησης των πακέτων. Λειτουργία-δυνατότητες Το STP παρέχει ένα τρόπο αποφυγής βρόχων αποκόπτοντας links σε ένα δίκτυο Ethernet. Αυτά τα link μπορούν έπειτα να χρησιμοποιηθούν εάν μια ενεργή ζεύξη τεθεί εκτός λειτουργίας. Η ρίζα του δέντρου σε ένα επεκταμένο δέντρο είναι το λογικό κέντρο της τοπολογίας και μπορεί να δει όλη την κίνηση που ανταλλάσσεται. Οι υπολογισμοί πραγματοποιούνται αυτόματα στις αλλαγές του δικτύου αλλά μπορεί να προκαλέσει προσωρινή διακοπή δικτύου. Νεότερα πρωτόκολλα, όπως το Trill ή το SPB, αποφεύγει τους βρόχους διατηρώντας ταυτόχρονα τα links που μπορεί να μπλοκάρονταν. 20

21 Σχήμα 6 Ο γράφος που δημιουργεί το STP Αν τα switches είναι συνδεδεμένα σε κλειστό βρόχο (redundancy) τότε καθένα από αυτά θα προωθήσει ξανά το πρώτο πακέτο broadcast που θα λάβει καθώς δεν θα υπάρχει κάποιος L2 μηχανισμός να το αποτρέψει. Το STP όμως εκτελεί αυτή την λειτουργία και αποκόπτει το ένα link (redundant) για την αποφυγή δημιουργίας βρόχου. Με αυτόν τον τρόπο, σε περίπτωση διακοπής θα γίνει το switchover από το primary στο redundant ώστε να έχουμε συνδεσιμότητα. Ο τρόπος με τον οποίο το πρωτόκολλο αποφασίζει ποιο μονοπάτι θα επιλεγεί για την κίνηση των πακέτων εξαρτάται από την τοπολογία, την οποία και είναι σε θέση να 'βλέπει'. Η ιδέα πίσω από το spanning tree είναι ότι κάθε bridge ανακαλύπτει ένα υποσύνολο της τοπολογίας η οποία θα είναι απαλλαγμένη από κλειστούς βρόχους. Ας δούμε όμως ποια είναι τα βήματα εκτέλεσης του αλγόριθμου. Αρχικά, τα switch εκτελούν το STP την πρώτη φορά που αυτά συνδέονται στο δίκτυο ή κάθε φορά που η τοπολογία αλλάζει. Όταν λάβουν από κάποιο γειτονικό switch ένα ειδικού τύπου (configuration) BPDU (Bridge Protocol Data Unit), ξεκινάει η εκτέλεση του αλγορίθμου και ο υπολογισμός του επεκταμένου δέντρου. Η διαδικασία αυτή ξεκινάει εκλέγοντας την λεγόμενη root bridge όπου μέσω αυτής θα περνάει όλη η κίνηση (σχήμα 6). Το επόμενο βήμα για κάθε bridge είναι να καθορίσει το κοντινότερο μονοπάτι προς την ρίζα έτσι ώστε να γνωρίζει πώς να φτάσει σε αυτή βάση της δημιουργούμενης τοπολογίας. Έπειτα μια δεύτερη εκλογή συμβαίνει σε κάθε LAN ξεχωριστά, όπου εκεί επιλέγεται η γέφυρα που είναι πιο κοντά στην ρίζα της κεντρικής τοπολογίας. Αυτή η γέφυρα αναλαμβάνει τον ρόλο της προώθησης όλων των πακέτων που λαμβάνονται προς την ρίζα. 21

22 Το τελευταίο βήμα της διαδικασίας είναι να επιλέξουμε σε κάθε bridge μια ριζική πόρτα (root port). Με απλά λόγια επιλέγεται η πόρτα με την οποία θα στέλνονται τα δεδομένα στην ριζική γέφυρα. Κάθε γέφυρα την οποία συνδέουμε στην υπάρχουσα τοπολογία από το σημείο αυτό και έπειτα θα στέλνει ένα reconfiguration BPDU, και οι άλλες συσκευές θα ακολουθούν την διαδικασία που περιγράψαμε. Όλη αυτή η κίνηση σταματάει μετά από 30 με 50 δευτερόλεπτα, όσο δηλαδή διαρκεί ο υπολογισμός του επεκταμένου δέντρου. Συνοψίζοντας την διαδικασία μπορούμε να περιγράψουμε τον αλγόριθμο με τα επόμενα 3 βήματα: 1. Ανταλλαγή BPDU μηνυμάτων μεταξύ των switch για να συμφωνήσουν ποια θα είναι η root bridge. 2. Aφού εκτελεστεί το βήμα 1 και ο ριζικός κόμβος έχει καθοριστεί, κάθε switch ξεχωριστά πρέπει να αποφασίσει με ποιες πόρτες (ports) θα επικοινωνεί με την root bridge. 3. Τέλος, γίνεται ο ορισμός των ports τα οποία θα χρησιμοποιούνται έτσι ώστε να έχουμε μόνο ένα ενεργό μονοπάτι προς κάθε κομμάτι/στοιχείο του δικτύου. Μειονεκτήματα Όπως ήδη έχουμε αναφέρει προηγουμένως το STP είναι ένα πρωτόκολλο το οποίο ναι μεν λύνει το πρόβλημα των κλειστών βρόχων αλλά η επιτυχία του οφείλεται σε μια υποβέλτιστη λύση αφού δεν χρησιμοποιεί ενεργά όλους τους διαθέσιμους πόρους του δικτύου. Ακόμα με την εξέλιξη των δικτύων και την έρευνα για ολοένα και πιο αποδοτικές και ευέλικτες/προσαρμόσιμες λύσεις διαφαίνεται η ανάγκη για επίλυση του προβλήματος με έναν αποδοτικότερο και καινοτόμο τρόπο. Αυτός ο τρόπος είναι με την χρήση προγραμματιζόμενων δικτύων ή SDN που θα δούμε παρακάτω. Αργότερα, στο κεφάλαιο 2 αναλύεται η μέθοδος-λύση που προτείνεται στην παρούσα διπλωματική και παρουσιάζεται ο τρόπος όπου μπορούμε να χρησιμοποιούμε αποδοτικά όλους τους κόμβους μειώνοντας παράλληλα κατά πολύ τις καθυστερήσεις. 22

23 Router ή Δρομολογητής Είναι μια L3 δικτυακή συσκευή που χρησιμοποιείται στα δίκτυα υπολογιστών για την δρομολόγηση πακέτων μεταξύ αυτόνομων και απομακρυσμένων δικτύων με βέλτιστο τρόπο. Ένας δρομολογητής είναι πάντα συνδεδεμένος σε 2 ή περισσότερες γραμμές διαφορετικών δικτύων. Όταν ένα πακέτο έρχεται σε μια από αυτές τότε ο δρομολογητής διαβάζει την διεύθυνση προορισμού ώστε να το προωθήσει κατάλληλα στον τελικό του προορισμό. Προκειμένου να το επιτύχει αυτό χρησιμοποιεί κάποιους εσωτερικούς πίνακες που ονομάζονται πίνακες δρομολόγησης ή όπως συνηθίζεται routing tables και εκεί είναι καταγεγραμμένοι όλοι οι πιθανοί προορισμοί που μπορούν να επακολουθήσουν τα πακέτα για να φτάσουν στον τελικό προορισμό. Η διαδικασία αυτή ονομάζεται δρομολόγηση. Η διαδικασία της δρομολόγησης Με τον όρο δρομολόγηση εννοούμε την διαδικασία εκμάθησης της βέλτιστης διαδρομής, την οποία πρέπει να ακολουθήσει ένα πακέτο ώστε να φτάσει στον τελικό προορισμό. Η μεθοδολογία που ακολουθείτε καθορίζεται από τον αλγόριθμο και το πρωτόκολλο δρομολόγησης που υλοποιείται στους routers προκειμένου να ανταλλάσσουν μεταξύ τους πληροφορίες σχετικές με την τοπολογία που συμμετέχουν. Η γνώση της τοπολογίας δίνει στους δρομολογητές την δυνατότητα να επιλέγουν την βέλτιστη διαδρομή με βάση κάποια κριτήρια. Τα κριτήρια αυτά μπορεί να είναι τα hops μεταξύ του επόμενου δρομολογητή, η ταχύτητα της ζεύξης (gigabit, fastethernet) κ.α. Είναι σημαντικό να αναφέρουμε ότι κάθε δρομολογητής συμβουλεύεται τον δικό του routing table για να αποφασίσει που θα προωθήσει κάποιο πακέτο, μπορεί όμως να ανταλλάσσει και πληροφορίες σχετικά με διαδρομές με γειτονικές συσκευές μέσω κάποιου πρωτοκόλλου που επιτρέπει αυτού του είδους το advertising. 23

24 Σχήμα 7 Επίπεδα λειτουργιών συσκευής προώθησης Η διαδικασία αυτή ονομάζεται hop-by-hop destination-based unicast routing και χρησιμοποιείται κατά κόρον στις σύγχρονες αρχιτεκτονικές δικτύων. Φάσεις λειτουργίας Ο δρομολογητής σαν συσκευή υλοποιεί 2 συγκεκριμένες φάσεις λειτουργίας, αυτές του ελέγχου (control) και της προώθησης (forward) του πακέτου. Συνηθίζεται να αναφερόμαστε σε αυτά τα 2 δομικά συστατικά της δρομολόγησης σαν 2 αυτόνομα αλλά και άμεσα εξαρτώμενα επίπεδα τα οποία είναι αναγκαίο αλλά όχι και απαραίτητο να συνεργάζονται ώστε να πραγματοποιούμε βέλτιστες δρομολογήσεις μεταξύ δικτύων. Ας δούμε όμως λίγο αναλυτικότερα αυτά τα 2 στάδια: Control Plane: Πρόκειται για το επίπεδο το οποίο επεξεργάζεται και αναλύει όλες τις πληροφορίες που έχουν συλλεχθεί σχετικά με τις διαθέσιμες διαδρομές. Μετά από αυτή την διαδικασία είναι σε θέση να δημιουργεί τις κατάλληλες πληροφορίες τις οποίες και θα περάσει στο Forwarding Plane ώστε να επιτυγχάνεται η προώθηση των πακέτων με βέλτιστο τρόπο Forwarding Plane: Είναι το επίπεδο που αναλαμβάνει την λήψη και την προώθηση των πακέτων του δρομολογητή ακολουθώντας την λογική που το Control Plane του έχει υποδείξει. Συγκριτικά με το Control Plane, το Forwarding Plane δεν υιοθετεί κάποια ευφυΐα και αρκείται στην λειτουργία της προώθησης. 24

25 Σε ένα κλασσικό δρομολογητή αυτές οι 2 λειτουργίες θεωρούνται και λαμβάνοντα υπόψη σαν μια λειτουργική οντότητα ώστε να έχουμε το επιθυμητό αποτέλεσμα. Όπως θα αναλύσουμε όμως, σε μια λογική προγραμματιζόμενων δικτύων ή SDN πραγματοποιούμε την αποσύνδεση του Control Plane από το Forwarding Plane, πράγμα που μας δίνει την δυνατότητα να επέμβουμε σε κάθε επίπεδο και να προσθέσουμε επιπλέον υπηρεσίες/λογική αλλά και να διαχειριστούμε με έναν ολοκληρωμένο τρόπο το σύνολο λειτουργιών που επεξεργάζονται τα πακέτα κλπ. Κλασσικοί αλγόριθμοι δρομολόγησης Η αυξανόμενη πολυπλοκότητα στον τρόπο με τον οποίο τα δίκτυα δημιουργούνται και η ανάγκη για αποδοτική παράδοση των πακέτων μεταξύ των κόμβων και των τερματικών σταθμών προϋποθέτει την εφαρμογή κάποιων αλγορίθμων. Από τους πλέον κλασσικούς αλγόριθμους δρομολόγησης είναι αυτός του Dijkstra (Ντάικστρα), που επινοήθηκε το 1956 από τον Ολλανδό Έντσγκερ Ντάικστρα και δημοσιεύτηκε το Ο αλγόριθμος αυτός δίνει λύση στο πρόβλημα της εύρεσης ενός βέλτιστου μονοπατιού σε έναν γράφο n κόμβων (κατευθυνόμενο ή μη), από μια καθορισμένη αφετηρία, προς όλους τους άλλους κόμβους του γράφου. Ο αλγόριθμος συγκαταλέγεται στους λεγόμενους άπληστους αλγόριθμους (greedy algorithms), οι οποίοι μέσα από μια διαδικασία επιλογής και εύρεσης τοπικών υπό-βέλτιστων λύσεων λύνουν τελικά το συνολικό πρόβλημα με βέλτιστη λύση. Σημειώνεται ότι ο αλγόριθμος δεν λειτουργεί σωστά στην περίπτωση που κάποιες ακμές του γράφου περιέχουν αρνητικά βάρη. Σε τέτοιες περιπτώσεις καταφεύγουμε στην λύση άλλων αλγορίθμων όπως αυτού των Bellman-Ford. Κατηγορίες πρωτοκόλλων δρομολόγησης Γενικότερα μπορούμε να κατατάξουμε τα πρωτόκολλα χρησιμοποιούνται σε 2 μεγάλες κατηγορίες οι οποίες είναι οι εξής: που 1. Κατάστασης σύνδεσης ή Link-state algorithms 2. Διανυσματικής απόστασης ή Distance vector algorithms Στον παρακάτω πίνακα (Πίνακας 1) φαίνονται οι κύριες διαφορές και τα χαρακτηριστικά γνωρίσματα των 2 αυτών κατηγοριών. 25

26 Distance Vector Link-State RIPv1/RIPv2 OSPF Bellman-Ford Algorithm Dijkstra's SPF Algorithm Hop count based on # of routers Cost based on Bandwidth Learns from directly connected routers Learns from the source of routing information No neighbor adjacencies Establishes neighbor adjacencies Exchanges routing table every 30 sec. Exchanges LSA only if a change occurs or every 30 minutes Not scalable or flexible The most scalable but not the most flexible Πίνακας 1 Διαφορές αλγορίθμων κατάστασης σύνδεσης και διανυσματικής απόστασης Dijkstra's Algorithm Ας δούμε τώρα ένα σύντομο παράδειγμα εφαρμόζοντας τον αλγόριθμο Dijkstra στον γράφο του παρακάτω σχήματος για να κατανοήσουμε την λειτουργία του. Σχήμα 8 Απλή τοπολογία με βάρη Τα βήματα εκτέλεσης του αλγόριθμου για την εύρεση της συντομότερης διαδρομής ξεκινώντας κάθε φορά από διαφορετική ακμή φαίνονται στον παρακάτω πίνακα (σχήμα 9): 26

27 Σχήμα 9 Πίνακας αποστάσεων κόστους Dijkstra Εδώ συμπεραίνουμε ότι η συντομότερη διαδρομή για ένα πακέτο που εισέρχεται στο δίκτυο από τον κόμβο Α και πρέπει να εξέλθει από το F έχει ελάχιστο κόστος με τιμή 7. Bellman-Ford Algorithm Σε περίπτωση που επιλέξουμε τον αλγόριθμο του Bellman-Ford εφόσον δεν έχουμε αρνητικά βάρη στον γράφο θα πρέπει να καταλήξουμε στο ίδιο αποτέλεσμα. Ο Bellman-Ford υπολογίζει τα ελάχιστα μονοπάτια από μια ακμή προς όλες τις άλλες ακμές ανάλογα τα hops που απέχουν οι κόμβοι μεταξύ τους σε έναν κατευθυνόμενο γράφο. Για τον ίδιο λοιπόν γράφο του σχήματος παραπάνω έχουμε τον εξής πίνακα (σχήμα 10): Σχήμα 10 Πίνακας αποστάσεων κόστους Bellman-Ford Όπως βλέπουμε καταλήγουμε στο ίδιο αποτέλεσμα (κόστος 7) όταν ο αλγόριθμος εκτελεστεί. Έχοντας τώρα παρουσιάσει κάποια πολύ βασικά χωρία της θεωρίας αρχιτεκτονικής των δικτύων είμαστε σε θέση να περάσουμε σε μια διαφορετική φιλοσοφία αρχιτεκτονικής και ανάπτυξης, αυτή του Software-Defined Networking (SDN) ή των προγραμματιζόμενων δικτύων που θα αναλύσουμε στην συνέχεια. 27

28 SOFTWARE-DEFINED NETWORKING Η άνοδος του Cloud computing έξυπνες συσκευές Τα τελευταία χρόνια με την εισαγωγή των έξυπνων συσκευών, των φορητών τάμπλετ και κινητών συσκευών στην καθημερινότητα μας είναι φυσικό να αυξηθεί και η απαιτούμενη δικτυακή κίνηση. Όλες αυτές οι νέες τεχνολογίες απαιτούν σύνδεση στο διαδίκτυο προκειμένου να έχουν πρόσβαση σε πολυμεσικές εφαρμογές και υπηρεσίες υψηλής ευκρίνειας. Εως το 2018 παραπάνω από την μισή δικτυακή κίνηση αναμένεται να προέρχεται από τέτοιου είδους συσκευές [1]. Πέρα από τις αυξημένες ανάγκες για εύρος ζώνης, είναι λογικό να έχουν και αντίστοιχες ανάγκες για αποθήκευση πολυμεσικών δεδομένων κ.ο.κ. Πρέπει δηλαδή ο χρήστης να είναι σε θέση να έχει πρόσβαση και να διαχειρίζεται εύκολα έναν τεράστιο όγκο πληροφοριών, ο οποίος δεν είναι ανάγκη να είναι αποθηκευμένος τοπικά αλλά μπορεί να είναι διαμοιρασμένος σε διαφορετικούς εξυπηρετητές (cloud storage servers). Είναι δηλαδή προφανές ότι οι κλασικές λύσεις όσον αφορά την δικτυακή διαχείριση της κίνησης αλλά και της διαχείρισης των χαοτικών πλέον ροών δεδομένων (big data) είναι πλέον ανεπαρκείς και επομένως απαιτούνται νέες προσεγγίσεις. Άλλωστε στόχος της διαχείρισης των πληροφοριών είναι η παροχή βέλτιστων υπηρεσιών. Προς αυτή την κατεύθυνση οι οργανισμοί και οι επιχειρήσεις παγκοσμίως έχουν στραφεί στην λεγόμενη τεχνολογία της συνεφοϋπολογιστικής ή αλλιώς cloud computing. Με αυτήν την τεχνολογία είναι δυνατή η απομακρυσμένη αποθήκευση πληροφοριών και δεδομένων σε εξυπηρετητές, που παρέχονται από τους λεγόμενους third-party providers ή αλλιώς παροχείς τρίτου τύπου. Αυτοί οι παροχείς είναι συνήθως οργανισμοί παροχής υπηρεσιών χώρου αποθήκευσης, πολυμέσων κλπ. Δηλαδή, λειτουργίες που μέχρι τώρα ήταν κοντά στον χρήστη απομακρύνονται από αυτόν και προσφέρονται σαν αυτόνομη υπηρεσία. Τέτοιου είδους υπηρεσίες όπως γίνεται αντιληπτό συνδέονται άμεσα με την δικτυακή κίνηση και την αποδοτική διαχείρισή της. Πέρα από αυτές τις ανάγκες βέβαια, υπάρχει πάντα και η απαίτηση για φθηνό υπολογιστικό υλικό (hardware) ώστε να μειωθούν τα επιχειρησιακά κόστη και τα κόστη συντήρησης και αντικατάστασης εξοπλισμού. Με βάση τα παραπάνω θα γίνει πιο εφικτό να κατανοήσουμε στην συνέχεια την λογική των προγραμματιζόμενων δικτύων και την προσπάθεια εισαγωγής τους στον τρόπο διαχείρισης των δεδομένων και των πληροφοριών. 28

29 Προγραμματιζόμενα δίκτυα Τα προγραμματιζόμενα δίκτυα στην πραγματικότητα δεν είναι κάτι καινούριο αφού πρώτα χρησιμοποιήθηκαν στην δεκαετία του Άλλωστε οι συσκευές είθισται να χρησιμοποιούν λογισμικό για να ελέγξουν το hardware τους. Κοιτάζοντας για παράδειγμα πίσω στο 1992 χρησιμοποιούσαμε κάποια scripts για να ελέγξουμε τα βασικά δομικά στοιχεία στο δίκτυό μας (core elements). H έλλειψη σχετικής όμως εμπειρίας και προγραμματιστικών δεξιοτήτων από τους διαχειριστές των δικτύων, το κλειστό υλικό με τις ιδιαίτερες ανάγκες για χειρισμό καθώς και η έλλειψη αξιόπιστων εργαλείων/διεπαφών για αυτοματοποίηση αυτών των διαδικασιών άφησε τον προγραμματισμό των δικτύων στην αναμονή. Σήμερα, η εφαρμογή του SDN σε συνδυασμό με κάποιους παραδοσιακούς μηχανισμούς, μπορεί να λύσει προβλήματα στα οποία δεν μπορούσαμε να επέμβουμε για να δώσουμε αποδοτική λύση ή κάτι τέτοιο ήταν αρκετά δύσκολο/περίπλοκο. Αυτό επιτυγχάνεται διαχωρίζοντας την διαδικασία ελέγχου των πακέτων από την διαδικασία προώθησης, και παρέχοντας ανοικτές διεπαφές προς εφαρμογές που απαιτούν συγκεκριμένες πληροφορίες από το δίκτυο για να λειτουργήσουν [2]. Εν ολίγοις οι δικτυακές συσκευές συμμετέχουν ενεργά στην δικτυακή διαχείριση και παροχή υπηρεσιών. Ενδεικτικά μερικά προβλήματα που μπορούμε να επέμβουμε είναι τα εξής: Δρομολόγηση βάση προτεραιοτήτων Προώθηση & δρομολόγηση πακέτων Πρόβλεψη και καταμερισμός κίνησης Έλεγχος συμφόρησης Ανακάλυψη και εξαγωγή της τοπολογίας του δικτύου Μια αρχιτεκτονική σαν αυτή σε συνδυασμό με την τεχνολογία του cloud και της εικονικοποίησης λειτουργιών δικτύου (Παράρτημα Α) θα επιτρέψει την σχεδόν στιγμιαία αλληλεπίδραση του διαχειριστή με τα δικτυακά στοιχεία. Επομένως μπορούμε να έχουμε πλήρη και αποδοτική χρησιμοποίηση του δικτύου χωρίς να σπαταλάμε για παράδειγμα πόρους για εφεδρεία 29

30 (redundancy), αλλά και να προσαρμόζουμε άμεσα το δίκτυο και το μονοπάτι των δεδομένων σε περίπτωση προβλήματος. Είμαστε δηλαδή σε θέση να έχουμε τον στοιχειώδη έλεγχο για κάθε στοιχείο του δικτύου (granular control) και να αντιλαμβανόμαστε και να αντιδράμε άμεσα στις όποιες αλλαγές και απαιτήσεις του δικτύου (provisioning). Στην παρούσα εργασία ασχοληθήκαμε κυρίως με την ανακάλυψη της τοπολογίας του δικτύου σε μια SDN αρχιτεκτονική και την εφαρμογή βέλτιστων δρομολογήσεων με την υλοποίηση και εκτέλεση αντίστοιχων αλγορίθμων. Για την διαχείριση του datapath και των switches χρησιμοποιήσαμε το πρωτόκολλο ForCES της IETF που θα αναλύσουμε στην συνέχεια. Ορισμός προγραμματιζόμενων δικτύων ή SDN Ας δώσουμε εδώ τον ορισμό για το τι είναι SDN με βάση τον οργανισμό IETF. Με βάση λοιπόν το RFC 7426 [2], SDN ορίζεται: Μια νέα προσέγγιση στον δικτυακό προγραμματισμό όπου δίνεται η δυνατότητα αρχικοποίησης, ελέγχου και δυναμικής διαχείρισης των δικτυακών συσκευών μέσω ανοιχτών διεπαφών, σε ένα πλαίσιο δημιουργίας δικτύων (framework) όπου υφίσταται φυσικός διαχωρισμός του επιπέδου ελέγχου - Control Plane από το επίπεδο προώθησης - Forwarding Plane. Αυτός ο διαχωρισμός επιτρέπει τον αυτόνομο σχεδιασμό και την διαχείριση του δικτύου με μια διαφορετική προσέγγιση από την κλασσική. Το επίπεδο ελέγχου (control plane) είναι υπεύθυνο για να παρατηρεί το δίκτυο, να ελέγχει το επίπεδο προώθησης και ουσιαστικά συγκεντρώνει όλη την δικτυακή ευφυΐα. Λειτουργίες λοιπόν όπως η δρομολόγηση υλοποιούνται σε αυτό το επίπεδο ενημερώνοντας κατάλληλα μέσω διεπαφών τα switches στο επίπεδο προώθησης. Η αρχιτεκτονική που περιγράφεται παρουσιάζεται στο σχήμα

31 Σχήμα 11 Κλασσική αρχιτεκτονική SDN Δηλαδή μέσω ανοιχτών και προγραμματιζόμενων API (RESTful APIs) οι εφαρμογές αποκτούν πρόσβαση στο επίπεδο ελέγχου και έπειτα στο επίπεδο του υλικού (hardware). Το σημείο κλειδί όμως για την εκτέλεση οποιασδήποτε λειτουργίας στο control plane είναι η γνώση της τοπολογίας του δικτύου. Αυτό είναι λογικό αναλογιζόμενοι ότι σε μια SDN αρχιτεκτονική το επίπεδο ελέγχου καλείται να ελέγξει ένα άλλο επίπεδο για το οποίο δεν έχει καμία εικόνα. Αυτό γιατί οι λειτουργίες που εκτελούνται για παράδειγμα στο επίπεδο προώθησης αγνοούν το τι συμβαίνει στο επίπεδο ελέγχου. Με την γνώση της τοπολογίας όμως μπορούν να εκτελεστούν αποτελεσματικά λειτουργίες διαχείρισης κίνησης αλλά και στοχευμένες αλλαγές χωρίς να επηρεάζεται ολόκληρο το δίκτυο. Σε αρχιτεκτονικές σαν αυτή προκειμένου να ανακαλύψουμε την τοπολογία χρειαζόμαστε πρώτα απ'όλα μεθόδους επικοινωνίας (πρωτόκολλα) από το forwarding plane προς το control plane. Παραδείγματα τέτοιων μηχανισμών πρωτοκόλλων, μεταξύ άλλων, είναι το ForCES και το OpenFlow, τα οποία και θα αναλύσουμε στην συνέχεια. Όσον αφορά την απόκτηση των πληροφοριών της τοπολογίας μπορούμε να χρησιμοποιούμε το LLDP, το οποίο και περιγράφεται σε επόμενο κεφάλαιο. Είναι σημαντικό να αναφέρουμε ότι το LLDP έχει επιλεχθεί από την πλειοψηφία των πρωτοκόλλων και εφαρμογών SDN για την εκτέλεση της λειτουργίας ανακάλυψης της τοπολογίας του δικτύου. Αυτό συνέβη επειδή δεν εξαρτάται από τον κατασκευαστή και επιπλέον αποτελεί τυποποιημένο πρωτόκολλο κατά τα standard της IEEE που το καθιστούν το πλέον κατάλληλο μεταξύ άλλων. Όπως θα δούμε όμως στην συνέχεια, η μέθοδος που προτείνεται στην παρούσα εργασία για την ανακάλυψη της τοπολογίας και τον καθορισμό βέλτιστων δρομολογήσεων, δεν εξαρτάται αποκλειστικά από το LLDP και 31

32 μπορεί να γίνει και με χρήση άλλων πρωτοκόλλων [3]. Πρόκειται δηλαδή για μια γενική προσέγγιση στην μέθοδο ανακάλυψης της τοπολογίας, αφού δεν συναντάται κάποιος περιορισμός στο πρωτόκολλο που επιλέγουμε για την ανακάλυψη της τοπολογίας του δικτύου. 32

33 NEIGHBOR DISCOVERY PROTOCOLS Ορισμός τοπολογίας δικτύου Μια πολύ σημαντική πληροφορία που εξυπηρετεί τους σκοπούς μας όσον αφορά τα δίκτυα και τις υπηρεσίες που δημιουργούμε πάνω από αυτά είναι να γνωρίζουμε την τοπολογία τους. Η γνώση μια τοπολογίας είναι ικανή να επιτρέψει την πλήρη εποπτεία του δικτύου ανά πάσα στιγμή, μειώνοντας παράλληλα τον χρόνο που χρειάζεται ένας διαχειριστής για να συλλέξει πληροφορίες για τα υπάρχοντα συστήματα. Αυτές μπορούν έπειτα να χρησιμοποιηθούν ώστε να επιλυθεί κάποιο πρόβλημα που μπορεί να προκύψει σε περίπτωση βλάβης, διακοπής δικτύου κλπ. (troubleshooting) ή και σε περίπτωση αλλαγής διαχειριστή όπου δεν θα υπάρχει καταγεγραμμένη καμία γνώση των υποδομών του δικτύου. Ορισμός Τοπολογία ορίζουμε τις συνδέσεις (φυσικές και λογικές) μεταξύ των στοιχείων ενός δικτύου. Σε τελικό επίπεδο είναι η σχέση μεταξύ δυο βασικών δομικών στοιχείων, αυτή των κόμβων και ζεύξεων (nodes & links). Οι κόμβοι μπορεί να είναι είτε συνδετικοί (connecting), είτε τερματικοί (terminal). Μερικές απλές και συνηθισμένες αναπαραστάσεις τοπολογιών από τον συνδυασμό των οποίων προκύπτουν και πολυπλοκότερες φαίνονται στο σχήμα: Σχήμα 12 Βασικές τοπολογίες δικτύων 33

34 Αναφορικά οι βασικές αυτές τοπολογίες είναι οι εξής έξι: Διαύλου. Δακτυλίου. Αστέρα. Επεκταμένου αστέρα. Ιεραρχική - δέντρου. Πλέγματος. Μέθοδοι & πρωτόκολλα κατασκευής τοπολογίας Οι μεθοδολογίες που ακολουθήθηκαν έως τώρα για κατασκευή τοπολογιών διακρίνονται σε 2 βασικές κατηγορίες. 1. Αυτές που χρησιμοποιούν πρωτόκολλα διαχείρισης για την συλλογή πληροφοριών 2. Αυτές που συμμετέχουν στην διαδικασία της δρομολόγησης ενεργά και παρακολουθούν την ροή των πακέτων για την κατανόηση των συνδέσεων. Ανεξαρτήτου μεθοδολογίας όμως, η αναπαράσταση και εκμετάλλευση των κόμβων είναι πολύ σημαντική διαδικασία, ειδικά σε ένα πολύπλοκο αφηρημένο/εικονικοποιημένο περιβάλλον με πολλαπλά φυσικά μηχανήματα και VΜs (Virtual Machines ή εικονικές μηχανές Παράρτημα Β). Παρ'όλα αυτά εφόσον πρόκειται για L2 δίκτυο η διαδικασία ανακάλυψης της τοπολογίας θα είναι όμοια για κάθε κλίμακα. Όσον αφορά τις διαθέσιμες εφαρμογές ικανές να προσδιορίζουν την τοπολογία του δικτύου υπάρχουν διάφορες, ανοιχτού κώδικα ή μη. Αναφορικά η ανοιχτού κώδικα πλατφόρμα OpenNMS υποστηρίζει τα δημοφιλέστερα πρωτόκολλα και μπορεί να δημιουργήσει ένα γράφημα της τοπολογίας του δικτύου βασιζόμενη στα πακέτα που ανταλλάσσονται στο δίκτυο. Το κύριο μειονέκτημα αυτών των 'παραδοσιακών' εφαρμογών και μεθόδων είναι ότι δεν 34

35 είναι σαφώς καθορισμένη η διαδικασία για την συλλογή πληροφοριών του δικτύου. Απαιτείται συνήθως, ακόμα ένας σταθμός διαχείρισης από όπου πρέπει να περνάει πρώτα η κίνηση ώστε να επεξεργάζεται. Μόνο αφού γίνει αυτό μπορούν αυτές οι πληροφορίες να διατεθούν στις όποιες εφαρμογές. Λύσεις όπως οι προηγούμενες όμως υστερούν της δυναμικότητας και προσαρμοστικότητας που χρειάζεται ένα σύγχρονο δίκτυο και ειδικά ένα πλαίσιο προγραμματιζόμενης λογικής δικτύου (SDN framework) για να λειτουργήσει. Χρειαζόμαστε δηλαδή ενεργά στοιχεία ικανά να αλληλεπιδρούν στο δίκτυο. Τα πρωτόκολλα που χρησιμοποιήθηκαν στο παρελθόν για την απόκτηση πληροφοριών σε δίκτυα 2ου επιπέδου ήταν κυρίως κλειστού κώδικα (proprietary) ή vendor specific (π.χ. Nortel DP, ExtremeDP, Microsoft LLTD) εξαρτώμενα πλήρως από το υλικό του κατασκευαστή που έτρεχαν (hardware specific) όπως το γνωστό πρωτόκολλο της Cisco, Cisco Discovery Protocol. Για την κάλυψη λοιπόν αυτής της ανάγκης όσον αφορά την κατασκευή τοπολογιών συχνά γινόταν χρήση πρωτοκόλλων τα οποία δεν ήταν προσανατολισμένα για αυτό τον σκοπό. Ένα παράδειγμα είναι η χρησιμοποίηση του ARP (address resolution protocol) που χρησιμοποιούνταν από εφαρμογές οι οποίες μέσω κάποιων αλγοριθμικών διαδικασιών και σε συνδυασμό με πρωτόκολλα διαχείρισης (SNMP) εξήγαγαν το επιθυμητό αποτέλεσμα. Την λύση σε αυτό το πρόβλημα έδωσε η IEEE με το standard ΙΕΕΕ 802.1ΑΒ ή αλλιώς Link Layer Discovery Protocol, (εφεξής LLDP). Το LLDP είναι ένα vendor-neutral πρωτόκολλο που λειτουργεί στο επίπεδο 2 της OSI stack και παρέχει μια ευρεία γκάμα πληροφοριών. Μεταξύ αυτών είναι οι γείτονες, οι δυνατότητες και η ταυτότητα της συσκευής. Παρακάτω αναλύουμε το πρωτόκολλο αυτό και αναφερόμαστε ειδικότερα στα πλεονεκτήματα και τις ιδιότητες του που το καθιστούν κατάλληλο για την δημιουργία της τοπολογίας του δικτύου σε μια SDN αρχιτεκτονική. 35

36 LINK LAYER DISCOVERY PROTOCOL LLDP Το πρωτόκολλο LLDP ως standard ορίστηκε τον Μάιο του 2005 με την ονομασία ΙΕΕΕ 802.1ΑΒ-2005 [4]. Είναι ένα επιπέδου 2 ανεξαρτήτου κατασκευαστή πρωτόκολλο το οποίο μπορεί να χρησιμοποιηθεί από έναν σταθμό προσαρτημένο σε ένα LAN για να διαφημίσει (advertise) τις δυνατότητές (capabilities) & την ταυτότητά του (identity) αλλά και να λάβει αντίστοιχες πληροφορίες από τους γειτονικούς του σταθμούς. Frame structure Οι πληροφορίες που μας δίνει το συγκεκριμένο πρωτόκολλο ανταλλάσσονται μεταξύ των συσκευών χρησιμοποιώντας την πλαισίωση Ethernet. Κάθε ένα από αυτά τα πλαίσια (Εικόνα 13) περιέχει το LLDPU (LLDP Data Unit), το οποίο αποτελεί μια ακολουθία τιμών ακολουθώντας την κωδικοποίηση TLV (Type Length Value). Εικόνα 13 Πλαίσιο LLDP Είναι ουσιαστικά ένας τρόπος αναπαράστασης προαιρετικών πληροφοριών που τον χρησιμοποιούμε όταν θέλουμε να μεταδοθούν δεδομένα μέσα σε ένα επικοινωνιακό κανάλι μέσω κάποιου πρωτοκόλλου. Η αναπαράσταση δεδομένων με αυτήν την μορφή έχει κάποια πλεονεκτήματα όπως: Τυχαία σειρά των στοιχείων μέσα στο σώμα του μηνύματος. Ευκολία δημιουργίας xml κώδικα για περιγραφή των δεδομένων σε human-readable μορφή. Ευκολία αναζήτησης και χρήσης των πληροφοριών (λόγω του Binary format) από εργαλεία ανάλυσης. 36

37 Δομή TLV Η δομή του κάθε tlv αποτελείται από τα εξής δομικά στοιχεία : Type: 7bits (Ένας δυαδικός κωδικός ο οποίος υποδεικνύει τον τύπο του μηνύματος που ακολουθεί) Length: 9bits ( Το μήκος του πεδίου τιμών συνήθως σε bytes ) Value: 0-511octets (Μεταβλητού μήκους σειριακά δεδομένα από byte τα οποία περιέχουν ουσιαστικά τα δεδομένα του μέρους του μηνύματος που αποστέλλεται) Ένα απλό παράδειγμα μιας τέτοιας κωδικοποίησης μπορεί να είναι το παρακάτω: command_c/4/makecall_c/phonenumbertocall_c/8/" " Σε αυτό το παράδειγμα οι λέξεις command_c, phone,makecall_c, NumberToCall_c αναπαριστούν τον τύπο (type), και τα 4, 8 το μήκος των τιμών (value) αντίστοιχα. Όπως μπορούμε να παρατηρήσουμε και στην παρακάτω εικόνα που περιγράφει την δομή του πλαισίου, το αναγνωριστικό του LLDP στην κεφαλίδα είναι 0x88cc. Για την αποστολή των πακέτων χρησιμοποιείται μια ειδική διεύθυνση πολλαπλής διανομής (multicast address) όπου δεν προωθείται από συσκευές οι οποίες είναι συμβατές με το πρότυπο 802.1D, αποφεύγοντας έτσι την δημιουργία κλειστών βρόχων. Κάθε πλαίσιο LLDP λοιπόν ξεκινάει με κάποια υποχρεωτικά tlv που περιγράφουν στοιχεία όπως τα: Chassis ID Port ID Time-to-Live Μετά από αυτά ακολουθούν μη υποχρεωτικά πεδία και στο τέλος του πλαισίου ένα ειδικό tlv που ονομάζεται endoflldpdu με τα στοιχεία type & length να είναι 0 και ουσιαστικά δηλώνει το τέλος αυτού. 37

38 Εικόνα 14 Δομή LLDP πλαισίου Πληροφορίες που συλλέγουμε Με το LLDP μπορούμε να συλλέξουμε κάποιες πολύ σημαντικές και χρήσιμες πληροφορίες που είναι αποθηκευμένες στην συσκευή που θέλουμε να διαχειριστούμε. Προκειμένου λοιπόν να τις αποκτήσουμε από το απομακρυσμένο μηχάνημα πρέπει να χρησιμοποιήσουμε κάποιο μηχανισμό επικοινωνίας. Αυτός συνήθως είναι το πρωτόκολλο SNMP όπως ορίζει και το RFC Εκμεταλλευόμενοι όμως κάποιες υλοποιήσεις ανοικτού κώδικα όπως τα project openlldp και lldpad στο περιβάλλον του λειτουργικού linux μπορούμε να χρησιμοποιήσουμε κάποιους daemons που τρέχουν πάνω απο τον agent του πρωτοκόλλου LLDP και να παρουσιάσουμε στο user-space αυτές τις πληροφορίες που συλλέξαμε από τις γειτονικές μας συσκευές. (Σε μια τέτοια βάση στηρίξαμε και αργότερα την εφαρμογή που χρησιμοποιήσαμε στην παρούσα διπλωματική για την κατασκευή της τοπολογίας του δικτύου. Αναλυτικότερα την ιδέα και την υλοποίηση θα την παρουσιάσουμε σε επόμενο κεφάλαιο). Ειδικότερα τώρα, όσον αφορά τις πληροφορίες που μπορούμε να συλλέξουμε είναι οι εξής : Όνομα και περιγραφή συστήματος (System name and description) Όνομα και περιγραφή πόρτας (Port name and description) Όνομα εικονικού τοπικού δικτύου VLAN (VLANname) Διεύθυνση IP για την διαχείριση του συστήματος (Ipmanagementaddress) Ιδιότητες/Δυνατότητες συστήματος, όπως δρομολόγηση, προώθηση κτλ. (Systemcapabilities (switching,routing,etc.) ) 38

39 Όνομα φυσικής διεύθυνσης ΜAC address Λειτουργία PoE (Power over Ethernet) Link aggregation (μέθοδος που επιτρέπει τον συνδυασμό πολλαπλών δικτυακών συνδέσεων παράλληλα ώστε να αυξηθεί η δυνατότητα διεκπεραίωσης κίνησης ή throughput) Μπορούμε ακόμα να χρησιμοποιήσουμε ένα πρόσθετο που δημιουργήθηκε και ενσωματώθηκε το 2006, το οποίο ονομάζεται Media Endpoint Discovery(LLDP MDED ) και επιτρέπει: Αυτόματη αναγνώριση των κανόνων που διέπουν ένα τοπικό δικτύου (LAN-policies) όπως προτεραιότητες VLAN, επιπέδου 2, διαφοροποιημένων υπηρεσιών κλπ. Ανακάλυψη συσκευών για την δημιουργία τοπικών βάσεων δεδομένων σε περιπτώσεις VoIP κτλ. Αυτόματη διαχείριση ενέργειας σε περιπτώσεις PoE Διαχείριση των διαθέσιμων συσκευών που επιτρέπει τον εντοπισμό των συστημάτων και των καθορισμό των χαρακτηριστικών τους. (κατασκευαστής, έκδοση λογισμικού και υλικού κλπ.) Μπορούμε να δούμε στις παρακάτω εικόνες (Εικόνες 15, 16) τις πληροφορίες που δίνει μέσω ενός τερματικού η υλοποίηση lldpd σε περιβάλλον linux, για ένα πακέτο LLDP όπως αιχμαλωτίστηκε από τον αναλυτή πρωτοκόλλων Wireshark. 39

40 Εικόνα 15 Ανακάλυψη γειτόνων με το lldpad Εικόνα 16 Capture lldp πλαισίων με wireshark 40

41 Εφαρμογές του LLDP To LLDP όπως αναφέρθηκε είναι ένα one-hop protocol. Αυτό σημαίνει ότι τα πακέτα που στέλνει μεταξύ των δικτυακών συσκευών μπορούν να φτάσουν μόνο μέχρι τον διπλανό τους γείτονα, δηλαδή το μηχάνημα που απέχει μόνο ένα hop απόσταση στην τοπολογία ή απλά είναι directly connected. Αν εμείς λοιπόν έχουμε μια συσκευή (switch) η οποία είναι άμεσα συνδεδεμένη με 3 άλλες συσκευές (pc, switch κλπ) και θελήσουμε να δούμε τις συνδέσεις τοπικά από την πρώτη συσκευή χρησιμοποιώντας το LLDP, θα δούμε όλες τις διαθέσιμες πληροφορίες και από τις 3 συνδεδεμένες συσκευές. Θέλοντας λοιπόν για τις ανάγκες τις διπλωματικής να μπορούμε να κατασκευάζουμε μια τοπολογία δικτύου για να μπορούμε να εφαρμόζουμε τις επιθυμητές βέλτιστες δρομολογήσεις, χρειαστήκαμε έναν τρόπο να συλλέξουμε πληροφορίες από τις διαθέσιμες συσκευές οι οποίες όμως να μας επιτρέπουν και την δημιουργία του χάρτη του δικτύου μας. Προσεγγίζοντας το πρόβλημα με μια SDN λογική όπου η ευφυΐα του δικτύου είναι συγκεντρωμένη στον controller μπορούμε με διαδοχικά query από αυτόν προς τις ελεγχόμενες συσκευές να μάθουμε τους γείτονες κάθε συσκευής και ύστερα να κατασκευάσουμε τον χάρτη του δικτύου κάνοντας τους απαραίτητους συσχετισμούς των διευθύνσεων και πορτών. Για να επιτύχουμε κάτι τέτοιο χρειαζόμαστε από κάθε συσκευή το ζεύγος πληροφοριών mac-address και connected port, οι οποίες μπορούν να προσδιοριστούν από το LLDP. Συλλέγοντας τελικά αυτές τις πληροφορίες τοπικά στον controller από κάθε forwarding element είμαστε σε θέση να συμπεραίνουμε την τοπολογία δικτύου, την οποία μπορούμε να ελέγχουμε και προσαρμόζουμε δυναμικά με την λειτουργία του LLDP στο 2ο επίπεδο. Το επικρατέστερο πρωτόκολλο όσον αφορά το SDN αλλά και που έχει χρησιμοποιηθεί έως σήμερα επί των πλείστων σε οργανισμούς είναι το OpenFlow. Για τον λόγο αυτό είναι θεμιτό να αναλύσουμε τον τρόπο που το OpenFlow λειτουργεί και εκτελεί τις διαδικασίες ανακάλυψης τοπολογίας, πριν περάσουμε στην υλοποίηση που πραγματοποιήσαμε με το ForCES. Έτσι θα μπορέσει να γίνει σύγκριση άλλα και να αποσαφηνιστεί και ο διαφορετικός βέλτιστος τρόπος - που προτείνεται στην παρούσα διπλωματική. 41

42 OPENFLOW PROTOCOL Όπως ήδη έχει αναφερθεί, στο SDN έχουμε τον διαχωρισμό του control από το forwarding plane. Ένα πρωτόκολλο που συνδέει αυτά τα 2 επίπεδα είναι το OpenFlow, το οποίο επιτρέπει την επικοινωνία και τον έλεγχο των στοιχείων προώθησης ώστε να τα καθοδηγήσει στο πως να διαχειρίζονται την εισερχόμενη κίνηση. OpenFlow switch Κάθε OpenFlow switch για να επιτύχει αποδοτική διαχείριση της κίνησης κάνει χρήση κάποιων πινάκων που ονομάζει πίνακες ροής ή flow tables. Eνός πίνακα ομάδας (group table) που χρησιμοποιείται για την αναζήτηση και προώθηση των πακέτων, και ενός καναλιού επικοινωνίας με τον controller. Πριν ξεκινήσουμε οποιαδήποτε σχετική ανάλυση πρέπει να ορίσουμε τις πόρτες (ports) που χρησιμοποιούνται από ένα OpenFlow switch. Τα ΟpenFlow ports είναι πρακτικά τα network interfaces που χρησιμοποιεί το πρωτόκολλο για να ανταλλάζει πακέτα με το υπόλοιπο δίκτυο. Σχετικά, μπορούμε να διακρίνουμε 3 είδη: Φυσικές πόρτες Physical ports Λογικές πόρτες Logical ports Δεσμευμένες πόρτες Reserved ports Οι φυσικές πόρτες είναι οι πόρτες που χρησιμοποιεί το hardware. Οι λογικές πόρτες δεν αντιστοιχούν απευθείας στο hardware του switch και μπορούν να υποστηρίξουν πακέτα με ενθυλάκωση (packet encapsulation) ή πακέτα που να αντιστοιχούν σε οποιεσδήποτε φυσικές πόρτες. Η διαφορά των 2 είναι ότι στις λογικές πόρτες είναι πιθανό να ανταλλάζονται πακέτα που 42

43 περιέχουν ένα επιπλέον πεδίο με τίτλο Tunnel-ID που μεταφέρει τα γνωστά μετα-δεδομένα ή metadata. Οι δεσμευμένες πόρτες περιλαμβάνουν γενικού σκοπού πόρτες που χρησιμοποιούνται για παράδειγμα για αποστολή εντολών στον controller ή για προώθηση πακέτων σε κλασσικά switch. OpenFlow tables Για να γίνει πιο κατανοητή η χρήση των flow tables ας παρατηρήσουμε το σχήμα 17 παρακάτω. Σχήμα 17 Κανόνες και ενέργειες στο OpenFlow Το σχήμα 17 περιγράφει το σύνολο των κανόνων και ενεργειών που δέχεται ένα πακέτο όταν εισέρχεται σε ένα OpenFlow switch. Όπως παρατηρούμε κάθε πακέτο υπόκειται σε μια κατηγοριοποίηση σύμφωνα με κάποιους κανόνες. Με βάση αυτούς τους κανόνες και κάποια ταιριάσματα (matching) μπορεί να προωθηθεί σε μια επόμενη πόρτα εξόδου ή να απορριφθεί. Κάθε πίνακας ροής αποτελείται από 3 βασικά στοιχεία που επηρεάζουν τα πακέτα: 1. Κανόνες - Rules 2. Ενέργειες - Actions 3. Στατιστικά - Stats 43

44 Το πεδίο Rule αποτελεί το αναγνωριστικό για έναν συγκεκριμένο πίνακα ροής. Με βάση το rule εκτελείται ένα πρώτο φιλτράρισμα πριν το πακέτο προχωρήσει στο δίκτυο. Δηλαδή κάθε φορά που ένα πακέτο εισέρχεται σε ένα OpenFlow switch interface (ingress port), προωθείται με βάση κάποια στοιχεία που περιέχονται στην κεφαλίδα του σε κάποιο αντίστοιχο table. Αφού κατηγοριοποιηθεί (rule), μπορούμε να εφαρμόσουμε κάποιους κανόνες που ουσιαστικά υποδεικνύουν τον τρόπο με τον οποίο θέλουμε να το διαχειριστούμε στο δίκτυό μας. Τέλος σε κάθε πίνακα κρατάμε και κάποια στατιστικά για το πλήθος των πακέτων και των bytes που έχει επεξεργαστεί. Εφαρμόζεται δηλαδή μια πολιτική διαχείρισης κίνησης ανά πίνακα και ανά πακέτο (per table packet processing), όπως αναλύεται παρακάτω και περιγράφεται στο σχήμα 18. Σχήμα 18 Επεξεργασία ανα πακέτο και ανα πίνακα Κάθε πακέτο δηλαδή εισερχόμενο στο OpenFlow switch υπόκειται σε μια διαδικασία pipelining μέσα από πίνακες με διαφορετική προτεραιότητα. Το δομικό διάγραμμα του αλγόριθμου που ακολουθείται παριστάνεται στο σχήμα

45 Σχήμα 19 Λογική μετακίνησης πακέτων στο OpenFlow Αν μέσω αυτής της διαδικασίας δεν υπάρχει κανένα matching τότε το πακέτο γίνεται drop. Αναφορικά, μπορούμε να εφαρμόσουμε ακόμα και λειτουργίες ποιότητας υπηρεσίας (QoS) κάνοντας χρήση των στατιστικών που αποθηκεύονται σε κάθε table. Η όλη επικοινωνία με τον controller γίνεται με το κανάλι επικοινωνίας που υπάρχει μεταξύ switch και controller. To switch δηλαδή επικοινωνεί με τον controller και ο controller διαχειρίζεται το switch μέσω του πρωτοκόλλου OpenFlow. Με την χρήση αυτού του πρωτοκόλλου μπορεί έπειτα ο controller να προσθέσει, να ανανεώσει ή να διαγράψει στοιχεία από τους πίνακες ροής. Η αρχιτεκτονική που περιγράψαμε ως τώρα φαίνεται στο σχήμα 20. Σχήμα 20 Αρχιτεκτονική OpenFlow-based συστήματος 45

46 OpenFlow topology discovery Όπως έχουμε αναφέρει το OpenFlow χρησιμοποιεί το LLDP για την ανακάλυψη της τοπολογίας. Ας δούμε τώρα ειδικότερα τον τρόπο με τον οποίο αυτό επιτυγχάνεται. Για να εκκινήσει η διαδικασία, ο controller στέλνει μια εντολή (packet_out) σε όλα τα switches έχοντας ενθυλακώσει ένα LLDP πλαίσιο. Το LLDP επειδή είναι ένα οne-hop πρωτόκολλο πρακτικά δεν μπορεί να προωθηθεί πέρα από ένα switch. Για να συμβεί αυτό το OpenFlow αλλάζει την προκαθορισμένη τιμή του LLDP με μια διαφορετική διεύθυνση πολυεκπομπής. Έτσι τα πλαίσια που αποστέλλονται στο δίκτυο είναι δυνατόν να ανταλλάσσονται σε περισσότερα από ένα switches. Όταν το switch λάβει την εντολή packet_out από τον controller τότε πλημμυρίζει όλες τις πόρτες του (flooding) προωθώντας τα LLDP πλαίσια με την αλλαγμένη διεύθυνση πολυεκπομπής. Όπως είναι λογικό, τα γειτονικά switches θα λάβουν αυτά τα πακέτα και όπως περιγράψαμε θα προσπαθήσουν να αντιστοιχήσουν την πληροφορία του LLDP πλαισίου με τις εγγραφές των πινάκων που διατηρούν τοπικά. Αν δεν υπάρχει καμία αντίστοιχη εγγραφή τότε θα πρέπει να ανανεώσουν τους πίνακές τους και να προωθήσουν το πακέτο με την επιπλέον αυτή πληροφορία. Ανταλλάζοντας λοιπόν αυτά τα πακέτα μεταξύ των switches το πακέτο εμπλουτίζεται σταδιακά με την πληροφορία των γειτόνων και τελικά αποστέλλονται με μια εντολή packet_in μέσω ενός καθορισμένου OpenFlow switch πίσω στον Controller. Σχήμα 21 Μηνύματα OpenFlow topology discovery 46

47 Συνοψίζοντας η διαδικασία ανακάλυψης της τοπολογίας με το OpenFlow μπορεί να περιγράφει με τις 3 εντολές: 1. Packet_out 2. Flow_lookup 3. Packet_in Είναι σημαντικά να αναφέρουμε ότι αυτή η διαδικασία δεν είναι αυστηρά καθορισμένη και οι controllers που χρησιμοποιούνται στην πράξη (π.χ. Opendaylight, RYU, POX) ακολουθούν αυτή την διαδικασία με μικρές όμως αλλαγές. Για παράδειγμα δεν είναι προτυποποιημένη η διεύθυνση πολυεκπομπής που χρησιμοποιείται. Αυτό μπορεί να οδηγήσει σε διάφορα προβλήματα κατανόησης και επικοινωνίας μεταξύ των διαφορετικών οντοτήτων στο δίκτυό μας. Πρέπει δηλαδή σε αυτή την διαδικασία να γίνεται σωστά ο χειρισμός των εντολών που στέλνει ο controller στα switch καθώς λανθασμένος χειρισμός μπορεί να οδηγήσει σε σημαντικά προβλήματα στο δίκτυο, όπως καθυστερήσεις, μη βέλτιστο load balancing ή ακόμα και διακοπή της επικοινωνίας [5]. Αξίζει να αναφερθεί ότι καθυστερήσεις υπάρχουν ήδη λόγω της φυσικής αποσύνδεσης του control από το data plane οπότε οποιοδήποτε επιπλέον πρόβλημα ή καθυστέρηση λειτουργεί προσθετικά στο δίκτυο. Στην παρούσα διπλωματική χειριστήκαμε τα LLDP πακέτα με διαφορετικό τρόπο χωρίς την ανάγκη να τροποποιήσουμε οποιοδήποτε στοιχείο του πρωτοκόλλου. Εκμεταλλευτήκαμε επίσης το γεγονός ότι το LLDP είναι one-hop protocol και μπορέσαμε να λάβουμε την πληροφορία σχετικά με τα γειτονικά στοιχεία τοπικά από το υπάρχον υλικό hardware. Καταφέρνουμε με αυτόν τον τρόπο να μειώσουμε το overhead των πακέτων που ανταλλάζονται στο δίκτυο αλλά και να μειώσουμε την κίνηση λόγω των πακέτων τα οποία θα έπρεπε, στην προσέγγιση που περιγράψαμε με το OpenFlow, να στέλνει περιοδικά ο contoller στα switch για να ανανεώνεται η τοπολογία. 47

48 C E F E F E FORCES ForCES Framework To πλαίσιο ForCES (Forward and Control Element Separation) [6] συνιστά έκβαση της σχετικής ομάδας εργασίας της IETF [7]. Η ανάπτυξή του ξεκίνησε το 2001 και ολοκληρώθηκε το Αποτελεί την πρώτη προσπάθεια σύνδεσης του επιπέδου ελέγχου με το επίπεδο προώθησης μέσω ανοιχτών διεπαφών σε αρχιτεκτονικές προγραμματιζόμενων δικτύων. Το ForCES όπως θα δούμε επιτυγχάνει τον διαχωρισμό του forwarding από το control plane με την χρήση διάφορων πρωτοκόλλων και ενός μοντέλου [8]. Με αυτόν τον τρόπο αποσυνδέονται λειτουργίες του επιπέδου ελέγχου όπως η δρομολόγηση, η σηματοδοσία κλπ. (γνωστή και ως slow path) από λειτουργίες του επιπέδου προώθησης όπως προώθηση πακέτων ή τροποποίηση κεφαλίδας πακέτου. Δομικά στοιχεία του ForCES Το πλαίσιο του ForCES βασίζεται στα δομικά στοιχεία που φαίνονται στο παρακάτω σχήμα. Σχήμα 22 Δομικά στοιχεία του ForCES 48

49 Κάθε στοιχείο στο δίκτυο ή αλλιώς Network Element αποτελείται όπως φαίνεται από δυο επί-μέρους συστατικά στοιχεία: 1. Τα στοιχεία προώθησης (FE). Αυτά ορίζονται από επί μέρους διασυνδεδεμένα δομικά στοιχεία που ονομάζονται block λογικών συναρτήσεων ή όπως συνηθίζεται LFBs (Logical Function Blocks). 2. Τα στοιχεία ελέγχου ή Control Elements (CE). Κάθε στοιχείο ελέγχου μπορεί χρησιμοποιώντας το ForCES να ελέγξει ένα ή περισσότερα στοιχεία προώθησης στο αντίστοιχο επίπεδο. Η σχέση μεταξύ των CE και των FE είναι master-slave και η αρχιτεκτονική που περιγράφει την σχέση μεταξύ αυτών όπως ορίζεται από τα παραπάνω περιγράφεται στο σχήμα 23. Σχήμα 23 Εσωτερική τοπολογία στοιχείων στο ForCES Προκειμένου τα control elements να μπορούν να ελέγχουν ένα πλήθος διαφορετικών λειτουργιών του δικτύου στο FE, αναπτύχθηκε ένα αφηρημένο μοντέλο περιγραφής λειτουργιών (ForCES model) που ορίζεται με την βοήθεια ενός XML(eXtensible Markup Language) schema. Ο χρήστης μπορεί με αυτό το εργαλείο να ορίσει - μοντελοποιήσει και να αναπτύξει τις δικές του λειτουργίες δικτύου με την μορφή λογικών λειτουργιών, όπως θα αναλύσουμε στην συνέχεια. 49

50 Ακόμα, χάριν της επεκτασιμότητας που το μοντέλο του ForCES προσφέρει, έχει προτυποποιηθεί ένα πρωτόκολλο (ForCES Protocol) που επιτρέπει στα CE να επικοινωνούν με οποιαδήποτε FE που έχουν μοντελοποιηθεί με το ForCES model. Παρέχεται δηλαδή ένας καθολικός τρόπος επικοινωνίας των στοιχείων προώθησης με τα στοιχεία ελέγχου όπου ουσιαστικά το πρωτόκολλο είναι αγνωστικό ως προς το περιεχόμενο του μοντέλου. Παρακάτω θα ακολουθήσει λεπτομερής ανάλυση του μοντέλου το οποίο χρησιμοποιήθηκε κυρίως στην παρούσα διπλωματική και έπειτα τα βασικά στοιχεία του πρωτοκόλλου για την πληρέστερη κατανόηση. FORCES MODEL Το σημείο κλειδί ώστε ένα CE να ελέγξει ένα FE είναι να αντιληφθεί τον τρόπο με τον οποίο αυτό επεξεργάζεται τα πακέτα. Αυτό επιτυγχάνεται με την μοντελοποίηση των λειτουργιών στα FE. Ουσιαστικά το μοντέλο περιγράφει τις δυνατότητες επεξεργασίας πακέτων για κάθε FE [9]. Η λογική πίσω από την μοντελοποίηση των FE είναι ότι τα δικτυακά στοιχεία όπως τα switches και τα routers αποτελούνται από λογικά διαχωρισμένες διεργασίες οι οποίες συνεργάζονται για να εκτελέσουν μια λειτουργία. Σε αυτή την λογική το ForCES χτίζει κάθε FE με διασυνδεδεμένα Block. Κάθε block αποτελείται από μια λογική συνάρτηση - logical function block (LFB) που εκτελεί μια συγκεκριμένη διεργασία ή υπολογισμό. Δηλαδή κάθε FE αποτελείται από ένα γράφο διασυνδεδεμένων LFB. Στο σχήμα 24 παρακάτω φαίνεται η εσωτερική αρχιτεκτονική ενός στοιχείου προώθησης αποτελούμενο από διασυνδεδεμένα LFBs. Σχήμα 24 Δομικά στοιχεία ενός FE 50

51 Εδώ ουσιαστικά προκύπτει και μια πρώτη βασική διαφορά με το OpenFlow. Όπως περιγράψαμε το OpenFlow πραγματοποιεί τις όποιες αλλαγές χρησιμοποιώντας actions και περιμένοντας ότι στο επίπεδο προώθησης υπάρχουν και κάποιοι αντίστοιχοι πίνακες (flow tables). Το ForCES όμως δημιουργεί τα flows των πακέτων χρησιμοποιώντας πολλά διαδοχικά LFBs αντί για πίνακες. Αυτός είναι και ένας τρόπος που εξασφαλίζει την διαλειτουργικότητα του πρωτοκόλλου σε μηχανήματα διαφορετικών κατασκευαστών. Δηλαδή ο κάθε χρήστης μπορεί απλά να ορίζει τα δικά του LFB σύμφωνα με κάποια γνωστά πρότυπα (ForCES model), ώστε να υπάρχει κοινή βάση επικοινωνίας μεταξύ αυτών και ο controller να μπορεί να καθορίζει αντίστοιχα το μονοπάτι των δεδομένων. Logical Function Blocks Τα λογικά μπλοκ λειτουργιών όπως αναφέραμε είναι αφηρημένες αναπαραστάσεις των στοιχείων του δικτύου που εκτελούν διάφορες προκαθορισμένες λειτουργίες. Κάθε LFB εκτελεί μια συγκεκριμένη λειτουργία και μπορεί να έχει σαν είσοδο κάποιο πακέτο, metadata και τα δυο ή τίποτα (π.χ. ανακατεύθυνση πακέτου). Όταν εκτελέσει την προκαθορισμένη λειτουργία του δημιουργεί και μεταδίδει πληροφορίες συνήθως στην μορφή των metadata. Metadata Μεταδεδομένα ορίζονται τα στοιχεία τα οποία ανταλλάσσονται μεταξύ των LFB κατά την διάρκεια μετακίνησης του πακέτου. Το ForCES παρέχει στον χρήστη έναν τρόπο ώστε να μπορεί να ορίζει την δημιουργία, τροποποίηση, ανάγνωση ή και διαγραφή τέτοιων μεταδεδομένων. LFB Outputs & Inputs Μια έξοδος είναι ουσιαστικά μια πόρτα η οποία είναι ικανή να ανταλλάσσει πληροφορίες με γειτονικά LFB. H πληροφορία που αποστέλλεται από μια τέτοια πόρτα είναι ζεύγος του πακέτου και των μεταδεδομένων (metadata) που σχετίζονται με αυτό. Σε ένα LFB μπορούν να οριστούν μια είσοδος/έξοδος, πολλαπλές είσοδοι/έξοδοι, ένα ή πολλά group εισόδων/εξόδων, συνδυασμός αυτών ή καθόλου είσοδοι/έξοδοι (π.χ. το drop πακέτου δεν χρειάζεται output port). Οι είσοδοι και οι έξοδοι διασυνδέονται με την μορφή 51

52 ενός κατευθυνόμενου γράφου για να δημιουργήσουν μια λειτουργία (π.χ. Δρομολόγηση). Όταν ορίζουμε το LFB, πρέπει επίσης να καθοριστεί ο τύπος των πακέτων που μπορεί να διαχειρίζεται. Εδώ πρέπει να σημειώσουμε ότι κάθε LFB λειτουργεί με κάποιους τύπους πακέτων αλλά δεν ενδιαφέρεται αν η υλοποίηση του κατώτερου επιπέδου περνάει στο παραπάνω επίπεδο περισσότερη 'πληροφορία' από όση χρειάζεται. Για παράδειγμα αν έχουμε ένα LFB που διαχειρίζεται πακέτα τύπου Ipv4, δεν είναι αναγκαστικό ότι η παρακάτω υλοποίηση θα αφαιρεί ή όχι την κεφαλίδα του 2ου επιπέδου. Επομένως το τι συμβαίνει σε τέτοιες περιπτώσεις είναι αδιάφορο του controller και δεν αφορά την διαδικασία απόφασης. Ενδεικτικά μεταξύ άλλων λειτουργιών που εκτελούν τα LFB κάποιες από τα συνηθέστερες λειτουργίες είναι οι εξής: Ipv4 LFB Classifier LFB Meter LFB Παρακάτω βλέπουμε πως μοντελοποιήσαμε τις εισόδους και εξόδους του LFB που χρησιμοποιήσαμε σε συνδυασμό με το LLDP στην παρούσα εργασία. <inputport group="true"> <name>lldpin</name> <synopsis>ports listening for lldp packets</synopsis> <expectation> <frameexpected> <ref>lldp</ref> </frameexpected> </expectation> </inputport> </inputports> <outputports> <outputport> <name>lldpout</name> <synopsis>ports for advertising local machine to neighbors sending LLDP packets </synopsis> <product> <frameproduced> <ref>lldp</ref> </frameproduced> </product> </outputport> </outputports> 52

53 Ειδικότερα όσον αφορά τα LFB όπως θα πρέπει να έχει γίνει σαφές, αποτελούν το βασικό δομικό συστατικό των FE και κάθε ένα είναι ουσιαστικά μια αφαιρετική αναπαράσταση μιας συγκεκριμένης λειτουργίας μιας δικτυακής συσκευής. Επιπρόσθετα όμως, κάθε FE μπορεί να ελέγχεται αυτούσιο, σαν μια ολότητα, από τον controller. Για τον λόγο αυτό έχουν δημιουργηθεί τα λεγόμενα LFB πυρήνα ή core LFBs. Αυτά είναι 2 και πρέπει να υπάρχουν σε κάθε FE. Core LFBs 1. Το πρώτο είναι το object LFB το οποίο δίνει πληροφορίες σχετικά με τις δυνατότητες και την κατάσταση στην οποία βρίσκεται το FE, αλλά και πληροφορίες σχετικά με την εσωτερική τοπολογία των LFB (intra-fe topology). 2. Το δεύτερο λέγεται Protocol LFB και αποθηκεύει σημαντικές πληροφορίες για την λειτουργικότητα του πρωτοκόλλου. Όπως αναφέρθηκε, το μοντέλο καθορίζεται από ένα XML schema. Αυτό ορίζει την δομή που θα έχει το LFB και τα στοιχεία που μπορούν να περιέχονται σε αυτό. Επειδή όμως ο καθένας μπορεί να δημιουργήσει το δικό του μοντέλο - βιβλιοθήκη, ο στόχος του μοντέλου πρακτικά είναι η διαλειτουργικότητα, που επιτυγχάνεται και με την απλότητα του πρωτοκόλλου όπως θα δούμε αργότερα. Ειδικότερα, μια βιβλιοθήκη περιέχει μια ακολουθία αντικειμένων (υποχρεωτικών ή μη), τα οποία αν υπάρχουν εμφανίζονται με την ακόλουθη σειρά. Definitions Load Frame Definitions Data Type Definitions Metadata Type Definitions LFBs 53

54 Logical Function Blocks Definitions Αυτό που μας ενδιαφέρει ιδιαίτερα σε σχέση και με την παρούσα εργασία είναι η υλοποίηση και περιγραφή των LFB. Το μοντέλο του ForCES ακολουθεί μια αντικειμενοστραφή προσέγγιση στον ορισμό των LFBs. Ορίζει δηλαδή κλάσεις, οι οποίες χρησιμοποιούν ένα σύστημα αρίθμησης έκδοσης ή versioning έτσι ώστε να μπορούν να δημιουργηθούν νέες εκδόσεις της ίδια κλάσης στο ίδιο LFB. Κάθε κλάση ορίζεται πλήρως περιγράφοντας το ακόλουθα στοιχεία: Name Synopsis Version LFB Class ID Inheritance Input ports Output ports Components Capabilities Events Description Σημαντικό στοιχείο στην επίλυση του προβλήματος της βέλτιστης τοπολογίας είναι το πεδίο events. Τα events είναι ένας μηχανισμός παρόμοιος με αυτόν των traps του SNMP και μπορεί να δημιουργεί ειδοποιήσεις προς τον controller. O προγραμματιστής μπορεί να ορίσει ποιο στοιχείο θα ενεργοποιήσει αυτόν τον μηχανισμό καθώς επίσης και την συνθήκη ενεργοποίησης. Για παράδειγμα ας δούμε ένα event που ενεργοποιείται κάθε 54

55 φορά που ένα νέο πακέτο LLDP ανιχνεύεται από μια πόρτα ώστε να ενημερώνει κατάλληλα τον controller για να αναπροσαρμόσει την τοπολογία: <event eventid="2"> <name>updatemap</name> <synopsis>information from CE that new nodes are available for the datapath </synopsis> <eventtarget> <eventfield>map</eventfield> </eventtarget> <eventchanged/> <eventreports> <eventreport> <eventfield>map</eventfield> <eventsubscript>neighbors</eventsubscript> </eventreport> </eventreports> </event> Παρακάτω περιγράφεται και η κλάση που ορίσαμε στην παρούσα διπλωματική για να περιγράψουμε ένα LFB το οποίο επεξεργάζεται τις πληροφορίες που χρειαζόμαστε για να εκτελέσουμε την ανακάλυψη της τοπολογίας με την χρήση του LLDP. <LFBClassDef LFBClassID="1024"> <name>lldump</name> <synopsis>lldump is used for capturing lldp frames and collecting neighbor's info </synopsis> <version>1.0</version> <inputports> <inputport group="true"> <name>lldpin</name> <synopsis>ports listening for lldp packets</synopsis> <expectation> <frameexpected> <ref>lldp</ref> </frameexpected> </expectation> </inputport> </inputports> <outputports> <outputport> <name>lldpout</name> <synopsis>ports for advertising local machine to neighbors sending LLDP packets </synopsis> <product> <frameproduced> <ref>lldp</ref> 55

56 </frameproduced> </product> </outputport> </outputports> <components> <component componentid="1" access="read-write"> <name>map</name> <synopsis>variable sized array containing stats and info per neighbor </synopsis> <array> <typeref>lldp_info</typeref> </array> </component> </components> <capabilities> <capability componentid="2"> <name>maxdevs</name> <synopsis>maximum local devices/ports from which discovery can be done simultaneously </synopsis> <typeref>uint16</typeref> </capability> </capabilities> <events baseid="3"> <event eventid="1"> <name>delneighbor</name> <synopsis>delete a neighbor entry record</synopsis> <eventtarget> <eventfield>map</eventfield> </eventtarget> <eventdeleted/> <eventreports> <eventreport> <eventfield>map</eventfield> <eventsubscript>neighbors</eventsubscript> </eventreport> </eventreports> </event> <event eventid="2"> <name>updatemap</name> <synopsis>information from CE that new nodes are available for the datapath </synopsis> <eventtarget> <eventfield>map</eventfield> </eventtarget> <eventchanged/> <eventreports> <eventreport> <eventfield>map</eventfield> <eventsubscript>neighbors</eventsubscript> </eventreport> </eventreports> </event> <event eventid="3"> <name>setneighbor</name> <synopsis>set a neighbor entry record</synopsis> 56

57 <eventtarget> <eventfield>map</eventfield> </eventtarget> <eventcreated/> <eventreports> <eventreport> <eventfield>map</eventfield> <eventsubscript>neighbors</eventsubscript> </eventreport> </eventreports> </event> </events> </LFBClassDef> ForCES Protocol Έχοντας ορίσει το μοντέλο είναι θεμιτό να παρουσιαστούν τώρα τα βασικά στοιχεία του πρωτοκόλλου. Το πρωτόκολλο [9] δημιουργήθηκε ώστε να επιτρέπει στα CE να καθορίζουν τις δυνατότητες κάθε FE, όπως αυτές εκφράζονται από το μοντέλο. Δηλαδή το πρωτόκολλο είναι αυτό που επιτρέπει σε ένα CE να συγκεντρώνει τις απαραίτητες πληροφορίες ώστε να είναι σε θέση να ελέγξει ένα FE. Οι εντολές που χρησιμοποιούνται στο ForCES Protocol είναι μόνο οι εξής 3: 1. Get 2. Set 3. Delete Αναφορικά, ακολουθούν την δομή TLV όπως και το LLDP. Οι εντολές αυτές αλληλεπιδρούν με τα στοιχεία που είναι αποθηκευμένα και ορισμένα στα LFBs και έτσι ο controller μπορεί να διαχειριστεί το datapath. Μπορεί δηλαδή να λάβει δεδομένα, να στείλει ή και να διαγράψει στοιχεία από τους πίνακες των LFBs. Το πρωτόκολλο μπορεί να ανιχνεύει και να αλληλεπιδρά με συγκεκριμένα LFBs και FEs χρησιμοποιώντας ένα μοναδικό αναγνωριστικό κάθε LFB όπως ορίζεται και από το μοντέλο, το LFBID. Ακολουθώντας την λογική των επιπέδων (layers) το πρωτόκολλο για να ανταλλάξει τα όποια μηνύματα χρησιμοποιεί 2 επίπεδα πρωτόκολλα, το επίπεδο πρωτοκόλλου ForCES (ForCES Protocol Layer) ή PL, και το επίπεδο χαρτογράφησης μεταφοράς (Transport Mapping Layer) ή TML. Το δεύτερο είναι υπεύθυνο για την μεταφορά των μηνυμάτων μεταξύ των FE και των CE και για να το επιτύχει χρησιμοποιεί το πρωτόκολλο SCTP (Σχήμα 25). 57

58 Σχήμα 25 Διαστρωμάτωση και χρησιμοποιούμενα πρωτόκολλα του ForCES Καταστάσεις λειτουργίας ForCES To πρωτόκολλο του ForCES προκειμένου να φτάσει στο σημείο να ελέγχει και να καθορίζει το μονοπάτι των δεδομένων περνάει από δυο διαφορετικές φάσεις λειτουργίας. Αυτές είναι οι εξής 2: 1. Pre-association phase 2. Post-association phase Κατά την διάρκεια της πρώτης λειτουργίας, η οποία απαρτίζεται από τρεις υπο-φάσεις, γίνονται οι απαραίτητες ρυθμίσεις των διεπαφών του ForCES για να μπορέσει να στηθεί κατάλληλα η επικοινωνία μεταξύ των οντοτήτων αργότερα (αρχικοποίηση και εκκίνηση του TML και του PL). Στην φάση αυτή σε μια απλή στοιχειώδη εγκατάσταση οι ρυθμίσεις είναι στατικές και μπορούν για παράδειγμα να διαβαστούν από ένα αρχείο κειμένου. Με την ολοκλήρωση αυτής της φάσης όλες οι απαραίτητες παράμετροι είναι πλέον γνωστοί. Όσον αφορά την Post-association phase, τα CE και τα FE βρίσκονται πλέον σε επικοινωνία και είναι σε θέση να ανταλλάσσουν μηνύματα χρησιμοποιώντας το ForCES Protocol (π.χ. SCTP & TML). Επιπλέον, στις 58

59 λειτουργίες του ForCES συγκαταλέγονται δυνατότητες όπως high availability, two-phase commits, command pipelines κλπ. Μέχρι εδώ έχουμε παρουσιάστηκαν και αναλύθηκαν κάποια πολύ σημαντικά και βασικά χωρία της θεωρίας αρχιτεκτονικής των σύγχρονων δικτύων και έχει αναλυθεί μια διαφορετική φιλοσοφία αρχιτεκτονικής και ανάπτυξης, αυτή του Software-Defined Networking (SDN) ή των προγραμματιζόμενων δικτύων. Στο επόμενο κεφάλαιο παρουσιάζεται ο αλγόριθμος βέλτιστης ανακάλυψης της τοπολογίας που δημιουργήθηκε στην παρούσα διπλωματική και αναλύεται η μεθοδολογία που ακολουθήθηκε για την επίλυση του προβλήματος της μη αποδοτικής χρησιμοποίησης όλων των πόρων του δικτύου λόγω χρήσης πρωτοκόλλων όπως το STP. 59

60 ΕΝΌΤΗΤΑ 2 ΑΛΓΌΡΙΘΜΟΣ ΒΈΛΤΙΣΤΗΣ ΑΝΑΚΆΛΥΨΗΣ ΤΟΠΟΛΟΓΊΑΣ ΣΕ ΔΊΚΤΥΟ SDN ΜΕ ΧΡΉΣΗ ΤΟΥ FORCES 60

61 ΒΈΛΤΙΣΤΗ ΑΝΑΚΆΛΥΨΗ ΤΟΠΟΛΟΓΊΑΣ ΜΕ ΤΗΝ ΧΡΉΣΗ ΤΟΥ FORCES Όπως έχει ήδη αναλυθεί, το σημείο κλειδί για την όλη διαδικασία εκτέλεσης των βέλτιστων δρομολογήσεων είναι η γνώση της τοπολογίας του δικτύου. Το επικρατέστερο πρωτόκολλο μέχρι στιγμής για αυτόν τον σκοπό είναι το LLDP. Πρέπει να διευκρινιστεί όμως ξανά ότι η μέθοδος που προτείνεται στην παρούσα διπλωματική δεν περιορίζεται στην χρήση του LLDP για την ανακάλυψη της τοπολογίας αλλά είναι γενική. Εδώ, το πρωτόκολλο LLDP χρησιμοποιήθηκε για την απόκτηση των απαραίτητων πληροφοριών από τα switches ώστε να κατασκευάσουμε την τοπολογία. Επομένως για να αποδείξουμε ότι το σενάριο της ανακάλυψης μπορεί να εκτελεστεί βέλτιστα με αυτό το πρωτόκολλο και για τους σκοπούς των πειραμάτων που θέλαμε να υλοποιήσουμε κρίθηκε ότι το LLDP είναι κατάλληλο για τους σκοπούς μας σε ένα SDN περιβάλλον. Προτεινόμενη μέθοδος Η μέθοδος που προτείνεται για την ανακάλυψη της τοπολογίας του δικτύου στηρίζεται σε μια κεντρικοποιημένη προσέγγιση απόκτησης των πληροφοριών του δικτύου με την βοήθεια του LLDP και την χρήση του ForCES. Αφήνουμε δηλαδή το πρωτόκολλο LLDP να εκτελείται στο επίπεδο προώθησης και με την χρήση ενός LFB που έχουμε μοντελοποιήσει βάση των αναγκών μας αναγνωρίζουμε και αποθηκεύουμε τους απευθείας συνδεδεμένους κόμβους. Έπειτα ενημερώνεται σχετικά ο controller ώστε να δημιουργήσει τις απαραίτητες λογικές συνδέσεις για να σχηματιστεί ο χάρτης του δικτύου. Ας δούμε όμως την διαδικασία αναλυτικότερα. Αρχικά όπως έχει ήδη αναφερθεί, προκειμένου να είμαστε σε θέση να αναγνωρίζουμε μοναδικά ένα στοιχείο στην τοπολογία χρειαζόμαστε 3 βασικά στοιχεία: 1. MAC τοπικού μηχανήματος 2. MAC γειτονικής συσκευής 3. Port από όπου λαμβάνουμε τα πακέτα της γειτονικής συσκευής 61

62 Για να εξάγουμε αυτές της πληροφορίες χρησιμοποιήσαμε το LLDP και την βιβλιοθήκη της C, pcap.h, που επιτρέπει το capture των πακέτων στην είσοδο μιας κάρτας δικτύου πάνω στο καλώδιο. Έτσι, κάθε φορά που ένα πλαίσιο LLDP λαμβάνεται από ένα FE, το LFB που έχουμε ορίσει αναλύει την κεφαλίδα του πακέτου και ελέγχει αν αυτό το πακέτο προέρχεται από μια νέα γειτονική συσκευή. Επειδή το LLDP είναι ένα one-hop πρωτόκολλο, είμαστε σίγουροι ότι οι πληροφορίες είναι από γειτονικά μηχανήματα και δεν προέρχονται από κάποιο broadcast. Για να ενημερώνουμε τον controller για τον νέα αυτό γείτονα χρησιμοποιούμε ένα update_event. Ας δούμε όμως πως λειτουργεί ο αλγόριθμος και η εφαρμογή που υλοποιήθηκε για να χτίζει την τοπολογία του δικτύου σε ένα απλό παράδειγμα τριών κόμβων. Έστω δηλαδή μια απλή τοπολογία όπως αυτή στο σχήμα 26 παρακάτω όπου κάθε στοιχείο στο επίπεδο προώθησης έχει αποθηκευμένα τα στοιχεία από τους γείτονές του και μόλις έχουμε εισάγει στην τοπολογία το FE που περικλείεται από το κόκκινο πλαίσιο. Σχήμα 26 Εισαγωγή νέου στοιχείου σε μια τοπολογία 62

63 Διαδικασία ανακάλυψης νέου κόμβου Ας δούμε πρώτα τα βασικά βήματα του προτεινόμενου αλγόριθμου για την ανακάλυψη της τοπολογίας με την βοήθεια ενός διαγράμματος ροής: Διάγραμμα ροής 63

64 Η μεθοδολογία και τα βήματα του αλγορίθμου που προτείνεται στην παρούσα διπλωματική για την ανακάλυψη του νέου κόμβου και κατ' επέκταση της τοπολογίας είναι η εξής. 1. Το στοιχείο προώθησης πραγματοποιεί την απαραίτητη σύνδεση με τον controller Ο controller αναμένει να συνδεθούν μαζί του τα όποια στοιχεία προώθησης. 64

65 2. Ο controller αντιλαμβάνεται την αλλαγή και προσθέτει τον νέο κόμβο στην ήδη υπάρχουσα τοπολογία χωρίς λογικές συνδέσεις. Το FE εκκινεί την λειτουργία του, συνδέεται με τον controller, και με την χρήση του LFB ακούει σε όλες τις πόρτες του για LLDP πακέτα ώστε να ανιχνεύσει τους όποιους γείτονές του. 65

66 3. Προκειμένου να γίνουν άμεσα αντιληπτές οι αλλαγές στην τοπολογία, ο τρόπος που έχουμε μοντελοποιήσει το LFB ορίζει την στιγμή που συνδέουμε το νέο FE στο δίκτυο να στέλνεται άμεσα ένα LLDP πλαίσιο σε όλους τους συνδεδεμένους κόμβους ώστε να ενημερώνεται άμεσα η τοπολογία και ο controller. 4. Λαμβάνοντας ο γειτονικός κόμβος το LLDP πλαίσιο και αναγνωρίζοντας ότι πρόκειται για έναν νέο κόμβο ενεργοποιεί ένα update_event ώστε να ενημερώσει κατάλληλα τον controller με τις πληροφορίες του νέου κόμβου ώστε να αλλάξει την τοπολογία και να εκτελέσει τις κατάλληλες τροποποιήσεις. 66

67 67

68 5. Αφού λοιπόν καθοριστεί η νέα τοπολογία με έναν γράφο ο οποίος ορίζει τις λογικές συνδέσεις μεταξύ των κόμβων, εφαρμόζεται ένας αλγόριθμος δρομολόγησης. Έπειτα στέλνονται μέσω του ForCES οι κατάλληλες εντολές ώστε να οριστεί το βέλτιστο μονοπάτι για την κίνηση στο επίπεδο προώθησης. 68

69 Μπορούμε δηλαδή να έχουμε πλήρη και αποδοτική χρησιμοποίηση όλων των πόρων του δικτύου μας χωρίς να αποκόπτουμε ζεύξεις για την αποφυγή κλειστών βρόχων. Αυτό συμβαίνει γιατί εφόσον έχουμε πλήρη και κεντρικοποιημένη εποπτεία του μονοπατιού των δεδομένων στο επίπεδο προώθησης, μπορούμε να ορίσουμε τις διαδρομές κατάλληλα χωρίς την χρήση πρωτοκόλλων όπως το STP. Έχουμε δηλαδή πλέον την δυνατότητα να αλλάζουμε δυναμικά την τοπολογία του δικτύου μας και να υπαγορεύουμε στους μεταγωγείς τον τρόπο με τον οποίο θέλουμε να διαχειρίζονται την κίνηση. Προστίθεται δηλαδή η δυνατότητα πραγματοποίησης διαχείρισης φόρτου κίνησης στο δίκτυο μας αλλά και μειώνουμε σημαντικά, όπως θα δούμε και στις μετρήσεις στην συνέχεια, τον χρόνο απόκρισης στις όποιες αλλαγές και στην επικοινωνία μεταξύ επιπέδου ελέγχου και προώθησης. Μειώνουμε ακόμα την κίνηση που έπρεπε να δημιουργείται κάθε φορά από τον controller για να εκτελεί την διαδικασία της ανακάλυψης σε τακτά χρονικά διαστήματα. Όπως αναφέρεται [5], αυτή η κίνηση είναι ικανή να προκαλέσει αυξημένο φόρτο ή ακόμα και διακοπή σε ένα δίκτυο. Όμως, με την μέθοδο που χρησιμοποιήσαμε, η διαδικασία αυτή είναι πλέον δυναμική και αυτόματη. 69

70 Αποτελέσματα προτεινόμενης μεθόδου Η διαδικασία που προτείνεται για την ανακάλυψη της τοπολογίας μπορεί να μειώσει σημαντικά τον χρόνο ανακάλυψης, όπως διαπιστώσαμε και πειραματικά εκτελώντας μετρήσεις σε ένα δίκτυο μικρής κλίμακας. Ειδικότερα οι μετρήσεις πραγματοποιήθηκαν σε μια τοπολογία παρόμοια με αυτή του σχήματος 27 που παρουσιάστηκε προηγουμένως. Σαν controller χρησιμοποιήθηκε ένα φυσικό μηχάνημα (Pentium 4, 3.2Ghz 2 Gb Ram) με εγκατεστημένη την εφαρμογή διαχείρισης των στοιχείων προώθησης που κατασκευάσαμε για τις ανάγκες της διπλωματικής. Ακόμα τροποποιήσαμε κατάλληλα το hardware του controller προσθέτοντάς του επιπλέον κάρτες δικτύου FastEthernet. Στο επίπεδο προώθησης χρησιμοποιήσαμε φυσικά και εικονικά μηχανήματα διασυνδεδεμένα μεταξύ τους στα οποία εγκαταστήσαμε το ForCES και το LLDP. Tροποποιήσαμε στην συνέχεια το λειτουργικό σύστημα Linux (Ubuntu kernel build ) ώστε να συμπεριφέρεται σαν switch. Χρησιμοποιώντας το πρωτόκολλο ForCES μπορέσαμε να εδραιώσουμε την επικοινωνία μεταξύ forwarding και control plane. Αφήσαμε ύστερα τα FEs να ανταλλάξουν μηνύματα και να ενημερώσουν τον controller για τους γείτονές τους. Η διαδικασία αυτή επαναλήφθηκε πολλές φορές και τα αποτελέσματα παρουσιάζονται συγκεντρωτικά στον παρακάτω πίνακα 2. Όπως παρατηρούμε ο μέσος χρόνος που χρειάζεται ο controller για να αντιληφθεί και να εισάγει έναν νέο κόμβο στην τοπολογία είναι περίπου 12 milliseconds. Πίνακας 2 Αποτελέσματα μετρήσεων χρόνου ανακάλυψης τοπολογίας 70

71 Αναλογιζόμενοι το χαμηλών επιδόσεων υλικό που χρησιμοποιήσαμε για να υλοποιήσουμε το testbed για τις μετρήσεις μας και συγκρίνοντας τα αποτελέσματα με έναν υπάρχον εμπορικό controller [10], συμπεραίνουμε ότι ο τρόπος που προτείνεται βελτιώνει κατά 90% τον χρόνο ανακάλυψης της τοπολογίας. Όσον αφορά τον χρόνο που χρειάζεται για να αντιληφθεί ο controller ότι μια ζεύξη δεν λειτουργεί, αυτός εξαρτάται από το διάστημα που μεσολαβεί για να λάβει ένας γειτονικός κόμβος ένα πλαίσιο LLDP. O προκαθορισμένος χρόνος που το LLDP στέλνει τα advertisement μηνύματα είναι 30 δευτερόλεπτα. Αν ένας κόμβος δεν λάβει κάποιο μήνυμα από έναν κόμβο με τον οποίο επικοινωνούσε προηγουμένως σε αυτό το χρονικό διάστημα τότε ενημερώνει τον controller κατάλληλα με κάποιο event ώστε να αλλάξει η τοπολογία. Αυτό το διάστημα μπορεί να αλλάξει (εύρος seconds) ώστε το σύστημα να είναι πιο δυναμικό και λιγότερο ανεκτικό σε καθυστερήσεις που μπορεί να προκύψουν. Επαναπροσδιορισμός των δρομολογήσεων Προκειμένου να ορίσουμε νέες διαδρομές για την εισερχόμενη και εξερχόμενη κίνηση στο επίπεδο προώθησης, πρέπει να εφαρμόζουμε εκ νέου έναν αλγόριθμο δρομολόγησης κάθε φορά που συμβαίνει κάποια αλλαγή στην τοπολογία. Για τους σκοπούς της διπλωματικής εφαρμόσαμε επιτυχώς τον αλγόριθμο Dijkstra στον γράφο που δημιουργεί ο controller κάθε φορά που σχηματίζει τον χάρτη του δικτύου. Ο αλγόριθμος αυτός εφαρμόζεται αυτόματα κάθε φορά που η τοπολογία αλλάζει. Αντί του Dijkstra μπορούμε να υλοποιήσουμε και εφαρμόσουμε οποιονδήποτε άλλον αλγόριθμο δρομολόγησης αλλά ο συγκεκριμένος μπορεί να βελτιστοποιηθεί [11] και να έχουμε καλύτερα αποτελέσματα στον καθορισμό των διαδρομών. 71

72 ΣΥΜΠΕΡΆΣΜΑΤΑ & ΜΕΛΛΟΝΤΙΚΉ ΈΡΕΥΝΑ Στην παρούσα διπλωματική εργασία παρουσιάστηκε ένας βέλτιστος τρόπος ανακάλυψης της τοπολογίας του δικτύου που μπορεί να εφαρμοστεί σε προγραμματιζόμενα δίκτυα. Συμπεραίνεται ότι το LLDP μπορεί να χρησιμοποιηθεί αποδοτικά για αυτούς τους σκοπούς μειώνοντας παράλληλα τον φόρτο εργασίας από τον controller (περίπτωση OpenFlow) ο οποίος δεν χρειάζεται να εκκινεί κάποια διαδικασία για να πραγματοποιήσει την ανακάλυψη της τοπολογίας. Περιγράφτηκε ακόμα ένα μοντέλο βασισμένο στο ForCES, το οποίο επιτρέπει στον controller να συλλέγει αυτόματα και δυναμικά όλες τις πληροφορίες που αφορούν την τοπολογία του δικτύου και κατ' επέκταση να μπορεί να εφαρμόζει βέλτιστες δρομολογήσεις. Επομένως όλοι οι κόμβοι και οι ζεύξεις του δικτύου μπορούν να είναι ενεργές και να συμμετέχουν στην διαχείριση της κίνησης χωρίς να χρειάζεται να αποκόπτουμε links για την αποφυγή βρόχων, αφού ο ελεγκτής έχει πλήρη εποπτεία και μπορεί να διαχειρίζεται την δρομολόγηση αυτόματα σε περίπτωση βλάβης. Στα πειράματα που πραγματοποιήθηκαν σε ένα δίκτυο μικρής κλίμακας παρατηρήσαμε ότι επιτεύχθηκε μείωση του χρόνου ανακάλυψης νέων κόμβων κατά 90%. Μελλοντικά προβλέπεται να πραγματοποιηθούν πειράματα και σε δίκτυο μεγάλης κλίμακας με αποδοτικότερο hardware για την εξέταση των πλεονεκτημάτων της μεθόδου αυτής στην διαχείριση του φόρτου της κίνησης. Ακόμα, προτείνεται να τροποποιηθεί ο προτεινόμενος αλγόριθμος ώστε η ανακάλυψη της τοπολογίας να συμβαίνει και με την χρήση άλλων πρωτοκόλλων εκτός του LLDP. Από κάποιες πρώτες ενδείξεις φαίνεται ότι το Address Resolution Protocol ή ARP θα μπορούσε να χρησιμοποιηθεί για αυτόν τον σκοπό [12]. Με αυτόν τον τρόπο θα μπορούμε να πραγματοποιούμε ανακάλυψη της τοπολογίας και σε ετερογενή ή υβριδικά δίκτυα ώστε να εφαρμόζονται αποδοτικότερα οι όποιοι αλγόριθμοι δρομολόγησης αλλά και να έχουμε καλύτερη εποπτεία και αποκατάσταση του δικτύου. Συμπερασματικά, μπορούμε να ισχυριστούμε ότι η φιλοσοφία της κεντρικοποιημένης ανακάλυψης τοπολογίας του δικτύου που προτείνεται μπορεί να ακολουθηθεί από το μεγαλύτερο μέρος των neighbor discovery πρωτοκόλλων. Αυτή η φιλοσοφία θα επιτρέψει την αποδοτική ανακάλυψη της τοπολογίας του δικτύου και των προϊόντων της (δρομολόγηση) σε πολύπλοκα περιβάλλοντα δικτύων, προγραμματιζόμενα ή κλασσικά. Στην επόμενη ενότητα ακολουθεί ο κώδικας υλοποίησης σε γλώσσα C και το ForCES xml μοντέλο που χρησιμοποιήθηκε. 72

73 ΕΝΌΤΗΤΑ 3 ΠΑΡΆΘΕΣΗ ΚΑΙ ΕΠΕΞΉΓΗΣΗ ΚΏΔΙΚΑ ΥΛΟΠΟΊΗΣΗΣ 73

74 ΣΥΝΟΠΤΙΚΉ ΕΠΕΞΉΓΗΣΗ ΚΏΔΙΚΑ Το πρόγραμμα αποτελείται από δυο επί μέρους κομμάτια. Αυτό το οποίο τρέχει στο επίπεδο προώθησης και υλοποιείται σαν LFB με το μοντέλο του ForCES και αυτό το οποίο τρέχει στο επίπεδο ελέγχου και διαχειρίζεται και συλλέγει τις πληροφορίες από τα LFB. Όλος ο κώδικας βασίστηκε στο μοντέλο που δημιουργήθηκε και που περιγράφεται παρακάτω. Ας δούμε πρώτα όμως συνοπτικά την λειτουργία κάθε μέρους κάνοντας άμεση αναφορά στον κώδικα της υλοποίησης που παρατίθεται αργότερα. Οπτική του fe... Αρχικά το LFB συνδέεται στον controller σε μια συγκεκριμένη ip και port. Για να λάβει τις συνδέσεις ο controller καλεί την συνάρτηση Infomgmt() η οποία είναι υπεύθυνη για την διαχείριση των συνδέσεων, τις ρυθμίσεις των sockets, για να λαμβάνει εντολές κλπ. Μέσω της συνάρτησης findalldevs() και της βιβλιοθήκης pcap γίνεται η ανακάλυψη όλων των διαθέσιμων nic στα οποία μπορεί να υπάρξει πακετική κίνηση. Ανάλογα με το πλήθος των nic καλούνται τα αντίστοιχα posix threads με την συνάρτηση devproc() και ορίζεται ένας σεμαφόρος για την προστασία κάποιων μεταβλητών που μπορεί να χρησιμοποιούνται ταυτόχρονα. Ειδικότερα η devproc() δημιουργεί ένα thread για ένα nic το οποίο ακούει μόνο στην εισερχόμενη κίνηση LLDP πλαισίων (βάση του ethertype 0x88cc) καλώντας μια loopback συνάρτηση της pcap. Όσα interfaces δεν είναι τύπου ethernet γίνονται kill. Όταν ανιχνευτεί ένα πακέτο, και κατ' επέκταση ένας νέος γείτονας, καλείται η συνάρτηση showframe_callback() με την βοήθεια της οποίας αποθηκεύονται σε έναν δυναμικά αυξανόμενο πίνακα τα δεδομένα για αυτό τον νέο κόμβο. Τα δεδομένα που συλλέγονται είναι: Τοπική MAC Γειτονική MAC Port που έγινε η λήψη Πακέτα LLDP που έχουν μετρηθεί έως τώρα Η χρονοσφραγίδα του τελευταίου πακέτου 74

75 Τα δυο τελευταία στοιχεία αποθηκεύονται για αποσφαλμάτωση και στατιστικούς λόγους. Οπτική του controller... Ουσιαστικά δρα σαν ένας echo-server. Αρχικά κάνει bind σε μια συγκεκριμένη port και ip και ξεκινά να ακούει για συνδέσεις από το fe. Προσφέρει ακόμα την δυνατότητα στον χρήστη να εισάγει εντολές μέσω ενός διαδραστικού cli. Ενδεικτικά οι εντολές και οι δυνατότητες περιγράφονται παρακάτω: q c g s d r h k u x e query local neighbor database connection manager get set del routing info and actions print this menu print statistics manual update event notifier clear screen exit program Οι εντολές του ForCES get/set/delete υλοποιούνται απο τις αντίστοιχες συναρτήσεις get_handler(), set_handler(), del_handler(). Για την διευκόλυνση του χρήστη δημιουργήθηκε και η ρουτίνα get_all() με την οποία λαμβάνονται αυτόματα όλα τα στοιχεία από τον πίνακα ενός fe. Η συνάρτηση choose_connection() προβάλλει όλες τις διαθέσιμες συνδέσεις με τα forwarding elements και δίνει επιπλέον την δυνατότητα στον χρήστη να αλληλεπιδράσει με ένα συγκεκριμένο fe σύμφωνα με την ip του. Η συνάρτηση local_query() επιτρέπει την εποπτεία όλων των δεδομένων που έχουν ληφθεί από τα fe. Τέλος, οι δρομολογήσεις συμβαίνουν με την χρήση της συνάρτησης create_graph(), η οποία δημιουργεί έναν γράφο με βάση τα στοιχεία που έχουν ληφθεί από τα FE κάνοντας τις κατάλληλες λογικές διασυνδέσεις μεταξύ των 75

76 στοιχείων (ίδια στοιχεία με αυτά που παρουσιάζονται από την local_query()). Η ρουτίνα reveal_graph() παρουσιάζει αυτόν τον γράφο με την μορφή ενός adjacency matrix και με την βοήθεια της συνάρτησης dijkstra(int graph[max_nodes][max_nodes],int vertices, int startnode) υπολογίζονται και τίθενται οι βέλτιστες διαδρομές από κάθε πιθανό κόμβο προς κάποιον άλλον. Παρακάτω ακολουθεί το μοντέλο και ο κώδικας υλοποίησης. FORCES MODEL To ForCES model που χρησιμοποιήθηκε <?xml version="1.0" encoding="utf-8"?> <LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0" xmlns:xsi=" provides="lldump"> <framedefs> <framedef> <name>lldp</name> <synopsis>an LLDP Ethernet frame [0x88cc]</synopsis> <description>this frame type refers to an lldp Ethernet frame being received</description> </framedef> </framedefs> <datatypedefs> <datatypedef> <name>neighbors_entry</name> <synopsis>info for neighbors </synopsis> <struct> <component componentid="1"> <name>source</name> <synopsis>local machine's 48bit IEEE mac address</synopsis> <typeref>byte[6]</typeref> </component> <component componentid="2"> <name>local_remote</name> <synopsis>neighbor's 48bit IEEE mac addresses from discovery process</synopsis> <typeref>byte[6]</typeref> </component> <component componentid="3"> <name>devport</name> <synopsis>the port from which the capture is done from FE</synopsis> <typeref>uint16</typeref> </component> </struct> </datatypedef> <datatypedef> <name>stats_entry</name> <synopsis>statistics entry</synopsis> <struct> 76

77 <component componentid="1"> <name>packetcounter</name> <synopsis>packet counter for lldp packets received from FE</synopsis> <atomic> <basetype>uint32</basetype> </atomic> </component> <component componentid="2"> <name>timestamp</name> <synopsis>whenever an LLDP packet is received the capture time is logged</synopsis> <atomic> <basetype>uchar</basetype> </atomic> </component> </struct> </datatypedef> <datatypedef> <name>lldp_info</name> <synopsis>struct containing all usable info for discovery process</synopsis> <struct> <component componentid="1"> <name>neighbors</name> <synopsis>neighbors info</synopsis> <typeref>neighbors_entry</typeref> </component> <component componentid="2"> <name>stats</name> <synopsis>stats info</synopsis> <typeref>stats_entry</typeref> </component> </struct> </datatypedef> </datatypedefs> <LFBClassDefs> <LFBClassDef LFBClassID="1024"> <name>lldump</name> <synopsis>lldump is used for capturing lldp frames and collecting neighbor's info</synopsis> <version>1.0</version> <inputports> <inputport group="true"> <name>lldpin</name> <synopsis>ports listening for lldp packets</synopsis> <expectation> <frameexpected> <ref>lldp</ref> </frameexpected> </expectation> </inputport> </inputports> <outputports> <outputport> <name>lldpout</name> <synopsis>ports for advertising local machine to neighbors sending LLDP packets</synopsis> 77

78 <product> <frameproduced> <ref>lldp</ref> </frameproduced> </product> </outputport> </outputports> <components> <component componentid="1" access="read-write"> <name>map</name> <synopsis>variable sized array containing stats and info per neighbor</synopsis> <array> <typeref>lldp_info</typeref> </array> </component> </components> <capabilities> <capability componentid="2"> <name>maxdevs</name> <synopsis>maximum local devices/ports from which discovery can be done simultaneously</synopsis> <typeref>uint16</typeref> </capability> </capabilities> <events baseid="3"> <event eventid="1"> <name>delneighbor</name> <synopsis>delete a neighbor entry record</synopsis> <eventtarget> <eventfield>map</eventfield> </eventtarget> <eventdeleted/> <eventreports> <eventreport> <eventfield>map</eventfield> <eventsubscript>neighbors</eventsubscript> </eventreport> </eventreports> </event> <event eventid="2"> <name>updatemap</name> <synopsis>information from CE that new nodes are available for the datapath</synopsis> <eventtarget> <eventfield>map</eventfield> </eventtarget> <eventchanged/> <eventreports> <eventreport> <eventfield>map</eventfield> <eventsubscript>neighbors</eventsubscript> </eventreport> </eventreports> </event> <event eventid="3"> <name>setneighbor</name> 78

79 <synopsis>set a neighbor entry record</synopsis> <eventtarget> <eventfield>map</eventfield> </eventtarget> <eventcreated/> <eventreports> <eventreport> <eventfield>map</eventfield> <eventsubscript>neighbors</eventsubscript> </eventreport> </eventreports> </event> </events> </LFBClassDef> </LFBClassDefs> </LFBLibrary> ΥΛΟΠΟΊΗΣΗ ΤΟΥ CONTROLLER Υλοποίηση κύριας συνάρτησης και χειρισμός συνδέσεων /********************************************************************** * file: controller.c v.3.2 * * Author:Tarnaras George * Date: * * Programme running on the controller to get info from FE (acts as a server based on ForCES architecture) * Routing information is also available with this version * * IMPORTANT: * Compile with: * gcc -g -Wall -pedantic controller.c controller_routing controller_routines.c controller_events.c controller_interface.c -pthread -o controller * * Usage: Run./controller <port> * No need to run as root ********************************************************************* <sys/socket.h> <netinet/in.h> <arpa/inet.h> <stdio.h> <stdlib.h> <unistd.h> <errno.h> <string.h> <sys/types.h> <time.h> <semaphore.h> <pthread.h> "controller_header.h" 79

80 int main(int argc, char **argv) /*initialize elements for dynarrays to zero num_elements=0; //struct info num_allocated=0; FEnum_elements=0; FEnum_allocated=0; //struct handlers connections=0; //connection counter concount=0; initialize_nodes=0; int counter=0,trigger,event; int optval; /* flag value for setsockopt int portno; /* port to listen on if (argc!= 2) fprintf(stderr, "usage: %s <port>\n", argv[0]); exit(1); portno = atoi(argv[1]); //convert port to use it /* create, initialize semaphore if( sem_init(&mutex,1,1) < 0) perror("semaphore initilization error"); exit(0); /*Create parent socket descriptors listener= socket(af_inet, SOCK_STREAM, 0); if (listener == -1) printf("\ncould not create controller socket\n"); exit(1); /* Eliminates "ERROR on binding: Address already in use" error. optval = 1; setsockopt(listener, SOL_SOCKET, SO_REUSEADDR,(const void *)&optval, sizeof(int)); /*Create the server's address serv_addr.sin_family = AF_INET; serv_addr.sin_addr.s_addr = htonl(inaddr_any); serv_addr.sin_port = htons((unsigned short)portno); /* bind: associate the parent socket with a port if(bind(listener, (struct sockaddr*)&serv_addr, sizeof(serv_addr))<0) puts("bind failed"); exit(1); printf("\nbind done...listening for clients on port: %d \n",portno); /*Start listening for FE connection requests. Set the waiting queue as defined in dynarrays.h if(listen((listener), FEQueueSize)<0) puts("error on listen"); return 1; clientlen = sizeof(client_addr); event_port=portno+1; 80

81 trigger = pthread_create( &tid[tcount], NULL,create_event, NULL); sleep(1); tcount++; //increase thread counter for future use loop:;//infinite loop! /*Create a thread for interactive communication with user trigger = pthread_create( &tid[tcount], NULL,command_handler, NULL); sleep(1); tcount++; //increase thread counter for future use /*Start looping, reading, storing neighbors data to map while(1) connfd = accept(listener, (struct sockaddr*)&client_addr, (&clientlen)); //fcntl(connfd, F_SETFL, O_NONBLOCK); /* Change the socket into non-blocking state command c) state connfdset=connfd; //set the handler to the last connected fe(change via //fcntl(connfdset, F_SETFL, O_NONBLOCK); /* Change the socket into non-blocking handlers.listenfd=connfd; //printf("\n>fe %s connected succesfully \n", inet_ntoa(client_addr.sin_addr)); snprintf(handlers.connip, sizeof(handlers.connip), "%s", inet_ntoa(client_addr.sin_addr)); //save connections to struct snprintf(handlers.link_state, sizeof(handlers.link_state), "active"); //save connections to struct printf("\n> "); fflush(stdout); connections++; concount++; //connection counters for stat printing and checking if discovery started connection_handler(); //~ trigger = pthread_create( &tid[tcount], NULL,connection_handler, NULL); //~ if (trigger!= 0) //~ //~ printf("\ncan't insert connection id :[%s]\n", strerror(trigger)); //~ //~ tcount++; //increase thread counter if (connfd<0) perror("failed to accept FE\n"); /*wait for threads to finish for(counter=0;counter<=tcount;counter++) pthread_join( tid[tcount], NULL); goto loop; /*infinite loop... /*Cleanup and say goodbye printf("closing server..."); close(connfd); return 0; 81

82 Υλοποίηση του μηχανισμού των events μεταξύ CE-FE /********************************************************************** * file: controller_events.c v.3.2 * * Author:Tarnaras George * Date: * * Controls events and updates in bidirectional link FE-CE * * * ********************************************************************* <sys/socket.h> <netinet/in.h> <arpa/inet.h> <stdio.h> <stdlib.h> <unistd.h> <errno.h> <string.h> <sys/types.h> <time.h> <semaphore.h> <pthread.h> "controller_header.h" /* Create a socket and handle connections from FEs. This port is used only for events void create_event() int event; /*Create parent socket descriptors event_listener= socket(af_inet, SOCK_STREAM, 0); if (event_listener == -1) printf("\ncould not create controller event socket\n"); exit(1); /* Eliminates "ERROR on binding: Address already in use" error. int optvalue = 1; setsockopt(event_listener, SOL_SOCKET, SO_REUSEADDR,(const void *)&optvalue, sizeof(int)); /*Create the server's event address, on port=portno+1 event_addr.sin_family = AF_INET; event_addr.sin_addr.s_addr = htonl(inaddr_any); event_addr.sin_port = htons((unsigned short)event_port); /* bind: associate the parent socket with a port if(bind(event_listener, (struct sockaddr*)&event_addr, sizeof(event_addr))<0) puts("bind failed"); exit(1); printf("\nbind done...listening for events on port: %d\n",event_port); /*Start listening for FE event connection requests. Set the waiting queue as defined in dynarrays.h if(listen((event_listener), FEQueueSize)<0) puts("error on event listen"); 82

83 eventclientlen = sizeof(client_addr); /*Start looping and interact with fe for updates/events while(1) event_connfd = accept(event_listener, (struct sockaddr*)&client_addr, (&eventclientlen)); event_connfdset=event_connfd; event_handlers.event_listenfd=event_connfd; //save to struct snprintf(event_handlers.event_connip, sizeof(event_handlers.event_connip), "%s", inet_ntoa(client_addr.sin_addr)); //save to struct snprintf(event_handlers.event_link_state, sizeof(event_handlers.event_link_state), "active"); //save to struct /*insert event handler element to array if (AddEventConnection(event_handlers) == -1) fprintf(stdout,"failed inserting data to events handlers"); if((event = read(event_connfdset, event_buff, sizeof(event_buff))) > 0) fprintf(stdout,"\n/* EVENT * \n"); fprintf(stdout,"update from FE: %s \n",event_buff); event_buff[n] = '\0'; //sleep(1); create_graph(); sleep(1); fprintf(stdout,"\ndijkstras unique nodes: %d\n",nodenum_elements); reveal_graph(); metra(); /* Handle update events, according to specific connection handler int update_handler(int event_connection) if(connections>0) //~ printf("\n=========event action========\n"); memset(event_buff, 0, sizeof(event_buff)); snprintf(event_buff,sizeof(event_buff),"routing and neighbor info has changed/updated"); /*Index we send to FE MSG_WAITALL if((send(event_connection, event_buff, sizeof(event_buff), 0))<=0) //~ fprintf(stderr, "Failure Sending Data\n"); close(event_connection); notify_failure(event_connection); //if send event fails then we probably have a conection down and we inform the other fes else //all good close socket and wait //~ fprintf(stdout,"fe informed!\n"); //~ printf("\n> "); close(event_connection); return 0; //~ sleep(1); /* When a device is down and controller cannot connect to it the inform all othes fes *this function handle the announcement to other fes int notify_failure(int event_descriptor) 83

84 int checker=0,i,checkid,j=0; for(i=0;i<=fenum_elements;i++) if(event_connid[i].event_feid.event_listenfd==event_descriptor) checkid=i; //find the row pointing to the failed connection break; snprintf(event_connid[checkid].event_feid.event_link_state, sizeof(event_connid[checkid].event_feid.event_link_state), "down"); //update connection state while(checker<=fenum_elements) if(strcmp(event_connid[checkid].event_feid.event_connip,connid[checker].feid.connip)==0) //find the down ip in connection struct and update the connection state snprintf(connid[checker].feid.link_state, sizeof(connid[checker].feid.link_state), "down"); break; checker++; for(j=0;j<fenum_elements;j++) //inform all available connection handlers(fes) for port down event_connfdset=event_connid[j].event_feid.event_listenfd; if(checkid!=event_connfdset) //leave out down ip down_handler(event_connfdset,checkid); sleep(1); return 0; /* function sending down to fes int down_handler(int event_connection,int fedown)//conn handler, struct row if(connections>0) //~ printf("\n=========event action========\n"); memset(event_buff, 0, sizeof(event_buff)); snprintf(event_buff,sizeof(event_buff),"fe %s down",event_connid[fedown].event_feid.event_connip); //pass the command argument /*Index we send to FE MSG_WAITALL if((send(event_connection, event_buff, sizeof(event_buff), 0))==-1) //~ fprintf(stderr, "Failure Sending Data\n"); close(event_connection); return 1; else sleep(1); //~ fprintf(stdout,"fe informed!\n"); //~ printf("\n> "); close(event_connection); return 0; /* function for updating all fes automatically int update_all(void) int j=0; if(connections>0) from CLI 84

85 for(j=0;j<fenum_elements;j++) event_connfdset=event_connid[j].event_feid.event_listenfd; update_handler(event_connfdset); //send updates to fes sleep(1); return 0; //~ else //~ //~ printf(">no connections yet...drink a coffee and wait...\n"); //~ printf("\n> "); //~ return 1; //~ /* Create struct with unique event ID's so we can serve multiple event clients simultaneously according their fd int AddEventConnection (struct event_allcons connitem) int enter=0,checker=0; while(checker<=(event_fenum_elements-1)) if(strcmp(event_connid[checker].event_feid.event_connip,connitem.event_feid.event_connip)==0) /*If connection already exists do not add it and update handlers event_connid[checker].event_feid.event_listenfd=event_connfd; enter=1; checker++; if(enter==0) /*If used elements exceed the limit double the size of our array if(event_fenum_elements ==event_fenum_allocated) if (event_fenum_allocated == 0) event_fenum_allocated = 3; else event_fenum_allocated *= 2; event_allcons))); /*make reallocation using temporary values void *_tmp = realloc(event_connid, (event_fenum_allocated * sizeof(struct /*check for errors and inform the user about memory allocation if (!_tmp) fprintf(stderr, "ERROR: Couldn't realloc return(-1); events memory!\n"); /*pass data into the dyn struct event_connid = (struct event_allcons*)_tmp; /*save into the database "id" event_connid[event_fenum_elements] = connitem; event_fenum_elements++; return event_fenum_elements; 85

86 Ηeader αρχείο που περιέχει απαραίτητες μεταβλητές και πίνακες /********************************************************************** * file: controller_header.h v.3.2 * * Author:Tarnaras George * Date: * * * Header file providing globals and dynarrays potential if needed. * * ********************************************************************* #ifndef CONTROLLER_HEADER_H_ #define CONTROLLER_HEADER_H_ /* Attention changing the buffer size both on controller and fe programme for the struct info #define BuffSize 90 //default buffer size used for transactions with fe #define commandsize 8 //command size for get/set/del etc. #define FEQueueSize 3 //listen queue size #define nhandlers 20 //max fd handlers for connections #define nthreads 40 //max threads we can create #define max_nodes 80 //dijkstras graph max nodes #define infinite 999 //infinite distance for nodes not yet been discovered on dijkstras algorithm /* ************************************************************************************************ /* **************************************GENERAL VARS****************************************** /* ************************************************************************************************ FILE *file; time_t ticks; sem_t mutex; callback function FILE *topology; /*Create a logfile for info storing /*use it for timestamp /*mutual exclusion for critical section into /*the file where we re saving topology matrix /* ************************************************************************************************ /* **************************************SOCKET THINGS****************************************** /* ************************************************************************************************ int n,tcount,event_port; //counter and thread counter int connections,concount,connfd,event_connfd; //count connections etc, accept fd /* Socket things struct sockaddr_in serv_addr,client_addr,event_addr; socklen_t clientlen,eventclientlen; /* Select client int connfdset,event_connfdset; int listener,event_listener; //handlers.listenfd int ferows,destid,globrow; //number of fe rows, destid for setting a specific destination /* newly accept()ed socket descriptor //connfd 86

87 /* ************************************************************************************************ /* *******************************************BUFFERS******************************************** /* ************************************************************************************************ /* Buffers used char recvbuff[buffsize],buff[buffsize],tempbuff[buffsize],event_buff[buffsize]; //general buf pthread_t tid[nthreads]; //max threads we can create char command[commandsize]; //use for command input /* ************************************************************************************************ /* **************************************MAP ELEMENTS******************************************* /* ************************************************************************************************ /* Arrays elements int num_elements ; /*To keep track of the number of elements used in NEIGHBORS array int num_allocated ; /*This is essentially how large the array is /*struct for saving all device's neighbor and infos struct compass char source[18]; /*the nic address from which we capture char capfrom[18]; /*addresses from received packets-->neighbors char devport[5]; /*the port from which we capture ; struct statistics uint16_t packetnum; char timestamp[25]; ; struct info struct compass neighbors; struct statistics stats; ; struct info *map ; //the struct we need for general use all info in there! /* ************************************************************************************************ /* *********************************DESCRIPTORS ELEMENTS*************************************** /* ************************************************************************************************ int FEnum_elements ; array int FEnum_allocated ; /*This is essentially how large the array is /* Descriptor struct etc struct descriptors int listenfd; char connip[128]; //handler //ip ; char link_state[64]; /*To keep track of the number of elements used in DESCRIPTORS //active/down struct allcons struct descriptors FEid; ; 87

88 struct descriptors handlers; struct allcons *connid; //use it in main for saving unique fd handler and ip //dyn grow handlers and use them globally connid[i].feid.listenfd /* ************************************************************************************************ /* Descriptors we use for events on port ==> portnno+1 int event_fenum_elements ; /*To keep track of the number of elements used in DESCRIPTORS array int event_fenum_allocated ; /*This is essentially how large the array is /* Descriptor struct etc struct event_descriptors int event_listenfd; char event_connip[128]; char event_link_state[64]; ; struct event_allcons struct event_descriptors event_feid; ; struct event_descriptors event_handlers; handler and ip struct event_allcons *event_connid; connid[i].feid.listenfd //use it in main for saving unique fd //dyn grow handlers and use them globally /* ************************************************************************************************ /* ************************************DIJKSTRA'S ELEMENTS************************************** /* ************************************************************************************************ int NODEnum_elements ; array int NODEnum_allocated ; /*To keep track of the number of elements used in DESCRIPTORS /*This is essentially how large the array is int initialize_nodes; /*avoid inserting values to map until the first elements come in int node_matrix[max_nodes][max_nodes]; /*use for creating adjacency matrix /* Nodes in dijkstras graph struct node char nodeid[18]; //nodes mac address int node_index; //nodes id ; struct node *nodes; //dyn grow array containing all useful info for Dijkstra /* ************************************************************************************************ /* ************************************FUNCTIONS USED******************************************* /* ************************************************************************************************ /* functions we use for handling messages and threads /* Get/Set/Del int get_handler(void); void get_all(int allrows,int ferows); //void for get //void for get automatically all int set_handler(void); int del_handler(void); //void for set //void for del /* Events, return 0 on success 1 on failure void create_event(); //handles sockets, accept etc for events 88

89 int update_handler(int event_connection); //function for informing specific fe according to connection handler int update_all(void); //function for automatically updating all fes int notify_failure(int event_descriptor); //function for notify fes on failure int down_handler(int event_connection,int fedown); //function sending fe failure with fe info /* CLI connections int connection_handler(void); //when a new connection is created add it to array handler void command_handler(); //main frame for entering commands etc. void choose_connection(); //function for choosing a specifique fe to deal with void local_query(); //local neighbor database query /* Routing functions int reveal_graph(void); //print all grapgh info int create_graph(void); //create a graph so we can apply dijkstra's routing algorithm void dijkstra(int graph[max_nodes][max_nodes],int vertices, int startnode); //implement dijkstras algorithm for finding minimum distance from chosen node #endif /* CONTROLLER_HEADER_H_ Υλοποίηση του cli με την δυνατότητα εισαγωγής εντολών /********************************************************************** * file: controller_interface.c v.3.2 * * Author:Tarnaras George * Date: * * * Header file providing source code and functions for controller CLI * ********************************************************************* <sys/socket.h> <netinet/in.h> <arpa/inet.h> <stdio.h> <stdlib.h> <unistd.h> <errno.h> <string.h> <sys/types.h> <semaphore.h> <pthread.h> "controller_header.h" /* Command handler from user void command_handler() printf("\n======lldump CONTROLLER v.3.1=====\n"); printf("\nq query local neighbor database\n"); printf("c connection manager\n"); printf("g get\n"); printf("s set\n"); printf("d del\n"); printf("r routing info and actions\n"); printf("h print this menu\n"); printf("k print statistics\n"); printf("u manual update event notifier\n"); printf("x clear screen\n"); printf("e exit program\n"); printf("\n=================================\n"); printf("> "); while(1) 89

90 fgets(command,commandsize, stdin); switch (command[0]) case 'u': /* query local database //update_handler(connfdset); update_all(); printf("> "); //~ getc(stdin); //get rid of buffer's remaining things fflush(stdout); break; case 'q': /* query local database printf(">quering local neighbor database...\n"); local_query(); printf("> "); fflush(stdout); break; case 'c': /* print and handle connection info if(connections>0) printf(">received %d connection requests so far.\n", connections); choose_connection(); else printf("connections so far 0\n"); printf("\n> "); fflush(stdout); break; case 'g': /* get printf(">**preparing for get**\n"); get_handler(); fflush(stdout); break; case 's': /* set printf(">**preparing for set**\n"); set_handler(); fflush(stdout); break; case 'd': /* del printf(">**preparing for del**\n"); del_handler(); fflush(stdout); break; case 'k': /*print statistics printf("\n======statistics so far======\n"); num_elements); \n",fenum_elements); FEnum_elements); ticks = time(null); fprintf(stdout,"\n%.24s\r\n",ctime(&ticks)); /*Elements used so far in arrays fprintf(stdout,"\nelement counter in neighbors struct: %d \n",num_elements); fprintf(stdout, "%d allocated, %d used so far...\n", num_allocated, fprintf(stdout,"\nelement counter in descriptor struct: %d fprintf(stdout, "%d allocated, %d used so far...\n", FEnum_allocated, fprintf(stdout,"received %d connection requests so far.\n", connections); fprintf(stdout,"\ndijkstras unique nodes: %d\n",nodenum_elements); fprintf(stdout,"\n> "); fflush(stdout); break; case 'r': /* routing stuff printf(">preparing routing info...\n"); printf("\n=======dijkstra's info=======\n"); 90

91 sleep(1); create_graph(); sleep(1); fprintf(stdout,"\ndijkstras unique nodes: %d\n",nodenum_elements); reveal_graph(); fflush(stdout); printf("\n>"); break; case 'x': /* clear screen printf(">clearing screen...\n"); sleep(1); system("clear"); printf(">"); fflush(stdout); break; case 'e': /* terminate the server printf("closing server...\n"); close(handlers.listenfd); sleep(1); exit(0); break; case 'h':/*help printf("q query local neighbor database\n"); printf("c connection manager\n"); printf("g get\n"); printf("s set\n"); printf("d del\n"); printf("r routing info and actions\n"); printf("k print statistics\n"); printf("x clear screen\n"); printf("u manual update event notifier\n"); printf("e exit program\n"); printf(">"); fflush(stdout); break; default: /* bad input printf(">unknown command\n"); printf("> "); fflush(stdout); break; 91

92 Υλοποίηση των συναρτήσεων εντολών /********************************************************************** * file: controller_routines.c v.3.2 * * Author:Tarnaras George * Date: * * * File providing source code and functions for get/set/del and connection functions * * ********************************************************************* <sys/socket.h> <netinet/in.h> <arpa/inet.h> <stdio.h> <stdlib.h> <unistd.h> <errno.h> <string.h> <sys/types.h> <semaphore.h> <pthread.h> <sys/time.h> <time.h> "controller_header.h" void metra() char buffer[30]; struct timeval tv; time_t curtime; gettimeofday(&tv, NULL); curtime=tv.tv_sec; strftime(buffer,30,"%m-%d-%y %T.",localtime(&curtime)); printf("was %s%ld\n",buffer,tv.tv_usec); return 0; /* Choose FE to connect with void choose_connection() int j=0,c=0,d=0; //~ sem_wait(&mutex); //lock connection ID printf("\n========connection Handler========\n"); fprintf(stdout,"\navailable connections are:\n"); for(j=0;j<fenum_elements;j++) /*print connections fprintf(stdout,"\nrow %d\n",j); fprintf(stdout,"ip: %s\n",connid[j].feid.connip); fprintf(stdout,"id: %d\n",connid[j].feid.listenfd); fprintf(stdout,"state: %s\n",connid[j].feid.link_state); /*set descriptor to chosen fe! fprintf(stdout,"enter ROW to choose FE or press %d for not selecting one:",fenum_elements+2); errc: scanf("%d",&c); if(c<fenum_elements) 92

93 stays the same out:; d=connid[c].feid.listenfd; //set descriptor according to row printf("setting connection handler..."); connfdset=d; for(j=0;j<fenum_elements;j++) /*set connections if(d==connid[j].feid.listenfd) globrow=j; //set unique row so when changing id the row identifiers printf("done!\n"); else if(c==(fenum_elements+2)) goto out; else printf("please choose an existing row:"); goto errc; //~ sem_post(&mutex); /* save all connections int connection_handler(void) /*insert neighbor element to our dyn. grow neighbor database called map if (AddConnection(handlers) == -1) fprintf(stdout,"failed inserting data to map"); return 1; else return 0; /* Query local database void local_query() int k=0,j=0,shift=0,rowdel; char dele[1]; //use for command input if(connections>0) printf("\n=========local Query========\n"); printf(">enter row, for revealing all database enter %d\nchoice:",num_elements+1); //enter search index fflush(stdout); scanf("%d",&k); if(k==(num_elements+1)) /*reveal all if(num_elements==0) goto error; for(j=0;j<num_elements;j++) fprintf(stdout,"row %d\n",j); fprintf(stdout,"device: %s, from %s ",map[j].neighbors.source,map[j].neighbors.devport); fprintf(stdout,"connected with device: %s \n",map[j].neighbors.capfrom); fprintf(stdout,"last packet saved on: %s \n",map[j].stats.timestamp); fprintf(stdout,"packet counted since last query %d \n",map[j].stats.packetnum); else if(k<num_elements) /*reveal specific fprintf(stdout,"device: %s, from %s ",map[k].neighbors.source,map[k].neighbors.devport); fprintf(stdout,"connected with device: %s \n",map[k].neighbors.capfrom); fprintf(stdout,"last packet saved on: %s \n",map[k].stats.timestamp); fprintf(stdout,"packets counted since last query %d \n",map[k].stats.packetnum); 93

94 else /*bad input goto error; /*provide possibility for user to delete rows printf("\n>for deleting a row enter y else press n\nchoice :"); //enter search index fflush(stdout); scanf("%s",dele); switch(dele[0]) case 'y'://delete a row printf(">enter row :"); //enter search index fflush(stdout); scanf("%s",dele); rowdel=atoi(dele); if(rowdel<=num_elements) printf("\ndeleting requested data...\n"); for(shift=rowdel;shift<=num_elements;shift++) //if del done on a row then shift data left memcpy(&map[shift+1],&map[shift],sizeof(struct info)); void *_tmp = realloc(map, (num_allocated * sizeof(struct info))); /*make sure pointer point right! buffer overflow etc. if (!_tmp) fprintf(stderr, "ERROR: Couldn't realloc memory!\n"); map = (struct info*)_tmp; num_elements=num_elements-1; //reduce counter to show previous element if(initialize_nodes==1) //check if we already created a grap otherwise do not update nodes NODEnum_elements=NODEnum_elements-2; //reduce nodes for dijkstra, every node contains 2 neighbors initialize_nodes=0; //make dijkstras graph run again from scratch printf( "****Row %d deleted succesfully!****\n", rowdel); //reply CE for success update_all(); //inform FE else error: printf("\nquery aborted or query on empty row...\n"); //something went wrong break; case 'n'://abort goto error; break; else default: /* bad input printf(">unknown command\n"); printf("> "); fflush(stdout); break; printf("no LLDP packet received yet...exiting...\n"); 94

95 /* Get command handler int get_handler(void) /*the struct we are going to use for storing neighbor info struct info info; int j=0; //~ sem_wait(&mutex); if(connections>0) //packets arrived? printf("\n=========get action========\n"); sprintf(buff,command); //pass the command argument memset(command, 0, commandsize); //clear command buffer to reuse /*choose a row to query printf(">enter row, for all rows enter *:"); fflush(stdout); scanf("%s",command); //enter search index sprintf((buff+strlen(buff))-1,command); //pass the command argument //memcpy(buff, &command,sizeof(command)); printf("\n>fetching row index: %s...\n",buff); /*Index we send to FE if((send(connfdset, Buff, sizeof(buff), 0))==-1) fprintf(stderr, "Failure Sending Index\n"); close(connfdset); //~ sem_post(&mutex); return 1; else sleep(1); /*read data ACK being received from FE while ( (n = read(connfdset, recvbuff, sizeof(recvbuff)-1)) > 0) switch(command[0]) case '*': //retrieve whole map from fe %s\n",connid[connfdset].feid.connip); id the row identifiers stays the same //memcpy(&ferows,recvbuff,sizeof(ferows)); //~ fprintf(stdout,"ip: //~ fprintf(stdout,"id: %d\n",connid[j].feid.listenfd); ferows=atoi(recvbuff); for(j=0;j<fenum_elements;j++) /*set connections if(connid[j].feid.listenfd==connfdset) globrow=j; //set unique row so when changing printf("fe with IP: %s has %d rows in total\n",connid[globrow].feid.connip,ferows); recvbuff[n] = '\0'; get_all(globrow,ferows); sleep(1); break; default: //get specific row /*print receive time on logfile file = fopen("logfilece.txt","a+"); ticks = time(null); //fprintf(file,"%.24s\r\n",ctime(&ticks)); fprintf(stdout,"receiving time %.24s\r\n",ctime(&ticks)); if(strlen(recvbuff)>5) the buffer must have at least appropriate length! //if FE/client have data to send 95

96 from FE memcpy(&info,recvbuff,sizeof(info)); /*insert neighbor database called map neighbor element to our dyn. grow if (AddToArray(info) == -1) fprintf(stdout,"failed map"); inserting data to /*Screen output fprintf(stdout, "\n%d allocated, %d used so far...\n", num_allocated, num_elements); ",info.neighbors.source,info.neighbors.devport); \n",info.neighbors.capfrom); %s fprintf(stdout,"connected with device: %s fprintf(stdout,"time last packet received: %s \n",info.stats.timestamp); ",info.neighbors.source,info.neighbors.devport); \n",info.neighbors.capfrom); /*Save data to logfile fprintf(file,"device: %s, from %s fprintf(file,"connected with device: %s /*Make sure we won't read any more from our received bufffer recvbuff[n] = '\0'; else /* clear the message buffer memset(recvbuff, 0, BuffSize); printf("\nno data send from FE\n"); /*If reading data from socket returns error if(n < 0) printf("\n Read error from socket\n"); close(connfdset); else fprintf(stdout,"succesfully received data from FE\n\n"); else fprintf(stdout,"device: %s, from fprintf(stdout,"lldp packets counted so far from FE: %d \n",info.stats.packetnum); /*Retrieve the data (compass struct) being send break; close(connfdset); return 0; printf(">no connections yet...drink a coffee and wait...\n"); printf("> "); //~ sem_post(&mutex); return 1; //~ sem_post(&mutex); fflush(stdout); 96

97 /* Get all requested info automatically void get_all(int allrows,int ferows) int j=0; struct info info; //~ sem_wait(&mutex); //lock glob variables connfdset=connid[globrow].feid.listenfd; row identifiers stays the same for(j=0;j<ferows;j++) //set unique row so when changing id the //j<ferrows and not <= because we start count from zero sprintf(buff, "g"); sprintf((buff+strlen(buff)),"%d",j); termination when appending printf("%s",buff); sleep(2); //pass the command argument and avoid null /*Index we send to FE if((send(connfdset, Buff, sizeof(buff), 0))==-1) fprintf(stderr, "Failure Sending Index ******\n"); close(connfdset); else /*read data ACK being received from FE while ( (n = read(connfdset, recvbuff, sizeof(recvbuff)-1)) > 0) /*print receive time on logfile file = fopen("logfilece.txt","a+"); ticks = time(null); //fprintf(file,"%.24s\r\n",ctime(&ticks)); fprintf(stdout,"receiving time %.24s\r\n",ctime(&ticks)); if(strlen(recvbuff)>5) //if FE/client have data to send the buffer must have at least appropriate length! /*Retrieve the data (compass struct) being send from FE memcpy(&info,recvbuff,sizeof(info)); /*insert neighbor element to our dyn. grow neighbor database called map if (AddToArray(info) == -1) fprintf(stdout,"failed inserting data to map"); num_allocated, num_elements); /*Screen output fprintf(stdout, "\n%d allocated, %d used so far...\n", fprintf(stdout,"device: %s, from %s ",info.neighbors.source,info.neighbors.devport); fprintf(stdout,"connected with device: %s \n",info.neighbors.capfrom); \n",info.stats.packetnum); \n",info.stats.timestamp); fprintf(stdout,"lldp packets counted so far from FE: %d fprintf(stdout,"time last packet received: %s /*Save data to logfile fprintf(file,"device: %s, from %s ",info.neighbors.source,info.neighbors.devport); fprintf(file,"connected with device: %s \n",info.neighbors.capfrom); bufffer /*Make sure we won't read any more from our received recvbuff[n] = '\0'; /* clear the message buffer 97

98 else memset(recvbuff, 0, BuffSize); printf("\nno data send from FE\n"); /*If reading data from socket returns error if(n < 0) printf("\nread error from socket\n"); close(connfdset); else fprintf(stdout,"succesfully received data from FE\n"); close(connfdset); //~ sem_post(&mutex); /* Set command handler int set_handler(void) int index; //~ sem_wait(&mutex); if(connections>0) int length = 0; printf("\n=========set action========\n"); argument wrong length+=snprintf(buff+length,sizeof(command),"%s",command); //pass the command memcpy( Buff, command, sizeof(command ) ); memset(command, 0, commandsize); //clear command buffer to reuse /*choose a row to query printf(">enter row to set from local database:"); //enter search index scanf("%s",command); index=atoi(command); if(index<num_elements) printf("\nsending selected data..."); memcpy(tempbuff,&map[index],sizeof(map[index])); memcpy(buff+1,tempbuff,sizeof(tempbuff)); sprintf(tempbuff+8,"s"); else printf("\nset request on empty local row...\n"); //something went goto err; printf("\n>setting row index : %d \n",index); /*Index we send to FE MSG_WAITALL if((send(connfdset, Buff, sizeof(buff), 0))==-1) fprintf(stdout, "Failure Sending Data\n"); close(connfdset); return 1; else //~ //memset(buff, 0, BuffSize); fprintf(stdout,"done!\n"); 98

99 else err: if(n = read(connfdset, recvbuff, sizeof(recvbuff)-1) > 0) fprintf(stdout,"fe Respond: %s\n",recvbuff); return 0; printf(">no connections yet...drink a coffee and wait...\n"); printf("> "); //~ sem_post(&mutex); return 1; printf("> "); //~ sem_post(&mutex); fflush(stdout); /* Del command handler int del_handler(void) //~ sem_wait(&mutex); if(connections>0) printf("\n=========del action========\n"); sprintf(buff,command); //pass the command argument memset(command, 0, commandsize); //clear command buffer to reuse /*choose a row to query printf(">enter row for del:"); fflush(stdout); scanf("%s",command); //enter search index sprintf((buff+strlen(buff))-1,command); //pass the command argument and avoid null termination when appending printf("\n>deleting row index: %s...\n",buff); /*Index we send to FE if((send(connfdset, Buff, sizeof(buff), 0))==-1) fprintf(stderr, "Failure Sending Index\n"); close(connfdset); sem_post(&mutex); return 1; else sleep(1); /*read data ACK being received from FE while ( (n = read(connfdset, recvbuff, sizeof(recvbuff)-1)) > 0) /*Make sure data were deleted from FE printf("fe Respond: %s\n",recvbuff); recvbuff[n] = '\0'; memset(recvbuff, 0, BuffSize); /*If reading data from socket returns error if(n < 0) printf("\n Read error from socket\n"); close(connfdset); else close(connfdset); return 0; 99

100 update_all(); else //inform FE printf(">no connections yet...drink a coffee and wait...\n"); printf("> "); //~ sem_post(&mutex); fflush(stdout); /* insert data to array map int AddToArray (struct info item) /*Make sure we don't have duplicate entries and the discovery process has already started int checker=0,enter=0; while(checker<=(num_elements-1)) if(strcmp(map[checker].neighbors.source,item.neighbors.source)==0) if(strcmp(map[checker].neighbors.capfrom,item.neighbors.capfrom)==0) if(strcmp(map[checker].neighbors.devport,item.neighbors.devport)==0) /*If packet already exists update time interval and packet counter memcpy(map[checker].stats.timestamp, &item.stats.timestamp,sizeof(item.stats.timestamp)); map[checker].stats.packetnum=item.stats.packetnum; enter=1; checker++; if(enter==0) update_all(); //inform FE /*If used elements exceed the limit double the size of our array if(num_elements == num_allocated) if (num_allocated == 0) num_allocated = 3; else num_allocated *= 2; /*make reallocation using temporary values void *_tmp = realloc(map, (num_allocated * sizeof(struct info))); /*check for errors and inform the user about memory allocation if (!_tmp) fprintf(stderr, "ERROR: Couldn't realloc memory!\n"); return(-1); /*pass data to the dyn struct map = (struct info*)_tmp; /*save into the database "map" map[num_elements] = item; num_elements++; return num_elements; 100

101 /* Create struct with unique ID's so we can serve multiple clients simultaneously according their fd int AddConnection (struct allcons connitem) int enter=0,checker=0; while(checker<=(fenum_elements-1)) if(strcmp(connid[checker].feid.connip,connitem.feid.connip)==0) /*If connection already exists do not add it and update connhandler integer connid[checker].feid.listenfd=connfd; snprintf(connid[checker].feid.link_state, sizeof(connid[checker].feid.link_state), "active"); //save connections to struct enter=1; checker++; if(enter==0) /*If used elements exceed the limit double the size of our array if(fenum_elements ==FEnum_allocated) if (FEnum_allocated == 0) FEnum_allocated = 3; else FEnum_allocated *= 2; /*make reallocation using temporary values void *_tmp = realloc(connid, (FEnum_allocated * sizeof(struct allcons))); /*check for errors and inform the user about memory allocation if (!_tmp) fprintf(stderr, "ERROR: Couldn't realloc memory!\n"); return(-1); /*pass data into the dyn struct connid = (struct allcons*)_tmp; /*save into the database "id" connid[fenum_elements] = connitem; FEnum_elements++; return FEnum_elements; 101

102 Υλοποίηση των δρομολογήσεων και της κατασκευής της τοπολογίας /********************************************************************** * file: controller_routing.c v.3.2 * * Author:Tarnaras George * Date: * * * Header file providing source code and functions for routing * ********************************************************************* <sys/socket.h> <netinet/in.h> <arpa/inet.h> <stdio.h> <stdlib.h> <unistd.h> <errno.h> <string.h> <sys/types.h> <semaphore.h> <pthread.h> "controller_header.h" /* Create the graph for Dijkstra using an adjacency struct for links int create_graph(void) int j=0,k=0,i=0; int node_ident; struct node temp; /* *Node==MAC, we set for every unique mac a row id for our matrix describing the graph /*find all uniques vertices for adjacency matrix scanning our database for(j=0;j<num_elements;j++) /*find all uniques vertices for adjacency matrix scanning our database memcpy(temp.nodeid,&map[j].neighbors.source,sizeof(map[j].neighbors.source)); temp.node_index=j; //initialize first elements for adjacency matrix /*insert node element to our dyn. grow neighbor database called nodes if (AddNode(temp) == -1) fprintf(stdout,"failed sleep(1); inserting data to nodes"); for(k=0;k<num_elements;k++) memcpy(temp.nodeid,&map[k].neighbors.capfrom,sizeof(map[k].neighbors.capfrom)); temp.node_index=k; //initialize first elements for adjacency matrix /*insert node element to our dyn. grow neighbor database called nodes if (AddNode(temp) == -1) fprintf(stdout,"failed inserting data to nodes"); sleep(1); 102

103 /* initialize adjacency matrix with zeroes for(i=0;i<nodenum_elements;i++) for(j=0;j<nodenum_elements;j++) node_matrix[i][j]=0; /* set adjacency matrix according to mac id from struct nodes for(j=0;j<nodenum_elements;j++) for(k=0;k<num_elements;k++) //start checking whether the node exists in map, if found then do the matching with nodes struct to set matrix correctly if(strcmp(nodes[j].nodeid,map[k].neighbors.source)==0) //find an id, now match it with the neighbor //found an id, now match it with the neighbor memcpy(temp.nodeid,map[k].neighbors.capfrom,sizeof(map[k].neighbors.source)); for(i=0;i<nodenum_elements;i++) if(strcmp(temp.nodeid,nodes[i].nodeid)==0) node_ident=nodes[i].node_index; node_matrix[j][node_ident]=1; if(strcmp(nodes[j].nodeid,map[k].neighbors.capfrom)==0) //find an id, now match it with the neighbor //do the same matching for the other struct member capfrom memcpy(temp.nodeid,map[k].neighbors.source,sizeof(map[k].neighbors.source)); for(i=0;i<nodenum_elements;i++) if(strcmp(temp.nodeid,nodes[i].nodeid)==0) node_ident=nodes[i].node_index; node_matrix[j][node_ident]=1; return 0; /* Reveal the constructed graph int reveal_graph(void) int j=0,i=0,startn=0; if(initialize_nodes==1) topology=fopen("topology.txt","r+"); for(j=0;j<nodenum_elements;j++) fprintf(stdout,"\nnode: %d \n%s \n",nodes[j].node_index,nodes[j].nodeid); //fprintf(topology,"node: %d \n%s \n\n",nodes[j].node_index,nodes[j].nodeid); printf("\nadjacency Matrix\n\n"); for(i=0;i<nodenum_elements;i++) SocNetV printf("---%d",i); printf("\n"); for(i=0;i<nodenum_elements;i++) //print adjacency matrix to topology.txt and we can easily create the map with printf("%d- ",i); for(j=0;j<nodenum_elements;j++) 103

104 fprintf(stdout,"%d ",node_matrix[i][j]); fprintf(topology,"%d ",node_matrix[i][j]); printf("\n"); fprintf(topology,"\n"); printf("\n\n"); fclose(topology); else printf("\nenter node to start: "); fflush(stdout); scanf("%d",&startn); dijkstra(node_matrix,nodenum_elements,startn); return 0; printf("no data on local database.make a query for routing info."); return 1; /* Dijkstra's algorithm for minimum distance void dijkstra(int graph[max_nodes][max_nodes],int vertices, int startnode) int cost[max_nodes][max_nodes],distance[max_nodes],previous[max_nodes],visited[max_nodes]; int count,mindistance,nextnode,i,j; //count for node counter matrix /* create the cost matrix for(i=0;i<vertices;i++) for(j=0;j<vertices;j++) if(graph[i][j]==0) //no connection exists from adjacency matrix cost[i][j]=infinite; else //pass the vertex weight as defined from cost[i][j]=graph[i][j]; /*Initialize distances for applying dijsktra for(i=0;i<vertices;i++) distance[i]=cost[startnode][i]; //set the distances from the startnode previous[i]=startnode; //set previous nodes from startnode visited[i]=0; //set 0 so never visited vertex distance[startnode]=0; //set startnodes distance to 0, so we calculate according this visited[startnode]=1; count=1; //obvious already visited //lower the node counter while(count<vertices-1) // -1 beacuse starts from 0 //start 'node discovery process' mindistance=infinite ; //set to infinite before any new node discovery /*nextnode is the node at minimum distance for(i=0;i<vertices;i++) //start checking for new nodes and better paths if(distance[i] < mindistance &&!visited[i]) mindistance=distance[i]; //lower cost distance nextnode=i; //move on visited[nextnode]=1; //check with 1 as visited and go on 104

105 for(i=0;i<vertices;i++) if(!visited[i]) if(mindistance+cost[nextnode][i]<distance[i]) distance[i]=mindistance+cost[nextnode][i]; //choose next node to continue previous[i]=nextnode; //update the previous node(parent) count++; //move node on /* print the path and the distance for and from each node for(i=0;i<vertices;i++) if(i!=startnode) printf("\ndistance from node %d => %d",i,distance[i]); printf("\npath :: %s ",nodes[i].nodeid); //print with mac id from struct nodes j=i; while(j!=startnode) j=previous[j]; //print parents backwards from startnode & also ends while condition printf("<--- %s ",nodes[j].nodeid); printf("\n"); /* Create struct with unique node ID's so we can create the dijkstras graph dynamically int AddNode (struct node nodeitem) int enter=0,checker=0; if(initialize_nodes==0) enter=0; else if(initialize_nodes==1) //first time just enter the values to the empty struct nodes while(checker<=(nodenum_elements)) //check if node exists if(strcmp(nodeitem.nodeid,nodes[checker].nodeid)==0) /*If node already exists do not add it enter=1; break; else if(strcmp(nodeitem.nodeid,nodes[checker].nodeid)==0) /*If node already exists do not add it enter=1; break; checker++; if(enter==0) initialize_nodes=1; nodeitem.node_index=nodenum_elements; //give a serial unique id /*If used elements exceed the limit double the size of our array if(nodenum_elements ==NODEnum_allocated) 105

106 if (NODEnum_allocated == 0) NODEnum_allocated = 3; else NODEnum_allocated *= 2; /*make reallocation using temporary values void *_tmp = realloc(nodes, (NODEnum_allocated * sizeof(struct node))); /*check for errors and inform the user about memory allocation if (!_tmp) fprintf(stderr, "ERROR: Couldn't realloc memory!\n"); return(-1); /*pass data into the dyn struct nodes = (struct node*)_tmp; /*save into the database "id" nodes[nodenum_elements] = nodeitem; NODEnum_elements++; //count uniques vertices for dijkstra return NODEnum_elements; 106

107 ΥΛΟΠΟΊΗΣΗ ΤΟΥ FE Εκκίνηση ελέγχου εισερχόμενης κίνηση από τα NIC /********************************************************************** * file:lldump.c v.3.2 * * Author:Tarnaras George * Date: * Modified version for sniffing and storing lldp packets directly. * *We start checking devices one by one creating a thread and proceeding to the next device. *When an LLDP packet is received we automatically send it to the controller with all info *provided by the specific protocol. * *IMPORTANT: * Compile with: * gcc -Wall -pedantic lldump.c lldump_routines.c lldump_interface.c lldump_events.c -lpcap -pthread -o lldump * Usage: Run as ROOT!!:./lldump <CE ip> <CE port> ********************************************************************* <pcap.h> <stdio.h> <stdlib.h> <signal.h> <errno.h> <string.h> <time.h> <sys/socket.h> <netinet/in.h> <arpa/inet.h> <sys/types.h> <sys/ioctl.h> <pthread.h> <unistd.h> <netinet/if_ether.h> <net/ethernet.h> <net/if.h> <netinet/ether.h> <netinet/ip.h> <semaphore.h> /*posix handling "lldump_header.h" /*begin sniffing process! int main(int argc,char **argv) int count =1,control1=0,check,trigger,event_trigger; /*just counters for checking etc. int ethonly,capmode,one_instance=1; /*variables to check if we 're running on one instance mode checking only one dev or all pcap_if_t *alldevs, *device; discovering all devices pthread_t comthread,eventhread; controller for receiving commands /*handlers used by pcap for /*create communication thread with 107

108 global array globalargc = argc; /*make argc and argv globalargv = argv; num_allocated=0; /*initialize dynamic num_elements=0; globcount=0; process has started--> global packet counter /*make sure discovery /*Make sure we run as root if(geteuid()!= 0) printf("\nrun as root\n",globalargv[0]); exit(1); /*controllers-servers ip address-->must be entered manually if(globalargc!= 3) printf("\nusage: %s <ip of server> <port> \n",globalargv[0]); return 1; /*Get list of all available devices printf("\nfinding available devices... "); if( pcap_findalldevs( &alldevs, errbuf) ) printf("error finding devices : %s", errbuf); exit(1); printf("done\n"); printf("\navailable Devices are :\n"); for(device = alldevs ; device!= NULL ; device = device->next) printf("%d. %s - %s\n", count, device->name, device->description); if(device->name!= NULL) strcpy(devs[count], device->name); count++; /* create, initialize semaphore if( sem_init(&mutex,1,1) < 0) perror("semaphore initilization error"); exit(0); devs ethonly=count+1; /*set ethonly to a specific value for checking all eth /*Chose running mode--all devs or only one dev-- fprintf(stdout,"\nchoose a capture device, for capturing an all ethernet devices enter %d\n",ethonly); fprintf(stdout,"\ncapture choice:"); scanf("%d",&capmode); if(capmode==ethonly) one_instance=0; /*variable for checking running mode /*Create connection with controller-->use last thread we can use trigger = pthread_create(&(comthread), NULL,Infomgmt, NULL); if (trigger!= 0) printf("\ncan't create communication thread :[%s]\n", strerror(trigger)); //~ else //~ printf("\ncommunication thread created successfully!\n"); sleep(1); event_trigger = pthread_create(&(eventhread), NULL,event_mgmt, NULL); if (event_trigger!= 0) printf("\ncan't create event thread :[%s]\n", strerror(event_trigger)); 108

109 //~ else //~ printf("\nevents thread created successfully!\n"); /*Check if capturing from all devs or user choosed only one if(one_instance==0) cheking /*capture from all devs n=1; /*initialize the device from which we start dev = devs[n]; check=count -3; /*set check=count-3 to avoid inf.loop that pseudo-device ''any'' and device ''lo'' cause --we just 'jump' these devs //~ fprintf(stdout,"\ncreating threads...\n"); for(control=0;control<check;control++) /*start creating threads for suitable devices trigger = pthread_create(&(tid[control]), NULL, devproc, NULL); if (trigger!= 0) printf("\ncan't create thread :[%s]", strerror(trigger)); //~ else //~ printf("\nthread %lu created successfully! (%d)\n",tid[control],control); sleep(3); n=n+1; dev=devs[n]; /*avoid race /*next device for(control1=0;control1<n;control1++) pthread_join( tid[control1], NULL); /*wait for threads to finish else /*capture from only one specific device n=capmode; dev = devs[n]; trigger = pthread_create(&(tid[n]), NULL, devproc, NULL); if (trigger!= 0) printf("\ncan't create thread :[%s]", strerror(trigger)); //~ else //~ printf("\nthread %lu created successfully! (%d)\n",tid[control],control); pthread_join( tid[n], NULL); /*wait for threads to finish pthread_join( tid[comthread], NULL); /*wait for communication thread to finish /*the end!!... :)... fprintf(stdout,"\nfinished\n"); return 0; 109

110 Υλοποίηση του interface του FE /********************************************************************** * file:lldump_interface.c v.3.2 * * Author:Tarnaras George * Date: * * * File providing src for routines used in lldump_interface.c * * ********************************************************************* <pcap.h> <stdio.h> <stdlib.h> <signal.h> <errno.h> <string.h> <time.h> <sys/socket.h> <netinet/in.h> <arpa/inet.h> <sys/types.h> <sys/ioctl.h> <pthread.h> <unistd.h> <netinet/if_ether.h> <net/ethernet.h> <net/if.h> <netinet/ether.h> <netinet/ip.h> <semaphore.h> /*posix handling "lldump_header.h" /* Communication Handler with controller/server for events void event_mgmt() loop_in: ; int event_portn,event; while(1) /*specify port number /*open the socket for sending lldp info to the controller and initialize the server address for events fprintf(stdout,"\nestablishing connection with controllers events port... "); if((event_sockfd = socket(af_inet, SOCK_STREAM, 0)) < 0) printf("error : Could not create FE socket \n"); /* type of sockets created event_addr.sin_family = AF_INET; event_portn=atoi(globalargv[2])+1; event_addr.sin_port = htons(event_portn); /*convert servers/controllers input address from text to binary if(inet_pton(af_inet, globalargv[1], &event_addr.sin_addr)<=0) printf("inet_pton error occured\n"); sleep(1); /* Now connect to the server for events 110

111 if( connect(event_sockfd, (struct sockaddr *)&event_addr, sizeof(event_addr)) < 0) printf("\nerror : Connect to controller events Failed. Establishing connection please wait... \n"); system("clear"); goto loop_in; fprintf(stdout,"connected to events!\n"); // Set the socket I/O mode: In this case FIONBIO // enables or disables the blocking mode for the // socket based on the numerical value of imode. // If imode = 0, blocking is enabled; // If imode!= 0, non-blocking mode is enabled. int imode=0; ioctl(event_sockfd, FIONBIO, & imode); if(imode==0) printf("blocking mode enabled\n"); else printf("****warning****non-blocking mode enabled\n"); /*Wait for server/ce request--get/set/del-read data being received from CE if ((event= recv(event_sockfd, event_buff, sizeof(event_buff)-1,msg_waitall)) <= 0 ) printf("connection Closed from remote Server\n"); //Break from the While close(event_sockfd); break; else /* EVENT HANDLER fprintf(stdout,"\n/* EVENT "); fprintf(stdout,"\nupdate from CE: %s ",event_buff); event_buff[n] = '\0'; close(event_sockfd); goto loop_in; refreshing /*create and infinite loop so thread never ends and connectivity always /* Function handling CE updates int update_handler(void) printf("\n=========event action========\n"); metra(); //sem_wait(&mutex); snprintf(event_buff,sizeof(event_buff),"routing and neighbor info has changed/updated"); //pass the command argument /*Index we send to CE MSG_WAITALL if((send(event_sockfd, event_buff, sizeof(event_buff), 0))==-1) fprintf(stderr, "Failure Sending Data\n"); close(event_sockfd); return 1; else fprintf(stdout,"ce informed!\n"); close(event_sockfd); return 0; //sem_post(&mutex); fflush(stdout); 111

112 Ηeader αρχείο που περιέχει απαραίτητες μεταβλητές και πίνακες /********************************************************************** * file:lldump_header.h v.3.2 * * Author:Tarnaras George * Date: * * *Header file providing global variables and routines for lldump.c *Changing defined variables affects programme's essential parameters * * ********************************************************************* #ifndef LLDUMP_HEADER_H_ #define LLDUMP_HEADER_H_ /* ether.h defines ETHER_HDRLEN #ifndef ETHER_HDRLEN #define ETHER_HDRLEN 14 #endif #ifndef ETHERTYPE_LLDP #define ETHERTYPE_LLDP 0x88CC #endif #define nthreads 40 #define nhandlers 40 #define nidents 40 #define BuffSize 90 #define reqbuff 90 server/ce /* prevent multiple definition errors /* LLDP ethertype /*max threads we can create /*max handlers for devices we can create /*max unique id's we can create for our threads /*define the length of buffer size for sending data to CE /*buffer used for request commands get/set/del from /* ************************************************************************************************ /* **************************************GENERAL VARS****************************************** /* ************************************************************************************************ FILE *file; capture info-->neighbors pcap_t* descr[nhandlers]; /*the file where we re saving /*handler of the device that shall be sniffed /*Parameters used for pcap functions etc. int n,control; /*n is used for changing device by increasing its value, -- control for right printing the device we re sniffing on int match[nidents],id; /*match is used for mathcing threads id with sniffing port (for printing in the loopback) pthread_t tid[nthreads]; /* Create independent threads-each onewill execute a function /* ************************************************************************************************ /* *******************************************BUFFERS******************************************** /* ************************************************************************************************ /* Buffers used char errbuf[pcap_errbuf_size],*dev, devs[100][100],tempbuff[81]; 112

113 char sendbuff[buffsize],buff[reqbuff],event_buff[buffsize]; /* buffer for sending data to CE and a timestamp /* ************************************************************************************************ /* **************************************SOCKET THINGS****************************************** /* ************************************************************************************************ /*Parameters used for sockets, address to connect,port etc. int globalargc; /* make argc and argv global for using info within functions char **globalargv; int globcount; /*global packet counter for checking if discovery process start int sockfd,event_sockfd; /*Initialize the socket and the file descriptor we are going to use for sending info to the controller struct sockaddr_in serv_addr,event_addr; time_t ticks; /*use it for timestamp sem_t mutex; /*mutual exclusion for critical section into callback function /* ************************************************************************************************ /* **************************************MAP ELEMENTS******************************************* /* ************************************************************************************************ int int num_elements ; /*To keep track of the number of elements used num_allocated ; /*This is essentially how large the array is /*struct for saving all device's neighbor and infos struct compass ; char source[18]; char capfrom[18]; char devport[5]; /*the nic address from which we capture /*addresses from received packets-->neighbors /*the port from which we capture struct statistics uint16_t packetnum; char timestamp[25]; ; struct info struct compass neighbors; struct statistics stats; ; /*This is the dynamically growing struct containing all info and the struct we use for data exchange with the controller's requests struct info *map ; /* ************************************************************************************************ /* ************************************FUNCTIONS USED******************************************* /* ************************************************************************************************ /*Routines used char *getmac(char *iface); //print sniffing device's mac void showframe_callback(u_char *args, const struct pcap_pkthdr* pkthdr,const u_char* packet); //loop, capture and control packets for sending to CE void devproc(); //choose and initialize the device for sniffing void Infomgmt(); //handle connection process void event_mgmt(); 113

114 int update_handler(void); void command_handler(char command[8]); //handle CE command requests int AddToArray (struct info item); //save neighbor info #endif /*LLDUMP_HEADER_H_ Υλοποίηση συναρτήσεων αλληλεπίδρασης με το CE /********************************************************************** * file:lldump_interface.c v.3.2 * * Author:Tarnaras George * Date: * * * File providing src for routines used in lldump_interface.c * * ********************************************************************* <pcap.h> <stdio.h> <stdlib.h> <signal.h> <errno.h> <string.h> <time.h> <sys/socket.h> <netinet/in.h> <arpa/inet.h> <sys/types.h> <sys/ioctl.h> <pthread.h> <unistd.h> <netinet/if_ether.h> <net/ethernet.h> <net/if.h> <netinet/ether.h> <netinet/ip.h> <semaphore.h> /*posix handling "lldump_header.h" /* Communication Handler with controller/server void Infomgmt() loop: ; int portn; while(1) address /*specify port number /*open the socket for sending lldp info to the controller and initialize the server fprintf(stdout,"\nestablishing connection with controller... "); if((sockfd = socket(af_inet, SOCK_STREAM, 0)) < 0) printf("error : Could not create FE socket \n"); /* type of sockets created serv_addr.sin_family = AF_INET; portn=atoi(globalargv[2]); serv_addr.sin_port = htons(portn); /*convert servers/controllers input address from text to binary 114

115 if(inet_pton(af_inet, globalargv[1], &serv_addr.sin_addr)<=0) printf("inet_pton error occured\n"); sleep(1); /* Now connect to the server if( connect(sockfd, (struct sockaddr *)&serv_addr, sizeof(serv_addr)) < 0) printf("\nerror : Connect to controller Failed. Establishing connection please wait... \n"); //fflush(stdout); goto loop; fprintf(stdout,"connected!\n"); // Set the socket I/O mode: In this case FIONBIO // enables or disables the blocking mode for the // socket based on the numerical value of imode. // If imode = 0, blocking is enabled; // If imode!= 0, non-blocking mode is enabled. int imode=0; ioctl(sockfd, FIONBIO, & imode); if(imode==0) printf("blocking mode enabled\n"); else printf("****warning****non-blocking mode enabled\n"); /*Wait for server/ce request--get/set/del-char command[8]; read data being received from CE printf("retrieving Command...\n"); if ((n= recv(sockfd, Buff, sizeof(buff)-1,msg_waitall)) <= 0 ) printf("connection Closed from remote Server\n"); //Break from the While close(sockfd); break; else switch(buff[n]) case 's': //set command from CE memcpy(command, &Buff[n],sizeof(command)); sleep(1); command_handler(command); break; goto loop; refreshing default: //other commands memcpy(command, &Buff,sizeof(command)); sleep(1); command_handler(command); break; /*create and infinite loop so thread never ends and connectivity always /* Process controller command requests void command_handler(char command[8]) int index; //index for get/set/del command int shift; //counter for for struct info data;//for set if(globcount>0) //make sure discovery process has started 115

116 switch (command[0]) /* GET fprintf(stdout,"command %s received\n",buff); //if command=get case 'g': while ( n > 0) printf("retrieving Get Index..."); switch (command[1]) default: index=atoi(buff+1); //convert to row leaving out the first character which describes command fprintf(stdout,"index %s received\n",buff); printf("get Index Row %d",index); /*If reading data from socket returns error if(index<num_elements) printf("\nsending requested data..."); memcpy(sendbuff, &map[index],sizeof(map[index])); send(sockfd, sendbuff, sizeof(sendbuff), 0); memset(sendbuff, 0,BuffSize); //clear command buffer to reuse printf("done!\n"); break; else printf("\nget request on empty row..."); //something went wrong goto emptydata; break; case '*': printf("\nsending requested data..."); sprintf(sendbuff, "%d", num_elements); //memcpy(sendbuff, &num_elements,sizeof(num_elements)); send(sockfd, sendbuff, sizeof(sendbuff), 0); printf("done!\n"); memset(sendbuff, 0,BuffSize); //clear command buffer to reuse break; break; //get out of the loop to end case g close(sockfd); break; /* SET //if command=set case 's': fprintf(stdout,"command set received\n"); file = fopen("logfilefe.txt","a+"); /*attention to the r/w argument! r+ file must already exist //memcpy(tempbuff,&(buff+1),sizeof(tempbuff)); //CHANGE SIZE? /*print receive time on logfile ticks = time(null); fprintf(file,"%.24s\r\n",ctime(&ticks)); fprintf(stdout,"receiving time %.24s\r\n",ctime(&ticks)); /*Retrieve the data (compass struct) being set from CE 116

117 memcpy(&data,buff+1,sizeof(struct info)); num_allocated, num_elements); /*Screen output fprintf(stdout,"\n****set FROM CONTROLLER****\n"); fprintf(stdout, "\n%d allocated, %d used so far...\n", fprintf(stdout,"device: %s, from %s ",data.neighbors.source,data.neighbors.devport); fprintf(stdout,"connected with device: %s \n",data.neighbors.capfrom); fprintf(stdout,"lldp packets counted so far from FE: %d \n",data.stats.packetnum); fprintf(stdout,"time last packet received: %s \n",data.stats.timestamp); /*Save data to logfile fprintf(file," device: %s, from %s ",data.neighbors.source,data.neighbors.devport); fprintf(file,"connected with device: %s \n",data.neighbors.capfrom); called map /*insert neighbor element to our dyn. grow neighbor database if (AddToArray(data) == -1) fprintf(stdout,"failed inserting data to map"); /*Make sure we won't read any more from our received bufffer Buff[n] = '\0'; /* Success sprintf(sendbuff, "%s", "Susccesfully executed SET"); send(sockfd, sendbuff, sizeof(sendbuff), 0); memset(sendbuff, 0,BuffSize); //clear command buffer to reuse /* clear the message buffer //memset(buff, 0, BuffSize); /*If reading data from socket returns error if(n < 0) printf("\n Read error from socket\n"); close(sockfd); else printf("\n Succesfully received data from CE\n"); fclose(file); close(sockfd); break; /* DEL //if command=del case 'd': fprintf(stdout,"command %s received\n",buff); printf("retrieving Del Index..."); index=atoi(buff+1); //convert to row leaving out the first character which describes command fprintf(stdout,"index %s received\n",buff); printf("del Index Row %d",index); if(index<num_elements) printf("\ndeleting requested data..."); for(shift=index;shift<=num_elements;shift++) //if del done on a row then shift data left memcpy(&map[shift+1],&map[shift],sizeof(struct info)); void *_tmp = realloc(map, (num_allocated * sizeof(struct info))); 117

118 /*make sure pointer point right! buffer overflow etc. if (!_tmp) fprintf(stderr, "ERROR: Couldn't realloc memory!\n"); map = (struct info*)_tmp; num_elements=num_elements-1; previous element //reduce counter to show snprintf(sendbuff, sizeof(sendbuff), "Row %d deleted //reply CE for success update_handler(); //inform for the change send(sockfd, sendbuff, sizeof(sendbuff), 0); memset(sendbuff, 0,BuffSize); //clear command buffer to succesfully", index); reuse printf("done!\n"); else row..."); //something went wrong reuse break; snprintf(sendbuff, sizeof(sendbuff),"del request on empty send(sockfd, sendbuff, sizeof(sendbuff), 0); memset(sendbuff, 0,BuffSize); //clear command buffer to close(sockfd); break; else emptydata: /*default empty/wrong action memset(sendbuff, 0,BuffSize); printf("\nwaiting for LLDP packets please be patient..."); wait message if no packets come yet //send(sockfd, sendbuff, sizeof(sendbuff), 0); //print memset(buff, 0,reqBuff); close(sockfd); Συναρτήσεις χειρισμού εντολών και αποθήκευσης τοπικών στατιστικών /********************************************************************** * file:lldump_routines.c v.3.2 * * Author:Tarnaras George * Date: * * * File providing src for routines used in lldump.c * * ********************************************************************* <pcap.h> <stdio.h> <stdlib.h> <signal.h> <errno.h> <string.h> 118

119 <time.h> <sys/socket.h> <netinet/in.h> <arpa/inet.h> <sys/types.h> <sys/ioctl.h> <pthread.h> <unistd.h> <netinet/if_ether.h> <net/ethernet.h> <net/if.h> <netinet/ether.h> <netinet/ip.h> <semaphore.h> /*posix handling <sys/time.h> <time.h> "lldump_header.h" void metra() char buffer[30]; struct timeval tv; time_t curtime; gettimeofday(&tv, NULL); curtime=tv.tv_sec; strftime(buffer,30,"%m-%d-%y %T.",localtime(&curtime)); printf("was %s%ld\n",buffer,tv.tv_usec); return 0; /*function for acquiring the mac address from a chosen dev char *getmac(char *iface) #define MAC_STRING_LENGTH 18 /*correct lenght of mac is always 13 but we add 5 more bits for eye candy printing with ':' char *ret = malloc(mac_string_length); struct ifreq s; int fd = socket(pf_inet, SOCK_DGRAM,0); strcpy(s.ifr_name, iface); if (fd >= 0 && ret && 0 == ioctl(fd, SIOCGIFHWADDR, &s)) int i; for (i = 0; i < 6; ++i) snprintf(ret+i*3,mac_string_length-i*3,"%02x:",(unsigned char) s.ifr_addr.sa_data[i]); /*correct formated mac else perror("malloc/socket/ioctl failed or not an Etherner device"); exit(1); close(fd); return(ret); /*function for device processing void devproc() & capturing when a unique thread is created from main 119

120 bpf_u_int32 maskp; bpf_u_int32 netp; u_char* args = NULL; /* our subnet mask /* our ip /*set args to null for callback function /* ask pcap for the network address and mask of the device pcap_lookupnet(dev,&netp,&maskp,errbuf); /* pcap_open_live(char *device, int snaplen,int promisc, int to_ms, char *errbuf) attention to mseconds! may cause cpu overload descr[n] = pcap_open_live(dev,bufsiz,1,100,errbuf); if(descr[n] == NULL) printf("pcap_open_live(): %s\n",errbuf); exit(1); /*store threads id so we can use correct handlers when calling loopback function id++; match[id]=pthread_self(); //~ printf("thread ID %ld\n", pthread_self()); /*make sure we capture/handling an ethernet only device(infos about link-layer addresses available from pcap) if (pcap_datalink(descr[n]) == DLT_EN10MB) /*capture only one way traffic...here we need incoming only-->options are PCAP_D_IN,PCAP_D_OUT,PCAP_D_INOUT if(pcap_setdirection(descr[n], PCAP_D_IN)==-1) fprintf(stderr,"error setting capture direction\n"); exit(1); packets else ethernet dev /* loop for capturing packets from a specific device!...attr '0' is for inf. pcap_loop(descr[n],0,showframe_callback,args); pthread_cancel(tid[control]); /*cancel the thread which is not listening to an /*callback function for looping & printing an LLDP packet which we call from devproc function for processing a device void showframe_callback(u_char *args, const struct pcap_pkthdr* pkthdr,const u_char* packet) u_int caplen = pkthdr->caplen; /* length of portion present u_int length = pkthdr->len; /* length of this packet (off wire) u_short ether_type; struct ether_header *eptr; /* net/ethernet.h struct info info; int scandev; int j=0; processing a dev static int count=0; /*use it for matching id with dev /*set packet counter for our thread -> /*match dev with thread for correct printing values... for(scandev=1;scandev<=nthreads;scandev++) if (pthread_self()==match[scandev]) dev=devs[scandev]; break; 120

121 /*from now on we re working with the correct device if (caplen < ETHER_HDRLEN) fprintf(stdout,"error:packet length less than ethernet header length\n"); //return -1; /*start checking ethernet headers and process header information eptr = (struct ether_header *) packet; /*open header info ether_type = ntohs(eptr->ether_type); /*network byte order to host byte order /*make sure we capture only lldp ethernet frames if(ether_type == ETHERTYPE_LLDP) file = fopen("logfilefe.txt","a+"); argument! r+ file must already exist ctime(&ticks)); /*attention to the r/w /*print capture time on logfile ticks = time(null); fprintf(file,"%.24s\r\n",ctime(&ticks)); fprintf(stdout,"%.24s\r\n",ctime(&ticks)); snprintf(info.stats.timestamp, sizeof(info.stats.timestamp), "%.24s\r\n", /*Print our NIC mac address from which we capture char *mac=getmac(dev); /*pass info into struct strcpy(info.neighbors.source,mac); strcpy(info.neighbors.devport,dev); fprintf(stdout,"capturing from device with mac: %s--> %s\n",info.neighbors.source,dev); fprintf(file,"capturing from device with mac: %s-->%s\n",info.neighbors.source,dev); free(mac); /*Print our remote mac address from which a packet is received strcpy(info.neighbors.capfrom,ether_ntoa((struct ether_addr*)eptr->ether_shost)); >ether_dhost)); of packets /*packet received --> means a neighbor is found fprintf(file,"lldp packet captured from device: %s \n",info.neighbors.capfrom); fprintf(stdout,"lldp packet captured from device: %s \n",info.neighbors.capfrom); fprintf(stdout,"lldp multicast is %s \n",ether_ntoa((struct ether_addr*)eptrprintf("packet Counter: %d\n", ++count); /* number globcount=count; info.stats.packetnum=count; /*pass counter into struct called map //sem_wait(&mutex); /*insert neighbor element struct and statistics to our dyn. grow neighbor database if (AddToArray(info) == -1) fprintf(stdout,"failed inserting data to map"); fprintf(stdout, "%d allocated, %d used so far...\n", num_allocated, num_elements); //sem_post(&mutex); update_handler(); of header //for count printf("received Packet Size(on wire): %d\n",length); /* length printf("payload:\n"); /* raw print the packet 121

122 /*...and life would be so easy with this... //~ if(system("lldpctl")<0) //~ //~ perror("lldpctl"); //~ exit(0); //~ for(j=0;j<length;j++) if(isprint(packet[j])) /* Check if the packet data is printable printf("%c ",packet[j]); else printf(". ",packet[j]); /* If not printable, print a '.' if((j%16==0 && j!=0) j==length-1) fclose(file); printf("\n"); /* insert get set del with index later int AddToArray (struct info item) /*Make sure we don't have duplicate entries and the discovery process has started int checker=0,enter=0; if(globcount>0) while(checker<=(num_elements-1)) if(strcmp(map[checker].neighbors.source,item.neighbors.source)==0) if(strcmp(map[checker].neighbors.capfrom,item.neighbors.capfrom)==0) if(strcmp(map[checker].neighbors.devport,item.neighbors.devport)==0) counter /*If packet already exists update time interval and packet memcpy(map[checker].stats.timestamp, &item.stats.timestamp,sizeof(item.stats.timestamp)); map[checker].stats.packetnum=item.stats.packetnum; enter=1; checker++; if(enter==0) //if we enter that loop it means we have a new neighbor so we must send a note to the controller /* Call event update update_handler(); /*If used elements exceed the limit double the size of our array if(num_elements == num_allocated) if (num_allocated == 0) num_allocated = 3; else num_allocated *= 2; /*make reallocation using temporary values 122

123 void *_tmp = realloc(map, (num_allocated * sizeof(struct info))); /*check for errors and inform the user about memory allocation if (!_tmp) fprintf(stderr, "ERROR: Couldn't realloc memory!\n"); return(-1); /*pass data into the dyn struct map = (struct info*)_tmp; /*save into the database "map" map[num_elements] = item; num_elements++; /*Elements used so far fprintf(stdout,"element counter: %d \n",num_elements); return num_elements; 123

124 ΠΑΡΆΡΤΗΜΑ Α. Εικονικοποίηση Λειτουργιών Δικτύου - Network Function Virtualization Η εικονικοποίηση λειτουργιών δικτύου μπορεί να αναπτυχθεί αυτόνομα σε μια modular αρχιτεκτονική δικτύου. Ο συνδυασμός όμως της τεχνολογίας αυτής με τα προγραμματιζόμενα δίκτυα φαίνεται να έχει κάποια σημαντικά πλεονεκτήματα τα οποία αξίζει να αναφέρουμε. Το μοντέλο που προτείνεται αποτελείται από 3 κύρια συστατικά στοιχεία που είναι τα εξής: Καινοτομία σε μια ανοιχτή λογική προσβάσιμη από όλους Εικονικοποίηση λειτουργιών Προγραμματιζόμενα δίκτυα Την αλληλεπίδραση και συσχέτιση αυτών των παραγόντων μπορούμε να δούμε και στο παρακάτω σχήμα Α.1. Συνοψίζοντας, πρόκειται λοιπόν για μια λογική παροχής υποδομών ( Infastructure as a service IaaS) και πλατφορμών (Platform as a service - PaaS) ως υπηρεσίες, εικονικά δηλαδή μέσω οδηγούμενων από προγράμματα εφαρμογών (Σχήμα Α.2). Σχήμα Α.1 Συστατικά στοιχεία εικονικοποίησης 124