🥇Kilang VxLAN. Bahagian 3

Hello, Habr. Saya sedang menyiapkan satu siri artikel, khusus untuk pelancaran kursus "Jurutera rangkaian" oleh OTUS, menggunakan teknologi VxLAN EVPN untuk penghalaan dalam fabrik dan menggunakan Firewall untuk menyekat akses antara perkhidmatan dalaman

Bahagian sebelumnya siri ini boleh didapati di pautan berikut:

Hari ini kita akan terus mengkaji logik penghalaan di dalam fabrik VxLAN. Dalam bahagian sebelumnya, kami melihat penghalaan intra-fabrik dalam satu VRF. Walau bagaimanapun, mungkin terdapat sejumlah besar perkhidmatan pelanggan dalam rangkaian, dan kesemuanya mesti diedarkan ke dalam VRF yang berbeza untuk membezakan akses antara mereka. Selain pengasingan rangkaian, perniagaan mungkin perlu menyambungkan Firewall untuk menyekat akses antara perkhidmatan ini. Ya, ini tidak boleh dipanggil penyelesaian terbaik, tetapi realiti moden memerlukan "penyelesaian moden".

Mari kita pertimbangkan dua pilihan untuk penghalaan antara VRF:

Menghala tanpa meninggalkan fabrik VxLAN;
Penghalaan pada peralatan luaran.

Mari kita mulakan dengan logik penghalaan antara VRF. Terdapat sebilangan VRF tertentu. Untuk membuat laluan antara VRF, anda perlu memilih peranti dalam rangkaian yang akan mengetahui tentang semua VRF (atau bahagian antara penghalaan yang diperlukan). Peranti sedemikian boleh, sebagai contoh, salah satu suis Leaf (atau sekaligus) . Topologi ini akan kelihatan seperti ini:

Apakah kelemahan topologi ini?

Betul, setiap Leaf perlu tahu tentang semua VRF (dan semua maklumat yang ada di dalamnya) pada rangkaian, yang membawa kepada kehilangan ingatan dan peningkatan beban rangkaian. Lagipun, selalunya setiap suis Daun tidak perlu mengetahui tentang semua yang ada pada rangkaian.

Walau bagaimanapun, mari kita pertimbangkan kaedah ini dengan lebih terperinci, kerana untuk rangkaian kecil pilihan ini agak sesuai (jika tidak ada keperluan perniagaan khusus)

Pada ketika ini, anda mungkin mempunyai soalan tentang cara memindahkan maklumat dari VRF ke VRF, kerana titik teknologi ini adalah tepat bahawa penyebaran maklumat harus dihadkan.

Dan jawapannya terletak pada fungsi seperti eksport dan import maklumat penghalaan (menyediakan teknologi ini dipertimbangkan dalam 2 bahagian kitaran). Biar saya ulangi secara ringkas:

Apabila menetapkan VRF dalam AF, anda mesti menentukan route-target untuk maklumat penghalaan import dan eksport. Anda boleh menentukannya secara automatik. Kemudian nilai akan termasuk ASN BGP dan L3 VNI yang dikaitkan dengan VRF. Ini mudah apabila anda hanya mempunyai satu ASN di kilang anda:

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

Walau bagaimanapun, jika anda mempunyai lebih daripada satu ASN dan perlu memindahkan laluan antara mereka, maka konfigurasi manual akan menjadi pilihan yang lebih mudah dan berskala route-target. Pengesyoran untuk persediaan manual ialah nombor pertama, gunakan nombor yang sesuai untuk anda, contohnya, 9999.
Yang kedua harus ditetapkan untuk menyamai VNI untuk VRF itu.

Mari konfigurasikannya seperti 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

Bagaimana rupanya dalam jadual penghalaan:

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 pilihan kedua untuk penghalaan antara VRF - melalui peralatan luaran, contohnya Firewall.

Terdapat beberapa pilihan untuk bekerja melalui peranti luaran:

Peranti mengetahui apa itu VxLAN dan kami boleh menambahkannya pada sebahagian daripada fabrik;
Peranti tidak mengetahui apa-apa tentang VxLAN.

