🥇Εργοστάσιο VxLAN. Μέρος 3

Γεια σου, Χαμπρ. Ολοκληρώνω μια σειρά άρθρων, αφιερωμένο στην έναρξη του μαθήματος "Μηχανικός Δικτύου" από την OTUS, χρησιμοποιώντας τεχνολογία VxLAN EVPN για δρομολόγηση εντός του υφάσματος και χρήση Τείχους προστασίας για περιορισμό της πρόσβασης μεταξύ εσωτερικών υπηρεσιών

Προηγούμενα μέρη της σειράς μπορείτε να βρείτε στους παρακάτω συνδέσμους:

Σήμερα θα συνεχίσουμε να μελετάμε τη λογική δρομολόγησης μέσα στο ύφασμα VxLAN. Στο προηγούμενο μέρος, εξετάσαμε τη δρομολόγηση εντός υφάσματος σε ένα μόνο VRF. Ωστόσο, μπορεί να υπάρχει ένας τεράστιος αριθμός υπηρεσιών πελατών στο δίκτυο και όλες πρέπει να διανέμονται σε διαφορετικά VRF για να διαφοροποιηθεί η πρόσβαση μεταξύ τους. Εκτός από τον διαχωρισμό δικτύου, μια επιχείρηση μπορεί να χρειαστεί να συνδέσει ένα Τείχος προστασίας για να περιορίσει την πρόσβαση μεταξύ αυτών των υπηρεσιών. Ναι, αυτή δεν μπορεί να ονομαστεί η καλύτερη λύση, αλλά οι σύγχρονες πραγματικότητες απαιτούν «μοντέρνες λύσεις».

Ας εξετάσουμε δύο επιλογές για δρομολόγηση μεταξύ VRF:

Δρομολόγηση χωρίς έξοδο από το ύφασμα VxLAN.
Δρομολόγηση σε εξωτερικό εξοπλισμό.

Ας ξεκινήσουμε με τη λογική δρομολόγησης μεταξύ των VRF. Υπάρχει ένας συγκεκριμένος αριθμός VRF. Για να δρομολογήσετε μεταξύ VRF, πρέπει να επιλέξετε μια συσκευή στο δίκτυο που θα γνωρίζει για όλα τα VRF (ή τα μέρη μεταξύ των οποίων απαιτείται δρομολόγηση). Μια τέτοια συσκευή θα μπορούσε να είναι, για παράδειγμα, ένας από τους διακόπτες Leaf (ή όλοι ταυτόχρονα) . Αυτή η τοπολογία θα μοιάζει με αυτό:

Ποια είναι τα μειονεκτήματα αυτής της τοπολογίας;

Σωστά, κάθε Leaf πρέπει να γνωρίζει για όλα τα VRF (και όλες τις πληροφορίες που υπάρχουν σε αυτά) στο δίκτυο, γεγονός που οδηγεί σε απώλεια μνήμης και αυξημένο φόρτο δικτύου. Εξάλλου, πολύ συχνά κάθε διακόπτης Leaf δεν χρειάζεται να γνωρίζει όλα όσα υπάρχουν στο δίκτυο.

Ωστόσο, ας εξετάσουμε αυτή τη μέθοδο με περισσότερες λεπτομέρειες, καθώς για μικρά δίκτυα αυτή η επιλογή είναι αρκετά κατάλληλη (αν δεν υπάρχουν συγκεκριμένες επιχειρηματικές απαιτήσεις)

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

Και η απάντηση βρίσκεται σε λειτουργίες όπως η εξαγωγή και η εισαγωγή πληροφοριών δρομολόγησης (η ρύθμιση αυτής της τεχνολογίας εξετάστηκε δεύτερος μέρη του κύκλου). Να επαναλάβω εν συντομία:

