VxLAN-fabriek. Deel 1

Hallo, habr. Momenteel ben ik cursusleider voor de opleiding Network Engineer bij OTUS.
In afwachting van de start van een nieuwe inschrijving voor de opleiding "Netwerktechnicus", Ik heb een reeks artikelen voorbereid over VxLAN EVPN-technologie.

Er is een enorme hoeveelheid materiaal over hoe VxLAN EVPN werkt, dus ik wil verschillende taken en praktijken verzamelen voor het oplossen van problemen in een modern datacenter.

VxLAN-fabriek. Deel 1

In het eerste deel van de serie over VxLAN EVPN-technologie wil ik kijken naar een manier om L2-connectiviteit tussen hosts bovenop een netwerkstructuur te organiseren.

Alle voorbeelden zullen worden uitgevoerd op een Cisco Nexus 9000v, geassembleerd in de Spine-Leaf-topologie. In dit artikel gaan we niet dieper in op het opzetten van een Underlay-netwerk.

  1. Onderliggend netwerk
  2. BGP-peering voor adresfamilie l2vpn evpn
  3. NVE opzetten
  4. Onderdrukken-arp

Onderliggend netwerk

De gebruikte topologie is als volgt:

VxLAN-fabriek. Deel 1

Laten we de adressering op alle apparaten instellen:

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

Laten we controleren of er IP-connectiviteit is tussen 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, intra

Laten we controleren of het VPC-domein is aangemaakt en dat beide switches de consistentiecontrole hebben doorstaan ​​en dat de instellingen op beide knooppunten identiek zijn:

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               1

BGP-peering

Ten slotte kunt u doorgaan met het instellen van het Overlay-netwerk.

Als onderdeel van het artikel is het noodzakelijk om een ​​netwerk tussen hosts te organiseren, zoals weergegeven in het onderstaande diagram:

VxLAN-fabriek. Deel 1

Om een ​​Overlay-netwerk te configureren, moet u BGP inschakelen op de Spine- en Leaf-switches met ondersteuning voor de l2vpn evpn-familie:

feature bgp
nv overlay evpn

Vervolgens moet u BGP-peering tussen Leaf en Spine configureren. Om de installatie te vereenvoudigen en de distributie van routeringsinformatie te optimaliseren, configureren we Spine als een Route-Reflector-server. We zullen alle Leaf in de configuratie schrijven met behulp van sjablonen om de installatie te optimaliseren.

Dus de instellingen op Spine zien er als volgt uit:

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

De opstelling op de Leaf-schakelaar ziet er hetzelfde uit:

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

Laten we op Spine de peering met alle Leaf-schakelaars controleren:

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

Zoals u kunt zien, waren er geen problemen met BGP. Laten we verder gaan met het instellen van VxLAN. Verdere configuratie zal alleen worden uitgevoerd aan de Leaf-zijde van de schakelaars. Spine fungeert alleen als de kern van het netwerk en is alleen betrokken bij het verzenden van verkeer. Al het inkapselings- en padbepalingswerk vindt alleen plaats op Leaf-schakelaars.

NVE opzetten

NVE - virtuele netwerkinterface

Voordat we met de installatie beginnen, introduceren we eerst wat terminologie:

VTEP - Vitual Tunnel End Point, het apparaat waarop de VxLAN-tunnel begint of eindigt. VTEP is niet noodzakelijkerwijs een netwerkapparaat. Een server die VxLAN-technologie ondersteunt, kan ook als server fungeren. In onze topologie zijn alle Leaf-switches VTEP.

VNI - Virtual Network Index - netwerkidentificatie binnen VxLAN. Er kan een analogie worden getrokken met VLAN. Er zijn echter enkele verschillen. Bij gebruik van een fabric worden VLAN's alleen uniek binnen één Leaf-switch en worden ze niet via het netwerk verzonden. Maar aan elk VLAN kan een VNI-nummer zijn gekoppeld, dat al via het netwerk wordt verzonden. Hoe het eruit ziet en hoe het kan worden gebruikt, wordt verder besproken.

