Persyaratan jaringan host untuk Azure Stack HCI

Berlaku untuk: Azure Stack HCI, versi 23H2 dan 22H2

Topik ini membahas pertimbangan dan persyaratan jaringan host untuk Azure Stack HCI. Untuk informasi tentang arsitektur pusat data dan koneksi fisik antar server, lihat Persyaratan jaringan fisik.

Untuk informasi tentang cara menyederhanakan jaringan host menggunakan Network ATC, lihat Menyederhanakan jaringan host dengan Network ATC.

Jenis lalu lintas jaringan

Lalu lintas jaringan Azure Stack HCI dapat diklasifikasikan berdasarkan tujuannya:

  • Lalu lintas manajemen: Lalu lintas ke atau dari luar kluster lokal. Misalnya, lalu lintas replika penyimpanan atau lalu lintas yang digunakan oleh administrator untuk pengelolaan kluster meliputi Desktop Jauh, Windows Admin Center, Active Directory, dll.
  • Lalu lintas komputasi: Lalu lintas yang berasal dari atau ditujukan untuk mesin virtual (VM).
  • Lalu lintas penyimpanan: Lalu lintas menggunakan Server Message Block (SMB), misalnya Storage Spaces Direct atau migrasi langsung berbasis SMB. Lalu lintas ini adalah lalu lintas lapisan-2 dan tidak dapat dirutekan.

Penting

Replika penyimpanan menggunakan lalu lintas SMB berbasis non-RDMA. Ini dan sifat arah lalu lintas (Utara-Selatan) membuatnya selaras dengan lalu lintas "manajemen" yang tercantum di atas, mirip dengan berbagi file tradisional.

Pilih adaptor jaringan

Adaptor jaringan memenuhi syarat berdasarkan jenis lalu lintas jaringan (lihat di atas) yang didukung untuk digunakan. Saat Anda meninjau Katalog Windows Server, sertifikasi Windows Server 2022 kini menunjukkan satu peran berikut atau lebih. Sebelum membeli server untuk Azure Stack HCI, Anda minimal harus memiliki setidaknya satu adaptor yang memenuhi syarat untuk manajemen, komputasi, dan penyimpanan karena ketiga jenis lalu lintas ini diperlukan di Azure Stack HCI. Anda kemudian dapat menggunakan NETWORK ATC untuk mengonfigurasi adaptor Anda untuk jenis lalu lintas yang sesuai.

Untuk informasi selengkapnya mengenai kualifikasi NIC berbasis peran ini, harap lihat link ini.

Penting

Menggunakan adaptor di luar jenis lalu lintas yang memenuhi syarat tidak didukung.

Tingkat Peran Manajemen Peran Komputasi Peran Penyimpanan
Perbedaan berbasis peran Manajemen Standar Komputasi Standar Penyimpanan
Penghargaan Maksimum Tidak berlaku Komputasi Premium Penyimpanan Premium

Catatan

Kualifikasi tertinggi untuk setiap adaptor dalam ekosistem kami akan berisi kualifikasi Manajemen, Komputasi Premium, dan Penyimpanan Premium.

Cuplikan layar memperlihatkan kualifikasi 'Bersertifikat untuk Windows', termasuk fitur Manajemen, Compute Premium, dan Storage Premium.

Persyaratan Driver

Driver kotak masuk tidak didukung untuk digunakan dengan Azure Stack HCI. Untuk mengidentifikasi apakah adaptor Anda menggunakan driver kotak masuk, jalankan cmdlet berikut. Adaptor menggunakan driver kotak masuk apabila properti DriverProvider adalah Microsoft.

Get-NetAdapter -Name <AdapterName> | Select *Driver*

Gambaran umum kemampuan adaptor jaringan kunci

Kemampuan adaptor jaringan penting yang digunakan oleh Azure Stack HCI meliputi:

  • Mesin Virtual Multi-Antrean Dynamic (Dynamic VMMQ atau d.VMMQ)
  • Akses Memori Langsung Jarak Jauh (RDMA)
  • RDMA Tamu
  • Switch Embedded Teaming (SET)

Dynamic VMMQ

Semua adaptor jaringan dengan kualifikasi Komputasi (Premium) mendukung Dynamic VMMQ. Dynamic VMMQ mengharuskan penggunaan Switch Embedded Teaming.

Jenis lalu lintas yang berlaku: komputasi

