Hallo, Habr. Momenteel ben ik de cursusleider van "Netwerkingenieur" bij OTUS.
In de aanloop naar de start van een nieuwe groep voor de cursus , ik heb een serie artikelen voorbereid over de VxLAN EVPN-technologie.
Er is een enorme hoeveelheid materiaal beschikbaar over het werken met VxLAN EVPN, daarom wil ik verschillende taken en praktijken voor het oplossen van taken in een modern datacenter verzamelen.
In het eerste deel van de serie over de VxLAN EVPN-technologie wil ik de manier waarop L2-connectiviteit tussen hosts bovenop een netwerkstructuur wordt georganiseerd, bekijken.
Alle voorbeelden worden uitgevoerd op Cisco Nexus 9000v, opgebouwd in een Spine-Leaf-topologie. We zullen in dit artikel niet stilstaan bij de configuratie van het Underlay-netwerk.
- Underlay-netwerk
- BGP-peering voor address-family l2vpn evpn
- NVE-configuratie
- Supress-arp
Underlay-netwerk
De gebruikte topologie ziet er als volgt uit:
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.20Laten 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 is bereikbaar via twee 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 is bereikbaar via twee 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, intraLaten we controleren of het VPC-domein is aangemaakt en of beide switches de consistentietoets hebben doorstaan en de configuraties op beide knooppunten identiek zijn:
Leaf11# show vpc
vPC domein-ID : 1
Peer-status : peer-adjacency gevormd ok
vPC keep-alive-status : peer is actief
Configuratieconsistentie-status : succes
Per-vlan consistentie-status : succes
Type-2 consistentie-status : succes
vPC-rol : primair
Aantal geconfigureerde vPC's : 0
Peer-gateway : Uitgeschakeld
Dual-active uitgesloten VLAN's : -
Graceful Consistency Check : Ingeschakeld
Auto-recovery status : Uitgeschakeld
Delay-restore status : Timer staat uit.(timeout = 30s)
Delay-restore SVI-status : Timer staat uit.(timeout = 10s)
Operationele Layer3 Peer-router : Uitgeschakeld
vPC-status
----------------------------------------------------------------------------
Id Poort Status Consistentiereden Actieve vlans
-- ------------ ------ ----------- ------ ---------------
5 Po5 up success success 1BGP-peering
Ten slotte kunnen we overgaan tot de configuratie van het Overlay-netwerk.
In dit artikel moet er een netwerk tussen de hosts worden georganiseerd, zoals weergegeven in het onderstaande schema:
Voor de configuratie van het Overlay-netwerk moeten BGP met ondersteuning voor het l2vpn evpn-gezin worden ingeschakeld op de Spine- en Leaf-switches:
feature bgp
nv overlay evpnVervolgens moet BGP-peering tussen Leaf en Spine worden ingesteld. Om de configuratie te vereenvoudigen en de distributie van route-informatie te optimaliseren, configureren we Spine als Route-Reflector-server. We zullen alle Leaf-configuraties via sjablonen in de configuratie opnemen om de configuratie te optimaliseren.
Zo ziet de configuratie op Spine eruit:
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 configuratie op de Leaf-switch ziet er vergelijkbaar 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 SPINEOp Spine controleren we het peering met alle Leaf-switches:
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 0Zoals we zien, zijn er geen problemen met BGP. Laten we verder gaan met de configuratie van VxLAN. De verdere configuratie zal alleen aan de zijde van de Leaf-switches plaatsvinden. Spine fungeert alleen als de kern van het netwerk en houdt zich uitsluitend bezig met het doorsturen van verkeer. Al het werk met encapsulatie en padbepaling vindt uitsluitend plaats op de Leaf-switches.
NVE-configuratie
NVE ā network virtual interface
Voor we met de configuratie beginnen, introduceren we een beetje terminologie:
VTEP ā Virtual Tunnel End Point, een apparaat waar de VxLAN-tunnel begint of eindigt. Een VTEP hoeft niet per se een netwerkapparaat te zijn. Het kan ook een server zijn die de VxLAN-technologie ondersteunt. In onze topologie zijn alle Leaf-switches VTEP.
VNI ā Virtual Network Index ā een netwerkidentificatienummer binnen VxLAN. Het kan worden vergeleken met VLAN. Er zijn echter enkele verschillen. Bij gebruik van een fabriek worden VLAN's uniek binnen Ć©Ć©n Leaf-switch en worden ze niet over het netwerk verzonden. Maar aan elke VLAN kan een VNI-nummer worden gekoppeld, dat wel over het netwerk wordt verzonden. Hoe dit eruitziet en hoe dit kan worden gebruikt, zal later worden besproken.
Laten we de functie inschakelen voor het werken met de VxLAN-technologie en de mogelijkheid om VLAN-nummers te koppelen aan VNI-nummers:
feature nv overlay
feature vn-segment-vlan-basedWe will configure the NVE interface, which is responsible for the operation of VxLAN. This interface is specifically responsible for encapsulating frames in VxLAN headers. A comparison can be made with a Tunnel interface for GRE operation:
interface nve1
no shutdown
host-reachability protocol bgp ! using BGP for route information transmission
source-interface loopback0 ! interface from which we send packets loopback0On Leaf-21, the switch is created without problems. However, if we check the output of the command show nve peers, it will be empty. Here it is necessary to return to the VPC configuration. We see that Leaf-11 and Leaf-12 are operating in pairs and are joined by the VPC domain. This results in the following situation:
Host-2 sends a frame towards Leaf-21, so that it can transmit it over the network towards Host-1. However, Leaf-21 sees that the MAC address of Host-1 is available through two VTEPs. How should Leaf-21 handle this case? This means that a loop may have appeared in the network.
To resolve this situation, we need Leaf-11 and Leaf-12 to act as a single device within the fabric. This is solved quite simply. On the Loopback interface from which we build the tunnel, we add a secondary address. The secondary address must be the same on both VTEPs.
interface loopback0
ip add 10.255.1.10/32 secondaryThus, from the perspective of other VTEPs, we get the following topology:
Now the tunnel will be built between the IP address of Leaf-21 and the virtual IP between the two Leaf-11 and Leaf-12. Now there will be no issues figuring out the MAC address from the two devices, and traffic can switch from one VTEP to another. Which of the two VTEPs will handle the traffic is determined using the routing table on the 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, intraAs seen above, the address 10.255.1.10 is accessible through two Next-hops.
At this stage, we have understood the basic connectivity. Letās move on to the configuration of the NVE interface:
We will immediately enable VLAN 10 and associate it with VNI 10000 on each Leaf for hosts. We will configure an L2 tunnel between the hosts.
vlan 10 ! Schakel VLAN in op alle VTEP's verbonden met de vereiste hosts
vn-segment 10000 ! Koppel VLAN aan VNI-nummer
interface nve1
member vni 10000 ! Voeg VNI 10000 toe voor werking via de NVE-interface, voor encapsulatie in VxLAN
ingress-replication protocol bgp ! Geef aan dat we BGP gebruiken voor het verspreiden van informatie over de hostLaten we nu de nve peers en de tabel voor BGP EVPN controleren:
Leaf21# sh nve peers
Interface Peer-IP State LearnType Uptime Router-Mac
--------- --------------- ----- --------- -------- -----------------
nve1 10.255.1.10 Up CP 00:00:41 n/a ! We zien dat de peer beschikbaar is vanaf het secundaire adres
Leaf11# sh bgp l2vpn evpn
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000) ! Van wie is deze l2VNI afkomstig
*>l[3]:[0]:[32]:[10.255.1.10]\/88 ! EVPN route-type 3 - toont onze buur, die ook weet van 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 iHierboven zien we alleen EVPN route-type 3 routes. Dit type routes vertelt over de peer (Leaf), maar waar zijn onze hosts?
Het probleem is dat de informatie over de MAC-adressen van de hosts wordt verzonden via EVPN route-type 2.
Om onze hosts te zien, moeten we EVPN route-type 2 configureren:
evpn
vni 10000 l2
route-target import auto ! In dit artikel gebruiken we een automatisch nummer voor route-target
route-target export autoLaten we een ping uitvoeren 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 van 192.168.10.2: Bestemmingshost onbereikbaar
Verzoek 0 timed out
64 bytes van 192.168.10.1: icmp_seq=1 ttl=254 tijd=215.555 ms
64 bytes van 192.168.10.1: icmp_seq=2 ttl=254 tijd=38.756 ms
64 bytes van 192.168.10.1: icmp_seq=3 ttl=254 tijd=42.484 ms
64 bytes van 192.168.10.1: icmp_seq=4 ttl=254 tijd=40.983 msEn hieronder kunnen we zien dat route-type 2 met MAC-adressen van hosts ā 5001.0007.0007 en 5001.0008.0007 is verschenen in de BGP-tabel.
Leaf11# sh bgp l2vpn evpn
Netwerk Volgende Hop Metric LocPrf Gewicht Pad
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 en MAC-adres van host 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 en MAC-adres van host 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 iHier kunnen we meer gedetailleerde informatie bekijken over de Update, waar we informatie hebben ontvangen over MAC Host. Hieronder is niet alle uitvoer van de opdracht weergegeven
Leaf21# sh bgp l2vpn evpn 5001.0007.0007
BGP-routeringstabelinformatie voor VRF standaard, adresfamilie L2VPN EVPN
Route Distinguisher: 10.255.1.11:32777 ! verzond Update met MAC Host. Geen virtueel VPC-adres, maar het adres van de Leaf
BGP-routeringstabelvermelding voor [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]\/216,
versie 1507
Paden: (2 beschikbaar, beste #2)
Vlaggen: (0x000202) (high32 00000000) op xmit-lijst, niet in l2rib\/evpn, is niet in HW
Padtype: intern, pad is geldig, niet beste reden: Buuradres, geen gelabeld nexthop
AS-Pad: NONE, pad is afkomstig uit intern AS
10.255.1.10 (metric 81) van 10.255.1.102 (10.255.1.102) ! met wie we precies de VxLAN-tunnel bouwen
Oorsprong IGP, MED niet ingesteld, localpref 100, gewicht 0
Ontvangen label 10000 ! Nummer VNI dat is geassocieerd met VLAN waarin de Host zich bevindt
Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8 ! Hier zien we dat RT automatisch is gevormd op basis van AS-nummers en VNI
Oorspronker: 10.255.1.11 Clusterlijst: 10.255.1.102Laten we kijken hoe de frames eruit zien wanneer ze door de fabriek worden verzonden:
Suppress-ARP
Geweldig, de L2-verbinding tussen de hosts is tot stand gekomen en we zouden hier kunnen stoppen. Maar het is niet zo eenvoudig. Terwijl we weinig hosts hebben, zullen er geen problemen optreden. Maar laten we ons scenario voorstellen waarin we honderden of duizenden hosts hebben. Met welke problemen kunnen we geconfronteerd worden?
Dit probleem is BUM (Broadcast, Unknown Unicast, Multicast) verkeer. In dit artikel zullen we een optie onderzoeken om broadcast verkeer te bestrijden.
De belangrijkste generator van Broadcast in Ethernet-netwerken zijn de hosts zelf via het ARP-protocol.
Op de nexus is de volgende mechanismen geĆÆmplementeerd om ARP-verzoeken te bestrijden ā suppress-arp.
De werking van deze functie ziet er als volgt uit:
- Host-1 verzendt een ARP-verzoek naar het broadcastadres van zijn netwerk.
- Het verzoek bereikt de Leaf-switch en in plaats van het verzoek verder naar de fabriek te sturen richting Host-2 ā beantwoordt Leaf zelf en geeft het gewenste IP en MAC aan.
Dus is de Broadcast-aanroep niet naar de fabric gestuurd. Maar hoe kan dit werken als de Leaf alleen het MAC-adres kent?
Het is eigenlijk heel eenvoudig, EVPN route-type 2 kan naast het MAC-adres ook een MAC/IP-koppeling doorgeven. Hiervoor moet een IP-adres in de VLAN op de Leaf worden ingesteld. De vraag is, welk IP moet worden toegewezen? Op de Nexus is het mogelijk om een gedistribueerd (identiek) adres op alle switches te creƫren:
feature interface-vlan
fabric forwarding anycast-gateway-mac 0001.0001.0001 ! stel een virtual MAC in voor het creƫren van een gedistribueerde gateway tussen alle switches
interface Vlan10
no shutdown
ip address 192.168.10.254/24 ! wijs op alle Leaf switches hetzelfde IP toe
fabric forwarding mode anycast-gateway ! geef aan om Virtual MAC te gebruikenDus vanuit het perspectief van de hosts zal het netwerk er als volgt uitzien:
Laten we BGP l2route evpn controleren
Leaf11# sh bgp l2vpn evpn
Netwerk Volgende Hop Metriek LocPrf Gewicht Pad
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 iUit de output van de opdracht blijkt dat we in EVPN route-type 2, naast de MAC, nu ook het IP-adres van de host zien.
Laten we terugkeren naar de configuratie van suppress-arp. Deze instelling wordt voor elk VNI afzonderlijk ingeschakeld:
interface nve1
member vni 10000
suppress-arpDaarna ontstaat er een bepaalde complexiteit:
- Voor het functioneren van deze feature is ruimte in het TCAM-geheugen vereist. Ik geef een voorbeeld van de configuratie voor suppress-arp:
hardware access-list tcam region arp-ether 256Voor deze instelling is double-wide vereist. Dit betekent dat als je 256 instelt, je 512 in TCAM moet vrijmaken. De TCAM-configuratie valt buiten het bestek van dit artikel, aangezien de TCAM-configuratie alleen afhankelijk is van de taak die je hebt gesteld en kan verschillen van het ene netwerk naar het andere.
- De implementatie van suppress-arp moet op alle Leaf-switches worden uitgevoerd. Er kan echter complicatie optreden bij de configuratie op paren Leaf binnen het VPC-domein. Bij wijziging van TCAM kan de consistentie tussen de paren worden verstoord en kan Ć©Ć©n node uitvallen. Bovendien kan een herstart van het apparaat noodzakelijk zijn om de instellingen voor de wijziging van TCAM toe te passen.
Daarom is het belangrijk om goed na te denken of het in uw situatie zinvol is om deze instelling op een operationele fabriek door te voeren.
Hiermee eindigen we het eerste deel van de cyclus. In het volgende deel zullen we de routering via de VxLAN-fabriek bekijken met netwerkscheiding via verschillende VRF's.
En nu nodig ik iedereen uit voor , waar ik uitgebreid uitleg zal geven over de cursus. De eerste 20 deelnemers die zich registreren voor dit webinar, ontvangen een kortingcertificaat op hun e-mail binnen 1-2 dagen na de uitzending.
Bron: habr.com
