Hej, habr. Jag är för närvarande kursledare för kursen Nätverksingenjör på OTUS.
I väntan på start av ny anmälan till kursen , Jag har förberett en serie artiklar om VxLAN EVPN-teknik.
Det finns en enorm mängd material om hur VxLAN EVPN fungerar, så jag vill samla olika uppgifter och metoder för att lösa problem i ett modernt datacenter.
I den första delen av serien om VxLAN EVPN-teknik vill jag titta på ett sätt att organisera L2-anslutning mellan värdar ovanpå ett nätverkstyg.
Alla exempel kommer att utföras på en Cisco Nexus 9000v, monterad i Spine-Leaf-topologin. Vi kommer inte att uppehålla oss vid att sätta upp ett Underlay-nätverk i den här artikeln.
- Underläggsnätverk
- BGP-peering för adressfamilj l2vpn evpn
- Konfigurera NVE
- Undertryck-arp
Underläggsnätverk
Topologin som används är följande:
Låt oss ställa in adressering på alla enheter:
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.20Låt oss kontrollera att det finns IP-anslutning mellan alla enheter:
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, intraLåt oss kontrollera att VPC-domänen har skapats och att båda switcharna har klarat konsistenskontrollen och att inställningarna på båda noderna är identiska:
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
Slutligen kan du gå vidare till att ställa in Overlay-nätverket.
Som en del av artikeln är det nödvändigt att organisera ett nätverk mellan värdar, som visas i diagrammet nedan:
För att konfigurera ett Overlay-nätverk måste du aktivera BGP på Spine och Leaf-switcharna med stöd för l2vpn evpn-familjen:
feature bgp
nv overlay evpnDärefter måste du konfigurera BGP-peering mellan Leaf och Spine. För att förenkla installationen och optimera distributionen av routinginformation konfigurerar vi Spine som en Route-Reflector-server. Vi kommer att skriva alla Leaf i konfigurationen med hjälp av mallar för att optimera inställningen.
Så inställningarna på Spine ser ut så här:
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 LEAFInställningen på Leaf-omkopplaren ser liknande ut:
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 SPINEPå Spine, låt oss kontrollera peering med alla Leaf-brytare:
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 0Som du kan se var det inga problem med BGP. Låt oss gå vidare till att ställa in VxLAN. Ytterligare konfiguration kommer endast att göras på bladsidan av switcharna. Spine fungerar bara som kärnan i nätverket och är bara involverad i att överföra trafik. Allt arbete med inkapsling och vägbestämning sker endast på bladomkopplare.
Konfigurera NVE
NVE - virtuellt nätverksgränssnitt
Innan du startar installationen, låt oss introducera lite terminologi:
VTEP - Vitual Tunnel End Point, enheten på vilken VxLAN-tunneln börjar eller slutar. VTEP är inte nödvändigtvis vilken nätverksenhet som helst. En server som stöder VxLAN-teknik kan också fungera som en server. I vår topologi är alla Leaf-switchar VTEP.
VNI - Virtual Network Index - nätverksidentifierare inom VxLAN. En analogi kan dras med VLAN. Det finns dock vissa skillnader. När du använder ett tyg blir VLAN unika endast inom en Leaf-switch och sänds inte över nätverket. Men varje VLAN kan ha ett VNI-nummer kopplat till sig, som redan överförs över nätverket. Hur det ser ut och hur det kan användas kommer att diskuteras vidare.
Låt oss aktivera funktionen för att VxLAN-tekniken ska fungera och möjligheten att associera VLAN-nummer med ett VNI-nummer:
feature nv overlay
feature vn-segment-vlan-basedLåt oss konfigurera NVE-gränssnittet, som ansvarar för driften av VxLAN. Detta gränssnitt är ansvarigt för att kapsla in ramar i VxLAN-huvuden. Du kan rita en analogi med Tunnel-gränssnittet för GRE:
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0På Leaf-21 switch skapas allt utan problem. Men om vi kontrollerar resultatet av kommandot show nve peers, då blir det tomt. Här måste du återgå till VPC-konfigurationen. Vi ser att Leaf-11 och Leaf-12 fungerar i par och förenas av en VPC-domän. Detta ger oss följande situation:
Host-2 skickar en ram mot Leaf-21 så att den sänder den över nätverket mot Host-1. Leaf-21 ser dock att MAC-adressen för Host-1 är tillgänglig via två VTEP samtidigt. Vad ska Leaf-21 göra i det här fallet? Det betyder trots allt att en loop kan dyka upp i nätverket.
För att lösa denna situation behöver vi Leaf-11 och Leaf-12 också fungera som en enhet inom fabriken. Lösningen är ganska enkel. Lägg till en sekundär adress på Loopback-gränssnittet som vi bygger tunneln från. Den sekundära adressen måste vara densamma på båda VTEP:erna.
interface loopback0
ip add 10.255.1.10/32 secondarySålunda, från andra VTEPs synvinkel, får vi följande topologi:
Det vill säga, nu kommer tunneln att byggas mellan IP-adressen för Leaf-21 och den virtuella IP-adressen mellan två Leaf-11 och Leaf-12. Nu kommer det inte att vara några problem att lära sig MAC-adressen från två enheter och trafik kan flyttas från en VTEP till en annan. Vilken av de två VTEP:erna som kommer att behandla trafiken avgörs med hjälp av routingtabellen på 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, intraSom du kan se ovan är adressen 10.255.1.10 tillgänglig omedelbart genom två Next-hops.
I detta skede har vi tagit itu med den grundläggande anslutningen. Låt oss gå vidare till att ställa in NVE-gränssnittet:
Låt oss omedelbart aktivera Vlan 10 och associera det med VNI 10000 på varje Leaf för värdarna. Låt oss sätta upp en L2-tunnel mellan värdarna
vlan 10 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
vn-segment 10000 ! Ассоциируем VLAN с номер VNI
interface nve1
member vni 10000 ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
ingress-replication protocol bgp ! указываем, что для распространения информации о хосте используем BGPLåt oss nu kolla nve peers och tabellen fö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 ! Видим что 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 iOvan ser vi bara EVPN-rutttyp 3. Denna typ av rutt talar om peer(Leaf), men var är våra värdar?
Saken är att information om MAC-värdarna överförs via EVPN-rutttyp 2
För att se våra värdar måste du konfigurera EVPN-rutttyp 2:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoLåt oss pinga från Host-2 till 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 msOch nedan kan vi se att rutttyp 2 med värd-MAC-adress dök upp i BGP-tabellen - 5001.0007.0007 och 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ärefter kan du se detaljerad information om Update, där du fick information om MAC-värden. Nedan visas inte hela kommandot.
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
<........>Låt oss se hur ramar ser ut när de passeras genom fabriken:
Undertryck-ARP
Bra, vi har nu L2-kommunikation mellan värdarna och vi kunde avsluta där. Dock inte allt så enkelt. Så länge vi har få värdar kommer det inte att vara några problem. Men låt oss föreställa oss en situation där vi har hundratals och tusentals värdar. Vilket problem kan vi möta?
Det här problemet är BUM-trafik (Broadcast, Unknown Unicast, Multicast). I den här artikeln kommer vi att överväga alternativet att hantera broadcast-trafik.
Huvudsändningsgeneratorn i Ethernet-nätverk är värdarna själva via ARP-protokollet.
Nexus implementerar följande mekanism för att bekämpa ARP-förfrågningar - suppress-arp.
Den här funktionen fungerar enligt följande:
- Host-1 skickar en APR-begäran till sändningsadressen för sitt nätverk.
- Begäran når Leaf-omkopplaren och istället för att skicka denna begäran vidare till tyget mot Host-2, svarar Leaf själv och indikerar erforderlig IP och MAC.
Således gick inte Broadcast-förfrågan till fabriken. Men hur kan detta fungera om Leaf bara känner till MAC-adressen?
Allt är ganska enkelt, EVPN-rutttyp 2, förutom MAC-adressen, kan överföra en MAC/IP-kombination. För att göra detta måste du konfigurera en IP-adress i VLAN on Leaf. Frågan uppstår, vilken IP ska jag ställa in? På nexus är det möjligt att skapa en distribuerad (samma) adress på alla switchar:
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 macFrån värdarnas synvinkel kommer nätverket att se ut så här:
Låt oss kolla 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
<......>Från kommandoutgången kan du se att i EVPN-rutttyp 2, förutom MAC, ser vi nu även värd-IP-adressen.
Låt oss återgå till att ställa in suppress-arp. Den här inställningen är aktiverad för varje VNI separat:
interface nve1
member vni 10000
suppress-arpDå uppstår en viss komplexitet:
- För att den här funktionen ska fungera krävs utrymme i TCAM-minnet. Här är ett exempel på inställningar för suppress-arp:
hardware access-list tcam region arp-ether 256Den här inställningen kräver dubbelbredd. Det vill säga om du ställer in 256 måste du frigöra 512 i TCAM. Att konfigurera TCAM ligger utanför ramen för den här artikeln, eftersom inställningen av TCAM bara beror på den uppgift som tilldelats dig och kan skilja sig från ett nätverk till ett annat.
- Implementering av suppress-arp måste göras på alla Leaf-omkopplare. Däremot kan komplexitet uppstå när man konfigurerar på Leaf-par som finns i en VPC-domän. Om TCAM ändras kommer konsistensen mellan par att brytas och en nod kan tas ur drift. Dessutom kan en omstart av enheten krävas för att tillämpa TCAM-ändringsinställningen.
Som ett resultat måste du noggrant överväga om det i din situation är värt att implementera denna inställning i en löpande fabrik.
Detta avslutar den första delen av serien. I nästa del kommer vi att titta på routing genom ett VxLAN-tyg med uppdelning av nätverk i olika VRF:er.
Och nu bjuder jag in alla , inom vilken jag kommer att berätta i detalj om kursen. De första 20 deltagarna som registrerar sig för detta webbseminarium kommer att få ett rabattcertifikat via e-post inom 1-2 dagar efter sändningen.
Källa: will.com