Azure Stack HCI için konak ağ gereksinimleri

Şunlar için geçerlidir: Azure Stack HCI, sürüm 21H2 ve 20H2

Bu konuda, Azure Stack HCI için konak ağı ile ilgili önemli noktalar ve gereksinimler açıklanmaktadır. Veri merkezi mimarileri ve sunucular arasındaki fiziksel bağlantılar hakkında bilgi için bkz. Fiziksel ağ gereksinimleri.

Ağ ATC kullanarak konak ağını basitleştirme hakkında bilgi için bkz. Ağ ATC ile konak ağını basitleştirme.

Ağ trafiği türleri

Azure Stack HCI ağ trafiği hedeflenen amacına göre sınıflandırılabilir:

  • İşlem trafiği: Bir sanal makineden (VM) kaynaklanan veya hedeflenen trafik.
  • trafik Depolama: Sunucu İleti Bloğu (SMB) kullanan trafik, örneğin Depolama Alanları Doğrudan veya SMB tabanlı dinamik geçiş.
  • Yönetim trafiği: Uzak Masaüstü, Windows Admin Center, Active Directory vb. dahil olmak üzere kümenin yönetimi için yönetici tarafından kullanılan trafik.

Ağ bağdaştırıcısı seçme

Azure Stack HCI, Standart veya Premium Ek Nitelik (AQ) ile Windows Server Software-Defined Veri Merkezi (SDDC) sertifikasına ulaşmış bir ağ bağdaştırıcısı seçmeyi gerektirir. Bu bağdaştırıcılar en gelişmiş platform özelliklerini destekler ve donanım iş ortaklarımız tarafından en fazla testden geçmiştir. Bu inceleme düzeyi genellikle donanım ve sürücüyle ilgili kalite sorunlarının azalmasına yol açar. Bu bağdaştırıcılar Depolama Alanları Doğrudan için oluşturulan ağ gereksinimlerini de karşılar.

Standart veya Premium AQ'ya sahip bir bağdaştırıcıyı, bağdaştırıcının Windows Sunucu Kataloğu girdisini ve ilgili işletim sistemi sürümünü gözden geçirerek tanımlayabilirsiniz. Premium AQ gösteriminin bir örneği aşağıda verilmiştir:

Screenshot of Windows Certified options, with a Premium AQ option highlighted.

Anahtar ağ bağdaştırıcısı özelliklerine genel bakış

Azure Stack HCI tarafından kullanılan önemli ağ bağdaştırıcısı özellikleri şunlardır:

  • Dinamik Sanal Makine Çok Sıralı (Dinamik VMMQ veya d.VMMQ)
  • Doğrudan Uzak Bellek Erişimi (RDMA)
  • Konuk RDMA
  • Anahtar Eklenmiş Ekip Oluşturma (SET)

Dinamik VMMQ

Premium AQ'ya sahip tüm ağ bağdaştırıcıları Dinamik VMMQ'yi destekler. Dinamik VMMQ, Anahtar Eklenmiş Ekip Oluşturma'nın kullanılmasını gerektirir.

Geçerli trafik türleri: işlem

Gerekli sertifikalar: Premium

Dinamik VMMQ akıllı ve alış tarafı bir teknolojidir. Üç birincil geliştirme sağlamak için Sanal Makine Kuyruğu (VMQ), Sanal Alma Tarafı Ölçeklendirme (vRSS) ve VMMQ öncüllerini temel alır:

  • Daha az CPU çekirdeği kullanarak konak verimliliğini iyileştirir.
  • Ağ trafiği işlemenin CPU çekirdeklerine otomatik olarak ayarlanması, böylece VM'lerin beklenen aktarım hızını karşılamasına ve sürdürmesine olanak tanır.
  • "Ani" iş yüklerinin beklenen trafik miktarını almasını sağlar.

Dinamik VMMQ hakkında daha fazla bilgi için Yapay hızlandırmalar blog gönderisine bakın.

RDMA

RDMA, ağ bağdaştırıcısına bir ağ yığını boşaltmasıdır. SMB depolama trafiğinin işlem için işletim sistemini atlamasına izin verir.

RDMA, en az konak CPU kaynağı kullanarak yüksek aktarım hızı ve düşük gecikme süreli ağ iletişimi sağlar. Bu konak CPU kaynakları daha sonra ek VM'leri veya kapsayıcıları çalıştırmak için kullanılabilir.

