ProHoster > блог > адміністраванне > VxLAN фабрыка. Частка 3

VxLAN фабрыка. Частка 3

Прывітанне, Хабр. Сканчаю цыкл артыкулаў, прысвечаных запуску курса "Сеткавы інжынер" ад OTUS, па тэхналогіі VxLAN EVPN па маршрутызацыі ўнутры фабрыкі і выкарыстанні Firewall для абмежавання доступу паміж унутранымі сэрвісамі

VxLAN фабрыка. Частка 3

Папярэднія часткі цыклу можна знайсці па спасылках:

Сёння працягнем вывучаць логіку маршрутызацыі ўнутры фабрыкі VxLAN. У папярэдняй частцы мы разглядалі маршрутызацыю ўнутры фабрыкі ў рамках аднаго VRF. Аднак у сетцы можа быць велізарная колькасць сэрвісаў-кліентаў і ўсіх трэба размеркаваць у розныя VRF, для размежавання доступу паміж імі. Дадаткова да сеткавага размежавання, у бізнэса можа быць запатрабаванне падлучыць Firewall, для абмежавання доступу паміж гэтымі сэрвісамі. Так, нельга назваць гэта найлепшым рашэннем, аднак сучасныя рэаліі патрабуюць "сучасных рашэнняў".

Разгледзім два варыянты маршрутызацыі паміж VRF:

  1. Маршрутызацыя, не выходзячы з VxLAN фабрыкі;
  2. Маршрутызацыя на знешнім абсталяванні.

Пачнём з логікі маршрутызацыі паміж VRF. Ёсць пэўную колькасць VRF. Каб маршрутызаваць паміж VRF, неабходна вылучыць прыладу ў сетцы, якое будзе ведаць пра ўсе VRF (ці часткі, паміж якімі патрэбна маршрутызацыя). Такой прыладай можа стаць, напрыклад, адзін з Leaf камутатараў (ці ўсё адразу). Выглядаць такая тапалогія будзе наступным чынам:

VxLAN фабрыка. Частка 3

Якія недахопы ў такой тапалогіі?

Дакладна, кожны Leaf павінен ведаць аб усіх VRF (і ўсёй інфармацыі, што ёсць у іх) у сетцы, што вядзе да страты памяці і павышэнню нагрузкі на сетку. Бо даволі часта кожнаму Leaf камутатару не трэба ведаць пра ўсё, што ёсць у сетцы.

Аднак разгледзім такі спосаб падрабязней, бо для невялікіх сетак такі варыянт суцэль падыдзе (калі няма якія-небудзь спецыфічных патрабаванняў бізнэсу)

На гэтым моманце ў вас можа з'явіцца пытанне, як перадаваць інфармацыю з VRF у VRF, бо сэнс гэтай тэхналогіі якраз у тым, што распаўсюджванне інфармацыі павінна быць абмежавана.

І адказ крыецца ў такіх функцыях як export і import маршрутнай інфармацыі (наладку дадзенай тэхналогіі разглядалі ва 2. часткі цыкла). Коратка паўтару:

Пры заданні VRF у AF неабходна ўказаць route-target для import і export маршрутнай інфармацыі. Указаць яго можна ў аўтаматычным рэжыме. Тады ў значэнне патрапіць ASN BGP і L3 VNI, прывязаны да VRF. Гэта зручна, калі ў вас у фабрыцы выкарыстоўваецца толькі адна ASN: 

vrf context PROD20
  address-family ipv4 unicast
    route-target export auto      ! В автоматическом режиме экспортируется RT-65001:99000
    route-target import auto

Аднак калі ў вас больш адной ASN і неабходна перадаваць маршруты паміж імі, то зручнейшым і маштабаваным варыянтам будзе ручная налада. route-target. Рэкамендацыя ў ручной наладзе - першае чысло, выкарыстоўваць зручнае Вам, напрыклад, 9999.
Другое трэба зрабіць роўным VNI для гэтага VRF.

Настроім наступным чынам:

vrf context PROD10
  address-family ipv4 unicast
    route-target export 9999:99000          
    route-target import 9999:99000
    route-target import 9999:77000         ! Пример 1 import из другого VRF
    route-target import 9999:88000         ! Пример 2 import из другого VRF

Як выглядае ў табліцы маршрутызацыі:

Leaf11# sh ip route vrf prod
<.....>
192.168.20.0/24, ubest/mbest: 1/0
    *via 10.255.1.20%default, [200/0], 00:24:45, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN          ! префикс доступен через L3VNI 99000

Разгледзім другі варыянт маршрутызацыі паміж VRF – праз знешняе абсталяванне, напрыклад Firewall.

Можна выказаць здагадку некалькі варыянтаў працы праз вонкавую прыладу:

  1. Прылада ведае, што такое VxLAN, і мы можам дадаць яго ў частку фабрыкі;
  2. Прылада нічога не ведае аб VxLAN.