Laten we de functie inschakelen zodat VxLAN-technologie werkt en de mogelijkheid om VLAN-nummers aan een VNI-nummer te koppelen:

feature nv overlay
feature vn-segment-vlan-based

Laten we de NVE-interface configureren, die verantwoordelijk is voor de werking van VxLAN. Deze interface is verantwoordelijk voor het inkapselen van frames in VxLAN-headers. Je kunt een analogie trekken met de Tunnel-interface voor GRE:

interface nve1
  no shutdown
  host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
  source-interface loopback0    ! интерфейс  с которого отправляем пакеты loopback0

Op de Leaf-21-schakelaar gebeurt alles zonder problemen. Als we echter de uitvoer van de opdracht controleren show nve peers, dan is deze leeg. Hier moet u terugkeren naar de VPC-configuratie. We zien dat Leaf-11 en Leaf-12 in paren werken en verenigd zijn door een VPC-domein. Dit levert ons de volgende situatie op:

Host-2 verzendt één frame naar Leaf-21, zodat het dit via het netwerk naar Host-1 verzendt. Leaf-21 ziet echter dat het MAC-adres van Host-1 via twee VTEP's tegelijk toegankelijk is. Wat moet Leaf-21 in dit geval doen? Dit betekent immers dat er een lus in het netwerk kan ontstaan.

Om deze situatie op te lossen hebben we Leaf-11 en Leaf-12 nodig die ook binnen de fabriek als één apparaat kunnen fungeren. De oplossing is vrij eenvoudig. Voeg een secundair adres toe aan de Loopback-interface van waaruit we de tunnel bouwen. Het secundaire adres moet op beide VTEP's hetzelfde zijn.

interface loopback0
 ip add 10.255.1.10/32 secondary

Vanuit het oogpunt van andere VTEP's krijgen we dus de volgende topologie:

VxLAN-fabriek. Deel 1

Dat wil zeggen dat nu de tunnel wordt gebouwd tussen het IP-adres van Leaf-21 en het virtuele IP-adres tussen twee Leaf-11 en Leaf-12. Nu zijn er geen problemen meer om het MAC-adres van twee apparaten te leren en kan het verkeer van de ene VTEP naar de andere gaan. Welke van de twee VTEP's het verkeer zal verwerken, wordt bepaald met behulp van de routeringstabel 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, intra

Zoals je hierboven kunt zien, is het adres 10.255.1.10 direct beschikbaar via twee Next-hops.

In dit stadium hebben we de basisconnectiviteit behandeld. Laten we verder gaan met het instellen van de NVE-interface:
Laten we Vlan 10 onmiddellijk inschakelen en koppelen aan VNI 10000 op elke Leaf voor de hosts. Laten we een L2-tunnel tussen hosts opzetten

vlan 10                 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
  vn-segment 10000      ! Ассоциируем VLAN с номер VNI 

interface nve1
  member vni 10000      ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
    ingress-replication protocol bgp    ! указываем, что для распространения информации о хосте используем BGP

Laten we nu nve peers en de tabel voor BGP EVPN bekijken:

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 i

Hierboven zien we alleen routes van het EVPN-routetype 3. Bij dit type route wordt gesproken over peer (Leaf), maar waar zijn onze hosts?
Het punt is dat informatie over de MAC-hosts wordt verzonden via EVPN-routetype 2

Om onze hosts te zien, moet je EVPN-routetype 2 configureren:

evpn
  vni 10000 l2
    route-target import auto   ! в рамках данной статьи используем автоматический номер для route-target
    route-target export auto

Laten we pingen van Host-2 naar 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

En hieronder kunnen we zien dat routetype 2 met host-MAC-adres in de BGP-tabel verscheen: 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 i

Vervolgens kunt u gedetailleerde informatie over Update bekijken, waarin u informatie over de MAC Host hebt ontvangen. Hieronder vindt u niet de volledige opdrachtuitvoer.

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

Laten we eens kijken hoe frames eruit zien als ze door de fabriek worden gehaald:

