Fabrika VxLAN. Pjesa 1

Përshëndetje, habr. Aktualisht jam drejtori i kursit "Inxhinier Rrjeti" në OTUS.
Në prag të fillimit të një grupi të ri për kursin "Inxhinieri i rrjetit", kam përgatitur një cikël artikujsh mbi teknologjinë VxLAN EVPN.

Ekziston një sasi e madhe materialesh mbi funksionimin e VxLAN EVPN, prandaj dua të grumbulloj detyra të ndryshme dhe praktika për zgjidhjen e tyre në një Qendër të Të Dhënave moderne.

Fabrika VxLAN. Pjesa 1

Në pjesën e parë të ciklit mbi teknologjinë VxLAN EVPN, do të shqyrtoj mënyrën e organizimit të lidhjes L2 midis hosteve mbi fabrikën rrjet.

Të gjitha shembujt do të zbatohen në Cisco Nexus 9000v, të organizuar në një topologji Spine-Leaf. Nuk do të ndalemi në konfigurimin e rrjetit Underlay brenda këtij artikulli.

  1. Rrjeti Underlay
  2. BGP peer për address-family l2vpn evpn
  3. Konfigurimi i NVE
  4. Supress-arp

Rrjeti Underlay

Topologjia e përdorur duket si më poshtë:

Fabrika VxLAN. Pjesa 1

Do të caktojmë adresimin në të gjitha pajisjet:

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.20

Do të verifikojmë se ka lidhje IP midis të gjitha pajisjeve:

Leaf21# sh ip route

10.255.1.11/32, ubest/mbest: 2/0                      ! Leaf-11 i aksesueshëm përmes dy Spine
    *përmes 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
    *përmes 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 i aksesueshëm përmes dy Spine
    *përmes 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
    *përmes 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.21/32, ubest/mbest: 2/0, i lidhur
    *përmes 10.255.1.22, Lo0, [0/0], 00:02:20, lokal
    *përmes 10.255.1.22, Lo0, [0/0], 00:02:20, direkt
10.255.1.101/32, ubest/mbest: 1/0
    *përmes 10.255.1.101, Eth1/4, [110/41], 00:00:06, ospf-UNDERLAY, intra
10.255.1.102/32, ubest/mbest: 1/0
    *përmes 10.255.1.102, Eth1/3, [110/41], 00:00:03, ospf-UNDERLAY, intra

Do të kontrollojmë nëse domeni VPC është krijuar dhe të dy switch-at kanë kaluar verifikimin e konsistencës dhe konfigurimi në të dy nodet është identik:

Leaf11# show vpc 

vPC domain id                     : 1
Peer status                       : statusi i fqinjit është formuar në rregull
vPC keep-alive status             : fqinj është aktiv
Configuration consistency status  : sukses
Per-vlan consistency status       : sukses
Type-2 consistency status         : sukses
vPC role                          : primar
Number of vPCs configured         : 0
Peer Gateway                      : i Çaktivizuar
Dual-active excluded VLANs        : -
Graceful Consistency Check        : Aktivizuar
Auto-recovery status              : i Çaktivizuar
Delay-restore status              : Timer është i fikur.(timeout = 30s)
Delay-restore SVI status          : Timer është i fikur.(timeout = 10s)
Operational Layer3 Peer-router    : i Çaktivizuar

vPC status
----------------------------------------------------------------------------
Id    Port          Status Konsistenca Arsye                VLAN-t aktivë
--    ------------  ------ ----------- ------                ---------------
5     Po5           up     sukses     sukses               1

BGP peer

Mund të kalojmë në konfigurimin e rrjetit Overlay.

Brenda këtij artikulli duhet të organizohet një rrjet midis hosteve, siç ilustrohet në diagramin më poshtë:

Fabrika VxLAN. Pjesa 1

Për të konfiguruar rrjetin Overlay, nevojitet të aktivizojmë BGP me mbështetje për familjen l2vpn evpn në switch-at Spine dhe Leaf:

feature bgp
nv overlay evpn

Pastaj duhet të konfigurojmë BGP peer midis Leaf dhe Spine. Për të thjeshtuar konfigurimin dhe për të optimizuar përhapjen e informacionit të rrugës, Spine do të konfigurohet si server Route-Reflector. Të gjitha Leaf-t do të shënohen në konfigurim përmes shablloneve, për të optimizuar konfigurimin.

Kështu që konfigurimet në Spine duken si më poshtë:

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 LEAF

Konfigurimi në switch-in Leaf duket në mënyrë të ngjashme:

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 SPINE

Në Spine do të verifikojmë lidhjen me të gjitha switch-at 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 0

