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
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.
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.
- Onderliggend netwerk
- BGP-peering voor adresfamilie l2vpn evpn
- NVE opzetten
- Onderdrukken-arp
Onderliggend netwerk
De gebruikte topologie is als volgt:
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:
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:
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:
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:
- Host-1 stuurt een APR-verzoek naar het Broadcast-adres van zijn netwerk.
- 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:
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
Bron: www.habr.com