Geçerli trafik türleri: konak depolama

Gerekli sertifikalar: Standart

Standart veya Premium AQ'ya sahip tüm bağdaştırıcılar RDMA'ya destek sağlar. RDMA, Azure Stack HCI'deki depolama iş yükleri için önerilen dağıtım seçeneğidir ve VM'ler için depolama iş yükleri (SMB kullanılarak) için isteğe bağlı olarak etkinleştirilebilir. Daha fazla bilgi için bu makalenin devamında yer alan "Konuk RDMA" bölümüne bakın.

Azure Stack HCI, İnternet Geniş Alan RDMA Protokolü (iWARP) veya Yakınsanmış Ethernet üzerinden RDMA (RoCE) protokol uygulamalarını kullanarak RDMA'yi destekler.

Önemli

RDMA bağdaştırıcıları yalnızca aynı RDMA protokolünü (iWARP veya RoCE) uygulayan diğer RDMA bağdaştırıcılarıyla çalışır.

Satıcıların tüm ağ bağdaştırıcıları RDMA'ları desteklemez. Aşağıdaki tabloda, sertifikalı Premium RDMA bağdaştırıcıları sunan satıcılar (alfabetik sırada) listelenmiştir. Ancak, bu listede RDMA'yı da destekleyen donanım satıcıları vardır. RDMA desteğini doğrulamak için Windows Sunucu Kataloğu'na bakın.

Not

InfiniBand (IB), Azure Stack HCI ile desteklenmez.

NIC satıcısı iWARP RoCE
Broadcom Hayır Yes
Chelsio Yes Hayır
Intel Yes Evet (bazı modeller)
Marvell (Qlogic/Cavium) Yes Yes
Nvidia (Mellanox) Hayır Yes

RDMA dağıtma hakkında daha fazla bilgi için SDN GitHub deposundan belgeyi indirin.

iWARP

iWARP İletim Denetimi Protokolü (TCP) kullanır ve isteğe bağlı olarak Öncelik Tabanlı Flow Denetimi (PFC) ve Gelişmiş İletim Hizmeti (ETS) ile geliştirilebilir.

Aşağıdakilerde iWARP kullanın:

  • Çok az ağ deneyiminiz var veya hiç yok ya da ağ anahtarlarını yönetmekte rahatsızsınız.
  • Raf üstü (ToR) anahtarlarınızı denetlemezsiniz.
  • Dağıtımın ardından çözümü yönetemezsiniz.
  • iWARP kullanan dağıtımlarınız zaten var.
  • Hangi seçeneği belirleyebileceğinizden emin değilsiniz.

RoCE

RoCE, Kullanıcı Veri Birimi Protokolü (UDP) kullanır ve güvenilirlik sağlamak için PFC ve ETS gerektirir.

Şu durumlara karşı RoCE kullanın:

  • Veri merkezinizde RoCE ile dağıtımlarınız zaten var.
  • DCB ağ gereksinimlerini rahatça yönetebilirsiniz.

Konuk RDMA

Konuk RDMA, VM'ler için SMB iş yüklerinin konaklarda RDMA kullanmanın aynı avantajlarını elde etmelerini sağlar.

Geçerli trafik türleri: Konuk tabanlı depolama

Gerekli sertifikalar: Premium

Konuk RDMA kullanmanın başlıca avantajları şunlardır:

  • Ağ trafiği işleme için NIC'ye CPU boşaltması.
  • Son derece düşük gecikme süresi.
  • Yüksek aktarım hızı.

Daha fazla bilgi için SDN GitHub deposundan belgeyi indirin.

SET

SET, Windows Server 2016 beri Windows Server işletim sistemine dahil edilmiş yazılım tabanlı bir ekip oluşturma teknolojisidir. SET, kullanılan ağ bağdaştırıcılarının türüne bağımlı değildir.

Geçerli trafik türleri: işlem, depolama ve yönetim

Gerekli sertifikalar: hiçbiri (SET işletim sisteminde yerleşiktir)

SET, Azure Stack HCI tarafından desteklenen tek grup oluşturma teknolojisidir. SET işlem, depolama ve yönetim trafiğiyle iyi çalışır.

Önemli