Siç po shohim, nuk kishte probleme me BGP. Le të kalojmë në konfigurimin e VxLAN. Konfigurimi në vazhdim do të bëhet vetëm në anën e switch-ave Leaf. Spine vepron vetëm si bërthama e rrjetit dhe merret vetëm me transmetimin e trafikut. Të gjitha operacionet e enkriptimit dhe përcaktimit të rrugës ndodhin vetëm në switch-at Leaf.

Konfigurimi i NVE

NVE — ndĂ«rfaqja virtuale e rrjetit

Para fillimit të konfigurimit, le të prezantojmë pak terminologji:

VTEP — Pika pĂ«rfundimtare e Tunelit Virtual, pajisje nĂ« tĂ« cilĂ«n fillon ose pĂ«rfundon tuneli VxLAN. VTEP nuk Ă«shtĂ« domosdoshmĂ«risht njĂ« pajisje rrjetesh. Po ashtu mund tĂ« jetĂ« njĂ« server qĂ« mbĂ«shtet teknologjinĂ« VxLAN. NĂ« topologjinĂ« tonĂ«, tĂ« gjitha switch-at Leaf janĂ« VTEP.

VNI — Indeksi i Rrjetit Virtual — identifikuesi i rrjetit brenda VxLAN. Mund tĂ« bĂ«het njĂ« krahasim me VLAN-in. MegjithatĂ«, ka disa ndryshime. Kur pĂ«rdoret fabrika, VLAN-t bĂ«hen unike vetĂ«m brenda njĂ« switch-i Leaf dhe nuk transmetohen pĂ«rmes rrjetit. Por secilit VLAN mund t'i asociohet njĂ« numĂ«r VNI, i cili tashmĂ« transmetohet pĂ«rmes rrjetit. Si duket kjo dhe si mund tĂ« pĂ«rdoret, do tĂ« shqyrtohet mĂ« vonĂ«.

Të aktivizojmë funksionin për të mbështetur teknologjinë VxLAN dhe mundësinë e asociimit të numrave VLAN me numrin VNI:

feature nv overlay
feature vn-segment-vlan-based

Do të konfigurojmë ndërfaqen NVE, e cila është përgjegjëse për funksionimin e VxLAN. Kjo ndërfaqe merret me inkapsulimin e cadra në titujt VxLAN. Mund të bëjmë një analogji me ndërfaqen Tunnel për funksionimin GRE:

interface nve1
  no shutdown
  host-reachability protocol bgp ! përdorim BGP për transmetimin e informacionit për rrugët
  source-interface loopback0    ! ndërfaqja nga e cila dërgojmë paketa loopback0

Në ndërlidhësin Leaf-21, gjithçka krijohet pa probleme. Megjithatë, nëse ne kontrollojmë daljen e komandës show nve peers, ajo do të jetë bosh. Këtu është e nevojshme të kthehemi në konfigurimin e VPC. Ne shohim se Leaf-11 dhe Leaf-12 funksionojnë në çift dhe janë të bashkuar në domenin VPC. Kështu rezulton situata e mëposhtme:

Host-2 dërgon një cadër drejt Leaf-21, në mënyrë që ai ta transmetojë në rrjet drejt Host-1. Megjithatë, Leaf-21 sheh se adresa MAC e Host-1 është e disponueshme menjëherë përmes dy VTEP. Si duhet të veprojë Leaf-21 në këtë rast? Sepse kjo do të thotë se një cikël mund të jetë shfaqur në rrjet.

Për të zgjidhur këtë situatë, kemi nevojë që Leaf-11 dhe Leaf-12 brenda fabrikës gjithashtu të paraqiten si një pajisje. Kjo zgjidhet mjaft thjesht. Në ndërfaqen Loopback, nga e cila ndërtuam tunelin, shtojmë adresën sekondare. Adresa sekondare duhet të jetë e njëjtë në të dy VTEP.

interface loopback0
 ip add 10.255.1.10/32 secondary

Kështu, nga këndvështrimi i VTEP të tjerë, ne marrim topologjinë e mëposhtme:

Fabrika VxLAN. Pjesa 1

Kështu, tani tuneli do të ndërtohet midis adresës IP të Leaf-21 dhe adresës virtuale IP ndërmjet dy Leaf-11 dhe Leaf-12. Tani, nuk do të ketë probleme me njohjen e adresës MAC nga dy pajisjet, dhe trafiku mund të kalojë nga një VTEP në tjetrin. Kush saktësisht nga dy VTEP do të trajtojë trafikun përcaktohet nga tabela e rrugëtimit në 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, intra

Siç duket më sipër, adresa 10.255.1.10 është e disponueshme përmes dy Next-hop.

