SDN and network automation: benefits and limits

What SDN changes about network control

Software Defined Networking separates control functions from packet forwarding and makes network behaviour programmable. The control plane determines how traffic is forwarded; the data plane carries out those decisions. RFC 7426 also distinguishes a management plane for configuration, monitoring and maintenance. A central management screen alone therefore does not describe an SDN architecture.

The Open Networking Foundation describes logically centralised control. That does not necessarily mean a single physical controller. Control, redundancy and interfaces must be examined for the specific platform. OpenFlow should not be treated as synonymous with SDN as a whole either.

Distinguish automation from SD-WAN

Network automation initially means using software to carry out repeatable tasks. Examples include collecting configurations, comparing them or generating them from templates. This does not require converting the entire network architecture to SDN. Supported devices, suitable interfaces and a clearly defined desired state matter.

SD-WAN focuses on software-controlled wide-area networking, such as connections between sites and cloud services. Cisco describes it as an application of SDN to the WAN. A requirement for site connectivity is therefore a different planning question from provisioning virtual networks in a data centre. First record which connectivity path needs improvement.

Start with one repeatable task

Choose a manageable task first, such as collecting existing VLAN configurations and comparing them with an approved list. Ansible provides network resource modules for this. Their gathered state reads information from the device; rendered generates device-specific configuration without connecting to it. Check the individual module documentation for supported states and resources.

Separate discovery, proposal and execution. Do not distribute a template to every device without review. Ansible check and diff modes also have limits: support depends on the module, and individual tasks can explicitly run normally even in check mode. Review these exceptions; an uneventful dry run does not prove connectivity after the change.

Check dependencies and failure behaviour

Software control does not replace physical infrastructure. Inventory links, switches, routing and management access alongside controllers, certificates and required services. Before choosing a platform, examine hardware support, version compatibility, licensing and the effort needed for operations and recovery. The SDN label alone does not establish cost savings or improved security.

Ask specifically what happens when a controller fails: which existing connections remain available, which new changes are possible and how does resynchronisation work? Microsoft, for example, specifies multiple virtual machines for a highly available Network Controller. That product-specific architecture is not a general availability promise for other SDN solutions.

Plan a pilot with verifiable outcomes

One possible test scenario is an additional network for a non-production application. Define in advance which destinations must be reachable and which connections must remain blocked. Then test the application, DNS, required database connections and intended isolation. A successful ping alone is insufficient for acceptance.

Compare the process with the previous workflow: which manual steps disappear, which checks are added and who can resolve a failure? Also document a tested rollback using an independent management path. Only then decide whether more networks or devices should use the same process.

• Record the pilot scope, owners and change approval.
• Back up the initial configuration and exclude sensitive values from openly accessible diffs.
• Test permitted and blocked connections and monitoring before and after the change.
• Verify stop conditions, rollback and the responsible contact in practice.

Agree the operational scope explicitly

For a discussion with NUXOA about IT support, prepare an overview of devices and sites and describe the recurring tasks. Clarify ownership of networking, applications, approvals and incident handling. A particular SDN platform or custom automation becomes part of the engagement only when explicitly agreed.