Yük Dengeleme/Yük Devretme (LBFO), Windows Server ile yaygın olarak kullanılan bir diğer ekip oluşturma teknolojisidir ancak Azure Stack HCI ile desteklenmez. Azure Stack HCI'de LBFO hakkında daha fazla bilgi için Azure Stack HCI'de Ekip Oluşturma blog gönderisine bakın.

SET, Azure Stack HCI için önemlidir çünkü aşağıdakileri etkinleştiren tek ekip oluşturma teknolojisidir:

  • RDMA bağdaştırıcıları grubu oluşturma (gerekirse).
  • Konuk RDMA.
  • Dinamik VMMQ.
  • Diğer önemli Azure Stack HCI özellikleri (bkz. Azure Stack HCI'de ekip oluşturma).

SET'in simetrik (özdeş) bağdaştırıcılar kullanılmasını gerektirdiğini unutmayın. Asimetrik bağdaştırıcıların ekip oluşturması desteklenmez. Simetrik ağ bağdaştırıcıları şunlara sahiptir:

  • make (satıcı)
  • model (sürüm)
  • hız (aktarım hızı)
  • yapılandırma

Bağdaştırıcıların simetrik olup olmadığını belirlemenin en kolay yolu hızların aynı olup olmadığını ve arabirim açıklamalarının eşleşip eşleşmediğini belirlemektir. Yalnızca açıklamada listelenen sayılarda sapabilir. Bildirilen yapılandırmanın Get-NetAdapterAdvancedProperty aynı özellik değerlerini listelediğinden emin olmak için cmdlet'ini kullanın.

Yalnızca sayı (#) ile sapma gösteren arabirim açıklamalarının bir örneği için aşağıdaki tabloya bakın:

Name Arabirim açıklaması Bağlantı hızı
NIC1 Ağ Bağdaştırıcısı #1 25 Gb/sn
NIC2 Ağ Bağdaştırıcısı #2 25 Gb/sn
NIC3 Ağ Bağdaştırıcısı #3 25 Gb/sn
NIC4 Ağ Bağdaştırıcısı #4 25 Gb/sn

Not

SET, Dinamik veya Hyper-V Bağlantı Noktası yük dengeleme algoritmalarını kullanarak yalnızca anahtardan bağımsız yapılandırmayı destekler. En iyi performans için 10 Gb/sn veya üzerinde çalışan tüm NIC'lerde Hyper-V bağlantı noktasının kullanılması önerilir.

RDMA trafiğinde dikkat edilmesi gerekenler

DCB uygularsanız, PFC ve ETS yapılandırmasının ağ anahtarları da dahil olmak üzere her ağ bağlantı noktasında düzgün uygulandığından emin olmanız gerekir. DcB, RoCE için gereklidir ve iWARP için isteğe bağlıdır.

RDMA'yı dağıtma hakkında ayrıntılı bilgi için SDN GitHub deposundan belgeyi indirin.

RoCE tabanlı Azure Stack HCI uygulamaları, doku ve tüm konaklar genelinde varsayılan trafik sınıfı dahil olmak üzere üç PFC trafik sınıfının yapılandırılmasını gerektirir.

Küme trafiği sınıfı

Bu trafik sınıfı, küme sinyalleri için ayrılmış yeterli bant genişliği olmasını sağlar:

  • Gerekli: Evet
  • PFC etkin: Hayır
  • Önerilen trafik önceliği: Öncelik 7
  • Önerilen bant genişliği ayırması:
    • 10 GbE veya daha düşük RDMA ağları = yüzde 2
    • 25 GbE veya üzeri RDMA ağları = yüzde 1

RDMA trafik sınıfı

Bu trafik sınıfı, Doğrudan Erişimli SMB kullanarak kayıpsız RDMA iletişimleri için ayrılmış yeterli bant genişliği olmasını sağlar:

  • Gerekli: Evet
  • PFC etkin: Evet
  • Önerilen trafik önceliği: Öncelik 3 veya 4
  • Önerilen bant genişliği rezervasyonu: Yüzde 50

Varsayılan trafik sınıfı

Bu trafik sınıfı, VM trafiği ve yönetim trafiği dahil olmak üzere kümede veya RDMA trafik sınıflarında tanımlanmayan diğer tüm trafiği taşır:

  • Gerekli: Varsayılan olarak (konakta yapılandırma gerekmez)
  • Flow denetimi (PFC) etkin: Hayır
  • Önerilen trafik sınıfı: Varsayılan olarak (Öncelik 0)
  • Önerilen bant genişliği ayırması: Varsayılan olarak (konak yapılandırması gerekmez)

trafik modellerini Depolama

SMB, Çok Kanallı SMB dahil olmak üzere Azure Stack HCI için depolama protokolü olarak birçok avantaj sağlar. Çok Kanallı SMB bu makalede ele alınmıyor, ancak trafiğin Çok Kanallı SMB kullanabileceği tüm olası bağlantılarda çoğullandığını anlamak önemlidir.

Not

Azure Stack HCI'de depolama trafiğini ayırmak için birden çok alt ağ ve VLAN kullanmanızı öneririz.

Aşağıdaki dört düğüm kümesi örneğini göz önünde bulundurun. Her sunucunun iki depolama bağlantı noktası vardır (sol ve sağ taraf). Her bağdaştırıcı aynı alt ağda ve VLAN'da olduğundan, Çok Kanallı SMB bağlantıları tüm kullanılabilir bağlantılara yayacaktır. Bu nedenle, ilk sunucudaki sol taraftaki bağlantı noktası (192.168.1.1), ikinci sunucudaki sol taraftaki bağlantı noktasına (192.168.1.2) bağlantı oluşturur. İlk sunucudaki sağ taraftaki bağlantı noktası (192.168.1.12), ikinci sunucudaki sağ taraftaki bağlantı noktasına bağlanır. Üçüncü ve dördüncü sunucular için benzer bağlantılar kurulur.

Ancak, bu gereksiz bağlantılar oluşturur ve ToR anahtarlarını (X ile işaretlenmiş) bağlayan bağlantıda (çok kasalı bağlantı toplama grubu veya MC-LAG) tıkanıklıklara neden olur. Aşağıdaki diyagrama bakın:

Diagram that shows a four-node cluster on the same subnet.

Önerilen yaklaşım, her bağdaştırıcı kümesi için ayrı alt ağlar ve VLAN'lar kullanmaktır. Aşağıdaki diyagramda, sağ bağlantı noktaları artık 192.168.2.x /24 ve VLAN2 alt akını kullanır. Bu, sol taraftaki bağlantı noktalarındaki trafiğin TOR1'de kalmasına ve sağ taraftaki bağlantı noktalarındaki trafiğin TOR2'de kalmasına olanak tanır.

Diagram that shows a four-node cluster on different subnets.

Trafik bant genişliği ayırma

Aşağıdaki tabloda, Azure Stack HCI'de yaygın bağdaştırıcı hızlarını kullanarak çeşitli trafik türlerinin örnek bant genişliği ayırmaları gösterilmektedir. Bunun, tüm trafik türlerinin (işlem, depolama ve yönetim) aynı fiziksel bağdaştırıcılar üzerinde çalıştığı ve SET kullanılarak ekip oluşturduğu yakınsanmış bir çözüm örneği olduğunu unutmayın.

Bu kullanım örneği en fazla kısıtlamayı oluşturduğundan, iyi bir temeli temsil eder. Ancak bağdaştırıcı sayısı ve hızları için permütasyonlar göz önünde bulundurularak, bu bir destek gereksinimi değil, bir örnek olarak düşünülmelidir.

Bu örnek için aşağıdaki varsayımlar yapılmıştır:

  • Takım başına iki bağdaştırıcı vardır.

  • Depolama Veri Yolu Katmanı (SBL), Küme Paylaşılan Birimi (CSV) ve Hyper-V (Dinamik Geçiş) trafiği:

    • Aynı fiziksel bağdaştırıcıları kullanın.
    • SMB kullanın.
  • SMB'ye DCB kullanılarak yüzde 50 bant genişliği ayırması verilir.

    • SBL/CSV en yüksek öncelikli trafiktir ve SMB bant genişliği ayırmasının yüzde 70'ini alır.
    • Dinamik Geçiş (LM) cmdlet'i kullanılarak Set-SMBBandwidthLimit sınırlıdır ve kalan bant genişliğinin yüzde 29'unu alır.
      • Dinamik Geçiş için kullanılabilir bant genişliği = 5 Gb/sn ise >ve ağ bağdaştırıcıları uygunsa RDMA kullanın. Bunu yapmak için aşağıdaki cmdlet'i kullanın:

        Set-VMHost VirtualMachineMigrationPerformanceOption SMB
        
      • Dinamik Geçiş için kullanılabilir bant genişliği 5 Gb/sn ise < , kesinti sürelerini azaltmak için sıkıştırmayı kullanın. Bunu yapmak için aşağıdaki cmdlet'i kullanın:

        Set-VMHost -VirtualMachineMigrationPerformanceOption Compression
        
  • Dinamik Geçiş trafiği için RDMA kullanıyorsanız, Dinamik Geçiş trafiğinin SMB bant genişliği sınırı kullanarak RDMA trafik sınıfına ayrılan bant genişliğinin tamamını tüketemediğinden emin olun. Bu cmdlet saniye başına bayt (Bps) cinsinden girdi aldığından, ağ bağdaştırıcıları saniyedeki bit sayısı (bps) cinsinden listelendiği için dikkatli olun. 6 Gb/sn bant genişliği sınırı ayarlamak için aşağıdaki cmdlet'i kullanın, örneğin:

    Set-SMBBandwidthLimit -Category LiveMigration -BytesPerSecond 750MB
    

    Not

    Bu örnekteki 750 MB/sn, 6 Gb/sn'ye eşittir.

Örnek bant genişliği ayırma tablosu aşağıda verilmiştir:

NIC hızı Gruplandırılmış bant genişliği SMB bant genişliği ayırma** SBL/CSV % SBL/CSV bant genişliği Dinamik Geçiş Yüzdesi Maksimum Dinamik Geçiş bant genişliği Sinyal Yüzdesi Sinyal bant genişliği
10 Gbps 20 Gb/sn 10 Gbps %70 7 Gb/sn ** 200 Mb/sn
25 Gb/sn 50 Gb/sn 25 Gb/sn %70 17,5 Gb/sn %29 7,25 Gb/sn %1 250 Mb/sn
40 Gbps 80 Gb/sn 40 Gbps %70 28 Gb/sn %29 11,6 Gb/sn %1 400 Mb/sn
50 Gb/sn 100 Gbps 50 Gb/sn %70 35 Gb/sn %29 14,5 Gb/sn %1 500 Mbps
100 Gbps 200 Gb/sn 100 Gbps %70 70 Gb/sn %29 29 Gb/sn %1 1 Gbps
200 Gb/sn 400 Gb/sn 200 Gb/sn %70 140 Gb/sn %29 58 Gb/sn %1 2 Gbps

* Dinamik Geçiş trafiği için bant genişliği ayırma 5 Gb/sn olduğundan <RDMA yerine sıkıştırma kullanın.

** Yüzde 50 örnek bir bant genişliği ayırma işlemidir.

Esnetilmiş kümeler

Esnetilmiş kümeler, birden çok veri merkezine yayılan olağanüstü durum kurtarma sağlar. En basit biçimiyle, esnetilmiş bir Azure Stack HCI küme ağı şöyle görünür:

Diagram that shows a stretched cluster.

Esnetilmiş küme gereksinimleri

Esnetilmiş kümeler aşağıdaki gereksinimlere ve özelliklere sahiptir:

  • RDMA tek bir siteyle sınırlıdır ve farklı siteler veya alt ağlar arasında desteklenmez.

  • Aynı sitedeki sunucular aynı rafta ve Katman 2 sınırında bulunmalıdır.

  • Siteler arasındaki konak iletişimi katman 3 sınırını geçmelidir; esnetilmiş Katman 2 topolojileri desteklenmez.

  • Diğer sitedeki iş yüklerini çalıştırmak için yeterli bant genişliğine sahip olmanız gerekir. Yük devretme durumunda alternatif sitenin tüm trafiği çalıştırması gerekir. Siteleri kullanılabilir ağ kapasitesinin yüzde 50'sinde sağlamanızı öneririz. Ancak yük devretme sırasında düşük performansa tolerans gösterebiliyorsanız bu bir gereksinim değildir.

  • Siteler arasındaki çoğaltma (kuzey/güney trafiği), yerel depolama (doğu/batı trafiği) ile aynı fiziksel NIC'leri kullanabilir. Aynı fiziksel bağdaştırıcıları kullanıyorsanız, bu bağdaştırıcıların SET ile birlikte kullanılması gerekir. Bağdaştırıcıların siteler arasındaki yönlendirilebilir trafik için sağlanan ek sanal NIC'leri de olmalıdır.

  • Siteler arasındaki iletişim için kullanılan bağdaştırıcılar:

    • Fiziksel veya sanal (konak vNIC) olabilir. Bağdaştırıcılar sanalsa, fiziksel NIC başına kendi alt ağinde ve VLAN'da bir vNIC sağlamalısınız.

    • Siteler arasında yönlendirilebilen kendi alt ağlarında ve VLAN'da olmalıdır.

    • RDMA cmdlet'i Disable-NetAdapterRDMA kullanılarak devre dışı bırakılmalıdır. cmdlet'ini kullanarak belirli arabirimleri kullanmak için Depolama Çoğaltma'ya Set-SRNetworkConstraint açıkça ihtiyaç duymanızı öneririz.

    • Depolama Çoğaltması için ek gereksinimleri karşılamalıdır.

Esnetilmiş küme örneği

Aşağıdaki örnekte esnetilmiş küme yapılandırması gösterilmektedir. Belirli bir sanal NIC'nin belirli bir fiziksel bağdaştırıcıyla eşlendiğinden emin olmak için Set-VMNetworkAdapterTeammapping cmdlet'ini kullanın.

Diagram that shows an example of stretched cluster storage.

Aşağıda, örnek esnetilmiş küme yapılandırmasının ayrıntıları gösterilmektedir.

Not

NIC adları, IP adresleri ve VLAN'lar gibi tam yapılandırmanız gösterilenden farklı olabilir. Bu yalnızca ortamınıza uyarlanabilen bir başvuru yapılandırması olarak kullanılır.

SiteA – Yerel çoğaltma, RDMA etkin, siteler arasında yönlendirilemeyen

Düğüm adı vNIC adı Fiziksel NIC (eşlenmiş) VLAN IP ve alt ağ Trafik kapsamı
NodeA1 vSMB01 pNIC01 711 192.168.1.1/24 Yalnızca Yerel Site
NodeA2 vSMB01 pNIC01 711 192.168.1.2/24 Yalnızca Yerel Site
NodeA1 vSMB02 pNIC02 712 192.168.2.1/24 Yalnızca Yerel Site
NodeA2 vSMB02 pNIC02 712 192.168.2.2/24 Yalnızca Yerel Site

SiteB – Yerel çoğaltma, RDMA etkin, siteler arasında yönlendirilemeyen

Düğüm adı vNIC adı Fiziksel NIC (eşlenmiş) VLAN IP ve alt ağ Trafik kapsamı
NodeB1 vSMB01 pNIC01 711 192.168.1.1/24 Yalnızca Yerel Site
NodeB2 vSMB01 pNIC01 711 192.168.1.2/24 Yalnızca Yerel Site
NodeB1 vSMB02 pNIC02 712 192.168.2.1/24 Yalnızca Yerel Site
NodeB2 vSMB02 pNIC02 712 192.168.2.2/24 Yalnızca Yerel Site

SiteA – Esnetilmiş çoğaltma, RDMA devre dışı, siteler arasında yönlendirilebilir

Düğüm adı vNIC adı Fiziksel NIC (eşlenmiş) IP ve alt ağ Trafik kapsamı
NodeA1 Esnetme1 pNIC01 173.0.0.1/8 Siteler Arası Yönlendirilebilir
NodeA2 Esnetme1 pNIC01 173.0.0.2/8 Siteler Arası Yönlendirilebilir
NodeA1 Esnetme2 pNIC02 174.0.0.1/8 Siteler Arası Yönlendirilebilir
NodeA2 Esnetme2 pNIC02 174.0.0.2/8 Siteler Arası Yönlendirilebilir

SiteB – Esnetilmiş çoğaltma, RDMA devre dışı, siteler arasında yönlendirilebilir

Düğüm adı vNIC adı Fiziksel NIC (eşlenmiş) IP ve alt ağ Trafik kapsamı
NodeB1 Esnetme1 pNIC01 175.0.0.1/8 Siteler Arası Yönlendirilebilir
NodeB2 Esnetme1 pNIC01 175.0.0.2/8 Siteler Arası Yönlendirilebilir
NodeB1 Esnetme2 pNIC02 176.0.0.1/8 Siteler Arası Yönlendirilebilir
NodeB2 Esnetme2 pNIC02 176.0.0.2/8 Siteler Arası Yönlendirilebilir

Sonraki adımlar