Në këtë fazë analizojmë lidhjen bazë. Të kalojmë te konfigurimi i ndërfaqes NVE:
Menjëherë do të aktivizojmë VLAN 10 dhe do ta asociojmë atë me VNI 10000 në çdo Leaf për hostet. Do të krijojmë një tunel L2 midis hosteve

vlan 10                 ! Aktivizojmë VLAN në të gjitha VTEP të lidhura me hostet e nevojshme
  vn-segment 10000      ! Asociojmë VLAN me numrin VNI 

interface nve1
  member vni 10000      ! Shtojmë VNI 10000 për funksionimin përmes ndërfaqes NVE, për inkapsulim në VxLAN
    ingress-replication protocol bgp    ! caktimi i BGP për shpërndarjen e informacionit për hostet

Tani le të kontrollojmë nve peers dhe tabelën për 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                 ! Shohim se peer është i disponueshëm nga adresa sekondare

Leaf11# sh bgp l2vpn evpn

   Rrjeti            Next Hop            Metric     LocPrf     Weight Path
Rrugë Distingues: 10.255.1.11:32777    (L2VNI 10000)        ! Nga kush ka ardhur ky l2VNI
*>l[3]:[0]:[32]:[10.255.1.10]/88                                   ! Rruga EVPN type 3 - tregon fqinjën tonë, i cili gjithashtu e njeh 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

Rrugë Distingues: 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 i

Më sipër shohim rrugët vetëm EVPN route-type 3. Ky tip rrugësh tregon për peer (Leaf), por ku janë hostet tona?
Arsyeja është se informacioni për MAC-in e hosteve transmetohet përmes EVPN route-type 2.

Për të parë hostet tona, duhet të konfigurojmë EVPN route-type 2:

evpn
  vni 10000 l2
    route-target import auto   ! Në kuadër të këtij artikulli përdorim numrin automatik për route-target
    route-target export auto

Do të bëjmë ping nga Host-2 në 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 ms

Dhe mĂ« poshtĂ« ne mund tĂ« shohim se nĂ« tabela BGP janĂ« shfaqur rrugĂ« tĂ« tipit 2 me adresat MAC tĂ« hosteve – 5001.0007.0007 dhe 5001.0008.0007.

Leaf11# sh bgp l2vpn evpn


   Rrjeti            Next Hop            Metric     LocPrf     Weight Path
