ПроХостер > блог > Администрација > ВкЛАН фабрика. Део 3

ВкЛАН фабрика. Део 3

Здраво, Хабр. Завршавам серију чланака, посвећен покретању курса "Инжењер мреже" би ОТУС, користећи ВкЛАН ЕВПН технологију за рутирање унутар структуре и користећи заштитни зид за ограничавање приступа између интерних услуга

ВкЛАН фабрика. Део 3

Претходне делове серијала можете пронаћи на следећим линковима:

Данас ћемо наставити да проучавамо логику рутирања унутар ВкЛАН тканине. У претходном делу, погледали смо интра-фабриц рутирање унутар једног ВРФ-а. Међутим, може постојати огроман број клијентских услуга у мрежи и сви они морају бити распоређени у различите ВРФ-ове да би се разликовао приступ између њих. Поред раздвајања мреже, предузеће ће можда морати да повеже заштитни зид да би ограничило приступ између ових услуга. Да, ово се не може назвати најбољим решењем, али савремена реалност захтева „модерна решења“.

Хајде да размотримо две опције за рутирање између ВРФ-ова:

  1. Рутирање без напуштања ВкЛАН тканине;
  2. Рутирање на спољној опреми.

Почнимо са логиком рутирања између ВРФ-ова. Постоји одређени број ВРФ-ова. Да бисте рутирали између ВРФ-ова, потребно је да изаберете уређај у мрежи који ће знати за све ВРФ-ове (или делове између којих је потребно рутирање). Такав уређај може бити, на пример, један од Леаф прекидача (или све одједном) . Ова топологија ће изгледати овако:

ВкЛАН фабрика. Део 3

Који су недостаци ове топологије?

Тако је, сваки Леаф треба да зна за све ВРФ-ове (и све информације које се налазе у њима) на мрежи, што доводи до губитка меморије и повећаног оптерећења мреже. На крају крајева, често сваки Леаф прекидач не мора да зна о свему што је на мрежи.

Међутим, размотримо овај метод детаљније, јер је за мале мреже ова опција сасвим прикладна (ако нема посебних пословних захтева)

У овом тренутку можете имати питање како да пренесете информације са ВРФ на ВРФ, јер је поента ове технологије управо у томе да се ширење информација ограничи.

А одговор лежи у функцијама као што су извоз и увоз информација о рутирању (подешавање ове технологије је разматрано у други делови циклуса). Да поновим укратко:

Када постављате ВРФ у АФ, морате навести route-target за информације о рутирању увоза и извоза. Можете га одредити аутоматски. Тада ће вредност укључивати АСН БГП и Л3 ВНИ повезане са ВРФ-ом. Ово је згодно када имате само један АСН у својој фабрици: 

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

Међутим, ако имате више од једног АСН-а и морате да преносите руте између њих, онда ће ручна конфигурација бити погоднија и скалабилнија опција route-target. Препорука за ручно подешавање је први број, користите онај који вам одговара, нпр. 9999.
Други треба да буде једнак ВНИ за тај ВРФ.

Хајде да га конфигуришемо на следећи начин:

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

Хајде да размотримо другу опцију за рутирање између ВРФ-ова - преко спољне опреме, на пример Фиревалл-а.

Постоји неколико опција за рад преко спољног уређаја:

  1. Уређај зна шта је ВкЛАН и можемо га додати у део тканине;
  2. Уређај не зна ништа о ВкЛАН-у.

Нећемо се задржавати на првој опцији, пошто ће логика бити скоро иста као што је приказано изнад - доводимо све ВРФ-ове у заштитни зид и на њему конфигуришемо рутирање између ВРФ-ова.

Хајде да размотримо другу опцију, када наш заштитни зид не зна ништа о ВкЛАН (сада се, наравно, појављује опрема са ВкЛАН подршком. На пример, Цхецкпоинт је најавио своју подршку у верзији Р81. Можете прочитати о томе овде, међутим, ово је све у фази тестирања и нема поверења у стабилност рада).

Када повежемо спољни уређај, добијамо следећи дијаграм:

ВкЛАН фабрика. Део 3

Као што можете видети из дијаграма, уско грло се појављује на интерфејсу са заштитним зидом. Ово се мора узети у обзир у будућности приликом планирања мреже и оптимизације мрежног саобраћаја.

Међутим, вратимо се првобитном проблему рутирања између ВРФ-ова. Као резултат додавања заштитног зида, долазимо до закључка да заштитни зид мора знати за све ВРФ-ове. Да бисте то урадили, сви ВРФ-ови такође морају бити конфигурисани на граничним листовима, а заштитни зид мора бити повезан са сваким ВРФ-ом са посебном везом.

Као резултат, шема са заштитним зидом:

ВкЛАН фабрика. Део 3

То јест, на заштитном зиду морате да конфигуришете интерфејс за сваки ВРФ који се налази на мрежи. Генерално, логика не изгледа компликована и једино што ми се овде не свиђа је огроман број интерфејса на заштитном зиду, али овде је време да размислите о аутоматизацији.

У реду. Повезали смо заштитни зид и додали га свим ВРФ-овима. Али како сада можемо натерати саобраћај са сваког листа да прође кроз овај заштитни зид?

На Леаф-у који је повезан са заштитним зидом, неће се појавити никакви проблеми, пошто су све руте локалне:

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

Међутим, шта је са удаљеним листовима? Како им проследити подразумевану спољну руту?

Тако је, преко ЕВПН руте типа 5, као и сваки други префикс преко ВкЛАН тканине. Међутим, ово није тако једноставно (ако говоримо о Цисцо-у, јер нисам проверио код других добављача)

Подразумевана рута се мора оглашавати са листа на који је повезан заштитни зид. Међутим, да би пренео руту, Леаф мора сам да је познаје. И ту се јавља одређени проблем (можда само за мене), рута мора бити статички регистрована у ВРФ-у где желите да оглашавате такву руту:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Затим, у БГП конфигурацији, поставите ову руту у АФ ИПв4:

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

Назначавамо који ће префикси ући у БГП путем редистрибуције

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 спада у ЕВПН руту типа 5 и преноси се на остатак листа:

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

У БГП табели такође можемо да посматрамо резултујући тип руте 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

Овим се завршава серија чланака посвећених ЕВПН-у. У будућности ћу покушати да размотрим рад ВкЛАН-а у вези са Мултицаст-ом, пошто се овај метод сматра скалабилнијим (у овом тренутку контроверзна изјава)

Ако и даље имате питања/сугестија о овој теми, размотрите било коју функционалност ЕВПН-а - пишите, ми ћемо то даље размотрити.

ВкЛАН фабрика. Део 3

Извор: ввв.хабр.цом

Додај коментар