Juniper NED for VPN on SRX

[Noel Cantenot]

Hi,

I planned use NSO to configure Remote-Access VPN on a Juniper SRX. I started to configure VPN using the Juniper-junos NED to get the XML format, but I realised that the NED is not complete, somme commands are not available.
Is use the NETCONF NED a good idea (or should I ask Cisco to develop those commands) ?

Example of missing configurations:

set services ssl termination profile NEWVPNNAME-ssl server-certificate xxxx
set security ike gateway NEWVPNNAME local-address a.b.c.d
set security ike gateway NEWVPNNAME aaa access-profile NEWUSERPROFILE
set security ike gateway NEWVPNNAME version v1-only
set security ike gateway NEWVPNNAME tcp-encap-profile ssl-profile
...

 Thanks.

[snovello · Accepted solution]

Hi,

both options are supported, the NED with our NSO yang models exists and is maintained to support existing deployments and old JunOS releases that don't have the 'rfc-compliant' option.

The new NED which relies of Juniper's Yang models is  recommended going forward, certainly for new deployments. See:

https://community.cisco.com/t5/crosswork-automation-hub-blogs/going-junos-native-with-nso/ba-p/3995765

So your choice has to do with your situation:

The benefit of the new NED is that the moment you receive a new JunOS version, you are able to update the models and use any new features without getting the NED extended. Nor will it happen that like now you come across an unsupported feature for a new service. However getting the NED extended is also not so hard, nor does it take much time. You have to weigh how much of a benefit that is to you, and how much work switching your existing services will be.

If you have an existing deployment with services using the legacy NED and are more inclined to stay with the old for now, maybe you can use this service as a learning experience to see what it takes to chenge a service from one NED to the other, so you can then better weigh the benefits against the costs.