ProHoster > blog > administrasi > pabrik VxLAN. Bagian 3

pabrik VxLAN. Bagian 3

Halo, Habr. Saya sedang menyelesaikan serangkaian artikel, didedikasikan untuk peluncuran kursus "Insinyur jaringan" oleh OTUS, menggunakan teknologi VxLAN EVPN untuk perutean di dalam fabric dan menggunakan Firewall untuk membatasi akses antar layanan internal

pabrik VxLAN. Bagian 3

Bagian sebelumnya dari seri ini dapat ditemukan di tautan berikut:

Hari ini kita akan terus mempelajari logika routing di dalam fabric VxLAN. Di bagian sebelumnya, kita melihat perutean intra-fabric dalam satu VRF. Namun, mungkin ada sejumlah besar layanan klien di jaringan, dan semuanya harus didistribusikan ke VRF yang berbeda untuk membedakan akses di antara mereka. Selain pemisahan jaringan, bisnis mungkin perlu menghubungkan Firewall untuk membatasi akses antar layanan ini. Ya, ini memang bukan solusi terbaik, namun realitas modern membutuhkan β€œsolusi modern”.

Mari pertimbangkan dua opsi untuk perutean antar VRF:

  1. Merutekan tanpa meninggalkan fabric VxLAN;
  2. Perutean pada peralatan eksternal.

Mari kita mulai dengan logika perutean antar VRF. Ada sejumlah VRF tertentu. Untuk merutekan antar VRF, Anda perlu memilih perangkat di jaringan yang akan mengetahui semua VRF (atau bagian yang memerlukan perutean). Perangkat tersebut dapat berupa, misalnya, salah satu switch Leaf (atau semuanya sekaligus) . Topologi ini akan terlihat seperti ini:

pabrik VxLAN. Bagian 3

Apa kelemahan topologi ini?

Benar, setiap Leaf perlu mengetahui semua VRF (dan semua informasi yang ada di dalamnya) di jaringan, yang menyebabkan hilangnya memori dan peningkatan beban jaringan. Lagi pula, seringkali setiap switch Leaf tidak perlu mengetahui semua yang ada di jaringan.

Namun, mari kita pertimbangkan metode ini lebih terinci, karena untuk jaringan kecil opsi ini cukup cocok (jika tidak ada persyaratan bisnis khusus)

Pada titik ini, Anda mungkin memiliki pertanyaan tentang bagaimana cara mentransfer informasi dari VRF ke VRF, karena inti dari teknologi ini justru penyebaran informasi harus dibatasi.

Dan jawabannya terletak pada fungsi seperti ekspor dan impor informasi perutean (pengaturan teknologi ini telah dipertimbangkan kedua bagian dari siklus). Izinkan saya ulangi secara singkat:

Saat mengatur VRF di AF, Anda harus menentukan route-target untuk informasi perutean impor dan ekspor. Anda dapat menentukannya secara otomatis. Kemudian nilainya akan mencakup ASN BGP dan L3 VNI yang terkait dengan VRF. Hal ini berguna bila Anda hanya memiliki satu ASN di pabrik Anda: 

vrf context PROD20
  address-family ipv4 unicast
    route-target export auto      ! Π’ автоматичСском Ρ€Π΅ΠΆΠΈΠΌΠ΅ экспортируСтся RT-65001:99000
    route-target import auto

Namun, jika Anda memiliki lebih dari satu ASN dan perlu mentransfer rute di antara mereka, maka konfigurasi manual akan menjadi pilihan yang lebih nyaman dan terukur. route-target. Rekomendasi untuk setup manual adalah angka pertama, gunakan angka yang nyaman bagi Anda, misalnya 9999.
Yang kedua harus disetel sama dengan VNI untuk VRF tersebut.

Mari kita konfigurasikan sebagai berikut:

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

Tampilan pada tabel routing:

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

Mari kita pertimbangkan opsi kedua untuk perutean antar VRF - melalui peralatan eksternal, misalnya Firewall.

Ada beberapa opsi untuk bekerja melalui perangkat eksternal:

  1. Perangkat mengetahui apa itu VxLAN dan kita dapat menambahkannya ke bagian fabric;
  2. Perangkat tidak mengetahui apa pun tentang VxLAN.

