PIM-SM μέσω VPN: έλεγχος BSR, αντιστοίχισης RP και διαδρομών RPF

Η σήραγγα είναι ενεργή, τα unicast ping τη διαπερνούν και ο δέκτης εξακολουθεί να δείχνει μαύρη οθόνη. Σε μια εγκατάσταση PIM-SM αυτό το σύμπτωμα σημαίνει σχεδόν πάντα ότι μία από τις τέσσερις διαδρομές ελέγχου έχει σπάσει και ότι η διαδρομή δεδομένων δεν ήταν ποτέ το πρόβλημα. Ακολουθήστε τη λίστα παρακάτω με τη σειρά και σταματήστε στο πρώτο βήμα που αποτυγχάνει, γιατί κάθε επόμενο βήμα εξαρτάται από το προηγούμενο. Κρατώ αυτούς τους πέντε ελέγχους σε ένα πρόχειρο αρχείο και τους επικολλώ σε ένα τερματικό όταν φτάνει ένα παράπονο για multicast, κάτι που εμποδίζει τη διάγνωση να μετατραπεί σε εικασίες.

Ξεκινήστε από τον δέκτη, όχι από τη σήραγγα

Ένας δέκτης που δεν ζήτησε ποτέ την ομάδα δεν παράγει κατάσταση σε κανέναν δρομολογητή, οπότε επιβεβαιώστε ότι η εγγραφή υπάρχει στο τμήμα προς τον δέκτη πριν ελέγξετε οτιδήποτε άλλο. Σε πλατφόρμες τύπου Cisco, η show ip igmp groups στον δρομολογητή τελευταίου άλματος εκτυπώνει τις ομάδες στις οποίες έχει γίνει εγγραφή δίπλα στη διεπαφή που τις άκουσε. Όταν η ομάδα λείπει από αυτή την έξοδο, η σήραγγα είναι περισπασμός: το αίτημα πέθανε στον μεταγωγέα πρόσβασης, στην υποδοχή του κεντρικού υπολογιστή ή σε ένα VLAN χωρίς querier.

Δύο συνηθισμένες αιτίες εξηγούν τις περισσότερες ελλείπουσες εγγραφές που έχω δει: ασυμφωνία έκδοσης IGMP μεταξύ κεντρικού υπολογιστή και δρομολογητή και εκλογή querier που κατέληξε σε μεταγωγέα που δεν δρομολογεί. Μια τρίτη είναι πιο λεπτή: η ομάδα έχει εγγραφεί αλλά στο λάθος VLAN, επειδή ο κεντρικός υπολογιστής έχει δύο κάρτες δικτύου και η εφαρμογή προσδέθηκε στη λάθος. Οι δέκτες IPv6 έχουν το αντίστοιχο πρόβλημα με το MLD, όπου η show ipv6 mld groups απαντά στην ίδια ερώτηση. Κανένα από αυτά δεν διορθώνεται αγγίζοντας τη σήραγγα, και γι' αυτό ακριβώς η σειρά έχει σημασία.

Μόλις η εγγραφή γίνει ορατή, επιβεβαιώστε ότι το PIM είναι ενεργό και στη διεπαφή προς τον δέκτη και στη διεπαφή που οδηγεί προς το σημείο συνάντησης. Ένας δρομολογητής με συμμετοχή IGMP αλλά χωρίς PIM στην ανάντη διεπαφή του θα κρατήσει την ομάδα σε τοπικό πίνακα και δεν θα στείλει τίποτα πουθενά.

Φτάνει το σύνολο BSR στην άλλη πλευρά;

Τα μηνύματα Bootstrap Router κινούνται άλμα προς άλμα μέσα σε ένα πεδίο PIM, και αυτή είναι η κατεύθυνση που σπάει μέσω σήραγγας. Οι υποψήφιοι RP στέλνουν τις ανακοινώσεις τους στον εκλεγμένο BSR μέσω unicast, οπότε το τμήμα RP προς BSR συνήθως επιβιώνει αμετάβλητο σε μια λειτουργική σήραγγα. Η πλημμύρα μηνυμάτων Bootstrap στην άλλη κατεύθυνση εξαρτάται από το ότι κάθε ενδιάμεση διεπαφή έχει ενεργό PIM και από το ότι τίποτα δεν σταματά τα μηνύματα σε ένα σύνορο. Η RFC 5059 ορίζει αυτή τη διανομή και τα όρια διαχειριστικού εύρους που επιτρέπεται να τη συντομεύσουν.

Μια δήλωση ip pim bsr-border, ένα ACL που φιλτράρει το πρωτόκολλο 103 ή μια σήραγγα IPsec βασισμένη σε πολιτική που δεν μπορεί να μεταφέρει multicast θα κόψουν την πλημμύρα αφήνοντας το unicast άθικτο. Ακριβώς αυτός ο συνδυασμός κάνει τη βλάβη να μοιάζει με πρόβλημα RP όταν στην πραγματικότητα είναι πρόβλημα προσβασιμότητας, και γι' αυτό διαβάζω την κατάσταση BSR πριν διαβάσω τη διαμόρφωση RP.

Στον δρομολογητή της απομακρυσμένης πλευράς, η show ip pim bsr-router ονομάζει τον εκλεγμένο BSR και το σύνολο RP που έμαθε· αν η έξοδος είναι κενή, η απομακρυσμένη πλευρά κάθεται στο δικό της πεδίο και καμία ποσότητα διαμόρφωσης RP δεν θα συμβιβάσει τις δύο. Συγκρίνετε τις περιοχές ομάδων και τις διευθύνσεις RP στην show ip pim rp mapping και στις δύο πλευρές της σήραγγας. Μια αντιστοίχιση που υπάρχει μόνο τοπικά παράγει ένα κοινόχρηστο δέντρο που καταλήγει στο λάθος σημείο, και ο δέκτης περιμένει για πάντα.

