Hei habr. Olen tällä hetkellä OTUS:n verkkoinsinöörin kurssin vetäjä.
Uuden kurssin ilmoittautumisen alkamista odotellessa , Olen valmistellut sarjan artikkeleita VxLAN EVPN -tekniikasta.
VxLAN EVPN:n toiminnasta on valtava määrä materiaalia, joten haluan kerätä erilaisia tehtäviä ja käytäntöjä ongelmien ratkaisemiseksi nykyaikaisessa datakeskuksessa.
VxLAN EVPN -teknologiasyklin ensimmäisessä osassa haluan harkita tapaa järjestää L2-yhteydet isäntien välillä verkkotehtaan päälle.
Kaikki esimerkit suoritetaan Cisco Nexus 9000v:llä, joka on koottu Spine-Leaf-topologiaan. Emme käsittele tässä artikkelissa Underlay-verkon määrittämistä.
- aluskateverkko
- BGP-peering osoiteperheelle l2vpn evpn
- NVE-asetukset
- Suppress-arp
aluskateverkko
Käytetty topologia on seuraava:
Asetetaan osoite kaikille laitteille:
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.20Tarkistamme, että kaikkien laitteiden välillä on IP-yhteys:
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, intraTarkistetaan, että VPC-toimialue on luotu ja molemmat kytkimet ovat läpäisseet johdonmukaisuustarkistuksen ja molempien solmujen asetukset ovat samat:
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
Lopuksi voimme siirtyä Overlay-verkon konfigurointiin.
Osana artikkelia on tarpeen järjestää verkko isäntien välillä alla olevan kaavion mukaisesti:
Overlay-verkon määrittämistä varten sinun on otettava BGP käyttöön Spine- ja Leaf-kytkimissä, jotka tukevat l2vpn evpn -perhettä:
feature bgp
nv overlay evpnSeuraavaksi sinun on määritettävä BGP-peering Leafin ja Spinen välillä. Konfiguroinnin yksinkertaistamiseksi ja reititystietojen jakelun optimoimiseksi määritämme Spinen Route-Reflector-palvelimeksi. Kirjoitamme kaikki Leaf konfiguraatioon mallien avulla optimoidaksemme asetusta.
Joten Spinen asetukset näyttävät tältä:
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 LEAFLeaf-kytkimen asetus näyttää samalta:
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 SPINETarkista selkäpuolella peering kaikilla Leaf-kytkimillä:
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 0Kuten näette, BGP:n kanssa ei ollut ongelmia. Siirrytään VxLAN-asetusten määrittämiseen. Lisäasetukset suoritetaan vain Leaf-kytkimien sivulla. Spine toimii vain verkon ytimenä ja on mukana vain liikenteen välittämisessä. Kaikki kapselointiin ja polun määrittelyyn liittyvä työ tapahtuu vain Leaf-kytkimillä.
NVE-asetukset
NVE - virtuaalinen verkkoliitäntä
Ennen kuin aloitat asennuksen, esittelemme terminologiaa:
VTEP - Vitual Tunnel End Point, laite, jossa VxLAN-tunneli alkaa tai päättyy. VTEP ei välttämättä ole mikään verkkolaite. VxLAN-tekniikkaa tukeva palvelin voi myös toimia. Topologiassamme kaikki Leaf-kytkimet ovat VTEP:itä.
VNI - Virtual Network Index - verkkotunniste VxLANissa. Voit vetää analogian VLANin kanssa. On kuitenkin joitain eroja. Käytettäessä kangasta VLAN-verkoista tulee ainutlaatuisia vain yhdessä Leaf-kytkimessä, eikä niitä välitetä verkon yli. Mutta jokainen VLAN voidaan liittää VNI-numeroon, joka on jo lähetetty verkon kautta. Miltä se näyttää ja miten sitä voidaan käyttää, käsitellään alla.
Ota VxLAN-tekniikan käyttöön ominaisuus ja mahdollisuus liittää VLAN-numeroita VNI-numeroon:
feature nv overlay
feature vn-segment-vlan-basedKonfiguroidaan NVE-liitäntä, joka vastaa VxLANin toiminnasta. Tämä käyttöliittymä vastaa kehysten kapseloimisesta VxLAN-otsikoihin. Voit vetää analogian GRE:n tunnelirajapinnan kanssa:
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0Leaf-21-kytkimellä kaikki luodaan ilman ongelmia. Jos kuitenkin tarkistamme komennon lähdön show nve peers, silloin se on tyhjä. Tässä sinun on palattava VPC-asetuksiin. Näemme, että Leaf-11 ja Leaf-12 muodostavat parin ja yhdistävät VPC-verkkotunnuksen. Tästä seuraa seuraava tilanne:
Isäntä-2 lähettää yhden kehyksen Leaf-21:lle lähetettäväksi verkon yli isäntä-1:lle. Leaf-21 kuitenkin näkee, että isäntä-1:n MAC-osoite on saatavilla kahden VTEP:n kautta kerralla. Mitä Leaf-21:n pitäisi tehdä tässä tapauksessa? Loppujen lopuksi tämä tarkoittaa, että verkkoon voi ilmestyä silmukka.
Tämän tilanteen ratkaisemiseksi tarvitsemme Leaf-11:n ja Leaf-12:n toimimaan yhtenä laitteena tehtaalla. Se ratkaistaan melko yksinkertaisesti. Lisää toissijainen osoite Loopback-liittymään, josta tunnelia rakennetaan. Toissijaisen osoitteen on oltava sama molemmissa VTEP:issä.
interface loopback0
ip add 10.255.1.10/32 secondarySiten muiden VTEP:ien näkökulmasta saamme seuraavan topologian:
Eli nyt tunneli rakennetaan Leaf-21:n IP-osoitteen ja kahden Leaf-11:n ja Leaf-12:n välisen virtuaalisen IP-osoitteen väliin. Nyt ei ole ongelmia MAC-osoitteen oppimisessa kahdesta laitteesta, ja liikennettä voidaan siirtää VTEP:stä toiseen. Kumpi kahdesta VTEP:stä käsittelee liikenteen, päätetään Spinen reititystaulukon avulla:
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, intraKuten yllä näkyy, osoite 10.255.1.10 on heti käytettävissä kahden Next-hopin kautta.
Tässä vaiheessa selvitimme perusyhteydet. Siirrytään NVE-liitännän määrittämiseen:
Otamme välittömästi käyttöön Vlan 10:n ja yhdistämme sen VNI 10000:een jokaisella isäntälehdellä. Luo L2-tunneli isäntien välille
vlan 10 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
vn-segment 10000 ! Ассоциируем VLAN с номер VNI
interface nve1
member vni 10000 ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
ingress-replication protocol bgp ! указываем, что для распространения информации о хосте используем BGPTarkastetaan nyt nve vertaistukea ja taulukko BGP EVPN:lle:
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 iYllä näemme reitit vain EVPN-reittityypin 3. Tämäntyyppiset reitit puhuvat vertaistyypistä (Leaf), mutta missä ovat isäntämme?
Ja asia on, että tiedot MAC-isännistä lähetetään EVPN-reititystyypin 2 kautta
Jotta voit nähdä isäntimme, sinun on määritettävä EVPN-reittityyppi 2:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoPingataan isäntä-2:lle isäntä-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 msJa alla näemme, että reittityyppi 2 ilmestyi BGP-taulukkoon isäntien MAC-osoitteilla - 5001.0007.0007 ja 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 iSeuraavaksi näet yksityiskohtaiset tiedot päivityksestä, jossa sait tietoja MAC-isännästä. Alla ei ole koko komennon tulos
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
<........>Katsotaan miltä kehykset näyttävät, kun ne kuljetetaan tehtaan läpi:
Suppress-ARP
Hienoa, meillä on L2-yhteys isäntien välillä ja tämä voi olla sen loppu. Kaikki eivät kuitenkaan ole niin yksinkertaisia. Niin kauan kuin meillä on vähän isäntiä, ei ole ongelmia. Mutta kuvitellaan tilanteita, joissa meillä on satoja ja tuhansia isäntiä. Minkä ongelman voimme kohdata?
Tämä ongelma on BUM (Broadcast, Unknown Unicast, Multicast) -liikenne. Tämän artikkelin puitteissa harkitsemme mahdollisuutta torjua lähetysliikennettä.
Päälähetysgeneraattori Ethernet-verkoissa ovat itse isännät ARP-protokollan kautta.
Nexus toteuttaa seuraavan mekanismin ARP-pyyntöjen käsittelyyn - suppress-arp.
Tämä ominaisuus toimii näin:
- Isäntä-1 lähettää APR-pyynnön verkkonsa Broadcast-osoitteeseen.
- Pyyntö saavuttaa Leaf-kytkimen ja sen sijaan, että se välittäisi tämän pyynnön edelleen tehtaalle Host-2:lle, Leaf vastaa itse ja ilmoittaa halutun IP:n ja MAC:n.
Näin ollen Broadcast-pyyntö ei mennyt tehtaalle. Mutta kuinka tämä voi toimia, jos Leaf tietää vain MAC-osoitteen?
Kaikki on melko yksinkertaista, EVPN-reittityyppi 2 voi MAC-osoitteen lisäksi lähettää MAC / IP -paketin. Tätä varten Leafille on määritettävä IP-osoite VLANissa. Herää kysymys, mitä IP-osoitetta kysyä? Nexuksessa on mahdollista luoda hajautettu (sama) osoite kaikille kytkimille:
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 macSiten isäntien näkökulmasta verkko näyttää tältä:
Tarkista 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
<......>Komennon lähdöstä voidaan nähdä, että EVPN-reitittimessä 2 näemme nyt MAC:n lisäksi myös isännän IP-osoitteen.
Palataan suppress-arp-asetukseen. Tämä asetus on käytössä jokaiselle VNI:lle erikseen:
interface nve1
member vni 10000
suppress-arpSitten on vaikeuksia:
- Tämä ominaisuus vaatii tilaa TCAM-muistissa. Annan esimerkin suppress-arpin asettamisesta:
hardware access-list tcam region arp-ether 256Tämä asetus vaatii kaksinkertaisen leveyden. Eli jos määrität 256, TCAM:ssa on vapautettava 512. TCAM:n määrittäminen ei kuulu tämän artikkelin piiriin, koska TCAM:n määrittäminen riippuu vain sinulle määrätystä tehtävästä ja voi vaihdella verkoittain.
- Suppress-arp on suoritettava kaikissa Leaf-kytkimissä. Monimutkaisuutta voi kuitenkin syntyä määritettäessä Leaf-pareja, jotka sijaitsevat VPC-toimialueessa. TCAM:ia vaihdettaessa parien välinen johdonmukaisuus katkeaa ja yksi solmu voidaan poistaa käytöstä. Lisäksi laite saattaa vaatia uudelleenkäynnistyksen, jotta TCAM-muutosasetus voidaan ottaa käyttöön.
Tästä syystä sinun tulee harkita huolellisesti, kannattaako tämä asetus ottaa käyttöön tilanteessasi toimivassa tehtaassa.
Tämä päättää syklin ensimmäisen osan. Seuraavassa osassa harkitsemme reititystä VxLAN-tehtaan kautta verkkoerottelulla eri VRF:ien välillä.
Ja nyt kutsun kaikki mukaan , jossa kerron kurssista yksityiskohtaisesti. Ensimmäiset 20 osallistujaa, jotka ilmoittautuvat tähän webinaariin, saavat alennustodistuksen sähköpostitse 1-2 päivän kuluessa lähetyksestä.
Lähde: will.com