Sertifikasi diperlukan: Komputasi (Premium)

Dynamic VMMQ adalah teknologi cerdas sisi penerimaan. Ia dibangun berdasarkan pendahulunya yaitu Antrean Mesin Virtual (VMQ), Penskalaan Virtual Sisi Penerimaan (vRSS), dan VMMQ, untuk memberikan tiga perbaikan utama:

  • Mengoptimalkan efisiensi host dengan menggunakan lebih sedikit core CPU.
  • Penyetelan otomatis pemrosesan lalu lintas jaringan ke core CPU, sehingga memungkinkan VM untuk memenuhi dan mempertahankan throughput yang diharapkan.
  • Memungkinkan beban kerja "bursty" untuk menerima jumlah lalu lintas yang diharapkan.

Untuk informasi selengkapnya tentang Dynamic VMMQ, lihat posting blog Akselerasi sintetis.

RDMA

RDMA melakukan offload tumpukan jaringan pada adaptor jaringan. Dengan RDMA, lalu lintas penyimpanan SMB dapat melewati sistem operasi untuk diproses.

RDMA mengaktifkan jaringan dengan throughput tinggi dan latensi yang rendah menggunakan sumber daya CPU host minimal. Sumber daya CPU host ini kemudian dapat digunakan untuk menjalankan VM atau kontainer tambahan.

Jenis lalu lintas yang berlaku: penyimpanan host

Sertifikasi diperlukan: Penyimpanan (Standar)

Semua adaptor dengan kualifikasi Penyimpanan (Standar) atau Penyimpanan (Premium) mendukung RDMA sisi host. Untuk informasi selengkapnya tentang menggunakan RDMA dengan beban kerja tamu, lihat bagian "RDMA Tamu" nanti di artikel ini.

Azure Stack HCI mendukung RDMA dengan implementasi protokol Internet Wide Area RDMA Protocol (iWARP) atau RDMA melalui Converged Ethernet (RoCE).

Penting

Adaptor RDMA hanya berfungsi dengan adaptor RDMA lain yang menerapkan protokol RDMA yang sama (iWARP atau RoCE).

Tidak semua adaptor jaringan dari vendor mendukung RDMA. Tabel berikut mencantumkan vendor tersebut (dalam urutan alfabet) yang menawarkan adaptor RDMA bersertifikat. Namun, ada vendor perangkat keras yang tidak termasuk dalam daftar ini yang juga mendukung RDMA. Lihat Katalog Windows Server untuk menemukan adaptor dengan kualifikasi Penyimpanan (Standar) atau Penyimpanan (Premium) yang memerlukan dukungan RDMA.

Catatan

InfiniBand (IB) tidak didukung oleh Azure Stack HCI.

Vendor NIC iWARP RoCE
Broadcom Tidak Ya
Intel Ya Ya (beberapa model)
Marvell (Qlogic) Ya Ya
Nvidia Tidak Ya

Untuk informasi selengkapnya tentang menyebarkan RDMA untuk host, kami sangat menyarankan Anda menggunakan ATC Jaringan. Untuk informasi tentang penyebaran manual, lihat repositori GitHub SDN.

iWARP

iWARP menggunakan Protokol Kendali Transmisi (TCP), dan dapat ditingkatkan secara opsional dengan Alur Kontrol Berbasis Prioritas (PFC) dan Layanan Transmisi yang Disempurnakan (ETS).

Gunakan iWARP jika:

  • Anda tidak memiliki pengalaman mengelola jaringan RDMA.
  • Anda tidak mengelola atau tidak nyaman mengelola sakelar top-of-rack (ToR).
  • Anda tidak akan mengelola solusi setelah penyebaran.
  • Anda sudah memiliki penyebaran yang menggunakan iWARP.
  • Anda tidak yakin pilihan mana yang harus dipilih.

RoCE

RoCE menggunakan Protokol Datagram Pengguna (UDP), dan membutuhkan PFC dan ETS untuk memberikan keandalan.

Gunakan RoCE jika:

  • Anda sudah memiliki penyebaran dengan RoCE di pusat data Anda.
  • Anda merasa nyaman mengelola persyaratan jaringan DCB.

RDMA Tamu

Dengan RDMA tamu, beban kerja SMB untuk VM bisa mendapatkan manfaat yang sama dengan menggunakan RDMA pada host.