Ταιριάξτε την αντιστοίχιση RP και στις δύο πλευρές της σήραγγας

Το στατικό RP, το BSR και το anycast-RP είναι τρεις τρόποι να απαντήσεις στην ίδια ερώτηση, και το να τα αναμειγνύεις μέσω σήραγγας είναι ένας αξιόπιστος τρόπος να χτίσεις ένα πεδίο που δεν συγκλίνει ποτέ. Αν το κεντρικό άκρο χρησιμοποιεί BSR και το υποκατάστημα ένα στατικό ip pim rp-address που δείχνει σε άλλη διεύθυνση, το υποκατάστημα χτίζει το κοινόχρηστο δέντρο του προς ένα RP που δεν έχει ιδέα ότι ο δέκτης υπάρχει. Η αντιστοίχιση πρέπει να συμφωνεί και στην περιοχή ομάδας και στη διεύθυνση, αφού μια πιο συγκεκριμένη περιοχή κερδίζει μια ευρύτερη.

Το anycast-RP υπάρχει ακριβώς για να μπορούν δύο τοποθεσίες να μοιράζονται μία διεύθυνση RP, και αξίζει να το ονομάσουμε εδώ γιατί αλλάζει το τι σημαίνει «το ίδιο RP». Δύο RP που διαφημίζουν μία διεύθυνση είναι συνεπή εκ σχεδιασμού· δύο RP που διαφημίζουν διαφορετικές διευθύνσεις για την ίδια περιοχή δεν είναι, όσο υγιής κι αν φαίνεται κάθε τοποθεσία από μόνη της.

Για multicast ειδικό για την πηγή εντός του 232.0.0.0/8, το RP δεν ερωτάται ποτέ, οπότε μια κενή αντιστοίχιση RP δεν είναι αυτόματα βλάβη. Αποφασίστε ποιο μοντέλο υπηρεσίας χρησιμοποιεί η εφαρμογή πριν κυνηγήσετε ένα RP που δεν χρειάστηκε ποτέ.

Διαβάστε την αναζήτηση RPF προς την πηγή

Το PIM χτίζει ένα δέντρο αντιστρέφοντας τη διαδρομή unicast, οπότε ο έλεγχος που μετράει είναι η διαδρομή πίσω στην πηγή, ή πίσω στο RP για ένα κοινόχρηστο δέντρο. Μια εγγραφή που φτάνει σε διεπαφή που ο δρομολογητής δεν θεωρεί ανάντη απορρίπτεται, και ο λόγος καταγράφεται ως αποτυχία RPF και όχι ως αποτυχία σήραγγας. Σε δρομολογητή υποκαταστήματος με προεπιλεγμένη διαδρομή μέσω της σήραγγας και πιο συγκεκριμένη διαδρομή μέσω WAN, η διεπαφή RPF μπορεί εύκολα να είναι το WAN ακόμη κι αν η πηγή είναι προσβάσιμη μόνο μέσω της σήραγγας. Αυτός είναι ο πιο συχνός λόγος που μια εγγραφή απορρίπτεται σιωπηλά.

Η show ip rpf 192.0.2.10 εκτυπώνει τη διεπαφή που επιλέχθηκε, το επόμενο άλμα και τη διαδρομή που παρήγαγε την απόφαση, και συνήθως αρκεί για να δει κανείς την ασυμφωνία. Μια στατική διαδρομή multicast όπως η ip mroute 192.0.2.0 255.255.255.0 tunnel0 υπερισχύει της αναζήτησης unicast για αυτό το πρόθεμα, και είναι μια θεμιτή διόρθωση όταν η τοπολογία multicast διαφέρει πραγματικά από την τοπολογία unicast. Αντιμετωπίστε την ως διαμόρφωση που πρέπει να τεκμηριωθεί, όχι ως μπάλωμα που εφαρμόστηκε κατά τη διάρκεια ενός συμβάντος και μετά ξεχάστηκε.

Επιβεβαιώστε την εγγραφή με εντολές, όχι με ping

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

show ip igmp groups 239.1.1.1
show ip pim rp mapping
show ip pim neighbor
show ip rpf 192.0.2.10
show ip mroute 239.1.1.1

Μια συμπληρωμένη καταχώριση (S,G) με πραγματική εισερχόμενη διεπαφή και μη κενή λίστα εξερχόμενων σημαίνει ότι το επίπεδο ελέγχου τελείωσε τη δουλειά του. Μια καταχώριση της οποίας η εισερχόμενη διεπαφή διαβάζεται ως Null, ή ένας μετρητής με ετικέτα RPF failed που συνεχίζει να ανεβαίνει, δείχνει πίσω στην προηγούμενη ενότητα και όχι στη σήραγγα.

Αν και οι πέντε εντολές φαίνονται σωστές και ο δέκτης εξακολουθεί να μη βλέπει τίποτα, ο εναπομείνας ύποπτος είναι η πολιτική της ίδιας της σήραγγας: ένα κρυπτογραφικό ACL ή ένας κανόνας τείχους προστασίας που επιτρέπει το πρωτόκολλο δρομολόγησης unicast αλλά όχι το PIM, το IGMP ή την ίδια την κίνηση της ομάδας. Σε σήραγγα IPsec βασισμένη σε πολιτική, το multicast δεν μεταφέρεται καθόλου, οπότε η απάντηση είναι σχεδιασμός GRE ή VTI και όχι άλλη μια εξαίρεση φίλτρου. Σημειώστε ποιος από τους πέντε ελέγχους απέτυχε πριν αλλάξετε οτιδήποτε, και μετά αλλάξτε μόνο εκείνο το επίπεδο.