ST 2110 Commissioning CLI Reference: Arista EOS, Cisco NX-OS ve NVIDIA Spectrum

Özet

Bu yazı uçtan uca okunacak bir CLI manual değil. Amaç daha pratik:

ST 2110 commissioning sırasında ikinci ekranda açık tutacağın, “hangi platformda hangi komuta bakıyorduk?” sorusunu hızlı cevaplayan bir referans.

Kapsam:

• Arista EOS
• Cisco Nexus / NX-OS
• NVIDIA Spectrum / Cumulus Linux
• Mellanox / NVIDIA Onyx

Odak noktaları:

• PTP / ST 2059 readiness
• IGMP snooping ve multicast membership
• PIM-SSM ve multicast routing
• QoS / DSCP / queue davranışı
• Interface counter, drop ve buffer kontrolü
• A/B fabric doğrulama

Önemli not: Buradaki komutlar production config şablonu değil, commissioning referansıdır. EOS, NX-OS, Cumulus Linux ve Onyx syntax’ı sürüm, lisans, ASIC, switch modeli ve network tasarımına göre değişebilir. Production’a uygulamadan önce kendi vendor dokümanınız ve lab ortamınızla doğrulayın.

1. Platform ayrımı

ST 2110 tarafında “switch komutu” demek tek bir dünya demek değildir.

NVIDIA tarafında özellikle dikkatli olmak gerekir. “Mellanox switch” dediğimiz cihaz Cumulus Linux da çalıştırıyor olabilir, Onyx de çalıştırıyor olabilir. Komut dünyaları aynı değildir.

2. Commissioning sırasında önce neye bakılır?

ST 2110 troubleshooting’de doğrudan en karmaşık komuta atlamak genellikle zaman kaybettirir. Sıra şu olmalı:

1. Interface up/down ve speed doğru mu?
2. MTU beklenen değerde mi?
3. VLAN / routed interface doğru mu?
4. PTP lock ve domain beklenen durumda mı?
5. IGMP membership oluşuyor mu?
6. Multicast route veya snooping state doğru mu?
7. QoS queue drop var mı?
8. A ve B fabric birbirinden gerçekten bağımsız mı?
9. Receiver doğru multicast group’a join oluyor mu?
10. RTP packet loss, sequence gap veya buffer drop var mı?

Tipik MTU notu:

ST 2110-20 sıkıştırılmamış video için çoğu tasarım uçtan uca 9000+ byte jumbo MTU kullanır. Sender, switch ve receiver path üzerindeki her hop aynı MTU beklentisiyle doğrulanmalıdır; aksi halde fragmentasyon veya sessiz drop sorunları görülebilir.

3. Arista EOS hızlı referans

Platform notu: Bu bölümdeki komutlar EOS ailesinde sık kullanılan commissioning kontrolleridir. ASIC, EOS release’i ve switch modeline göre bazı sayaç veya platform komutları değişebilir; özellikle platform-spesifik counter komutlarını lab’de doğrulayın.

3.1 Interface ve temel sağlık

1
2
3
4
5
6

show interfaces status
show interfaces Ethernet1
show interfaces Ethernet1 counters errors
show interfaces Ethernet1 transceiver
show interfaces counters rates
show lldp neighbors

Bakılacak şeyler:

• Link speed beklenen değer mi? 25G, 100G, 400G?
• CRC, symbol error, input discard var mı?
• Optik power seviyesi sınırda mı?
• Port-channel varsa member port’lar gerçekten up mı?

3.2 PTP kontrolü

1
2
3
4
5

show ptp
show ptp clock
show ptp port
show ptp foreign-master
show logging | include PTP

Commissioning notu:

• ST 2110 için PTP domain’in beklenen domain ile uyumlu olduğunu doğrula.
• Switch boundary clock veya transparent clock rolünde ise bunu sadece config’te değil runtime state’te de gör.
• PTP sorununu bu makalede derinleştirmiyoruz; detay için PTP/ST 2059 yazısına bak.

3.3 IGMP ve multicast

1
2
3
4
5
6

show ip igmp snooping
show ip igmp snooping groups
show ip igmp groups
show ip mroute
show ip pim neighbor
show ip pim interface