На першым варыянце спыняцца не будзем, бо логіка будзе практычна такая ж, як паказана вышэй – даводзім усе VRF да Firewall і на ім наладжваем маршрутызацыю паміж VRF.

Разгледзім другі варыянт, калі наш Firewall нічога не ведае аб VxLAN (цяпер, вядома, з'яўляецца абсталяванне з падтрымкай VxLAN. Напрыклад, Checkpoint анансаваў яго падтрымку ў версіі R81. Пачытаць аб гэтым можна тут, аднак гэта ўсё на стадыі тэсціравання і няма ўпэўненасці ў стабільнасці працы).

Пры падлучэнні вонкавага прылады ў нас атрымліваецца наступная схема:

VxLAN фабрыка. Частка 3

Як відаць па схеме – з'яўляецца вузкае месца на стыку з Firewall. Неабходна гэта ўлічваць у далейшым пры планаванні сеткі і аптымізацыі сеткавага трафіку.

Аднак, вернемся да першапачатковай задачы маршрутызацыі паміж VRF. У выніку дадання Firewall мы прыходзім да таго, што Firewall павінен ведаць аб усіх VRF. Для гэтага на памежных Leaf гэтак жа павінны быць наладжаны ўсе VRF, а Firewall падлучальны ў кожны VRF асобным лінкам.

У выніку схема з Firewall:

VxLAN фабрыка. Частка 3

Гэта значыць на Firewall неабходна наладзіць інтэрфейс у кожны VRF, які знаходзіцца ў сетцы. У цэлым логіка выглядае не складана і адзінае, што можа тут не падабаецца, дык гэта велізарная колькасць інтэрфейсаў на Firewall, але тут пара задумацца аб аўтаматызацыі.

Добра. Падлучылі Firewall, дадалі яго ва ўсе VRF. Але як зараз прымусіць трафік з кожнага Leaf ісці праз гэты Firewall?

На Leaf, падлучанаму да Firewall, ніякіх праблем не ўзнікне, бо ўсе маршруты лакальныя:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6w5d, static       ! маршрут по-умолчанию через Firewall

Аднак што рабіць з выдаленымі Leaf? Як перадаць ім знешні маршрут па змаўчанні?

Правільна, праз EVPN route-type 5, як і любы іншы прэфікс па VxLAN фабрыцы. Аднак з гэтым не ўсё так проста (калі мы гаворым пра cisco, як у іншых вендараў не правяраў)

Анансаваць маршрут па-змаўчанні неабходна з Leaf, да якога падлучаны Firewall. Аднак для перадачы маршруту, Leaf павінен сам яго шляхта. І тут узнікае некаторая праблема (магчыма толькі ў мяне), маршрут неабходна прапісаць статыкай у тым VRF, дзе вы жадаеце анансаваць такі маршрут:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Далей у наладзе BGP задаць гэты маршрут у AF IPv4:

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0

Аднак гэта не ўсё. Такім чынам маршрут па-змаўчанні не патрапіць у сямейства l2vpn evpn. Дадаткова да гэтага неабходна наладзіць рэдыстрыбуцыю:

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0
            redistribute static route-map COMMON_OUT

Указваем якія менавіта прэфіксы трапяць у BGP праз рэдыстрыбуцыю

route-map COMMON_OUT permit 10
  match ip address prefix-list COMMON_OUT

ip prefix-list COMMON_OUT seq 10 permit 0.0.0.0/0

Цяпер прэфікс 0.0.0.0/0 пападае ў EVPN route-type 5 і перадаецца астатнім Leaf:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.255.1.5%default, [200/0], 5w6d, bgp-65001, internal, tag 65001, segid: 99000 tunnelid: 0xaff0105 encap: VXLAN
    ! 10.255.1.5 - Виртуальный адрес Leaf(так как Leaf выступают в качестве VPС пары), к которому подключен Firewall

У табліцы BGP таксама можам назіраць атрыманы route-type 5 з маршрутам па-змаўчанні праз 10.255.1.5:

* i[5]:[0]:[0]:[0]:[0.0.0.0]/224
                      10.255.1.5                        100          0 i
*>i                   10.255.1.5                        100          0 i

На гэтым скончым цыкл артыкулаў прысвечаных EVPN. У далейшым пастараюся разгледзець працу VxLAN у звязку з Multicast, бо такі спосаб лічыцца больш які маштабуецца (на дадзены момант спрэчнае сцвярджэнне)

Калі ж у вас засталіся пытанні/прапановы на тэму, разгледзець які-небудзь функцыянал EVPN - напішыце, разгледзім дадаткова.

VxLAN фабрыка. Частка 3

Крыніца: habr.com

Дадаць каментар