Kami tidak akan memikirkan pilihan pertama, kerana logiknya akan hampir sama seperti yang ditunjukkan di atas - kami membawa semua VRF ke Firewall dan mengkonfigurasi penghalaan antara VRF di atasnya.

Mari kita pertimbangkan pilihan kedua, apabila Firewall kami tidak mengetahui apa-apa tentang VxLAN (kini, sudah tentu, peralatan dengan sokongan VxLAN muncul. Sebagai contoh, Checkpoint mengumumkan sokongannya dalam versi R81. Anda boleh membaca mengenainya di sini, walau bagaimanapun, ini semua di peringkat ujian dan tiada keyakinan terhadap kestabilan operasi).

Apabila menyambungkan peranti luaran, kami mendapat rajah berikut:

Seperti yang anda boleh lihat daripada rajah, hambatan muncul pada antara muka dengan Firewall. Ini mesti diambil kira pada masa hadapan apabila merancang rangkaian dan mengoptimumkan trafik rangkaian.

Walau bagaimanapun, mari kita kembali kepada masalah asal penghalaan antara VRF. Hasil daripada menambah Firewall, kami membuat kesimpulan bahawa Firewall mesti tahu tentang semua VRF. Untuk melakukan ini, semua VRF juga mesti dikonfigurasikan pada Daun sempadan, dan Firewall mesti disambungkan kepada setiap VRF dengan pautan yang berasingan.

Akibatnya, skema dengan Firewall:

Iaitu, pada Firewall anda perlu mengkonfigurasi antara muka untuk setiap VRF yang terletak pada rangkaian. Secara umum, logiknya tidak kelihatan rumit dan satu-satunya perkara yang saya tidak suka di sini ialah bilangan antara muka yang besar pada Firewall, tetapi inilah masanya untuk memikirkan automasi.

baik. Kami menyambungkan Firewall dan menambahkannya pada semua VRF. Tetapi bagaimana kita boleh memaksa trafik dari setiap Daun untuk melalui Firewall ini?

Pada Leaf yang disambungkan ke Firewall, tiada masalah akan timbul, kerana semua laluan adalah setempat:

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

Namun, bagaimana pula dengan Daun terpencil? Bagaimana untuk melepasi mereka laluan luaran lalai?

Betul, melalui laluan EVPN jenis 5, seperti mana-mana awalan lain di atas fabrik VxLAN. Walau bagaimanapun, ini tidak begitu mudah (jika kita bercakap tentang Cisco, kerana saya belum menyemak dengan vendor lain)

Laluan lalai mesti diiklankan dari Leaf yang mana Firewall disambungkan. Walau bagaimanapun, untuk menghantar laluan, Leaf mesti mengetahuinya sendiri. Dan di sini masalah tertentu timbul (mungkin hanya untuk saya), laluan mesti didaftarkan secara statik dalam VRF di mana anda ingin mengiklankan laluan sedemikian:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Seterusnya, dalam konfigurasi BGP, tetapkan laluan ini dalam AF IPv4:

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

Namun, bukan itu sahaja. Dengan cara ini laluan lalai tidak akan disertakan dalam keluarga l2vpn evpn. Di samping itu, anda perlu mengkonfigurasi pengagihan semula:

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

Kami menunjukkan awalan yang akan masuk ke BGP melalui pengagihan semula

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 awalan 0.0.0.0/0 jatuh ke dalam laluan EVPN jenis 5 dan dihantar 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

Dalam jadual BGP kita juga boleh melihat laluan-jenis 5 yang terhasil dengan laluan lalai 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 siri artikel yang dikhaskan untuk EVPN. Pada masa akan datang, saya akan cuba mempertimbangkan operasi VxLAN bersama-sama dengan Multicast, kerana kaedah ini dianggap lebih berskala (pada masa ini pernyataan kontroversial)

Jika anda masih mempunyai soalan/cadangan mengenai topik tersebut, pertimbangkan sebarang fungsi EVPN - tulis, kami akan mempertimbangkannya dengan lebih lanjut.

Sumber: www.habr.com

kilang VxLAN. Bahagian 3

Tambah komen Batal reply