Bakılacak şeyler:

• Receiver gerçekten beklenen multicast group’a join olmuş mu?
• Join A fabric’te A group’a, B fabric’te B group’a mı gidiyor?
• Unknown multicast flooding var mı?
• Querier doğru VLAN’da mı?
• PIM-SSM kullanılıyorsa IGMPv3 desteği doğrulandı mı? IGMPv2’ye düşen receiver veya port, (S,G) join’inin hiç oluşmamasına neden olabilir.

3.4 QoS ve queue

1
2
3
4

show qos interfaces
show interfaces counters queue
show platform trident counters
show policy-map interface

Not:

• EOS komutları switch ailesine göre değişebilir.
• show platform trident counters Trident/Trident+ ASIC tabanlı eski EOS platformlarına özgü bir örnektir. Jericho, Tomahawk veya daha yeni ASIC ailelerinde karşılık gelen platform counter komutu farklı hiyerarşide olabilir.
• ST 2110 için kritik olan sadece QoS config’in varlığı değil, drop counter’ların sıfır veya beklenen seviyede olmasıdır.

4. Cisco NX-OS hızlı referans

Platform notu: Bu bölümdeki komutlar Nexus/NX-OS commissioning kontrolleri için referanstır. NX-OS release’i, Nexus modeli ve linecard ailesine göre PTP, queue ve hardware internal komutları değişebilir.

4.1 Interface ve temel sağlık

1
2
3
4
5
6

show interface status
show interface ethernet 1/1
show interface ethernet 1/1 counters errors
show interface transceiver details
show lldp neighbors
show port-channel summary

Bakılacak şeyler:

• Port-channel varsa hashing yüzünden tek flow beklenmeyen linke mi düşüyor?
• Input discard veya queue drop var mı?
• Interface MTU media payload için uygun mu?

4.2 PTP kontrolü

1
2
3
4
5

show ptp brief
show ptp clock
show ptp port interface ethernet 1/1
show ptp corrections
show logging logfile | include PTP

Cisco NX-OS tarafında PTP platform desteği model ve release’e göre değişir. Bazı Nexus platformlarında PTP boundary clock davranışı, PTP offload ve supported clock mode ayrıntıları özellikle kontrol edilmelidir. PTP teorisi, ST 2059 profili ve domain davranışı için ayrı PTP/ST 2059 yazısına bakılmalıdır.

4.3 IGMP, PIM ve multicast

1
2
3
4
5
6

show ip igmp snooping
show ip igmp snooping groups
show ip igmp groups
show ip mroute
show ip pim neighbor
show ip pim interface

Bakılacak şeyler:

• Receiver join’i doğru VLAN/VRF içinde mi?
• PIM neighbor oluşmuş mu?
• Source-specific multicast kullanılıyorsa (S,G) state doğru mu?
• PIM-SSM için IGMPv3 desteği doğrulandı mı? IGMPv2’ye düşen receiver veya ara port, (S,G) join’inin oluşmamasına yol açabilir.
• Multicast route A ve B path’te simetrik beklentiye uygun mu?

4.4 QoS ve queue

1
2
3
4

show policy-map interface
show queuing interface ethernet 1/1
show interface ethernet 1/1 counters detailed
show hardware internal buffer info pkt-stats

Not:

• hardware internal komutları NX-OS release ve platforma göre değişebilir.
• Commissioning sırasında amaç, medya queue’larında drop olup olmadığını ve PTP/management/media trafiğinin doğru class’a girdiğini doğrulamaktır.

5. NVIDIA Spectrum / Cumulus Linux hızlı referans

Platform notu: Bu bölüm NVIDIA Spectrum üzerinde Cumulus Linux operasyon modelini hedefler. Cumulus release’i, Linux kernel, FRR sürümü, switchd/SDK ve platform profiline göre komut çıktıları değişebilir.

Cumulus Linux tarafında klasik switch CLI yerine Linux networking, FRR ve NVIDIA araçları birlikte kullanılır.

5.1 Interface ve link kontrolü

1
2
3
4
5
6

