Γεια σου habr. Αυτήν τη στιγμή είμαι επικεφαλής μαθημάτων για τον "Μηχανικό Δικτύων" στο OTUS.
Εν αναμονή της έναρξης νέας εγγραφής για το μάθημα
Υπάρχει τεράστιος όγκος υλικού για τη λειτουργία του VxLAN EVPN, επομένως θέλω να συλλέξω διάφορες εργασίες και πρακτικές για την επίλυση προβλημάτων σε ένα σύγχρονο κέντρο δεδομένων.
Στο πρώτο μέρος του κύκλου τεχνολογίας VxLAN EVPN, θέλω να εξετάσω έναν τρόπο οργάνωσης της συνδεσιμότητας L2 μεταξύ κεντρικών υπολογιστών πάνω από ένα εργοστάσιο δικτύου.
Όλα τα παραδείγματα θα εκτελεστούν σε Cisco Nexus 9000v, συναρμολογημένο στην τοπολογία Spine-Leaf. Δεν θα σταθούμε στη ρύθμιση του δικτύου Underlay σε αυτό το άρθρο.
- δίκτυο υποστρώματος
- Ομοτίμηση BGP για διεύθυνση-οικογένεια l2vpn evpn
- Ρύθμιση NVE
- Καταστολή-αρπ
δίκτυο υποστρώματος
Η τοπολογία που χρησιμοποιείται είναι η εξής:
Ας ορίσουμε τη διεύθυνση σε όλες τις συσκευές:
Spine-1 - 10.255.1.101
Spine-2 - 10.255.1.102
Leaf-11 - 10.255.1.11
Leaf-12 - 10.255.1.12
Leaf-21 - 10.255.1.21
Host-1 - 192.168.10.10
Host-2 - 192.168.10.20
Ας ελέγξουμε ότι υπάρχει σύνδεση IP μεταξύ όλων των συσκευών:
Leaf21# sh ip route
<........>
10.255.1.11/32, ubest/mbest: 2/0 ! Leaf-11 доступен чеерз два Spine
*via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
*via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.12/32, ubest/mbest: 2/0 ! Leaf-12 доступен чеерз два Spine
*via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
*via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.21/32, ubest/mbest: 2/0, attached
*via 10.255.1.22, Lo0, [0/0], 00:02:20, local
*via 10.255.1.22, Lo0, [0/0], 00:02:20, direct
10.255.1.101/32, ubest/mbest: 1/0
*via 10.255.1.101, Eth1/4, [110/41], 00:00:06, ospf-UNDERLAY, intra
10.255.1.102/32, ubest/mbest: 1/0
*via 10.255.1.102, Eth1/3, [110/41], 00:00:03, ospf-UNDERLAY, intra
Ας ελέγξουμε ότι ο τομέας VPC έχει δημιουργηθεί και ότι και οι δύο διακόπτες έχουν περάσει τον έλεγχο συνέπειας και ότι οι ρυθμίσεις και στους δύο κόμβους είναι ίδιες:
Leaf11# show vpc
vPC domain id : 1
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
Configuration consistency status : success
Per-vlan consistency status : success
Type-2 consistency status : success
vPC role : primary
Number of vPCs configured : 0
Peer Gateway : Disabled
Dual-active excluded VLANs : -
Graceful Consistency Check : Enabled
Auto-recovery status : Disabled
Delay-restore status : Timer is off.(timeout = 30s)
Delay-restore SVI status : Timer is off.(timeout = 10s)
Operational Layer3 Peer-router : Disabled
vPC status
----------------------------------------------------------------------------
Id Port Status Consistency Reason Active vlans
-- ------------ ------ ----------- ------ ---------------
5 Po5 up success success 1
BGP peering
Τέλος, μπορούμε να προχωρήσουμε στη διαμόρφωση του δικτύου Overlay.
Ως μέρος του άρθρου, είναι απαραίτητο να οργανωθεί ένα δίκτυο μεταξύ κεντρικών υπολογιστών, όπως φαίνεται στο παρακάτω διάγραμμα:
Για να διαμορφώσετε ένα δίκτυο Overlay, πρέπει να ενεργοποιήσετε το BGP στους διακόπτες Spine και Leaf με υποστήριξη για την οικογένεια l2vpn evpn:
feature bgp
nv overlay evpn
Στη συνέχεια, θα πρέπει να ρυθμίσετε τις παραμέτρους του BGP peering μεταξύ Leaf και Spine. Για να απλοποιήσουμε τη διαμόρφωση και να βελτιστοποιήσουμε τη διανομή των πληροφοριών δρομολόγησης, διαμορφώνουμε το Spine ως διακομιστή Route-Reflector. Θα γράψουμε όλα τα φύλλα στη διαμόρφωση μέσω προτύπων για να βελτιστοποιήσουμε τη ρύθμιση.
Έτσι οι ρυθμίσεις στο Spine μοιάζουν με αυτό:
router bgp 65001
template peer LEAF
remote-as 65001
update-source loopback0
address-family l2vpn evpn
send-community
send-community extended
route-reflector-client
neighbor 10.255.1.11
inherit peer LEAF
neighbor 10.255.1.12
inherit peer LEAF
neighbor 10.255.1.21
inherit peer LEAF
Η ρύθμιση στο διακόπτη Leaf μοιάζει παρόμοια:
router bgp 65001
template peer SPINE
remote-as 65001
update-source loopback0
address-family l2vpn evpn
send-community
send-community extended
neighbor 10.255.1.101
inherit peer SPINE
neighbor 10.255.1.102
inherit peer SPINE
Στη Σπονδυλική στήλη, ελέγξτε το peering με όλους τους διακόπτες Leaf:
Spine1# sh bgp l2vpn evpn summary
<.....>
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.255.1.11 4 65001 7 8 6 0 0 00:01:45 0
10.255.1.12 4 65001 7 7 6 0 0 00:01:16 0
10.255.1.21 4 65001 7 7 6 0 0 00:01:01 0
Όπως μπορείτε να δείτε, δεν υπήρχαν προβλήματα με το BGP. Ας προχωρήσουμε στη ρύθμιση του VxLAN. Περαιτέρω διαμόρφωση θα πραγματοποιηθεί μόνο στο πλάι των διακοπτών Leaf. Το Spine λειτουργεί μόνο ως ο πυρήνας του δικτύου και εμπλέκεται μόνο στη μετάδοση της κίνησης. Όλες οι εργασίες για την ενθυλάκωση και τον καθορισμό διαδρομής γίνονται μόνο στους διακόπτες Leaf.
Ρύθμιση NVE
NVE - εικονική διεπαφή δικτύου
Πριν ξεκινήσετε τη ρύθμιση, ας εισαγάγουμε κάποια ορολογία:
VTEP - Vitual Tunnel End Point, η συσκευή στην οποία ξεκινά ή τελειώνει η σήραγγα VxLAN. Το VTEP δεν είναι απαραίτητα οποιαδήποτε συσκευή δικτύου. Ένας διακομιστής που υποστηρίζει τεχνολογία VxLAN μπορεί επίσης να ενεργήσει. Στην τοπολογία μας, όλοι οι διακόπτες Leaf είναι VTEP.
VNI - Virtual Network Index - αναγνωριστικό δικτύου εντός VxLAN. Μπορείτε να σχεδιάσετε μια αναλογία με το VLAN. Ωστόσο, υπάρχουν κάποιες διαφορές. Όταν χρησιμοποιείτε ένα ύφασμα, τα VLAN γίνονται μοναδικά μόνο μέσα σε έναν διακόπτη Leaf και δεν μεταδίδονται μέσω του δικτύου. Αλλά κάθε VLAN μπορεί να συσχετιστεί με έναν αριθμό VNI που έχει ήδη μεταδοθεί μέσω του δικτύου. Το πώς φαίνεται και πώς μπορεί να χρησιμοποιηθεί θα συζητηθεί παρακάτω.
Ενεργοποιήστε τη λειτουργία για την τεχνολογία VxLAN και τη δυνατότητα συσχέτισης αριθμών VLAN με αριθμό VNI:
feature nv overlay
feature vn-segment-vlan-based
Ας διαμορφώσουμε τη διεπαφή NVE, η οποία είναι υπεύθυνη για τη λειτουργία του VxLAN. Αυτή η διεπαφή είναι υπεύθυνη για την ενθυλάκωση πλαισίων σε κεφαλίδες VxLAN. Μπορείτε να σχεδιάσετε μια αναλογία με τη διεπαφή Tunnel για το GRE:
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0
Στον διακόπτη Leaf-21, όλα δημιουργούνται χωρίς προβλήματα. Ωστόσο, αν ελέγξουμε την έξοδο της εντολής show nve peers
, τότε θα είναι άδειο. Εδώ πρέπει να επιστρέψετε στη ρύθμιση VPC. Βλέπουμε ότι το Leaf-11 και το Leaf-12 συνδέονται και ενώνονται με έναν τομέα VPC. Αυτό έχει ως αποτέλεσμα την εξής κατάσταση:
Ο κεντρικός υπολογιστής-2 στέλνει ένα πλαίσιο στο Leaf-21 για να μεταδοθεί μέσω του δικτύου στον κεντρικό υπολογιστή-1. Ωστόσο, το Leaf-21 βλέπει ότι η διεύθυνση MAC του Host-1 είναι διαθέσιμη μέσω δύο VTEP ταυτόχρονα. Τι πρέπει να κάνει το Leaf-21 σε αυτή την περίπτωση; Άλλωστε, αυτό σημαίνει ότι θα μπορούσε να εμφανιστεί ένας βρόχος στο δίκτυο.
Για να λύσουμε αυτήν την κατάσταση, χρειαζόμαστε τα Leaf-11 και Leaf-12 να λειτουργούν ως μία συσκευή εντός του εργοστασίου. Λύνεται πολύ απλά. Στη διεπαφή Loopback από την οποία κατασκευάζουμε τη σήραγγα, προσθέστε τη δευτερεύουσα διεύθυνση. Η δευτερεύουσα διεύθυνση πρέπει να είναι η ίδια και στα δύο VTEP.
interface loopback0
ip add 10.255.1.10/32 secondary
Έτσι, από την άποψη άλλων VTEP, έχουμε την ακόλουθη τοπολογία:
Δηλαδή, τώρα το τούνελ θα κατασκευαστεί μεταξύ της διεύθυνσης IP του Leaf-21 και της εικονικής IP μεταξύ δύο Leaf-11 και Leaf-12. Τώρα δεν θα υπάρχουν προβλήματα με την εκμάθηση της διεύθυνσης MAC από δύο συσκευές και η κίνηση μπορεί να μεταφερθεί από το ένα VTEP στο άλλο. Ποιο από τα δύο VTEP θα επεξεργαστεί την κίνηση αποφασίζεται χρησιμοποιώντας τον πίνακα δρομολόγησης στο Spine:
Spine1# sh ip route
<.....>
10.255.1.10/32, ubest/mbest: 2/0
*via 10.255.1.11, Eth1/1, [110/41], 1d01h, ospf-UNDERLAY, intra
*via 10.255.1.12, Eth1/2, [110/41], 1d01h, ospf-UNDERLAY, intra
10.255.1.11/32, ubest/mbest: 1/0
*via 10.255.1.11, Eth1/1, [110/41], 1d22h, ospf-UNDERLAY, intra
10.255.1.12/32, ubest/mbest: 1/0
*via 10.255.1.12, Eth1/2, [110/41], 1d01h, ospf-UNDERLAY, intra
Όπως μπορείτε να δείτε παραπάνω, η διεύθυνση 10.255.1.10 είναι διαθέσιμη αμέσως μέσω δύο Next-hops.
Σε αυτό το στάδιο, καταλάβαμε τη βασική συνδεσιμότητα. Ας προχωρήσουμε στη ρύθμιση της διεπαφής NVE:
Θα ενεργοποιήσουμε αμέσως το Vlan 10 και θα το συσχετίσουμε με το VNI 10000 σε κάθε Leaf για κεντρικούς υπολογιστές. Ρυθμίστε μια σήραγγα L2 μεταξύ των κεντρικών υπολογιστών
vlan 10 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
vn-segment 10000 ! Ассоциируем VLAN с номер VNI
interface nve1
member vni 10000 ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
ingress-replication protocol bgp ! указываем, что для распространения информации о хосте используем BGP
Τώρα ας ελέγξουμε τους ομοτίμους και τον πίνακα nve για BGP EVPN:
Leaf21# sh nve peers
Interface Peer-IP State LearnType Uptime Router-Mac
--------- --------------- ----- --------- -------- -----------------
nve1 10.255.1.10 Up CP 00:00:41 n/a ! Видим что peer доступен с secondary адреса
Leaf11# sh bgp l2vpn evpn
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000) ! От кого именно пришел этот l2VNI
*>l[3]:[0]:[32]:[10.255.1.10]/88 ! EVPN route-type 3 - показывает нашего соседа, который так же знает об l2VNI10000
10.255.1.10 100 32768 i
*>i[3]:[0]:[32]:[10.255.1.20]/88
10.255.1.20 100 0 i
* i 10.255.1.20 100 0 i
Route Distinguisher: 10.255.1.21:32777
* i[3]:[0]:[32]:[10.255.1.20]/88
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 i
Παραπάνω βλέπουμε διαδρομές μόνο EVPN διαδρομής τύπου 3. Αυτός ο τύπος διαδρομών μιλάει για peer (Leaf), αλλά πού είναι οι οικοδεσπότες μας;
Και το θέμα είναι ότι οι πληροφορίες σχετικά με τους κεντρικούς υπολογιστές MAC μεταδίδονται μέσω EVPN διαδρομής τύπου 2
Για να δείτε τους κεντρικούς υπολογιστές μας, πρέπει να διαμορφώσετε το EVPN route-type 2:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export auto
Ας κάνουμε ping από το Host-2 στον Host-1:
Firewall2# ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1): 56 data bytes
36 bytes from 192.168.10.2: Destination Host Unreachable
Request 0 timed out
64 bytes from 192.168.10.1: icmp_seq=1 ttl=254 time=215.555 ms
64 bytes from 192.168.10.1: icmp_seq=2 ttl=254 time=38.756 ms
64 bytes from 192.168.10.1: icmp_seq=3 ttl=254 time=42.484 ms
64 bytes from 192.168.10.1: icmp_seq=4 ttl=254 time=40.983 ms
Και παρακάτω μπορούμε να δούμε ότι ο τύπος διαδρομής 2 εμφανίστηκε στον πίνακα BGP με τη διεύθυνση MAC των κεντρικών υπολογιστών - 5001.0007.0007 και 5001.0008.0007
Leaf11# sh bgp l2vpn evpn
<......>
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216 ! evpn route-type 2 и mac адрес хоста 1
10.255.1.10 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216 ! evpn route-type 2 и mac адрес хоста 2
* i 10.255.1.20 100 0 i
*>l[3]:[0]:[32]:[10.255.1.10]/88
10.255.1.10 100 32768 i
Route Distinguisher: 10.255.1.21:32777
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 i
Στη συνέχεια, μπορείτε να δείτε λεπτομερείς πληροφορίες για το Update, στο οποίο λάβατε πληροφορίες σχετικά με τον κεντρικό υπολογιστή MAC. Παρακάτω δεν είναι ολόκληρη η έξοδος της εντολής
Leaf21# sh bgp l2vpn evpn 5001.0007.0007
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.255.1.11:32777 ! отправил Update с MAC Host. Не виртуальный адрес VPC, а адрес Leaf
BGP routing table entry for [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216,
version 1507
Paths: (2 available, best #2)
Flags: (0x000202) (high32 00000000) on xmit-list, is not in l2rib/evpn, is not i
n HW
Path type: internal, path is valid, not best reason: Neighbor Address, no labe
led nexthop
AS-Path: NONE, path sourced internal to AS
10.255.1.10 (metric 81) from 10.255.1.102 (10.255.1.102) ! с кем именно строим VxLAN тоннель
Origin IGP, MED not set, localpref 100, weight 0
Received label 10000 ! Номер VNI, который ассоциирован с VLAN, в котором находится Host
Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8 ! Тут видно, что RT сформировался автоматически на основе номеров AS и VNI
Originator: 10.255.1.11 Cluster list: 10.255.1.102
<........>
Ας δούμε πώς φαίνονται τα κουφώματα όταν περνούν από το εργοστάσιο:
Καταστολή-ARP
Ωραία, έχουμε μια σύνδεση L2 μεταξύ των κεντρικών υπολογιστών και αυτό θα μπορούσε να είναι το τέλος της. Ωστόσο, δεν είναι όλα τόσο απλά. Όσο έχουμε λίγους γηπεδούχους, δεν θα υπάρχουν προβλήματα. Ας φανταστούμε όμως καταστάσεις που έχουμε εκατοντάδες και χιλιάδες οικοδεσπότες. Τι πρόβλημα μπορούμε να αντιμετωπίσουμε;
Αυτό το πρόβλημα είναι η κυκλοφορία BUM (Μετάδοση, Άγνωστη Unicast, Multicast). Στο πλαίσιο αυτού του άρθρου, θα εξετάσουμε την επιλογή καταπολέμησης της κυκλοφορίας εκπομπής.
Η κύρια γεννήτρια Broadcast στα δίκτυα Ethernet είναι οι ίδιοι οι κεντρικοί υπολογιστές μέσω του πρωτοκόλλου ARP.
Το Nexus εφαρμόζει τον ακόλουθο μηχανισμό για την αντιμετώπιση αιτημάτων ARP - suppress-arp.
Αυτή η δυνατότητα λειτουργεί ως εξής:
- Ο κεντρικός υπολογιστής-1 στέλνει ένα αίτημα APR στη διεύθυνση Broadcast του δικτύου του.
- Το αίτημα φτάνει στο διακόπτη Leaf και αντί να περάσει αυτό το αίτημα περαιτέρω στο εργοστάσιο προς το Host-2, το Leaf απαντά μόνο του και υποδεικνύει την επιθυμητή IP και MAC.
Έτσι, το αίτημα Broadcast δεν πήγε στο εργοστάσιο. Αλλά πώς μπορεί να λειτουργήσει αυτό εάν το Leaf γνωρίζει μόνο τη διεύθυνση MAC;
Όλα είναι πολύ απλά, το EVPN route-type 2, εκτός από τη διεύθυνση MAC, μπορεί να μεταδώσει ένα πακέτο MAC/IP. Για να γίνει αυτό, το Leaf πρέπει να ρυθμιστεί με μια διεύθυνση IP στο VLAN. Τίθεται το ερώτημα, τι IP να ρωτήσω; Στο nexus, είναι δυνατή η δημιουργία μιας κατανεμημένης (ίδιας) διεύθυνσης σε όλους τους διακόπτες:
feature interface-vlan
fabric forwarding anycast-gateway-mac 0001.0001.0001 ! задаем virtual mac для создания распределенного шлюза между всеми коммутаторами
interface Vlan10
no shutdown
ip address 192.168.10.254/24 ! на всех Leaf задаем одинаковый IP
fabric forwarding mode anycast-gateway ! говорим использовать Virtual mac
Έτσι, από την άποψη των κεντρικών υπολογιστών, το δίκτυο θα μοιάζει με αυτό:
Ελέγξτε BGP l2route evpn
Leaf11# sh bgp l2vpn evpn
<......>
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216
10.255.1.21 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
10.255.1.10 100 0 i
* i 10.255.1.10 100 0 i
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.10.20]/248
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
<......>
Route Distinguisher: 10.255.1.21:32777
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 i
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.10.20]/248
*>i 10.255.1.20 100 0 i
<......>
Από την έξοδο της εντολής, φαίνεται ότι στο EVPN route-type 2, εκτός από το MAC, βλέπουμε τώρα και τη διεύθυνση IP του κεντρικού υπολογιστή.
Ας επιστρέψουμε στη ρύθμιση suppress-arp. Αυτή η ρύθμιση είναι ενεργοποιημένη για κάθε VNI ξεχωριστά:
interface nve1
member vni 10000
suppress-arp
Τότε υπάρχει κάποια δυσκολία:
- Αυτή η δυνατότητα απαιτεί χώρο στη μνήμη TCAM. Θα δώσω ένα παράδειγμα ρύθμισης για suppress-arp:
hardware access-list tcam region arp-ether 256
Αυτή η ρύθμιση θα απαιτήσει διπλό πλάτος. Δηλαδή, εάν ορίσετε το 256, τότε το 512 πρέπει να κυκλοφορήσει στο TCAM. Η ρύθμιση του TCAM δεν εμπίπτει στο πεδίο εφαρμογής αυτού του άρθρου, καθώς η ρύθμιση του TCAM εξαρτάται μόνο από την εργασία που σας έχει ανατεθεί και μπορεί να διαφέρει από το ένα δίκτυο στο άλλο.
- Η υλοποίηση του suppress-arp πρέπει να γίνεται σε όλους τους διακόπτες Leaf. Ωστόσο, μπορεί να προκύψει πολυπλοκότητα κατά τη ρύθμιση παραμέτρων σε ζεύγη φύλλων που βρίσκονται σε έναν τομέα VPC. Κατά την αλλαγή του TCAM, η συνέπεια μεταξύ των ζευγών θα σπάσει και ένας κόμβος μπορεί να τεθεί εκτός λειτουργίας. Επιπλέον, ενδέχεται να απαιτείται επανεκκίνηση συσκευής για την εφαρμογή της ρύθμισης αλλαγής TCAM.
Ως αποτέλεσμα, θα πρέπει να εξετάσετε προσεκτικά εάν αξίζει να εφαρμόσετε αυτήν τη ρύθμιση σε ένα εργοστάσιο που λειτουργεί στην περίπτωσή σας.
Αυτό ολοκληρώνει το πρώτο μέρος του κύκλου. Στο επόμενο μέρος, θα εξετάσουμε τη δρομολόγηση μέσω ενός εργοστασίου VxLAN με διαχωρισμό δικτύου μεταξύ διαφορετικών VRF.
Και τώρα καλώ όλους να
Πηγή: www.habr.com