Салом, хабр. Ман дар айни замон роҳбари курси муҳандиси шабака дар OTUS ҳастам.
Дар интизори оғози қабули нав барои курс , Ман як силсила мақолаҳоро оид ба технологияи VxLAN EVPN омода кардам.
Дар бораи чӣ гуна кор кардани VxLAN EVPN миқдори зиёди мавод мавҷуд аст, бинобар ин ман мехоҳам вазифаҳо ва таҷрибаҳои гуногунро барои ҳалли мушкилот дар маркази муосири додаҳо ҷамъ оварам.
Дар қисми якуми силсила дар технологияи VxLAN EVPN, ман мехоҳам роҳи ташкили пайвасти L2 байни ҳостҳо дар болои матоъ шабакаро бубинам.
Ҳама намунаҳо дар Cisco Nexus 9000v, ки дар топологияи Spine-Leaf ҷамъ оварда шудаанд, иҷро карда мешаванд. Мо дар ин мақола дар бораи таъсиси шабакаи Underlay таваққуф нахоҳем кард.
- Шабакаи зеризаминӣ
- Пиринг BGP барои суроға-оила l2vpn evpn
- Насб кардани NVE
- Пахш кардан-arp
Шабакаи зеризаминӣ
Топологияи истифодашуда чунин аст:
Биёед адресро дар ҳама дастгоҳҳо муқаррар кунем:
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 1Пиринг BGP
Дар ниҳоят, шумо метавонед ба танзими шабакаи Overlay гузаред.
Ҳамчун як қисми мақола, шумо бояд шабакаро байни ҳостҳо ташкил кунед, тавре ки дар диаграммаи зер нишон дода шудааст:
Барои танзим кардани шабакаи Overlay, шумо бояд BGP-ро дар коммутаторҳои Spine ва Leaf бо дастгирии оилаи l2vpn evpn фаъол созед:
feature bgp
nv overlay evpnБаъдан, ба шумо лозим аст, ки BGP-ро байни Leaf ва Spine танзим кунед. Барои содда кардани танзим ва оптимизатсияи тақсимоти иттилооти масир, мо Spine-ро ҳамчун сервери Route-Reflector танзим мекунем. Мо ҳама 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 - Vitual Tunnel End Point, дастгоҳе, ки нақби VxLAN дар он оғоз ё анҷом меёбад. VTEP ҳатман ягон дастгоҳи шабакавӣ нест. Сервере, ки технологияи VxLAN-ро дастгирӣ мекунад, метавонад ҳамчун сервер амал кунад. Дар топологияи мо, ҳама коммутаторҳои Leaf VTEP мебошанд.
VNI - Индекси шабакаи виртуалӣ - идентификатори шабака дар дохили VxLAN. Бо VLAN аналогияро метавон кашид. Бо вуҷуди ин, баъзе фарқиятҳо вуҷуд доранд. Ҳангоми истифодаи матоъ, VLANҳо танҳо дар як коммутаторҳои барг беназир мешаванд ва дар тамоми шабака интиқол дода намешаванд. Аммо ҳар як VLAN метавонад рақами VNI бо он дошта бошад, ки аллакай тавассути шабака интиқол дода мешавад. Он чӣ гуна аст ва чӣ гуна онро истифода бурдан мумкин аст, минбаъд муҳокима карда мешавад.
Биёед хусусиятро барои кор кардани технологияи 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 муттаҳид мешаванд. Ин ба мо вазъияти зеринро медиҳад:
Хост-2 як чаҳорчӯбаро ба сӯи Leaf-21 мефиристад, то онро тавассути шабака ба сӯи Хост-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Акнун биёед ҳамсолон ва ҷадвали 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-ро мебинем. Ин навъи масир дар бораи peer(Leaf) сухан меронад, аммо мизбонҳои мо дар куҷоянд?
Гап дар он аст, ки маълумот дар бораи ҳостҳои MAC тавассути EVPN хатсайри навъи 2 интиқол дода мешавад
Барои дидани мизбонҳои мо, шумо бояд EVPN хатсайри навъи 2-ро танзим кунед:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoБиёед аз 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Ва дар зер мо мебинем, ки хатсайри навъи 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
<........>Биёед бубинем, ки чорчубахо хангоми аз завод гузарондани онхо чй гуна мешаванд:
Паҳн кардан - ARP
Аҷоиб, мо ҳоло алоқаи L2 байни мизбон дорем ва мо метавонем дар он ҷо ба анҷом расонем. Бо вуҷуди ин, на ҳама он қадар оддӣ. То он даме, ки мо мизбонҳои кам дорем, ҳеҷ мушкиле нахоҳад буд. Аммо биёед вазъиятеро тасаввур кунем, ки мо садҳо ва ҳазорҳо мизбон дорем. Мо бо кадом мушкилот дучор шуда метавонем?
Ин мушкилот трафики BUM (Broadcast, Unknown Unicast, Multicast) мебошад. Дар ин мақола мо варианти мубориза бо трафики пахшро баррасӣ хоҳем кард.
Генератори асосии пахши шабакаҳои Ethernet худи ҳостҳо тавассути протоколи ARP мебошад.
Nexus механизми зеринро барои мубориза бо дархостҳои ARP амалӣ мекунад - suppress-arp.
Ин хусусият ба таври зерин кор мекунад:
- Хост-1 дархости APR-ро ба суроғаи пахши шабакаи худ мефиристад.
- Дархост ба гузариши Leaf мерасад ва ба ҷои он ки ин дархостро ба матоъ ба Хост-2 интиқол диҳад, Леф худаш посух медиҳад ва IP ва MAC-и лозимиро нишон медиҳад.
Хамин тавр, дархости Радио ба завод нарасид. Аммо ин чӣ гуна кор карда метавонад, агар Лиф танҳо суроғаи 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 анҷом дода шавад. Аммо, ҳангоми конфигуратсия кардани ҷуфтҳои Leaf, ки дар домени VPC зиндагӣ мекунанд, мушкилӣ метавонад ба миён ояд. Агар TCAM иваз карда шавад, мувофиқати байни ҷуфтҳо вайрон мешавад ва як гиреҳ метавонад аз кор хориҷ карда шавад. Илова бар ин, барои татбиқи танзимоти тағирёбии TCAM метавонад аз нав боркунии дастгоҳ талаб карда шавад.
Дар натиҷа, шумо бояд бодиққат фикр кунед, ки оё дар вазъияти шумо ин танзимотро дар як корхонаи фаъол татбиқ кардан лозим аст.
Бо ин қисми якуми силсила ба охир мерасад. Дар қисми оянда мо масирро тавассути матоъҳои VxLAN бо ҷудо кардани шабакаҳо ба VRF-ҳои гуногун дида мебароем.
Ва ҳоло ман ҳамаро ба он даъват мекунам , ки дар доираи он ман ба шумо дар бораи курс муфассал нақл мекунам. Аввалин 20 иштирокчӣ, ки дар ин вебинар сабти ном шудаанд, дар давоми 1-2 рӯз пас аз пахши он тавассути почтаи электронӣ шаҳодатномаи тахфиф мегиранд.
Манбаъ: will.com