ip link show
ip -br link
ip -br addr
ethtool swp1
ethtool -S swp1
lldpctl

Bakılacak şeyler:

• swp1, swp2 gibi front-panel port’lar up mı?
• Speed, autoneg, FEC ve optics değerleri beklenen gibi mi?
• ethtool -S içinde discard/drop/error artıyor mu?

5.2 Bridge, VLAN ve multicast state

1
2
3
4
5
6
7

bridge link
bridge vlan show
bridge mdb show
ip mroute show
vtysh -c "show ip pim neighbor"
vtysh -c "show ip pim interface"
vtysh -c "show ip igmp groups"

Commissioning notu:

• Cumulus’ta L2 bridge state ile FRR L3 multicast state’i ayrı dünyalar gibi düşün.
• ST 2110 receiver join’i geliyorsa bridge mdb show ve IGMP/PIM state birlikte okunmalı.
• PIM-SSM tasarımında receiver ve access path’in IGMPv3 kullandığını doğrula. IGMPv2 fallback, source-specific join’in kaybolmasına neden olabilir.

5.3 PTP kontrolü

1
2
3
4
5
6

timedatectl
pmc -u -b 0 "GET CURRENT_DATA_SET"
pmc -u -b 0 "GET TIME_STATUS_NP"
pmc -u -b 0 "GET PORT_DATA_SET"
journalctl -u ptp4l
journalctl -u phc2sys

Not:

• Cumulus tarafında PTP çoğu zaman Linux PTP araçlarıyla okunur.
• Interface PHC, ptp4l profile ve phc2sys ilişkisi ayrı doğrulanmalıdır.
• PTP/ST 2059 mantığı ve domain planı için ayrı PTP/ST 2059 yazısına bakılmalıdır.

5.4 QoS ve queue

1
2
3
4

tc -s qdisc show dev swp1
tc -s class show dev swp1
ethtool -S swp1 | grep -i drop
ethtool -S swp1 | grep -i discard

NVIDIA Spectrum platformlarında queue ve buffer görünürlüğü Cumulus sürümü, SDK ve telemetry entegrasyonuna göre değişebilir. CLI ile anlık kontrol yapılabilir; production izleme için gNMI/telemetry daha doğru yaklaşımdır.

6. Mellanox / NVIDIA Onyx hızlı referans

Platform notu: Bu bölüm Mellanox/NVIDIA Onyx CLI kullanan kurulumlar içindir. Onyx release’i ve switch modeli komut adlarını etkileyebilir; bu bölüm Cumulus Linux çalıştıran Spectrum switch’ler için kullanılmamalıdır.

Onyx, Cumulus Linux’tan farklı bir CLI dünyasıdır. Aynı switch ailesinde bile OS değiştiğinde komut seti değişebilir.

6.1 Interface ve temel sağlık

1
2
3
4
5

show interfaces status
show interfaces ethernet 1/1
show interfaces ethernet 1/1 counters
show lldp neighbors
show interfaces transceiver

6.2 PTP, IGMP ve multicast

1
2
3
4
5
6
7
8

show ptp
show ptp status
show ptp interface ethernet 1/1
show ptp interface ethernet 1/1 counters
show ip igmp snooping
show ip igmp groups
show ip mroute
show ip pim neighbors

Not: PIM-SSM kullanılıyorsa IGMPv3 desteği ayrıca doğrulanmalıdır. IGMPv2’ye düşen receiver veya switch port’u, (S,G) join state’inin oluşmamasına neden olabilir.

PTP/ST 2059 ayrıntıları için bu bölümdeki show komutları yeterli değildir; domain, grandmaster, boundary clock ve zaman referansı tasarımı ayrı PTP/ST 2059 yazısındaki mantıkla doğrulanmalıdır.

6.3 QoS

1
2
3

show qos
show interfaces ethernet 1/1 counters
show buffers

Not:

• Onyx command syntax release’e göre değişebilir.
• Eğer platform Cumulus çalıştırıyorsa bu bölüm değil, Cumulus bölümü kullanılmalıdır.

7. A/B fabric doğrulama komutları

ST 2022-7 veya A/B redundant ST 2110 tasarımında en tehlikeli hata şudur:

