Adopting an open Network Operating System (NOS) like SONiC promotes disaggregation, a concept that liberates hardware from software constraints, allowing for a flexible, plug-and-play approach. This modular structure enables a unified software interface across different hardware architectures, enhancing supply chain flexibility and avoiding vendor lock-in. Custom in-house automation frameworks can be preserved without needing per-vendor adjustments. The DevOps-oriented model of SONiC accelerates feature deployment and rapid bug fixes, reducing dependence on vendor-specific release schedules. Moreover, the open-source ecosystem fosters innovation and broad collaboration, supporting custom use cases across various deployments. This freedom translates into significant cost efficiencies, reducing Total Cost of Ownership (TCO), Operational Expenditure (OpEx), and Capital Expenditure (CapEx), making it a compelling choice for modern networks.

Among the numerous open-source NOS solutions available, SONiC distinguishes itself through its growing adoption across enterprises, hyperscale data centers, and service providers. This success highlights its versatility and robustness. Open-source contributions have meticulously refined SONiC, tailoring it for specific use cases and enhancing its features while allowing adaptable architectures.

Key Attributes of SONiC:

Open Source:

• Vendor-neutral: Operates on any compatible vendor hardware.
• Accelerated feature deployment: Custom modifications and quick bug resolutions.
• Community-driven: Contributions benefit the broader SONiC ecosystem.
• Cost-effective: Reduces TCO, OpEx, and CapEx significantly.

Despite SONiC’s evident advantages, network operators often has these critical questions- Is SONiC suitable for my network?, What does support entail?, How do I ensure code quality?, and How do I train my team?. The true test of a NOS is its user experience. For open-source solutions like SONiC, success depends on delivering a seamless experience while ensuring robust vendor-backed support.

Operators considering SONiC typically fall into two categories: those with a self-sustaining ecosystem capable of handling an open NOS and those exploring its potential. For the former, SONiC may be customized to meet specific network demands, potentially involving a private distribution or vendor-backed commercial versions. The latter group, often seeking simpler use cases, typically relies on community SONiC, balancing its open-source nature with vendor validation.

The shift towards open networking, driven by disaggregation, has brought SONiC into the spotlight. Its flexibility, cost-effectiveness, and capacity for innovation make it an attractive option, especially for hyperscalers, enterprises, and service providers. By embracing open architecture and standard merchant silicon, SONiC provides a cost-efficient alternative to traditional closed systems, delivering equivalent features and support at a fraction of the price.

While companies like Microsoft, LinkedIn, and eBay have successfully integrated SONiC, they often encounter challenges such as vendor fragmentation, compatibility issues, and inconsistent support across hardware platforms. Managing diverse hardware can become complex due to each vendor’s unique configurations, while updates can disrupt operations by introducing compatibility problems. Integrating different SONiC versions across vendors may also lead to inconsistencies and unreliable telemetry data, adding further complications. Additionally, varying support levels make troubleshooting difficult, and operators often require additional training to navigate the nuances of each vendor’s implementation. Although these challenges can feel overwhelming, with careful planning, skilled personnel, and the right support, they can be effectively managed for a smooth and successful SONiC deployment.

PalC’s SONiC NetPro Suite directly addresses these challenges by offering comprehensive solutions designed to streamline SONiC adoption. Through the Ready, Deploy, and Sustain packages, PalC ensures end-to-end support, providing expert guidance to fill gaps in in-house expertise and fostering a DevOps-friendly culture for smooth operations. PalC’s strong partnerships with switch and ASIC vendors guarantee seamless integration and full infrastructure support, while its rigorous QA processes ensure performance and reliability. By offering customized support and clear cost assessments, PalC simplifies SONiC deployment, minimizing disruptions and ensuring a scalable, secure, and optimized network infrastructure.

Choosing the right SONiC version is crucial for network optimization. By assessing feature needs, community support, hardware compatibility, and security, organizations can make informed decisions that enhance network performance. SONiC’s evolution from a Microsoft project to a leading open-source NOS underscores its transformative potential and solidifies its role in future cloud networking.

The Power of PalC NetPulse
Efficiency and Control:

• L1 Cross Connect for EdgeCore Cassini Boxes: We’ve integrated L1 cross-connect capabilities for EdgeCore Cassini boxes, enhancing your control over network resources.
• Interface Configuration Management: Our NMS software offers streamlined configuration management for both Ethernet and Optical interfaces, simplifying network setup and maintenance.
• Inventory and User Management: PalC NetPulse provides robust inventory management, allowing you to keep track of network assets

Comprehensive Monitoring:
Peripheral Device Monitoring: Stay on top of your network’s health by monitoring peripheral devices. PalC NetPulse offers a holistic view of your infrastructure.

• Optical Parameter Monitoring: Get in-depth insights into optical parameters to ensure
  optimal performance.
• Topology Viewer and Alarms/Event Notification: Visualize your network’s topology
  and receive real-time alarms and notifications. Stay informed and respond swiftly.
• Microservices Compatible Architecture: Our NMS is built on a microservices-
  compatible architecture, ensuring flexibility and scalability for your evolving network
  needs.

What Lies Ahead in Our Roadmap:
We are committed to enhancing our NMS software further to meet the ever-changing demands of network management:
Layer-2 Configuration Features: We are adding more layer-2 configuration features to provide you with a more comprehensive toolkit.

• Advanced Automation: Our NetPulse will have enhanced network automation capabilities, simplifying complex tasks.
• Integration with Cloud-Based Environments: In line with the industry’s shift towards cloud-based solutions, we are working on seamless integration with cloud environments.

Supported Software for Versatility
PalC NetPulse is compatible with various software platforms, making it versatile and adaptable to different deployment scenarios:

SONiC for Data-Center Deployments: Perfect for data-center networks, PalC NetPulse integrates seamlessly with SONiC.

• Goldstone for Packet Optical Deployments: If your network requires packet optical solutions, PalC NetPulse has you covered with Goldstone compatibility.
• OcNOS for Data Center/CSR Requirements: Data center and carrier-grade service provider networks benefit from our support for OcNOS.

Figure 1 – perfSONAR architecture

In the architecture diagram (Figure 1) mentioned above, the key components have been outlined below:

• perfsonar tools – This module contains different utilities responsible for carrying out the actual network measurements. Twamp tool consists of twping binary which is used on client side and twampd binary which runs on the server/responder side. Similarly, we have owamp, powstream, traceroute, tracepath, paris-traceroute and other diagnostic methods. We can use these tools for measurement of following performance metrics.
• Latency – measuring one-way and two-way delays
• Packet loss, duplicate packets, jitter
• Tracing network path
• Trace path – Identifying the path MTU
• Throughput – Measuring the bandwidth availability

An overview of supported tools –

• owamp – A set of tools primarily used for measuring packet loss and one-way delay. It includes the command owping for single short-lived tests and the powstream command for long-running background tests.
• twamp – A tool primarily used for measuring packet loss and two-way delay. It has an increased accuracy over tools like ping without the same clock synchronization requirements as OWAMP. The client tool is named twping and can be used to run against TWAMP servers. You can use the provided twampd server or many routers also come with vendor implementation of TWAMP servers that can be tested against.
• iperf3 – A rewrite of the classic iperf tool used to measure network throughput and associated metrics.
• iperf2 – Also known as just iperf, a common tool used to measure network throughput that has been around for many years.
• nuttcp – Another throughput tool with some useful options not found in other tools.
• traceroute – The classic packet trace tool used in identifying network paths
• tracepath – Another path trace tool that also measures path MTU
• paris-traceroute – A packet trace tool that attempts to identify paths in the presence of load balancers
• ping – The classic utility for determining reachability, round-trip time (RTT), and basic packet loss.
• pScheduler – The pScheduler is responsible for scheduling the tests based on user configuration and available time slots on the machine. It finds time-slots to run the tools while avoiding scheduling conflicts that would negatively impact results, Executing the tools and gathering results, and send the results to the configured archiver
• Archiving – This module contains the esmond component which stores the measurement information for the tests run. It is often referred to as the measurement archive (MA) and the term is used interchangeably with esmond. Esmond can be installed in each end device, or in the central server device which collects all test results.
• Psconfig pscheduler agent – This module will get the user configurations from a file in json format and then use it to communicate with the pScheduler to schedule the tests.
• Psconfig maddash agent – The agent responsible for reading the same configuration json file and creating graphs and charts based on the conducted test results.