Όταν ρυθμίζετε το VRF στο AF, πρέπει να καθορίσετε route-target για πληροφορίες δρομολόγησης εισαγωγής και εξαγωγής. Μπορείτε να το καθορίσετε αυτόματα. Στη συνέχεια, η τιμή θα περιλαμβάνει τα ASN BGP και L3 VNI που σχετίζονται με το VRF. Αυτό είναι βολικό όταν έχετε μόνο ένα ASN στο εργοστάσιό σας:

vrf context PROD20
  address-family ipv4 unicast
    route-target export auto      ! В автоматическом режиме экспортируется RT-65001:99000
    route-target import auto

Ωστόσο, εάν έχετε περισσότερα από ένα ASN και πρέπει να μεταφέρετε διαδρομές μεταξύ τους, τότε η μη αυτόματη διαμόρφωση θα είναι μια πιο βολική και επεκτάσιμη επιλογή route-target. Η σύσταση για μη αυτόματη ρύθμιση είναι ο πρώτος αριθμός, χρησιμοποιήστε έναν που σας βολεύει, για παράδειγμα, 9999.
Το δεύτερο θα πρέπει να οριστεί ως ίσο με το VNI για αυτό το VRF.

Ας το διαμορφώσουμε ως εξής:

vrf context PROD10
  address-family ipv4 unicast
    route-target export 9999:99000          
    route-target import 9999:99000
    route-target import 9999:77000         ! Пример 1 import из другого VRF
    route-target import 9999:88000         ! Пример 2 import из другого VRF

Πώς φαίνεται στον πίνακα δρομολόγησης:

Leaf11# sh ip route vrf prod
<.....>
192.168.20.0/24, ubest/mbest: 1/0
    *via 10.255.1.20%default, [200/0], 00:24:45, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN          ! префикс доступен через L3VNI 99000

Ας εξετάσουμε τη δεύτερη επιλογή για δρομολόγηση μεταξύ VRF - μέσω εξωτερικού εξοπλισμού, για παράδειγμα Firewall.

Υπάρχουν πολλές επιλογές για εργασία μέσω εξωτερικής συσκευής:

Η συσκευή γνωρίζει τι είναι το VxLAN και μπορούμε να το προσθέσουμε σε μέρος του υφάσματος.
Η συσκευή δεν γνωρίζει τίποτα για το VxLAN.

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

Ας εξετάσουμε τη δεύτερη επιλογή, όταν το Firewall μας δεν γνωρίζει τίποτα για το VxLAN (τώρα, φυσικά, εμφανίζεται εξοπλισμός με υποστήριξη VxLAN. Για παράδειγμα, το Checkpoint ανακοίνωσε την υποστήριξή του στην έκδοση R81. Μπορείτε να διαβάσετε σχετικά εδώ, ωστόσο, όλα αυτά βρίσκονται στο στάδιο της δοκιμής και δεν υπάρχει εμπιστοσύνη στη σταθερότητα της λειτουργίας).

Όταν συνδέουμε μια εξωτερική συσκευή, έχουμε το ακόλουθο διάγραμμα:

Όπως μπορείτε να δείτε από το διάγραμμα, εμφανίζεται ένα σημείο συμφόρησης στη διεπαφή με το Τείχος προστασίας. Αυτό πρέπει να λαμβάνεται υπόψη στο μέλλον κατά τον σχεδιασμό του δικτύου και τη βελτιστοποίηση της κυκλοφορίας του δικτύου.

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

Ως αποτέλεσμα, το σχήμα με το Firewall:

Δηλαδή, στο Τείχος προστασίας πρέπει να διαμορφώσετε μια διεπαφή για κάθε VRF που βρίσκεται στο δίκτυο. Γενικά, η λογική δεν φαίνεται περίπλοκη και το μόνο πράγμα που δεν μου αρέσει εδώ είναι ο τεράστιος αριθμός διεπαφών στο τείχος προστασίας, αλλά εδώ είναι καιρός να σκεφτούμε την αυτοματοποίηση.

