Aryaka Raises $16M More for the Software-Defined WAN
Startup has raised nearly $100M in the name of networking-as-a-service and the software-defined WAN.
Startup has raised nearly $100M in the name of networking-as-a-service and the software-defined WAN.
mkdir usbflash:/MY_ROOT_CA
crypto key generate rsa label MY_ROOT_CA modulus 2048 exportable storage nvram:
Two years later it's time for an update.
In this featured white paper from Edgewater Networks, we learn how an SaaS model gives an enterprise feel to SMB security. Download the white paper now to read more.
Now you can have a Telefónica NFV MANO stack of your very own.
For those that followed my SDN Protocols series last summer, you might have noticed a missing entry: NETCONF. This protocol has actually existed for some time (the original now-outdated specification was published in 2006), but is appearing more often, especially in discussions pertaining to network automation. The current, updated specification - RFC6241 - covers a fairly large amount of material, so I will attempt to condense here.
NETCONF operates at the management layer of the network, and therefore plays a role similar to that of OVSDB. This is in contrast to protocols like OpenFlow which operate at the control plane.
A key difference between NETCONF and other management protocols (including SNMP) is that NETCONF is built around the idea of a transaction-based configuration model. The NETCONF specification provides for some optional device capabilities aimed at assisting operators with the lifecycle of configuring a network device, such as rolling back a configuration upon an error. Unfortunately, not all network devices support such capabilities, but the protocol was built to make it easier to discover what kind of capabilities a network device can support.
Before getting into the semantics of the NETCONF protocol itself, it’s worth briefly jumping ahead to address the Continue reading
For those that followed my SDN Protocols series last summer, you might have noticed a missing entry: NETCONF. This protocol has actually existed for some time (the original now-outdated specification was published in 2006), but is appearing more often, especially in discussions pertaining to network automation. The current, updated specification – RFC6241 - covers a fairly large amount of material, so I will attempt to condense here.
NETCONF operates at the management layer of the network, and therefore plays a role similar to that of OVSDB. This is in contrast to protocols like OpenFlow which operate at the control plane.
A key difference between NETCONF and other management protocols (including SNMP) is that NETCONF is built around the idea of a transaction-based configuration model. The NETCONF specification provides for some optional device capabilities aimed at assisting operators with the lifecycle of configuring a network device, such as rolling back a configuration upon an error. Unfortunately, not all network devices support such capabilities, but the protocol was built to make it easier to discover what kind of capabilities a network device can support.
Before getting into the semantics Continue reading