Cześć, Habrze. Obecnie jestem kierownikiem kursu "Inżynier sieci" w OTUS.
W przededniu nowego naboru na kurs , przygotowałem cykl artykułów o technologii VxLAN EVPN.
Istnieje ogromna ilość materiałów dotyczących pracy z VxLAN EVPN, dlatego chcę zebrać różne zadania oraz praktyki rozwiązywania problemów w nowoczesnym centrum danych.
W pierwszej części cyklu poświęconego technologii VxLAN EVPN pragnę rozważyć sposób organizacji łączności L2 między hostami na sieci fabrycznej.
Wszystkie przykłady będą realizowane na Cisco Nexus 9000v, zbudowanych w topologii Spine-Leaf. Nie będziemy się zatrzymywać na konfiguracji sieci Underlay w ramach tego artykułu.
- Sieć Underlay
- BGP peering dla address-family l2vpn evpn
- Konfiguracja NVE
- Supress-arp
Sieć Underlay
Używana topologia wygląda następująco:
Ustalamy adresację na wszystkich urządzeniach:
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.20Sprawdźmy, czy istnieje łączność IP między wszystkimi urządzeniami:
Leaf21# sh ip route
10.255.1.11/32, ubest/mbest: 2/0 ! Leaf-11 dostępny przez dwa 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 dostępny przez dwa 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, intraSprawdźmy, czy domena VPC została utworzona i oba przełączniki przeszły kontrolę spójności oraz mają identyczną konfigurację na obu węzłach:
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 1BGP peering
Wreszcie możemy przejść do konfiguracji sieci Overlay.
W ramach artykułu należy zorganizować sieć między hostami, jak pokazano na poniższym schemacie:
Aby skonfigurować Overlay sieci, należy włączyć BGP z obsługą rodziny l2vpn evpn na przełącznikach Spine i Leaf:
feature bgp
nv overlay evpnNastępnie należy skonfigurować połączenie BGP między Leaf a Spine. Dla uproszczenia konfiguracji i optymalizacji rozpowszechniania informacji o trasowaniu, Spine skonfigurujemy jako Route-Reflector server. Wszystkie Leaf wpiszemy w konfiguracji przez szablony, aby zoptymalizować ustawienia.
Tak więc konfiguracja na Spine wygląda następująco:
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 LEAFKonfiguracja na przełączniku Leaf wygląda analogicznie:
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 SPINENa Spine sprawdzamy połączenie z wszystkimi przełącznikami 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 0Jak widać, nie było żadnych problemów z BGP. Przejdźmy do konfiguracji VxLAN. Dalsza konfiguracja będzie przeprowadzana tylko po stronie przełączników Leaf. Spine działa tylko jako rdzeń sieci i zajmuje się tylko przesyłaniem ruchu. Cała praca związana z enkapsulacją i ustalaniem trasy odbywa się tylko na przełącznikach Leaf.
Konfiguracja NVE
NVE — interfejs wirtualny sieciowy
Przed rozpoczęciem konfiguracji wprowadzimy kilka terminów:
VTEP — Wirtualny Punkt Końcowy Tunelu, urządzenie, na którym zaczyna się lub kończy tunel VxLAN. VTEP nie musi być urządzeniem sieciowym. Może to być również serwer obsługujący technologię VxLAN. W naszej topologii wszystkie przełączniki Leaf są VTEP.
VNI — Wirtualny Indeks Sieci — identyfikator sieci w ramach VxLAN. Można to porównać z VLAN. Istnieją jednak pewne różnice. Przy użyciu fabryki, VLAN stają się unikalne tylko w ramach jednego przełącznika Leaf i nie są przesyłane w sieci. Ale z każdym VLAN może być powiązany numer VNI, który już jest przesyłany w sieci. Jak to wygląda i jak można to wykorzystać, zostanie omówione dalej.
Włączymy funkcję do pracy z technologią VxLAN oraz możliwość powiązania numerów VLAN z numerem VNI:
feature nv overlay
feature vn-segment-vlan-basedSkonfigurujemy interfejs NVE, który odpowiada za działanie VxLAN. Ten interfejs jest odpowiedzialny za enkapsulację ramek w nagłówki VxLAN. Można go porównać z interfejsem Tunnel używanym do pracy z GRE:
interfejs nve1
no shutdown
protokół dostępności hostów bgp ! używamy BGP do przesyłania informacji o trasach
źródło-interfejs loopback0 ! interfejs, z którego wysyłamy pakiety loopback0Na przełączniku Leaf-21 wszystko tworzy się bez problemów. Jednak jeśli sprawdzimy wynik polecenia show nve peers, to okaże się pusty. Musimy wrócić do konfiguracji VPC. Widzimy, że Leaf-11 i Leaf-12 działają w parze i są połączone domeną VPC. Z tej sytuacji wynika, że:
Host-2 wysyła jedną ramkę w kierunku Leaf-21, aby ten mógł ją przesłać w sieci do Host-1. Jednak Leaf-21 widzi, że adres MAC Host-1 jest dostępny przez dwa VTEP. Jak w tym przypadku powinien postąpić Leaf-21? Oznacza to, że w sieci mogła pojawić się pętla.
Aby rozwiązać tę sytuację, potrzebujemy, aby Leaf-11 i Leaf-12 w ramach fabryki działały również jako jedno urządzenie. Rozwiązuje się to dość prosto. Na interfejsie Loopback, z którego budujemy tunel, dodajemy adres pomocniczy. Adres pomocniczy powinien być identyczny na obu VTEP.
interfejs loopback0
ip add 10.255.1.10/32 secondaryDzięki temu z punktu widzenia innych VTEP otrzymujemy następującą topologię:
Oznacza to, że teraz tunel będzie budowany pomiędzy adresem IP Leaf-21 a wirtualnym adresem IP między dwoma Leaf-11 i Leaf-12. Teraz problemy z poznawaniem adresu MAC z dwóch urządzeń nie będą się pojawiać i ruch może przechodzić z jednego VTEP na drugi. Kto z dwóch VTEP obsłuży ruch, decyduje się przy pomocy tabeli routingu na 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, intraJak widać powyżej, adres 10.255.1.10 jest dostępny przez dwa Next-hop.
Na tym etapie zrozumieliśmy podstawową spójność. Przejdźmy do konfiguracji interfejsu NVE:
Od razu włączymy Vlan 10 i powiążemy go z VNI 10000 na każdym Leaf dla hostów. Skonfigurujemy L2 tunel między hostami.
vlan 10 ! Włączamy VLAN na wszystkich VTEP podłączonych do potrzebnych hostów
vn-segment 10000 ! Powiązujemy VLAN z numerem VNI
interface nve1
member vni 10000 ! Dodajemy VNI 10000 do pracy przez interfejs NVE. do enkapsulacji w VxLAN
ingress-replication protocol bgp ! wskazujemy, że do rozpowszechniania informacji o hoście używamy BGPTeraz sprawdzimy nve peers i tabelę dla 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 ! Widzę, że peer jest dostępny z adresu drugorzędnego
Leaf11# sh bgp l2vpn evpn
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000) ! Od kogo dokładnie przyszedł ten l2VNI
*>l[3]:[0]:[32]:[10.255.1.10]\/88 ! EVPN route-type 3 - pokazuje naszego sąsiada, który także zna o 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 iPowyżej widzę trasy tylko EVPN route-type 3. Ten typ tras informuje o peerze (Leaf), ale gdzie są nasze hosty?
A wszystko sprowadza się do tego, że informacje o MAC hostów są przesyłane przez EVPN route-type 2.
Aby zobaczyć nasze hosty, musimy skonfigurować EVPN route-type 2:
evpn
vni 10000 l2
route-target import auto ! w ramach tego artykułu używamy automatycznego numeru dla route-target
route-target export autoZróbmy ping z Host-2 na Host-1:
Firewall2# ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1): 56 bajtów danych
36 bajtów z 192.168.10.2: Host docelowy niedostępny
Request 0 timed out
64 bajty z 192.168.10.1: icmp_seq=1 ttl=254 time=215.555 ms
64 bajty z 192.168.10.1: icmp_seq=2 ttl=254 time=38.756 ms
64 bajty z 192.168.10.1: icmp_seq=3 ttl=254 time=42.484 ms
64 bajty z 192.168.10.1: icmp_seq=4 ttl=254 time=40.983 msA poniżej możemy zobaczyć, że w tabeli BGP pojawiły się route-type 2 z adresami MAC hostów — 5001.0007.0007 i 5001.0008.0007
Leaf11# sh bgp l2vpn evpn
Sieć Następny skok Metrika LocPrf Waga Ścieżka
Rozróżniacz trasy: 10.255.1.11:32777 (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]\/216 ! typ trasy evpn 2 i adres mac hosta 1
10.255.1.10 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]\/216 ! typ trasy evpn 2 i adres mac hosta 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
Rozróżniacz trasy: 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 iMożesz teraz zapoznać się z szczegółowymi informacjami na temat aktualizacji, w której otrzymaliśmy informację o MAC hoście. Poniżej przedstawiono nie cały output polecenia
Leaf21# sh bgp l2vpn evpn 5001.0007.0007
Informacje o tabeli routingu BGP dla VRF domyślnego, rodzina adresów L2VPN EVPN
Rozróżniacz trasy: 10.255.1.11:32777 ! wysłano aktualizację z MAC hosta. Nie adres wirtualny VPC, a adres Leaf
Wpis w tabeli routingu BGP dla [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]\/216,
wersja 1507
Ścieżki: (2 dostępne, najlepsze #2)
Flagi: (0x000202) (high32 00000000) na liście xmit, nie znajduje się w l2rib\/evpn, nie jest w HW
Typ ścieżki: wewnętrzna, ścieżka jest ważna, nie najlepsza powód: Adres sąsiada, brak etykietowanego nexthopa
AS-Path: BRAK, ścieżka wewnętrzna dla AS
10.255.1.10 (metryka 81) z 10.255.1.102 (10.255.1.102) ! z kim dokładnie budujemy tunel VxLAN
Origin IGP, MED nie ustawione, localpref 100, waga 0
Odebrana etykieta 10000 ! Numer VNI, który jest związany z VLAN, w którym znajduje się host
Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8 ! Tutaj widać, że RT został utworzony automatycznie na podstawie numerów AS i VNI
Originator: 10.255.1.11 Lista klastrów: 10.255.1.102Zobaczmy, jak wyglądają ramki, gdy są przesyłane przez fabrykę:
Suppress-ARP
Doskonałe, mamy połączenie L2 między hostami i na tym moglibyśmy zakończyć. Jednak nie wszystko jest takie proste. Dopóki mamy niewiele hostów, nie wystąpią problemy. Ale wyobraźmy sobie sytuację, w której mamy setki i tysiące hostów. Z jakim problemem możemy się zmierzyć?
Ten problem to ruch BUM (Broadcast, Unknown Unicast, Multicast). W ramach tego artykułu rozważymy sposób przeciwdziałania ruchowi broadcast.
Głównym generatorem broadcast w sieciach Ethernet są same hosty poprzez protokół ARP.
Na nexus wdrożono następujący mechanizm do zwalczania zapytań ARP — suppress-arp.
Działanie tej funkcji wygląda w następujący sposób:
- Host-1 wysyła zapytanie APR na adres broadcast swojej sieci.
- Zapytanie dociera do przełącznika Leaf i zamiast przesłać to zapytanie dalej do fabryki w kierunku Host-2 — Leaf odpowiada samodzielnie i podaje odpowiedni adres IP i MAC.
W ten sposób zapytanie Broadcast nie dotarło do fabryki. Ale jak to może działać, skoro Leaf zna tylko adres MAC?
Wszystko jest dość proste, typ trasy EVPN 2 oprócz adresu MAC może przesyłać parę MAC/IP. W tym celu na Leaf należy skonfigurować adres IP w VLAN. Pojawia się pytanie, jaki adres IP ustawić? Na nexusie można stworzyć rozproszony (identyczny) adres na wszystkich przełącznikach:
feature interface-vlan
fabric forwarding anycast-gateway-mac 0001.0001.0001 ! ustawiamy adres MAC wirtualny do utworzenia rozproszonej bramy między wszystkimi przełącznikami
interface Vlan10
no shutdown
ip address 192.168.10.254/24 ! na wszystkich Leaf ustawiamy ten sam adres IP
fabric forwarding mode anycast-gateway ! mówimy, aby używać MAC wirtualnegoW ten sposób z punktu widzenia hostów sieć będzie wyglądać następująco:
Sprawdźmy BGP l2route evpn
Leaf11# sh bgp l2vpn evpn
Sieć Następny skok Metrika LocPrf Waga Ścieżka
Rozróżniacz trasy: 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
Rozróżniacz trasy: 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 iZ wyniku polecenia widać, że w EVPN route-type 2 oprócz MAC widzimy teraz także adres IP hosta.
Wracamy do konfiguracji suppress-arp. Ta opcja jest włączana dla każdego VNI osobno:
interface nve1
member vni 10000
suppress-arpNastępnie pojawia się pewna trudność:
- Aby ta funkcja działała, potrzebna jest przestrzeń w pamięci TCAM. Podam przykład konfiguracji dla suppress-arp:
hardware access-list tcam region arp-ether 256Do tej konfiguracji wymagany będzie podwójny szerokości. To znaczy, jeśli ustawisz 256, to w TCAM należy zwolnić 512. Konfiguracja TCAM wykracza poza zakres tego artykułu, ponieważ zależy jedynie od zadania, które przed Tobą stoi i może się różnić od jednej sieci do drugiej.
- Wdrożenie suppress-arp należy przeprowadzić na wszystkich przełącznikach Leaf. Jednakże mogą wystąpić trudności przy konfiguracji w parach Leaf znajdujących się w domenie VPC. Przy zmianie TCAM spójność między parami zostanie naruszona, a jeden z węzłów może przestać działać. Dodatkowo, aby zastosować ustawienia zmiany TCAM, może być konieczne uruchomienie urządzenia ponownie.
W rezultacie warto dokładnie rozważyć, czy w Twojej sytuacji wdrożenie tej konfiguracji w działającym centrum danych jest zasadne.
Na tym zakończymy pierwszą część cyklu. W następnej części omówimy routowanie przez fabrykę VxLAN z podziałem sieci na różne VRF.
A teraz zapraszam wszystkich na , podczas którego szczegółowo opowiem o kursie. Pierwsze 20 uczestników, którzy zarejestrują się na ten webinar, otrzyma certyfikat na zniżkę na e-mail w ciągu 1-2 dni po transmisji.
Źródło: habr.com
