Здраво, Хабр. Моментално сум лидер на курсот за курсот Мрежен инженер во OTUS.
Во пресрет на почеток на нови уписи за курсот , подготвив серија статии за VxLAN EVPN технологијата.
Има огромно количество материјал за тоа како работи VxLAN EVPN, па затоа сакам да соберам различни задачи и практики за решавање проблеми во модерен центар за податоци.
Во првиот дел од серијата за VxLAN EVPN технологијата, сакам да погледнам начин да се организира L2 поврзување помеѓу домаќините на врвот на мрежна ткаенина.
Сите примери ќе се изведуваат на Cisco Nexus 9000v, склопен во топологијата Spine-Leaf. Во овој напис нема да се задржиме на поставување мрежа на Underlay.
- Подлога мрежа
- BGP peering за адреса-семејство l2vpn evpn
- Поставување на NVE
- Потиснете-арп
Подлога мрежа
Користената топологија е како што следува:
Ајде да поставиме адресирање на сите уреди:
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Ајде да провериме дали има IP конекција помеѓу сите уреди:
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Ајде да провериме дали доменот VPC е создаден и двата прекинувачи ја поминале проверката на конзистентноста и поставките на двата јазли се идентични:
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
Конечно, можете да продолжите со поставувањето на мрежата за преклопување.
Како дел од статијата, неопходно е да се организира мрежа помеѓу домаќините, како што е прикажано на дијаграмот подолу:
За да конфигурирате мрежа за преклопување, треба да овозможите BGP на прекинувачите 'Рбет и Лист со поддршка за семејството l2vpn evpn:
feature bgp
nv overlay evpnСледно, треба да го конфигурирате BGP peering помеѓу Leaf и Spine. За да го поедноставиме поставувањето и да ја оптимизираме дистрибуцијата на информации за насочување, го конфигурираме Spine како сервер за рефлектори на маршрутата. Ќе ги напишеме сите Leaf во конфигурацијата користејќи шаблони за да го оптимизираме поставувањето.
Значи, поставките на Spine изгледаат вака:
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Поставувањето на прекинувачот Leaf изгледа слично:
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На 'рбетот, ајде да го провериме ѕиркањето со сите прекинувачи 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Како што можете да видите, немаше проблеми со BGP. Ајде да продолжиме со поставувањето на VxLAN. Понатамошната конфигурација ќе се врши само на Лист страна на прекинувачите. 'Рбетот делува само како јадро на мрежата и е вклучен само во пренос на сообраќај. Целата работа со инкапсулација и одредување на патеката се случува само на прекинувачите Leaf.
Поставување на NVE
NVE - мрежен виртуелен интерфејс
Пред да започнеме со поставувањето, да воведеме некоја терминологија:
VTEP - Крајна точка на витуален тунел, уред на кој започнува или завршува тунелот VxLAN. VTEP не е нужно каков било мрежен уред. Сервер кој поддржува VxLAN технологија може да дејствува и како сервер. Во нашата топологија, сите прекинувачи на Leaf се VTEP.
VNI - Индекс на виртуелна мрежа - мрежен идентификатор во рамките на VxLAN. Може да се направи аналогија со VLAN. Сепак, постојат некои разлики. Кога користите ткаенина, VLAN-овите стануваат единствени само во рамките на еден прекинувач Leaf и не се пренесуваат низ мрежата. Но, секој VLAN може да има VNI број поврзан со него, кој веќе се пренесува преку мрежата. Како изгледа и како може да се користи ќе се дискутира понатаму.
Ајде да ја овозможиме функцијата за работа на технологијата VxLAN и можноста за поврзување VLAN броеви со VNI број:
feature nv overlay
feature vn-segment-vlan-basedАјде да го конфигурираме интерфејсот NVE, кој е одговорен за работата на VxLAN. Овој интерфејс е одговорен за инкапсулирање на рамки во заглавијата на VxLAN. Можете да нацртате аналогија со интерфејсот на тунелот за GRE:
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0На прекинувачот Leaf-21 сè е создадено без проблеми. Меѓутоа, ако го провериме излезот од командата show nve peers, тогаш ќе биде празен. Тука треба да се вратите на конфигурацијата VPC. Гледаме дека Leaf-11 и Leaf-12 работат во парови и се обединети со VPC домен. Ова ни ја дава следната ситуација:
Host-2 испраќа една рамка кон Leaf-21, така што ја пренесува преку мрежата кон Host-1. Сепак, Leaf-21 гледа дека MAC адресата на Host-1 е достапна преку два VTEP одеднаш. Што треба да направи Leaf-21 во овој случај? На крајот на краиштата, ова значи дека може да се појави јамка во мрежата.
За да ја решиме оваа ситуација, потребни ни се Leaf-11 и Leaf-12 да дејствуваат како еден уред во фабриката. Решението е прилично едноставно. На интерфејсот Loopback од кој го градиме тунелот, додадете секундарна адреса. Секундарната адреса мора да биде иста на двата VTEP.
interface loopback0
ip add 10.255.1.10/32 secondaryТака, од гледна точка на другите VTEP, ја добиваме следнава топологија:
Односно, сега тунелот ќе биде изграден помеѓу IP адресата на Leaf-21 и виртуелната IP помеѓу два Leaf-11 и Leaf-12. Сега нема да има проблеми со учењето на MAC адресата од два уреди и сообраќајот може да се движи од еден VTEP на друг. Кој од двата VTEP ќе го обработи сообраќајот се одлучува со помош на рутирачката табела на 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Како што можете да видите погоре, адресата 10.255.1.10 е достапна веднаш преку два Next-hops.
Во оваа фаза се занимававме со основната поврзаност. Ајде да продолжиме со поставување на интерфејсот NVE:
Веднаш да го овозможиме Vlan 10 и да го поврземе со VNI 10000 на секој Leaf за домаќините. Ајде да поставиме тунел L2 помеѓу домаќините
vlan 10 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
vn-segment 10000 ! Ассоциируем VLAN с номер VNI
interface nve1
member vni 10000 ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
ingress-replication protocol bgp ! указываем, что для распространения информации о хосте используем BGPСега да ги провериме nve peers и табелата за 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 iПогоре гледаме само рути EVPN-тип 3. Овој тип на рута зборува за peer(Leaf), но каде се нашите домаќини?
Работата е дека информациите за MAC-домаќините се пренесуваат преку EVPN рута-тип 2
За да ги видите нашите домаќини, треба да го конфигурирате EVPN рута-тип 2:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoАјде да пингуваме од Домаќин-2 до Домаќин-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И подолу можеме да видиме дека рутата-тип 2 со MAC адреса на домаќинот се појави во табелата BGP - 5001.0007.0007 и 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Следно, можете да видите детални информации за Ажурирање, во кое добивте информации за MAC-домаќинот. Подолу не е целиот излез на командата.
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
<........>Ајде да видиме како изгледаат рамки кога се пропуштаат низ фабриката:
Suppress-ARP
Одлично, сега имаме L2 комуникација меѓу домаќините и би можеле да завршиме таму. Сепак, не се толку едноставно. Се додека имаме малку домаќини нема да има проблеми. Но, да замислиме ситуација кога имаме стотици и илјадници домаќини. Со каков проблем би можеле да се соочиме?
Овој проблем е сообраќајот BUM (Емитување, Непознат уникаст, Мултикаст). Во оваа статија, ќе ја разгледаме опцијата за справување со преносниот сообраќај.
Главниот генератор на емитување во етернет мрежите се самите домаќини преку протоколот ARP.
Nexus го имплементира следниов механизам за борба против ARP барањата - suppress-arp.
Оваа функција работи на следниов начин:
- Домаќинот-1 испраќа барање за APR до адресата за емитување на неговата мрежа.
- Барањето стигнува до прекинувачот Leaf и наместо да го пренесе ова барање понатаму до ткаенината кон Host-2, Leaf сам одговара и ги покажува потребните IP и MAC.
Така, барањето за Емитување не отиде во фабриката. Но, како може ова да функционира ако Leaf ја знае само MAC адресата?
Сè е прилично едноставно, EVPN рута-тип 2, покрај MAC адресата, може да пренесе и комбинација MAC/IP. За да го направите ова, треба да конфигурирате IP адреса во VLAN на Leaf. Се поставува прашањето, каква IP да поставам? На nexus е можно да се креира дистрибуирана (иста) адреса на сите прекинувачи:
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Така, од гледна точка на домаќините, мрежата ќе изгледа вака:
Ајде да провериме 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
<......>Од командниот излез можете да видите дека во EVPN рута-тип 2, покрај MAC, сега ја гледаме и IP адресата на домаќинот.
Да се вратиме на поставувањето suppress-arp. Оваа поставка е овозможена за секој VNI посебно:
interface nve1
member vni 10000
suppress-arpТогаш се појавува одредена сложеност:
- За да функционира оваа функција, потребен е простор во TCAM меморијата. Еве пример за поставки за suppress-arp:
hardware access-list tcam region arp-ether 256За оваа поставка ќе биде потребна двојна ширина. Односно, ако поставите 256, тогаш треба да ослободите 512 во TCAM. Поставувањето TCAM е надвор од опсегот на овој напис, бидејќи поставувањето на TCAM зависи само од задачата што ви е доделена и може да се разликува од една до друга мрежа.
- Спроведувањето на suppress-arp мора да се направи на сите прекинувачи Leaf. Сепак, може да настане сложеност при конфигурирање на парови на листови кои живеат во домен VPC. Ако TCAM се смени, конзистентноста помеѓу паровите ќе се прекине и еден јазол може да се извади од работа. Дополнително, може да биде потребно рестартирање на уредот за да се примени поставката за промена на TCAM.
Како резултат на тоа, треба внимателно да размислите дали, во вашата ситуација, вреди да се имплементира оваа поставка во фабрика која работи.
Ова го завршува првиот дел од серијата. Во следниот дел ќе разгледаме рутирање низ VxLAN ткаенина со раздвојување на мрежите во различни VRFs.
И сега ги поканувам сите да , во чии рамки ќе ви кажам детално за курсот. Првите 20 учесници кои ќе се пријават за овој вебинар ќе добијат сертификат за попуст преку е-пошта во рок од 1-2 дена по емитувањето.
Извор: www.habr.com