A universal build with 13 distributions has been prepared for PinePhone

Helló, Habr. Befejezem a cikkek ciklusát, amelyek a kurzus indításáról szólnak "Hálózati mérnök" az OTUS-tól, a VxLAN EVPN technológiával a gyári belső útválasztásról és a tűzfal használatáról a belső szolgáltatások közötti hozzáférés korlátozására.

A ciklus korábbi részei az alábbi linkeken találhatók:

• 1. rész a ciklusból — L2 összekapcsolás a szerverek között
• 2. rész a ciklusból — Útválasztás a VNI között
• 2.5. rész a ciklusból — Elméleti kitérő

Ma folytatjuk a VxLAN gyári belső útválasztási logika tanulmányozását. Az előző részben a gyár egyetlen VRF-jén belüli útválasztást vizsgáltuk. Azonban a hálózaton számos kliens-szolgáltatás lehet, és mindet különböző VRF-ekbe kell elhelyezni, hogy elkülönüljön a hozzáférés közöttük. Továbbá a vállalkozásnak szüksége lehet tűzfalra is a szolgáltatások közötti hozzáférés korlátozására. Igen, ezt nem lehet a legjobb megoldásnak nevezni, de a modern valóság "modern megoldásokat" követel.

Vizsgáljuk meg a VRF-ek közötti útválasztás két lehetőségét:

1. Útválasztás a VxLAN gyár keretein belül;
2. Útválasztás külső eszközökön.

Kezdjük a VRF-ek közötti útválasztási logikával. Egy meghatározott számú VRF létezik. Az útválasztáshoz VRF-ek között szükség van egy eszközre a hálózaton, amely tud mindegyik VRF-ről (vagy a részükről, amelyek között szükséges az útválasztás). Ilyen eszköz lehet például az egyik Leaf switch (vagy mindegyik egyszerre). Az ilyen topológia így néz ki:

Melyek a hátrányai ennek a topológiának?

Helyes, minden Leaf-nek tudnia kell az összes VRF-ről (és az ott található információkról) a hálózaton, ami memória-vesztéshez és a hálózatra nehezedő terhelés növekedéséhez vezet. Hiszen viszonylag gyakran nem szükséges, hogy minden Leaf switch mindent tudjon, ami a hálózaton található.

Itt azonban érdemes ezt a megoldást részletesebben megvizsgálni, mivel kis hálózatok esetén ez a variáció teljesen megfelelő lehet (ha nincsenek speciális üzleti követelmények).

Ezen a ponton felmerülhet a kérdés, hogyan lehet információt továbbítani az egyik VRF-ből a másikba, hiszen a technológia lényege pont az, hogy az információ terjesztése korlátozott legyen.

A válasz az export és import funkciókban rejlik a forgalmi információk számára (e technológia beállítását a második ciklus részében tárgyaltuk). Röviden összefoglalom:

Amikor VRF-t állítunk be az AF-ben, meg kell adni route-target az importálás és exportálás útvonal-információk. Ezt automatikusan lehet megadni. Így az ASN BGP és az L3 VNI értéke kerül hozzárendelésre a VRF-hez. Ez kényelmes, amikor a gyárban csak egy ASN-t használnak:

vrf kontextus PROD20
  cím-család ipv4 unicast
    útvonal-cél export automatikus      ! Automatikus üzemmódban exportálva: RT-65001:99000
    útvonal-cél import automatikus

Ha azonban több ASN van, és szükséges a közti útvonalak átadása, a kézi beállítás kényelmesebb és skálázhatóbb megoldás lesz. route-targetA kézi beállításhoz a javasolt első számot használja, ami Önnek kényelmes, például: 9999.
A második értéket állítsa be ennek a VRF-nek a VNI-jára.

A következőképpen állítsuk be:

vrf kontextus PROD10
  cím-család ipv4 unicast
    útvonal-cél export 9999:99000         
    útvonal-cél import 9999:99000
    útvonal-cél import 9999:77000         ! Példa 1 import másik VRF-ből
    útvonal-cél import 9999:88000         ! Példa 2 import másik VRF-ből

Hogyan néz ki az útvonal táblázatban:

Leaf11# sh ip route vrf prod

192.168.20.0/24, ubest/mbest: 1/0
 *via 10.255.1.20fault, [200/0], 00:24:45, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! a prefix elérhető az L3VNI 99000-en keresztül

Nézzük meg a második útvonalazási lehetőséget a VRF között — külső berendezésen keresztül, például egy tűzfalon.

Több működési lehetőséget feltételezhetünk a külső eszközön keresztül:

