cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

Device types supported by Cisco NSO NEDs

5562
Views
16
Helpful
5
Comments

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.)

Comments
Beginner
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.
Cisco Employee

@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.

Beginner

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 :)

Cisco Employee

@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

Beginner

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