Ahoj, Habr. V současné době jsem vedoucí kurzu "Síťový inženýr" na OTUS.
V předvečer zahájení nového zápisu do kurzu , připravil jsem cyklus článků o technologii VxLAN EVPN.
Existuje obrovské množství materiálů o práci s VxLAN EVPN, takže chci shromáždit různé úkoly a praktiky řešení problémů v moderním datovém centru.
V první části cyklu o technologii VxLAN EVPN chci prozkoumat způsob organizace L2 konektivity mezi hostiteli nad síťovou infrastrukturou.
Všechny příklady budeme provádět na Cisco Nexus 9000v, uspořádaných do topologie Spine-Leaf. Na nastavení Underlay sítě se v rámci tohoto článku nezaměříme.
- Underlay síť
- BGP párování pro address-family l2vpn evpn
- Nastavení NVE
- Supress-arp
Underlay síť
Používaná topologie vypadá takto:
Nastavíme adresaci na všech zařízeních:
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.20Ověříme, že existuje IP konektivita mezi všemi zařízeními:
Leaf21# sh ip route
10.255.1.11/32, ubest/mbest: 2/0 ! Leaf-11 je dostupný přes dva 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 je dostupný přes dva 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, intraOvěříme, že VPC doména byla vytvořena a oba switche prošly kontrolou konzistence a nastavení na obou uzlech jsou shodná:
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 párování
Nakonec se můžeme přejít k nastavení Overlay sítě.
V rámci článku je třeba organizovat síť mezi hostiteli, jak je znázorněno na schématu níže:
Pro konfiguraci Overlay sítě je nutné na Spine a Leaf přepínačích povolit BGP s podporou rodiny l2vpn evpn:
feature bgp
nv overlay evpnDále je třeba nastavit BGP peerování mezi Leaf a Spine. Pro zjednodušení konfigurace a optimalizaci šíření informací o směrování konfiguruje Spine jako Route-Reflector server. Všechny Leaf přidáme do konfigurace pomocí šablon, abychom optimalizovali nastavení.
Takto vypadá konfigurace na 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 LEAFKonfigurace na Leaf přepínači vypadá obdobně:
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 zkontrolujeme peerování se všemi Leaf přepínači:
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 vidíme, s BGP nevznikly žádné problémy. Přecházíme k nastavení VxLAN. Další nastavení bude prováděno pouze na straně Leaf přepínačů. Spine působí pouze jako jádro sítě a zabývá se pouze přenosem provozu. Celá práce na inkapsulaci a určování cesty probíhá pouze na Leaf přepínačích.
Nastavení NVE
NVE — síťové virtuální rozhraní
Před zahájením nastavení si představíme několik termínů:
VTEP — Virtuální tunelový koncový bod, zařízení, na kterém začíná nebo končí VxLAN tunel. VTEP nemusí nutně být nějaké síťové zařízení. Může to být také server s podporou technologie VxLAN. V naší topologii jsou všechny Leaf přepínače VTEP.
VNI — Virtuální síťový index — identifikátor sítě v rámci VxLAN. Je možné provést analogii s VLAN. Existují však některé rozdíly. Při použití fabriky jsou VLAN unikátní pouze v rámci jednoho Leaf přepínače a nepřenášejí se po síti. Avšak každému VLAN může být přiřazen číslo VNI, které se již přenáší po síti. Jak to vypadá a jak to lze použít, bude podrobněji vysvětleno dále.
Povolíme funkci pro práci technologie VxLAN a možnost přiřazuje čísla VLAN k číslu VNI:
feature nv overlay
feature vn-segment-vlan-basedNastavíme rozhraní NVE, které je zodpovědné za provoz VxLAN. Toto rozhraní právě zajišťuje enkapsulaci rámců do VxLAN hlaviček. Lze provést analogii s rozhraním Tunnel pro provoz GRE:
interface nve1
no shutdown
host-reachability protocol bgp ! používáme BGP pro přenos směrovacích informací
source-interface loopback0 ! rozhraní, z kterého posíláme pakety loopback0Na spínači Leaf-21 se všechno vytváří bez problémů. Pokud však zkontrolujeme výstup příkazu show nve peers, bude prázdný. Je třeba se vrátit k nastavení VPC. Vidíme, že Leaf-11 a Leaf-12 fungují v páru a jsou spojeny VPC doménou. Zde vzniká následující situace:
Host-2 posílá jeden rámec směrem k Leaf-21, aby ho doručil po síti směrem k Host-1. Leaf-21 však vidí, že MAC adresa Host-1 je dostupná ihned přes dvě VTEP. Jak se v tomto případě má Leaf-21 zachovat? To přece znamená, že v síti se mohla objevit smyčka.
Abychom tuto situaci vyřešili, potřebujeme, aby Leaf-11 a Leaf-12 v rámci továrny také vystupovaly jako jedno zařízení. To se řeší poměrně jednoduše. Na rozhraní Loopback, z kterého budujeme tunel, přidáme sekundární adresu. Sekundární adresa by měla být stejná na obou VTEP.
interface loopback0
ip add 10.255.1.10/32 secondaryTímto pohledem z hlediska ostatních VTEP získáváme následující topologii:
Takže nyní bude tunel postaven mezi IP adresou Leaf-21 a virtuální IP mezi dvěma Leaf-11 a Leaf-12. Nyní nebudou vznikat problémy s získáváním MAC adresy od dvou zařízení a provoz může přecházet z jednoho VTEP na druhý. Kdo konkrétně z těchto dvou VTEP zaregistruje provoz, se řeší pomocí směrovací tabulky 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 je vidět výše, adresa 10.255.1.10 je dostupná ihned přes dva Next-hop.
V této fázi jsme si vyjasnili základní propojení. Přejděme k nastavení rozhraní NVE:
Ihned aktivujeme VLAN 10 a asociujeme ji s VNI 10000 na každém Leaf pro hosty. Nastavíme L2 tunel mezi hosty.
vlan 10 ! Aktivujeme VLAN na všech VTEP připojených k potřebným hostitelům
vn-segment 10000 ! Asociujeme VLAN s číslem VNI
interface nve1
member vni 10000 ! Přidáváme VNI 10000 pro práci přes rozhraní NVE, pro enkapsulaci v VxLAN
ingress-replication protocol bgp ! Určujeme, že pro distribuci informací o hostiteli používáme BGPNyní zkontrolujeme nve peers a tabulku pro 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 ! Vidíme, že peer je dostupný se sekundární adresy
Leaf11# sh bgp l2vpn evpn
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000) ! Od koho konkrétně přišel tento l2VNI
*>l[3]:[0]:[32]:[10.255.1.10]\/88 ! EVPN route-type 3 - ukazuje našeho souseda, který také zná 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 iNad námi vidíme trasy pouze EVPN route-type 3. Tento typ tras hovoří o peer (Leaf), ale kde jsou naše hosty?
Záležitost je v tom, že informace o MAC adresách hostitelů se přenášejí přes EVPN route-type 2
Abychom viděli naše hosty, je třeba nastavit EVPN route-type 2:
evpn
vni 10000 l2
route-target import auto ! V rámci tohoto článku používáme automatické číslo pro route-target
route-target export autoProvedeme ping z Host-2 na 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 msA níže vidíme, že v tabulce BGP se objevily route-type 2 s MAC adresami hostitelů — 5001.0007.0007 a 5001.0008.0007
Leaf11# sh bgp l2vpn evpn
Síť Další skok Metrika LocPrf Váha Cesta
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 a mac adresa hosta 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 a mac adresa 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
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 iDále se můžeme podívat na podrobnosti aktualizace, ve které jsme dostali informace o MAC Host. Níže je uvedený neúplný výstup příkazu
Leaf21# sh bgp l2vpn evpn 5001.0007.0007
Informace o směrovací tabulce BGP pro VRF default, rodina adres L2VPN EVPN
Route Distinguisher: 10.255.1.11:32777 ! odeslat aktualizaci s MAC Host. Ne virtuální adresa VPC, ale adresa Leaf
Záznam směrovací tabulky BGP pro [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]\/216,
verze 1507
Cesty: (2 k dispozici, nejlepší #2)
Příznaky: (0x000202) (high32 00000000) na xmit-list, není v l2rib\/evpn, není v HW
Typ cesty: interní, cesta je platná, není nejlepší důvod: Adresa souseda, žádný označený následující skok
AS-Cesta: ŽÁDNÁ, cesta pochází interně do AS
10.255.1.10 (metrika 81) z 10.255.1.102 (10.255.1.102) ! s kým konkrétně vytváříme VxLAN tunel
Původ IGP, MED není nastaven, localpref 100, váha 0
Přijatý štítek 10000 ! Číslo VNI, které je asociováno s VLAN, ve které se nachází Host
Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8 ! Zde vidíme, že RT byl automaticky vytvořen na základě čísel AS a VNI
Originátor: 10.255.1.11 Seznam clusterů: 10.255.1.102Podívejme se, jak vypadají rámce, když procházejí fabrikou:
Suppress-ARP
Skvěle, máme L2 spojení mezi hosty a na tom bychom mohli skončit. Nicméně, vše není tak jednoduché. Dokud máme málo hostů, problémy nevzniknou. Ale představme si situaci, kdy máme stovky a tisíce hostů. S jakým problémem se můžeme setkat?
Tento problém — BUM (Broadcast, Unknown Unicast, Multicast) provoz. V rámci tohoto článku se podíváme na možnosti, jak bojovat s broadcast provozem.
Hlavním generátorem Broadcast v Ethernet sítích jsou samotní hosté prostřednictvím protokolu ARP.
Na nexus je realizován následující mechanismus pro boj s ARP požadavky — suppress-arp.
Funkce této funkce vypadá následovně:
- Host-1 posílá ARP dotaz na Broadcast adresu své sítě.
- Dotaz dorazí k Leaf přepínači a místo toho, aby tento dotaz předal dále ve fabrice směrem k Host-2 — Leaf odpovídá sám a uvádí potřebný IP a MAC.
Tímto způsobem Broadcast dotaz neodešel do fabricu. Jak to však může fungovat, pokud Leaf zná pouze MAC adresu?
Vše je docela jednoduché, EVPN route-type 2 kromě MAC adresy může předávat i combo MAC/IP. K tomu je potřeba na Leaf nastavit IP adresu ve VLAN. Objevuje se otázka, jakou IP adresu zadat? Na Nexus je možnost vytvořit distribuovanou (stejnou) adresu na všech switchích:
feature interface-vlan
fabric forwarding anycast-gateway-mac 0001.0001.0001 ! nastavujeme virtual mac pro vytvoření distribuované brány mezi všemi switcheTímto způsobem bude síť z pohledu hostitelů vypadat následovně:
Zkontrolujeme 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 iZ výstupu příkazu je patrné, že v EVPN route-type 2 kromě MAC nyní vidíme také IP adresu hostitele.
Vracíme se k nastavení suppress-arp. Tato možnost se zapíná pro každý VNI zvlášť:
interface nve1
member vni 10000
suppress-arpDále nastává jistá komplikace:
- Pro fungování této funkce je potřeba místo v TCAM paměti. Uvedu příklad nastavení pro suppress-arp:
hardware access-list tcam region arp-ether 256Pro toto nastavení bude potřeba double-wide. To znamená, že pokud nastavujete 256, musíte v TCAM uvolnit 512. Nastavení TCAM vychází za hranice tohoto článku, protože konkrétní nastavení TCAM závisí pouze na úkolu, který máte před sebou, a může se lišit od jedné sítě k druhé.
- Implementace suppress-arp je nutné provést na všech Leaf přepínačích. Avšak složitosti mohou nastat při konfiguraci na párech Leaf, nacházejících se v doméně VPC. Při změnách TCAM bude narušena konzistence mezi páry a jeden uzel může být vyřazen z provozu. Navíc pro aplikaci nastavení změn TCAM může být zapotřebí restart zařízení.
Výsledkem je, že byste měli pečlivě zvážit, zda v vaší situaci implementovat toto nastavení na funkční továrnu.
Tímto zakončíme první část cyklu. V další části se budeme zabývat směrováním přes VxLAN továrnu s rozdělením sítí podle různých VRF.
A teď zvu všechny na , v rámci kterého podrobně představím kurz. Prvních 20 účastníků, kteří se registrovali na tento webinář, obdrží certifikát na slevu na elektronickou poštu během 1-2 dnů po přenosu.
Zdroj: habr.com