Jenis lalu lintas yang berlaku: Penyimpanan berbasis tamu

Sertifikasi diperlukan: Komputasi (Premium)

Manfaat utama menggunakan RDMA Tamu adalah:

  • CPU melakukan offload pada NIC untuk pemrosesan lalu lintas jaringan.
  • Latensi yang sangat rendah.
  • Throughput tinggi.

Untuk informasi selengkapnya, unduh dokumen dari Repositori GitHub SDN.

Switch Embedded Teaming (SET)

SET adalah teknologi teaming berbasis perangkat lunak yang telah dimasukkan dalam sistem operasi Windows Server sejak Windows Server 2016. SET adalah satu-satunya teknologi teaming yang didukung oleh Azure Stack HCI. SET berfungsi dengan baik dengan lalu lintas komputasi, penyimpanan, dan manajemen dan didukung dengan hingga delapan adaptor di tim yang sama.

Jenis lalu lintas yang berlaku: komputasi, penyimpanan, dan manajemen

Sertifikasi diperlukan: Komputasi (Standar) atau Komputasi (Premium)

SET adalah satu-satunya teknologi teaming yang didukung oleh Azure Stack HCI. SET bekerja dengan baik bersama komputasi, penyimpanan, dan lalu lintas manajemen.

Penting

Azure Stack HCI tidak mendukung tim NIC dengan Load Balancing/Failover (LBFO) yang lebih lama. Lihat posting blog Teaming di Azure Stack HCI untuk informasi selengkapnya tentang LBFO di Azure Stack HCI.

SET penting untuk Azure Stack HCI karena ini adalah satu-satunya teknologi teaming yang memungkinkan:

  • Teaming adaptor RDMA (jika diperlukan).
  • RDMA Tamu.
  • Dynamic VMMQ.
  • Fitur kunci Azure Stack HCI lainnya (lihat Teaming di Azure Stack HCI).

SET memerlukan penggunaan adaptor simetris (identik). Adaptor jaringan simetris adalah adaptor yang memiliki kesamaan dalam hal:

  • membuat (vendor)
  • model (versi)
  • kecepatan (throughput)
  • konfigurasi

Pada 22H2, NETWORK ATC akan secara otomatis mendeteksi dan memberi tahu Anda jika adaptor yang Anda pilih asimetris. Cara termudah untuk mengidentifikasi secara manual apakah adaptor simetris adalah jika kecepatan dan deskripsi antarmuka sama persis . Penyimpangan diizinkan pada angka yang tercantum dalam deskripsi. Gunakan Get-NetAdapterAdvancedProperty cmdlet untuk memastikan konfigurasi yang dilaporkan mencantumkan nilai properti yang sama.

