Cześć, Habr. Kontynuuję cykl artykułów na temat technologii VxLAN EVPN, które zostały napisane specjalnie na potrzeby uruchomienia kursu od OTUS. Dzisiaj przyjrzymy się interesującej części zadań — routingu. Jakby to nie brzmiało banalnie, w ramach pracy sieciowej fabryki wszystko może być bardziej skomplikowane.
W poprzedniej części osiągnęliśmy jedną domenę rozgłoszeniową, zbudowaną na bazie sieci fabrycznej na Nexus 9000v. Jednak to nie jest cały zakres zadań, które musimy rozwiązać w ramach sieci centrum danych. Dzisiaj przyjrzymy się kolejnemu zadaniu — routingu pomiędzy sieciami lub pomiędzy VNI.
Przypomnę, że używamy topologii Spine-Leaf:
Na początek omówimy, jak przebiega routing i jakie są jego cechy.
Aby lepiej to zrozumieć, uprościmy schemat logiczny i dodamy jeszcze jeden VNI 20000 dla Host-2. W rezultacie otrzymujemy:
Jak w takim przypadku można przesłać ruch z jednego hosta do drugiego?
Są dwie opcje:
- Na wszystkich przełącznikach Leaf przechowywać informacje o wszystkich VNI, wtedy cały routing odbywa się na pierwszym Leaf w sieci;
- Użyć specjalnie dedykowanego — L3 VNI
Pierwsza metoda jest prosta i wygodna. Wymaga tylko wprowadzenia wszystkich VNI na wszystkie przełączniki Leaf. Jednak wprowadzenie kilku setek lub tysięcy VNI na wszystkie Leaf nie wydaje się już prostym zadaniem. Dlatego w praktyce rzadko się ją stosuje.
Przyjrzymy się drugiemu sposobowi, który jest bardziej interesujący i nieco bardziej skomplikowany, ale oferuje większą elastyczność w konfiguracji fabryki.
Dodamy do topologii VRF "PROD". Dodamy do niej interface VLAN 10 na parach Leaf-11/12 oraz interface VLAN 20 na Leaf-21. VLAN 20 będzie skojarzony z VNI 20000
vrf context PROD
rd auto ! Route Distinguisher nie jest kluczowy, możemy używać automatycznie utworzonego
address-family ipv4 unicast
route-target both auto ! określamy Route-target, z którym będą importowane i eksportowane prefiksy do/pobocza VRF
vlan 20
vn-segment 20000
interface nve 1
member vni 20000
ingress-replication protocol bgp
interface Vlan10
no shutdown
vrf member PROD
ip address 192.168.20.1/24
fabric forwarding mode anycast-gatewayAby korzystać z L3VNI, należy utworzyć nowy VLAN, skojarzyć go z nowym VNI. Nowy VNI powinien być taki sam na wszystkich Leaf, które są zainteresowane informacjami o VLAN 10 i 20
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! Tworzymy L3 VNI
vrf context PROD
vni 99000 ! Przypisujemy L3 VNI do określonego VRFW rezultacie schemat będzie wyglądać tak:
Pozostało tylko trochę do zrobienia — dodać jeszcze jeden interfejs — interface vlan 99 w VRF PROD
interface Vlan99
no shutdown
vrf member PROD
ip forward ! Na interfejsie nie powinno być IP. Używany jest tylko do przesyłania pakietów między Leaf.Ostatecznie logika przechodzenia ramki od Host-1 do Host-2 jest następująca:
- Ramka wysłana przez Host-1 trafia na Leaf w VLAN 10, który jest powiązany z VNI 10000;
- Leaf sprawdza, gdzie znajduje się adres docelowy, i znajduje go przez L3 VNI na drugim przełączniku Leaf;
- Gdy tylko znajdzie trasę do adresu docelowego, Leaf pakuje ramkę w nagłówek z wymaganym L3VNI 99000 — i wysyła w kierunku drugiego Leaf;
- Drugi przełącznik Leaf otrzymuje dane z L3VNI 99000. Wydobywa oryginalną ramkę i przenosi ją do potrzebnego L2VNI 20000, a następnie do VLAN 20.
W rezultacie taka praca L3VNI eliminuje potrzebę trzymania na wszystkich przełącznikach Leaf informacji o wszystkich VNI w sieci.
Ostatecznie, gdy wysyłamy ruch z Host-1 do Host-2, pakiet jest opakowywany w VxLAN z nowym VNI — 99000:
Musimy zrozumieć, jak dokładnie Leaf-1 dowiaduje się o adresie MAC z innego VNI. Dzieje się to również za pomocą EVPN route-type 2 (MAC/IP).
Poniżej przedstawiono proces rozpowszechniania trasy dotyczącej prefiksu znajdującego się w innym VNI:
To znaczy, że adresy uzyskane z VNI 20000 mają dwa RT.
Przypominam, że trasy uzyskane z Update trafiają do tabeli BGP z Route-target wskazanym w ustawieniach VRF (proces jest nieco bardziej skomplikowany, jednak w ramach tego artykułu nie będziemy się w to zagłębiać).
Sam RT jest formowany według wzoru: AS:VNI (jeśli używany jest tryb automatyczny).
Przykład formowania RT w trybie automatycznym i ręcznym:
vrf context PROD
address-family ipv4 unicast
route-target import auto - tryb automatyczny
route-target export 65001:20000 - ręczny tryb formowania RTW wyniku powyższego widać, że prefiksy z innego VNI mają dwie wartości RT.
Jedna z nich to 65001:99000 — dodatkowy L3 VNI. Ponieważ ten VNI jest taki sam na wszystkich Leaf i podlega naszym zasadom importu w ustawieniach VRF — prefiks trafia do tabeli BGP, co można zobaczyć z wyjścia:
sh bgp l2vpn evpn
Sieć Następny skok Metryka LocPrf Waga Ścieżka
Numer rozdzielający: 10.255.1.11:32777 (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]\/216
10.255.1.10 100 32768 i
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[32]:[192.168.10.10]\/272
10.255.1.10 100 32768 i
*>l[3]:[0]:[32]:[10.255.1.10]\/88
10.255.1.10 100 32768 i
Numer rozdzielający: 10.255.1.21:32787
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]\/272 ! Prefiks uzyskany z VNI 20000
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iPrzy bliższym przyjrzeniu się uzyskanemu aktualizacji, widać, że ten prefiks ma dwa RT:
Leaf11# sh bgp l2vpn evpn 5001.0008.0007
Informacje o tabeli routingu BGP dla VRF default, rodzaj adresu L2VPN EVPN
Numer rozdzielający: 10.255.1.21:32787
Wpis w tabeli routingu BGP dla [2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]\/272, wersja 5164
Ścieżki: (2 dostępne, najlepsza #2)
Flagi: (0x000202) (high32 00000000) na liście xmit, nie jest w l2rib/evpn, nie jest w HW
Typ ścieżki: wewnętrzny, ścieżka jest ważna, nie najlepsza przyczyna: Adres sąsiada, brak oznakowanego next hop
Ścieżka AS: BRAK, ścieżka pochodzi od wewnątrz AS
10.255.1.20 (metryka 81) z 10.255.1.102 (10.255.1.102)
Początek IGP, MED nie ustawiony, localpref 100, waga 0
Otrzymany label 20000 99000 ! Dwa label do pracy VxLAN
Extcommunity: RT:65001:20000 RT:65001:99000 SOO:10.255.1.20:0 ENCAP:8 ! Dwa wartości Route-target, na podstawie których dodano ten prefiks
Router MAC:5001.0005.0007
Autor: 10.255.1.21 Lista klastrów: 10.255.1.102W tabeli routingu na Leaf-1 również można zauważyć prefiks 192.168.20.20\/32:
Leaf11# sh ip route vrf PROD
192.168.10.0\/24, ubest\/mbest: 1\/0, podłączone
* przez 192.168.10.1, Vlan10, [0\/0], 01:29:28, bezpośrednie
192.168.10.1\/32, ubest\/mbest: 1\/0, podłączone
* przez 192.168.10.1, Vlan10, [0\/0], 01:29:28, lokalne
192.168.10.10\/32, ubest\/mbest: 1\/0, podłączone
* przez 192.168.10.10, Vlan10, [190\/0], 01:27:22, hmm
192.168.20.20\/32, ubest\/mbest: 1\/0 ! Adres Host-2
* przez 10.255.1.20fault, [200\/0], 01:20:20, bgp-65001, wewnętrzny, tag 65001 ! Dostępny przez Leaf-2
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! Przez VNI 99000Zauważyliśmy brak głównego prefiksu 192.168.20.0\/24 w tabeli routingu?
Dokładnie, go tam nie ma. To znaczy, że zdalne Leafy otrzymują informacje tylko o hostach, które znajdują się w twojej sieci. I to jest poprawne zachowanie. Wyżej we wszystkich aktualizacjach widać, że przychodzi informacja zawierająca MAC/IP. Nie ma mowy o jakichkolwiek prefiksach.
To działa protokół Host Mobility Manager (HMM), który wypełnia tabelę ARP, z której następnie wypełniana jest tabela BGP (w ramach tego artykułu pominiemy ten proces). Na podstawie informacji uzyskanych z HMM formowane są EVPN route-type 2 (przechodzi MAC/IP).
Jednak co zrobić, jeśli istnieje potrzeba przekazania informacji o jakimś prefiksie?
Dla tego typu informacji istnieje EVPN route-type 5 — umożliwia on przesyłanie prefiksów przez address-family l2vpn evpn (ten typ tras w momencie pisania artykułu znajduje się tylko w wersji roboczej) , z tego powodu zachowanie tego typu trasy może się różnić w zależności od producenta)
Aby przesłać prefiksy, należy w trakcie BGP dla VRF dodać prefiksy, które będą ogłaszane:
router bgp 65001
vrf PROD
address-family ipv4 unicast
redistribute direct route-map VNI20000 ! W tym przypadku ogłaszamy prefiksy podłączenia bezpośredniego do Leaf w VNI 20000
route-map VNI20000 permit 10
match ip address prefix-list VNI20000_OUT ! Określamy, którego prefix-list użyć
ip prefix-list VNI20000_OUT seq 5 permit 192.168.20.0/24 ! Określamy, które sieci trafią do EVPN route-type 5Ostatecznie w aktualizacji będzie:
Zobaczmy tabelę BGP. Oprócz EVPN route-type 2, 3 pojawiły się trasy typu 5, które zawierają informacje o numerze sieci:
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:3
* i[5]:[0]:[0]:[24]:[192.168.10.0]/224
10.255.1.10 0 100 0 ?
*>i 10.255.1.10 0 100 0 ?
Route Distinguisher: 10.255.1.11:32777
* i[2]:[0]:[0]:[48]:[5001.0007.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.0007.0007]:[32]:[192.168.10.10]/272
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
* i[3]:[0]:[32]:[10.255.1.10]/88
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
Route Distinguisher: 10.255.1.12:3
*>i[5]:[0]:[0]:[24]:[192.168.10.0]/224 ! EVPN route-type 5 z numerem prefiksu
10.255.1.10 0 100 0 ?
* i W tabeli routingu prefiks również się pojawił:
Leaf21# sh ip ro vrf PROD
192.168.10.0/24, ubest/mbest: 1/0
*via 10.255.1.10fault, [200/0], 00:14:32, bgp-65001, internal, tag 65001 ! Zdalny prefiks, dostępny przez Leaf1/2 (adres Next-hop = wirtualny IP między parą VPC)
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN ! Prefiks dostępny przez L3VNI 99000
192.168.10.10/32, ubest/mbest: 1/0
*via 10.255.1.10fault, [200/0], 02:33:40, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN
192.168.20.0/24, ubest/mbest: 1/0, attached
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, direct
192.168.20.1/32, ubest/mbest: 1/0, attached
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, local
192.168.20.20/32, ubest/mbest: 1/0, attached
*via 192.168.20.20, Vlan20, [190/0], 02:35:46, hmmNa tym zakończymy drugą część cyklu artykułów o VxLAN EVPN. W następnej części omówimy różne metody routingu między VRF.
Źródło: habr.com
