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

Summary

This is not a CLI manual to read end to end. The goal is more practical:

A second-screen reference for ST 2110 commissioning, answering “which command should I check on this platform?” quickly.

Scope:

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

Focus areas:

• PTP / ST 2059 readiness
• IGMP snooping and multicast membership
• PIM-SSM and multicast routing
• QoS / DSCP / queue behavior
• Interface counters, drops, and buffer checks
• A/B fabric validation

Important note: These commands are not production configuration templates. They are commissioning references. EOS, NX-OS, Cumulus Linux, and Onyx syntax can vary by software release, license, ASIC, switch model, and network design. Validate every command against your vendor documentation and lab environment before production use.

1. Platform split

In ST 2110, “switch CLI” does not mean one single world.

Be especially careful on the NVIDIA side. A device described as a “Mellanox switch” might be running Cumulus Linux or Onyx. Those are different command worlds.

2. What should we check first during commissioning?

In ST 2110 troubleshooting, jumping directly to the most complex command usually wastes time. The order should be:

1. Are interfaces up and running at the expected speed?
2. Is MTU correct?
3. Is VLAN / routed interface state correct?
4. Is PTP lock and domain state expected?
5. Is IGMP membership present?
6. Is multicast route or snooping state correct?
7. Are there QoS queue drops?
8. Are A and B fabrics truly independent?
9. Is the receiver joining the correct multicast group?
10. Are there RTP packet loss, sequence gaps, or buffer drops?

Typical MTU note:

For ST 2110-20 uncompressed video, most designs use 9000+ byte jumbo MTU end to end. Sender, switch, and receiver hops must be validated against the same MTU expectation; otherwise fragmentation or silent drops can appear.

3. Arista EOS quick reference

Platform note: The commands in this section are common EOS commissioning checks. Some counter and platform commands vary by ASIC, EOS release, and switch model; validate platform-specific counters in a lab.

3.1 Interface and basic health

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

What to check:

• Is link speed correct: 25G, 100G, 400G?
• Are CRC, symbol errors, or input discards increasing?
• Is optical power within range?
• If port-channel is used, are member ports really up?

3.2 PTP checks

1
2
3
4
5

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

Commissioning note:

• Confirm that the PTP domain matches the expected design.
• If the switch acts as boundary clock or transparent clock, confirm runtime state, not only configuration.
• This article does not go deep into PTP theory; use the PTP/ST 2059 article for that.

3.3 IGMP and 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

What to check:

• Did the receiver actually join the expected multicast group?
• Does A fabric join the A group and B fabric join the B group?
• Is there unknown multicast flooding?
• Is the querier present on the correct VLAN?
• If PIM-SSM is used, was IGMPv3 support validated? A receiver or port falling back to IGMPv2 can prevent (S,G) joins from forming.

3.4 QoS and queues

1
2
3
4

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

Note:

• EOS commands vary by switch family.
• show platform trident counters is an example specific to older Trident/Trident+ ASIC-based EOS platforms. On Jericho, Tomahawk, or newer ASIC families, the equivalent platform counter command may live under a different hierarchy.
• For ST 2110, the important thing is not only that QoS config exists, but that drop counters are zero or within the expected operational threshold.

4. Cisco NX-OS quick reference

Platform note: The commands in this section are references for Nexus/NX-OS commissioning. PTP, queue, and hardware internal commands can vary by NX-OS release, Nexus model, and line card family.

4.1 Interface and basic health

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

What to check:

• If port-channel is used, is hashing placing a flow on an unexpected link?
• Are input discards or queue drops increasing?
• Is interface MTU suitable for media payloads?

4.2 PTP checks

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

On Cisco NX-OS, PTP platform support depends on model and release. Boundary clock behavior, PTP offload, and supported clock modes must be checked carefully for the exact Nexus platform. For PTP theory, the ST 2059 profile, and domain behavior, refer to the separate PTP/ST 2059 article.

4.3 IGMP, PIM, and 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

What to check:

• Is the receiver join in the correct VLAN/VRF?
• Are PIM neighbors established?
• If source-specific multicast is used, is (S,G) state correct?
• If PIM-SSM is used, was IGMPv3 support validated? A receiver or intermediate port falling back to IGMPv2 can prevent (S,G) joins from forming.
• Does multicast route state match the expected A/B path design?

4.4 QoS and queues

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

Note:

• hardware internal commands vary by NX-OS release and platform.
• During commissioning, the goal is to confirm whether media queues drop packets and whether PTP, media, and management traffic are classified into the expected classes.

5. NVIDIA Spectrum / Cumulus Linux quick reference

Platform note: This section targets the Cumulus Linux operation model on NVIDIA Spectrum switches. Command output can vary by Cumulus release, Linux kernel, FRR version, switchd/SDK, and platform profile.

Cumulus Linux uses Linux networking, FRR, and NVIDIA tooling rather than a classic switch-only CLI.

5.1 Interface and link checks

