Hallo habr. Ik bin op it stuit de kursuslieder foar "Network Engineer" by OTUS.
Yn ôfwachting fan it begjin fan in nije ynskriuwing foar de kursus , Ik haw taret in rige fan artikels oer VxLAN EVPN technology.
D'r is in enoarme hoemannichte materiaal oer de wurking fan VxLAN EVPN, dus ik wol ferskate taken en praktiken sammelje foar it oplossen fan problemen yn in moderne datasintrum.
Yn it earste diel fan 'e VxLAN EVPN-technologysyklus wol ik in manier beskôgje om L2-ferbining te organisearjen tusken hosts boppe op in netwurkfabryk.
Alle foarbylden sille wurde útfierd op Cisco Nexus 9000v, gearstald yn de Spine-Leaf topology. Wy sille net dwaen oer it ynstellen fan it Underlay-netwurk yn dit artikel.
- underlay netwurk
- BGP peering foar adres-famylje l2vpn evpn
- NVE opset
- Underdruk-arp
underlay netwurk
De brûkte topology is as folget:
Litte wy adressen ynstelle op alle apparaten:
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.20Litte wy kontrolearje dat d'r IP-ferbining is tusken alle apparaten:
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, intraLitte wy kontrolearje dat it VPC-domein oanmakke is en beide skeakels de konsistinsjekontrôle hawwe trochjûn en de ynstellingen op beide knopen binne identyk:
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
Uteinlik kinne wy gean nei it konfigurearjen fan it Overlay-netwurk.
As ûnderdiel fan it artikel is it nedich om in netwurk te organisearjen tusken hosts, lykas werjûn yn it diagram hjirûnder:
Om in Overlay-netwurk te konfigurearjen, moatte jo BGP ynskeakelje op 'e Spine- en Leaf-skeakels mei stipe foar de l2vpn evpn-famylje:
feature bgp
nv overlay evpnDêrnei moatte jo BGP-peering konfigurearje tusken Leaf en Spine. Foar ferienfâldigjen de konfiguraasje en optimalisearjen fan de ferdieling fan routing ynformaasje, wy konfigurearje Spine as Route-Reflector tsjinner. Wy sille alle Leaf yn 'e konfiguraasje skriuwe fia sjabloanen om de ynstelling te optimalisearjen.
Dat de ynstellingen op Spine sjogge der sa út:
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 LEAFDe opset op 'e Leaf-skeakel sjocht der sa út:
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 SPINEKontrolearje op Spine peering mei alle Leaf-skeakels:
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 0Sa't jo sjen kinne, wiene d'r gjin problemen mei BGP. Litte wy trochgean mei it ynstellen fan VxLAN. Fierdere konfiguraasje wurdt útfierd allinnich oan 'e kant fan' e Leaf skakelaars. Spine docht allinich as de kearn fan it netwurk en is allinich belutsen by de oerdracht fan ferkear. Alle wurk op ynkapseling en paad definysje komt allinnich op Leaf skakelaars.
NVE opset
NVE - netwurk firtuele ynterface
Foardat jo de opset begjinne, litte wy wat terminology yntrodusearje:
VTEP - Vitual Tunnel End Point, it apparaat wêrop de VxLAN-tunnel begjint of einiget. VTEP is net needsaaklik in netwurkapparaat. In server dy't VxLAN-technology stipet kin ek hannelje. Yn ús topology binne alle Leaf-skeakels VTEP's.
VNI - Virtual Network Index - netwurk identifier binnen VxLAN. Jo kinne in analogy tekenje mei VLAN. D'r binne lykwols wat ferskillen. By it brûken fan in stof, wurde VLANs unyk allinnich binnen ien Leaf switch en wurde net oerdroegen oer it netwurk. Mar elke VLAN kin wurde assosjearre mei in VNI nûmer dat is al oerdroegen oer it netwurk. Hoe't it derút sjocht en hoe't it kin wurde brûkt wurdt hjirûnder besprutsen.
Aktivearje de funksje foar VxLAN-technology om te wurkjen en de mooglikheid om VLAN-nûmers te assosjearjen mei in VNI-nûmer:
feature nv overlay
feature vn-segment-vlan-basedLitte wy de NVE-ynterface konfigurearje, dy't ferantwurdlik is foar de wurking fan VxLAN. Dizze ynterface is ferantwurdlik foar it ynkapseljen fan frames yn VxLAN-koppen. Jo kinne in analogy tekenje mei de Tunnel-ynterface foar GRE:
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0Op de Leaf-21 switch alles wurdt makke sûnder problemen. As wy lykwols de útfier fan it kommando kontrolearje show nve peers, dan sil it leech wêze. Hjir moatte jo weromgean nei de VPC-opset. Wy sjogge dat Leaf-11 en Leaf-12 wurde keppele en ferienige troch in VPC-domein. Dit resultearret yn de folgjende situaasje:
Host-2 stjoert ien frame nei Leaf-21 om oer it netwurk te stjoeren nei Host-1. Leaf-21 sjocht lykwols dat it MAC-adres fan Host-1 tagelyk beskikber is fia twa VTEP's. Wat moat Leaf-21 dwaan yn dit gefal? Dit betsjut ommers dat der in lus yn it netwurk kin ferskine.
Om dizze situaasje op te lossen, moatte wy Leaf-11 en Leaf-12 ek fungearje as ien apparaat binnen it fabryk. It is frij simpel oplost. Op de Loopback-ynterface wêrfan wy de tunnel bouwe, foegje it sekundêre adres ta. Sekundêr adres moat itselde wêze op beide VTEP's.
interface loopback0
ip add 10.255.1.10/32 secondarySa, út it eachpunt fan oare VTEP's, krije wy de folgjende topology:
Dat is, no sil de tunnel boud wurde tusken it IP-adres fan Leaf-21 en de firtuele IP tusken twa Leaf-11 en Leaf-12. No sille d'r gjin problemen wêze mei it learen fan it MAC-adres fan twa apparaten, en ferkear kin wurde oerbrocht fan de iene VTEP nei de oare. Hokker fan 'e twa VTEP's it ferkear sil ferwurkje wurdt besletten mei de routingtabel op 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, intraLykas jo hjirboppe kinne sjen, is it adres 10.255.1.10 direkt beskikber fia twa Next-hops.
Op dit stadium hawwe wy de basisferbining útfûn. Litte wy trochgean mei it ynstellen fan de NVE-ynterface:
Wy sille fuortendaliks ynskeakelje Vlan 10 en assosjearje it mei VNI 10000 op elk Leaf foar hosts. Stel in L2-tunnel op tusken hosts
vlan 10 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
vn-segment 10000 ! Ассоциируем VLAN с номер VNI
interface nve1
member vni 10000 ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
ingress-replication protocol bgp ! указываем, что для распространения информации о хосте используем BGPLitte wy no nve peers en tabel kontrolearje foar 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 iHjirboppe sjogge wy rûtes allinich EVPN-rûte-type 3. Dit soarte rûtes sprekt oer peer (Leaf), mar wêr binne ús hosts?
En it ding is dat ynformaasje oer MAC-hosts wurdt oerbrocht fia EVPN-rûte-type 2
Om ús hosts te sjen, moatte jo EVPN-rûtetype 2 konfigurearje:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoLitte wy Host-2 pinge nei 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 msEn hjirûnder kinne wy sjen dat rûtetype 2 ferskynde yn 'e BGP-tabel mei it MAC-adres fan' e hosts - 5001.0007.0007 en 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êrnei kinne jo detaillearre ynformaasje sjen oer Update, wêryn jo ynformaasje krigen hawwe oer de MAC Host. Hjirûnder is net de folsleine útfier fan it kommando
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
<........>Litte wy sjen hoe't de frames der útsjen as se troch it fabryk passe:
Underdrukke-ARP
Geweldich, wy hawwe in L2-ferbining tusken hosts en dit kin it ein wêze. Lykwols, net allegear sa ienfâldich. Salang't wy in pear hosts hawwe, sille d'r gjin problemen wêze. Mar lit ús situaasjes foarstelle dat wy hûnderten en tûzenen hosts hawwe. Hokker probleem kinne wy tsjinkomme?
Dit probleem is BUM (Broadcast, Unbekend Unicast, Multicast) ferkear. Yn it ramt fan dit artikel sille wy de opsje beskôgje om útstjoerferkear te bestriden.
De wichtichste Broadcast-generator yn Ethernet-netwurken is de hosts sels fia it ARP-protokol.
Nexus implementeart it folgjende meganisme foar it omgean mei ARP-oanfragen - suppress-arp.
Dizze funksje wurket sa:
- Host-1 stjoert in APR-fersyk nei it útstjoeradres fan syn netwurk.
- It fersyk berikt de Leaf-skeakel en ynstee fan dit fersyk fierder te stjoeren nei it fabryk rjochting Host-2, antwurdet it Leaf himsels en jout de winske IP en MAC oan.
Sa gie it Omropfersyk net nei it fabryk. Mar hoe kin dit wurkje as Leaf allinich it MAC-adres wit?
Alles is frij ienfâldich, EVPN-rûte-type 2, neist it MAC-adres, kin in MAC / IP-bondel ferstjoere. Om dit te dwaan, moat it Leaf konfigureare wurde mei in IP-adres yn it VLAN. De fraach ûntstiet, hokker IP te freegjen? Op nexus is it mooglik om in ferspraat (itselde) adres oan te meitsjen op alle skeakels:
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 macSa, út it eachpunt fan hosts, it netwurk sil der sa útsjen:
Kontrolearje 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
<......>Ut de útfier fan it kommando kin sjoen wurde dat yn EVPN-rûte-type 2, neist de MAC, wy no ek it IP-adres fan 'e host sjogge.
Litte wy weromgean nei de ûnderdruk-arp-ynstelling. Dizze ynstelling is ynskeakele foar elke VNI apart:
interface nve1
member vni 10000
suppress-arpDan is der wat muoite:
- Dizze funksje fereasket romte yn TCAM ûnthâld. Ik sil in foarbyld jaan fan ynstelling foar suppress-arp:
hardware access-list tcam region arp-ether 256Dizze opset sil dûbel-wide fereaskje. Dat is, as jo 256 ynstelle, dan moat 512 frijlitten wurde yn TCAM. It opsetten fan TCAM is bûten it berik fan dit artikel, om't it ynstellen fan TCAM allinich hinget fan 'e taak dy't jo tawiisd is en kin ferskille fan it iene netwurk nei it oare.
- De ymplemintaasje fan suppress-arp moat dien wurde op alle Leaf-skeakels. Kompleksiteit kin lykwols ûntstean by it konfigurearjen op Leaf-pearen dy't yn in VPC-domein leit. By it feroarjen fan TCAM sil de konsistinsje tusken de pearen brutsen wurde en kin ien knooppunt út tsjinst nommen wurde. Derneist kin in apparaat opnij opstarte nedich wêze om de TCAM-feroaringsynstelling oan te passen.
As gefolch, jo moatte soarchfâldich beskôgje oft it is de muoite wurdich om te fieren dizze ynstelling op in wurkjende fabryk yn jo situaasje.
Dit einiget it earste diel fan 'e syklus. Yn it folgjende diel sille wy routing beskôgje troch in VxLAN-fabryk mei netwurkskieding oer ferskate VRF's.
En no noegje ik elkenien út , dêr't ik yn detail oer de kursus sil prate. De earste 20 dielnimmers dy't har registrearje foar dit webinar krije binnen 1-2 dagen nei de útstjoering in koartingssertifikaat per e-post.
Boarne: www.habr.com