The user has different installation options for different end devices such as centralized servers, clients, and servers. Here centralized server refers to devices that register clients and servers, manage to conduct tests, collect results and act as a central server where other devices communicate anything related to test parameters. Clients are devices that conduct the throughput, latency, and RTT tests with another end device. Servers are end devices that act as the receiver or reflector for measuring network health. The tests are conducted from the client to the server, either from the client interactive shell based on demand or from the central server using a configuration json/psconfig web admin GUI.

PerfSONAR can be installed in CentOS or Ubuntu based Linux environments. The various offerings are,

• Perfsonar-tools – This package installs only the command line binaries needed to run on-demand tests such as iperf, iperf3 and owamp. Often used for debugging network disruptions rather than for dedicated monitoring of network.
• Perfsonar-testpoint – This package contains command-line binaries to run on-demand tests, in addition to tools to scheduling of tests conduct tests based on central server instructions in json files, and participate in node discovery conducted in central servers. But this package lacks software to store measurement data in a local archive.
• Perfsonar-core – This package is dedicated for devices that run tests themselves, instruct others to run the tests and store measurement data themselves.
•  Perfsonar-toolkit – This package includes everything present in perfsonar-core including the web-admin to conduct tests via GUI.
•  Personar-centralmanagement – This package is installed in central management servers that instruct others to run tests and manage a number of hosts, while also being able to retrieve and archive the test results from a number of hosts.

Figure 2 below explains the bundle options,

We can run network measurement tests in two different modes.

• Full mesh mode – where all the perfsonar hosts in the network are involved in running the tests to each other, essentially all the hosts should be running perfSONAR
• Disjoint mode – where the tests are run from one set of perfsonar hosts to another set of hosts (these hosts can be other 3rd party devices as well)

Once the scheduled tests are completed, results ae published to the central management server archiver, which is picked up by the maddash agent and visualizations are generated. Any present issues can be detected by observing the graphs and charts data, drawn up by the maddash agent.

TWAMP and TWAMP-light

Twping hosted by TWAMP (Two-Way Active Measurement Protocol) is a tool used to generate IP performance metrics between a client and server device by using two-way or round-trip tests. TWAMP is a development from the OWAMP (One-Way Active Measurement Protocol) method. TWAMP uses four entities in the topology, control-client and session-sender packaged into the client device and session-reflector and the server are packaged into the server device.

Initially, a TCP socket connection is established between the client and server in the TWAMP dedicated TCP port 862, after which the server sends a greeting message, that contains the security authentication modes supported by the server. Upon receiving the greeting message, the client sends the test conditions and the client information on which IP of the server device the test packets will be sent to. If the server agrees to conduct the described tests, the test begins as soon as the client sends a Start-Sessions or Start-N-Session message. This process is referred to as a twamp-control process

As part of a test, the server sends a stream of UDP-based test packets to the server, and the server responds to each received packet with a response UDP-based test packet. When the client receives the response packets from the session-reflector, the information is used to calculate two-way delay, packet loss, and packet delay variation between the two devices.

The user is provided with an option to bypass the TWAMP control process and conduct a TWAMP-light test. In a TWAMP-light test, the entities present are only the session sender and the session reflector. The initial TCP connection between the server and client is bypassed and only the stream of UDP-based test packets is sent and received by the client. But to run a TWAMP-light test, the server IP and the UDP port which will reflect the TWAMP packets, needs to be added as a part of the reflector configuration in the server. The client that runs a TWAMP-light test, will need to send the UDP packets to this configured IP and UDP port, failing which will result in the sent packets being dropped and loss of test metrics.

Figure 3 and 4 show the TWAMP and TWAMP-light protocol components

Figure 3 – TWAMP

Figure 4 – TWAMP-light

Adding sites to Netbox:-

a) Using GUI

b) Get details of sites using Rest API: –

Response: –

Adding interface to device: –

Get interface details using ID: –

Response: –

Assign IP address to interface to Device: –

Get IP-address using ID: –

Response: –