Witaj, hab. Obecnie jestem kierownikiem kursu Network Engineer w firmie OTUS.
W oczekiwaniu na rozpoczęcie nowych zapisów na kurs , przygotowałem cykl artykułów na temat technologii VxLAN EVPN.
Materiału na temat działania VxLAN EVPN jest bardzo dużo, dlatego chcę zebrać różne zadania i praktyki rozwiązywania problemów w nowoczesnym centrum danych.
W pierwszej części serii poświęconej technologii VxLAN EVPN chcę przyjrzeć się sposobom zorganizowania łączności L2 między hostami na szczycie sieci szkieletowej.
Wszystkie przykłady zostaną wykonane na Cisco Nexus 9000v, zmontowanym w topologii Spine-Leaf. W tym artykule nie będziemy rozwodzić się nad konfiguracją sieci Underlay.
- Sieć podkładowa
- BGP peering dla rodziny adresów l2vpn evpn
- Konfigurowanie NVE
- Pomiń-arp
Sieć podkładowa
Stosowana topologia jest następująca:
Ustawmy adresowanie 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 pomiędzy wszystkimi urządzeniami istnieje łączność 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, intraSprawdźmy, czy domena VPC została utworzona i oba przełączniki przeszły kontrolę spójności, a ustawienia na obu węzłach są identyczne:
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 1Peering BGP
Na koniec możesz przejść do konfiguracji sieci Overlay.
W ramach artykułu konieczne jest zorganizowanie sieci między hostami, jak pokazano na poniższym schemacie:
Aby skonfigurować sieć Overlay, musisz włączyć BGP na przełącznikach Spine i Leaf z obsługą rodziny l2vpn evpn:
feature bgp
nv overlay evpnNastępnie musisz skonfigurować peering BGP pomiędzy Leaf i Spine. Aby uprościć konfigurację i zoptymalizować dystrybucję informacji o routingu, konfigurujemy Spine jako serwer Route-Reflector. Napiszemy cały liść w konfiguracji przy użyciu szablonów, aby zoptymalizować konfigurację.
Zatem ustawienia Spine wyglądają 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 przełącznika Leaf wygląda podobnie:
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 SPINEW Spine sprawdźmy peering ze 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ć, z BGP nie było problemów. Przejdźmy do konfiguracji VxLAN. Dalsza konfiguracja zostanie przeprowadzona tylko po stronie liścia przełączników. Spine pełni jedynie rolę rdzenia sieci i zajmuje się jedynie przesyłaniem ruchu. Wszystkie prace związane z hermetyzacją i określaniem ścieżki są wykonywane tylko na przełącznikach typu Leaf.
Konfigurowanie NVE
NVE - wirtualny interfejs sieciowy
Przed rozpoczęciem konfiguracji wprowadźmy trochę terminologii:
VTEP – Vitual Tunnel End Point, urządzenie, na którym zaczyna się lub kończy tunel VxLAN. VTEP nie musi być koniecznie dowolnym urządzeniem sieciowym. Serwer obsługujący technologię VxLAN może również pełnić funkcję serwera. W naszej topologii wszystkie przełączniki liściowe są wyposażone w technologię VTEP.
VNI - Virtual Network Index - identyfikator sieci w obrębie VxLAN. Można wyciągnąć analogię z siecią VLAN. Istnieją jednak pewne różnice. W przypadku korzystania z sieci szkieletowej sieci VLAN stają się unikalne tylko w obrębie jednego przełącznika Leaf i nie są przesyłane przez sieć. Jednak z każdą siecią VLAN może być powiązany numer VNI, który jest już przesyłany w sieci. Jak to wygląda i jak można go wykorzystać, zostanie omówione dalej.
Włączmy funkcję obsługi technologii VxLAN i możliwość powiązania numerów VLAN z numerem VNI:
feature nv overlay
feature vn-segment-vlan-basedSkonfigurujmy interfejs NVE, który odpowiada za działanie VxLAN. Interfejs ten odpowiada za enkapsulację ramek w nagłówkach VxLAN. Można narysować analogię z interfejsem Tunnel dla GRE:
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0Na przełączniku Leaf-21 wszystko tworzy się bez problemów. Jeśli jednak sprawdzimy dane wyjściowe polecenia show nve peers, wtedy będzie pusty. Tutaj musisz wrócić do konfiguracji VPC. Widzimy, że Leaf-11 i Leaf-12 działają w parach i łączy je domena VPC. Daje nam to następującą sytuację:
Host-2 wysyła jedną ramkę do Leaf-21, aby przesłać ją przez sieć do Host-1. Jednak Leaf-21 widzi, że adres MAC Hosta-1 jest dostępny za pośrednictwem dwóch VTEP jednocześnie. Co w tej sytuacji powinien zrobić Liść-21? Wszak oznacza to, że w sieci może pojawić się pętla.
Aby rozwiązać tę sytuację, potrzebujemy, aby Leaf-11 i Leaf-12 działały również jako jedno urządzenie w fabryce. Rozwiązanie jest dość proste. Na interfejsie Loopback z którego budujemy tunel dodaj adres wtórny. Adres dodatkowy musi być taki sam w obu VTEP.
interface loopback0
ip add 10.255.1.10/32 secondaryZatem z punktu widzenia innych VTEP otrzymujemy następującą topologię:
Oznacza to, że teraz tunel zostanie zbudowany pomiędzy adresem IP Leaf-21 a wirtualnym adresem IP pomiędzy dwoma Leaf-11 i Leaf-12. Teraz nie będzie już problemów z nauczeniem się adresu MAC z dwóch urządzeń, a ruch będzie mógł być przenoszony z jednego VTEP na drugi. O tym, który z dwóch VTEP będzie przetwarzał ruch, decyduje tablica routingu w 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 od razu poprzez dwa Next-hopy.
Na tym etapie zajęliśmy się podstawową łącznością. Przejdźmy do konfiguracji interfejsu NVE:
Natychmiast włączmy Vlan 10 i powiążmy go z VNI 10000 na każdym liściu dla hostów. Skonfigurujmy tunel L2 pomiędzy hostami
vlan 10 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
vn-segment 10000 ! Ассоциируем VLAN с номер VNI
interface nve1
member vni 10000 ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
ingress-replication protocol bgp ! указываем, что для распространения информации о хосте используем BGPSprawdźmy teraz nve peerów 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 ! Видим что 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 iPowyżej widzimy tylko trasy EVPN typu 3. Ten typ trasy mówi o równorzędnej trasie (Leaf), ale gdzie są nasi gospodarze?
Rzecz w tym, że informacje o hostach MAC przesyłane są za pośrednictwem trasy EVPN typu 2
Aby zobaczyć naszych gospodarzy, musisz skonfigurować trasę EVPN typu 2:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoPingujmy z Hosta-2 do Hosta-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 msPoniżej widzimy, że w tabeli BGP pojawiła się trasa typu 2 z adresem MAC hosta - 5001.0007.0007 i 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 iNastępnie możesz zobaczyć szczegółowe informacje na temat Aktualizacji, w której otrzymałeś informacje o hoście MAC. Poniżej nie znajdują się wszystkie dane wyjściowe polecenia.
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
<........>Zobaczmy jak wyglądają ramy po przejściu przez fabrykę:
Pomiń-ARP
Świetnie, mamy teraz komunikację L2 pomiędzy hostami i na tym moglibyśmy zakończyć. Jednak nie wszystko jest takie proste. Dopóki mamy niewielu hostów, nie będzie żadnych problemów. Ale wyobraźmy sobie sytuację, w której mamy setki i tysiące hostów. Z jakim problemem możemy się spotkać?
Ten problem dotyczy ruchu BUM (rozgłaszanie, nieznany odbiór pojedynczy, multicast). W tym artykule rozważymy opcję radzenia sobie z ruchem rozgłoszeniowym.
Głównym generatorem rozgłaszania w sieciach Ethernet są same hosty za pośrednictwem protokołu ARP.
Nexus implementuje następujący mechanizm do zwalczania żądań ARP - supres-arp.
Ta funkcja działa w następujący sposób:
- Host-1 wysyła żądanie APR na adres rozgłoszeniowy swojej sieci.
- Żądanie dociera do przełącznika Leaf i zamiast przekazywać je dalej do sieci szkieletowej w kierunku Host-2, Leaf odpowiada sam i wskazuje wymagane adresy IP i MAC.
Dlatego żądanie transmisji nie trafiło do fabryki. Ale jak to może działać, jeśli Leaf zna tylko adres MAC?
Wszystko jest dość proste, trasa EVPN typu 2 oprócz adresu MAC może przesyłać kombinację MAC/IP. Aby to zrobić, musisz skonfigurować adres IP w sieci VLAN na Leafie. Powstaje pytanie jakie IP ustawić? Na nexusie możliwe jest utworzenie rozproszonego (tego samego) adresu na wszystkich przełącznikach:
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 macZatem z punktu widzenia hostów sieć będzie wyglądać następująco:
Sprawdźmy 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
<......>Z wyniku polecenia widać, że w przypadku trasy EVPN typu 2 oprócz adresu MAC widzimy teraz także adres IP hosta.
Wróćmy do ustawiania tłumienia-arp. To ustawienie jest włączone dla każdego VNI osobno:
interface nve1
member vni 10000
suppress-arpWtedy pojawia się pewna złożoność:
- Aby ta funkcja działała, wymagane jest miejsce w pamięci TCAM. Oto przykład ustawień tłumienia-arp:
hardware access-list tcam region arp-ether 256To ustawienie będzie wymagało podwójnej szerokości. Oznacza to, że jeśli ustawisz 256, musisz zwolnić w TCAM 512. Konfigurowanie TCAM wykracza poza zakres tego artykułu, ponieważ konfiguracja TCAM zależy tylko od przypisanego Ci zadania i może różnić się w zależności od sieci.
- Implementację tłumienia arp należy wykonać na wszystkich przełącznikach typu Leaf. Jednak podczas konfiguracji par liści znajdujących się w domenie VPC może pojawić się złożoność. Jeśli TCAM zostanie zmieniony, spójność między parami zostanie zerwana, a jeden węzeł może zostać wyłączony z eksploatacji. Ponadto w celu zastosowania ustawienia zmiany TCAM może być wymagane ponowne uruchomienie urządzenia.
W rezultacie musisz dokładnie rozważyć, czy w Twojej sytuacji warto wdrożyć to ustawienie w działającej fabryce.
Na tym kończy się pierwsza część serii. W następnej części przyjrzymy się routingowi w strukturze VxLAN z podziałem sieci na różne VRF.
A teraz zapraszam wszystkich , w ramach którego szczegółowo opowiem Ci o kursie. Pierwszych 20 uczestników, którzy zarejestrują się na to webinarium, otrzyma certyfikat rabatowy pocztą elektroniczną w ciągu 1-2 dni po transmisji.
Źródło: www.habr.com