Device types supported by Cisco NSO NEDs

[KJ Rossavik]

Cisco NSO has the broadest multivendor support in the industry. We currently support more than 100 different device types, physical and virtual, including those listed below. These Network Element Drivers (NEDs) use legacy communication mechanisms and protocols, such as CLI, TL1, REST, etc. to communicate with the devices. These are sold at a fixed price, and there is no additional charge for incremental feature development for a productized NED.

If a device/system, e.g. Cisco ESC, supports NETCONF/YANG, and is well behaved, then a NED can be easily generated automatically, as described in the NSO user documentation. Cisco does not develop or sell such a NETCONF/YANG NED, and hence the integration is free - no integration taxation http://info.tail-f.com/noadaptertax

Here is a non-exhaustive list of NEDs for legacy protocols (i.e. not NETCONF/YANG). If you need to orchestrate devices not on this list, then we will in most cases support, either because we have the NED already, or we can very quickly (in a matter of weeks) develop the required NED. New NED types are added at a rate of around one per month.

Cisco Aireos	ALU SAM	Huawei IAS
Cisco ACI (APIC DC)	ALU SR	Huawei iManager
Cisco APIC EM	Alvarion Breezemax	Huawei USN
Cisco ASA	Amazon AWS	Huawei VRP
Cisco DCNM	Arista EOS	IDirect Pulse
Cisco DNAC	Arris CMTS	Infinera EMXP
Cisco EPNM	Avi Vantage	Infoblox NIOS
Cisco ESA	Aviat CTR8000	Juniper JunOS
Cisco FMC	Brocade Ironware	Juniper NSM
Cisco FTD	Brocade NOS	MRV MasterOS
Cisco FXOS	Ceragon IP10	NetxDC Axon
Cisco GSS	Checkpoint GaiaOS	Nuage VSD
Cisco IOS & IOS XE	Ciena ESM	OneAccess OneOS
Cisco IOS XR	Ciena SAOS	OneAccess TRDE
Cisco ME1200	Ciena MCP	ONF TAPI
Cisco ME4600	Citrix Netscaler	Openstack
Cisco Meraki	Citrix SDX	Overture 1400
Cisco NCS2000	Clavister COS	Overture 5K
Cisco NXOS	Coriant SDNTC	Overture 6K
Cisco PNR	Coriant SmartRouter	Palo Alto Networks Panos
Cisco QPS	Datacom DM	Procera PLOS
Cisco RPD	Dell FTOS	Quagga BGP AOS
Cisco SMA	ECI Muse	RAD VX
Cisco STAROS	Equinix ECX	Radware AlteonOS
Cisco UCS	Ericsson EFN	Redback SE
Cisco WAAS	Ericsson SGSN/MME	Riverbed Steelhead
Cisco WSA	ETSI SOL003	Secure64 SourceT
A10 ACOS	F5 BigIP	Sumitomo EPON
Accedian NID	F5 BigIQ	Telco Systems Binox
ADTRAN AOS	Fortinet FMG	Unix BIND
Adva-825	Fortinet FW	Velocloud VCO
Adva FSPNH	Furukawa FX1	Viptela vManage
Aethra ATOS	HP Comware	VMware vSphere/vCenter
Affirmed Acuitas	HP Nonstop	Vyatta VC
ALU ISAM	HPE Aruba	ZenOSS
ALU OmniSwitch	HPE VCM	ZTE XPON
		ZTE ZXROS

Network Element Drivers (NED) provide the connectivity between the NSO Software and Network Elements. Network Elements and their associated functionality are constantly evolving and therefore, NEDs will not support all possible devices, capabilities, or use cases. Customers may request additional NED functionality from Cisco by discussing with their Cisco Sales representative, or may choose to develop their own NEDs using documented Cisco APIs (although we would strongly discourage this as these would make the NED fall outside of our support model/contract.)

[SiewSE55115]

Hi KJ Rossavik Do companies look for Cisco to develop NEDs for their devices or they can self help to create a NED on their own? For example, the hardware is a customized one but its communication protocol is standard like TL1 or SNMP. Many thanks in advance.

[KJ Rossavik]

@SiewSE55115

Today all non-NETCONF NEDs (i.e. CLI/REST/TL1/etc.) are developed by the Cisco NSO NED team. NED development is a specialised skillset, so although theoretically others could do it, it is most cost-effective for everybody to leave it to the NED team. The exception to that is if a customer requires a NED for a bespoke system, i.e. something that is not generally available. In that case the NED would not be subject to productisation, since there is no market for it outside of the one customer. In that case we would point the customer towards one of the partners that we use for NED development, as they have the skillset and critical mass of people to be able to develop, maintain and support such a bespoke NED.

From a vendor perspective, rather than attempting to develop their own NED, it would make more sense to offer a NETCONF interface on their devices, so that the NED can be auto-generated.

[SiewSE55115]

Thanks KJ Rossavik for your explanation.

You mentioned that it is theoretically possible to develop NED for a Bespoke hardware using documented Cisco APIs though it is quite a specialized skill set.  

Does Cisco provide training on how to develop NED for bespoke hardware (I have 1 bespoke equipment using its own custom protocol and another 1 bespoke equipment using SNMP)? Thanks again :)

[KJ Rossavik]

@SiewSE55115 

We do not offer training for this, as nobody does this, and neither should they. If you require a NED for a bespoke device/system then we would recommend that you get that developed and supported by one of the partners that we use for NED development.

SNMP NEDs can be generated from the SNMP MIBs as described in the NED development guide

[SiewSE55115]

Thanks KJ Rossavik for your prompt and clear explanation. Really appreciate it. :)