Ενεργό-εφεδρικό bond του Linux σε EVPN all-active: τι χαλάει

Βάλτε ένα ενεργό-εφεδρικό bond στον διακομιστή και ένα τμήμα Ethernet all-active στο fabric, και ο μισός δρόμος επιστροφής της κίνησης μπορεί να εξαφανιστεί χωρίς να κουνηθεί ούτε ένας μετρητής σφαλμάτων. Καμία από τις δύο ρυθμίσεις δεν είναι λάθος από μόνη της. Το πρόβλημα βρίσκεται στην παράδοση ανάμεσά τους, όπου η μία πλευρά διαλέγει μία θύρα και η άλλη υποθέτει ότι κάθε συνδεδεμένο leaf μπορεί να παραδώσει. Ακολουθήστε ένα πλαίσιο σε κάθε κατεύθυνση και η ασυμφωνία γίνεται φανερή.

Τι κάνει το ενεργό-εφεδρικό σε ένα εισερχόμενο πλαίσιο

Η λειτουργία bonding 1 κρατά ακριβώς ένα slave στη διαδρομή αποστολής και το αλλάζει μόνο όταν αποτύχει το τρέχον. Αυτό το μέρος είναι γνωστό. Εδώ έχει σημασία η πλευρά λήψης: ο πυρήνας παραδίδει ένα πλαίσιο στη στοίβα μόνο αν φτάσει στο ενεργό slave, και απορρίπτει πλαίσια που εμφανίζονται σε οποιοδήποτε άλλο slave. Αυτή all_slaves_active η ρύθμιση υπάρχει ακριβώς για να χαλαρώσει αυτόν τον κανόνα, και από προεπιλογή είναι κλειστή. ip -d link show bond0 εκτυπώνει την τρέχουσα τιμή δίπλα στη λειτουργία.

/proc/net/bonding/bond0 ονομάζει το ενεργό slave και αναφέρει την κατάσταση ζεύξης για κάθε slave. Αυτό το αρχείο είναι η μόνη έντιμη πηγή για το ποια θύρα μεταφέρει κίνηση αυτή τη στιγμή.

Ένας host σε αυτή τη λειτουργία έχει μία χρησιμοποιήσιμη διαδρομή λήψης κάθε φορά, επιλεγμένη τοπικά χωρίς γνώση του fabric. Αν ένα πλαίσιο για αυτόν τον host φτάσει στο άλλο καλώδιο, η θύρα του μεταγωγέα το μετρά ως ληφθέν, η στοίβα του host δεν το βλέπει ποτέ, και κάθε μετρητής εκτός από τον δικό του μετρητή απορρίψεων φαίνεται απόλυτα υγιής.

Τι κάνει το all-active multihoming σε ένα απομακρυσμένο επόμενο άλμα

Το EVPN multihoming περιγράφει ένα σύνολο leaf που μοιράζονται ένα τμήμα Ethernet, το οποίο προσδιορίζεται από ένα ESI, και διαφημίζει αυτό το τμήμα στο υπόλοιπο fabric. Στο μοντέλο all-active, οι απομακρυσμένοι peers εγκαθιστούν περισσότερα από ένα επόμενα άλματα για τις διευθύνσεις του τμήματος. Το unicast προς τον διακομιστή μπορεί τότε να φτάσει σε οποιοδήποτε leaf, και το fabric είναι ελεύθερο να επιλέγει ανά ροή. Αυτός είναι όλος ο σκοπός του σχεδιασμού, και είναι επίσης η παραδοχή που πρέπει να ικανοποιεί το bond του διακομιστή.

Η πλημμυρισμένη κίνηση ακολουθεί διαφορετικό κανόνα. Τα leaf εκλέγουν έναν καθορισμένο forwarder ανά τμήμα, οπότε το broadcast, το άγνωστο unicast και το multicast μπαίνουν συνήθως από ένα από αυτά. Επομένως το unicast και η πλημμύρα παίρνουν δύο ξεχωριστές αποφάσεις, και μόνο μία από αυτές φαίνεται στην κατάσταση του bond του host.

Πού διαφωνούν οι δύο εκλογές

Ο πυρήνας διαλέγει το ενεργό slave από την κατάσταση ζεύξης και τη δική του πολιτική. Το fabric διαλέγει επόμενα άλματα από τις διαδρομές EVPN, και έναν καθορισμένο forwarder από εκλογή μεταξύ των leaf. Καμία από τις δύο διεργασίες δεν συμβουλεύεται την άλλη. Όταν διαλέξουν διαφορετικά leaf, η αποτυχία εξαρτάται από την κατεύθυνση: ό,τι στέλνει ο διακομιστής φεύγει κανονικά, και οι απαντήσεις εξαφανίζονται.