Rrugë Distingues: 10.255.1.11:32777    (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216                      !  rruga evpn type 2 dhe adresa mac e hostit 1
                      10.255.1.10                       100      32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216                      ! rruga evpn type 2 dhe adresa mac e hostit 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
Rrugë Distingues: 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

Më pas mund të shikojmë informacionin e detajuar mbi Update, në të cilin kemi marrë informacionin mbi MAC-in e Host. Më poshtë paraqitet jo e gjithë dalja e komandës.

Leaf21# sh bgp l2vpn evpn 5001.0007

Informacionet e tabelës së ruterit BGP për VRF default, familja e adresave L2VPN EVPN
Distinguesi i Rrugës: 10.255.1.11:32777        ! dërguar Update me MAC Host. Jo adresë virtuale VPC, por adresë Leaf
Shënimi i tabelës BGP për [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216,
 version 1507
Rrugët: (2 të disponueshme, më e mira #2)
Flamuj: (0x000202) (high32 00000000) në xmit-list, nuk është në l2rib/evpn, nuk është në HW

  Lloji i shkallës: i brendshëm, rruga është e vlefshme, arsyeja nuk është më e mira: Adresa e Fqinjit, asnjë nexthop me etiketë
  AS-Path: ASNONE, rruga e burimit është e brendshme për AS
    10.255.1.10 (metrikë 81) nga 10.255.1.102 (10.255.1.102)    ! me kë po e ndërtojmë tunelin VxLAN
      Origjina IGP, MED nuk është vendosur, preferenca lokale 100, pesha 0
      Etiketa e pranuar 10000         ! Numri VNI që është asociuar me VLAN-in, ku ndodhet Host
      Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8        ! Këtu duket se RT është formuar automatikisht mbi bazën e numrave AS dhe VNI
      Origjinatori: 10.255.1.11 Lista e klasterit: 10.255.1.102

Le të shohim si duken kadrat kur ato dërgohen përmes fabrikës:

Fabrika VxLAN. Pjesa 1

Suppress-ARP

Shumë mirë, lidhja L2 ndërmjet hosteve tani është krijuar dhe këtu mund ta përfundojmë. Megjithatë, gjërat nuk janë aq të thjeshta. Deri tani, me pak hostë nuk do të ketë probleme. Por le të imagjinojmë situatat kur kemi qindra ose mijëra hostë. Me çfarë problemi mund të ballafaqohemi?

Ky problem është trafiku BUM (Broadcast, Unknown Unicast, Multicast). Në këtë artikull do të shqyrtojmë mënyrat e trajtimit të trafikut broadcast.
Burimi kryesor i Broadcast në rrjetet Ethernet janë vetë hostet përmes protokollit ARP.

NĂ« nexus Ă«shtĂ« implementuar mekanizmi i mĂ«poshtĂ«m pĂ«r tĂ« luftuar kĂ«rkesat ARP — suppress-arp.
Funksionimi i kësaj veçorie duket si më poshtë:

  1. Host-1 dërgon kërkesën APR në adresën Broadcast të rrjetit të tij.
  2. KĂ«rkesa arrin nĂ« switch-in Leaf dhe nĂ« vend qĂ« ta dĂ«rgojĂ« mĂ« tej nĂ« fabrikĂ« drejt Host-2 — Leaf pĂ«rgjigjet vetĂ« dhe tregon IP dhe MAC tĂ« nevojshme.

Kështu, kërkesa Broadcast nuk shkoi në fabrikë. Por si mund të funksionojë kjo, nëse Leaf di vetëm adresën MAC?

E gjithë kjo është mjaft e thjeshtë, lloji i rrugës EVPN 2 përveç adresës MAC mund të transmetojë një çift MAC/IP. Për këtë, në Leaf është e nevojshme të konfigurohet një adresë IP në VLAN. Këtu lind pyetja, cila IP duhet të vendoset? Në nexus ekziston mundësia për të krijuar një adresë të shpërndarë (të njëjtë) në të gjitha switch-et:

feature interface-vlan

fabric forwarding anycast-gateway-mac 0001.0001.0001    ! vendosim virtual mac për krijimin e një gateway të shpërndarë midis të gjithë switch-eve

interface Vlan10
  no shutdown
  ip address 192.168.10.254/24          ! në të gjithë Leaf vendosim IP-në e njëjtë
  fabric forwarding mode anycast-gateway    ! i themi të përdorë Virtual mac

Kështu, nga pikëpamja e hosteve, rrjeti do të duket si më poshtë:

Fabrika VxLAN. Pjesa 1

Le të kontrollojmë BGP l2route evpn

Leaf11# sh bgp l2vpn evpn


   Rrjeti            Next Hop            Metrikë     LocPrf     Pesha Rruga
Distinguesi i Rrugës: 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

<......>

Distinguesi i Rrugës: 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

<......>

Nga dalja e komandës, është e qartë se në EVPN route-type 2, përveç MAC tani shohim gjithashtu adresën IP të hostit.

Të kthehemi tek konfigurimi i suppress-arp. Ky parametër aktivizohet për çdo VNI veçmas:

interface nve1
  member vni 10000   
    suppress-arp

Më pas lind një vështirësi e caktuar:

  • PĂ«r tĂ« funksionuar kjo veçori, Ă«shtĂ« e nevojshme hapĂ«sira nĂ« memorien TCAM. Do tĂ« jap njĂ« shembull tĂ« konfigurimit pĂ«r suppress-arp:

hardware access-list tcam region arp-ether 256

Për këtë konfigurim do të nevojitet double-wide. Kështu, nëse vendosni 256, në TCAM duhet të lirohet 512. Konfigurimi i TCAM kalon jashtë përmbajtjes së këtij artikulli, pasi konfigurimi i TCAM varet vetëm nga detyra e vendosur dhe mund të ndryshojë nga një rrjet në një tjetër.

  • Implementimi i suppress-arp duhet tĂ« bĂ«het nĂ« tĂ« gjitha switch-et Leaf. MegjithatĂ«, vĂ«shtirĂ«si mund tĂ« lindin nĂ« konfigurimin e çifteve Leaf qĂ« ndodhen nĂ« domenin VPC. Kur ndryshohet TCAM, konsistenca midis çifteve do tĂ« prishet dhe njĂ« nodĂ« mund tĂ« nxirret nga operimi. PĂ«rveç kĂ«saj, pĂ«r zbatimin e konfigurimit, ndonjĂ«herĂ« mund tĂ« kĂ«rkohet njĂ« rindezje e pajisjes.

Si rezultat, duhet të mendoni mirë nëse implementimi i kësaj konfigurimi në fabrikën tuaj aktive është një zgjedhje e mençur.

Me këtë, përfundojmë pjesën e parë të ciklit. Në pjesën tjetër do të shqyrtojmë ruterimin përmes fabrikës VxLAN me ndarjen e rrjeteve sipas VRF-ve të ndryshme.

Tani ju ftoj të gjithë në webinarin falas, në kuadër të cilit do t'ju flas në detaje për kursin. 20 pjesëmarrësit e parë që regjistrohen në këtë webinar do të marrin një Certifikatë për zbritje në email-in e tyre brenda 1-2 ditësh pas transmetimit.

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster