Прывітанне, хабр. У цяперашні час я з'яўляюся кіраўніком курса "Сеткавы інжынер" у OTUS.
Напярэдадні старту новага набору на курс , я падрыхтаваў цыкл артыкулаў па тэхналогіі VxLAN EVPN.
Існуе мноства матэрыялаў па працы VxLAN EVPN, таму я хачу сабраць розныя задачы і практыкі рашэння задач у сучасным ЦАД.
У першай частцы цыклу па тэхналогіі VxLAN EVPN жадаю разгледзець спосаб арганізацыі L2 cвязанасці паміж хастамі па-над сеткавай фабрыкай.
Усе прыклады будзем выконваць на Cisco Nexus 9000v, сабраных у тапалогію Spine-Leaf. Спыняцца на наладзе Underlay сеткі ў рамках гэтага артыкула мы не будзем.
- Underlay сетка
- BGP пірынг для address-family l2vpn evpn
- Настройка NVE
- Supress-arp
Underlay сетка
Выкарыстоўваная тапалогія выглядае наступным чынам:
Задамо адрасаванне на ўсіх прыладах:
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 пірынг
Нарэшце можна перайсці да настройкі Overlay сеткі.
У рамках артыкула неабходна арганізаваць сетку паміж хастамі, як паказана на схеме ніжэй:
Для настройкі Overlay сеткі неабходна на Spine і Leaf камутатарах уключыць BGP з падтрымкай сямейства l2vpn evpn:
feature bgp
nv overlay evpnДалей неабходна наладзіць BGP пірынг паміж Leaf і Spine. Для спрашчэння налады і аптымізацыі распаўсюджвання маршрутнай інфармацыі Spine наладжваем у якасці Route-Reflector server. Усе 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На 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 камутатараў. Spine выступае толькі ў якасці ядра сеткі і займаюцца толькі перадачай трафіку. Уся праца па інкапсуляцыі і вызначэнні шляху адбываецца толькі на Leaf камутатарах.
Настройка NVE
NVE – network virtual interface
Перад пачаткам наладкі ўвядзем крыху тэрміналогіі:
VTEP – Vitual Tunnel End Point, прылада на якім пачынаецца або заканчваецца VxLAN тунэль. VTEP гэта не абавязкова якая-небудзь сеткавая прылада. Гэтак жа можа выступаць і сервер з падтрымкай тэхналогіі VxLAN. У нашай тапалогіі ўсе Leaf камутатары з'яўляюцца VTEP.
VNI – Virtual Network Index – ідэнтыфікатар сеткі ў рамках VxLAN. Можна правесці аналогію з VLAN. Аднак ёсць некаторыя адрозненні. Пры выкарыстанні фабрыкі, VLAN становяцца ўнікальнымі толькі ў рамках аднаго Leaf камутатара і не перадаюцца па сетцы. Але з кожным VLAN можа быць праасацыіраваны нумар VNI, які ўжо перадаецца па сетцы. Як гэта выглядае і як гэта можна выкарыстоўваць будзе разгледжана далей.
Уключым feature для працы тэхналогіі VxLAN і магчымасць асацыяваць нумары VLAN з нумарам VNI:
feature nv overlay
feature vn-segment-vlan-basedНаладзім інтэрфейс NVE, які адказвае за працу VxLAN. Дадзены інтэрфейс як раз і адказвае за інкапсуляцыю кадраў у VxLAN загалоўкі. Можна правесці аналогію з Tunnel інтэрфейсам для працы 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 з якога які будуецца тунэль, дадаем secondary адрас. Secondary адрас павінен быць аднолькавым на абодвух 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-hop.
На дадзеным этапе разабраліся з базавай звязанасцю. Пяройдзем да настройкі інтэрфейсу 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 route-type 3. Дадзены тып маршрутаў распавядае пра peer(Leaf), аднак дзе ж нашы хасты?
А справа ўсё ў тым, што інфармацыя аб MAC хастоў перадаецца праз EVPN route-type 2.
Для таго каб убачыць нашы хасты неабходна наладзіць EVPN route-type 2:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoЗробім ping з Host-2 на 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І ніжэй мы можам бачыць, што ў табліцы BGP з'явіліся route-type 2 c MAC адрасам хастоў – 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Далей можна паглядзець падрабязную інфармацыю па Update, у якім атрымалі інфармацыю аб MAC Host. Ніжэй прадстаўлены не ўся выснова каманды
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 (Broadcast, Unknown Unicast, Multicast) трафік. У рамках гэтага артыкула разгледзім варыянт дужання з broadcast трафікам.
Асноўны генератар Broadcast у Ethernet сетках самі хасты праз пратакол ARP.
На nexus рэалізаваны наступны механізм для барацьбы з ARP запытамі – suppress-arp.
Праца дадзенай фічы выглядае наступным чынам:
- Host-1 адпраўляе APR запыт на Broadcast адрас сваёй сеткі.
- Запыт даходзіць да Leaf камутатара і замест таго каб перадаць гэты запыт далей у фабрыку ў бок Host-2 – Leaf адказвае сам і паказвае патрэбны IP і MAC.
Такім чынам Broadcast запыт не сышоў у фабрыку. Але як гэта можа працаваць, калі Leaf ведае толькі адрас MAC?
Усё даволі проста, EVPN route-type 2 апроч MAC адрасы можа перадаваць звязак MAC/IP. Для гэтага на Leaf неабходна наладзіць IP адрас у VLAN. Узнікае пытанне, які 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 route-type 2 апроч MAC зараз бачым яшчэ і IP адрас хаста.
Вяртаемся да наладкі suppress-arp. Уключаецца гэтая настройка для кожнага VNI асобна:
interface nve1
member vni 10000
suppress-arpДалей узнікае некаторая складанасць:
- Для працы дадзенай фічы неабходна месца ў TCAM памяці. Прывяду прыклад наладкі для suppress-arp:
hardware access-list tcam region arp-ether 256Для дадзенай наладкі запатрабуецца double-wide. Гэта значыць калі задаяце 256, то ў TCAM неабходна вызваліць 512. Налада TCAM выходзіць за межы дадзенага артыкула, бо налада TCAM залежыць толькі ад задачы пастаўленай перад Вамі і можа адрознівацца ад адной сеткі да іншай.
- Укараненне suppress-arp неабходна зрабіць на ўсіх Leaf камутатарах. Аднак складанасць можа паўстаць пры наладзе на парах Leaf, змешчаных у дамене VPC. Пры змене TCAM, кансістэнцыя паміж парамі будзе парушана і адна нода можа быць выведзена з працы. Дадаткова для ўжывання налады змене TCAM можа запатрабавацца перазагрузка прылады.
У выніку трэба як след падумаць, ці варта ў вашай сітуацыі ўкараніць дадзеную наладу на працуючую фабрыку.
На гэтым скончым першую частку цыклу. У наступнай частцы разгледзім маршрутызацыю праз VxLAN фабрыку з падзелам сетак па розных VRF.
А зараз запрашаю ўсіх на , у рамках якога я падрабязна раскажу пра курс. Першыя 20 удзельнікаў, якія зарэгістраваліся на гэты вэбінар, атрымаюць Сертыфікат на скідку на электронную пошту на працягу 1-2 дзён пасля трансляцыі.
Крыніца: habr.com