Υπάρχουν δύο υποστηριζόμενες διέξοδοι, και δεν είναι εναλλάξιμες. Δώστε στον host ένα bond που το fabric μπορεί να αντιμετωπίσει ως μία λογική σύνδεση, που στην πράξη σημαίνει bond LACP διαπραγματευμένο με τα leaf, και οι δύο ζεύξεις είναι πραγματικά ενεργές μαζί. Ή δεχτείτε και παράδοση single-active από το fabric, ώστε το τμήμα να ακολουθεί το ίδιο μοντέλο μίας θύρας τη φορά με το bond. Αυτό που δεν δουλεύει είναι ένα τμήμα all-active μπροστά από ένα bond που ακούει μόνο σε μία θύρα, εκτός αν ενεργοποιήσετε σκόπιμα τη λήψη στα ανενεργά slave και δεχτείτε τη διπλή παράδοση που ακολουθεί.

Γιατί το εφεδρικό καλώδιο συνεχίζει να φαίνεται υγιές

Ένα καλώδιο που δεν μεταφέρει κίνηση εξακολουθεί να αναφέρει ζεύξη πάνω, και ένα εφεδρικό slave σε ένα bond είναι σχεδιασμένο να φαίνεται έτοιμο. Οι χειριστές το διαβάζουν ως πλεονασμό και σταματούν να ρωτούν.

Ρωτήστε αντί γι' αυτό ποια φυσική θύρα χρησιμοποίησε το πλαίσιο επιστροφής. Στον host, μετρήστε τα ληφθέντα πακέτα ανά slave και όχι ανά bond, γιατί ο μετρητής του bond κρύβει την ασυμμετρία. Στο leaf, κοιτάξτε τις εγγραφές προώθησης της γέφυρας για τη MAC του διακομιστή και το σύνολο επόμενων αλμάτων που μεταφέρει η διαδρομή EVPN. Αν η εγγραφή δείχνει στο leaf του οποίου η ζεύξη με τον host είναι η εφεδρική, ο σχεδιασμός παραδίδει σε θύρα που ο host αγνοεί. Αυτή είναι ασυμφωνία ρυθμίσεων και όχι βλάβη υλικού, και καμία ποσότητα παρακολούθησης κατάστασης ζεύξης δεν θα την αποκαλύψει.

Δοκιμάστε την παράδοση και στις δύο κατευθύνσεις, όχι την κατάσταση ζεύξης

Φτιάξτε έναν πίνακα με μία γραμμή ανά αστοχία και μία στήλη ανά κατεύθυνση, και μετά συμπληρώστε παραδοθείσα κίνηση αντί για κατάσταση διεπαφής. Η γραμμή ένα είναι κανονική λειτουργία, και εκεί ακριβώς κρύβεται η ασυμφωνία, γιατί το σύμπτωμα μοιάζει με πρόβλημα εφαρμογής.

Στη συνέχεια αφαιρέστε την ενεργή ζεύξη του host, αφαιρέστε ένα leaf, αφαιρέστε τα uplinks αυτού του leaf, και επαναφέρετε το καθένα με τη σειρά. Μετά από κάθε βήμα, καταγράψτε το ενεργό slave, την κατάσταση του τμήματος EVPN, την απομακρυσμένη εγγραφή προώθησης και τη μετρούμενη απόδοση και στις δύο κατευθύνσεις. Ένα leaf που χάνει τη διαδρομή του προς το fabric ενώ η ζεύξη του με τον host μένει πάνω είναι η ενδιαφέρουσα περίπτωση, γιατί η σύνδεση παραμένει διαφημισμένη και μπορεί ήσυχα να γίνει αδιέξοδο. Δοκιμάστε με νέες ροές unicast και με την πλημμυρισμένη κίνηση από την οποία εξαρτάται η εφαρμογή, γιατί οι δύο χρησιμοποιούν διαφορετικές αποφάσεις προώθησης.

Δεχτείτε τον σχεδιασμό μόνο όταν ο πίνακας δείχνει αμφίδρομη παράδοση μέσα από τη διαδρομή που σκοπεύατε. Δύο καλώδια με ζεύξη πάνω δεν είναι αυτό το αποτέλεσμα.