Прывітанне, Хабр. Працягваю цыкл артыкулаў па тэхналогіі VxLAN EVPN, якія былі напісаны спецыяльна да запуску курса ад OTUS. І сёння разгледзім цікавую частку задач - маршрутызацыю. Як бы ні банальна гэта гучала, аднак у рамках працы сеткавай фабрыкі ўсё можа быць не так проста.
У мінулай частцы мы дамагліся аднаго шырокавяшчальнага дамена, пабудаванага па-над сеткавай фабрыкай на Nexus 9000v. Аднак гэта далёка не ўвесь спектр задач, якія неабходна вырашыць у рамках сеткі ЦАД. І сёння мы разгледзім наступную задачу – маршрутызацыя паміж сеткамі ці паміж VNI.
Нагадаю, што выкарыстоўваецца тапалогія Spine-Leaf:
Для пачатку разбяром, як адбываецца маршрутызацыя і якія ёсць асаблівасці.
Для разумення спросцім лагічную схему і дадамо яшчэ адзін VNI 20000 для Host-2. У выніку атрымліваецца:
Як у такім выпадку можна перадаць трафік ад аднаго Host да іншага?
Ёсць два варыянты:
- На ўсіх Leaf камутатарах трымаць інфармацыю аб усіх VNI, тады ўся маршрутызацыя будзе адбывацца на першым жа Leaf у сетцы;
- Выкарыстоўваць спецыяльна выдзелены - L3 VNI
Першы спосаб просты і зручны. Бо патрабуецца ўсяго толькі завесці ўсе VNI на ўсе Leaf камутатары. Аднак завесці некалькі сотняў ці тысяч VNI на ўсе Leaf ужо не здаецца простай задачай. Таму ў працы ён прымяняецца даволі рэдка.
Разбярэм 2 спосаб, як цікавейшы і ледзь больш складаны, але які дае вялікую гнуткасць у наладзе фабрыкі.
Дадамо ў тапалогію VRF "PROD". У яго дадамо interface vlan 10 на пары Leaf-11/12 і interface VLAN 20 на Leaf-21. VLAN 20 асацыюем з VNI 20000
vrf context PROD
rd auto ! Route Distinguisher не принципиален и можем использовать сформированный автоматически
address-family ipv4 unicast
route-target both auto ! указываем Route-target с которым будут импортироваться и экспортироваться префиксы в/из VRF
vlan 20
vn-segment 20000
interface nve 1
member vni 20000
ingress-replication protocol bgp
interface Vlan10
no shutdown
vrf member PROD
ip address 192.168.20.1/24
fabric forwarding mode anycast-gatewayДля таго каб выкарыстоўваць L3VNI неабходна стварыць новы VLAN, асацыяваць яго з новым VNI. Новы VNI павінен быць аднолькавым на ўсіх Leaf, зацікаўленых у інфармацыі аб VLAN 10 і 20
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! Создаем L3 VNI
vrf context PROD
vni 99000 ! Привязываем L3 VNI к определенному VRFУ выніку схема будзе прадстаўляцца так:
Засталося крыху дарабіць - дадаць яшчэ адзін інтэрфейс - interface vlan 99 у VRF PROD
interface Vlan99
no shutdown
vrf member PROD
ip forward ! На интерфейсе не должно быть IP. Используется только для пересылки пакетов между LeafУ выніку логіка праходжання кадра ад Host-1 да Host-2 наступная:
- Кадр, адпраўлены Host-1 прыходзіць на Leaf у VLAN 10, які асацыіраваны з VNI 10000;
- Leaf правярае дзе знаходзіцца адрас прызначэння і знаходзіць яго праз L3 VNI на другім Leaf камутатар;
- Як толькі знойдзены маршрут да адрасу прызначэння, Leaf запакоўвае кадр у загаловак з неабходным L3VNI 99000 - і адпраўляе ў бок другога Leaf;
- Другі Leaf камутатар атрымлівае дадзеныя з L3VNI 99000. Дастае першапачатковы кадр і пераносіць яго ў неабходны L2VNI 20000 і далей у VLAN 20.
Вынікам такой працы L3VNI прыбірае неабходнасць трымаць на ўсіх Leaf камутатарах інфармацыю аб усіх VNI, якія ёсць у сетцы.
У выніку, калі адпраўляем трафік з Host-1 да Host-2 пакет запакоўваецца ўнутр VxLAN з новым VNI – 99000:
Застаецца зразумець, як менавіта Leaf-1 даведаецца пра MAC адрас з іншага VNI. Адбываецца гэта гэтак жа з дапамогай EVPN route-type 2 (MAC/IP).
Ніжэй паказаны працэс распаўсюджвання маршруту аб прэфіксе, які знаходзіцца ў іншым VNI:
Гэта значыць адрасы атрыманыя з VNI 20000 маюць два RT.
Нагадаю, што маршруты атрыманыя з Update пападаюць у табліцу BGP c Route-target, паказаным у наладах VRF (працэс некалькі складаней, аднак у рамках дадзенага артыкула паглыбляцца не будзем).
Сам RT фармуецца па формуле: AS: VNI (калі выкарыстоўваецца аўтаматычны рэжым).
Прыклад фармаванне RT у аўтаматычным і ручным рэжыме:
vrf context PROD
address-family ipv4 unicast
route-target import auto - автоматический режим работы
route-target export 65001:20000 - ручной режим формирования RTУ выніку вышэй бачна, што прэфіксы з іншага VNI маюць два значэнні RT.
Адно з іх 65001:99000 – дадатковы L3 VNI. Бо гэты VNI аднолькавы на ўсіх Leaf і пападае пад нашы правілы import у наладах VRF — прэфікс пападае ў табліцу BGP, што можна ўбачыць з высновы:
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.10 100 32768 i
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[32]:[192.168.10.10]/272
10.255.1.10 100 32768 i
*>l[3]:[0]:[32]:[10.255.1.10]/88
10.255.1.10 100 32768 i
Route Distinguisher: 10.255.1.21:32787
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]/272 ! Префикс полученный из VNI 20000
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iКалі паглядзім больш уважліва на атрыманы update, то бачна, што дадзены прэфікс мае два RT:
Leaf11# sh bgp l2vpn evpn 5001.0008.0007
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.255.1.21:32787
BGP routing table entry for [2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.2
0]/272, version 5164
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 labeled nexthop
AS-Path: NONE, path sourced internal to AS
10.255.1.20 (metric 81) from 10.255.1.102 (10.255.1.102)
Origin IGP, MED not set, localpref 100, weight 0
Received label 20000 99000 ! Два label для работы VxLAN
Extcommunity: RT:65001:20000 RT:65001:99000 SOO:10.255.1.20:0 ENCAP:8 ! Два значения Route-target, на основе, которых добавили данный префикс
Router MAC:5001.0005.0007
Originator: 10.255.1.21 Cluster list: 10.255.1.102
<......>У табліцы маршрутызацыі на Leaf-1 таксама можна назіраць прэфікс 192.168.20.20/32:
Leaf11# sh ip route vrf PROD
192.168.10.0/24, ubest/mbest: 1/0, attached
*via 192.168.10.1, Vlan10, [0/0], 01:29:28, direct
192.168.10.1/32, ubest/mbest: 1/0, attached
*via 192.168.10.1, Vlan10, [0/0], 01:29:28, local
192.168.10.10/32, ubest/mbest: 1/0, attached
*via 192.168.10.10, Vlan10, [190/0], 01:27:22, hmm
192.168.20.20/32, ubest/mbest: 1/0 ! Адрес Host-2
*via 10.255.1.20%default, [200/0], 01:20:20, bgp-65001, internal, tag 65001 ! Доступный через Leaf-2
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! Через VNI 99000Заўважылі адсутнасць асноўнага прэфікса 192.168.20.0/24 у табліцы маршрутызацыі?
Дакладна, яго там няма. Гэта значыць выдаленыя Leaf атрымліваюць інфармацыю толькі аб хастах, што ёсць у вашай сеткі. І гэтыя правільныя паводзіны. Вышэй ва ўсіх update відаць, што прыходзіць інфармацыя са зместам MAC/IP. Ні пра якія прэфіксы гаворкі не ідзе.
Гэта працуе пратакол Host Mobility Manager (HMM), які запаўняе ARP табліцу з якой далей запаўняецца BGP табліца (у рамках дадзенага артыкула апусцім гэты працэс). На аснове інфармацыі атрыманай з HMM фармуюцца EVPN route-type 2 (перадаецца MAC/IP).
Аднак, што рабіць, калі ёсць неабходнасць перадаць інфармацыю аб які-небудзь прэфіксе?
Для такога віду інфармацыі існуе EVPN route-type 5 - дазваляе перадаваць прэфіксы праз address-family l2vpn evpn (дадзены тып маршрутаў на момант напісання артыкула знаходзіцца толькі ў draft версіі , з-за гэтага ў розных вытворцаў можа адрознівацца паводзіны працы гэтага тыпу маршруту)
Для перадачы прэфіксаў, неабходна падчас BGP для VRF дадаць прэфіксы, якія будуць анансавацца:
router bgp 65001
vrf PROD
address-family ipv4 unicast
redistribute direct route-map VNI20000 ! В данном случае анонсируем префиксы подключение непосредственно к Leaf в VNI 20000
route-map VNI20000 permit 10
match ip address prefix-list VNI20000_OUT ! Указываем какой использовать prefix-list
ip prefix-list VNI20000_OUT seq 5 permit 192.168.20.0/24 ! Указываем какие сети будут попадать в EVPN route-type 5У выніку ў Update будзе:
Паглядзім табліцу BGP. Апроч EVPN route-type 2,3 з'явіліся маршруты 5 тыпу, якія ўтрымоўваюць інфармацыю аб нумары сеткі:
<......>
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:3
* i[5]:[0]:[0]:[24]:[192.168.10.0]/224
10.255.1.10 0 100 0 ?
*>i 10.255.1.10 0 100 0 ?
Route Distinguisher: 10.255.1.11:32777
* i[2]:[0]:[0]:[48]:[5001.0007.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.0007.0007]:[32]:[192.168.10.10]/272
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
* i[3]:[0]:[32]:[10.255.1.10]/88
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
Route Distinguisher: 10.255.1.12:3
*>i[5]:[0]:[0]:[24]:[192.168.10.0]/224 ! EVPN route-type 5 с номером префикса
10.255.1.10 0 100 0 ?
* i
<.......> У табліцы маршрутызацыі прэфікс таксама з'явіўся:
Leaf21# sh ip ro vrf PROD
192.168.10.0/24, ubest/mbest: 1/0
*via 10.255.1.10%default, [200/0], 00:14:32, bgp-65001, internal, tag 65001 ! Удаленный префикс, доступный через Leaf1/2(адрес Next-hop = virtual IP между парой VPC)
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN ! Префикс доступен через L3VNI 99000
192.168.10.10/32, ubest/mbest: 1/0
*via 10.255.1.10%default, [200/0], 02:33:40, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN
192.168.20.0/24, ubest/mbest: 1/0, attached
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, direct
192.168.20.1/32, ubest/mbest: 1/0, attached
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, local
192.168.20.20/32, ubest/mbest: 1/0, attached
*via 192.168.20.20, Vlan20, [190/0], 02:35:46, hmmНа гэтым скончым другую частку цыклу артыкулаў па VxLAN EVPN. У наступнай частцы разгледзім розныя варыянты маршрутызацыі паміж VRF.
Крыніца: habr.com