Ahoj habr. V současné době jsem vedoucím kurzu pro „Network Engineer“ ve společnosti OTUS.
V očekávání zahájení nového zápisu do kurzu , připravil jsem sérii článků o technologii VxLAN EVPN.
Materiálů o fungování VxLAN EVPN je obrovské množství, proto chci shromáždit různé úkoly a postupy pro řešení problémů v moderním datovém centru.
V první části technologického cyklu VxLAN EVPN chci zvážit způsob, jak organizovat L2 konektivitu mezi hostiteli na vrcholu síťové továrny.
Všechny příklady budou provedeny na Cisco Nexus 9000v sestaveném v topologii Spine-Leaf. V tomto článku se nebudeme zdržovat nastavením sítě Underlay.
- podkladová síť
- Peering BGP pro rodinu adres l2vpn evpn
- Nastavení NVE
- Potlačit-arp
podkladová síť
Použitá topologie je následující:
Nastavíme adresování 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.20Pojďme zkontrolovat, zda je mezi všemi zařízeními IP konektivita:
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, intraZkontrolujeme, že doména VPC byla vytvořena a oba přepínače prošly kontrolou konzistence a nastavení na obou uzlech je totožné:
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
Nakonec můžeme přejít ke konfiguraci sítě Overlay.
V rámci článku je nutné zorganizovat síť mezi hostiteli, jak je znázorněno na obrázku níže:
Chcete-li nakonfigurovat překryvnou síť, musíte povolit BGP na přepínačích Spine a Leaf s podporou pro rodinu l2vpn evpn:
feature bgp
nv overlay evpnDále musíte nakonfigurovat peering BGP mezi Leaf a Spine. Pro zjednodušení konfigurace a optimalizaci distribuce směrovacích informací nakonfigurujeme Spine jako Route-Reflector server. Všechny Leaf zapíšeme do konfigurace přes šablony, abychom optimalizovali nastavení.
Takže nastavení na Spine vypadá takto:
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 LEAFNastavení přepínače Leaf vypadá podobně:
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 zkontrolujte peering se všemi přepínači 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 vidíte, s BGP nebyly žádné problémy. Pojďme k nastavení VxLAN. Další konfigurace bude provedena pouze na straně přepínačů Leaf. Spine funguje pouze jako jádro sítě a podílí se pouze na přenosu provozu. Veškerá práce na zapouzdření a definici cesty probíhá pouze na přepínačích Leaf.
Nastavení NVE
NVE - síťové virtuální rozhraní
Před zahájením nastavení si uvedeme nějakou terminologii:
VTEP - Vitual Tunnel End Point, zařízení, na kterém začíná nebo končí tunel VxLAN. VTEP není nutně žádné síťové zařízení. Může také fungovat server podporující technologii VxLAN. V naší topologii jsou všechny Leaf přepínače VTEP.
VNI - Virtual Network Index - identifikátor sítě v rámci VxLAN. Můžete nakreslit analogii s VLAN. Existují však určité rozdíly. Při použití struktury se VLAN stávají jedinečnými pouze v rámci jednoho přepínače Leaf a nejsou přenášeny po síti. Každá VLAN však může být spojena s číslem VNI, které je již přenášeno sítí. Jak to vypadá a jak to může být použito, bude probráno níže.
Aktivujte funkci pro technologii VxLAN a možnost přidružit čísla VLAN k číslu VNI:
feature nv overlay
feature vn-segment-vlan-basedPojďme nakonfigurovat rozhraní NVE, které je zodpovědné za provoz VxLAN. Toto rozhraní je zodpovědné za zapouzdření rámců v hlavičkách VxLAN. Můžete nakreslit analogii s rozhraním Tunnel pro GRE:
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0Na přepínači Leaf-21 je vše vytvořeno bez problémů. Pokud však zkontrolujeme výstup příkazu show nve peers, pak bude prázdný. Zde se musíte vrátit do nastavení VPC. Vidíme, že Leaf-11 a Leaf-12 jsou spárovány a spojeny doménou VPC. To má za následek následující situaci:
Host-2 odešle jeden rámec do Leaf-21, aby byl přenesen po síti do hostitele-1. Leaf-21 však vidí, že MAC adresa hostitele-1 je dostupná prostřednictvím dvou VTEP najednou. Co by měl Leaf-21 v tomto případě udělat? To koneckonců znamená, že by se v síti mohla objevit smyčka.
Abychom tuto situaci vyřešili, potřebujeme, aby Leaf-11 a Leaf-12 také fungovaly jako jedno zařízení v továrně. Řeší se to celkem jednoduše. Na rozhraní Loopback, ze kterého tunel stavíme, přidejte sekundární adresu. Sekundární adresa musí být na obou VTEP stejná.
interface loopback0
ip add 10.255.1.10/32 secondaryZ pohledu ostatních VTEP tedy dostáváme následující topologii:
To znamená, že nyní bude tunel vybudován mezi IP adresou Leaf-21 a virtuální IP mezi dvěma Leaf-11 a Leaf-12. Nyní nebudou žádné problémy s učením MAC adresy ze dvou zařízení a provoz lze přenášet z jednoho VTEP na druhý. O tom, který ze dvou VTEP bude provoz zpracovávat, se rozhoduje 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 můžete vidět výše, adresa 10.255.1.10 je dostupná okamžitě prostřednictvím dvou Next-hopů.
V této fázi jsme přišli na základní konektivitu. Pojďme k nastavení rozhraní NVE:
Okamžitě povolíme Vlan 10 a spojíme jej s VNI 10000 na každém listu pro hostitele. Nastavte L2 tunel mezi hostiteli
vlan 10 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
vn-segment 10000 ! Ассоциируем VLAN с номер VNI
interface nve1
member vni 10000 ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
ingress-replication protocol bgp ! указываем, что для распространения информации о хосте используем BGPNyní zkontrolujeme nve peery 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 ! Видим что 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 iNahoře vidíme pouze trasy EVPN typu 3. Tento typ tras hovoří o peer (Leaf), ale kde jsou naši hostitelé?
A jde o to, že informace o hostitelích MAC se přenášejí prostřednictvím EVPN typu 2
Abyste viděli naše hostitele, musíte nakonfigurovat EVPN route-type 2:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoOdešleme příkaz ping 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 můžeme vidět, že v tabulce BGP se objevil typ trasy 2 s MAC adresami hostitelů - 5001.0007.0007 a 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 iDále můžete vidět podrobné informace o aktualizaci, ve které jste obdrželi informace o hostiteli MAC. Níže není celý výstup příkazu
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
<........>Podívejme se, jak rámy vypadají, když procházejí továrnou:
Potlačit-ARP
Skvělé, máme L2 spojení mezi hostiteli a tím to může skončit. Nicméně, ne všechno tak jednoduché. Dokud budeme mít málo hostitelů, nebudou žádné problémy. Představme si ale situace, že máme stovky a tisíce hostitelů. S jakým problémem se můžeme potýkat?
Tento problém je BUM (Broadcast, Unknown Unicast, Multicast) provoz. V rámci tohoto článku se budeme zabývat možností boje proti vysílání.
Hlavním generátorem vysílání v sítích Ethernet jsou samotní hostitelé prostřednictvím protokolu ARP.
Nexus implementuje následující mechanismus pro zpracování požadavků ARP - potlačit-arp.
Tato funkce funguje takto:
- Host-1 odešle požadavek APR na Broadcast adresu své sítě.
- Požadavek dorazí k přepínači Leaf a místo předání tohoto požadavku dále do továrny směrem k hostiteli-2, Leaf sám odpoví a uvede požadovanou IP a MAC.
Požadavek na vysílání tedy nešel do továrny. Jak to ale může fungovat, když Leaf zná pouze MAC adresu?
Vše je celkem jednoduché, EVPN route-type 2 kromě MAC adresy umí přenášet i MAC/IP svazek. K tomu musí být Leaf nakonfigurován s IP adresou ve VLAN. Nabízí se otázka, na jakou IP se zeptat? Na nexusu je možné vytvořit distribuovanou (stejnou) adresu na všech přepínačích:
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 macZ pohledu hostitelů tedy bude síť vypadat takto:
Zkontrolujte 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 výstupu příkazu je vidět, že v EVPN route-type 2 nyní kromě MAC vidíme i IP adresu hostitele.
Vraťme se k nastavení potlačení-arp. Toto nastavení je povoleno pro každý VNI zvlášť:
interface nve1
member vni 10000
suppress-arpPak je tu určitá obtíž:
- Tato funkce vyžaduje místo v paměti TCAM. Uvedu příklad nastavení pro supresi-arp:
hardware access-list tcam region arp-ether 256Toto nastavení bude vyžadovat dvojitou šířku. To znamená, že pokud nastavíte 256, pak musí být v TCAM uvolněno 512. Nastavení TCAM je nad rámec tohoto článku, protože nastavení TCAM závisí pouze na úkolu, který vám byl přidělen, a může se v jednotlivých sítích lišit.
- Implementace potlačení-arp musí být provedena na všech přepínačích Leaf. Složitost však může nastat při konfiguraci na párech listů umístěných v doméně VPC. Při změně TCAM bude narušena konzistence mezi páry a jeden uzel může být vyřazen z provozu. Kromě toho může být vyžadováno restartování zařízení k použití nastavení změny TCAM.
V důsledku toho byste měli pečlivě zvážit, zda se ve vaší situaci vyplatí implementovat toto nastavení na fungující továrnu.
Tím končí první část cyklu. V další části se budeme zabývat směrováním přes továrnu VxLAN s oddělením sítě napříč různými VRF.
A teď všechny zvu , ve kterém budu podrobně mluvit o průběhu. Prvních 20 účastníků, kteří se zaregistrují na tento webinář, obdrží Slevový certifikát e-mailem do 1-2 dnů po vysílání.
Zdroj: www.habr.com