1
2
3
4
5
6

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

What to check:

• Are front-panel ports such as swp1, swp2 up?
• Are speed, autoneg, FEC, and optics as expected?
• Are discards, drops, or errors increasing in ethtool -S?

5.2 Bridge, VLAN, and 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 note:

• In Cumulus, treat L2 bridge state and FRR L3 multicast state as related but separate views.
• If an ST 2110 receiver sends a join, read bridge mdb show and IGMP/PIM state together.
• In PIM-SSM designs, confirm that the receiver and access path use IGMPv3. IGMPv2 fallback can make source-specific joins disappear.

5.3 PTP checks

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

Note:

• On Cumulus, PTP is often inspected using Linux PTP tooling.
• Interface PHC, ptp4l profile, and phc2sys behavior must be validated separately.
• For PTP/ST 2059 logic and domain planning, refer to the separate PTP/ST 2059 article.

5.4 QoS and queues

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

On NVIDIA Spectrum platforms, queue and buffer visibility depends on Cumulus version, SDK, and telemetry integration. CLI is useful for spot checks; gNMI/telemetry is better for production monitoring.

6. Mellanox / NVIDIA Onyx quick reference

Platform note: This section is for Mellanox/NVIDIA Onyx CLI deployments. Onyx release and switch model can affect command names; do not use this section for Spectrum switches running Cumulus Linux.

Onyx is a different CLI world from Cumulus Linux. Even on similar switch hardware, changing the OS changes the command model.

6.1 Interface and basic health

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, and 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

Note: If PIM-SSM is used, IGMPv3 support must be validated separately. A receiver or switch port falling back to IGMPv2 can prevent (S,G) join state from forming.

For PTP/ST 2059 details, these show commands are not enough by themselves; domain, grandmaster, boundary clock, and timing-reference design should be validated with the logic from the separate PTP/ST 2059 article.

6.3 QoS

1
2
3

show qos
show interfaces ethernet 1/1 counters
show buffers

Note:

• Onyx command syntax can vary by release.
• If the platform runs Cumulus, use the Cumulus section instead of this one.

7. A/B fabric validation commands

The most dangerous mistake in ST 2022-7 or A/B redundant ST 2110 design is this:

A and B look separate in the drawing, but physically or logically share the same fault domain.

Checklist:

Questions to answer separately for A and B:

• Can path A carry the programme by itself?
• Can path B carry the programme by itself?
• Does the receiver see A and B flows at the same time?
• If the A link fails, does the B flow arrive over a truly independent path?
• If the B link fails, does the A flow continue?
• Does the PTP/time reference survive both failure cases?

8. Symptom-to-command quick reference

During commissioning, “which command should I check?” usually starts with a symptom. The table below is a quick navigation aid:

9. QoS/DSCP quick check logic

Writing QoS config is easy. Proving that it works is harder.

Practical check:

1. Does the sender mark DSCP?
2. Does the switch preserve DSCP at ingress?
3. Does queue mapping match the design?
4. Are there egress queue drops?
5. Are PTP, media, and management traffic falling into the same queue?
6. During a congestion test, which class drops?

Typical split:

These DSCP values are not universal rules. Some facilities use CS7 for PTP, EF for audio, and AF41/AF4x for video; some vendor profiles recommend different mappings. The important point is not the label alone but end-to-end consistency: the sender marks traffic, the switch preserves it at ingress, queue mapping behaves as designed, and egress queues do not drop media.

10. Commissioning playbook

Field flow:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

1. Validate links
2. Validate MTU and VLAN/L3 addressing
3. Validate PTP lock and domain
4. Check whether IGMP joins appear
5. Check multicast route or snooping state
6. Check QoS queue drops
7. Break path A and confirm B survives
8. Break path B and confirm A survives
9. Check whether the receiver merged output raises alarms
10. Save the evidence: config, show output, timestamp

At the end of commissioning, “it works” is not enough. Record:

• Switch OS version
• Running config snapshot
• PTP state output
• IGMP/multicast state output
• QoS/drop counter output
• A/B failover test result
• Receiver alarm and merge state result

11. Conclusion

ST 2110 network commissioning is not about memorizing one vendor command. The real work is applying the same validation logic with the correct commands on each platform.

Arista EOS, Cisco NX-OS, NVIDIA Cumulus, and Mellanox Onyx are different CLI worlds. But from an ST 2110 perspective, the truth we are looking for is the same:

Is the RTP media flow being transported without loss, with timing intact, observable behavior, and properly separated A/B fault domains?

This article should be treated as a practical field reference for answering that question faster.

The commands in this article are point-in-time validation tools. For continuous and automated monitoring, they should be complemented by the gNMI, exporter, dashboard, and alerting approach described in the ST 2110 Monitoring article.

References

• 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
• Related article: ST 2022-7 Hitless Switching
• Related article: PTP and SMPTE ST 2059
• Related article: ST 2110 Monitoring