Lihat tabel berikut untuk mengetahui contoh deskripsi antarmuka yang menyimpang hanya berdasarkan angka (#):

Nama Deskripsi antarmuka Kecepatan link
NIC1 Adaptor Jaringan #1 25 Gbps
NIC2 Adaptor Jaringan #2 25 Gbps
NIC3 Adaptor Jaringan #3 25 Gbps
NIC4 Adaptor Jaringan #4 25 Gbps

Catatan

SET hanya mendukung konfigurasi switch-independent dengan menggunakan algoritma load-balancing Dynamic atau Port Hyper-V. Untuk performa terbaik, disarankan untuk menggunakan Port Hyper-V pada semua NIC yang beroperasi pada atau di atas 10 Gbps. ATC Jaringan membuat semua konfigurasi yang diperlukan untuk SET.

Pertimbangan lalu lintas RDMA

Jika Anda menerapkan DCB, Anda harus memastikan bahwa konfigurasi PFC dan ETS diimplementasikan dengan benar di setiap port jaringan, termasuk sakelar jaringan. DCB diperlukan untuk RoCE dan opsional untuk iWARP.

Untuk informasi terperinci tentang cara menyebarkan RDMA, unduh dokumen dari Repositori GitHub SDN.

Implementasi Azure Stack HCI berbasis RoCE memerlukan konfigurasi tiga kelas lalu lintas PFC, termasuk kelas lalu lintas default, di seluruh fabric dan semua host.

Kelas lalu lintas kluster

Kelas lalu lintas ini memastikan bahwa ada cukup bandwidth yang disediakan untuk heartbeat kluster:

  • Diperlukan: Ya
  • PFC-diaktifkan: Tidak
  • Prioritas lalu lintas yang direkomendasikan: Prioritas 7
  • Reservasi bandwidth yang direkomendasikan:
    • Jaringan RDMA 10 GbE atau lebih rendah = 2 persen
    • Jaringan RDMA 25 GbE atau lebih rendah = 1 persen

Kelas lalu lintas RDMA

Kelas lalu lintas ini memastikan bahwa ada cukup bandwidth yang disediakan untuk komunikasi RDMA lossless dengan menggunakan SMB Direct:

  • Diperlukan: Ya
  • PFC-diaktifkan: Ya
  • Prioritas lalu lintas yang direkomendasikan: Prioritas 3 atau 4
  • Reservasi bandwidth yang direkomendasikan: 50 persen

Kelas lalu lintas default

Kelas lalu lintas ini membawa semua lalu lintas lain yang tidak didefinisikan dalam kelas lalu lintas kluster atau RDMA, termasuk lalu lintas VM dan lalu lintas manajemen:

  • Diperlukan: Secara default (tidak ada konfigurasi yang diperlukan pada host)
  • Kontrol alur (PFC)-diaktifkan: Tidak
  • Kelas lalu lintas yang direkomendasikan: Secara default (Prioritas 0)
  • Reservasi bandwidth yang direkomendasikan: Secara default (tidak diperlukan konfigurasi host)

Model lalu lintas penyimpanan

SMB memberikan banyak manfaat sebagai protokol penyimpanan untuk Azure Stack HCI, termasuk SMB Multichannel. SMB Multichannel tidak tercakup dalam artikel ini, tetapi penting untuk dipahami bahwa lalu lintas digandakan di setiap link yang dapat digunakan SMB Multichannel.

Catatan

Sebaiknya gunakan beberapa subnet dan VLAN untuk memisahkan lalu lintas penyimpanan di Azure Stack HCI.

Pertimbangkan contoh kluster empat node berikut. Setiap server memiliki dua port penyimpanan (sisi kiri dan kanan). Karena setiap adaptor berada di subnet dan VLAN yang sama, SMB Multichannel akan menyebarkan koneksi di semua link yang tersedia. Oleh karena itu, port sisi kiri pada server pertama (192.168.1.1) akan membuat koneksi ke port sisi kiri pada server kedua (192.168.1.2). Port sisi kanan pada server pertama (192.168.1.12) akan terhubung ke port sisi kanan pada server kedua. Koneksi serupa dibuat untuk server ketiga dan keempat.

Namun, hal ini menciptakan koneksi yang tidak perlu dan menyebabkan penyumbatan pada interlink (multi-chassis link aggregation group atau MC-LAG) yang menghubungkan switch ToR (ditandai dengan X). Lihat diagram berikut:

Diagram yang memperlihatkan kluster empat node pada subnet yang sama.

Pendekatan yang disarankan adalah menggunakan subnet dan VLAN terpisah untuk setiap set adaptor. Pada diagram berikut, port kanan sekarang menggunakan subnet 192.168.2.x /24 dan VLAN2. Hal ini memungkinkan lalu lintas di port sisi kiri untuk tetap berada di TOR1 dan lalu lintas di port sisi kanan tetap berada di TOR2.

Diagram yang memperlihatkan kluster empat node pada subnet yang berbeda.

Alokasi bandwidth lalu lintas

Tabel berikut menunjukkan contoh alokasi bandwidth dari berbagai jenis lalu lintas, dengan menggunakan kecepatan adaptor umum, di Azure Stack HCI. Perhatikan bahwa pada contoh solusi konvergen ini, semua jenis lalu lintas (komputasi, penyimpanan, dan manajemen) berjalan pada adaptor fisik yang sama, dan bekerja sama dengan menggunakan SET.

Karena menimbulkan batasan terbanyak, kasus penggunaan ini merupakan garis besar yang baik. Namun, mengingat permutasi untuk jumlah adaptor dan kecepatan, ini harus dianggap sebagai contoh dan bukan persyaratan dukungan.

Asumsi berikut dibuat untuk contoh ini:

  • Terdapat dua adaptor per tim.

  • Lalu lintas Storage Bus Layer (SBL), Cluster Shared Volume (CSV), dan Hyper-V (Live Migration):

    • Gunakan adaptor fisik yang sama.
    • Gunakan SMB.
  • SMB diberikan alokasi bandwidth 50 persen dengan menggunakan DCB.

    • SBL/CSV adalah lalu lintas prioritas tertinggi, dan menerima 70 persen dari reservasi bandwidth SMB.
    • Migrasi Langsung (LM) dibatasi dengan menggunakan Set-SMBBandwidthLimit cmdlet, dan menerima 29 persen dari bandwidth yang tersisa.
      • Jika bandwidth yang tersedia untuk Migrasi Langsung = >5 Gbps, dan adaptor jaringan mendukung hal ini, gunakan RDMA. Gunakan cmdlet berikut untuk melakukannya:

        Set-VMHost -VirtualMachineMigrationPerformanceOption SMB
        
      • Jika bandwidth yang tersedia untuk Migrasi Langsung adalah < 5 Gbps, gunakan pemadatan untuk mengurangi waktu pemadaman. Gunakan cmdlet berikut untuk melakukannya:

        Set-VMHost -VirtualMachineMigrationPerformanceOption Compression
        
  • Jika Anda menggunakan RDMA untuk lalu lintas Migrasi Langsung, pastikan lalu lintas Migrasi Langsung tidak dapat menghabiskan seluruh bandwidth yang dialokasikan ke kelas lalu lintas RDMA dengan menggunakan batas bandwidth SMB. Hati-hati, karena cmdlet ini menerima masukan dalam byte per detik (Bps), sedangkan adaptor jaringan terdaftar dalam bit per detik (bps). Gunakan cmdlet berikut untuk menetapkan batas bandwidth 6 Gbps, misalnya:

    Set-SMBBandwidthLimit -Category LiveMigration -BytesPerSecond 750MB
    

    Catatan

    750 MBps dalam contoh ini setara dengan 6 Gbps.

Berikut adalah contoh tabel alokasi bandwidth:

Kecepatan NIC Bandwidth yang bekerja sama Reservasi bandwidth SMB** SBL/CSV % Bandwidth SBL/CSV Migrasi Langsung % Bandwidth Migrasi Langsung Maksimum Heartbeat % Bandwidth heartbeat
10 Gbps 20 Gbps 10 Gbps 70% 7 Gbps ** 200 Mbps
25 Gbps 50 Gbps 25 Gbps 70% 17,5 Gbps 29% 7,25 Gbps 1% 250 Mbps
40 Gbps 80 Gbps 40 Gbps 70% 28 Gbps 29% 11,6 Gbps 1% 400 Mbps
50 Gbps 100 Gbps 50 Gbps 70% 35 Gbps 29% 14,5 Gbps 1% 500 Mbps
100 Gbps 200 Gbps 100 Gbps 70% 70 Gbps 29% 29 Gbps 1% 1 Gbps
200 Gbps 400 Gbps 200 Gbps 70% 140 Gbps 29% 58 Gbps 1% 2 Gbps

* Gunakan pemadatan daripada RDMA, karena alokasi bandwidth untuk lalu lintas Migrasi Langsung adalah <5 Gbps.

** 50 persen adalah contoh reservasi bandwidth.

Kluster rentang

Kluster rentang memberikan pemulihan bencana yang mencakup beberapa pusat data. Dalam bentuknya yang paling sederhana, jaringan kluster Azure Stack HCI yang direntangkan terlihat seperti ini:

Diagram yang memperlihatkan rentangan kluster.

Persyaratan kluster rentang

Kluster rentang memiliki persyaratan dan karakteristik berikut:

  • RDMA terbatas pada satu situs, dan tidak didukung di berbagai situs atau subnet berbeda.

  • Server di situs yang sama harus berada di rak yang sama dan batas Layer-2.

  • Komunikasi host antar situs harus melewati batas Layer-3; Topologi Layer-2 yang direntangkan tidak didukung.

  • Memiliki bandwidth yang cukup untuk menjalankan beban kerja di situs lain. Jika terjadi failover, situs alternatif harus menjalankan semua lalu lintas. Anda sebaiknya memprovisikan situs sebesar 50 persen dari kapasitas jaringan yang tersedia. Akan tetapi, ini bukan persyaratan, asalkan Anda dapat menoleransi performa yang lebih rendah selama failover.

  • Replikasi antar situs (lalu lintas utara/selatan) dapat menggunakan NIC fisik yang sama dengan penyimpanan lokal (lalu lintas timur/barat). Jika Anda menggunakan adaptor fisik yang sama, adaptor ini harus bekerja sama dengan SET. Adaptor juga harus memiliki NIC virtual tambahan yang disediakan untuk lalu lintas antar situs yang dapat dirutekan.

  • Adaptor yang digunakan untuk komunikasi antar situs:

    • Bisa berupa fisik atau virtual (vNIC host). Jika adaptor bersifat virtual, Anda harus memprovisikan satu vNIC di subnet dan VLAN sendiri untuk setiap NIC fisik.

    • Harus berada di subnet mereka sendiri dan VLAN yang dapat merutekan antar situs.

    • RDMA harus dinonaktifkan dengan menggunakan Disable-NetAdapterRDMA cmdlet. Sebaiknya Anda secara eksplisit mensyaratkan Replika Penyimpanan untuk menggunakan antarmuka tertentu melalui cmdletSet-SRNetworkConstraint.

    • Harus memenuhi persyaratan tambahan untuk Replika Penyimpanan.

Contoh kluster rentang

Contoh berikut menggambarkan konfigurasi kluster rentang. Untuk memastikan bahwa NIC virtual tertentu dipetakan ke adaptor fisik tertentu, gunakan cmdlet Set-VMNetworkAdapterTeammapping.

Diagram yang memperlihatkan contoh penyimpanan rentangan kluster.

Bagian berikut ini menunjukkan detail pada contoh konfigurasi kluster rentang.

Catatan

Konfigurasi pasti Anda, termasuk nama NIC, alamat IP, dan VLAN, mungkin berbeda dari apa yang ditampilkan. Ini hanya digunakan sebagai konfigurasi referensi yang dapat disesuaikan dengan lingkungan Anda.

SiteA – Replikasi lokal, RDMA diaktifkan, tidak dapat dirutekan antar situs

Nama node Nama vNIC NIC Fisik (dipetakan) VLAN IP dan subnet Cakupan lalu lintas
NodeA1 vSMB01 pNIC01 711 192.168.1.1/24 Hanya Situs Lokal
NodeA2 vSMB01 pNIC01 711 192.168.1.2/24 Hanya Situs Lokal
NodeA1 vSMB02 pNIC02 712 192.168.2.1/24 Hanya Situs Lokal
NodeA2 vSMB02 pNIC02 712 192.168.2.2/24 Hanya Situs Lokal

SiteB – Replikasi lokal, RDMA diaktifkan, tidak dapat dirutekan antar situs

Nama node Nama vNIC NIC Fisik (dipetakan) VLAN IP dan subnet Cakupan lalu lintas
NodeB1 vSMB01 pNIC01 711 192.168.1.1/24 Hanya Situs Lokal
NodeB2 vSMB01 pNIC01 711 192.168.1.2/24 Hanya Situs Lokal
NodeB1 vSMB02 pNIC02 712 192.168.2.1/24 Hanya Situs Lokal
NodeB2 vSMB02 pNIC02 712 192.168.2.2/24 Hanya Situs Lokal

SiteA – Replikasi rentang, RDMA dinonaktifkan, dapat dirutekan antar situs

Nama node Nama vNIC NIC Fisik (dipetakan) IP dan subnet Cakupan lalu lintas
NodeA1 Stretch1 pNIC01 173.0.0.1/8 Dapat dirutekan Lintas Situs
NodeA2 Stretch1 pNIC01 173.0.0.2/8 Dapat dirutekan Lintas Situs
NodeA1 Stretch2 pNIC02 174.0.0.1/8 Dapat dirutekan Lintas Situs
NodeA2 Stretch2 pNIC02 174.0.0.2/8 Dapat dirutekan Lintas Situs

SiteB – Replikasi rentang, RDMA dinonaktifkan, dapat dirutekan antar situs

Nama node Nama vNIC NIC Fisik (dipetakan) IP dan subnet Cakupan lalu lintas
NodeB1 Stretch1 pNIC01 175.0.0.1/8 Dapat dirutekan Lintas Situs
NodeB2 Stretch1 pNIC01 175.0.0.2/8 Dapat dirutekan Lintas Situs
NodeB1 Stretch2 pNIC02 176.0.0.1/8 Dapat dirutekan Lintas Situs
NodeB2 Stretch2 pNIC02 176.0.0.2/8 Dapat dirutekan Lintas Situs

Langkah berikutnya