Çizimde A ve B ayrı görünür, ama fiziksel veya logical olarak aynı fault domain’i paylaşırlar.

Kontrol listesi:

A ve B için ayrı ayrı cevaplanması gereken sorular:

• A path tek başına yayını taşıyor mu?
• B path tek başına yayını taşıyor mu?
• Receiver A ve B flow’larını aynı anda görüyor mu?
• A link kesildiğinde B flow gerçekten bağımsız path’ten geliyor mu?
• B link kesildiğinde A flow aynı şekilde devam ediyor mu?
• PTP/time reference iki arıza senaryosunda da korunuyor mu?

8. Semptomdan komuta hızlı başvuru

Commissioning sırasında çoğu zaman “hangi komuta bakayım?” sorusu bir belirtiyle başlar. Aşağıdaki tablo hızlı yön bulmak içindir:

9. QoS/DSCP hızlı kontrol mantığı

ST 2110’da QoS yazmak kolay, doğru çalıştığını kanıtlamak zordur.

Pratik kontrol:

1. Sender DSCP işaretliyor mu?
2. Switch ingress’te DSCP’yi koruyor mu?
3. Queue mapping beklenen gibi mi?
4. Egress queue drop var mı?
5. PTP, media ve management aynı queue’ya düşüyor mu?
6. Congestion testinde hangi class drop ediyor?

Tipik ayrım:

Buradaki DSCP değerleri evrensel kural değildir. Bazı tesisler PTP için CS7, audio için EF, video için AF41/AF4x gibi yaklaşımlar kullanır; bazı vendor profilleri farklı mapping önerebilir. Önemli olan DSCP değerinden çok uçtan uca mapping’in tutarlı olmasıdır: sender işaretler, switch ingress bunu korur, queue mapping doğru çalışır ve egress’te drop oluşmaz.

10. Commissioning playbook

Sahada hızlı akış:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

1. Linkleri doğrula
2. MTU ve VLAN/L3 adreslemeyi doğrula
3. PTP lock ve domain'i doğrula
4. IGMP join oluşuyor mu bak
5. Multicast route veya snooping state'i kontrol et
6. QoS queue drop var mı bak
7. A path'i kes, B devam ediyor mu gör
8. B path'i kes, A devam ediyor mu gör
9. Receiver merged output alarm veriyor mu kontrol et
10. Son durumu kaydet: config, show output, timestamp

Commissioning sonunda sadece “çalışıyor” demek yetmez. Şunlar kayıt altına alınmalı:

• Switch OS versiyonu
• Running config snapshot
• PTP state çıktısı
• IGMP/multicast state çıktısı
• QoS/drop counter çıktısı
• A/B failover test sonucu
• Receiver alarm ve merge state sonucu

11. Sonuç

ST 2110 network commissioning, tek bir vendor CLI komutunu ezberlemekten ibaret değildir. Asıl iş, aynı doğrulama mantığını her platformda doğru komutlarla uygulamaktır.

Arista EOS, Cisco NX-OS, NVIDIA Cumulus ve Mellanox Onyx farklı CLI dünyalarıdır. Ama ST 2110 açısından aradığımız gerçek aynıdır:

RTP media flow kayıpsız, zamanlı, izlenebilir ve A/B fault domain’leri ayrılmış şekilde taşınıyor mu?

Bu yazı o soruyu sahada daha hızlı cevaplamak için bir referans olarak düşünülmelidir.

Bu makaledeki komutlar anlık doğrulama içindir. Sürekli ve otomatik izleme için ST 2110 Monitoring yazısındaki gNMI, exporter, dashboard ve alarm yaklaşımıyla tamamlanmalıdır.

Referanslar

• Cisco Nexus 9000 NX-OS System Management Configuration Guide - Precision Time Protocol
• Arista EOS Precision Time Protocol Documentation
• NVIDIA Cumulus Linux Documentation
• NVIDIA Networking Documentation
• İlgili yazı: ST 2022-7 Hitless Switching
• İlgili yazı: PTP ve SMPTE ST 2059
• İlgili yazı: ST 2110 Monitoring