Kami tidak akan memikirkan opsi pertama, karena logikanya akan hampir sama seperti yang ditunjukkan di atas - kami membawa semua VRF ke Firewall dan mengonfigurasi perutean antar VRF di dalamnya.

Mari kita pertimbangkan opsi kedua, ketika Firewall kita tidak tahu apa-apa tentang VxLAN (sekarang, tentu saja, peralatan dengan dukungan VxLAN muncul. Misalnya, Checkpoint mengumumkan dukungannya di versi R81. Anda dapat membacanya di sini, namun, ini semua masih dalam tahap pengujian dan tidak ada kepercayaan terhadap stabilitas operasi).

Saat menghubungkan perangkat eksternal, kami mendapatkan diagram berikut:

pabrik VxLAN. Bagian 3

Seperti yang Anda lihat dari diagram, hambatan muncul di antarmuka dengan Firewall. Hal ini harus diperhitungkan di masa depan ketika merencanakan jaringan dan mengoptimalkan lalu lintas jaringan.

Namun, mari kita kembali ke masalah awal perutean antar VRF. Sebagai hasil dari penambahan Firewall, kami sampai pada kesimpulan bahwa Firewall harus mengetahui semua VRF. Untuk melakukan ini, semua VRF juga harus dikonfigurasi di perbatasan Leafs, dan Firewall harus terhubung ke setiap VRF dengan tautan terpisah.

Hasilnya, skema dengan Firewall:

pabrik VxLAN. Bagian 3

Artinya, di Firewall Anda perlu mengkonfigurasi antarmuka ke setiap VRF yang terletak di jaringan. Secara umum, logikanya tidak terlihat rumit dan satu-satunya hal yang saya tidak suka di sini adalah banyaknya antarmuka di Firewall, tetapi inilah saatnya memikirkan tentang otomatisasi.

Bagus. Kami menghubungkan Firewall dan menambahkannya ke semua VRF. Tapi bagaimana sekarang kita bisa memaksa lalu lintas dari setiap Leaf melewati Firewall ini?

Di Leaf yang terhubung ke Firewall, tidak ada masalah yang muncul, karena semua rute bersifat lokal:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6w5d, static       ! ΠΌΠ°Ρ€ΡˆΡ€ΡƒΡ‚ ΠΏΠΎ-ΡƒΠΌΠΎΠ»Ρ‡Π°Π½ΠΈΡŽ Ρ‡Π΅Ρ€Π΅Π· Firewall

Namun, bagaimana dengan Leafs yang terpencil? Bagaimana cara memberikan mereka rute eksternal default?

Benar, melalui EVPN tipe rute 5, seperti awalan lainnya melalui fabric VxLAN. Namun, ini tidak sesederhana itu (jika kita berbicara tentang Cisco, karena saya belum memeriksanya ke vendor lain)

Rute default harus diiklankan dari Leaf yang terhubung dengan Firewall. Namun, untuk mengirimkan rute tersebut, Leaf harus mengetahuinya sendiri. Dan di sini muncul masalah tertentu (mungkin hanya untuk saya), rute tersebut harus didaftarkan secara statis di VRF tempat Anda ingin mengiklankan rute seperti itu:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Selanjutnya pada konfigurasi BGP, atur rute ini di AF IPv4:

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

Namun, bukan itu saja. Dengan cara ini rute default tidak akan disertakan dalam keluarga l2vpn evpn. Selain itu, Anda perlu mengonfigurasi redistribusi:

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

Kami menunjukkan awalan mana yang akan masuk ke BGP melalui redistribusi

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

Sekarang awalannya 0.0.0.0/0 termasuk dalam rute EVPN tipe 5 dan ditransmisikan ke seluruh 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

Pada tabel BGP kita juga dapat mengamati hasil tipe rute 5 dengan rute default melalui 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

Ini menyimpulkan rangkaian artikel yang ditujukan untuk EVPN. Di masa depan, saya akan mencoba mempertimbangkan pengoperasian VxLAN bersama dengan Multicast, karena metode ini dianggap lebih terukur (saat ini merupakan pernyataan kontroversial)

Jika Anda masih memiliki pertanyaan/saran tentang topik tersebut, pertimbangkan fungsi EVPN apa pun - tulis, kami akan mempertimbangkannya lebih lanjut.

pabrik VxLAN. Bagian 3

Sumber: www.habr.com

Tambah komentar