VxLAN-fabriek. Deel 1

Onderdruk-ARP

Geweldig, we hebben nu L2-communicatie tussen de hosts en we konden daar eindigen. Echter, niet allemaal zo eenvoudig. Zolang we weinig hosts hebben, zullen er geen problemen zijn. Maar laten we ons een situatie voorstellen waarin we honderden en duizenden hosts hebben. Met welk probleem kunnen we te maken krijgen?

Dit probleem is BUM-verkeer (Broadcast, Unknown Unicast, Multicast). In dit artikel zullen we de mogelijkheid bekijken om met uitzendverkeer om te gaan.
De belangrijkste Broadcast-generator in Ethernet-netwerken zijn de hosts zelf via het ARP-protocol.

Nexus implementeert het volgende mechanisme om ARP-verzoeken te bestrijden: suppress-arp.
Deze functie werkt als volgt:

  1. Host-1 stuurt een APR-verzoek naar het Broadcast-adres van zijn netwerk.
  2. Het verzoek bereikt de Leaf-switch en in plaats van dit verzoek verder door te geven aan de fabric richting Host-2, reageert Leaf zelf en geeft het vereiste IP-adres en MAC aan.

Het Broadcast-verzoek ging dus niet naar de fabriek. Maar hoe kan dit werken als Leaf alleen het MAC-adres kent?

Alles is heel eenvoudig: EVPN-routetype 2 kan naast het MAC-adres een MAC/IP-combinatie verzenden. Om dit te doen, moet u een IP-adres configureren in het VLAN op Leaf. De vraag rijst: welk IP-adres moet ik instellen? Op nexus is het mogelijk om op alle schakelaars een gedistribueerd (hetzelfde) adres aan te maken:

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 mac

Vanuit het oogpunt van de hosts ziet het netwerk er dus als volgt uit:

VxLAN-fabriek. Deel 1

Laten we BGP l2route evpn controleren

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

<......>

Uit de opdrachtuitvoer kun je zien dat we in EVPN-routetype 2, naast de MAC, nu ook het host-IP-adres zien.

Laten we terugkeren naar het instellen van suppress-arp. Deze instelling wordt voor elke VNI afzonderlijk ingeschakeld:

interface nve1
  member vni 10000   
    suppress-arp

Dan ontstaat er enige complexiteit:

  • Om deze functie te laten werken, is ruimte in het TCAM-geheugen vereist. Hier is een voorbeeld van instellingen voor suppress-arp:

hardware access-list tcam region arp-ether 256

Voor deze instelling is dubbelbreed vereist. Dat wil zeggen, als u 256 instelt, moet u in TCAM 512 vrijmaken. Het instellen van TCAM valt buiten het bestek van dit artikel, aangezien het instellen van TCAM alleen afhankelijk is van de aan u toegewezen taak en kan verschillen van netwerk tot netwerk.

  • Het implementeren van suppress-arp moet op alle Leaf-schakelaars worden gedaan. Er kan echter complexiteit ontstaan ​​bij het configureren van Leaf-paren die zich in een VPC-domein bevinden. Als TCAM wordt gewijzigd, wordt de consistentie tussen paren verbroken en kan één knooppunt buiten gebruik worden gesteld. Bovendien kan het opnieuw opstarten van het apparaat nodig zijn om de TCAM-wijzigingsinstelling toe te passen.

Daarom moet u zorgvuldig overwegen of het in uw situatie de moeite waard is om deze instelling in een draaiende fabriek te implementeren.

Hiermee is het eerste deel van de serie afgesloten. In het volgende deel zullen we kijken naar routering via een VxLAN-fabric met scheiding van netwerken in verschillende VRF's.

En nu nodig ik iedereen uit gratis webinar, waarin ik je uitgebreid over de cursus vertel. De eerste 20 deelnemers die zich inschrijven voor dit webinar ontvangen binnen 1-2 dagen na de uitzending een Kortingscertificaat per e-mail.

Bron: www.habr.com

Voeg een reactie