Πρόστιμο. Συνδέσαμε το Firewall και το προσθέσαμε σε όλα τα VRF. Αλλά πώς μπορούμε τώρα να αναγκάσουμε την κυκλοφορία από κάθε φύλλο να περάσει από αυτό το Τείχος προστασίας;

Στο Leaf που είναι συνδεδεμένο στο Firewall, δεν θα προκύψουν προβλήματα, καθώς όλες οι διαδρομές είναι τοπικές:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6w5d, static       ! маршрут по-умолчанию через Firewall

Ωστόσο, τι γίνεται με τα απομακρυσμένα φύλλα; Πώς να τους περάσω την προεπιλεγμένη εξωτερική διαδρομή;

Αυτό είναι σωστό, μέσω EVPN route-type 5, όπως κάθε άλλο πρόθεμα πάνω από το ύφασμα VxLAN. Ωστόσο, αυτό δεν είναι τόσο απλό (αν μιλάμε για Cisco, καθώς δεν έχω ελέγξει με άλλους προμηθευτές)

Η προεπιλεγμένη διαδρομή πρέπει να διαφημίζεται από το Leaf στο οποίο είναι συνδεδεμένο το Firewall. Ωστόσο, για να μεταδώσει τη διαδρομή, το Leaf πρέπει να το γνωρίζει το ίδιο. Και εδώ προκύπτει ένα συγκεκριμένο πρόβλημα (ίσως μόνο για μένα), η διαδρομή πρέπει να καταχωρηθεί στατικά στο VRF όπου θέλετε να διαφημίσετε μια τέτοια διαδρομή:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Στη συνέχεια, στη διαμόρφωση BGP, ορίστε αυτήν τη διαδρομή στο AF IPv4:

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0

Ωστόσο, δεν είναι μόνο αυτό. Με αυτόν τον τρόπο η προεπιλεγμένη διαδρομή δεν θα συμπεριληφθεί στην οικογένεια l2vpn evpn. Εκτός από αυτό, πρέπει να διαμορφώσετε την ανακατανομή:

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0
            redistribute static route-map COMMON_OUT

Υποδεικνύουμε ποια προθέματα θα μπουν στο BGP μέσω της ανακατανομής

route-map COMMON_OUT permit 10
  match ip address prefix-list COMMON_OUT

ip prefix-list COMMON_OUT seq 10 permit 0.0.0.0/0

Τώρα το πρόθεμα 0.0.0.0/0 εμπίπτει στη διαδρομή EVPN τύπου 5 και μεταδίδεται στο υπόλοιπο φύλλο:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.255.1.5%default, [200/0], 5w6d, bgp-65001, internal, tag 65001, segid: 99000 tunnelid: 0xaff0105 encap: VXLAN
    ! 10.255.1.5 - Виртуальный адрес Leaf(так как Leaf выступают в качестве VPС пары), к которому подключен Firewall

Στον πίνακα BGP μπορούμε επίσης να παρατηρήσουμε τον τύπο διαδρομής 5 που προκύπτει με την προεπιλεγμένη διαδρομή μέσω 10.255.1.5:

* i[5]:[0]:[0]:[0]:[0.0.0.0]/224
                      10.255.1.5                        100          0 i
*>i                   10.255.1.5                        100          0 i

Αυτό ολοκληρώνει τη σειρά άρθρων που είναι αφιερωμένα στο EVPN. Στο μέλλον, θα προσπαθήσω να εξετάσω τη λειτουργία του VxLAN σε συνδυασμό με το Multicast, καθώς αυτή η μέθοδος θεωρείται πιο επεκτάσιμη (προς το παρόν μια αμφιλεγόμενη δήλωση)

Εάν εξακολουθείτε να έχετε ερωτήσεις/προτάσεις σχετικά με το θέμα, εξετάστε τυχόν λειτουργικότητα του EVPN - γράψτε, θα το εξετάσουμε περαιτέρω.

Πηγή: www.habr.com

Εργοστάσιο VxLAN. Μέρος 3ο

Προσθέστε ένα σχόλιο Ακύρωση απάντησης