1. Az eszköz tudja, mi az a VxLAN és hozzáadhatjuk a gyár egy részéhez;
2. Az eszköz nem tud semmit a VxLAN-ról.

Az első lehetőségnél nem állunk meg, mivel a logika gyakorlatilag ugyanolyan lesz, mint fentebb — az összes VRF-et a tűzfalhoz vezetjük, és azon állítjuk be a VRF közötti útvonalazást.

Nézzük meg a második lehetőséget, amikor a tűzfalunk nem tud semmit a VxLAN-ról (jelenleg természetesen megjelennek az VxLAN támogatású berendezések. Például a Checkpoint bejelentette ennek támogatását az R81 verzióban. Erről bővebben olvashatunk itt, de ez jelenleg még tesztelési fázisban van, és nincs biztosíték a stabil működésre).

Külső eszköz csatlakoztatásával a következő ábra adódik:

Ahogyan a sémán látható — szűk keresztmetszet alakul ki a tűzfalsal. Ezt figyelembe kell venni a hálózat tervezése és a hálózati forgalom optimalizálása során.

Viszont térjünk vissza az eredeti VRF közötti útvonalazási feladathoz. A tűzfal hozzáadásával arra a következtetésre jutunk, hogy a tűzfalnak tudnia kell minden VRF-ről. Ehhez a határ Leafeken is be kell állítani az összes VRF-et, és a tűzfalat minden VRF-hez külön linkkel kell csatlakoztatni.

A tűzfal rendszere:

Ezért a tűzfalon be kell állítani az interfészt minden VRF-re, amely a hálózaton található. Összességében a logika nem tűnik bonyolultnak, és az egyetlen dolog, ami nem tetszhet, az a tűzfalon található hatalmas interfészek száma, de itt ideje elgondolkodni az automatizáláson.

Rendben. Csatlakoztattuk a tűzfalat, és hozzáadtuk minden VRF-hez. De hogyan kényszerítsük rá a forgalmat minden Leaf-re, hogy ezen a tűzfalon menjen keresztül?

A tűzfalhoz csatlakoztatott Leaf-en nem lesz probléma, mivel az összes útvonal helyi:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6h5d, statikus       ! alapértelmezett útvonal a tűzfalon keresztül

De mi a helyzet a távoli Leaf-ekkel? Hogyan tudnánk értük átadni a külső alapértelmezett útvonalat?

Helyes, az EVPN route-type 5-ön keresztül, mint bármely más prefix VxLAN gyárban. De ezzel nem minden olyan egyszerű (ha Cisco-ról beszélünk, más gyártóknál nem ellenőriztem ezt)

Az alapértelmezett útvonalat a Leaf-ről kell hirdetni, amelyhez a tűzfal csatlakozik. De az útvonal átviteléhez a Leaf-nek magának is tudnia kell azt. Itt egy kis probléma adódik (talán csak nálam), az útvonalat statikus formában kell beállítani abban a VRF-ben, ahol hirdetni szeretné ezt az útvonalat:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Ezután a BGP beállításában ezt az útvonalat az AF IPv4-be kell megadni:

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

De ez még nem minden. Ily módon az alapértelmezett útvonal nem fog belekerülni a családba l2vpn evpn. Ezen kívül a redistribúciót is be kell állítani:

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

Megadjuk, hogy pontosan mely prefixek kerülnek a BGP-be a redistribúció révén

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

Most a prefix 0.0.0.0/0 belekerül az EVPN route-type 5-be, és átkerül a többi Leafhez:

0.0.0.0/0, ubest/mbest: 1/0
 *via 10.255.1.5fault, [200/0], 5h6d, bgp-65001, internal, tag 65001, segid: 99000 tunnelid: 0xaff0105 encap: VXLAN
 ! 10.255.1.5 - Virtuális cím Leaf(ahol a Leaf VPС párként működik), amelyhez a Firewall csatlakozik

A BGP táblázatban szintén láthatjuk a kapott route-type 5-öt az alapértelmezett útvonallal a 10.255.1.5-ön keresztül:

* 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

Ezzel befejezzük az EVPN-ről szóló cikkek ciklusát. A jövőben megpróbálom megvizsgálni a VxLAN működését a Multicast-tal összekapcsolva, mivel ez a módszer sokkal skálázhatóbbnak számít (jelenleg vitatott állítás).

Ha bármilyen kérdése van, vagy javaslatot tenne az EVPN bármely funkciójának megvitatására — írjon nekünk, további részleteket megvitatunk.

Forrás: habr.com