Hello my friend,
Some time ago I have written few articles about SDN technologies and protocols that you might find now or will find in near future in service provider networks. There is one important technology missing there, and we’ll speak about it now.
1 2 3 4 5 | No part of this blogpost could be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical or photocopying, recording, or otherwise, for commercial purposes without the prior permission of the author. |
Brief overview
NETCONF/YANG is quite often mentioned together, though it isn’t necessity the case. NETCONF is an abbreviation from Network Configuration Protocol, which is described in RFC6241 currently. And it has two major modules to control network elements: XML and YANG. When NETCONF was released, only XML was available as it’s shown in RFC4741.
YANG is a data modelling language and was initially described in RFC6020. Over the years it evolves to a newer version 1.1 covered by RFC7950. Actually YANG is an abstraction that helps create vendor-independent view on the configuration of particular device.
In general, if we think about main idea of NETCONF, it’s about vendor independent configuration. Nowadays each vendor has its own CLI language. Though it’s always English, commands are always different. So we, as a network engineers, must to be trained in all kinds of these languages. For example, I’m writing about two languages in my articles (link):
- Cisco IOS XR;
- Nokia (Alcatel-Lucent) SR OS.
On top comes the following (just what I have in my mind regarding main vendors in service provider network):
- Juniper JUNOS;
- Huawei NOS VRP;
When we start speaking about enterprise networking, data centers or security, the number of different CLI languages increases tremendously. So NETCONF’s intention to simplify life of network engineers by overcoming this language barrier and give possibility to configure all devices in the same manner through NETCONF.
What are we going to test?
We’ll configure Nokia (Alcatel-Lucent) VSR and Cisco IOS XRv to support NETCONF. After that we’ll perform some configuration and verification activities using this protocol.
Software version
For Nokia (Alcatel-Lucent) VSR we use the newer version, what was not possible for multicast. There are no changes for Cisco:
- Nokia (Alcatel-Lucent) SR OS 15.0.R4
- Cisco IOS XRv 6.1.2
Topology
Physical topology is the same as it was previously:
I must admit that I’ll use only two routers: SR1 and XR3. Routers SR2 and XR4 aren’t even launched. For logical topology we have the following:
The initial configuration is quite easy. Actually there is no initial configuration for Nokia (Alcatel-Lucent) VSR router SR1 besides provisioned line cards. For Cisco IOS XRv we just configure interface in order to have connectivity for SSH. For SR1 we use OOB management through BOF, which is done during provisioning of VSR: 096_config_initial_XR3 096_config_initial_linux 096_config_initial_SR1
Configuration of NETCONF agent
Both for Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR we need to make sure that following steps are done to get NETCONG working:
- SSH server is enabled
- Corresponsing user has rights to utilize NETCONF
- NETCONF agent is enabled and associated with SSH
As I’m taking the default configuration, I will show only necessary steps for each vendor. For example, in Cisco IOS XR default user has NETCONF access, and in Nokia (Alcatel-Lucent) SR OS SSH server is enabled:
| Nokia (Alcatel-Lucent) SR OS | Cisco IOS XR |
| SR1 | XR3 |
|
A:VSR>edit-cfg# candidate view |
RP/0/0/CPU0:ios#show run |
Actually, that’s it. We have enabled NETCONF at our Nokia (Alcate-Lucent) SR OS router SR1 and Cisco IOS XR router XR3.
Connecting to NETCONF agent at Nokia (Alcatel-Lucent) SR OS
Now we need to make sure that NETCONF is working. By default, NETCONF is working on TCP port 830, so we need to establish SSH to this port with mentioning keyword “NETCONF”. Let’s try how it’s working on Nokia (Alcatel-Lucent) VSR (SR 7750) router SR1:
|
[root@localhost ~]# ssh admin@192.168.1.151 -p 830 -s netconf |
I have reduced the output, because it was just unreal big. For sure, if you develop NETCONF application, you need to see them all to understand, what you need use. SR1. To start working, we need to send hello from our side to the router
|
<?xml version=”1.0″ encoding=”UTF-8″?> |
Now the SR1 is ready to be configured through NETCONF, using XM.
Connecting to NETCONF agent at Cisco IOS XR router
The same is true for Cisco IOS XR router XR3, as we haven’t modified TCP port for NETCONF:
|
[root@localhost ~]# ssh cisco@192.168.1.131 -p 830 -s netconf |
The structure of HELLO message from Cisco IOS XRv is the same as we’ve just seen for Nokia. The difference is on the capabilities, which refer to Cisco modules. In the same way we send our HELLO back to XR3:
|
<?xml version=”1.0″ encoding=”UTF-8″?> |
You might see the difference. Here we send capability for NETCONF 1.1, rather than 1.0, because based on my tests Cisco IOS XRv 6.1.2 supports only this capability.
Configuring Nokia (Alcatel-Lucent) SR OS using NETCONF
We continue this sub-chapter from the point, when we have connected through SSH to Nokia (Alcatel-Lucent) VSR (SR 7750) SR1, received HELLO and sent our HELLO back to it.
The first essential task is to grab the existing configuration and analyse it. The first message is or request and the second one is the output from the router:
|
<?xml version=”1.0″ encoding=”UTF-8″?> |
Use this output ant get-config message as a basis for reverse engineering by writing edit-config commands!
This output is especially important for us. As it’s stated above, I’ve used this output to writing my own edit-config messages. Probably you can find good description of all trees and commands in this XML. I haven’t found it, though I must admit that I haven’t spent a lot of time on this task. So I’ve used reverse engineering approach to define what I need.
As you see, we don’t have any L3 interface configured. Brief double check in CLI confirms that:
|
A:VSR# show router interface |
OK. In order to make our example more useful and interesting, let’s create the following simple topology:
Let’s start doing it. First of all, we create the following message, which configures IPv4 and IPv6 addresses at interface system:
|
<?xml version=”1.0″ encoding=”UTF-8″?> |
If your request is correct and successfully applied. The verification of implemented config I show from Nokia (Alcatel-Lucent) SR OS CLI at SR1:
|
*A:VSR# show router interface |
Hurray! It works. I’m quite impressed, and what about you?
Now we create another L3 interface, which will point to Cisco IOS XR router XR3. So we also need to make proper configuration of physical port and add proper mapping to each other:
|
<?xml version=”1.0″ encoding=”UTF-8″?> |
NETCONF CLI informs us that our configuration is successful.
Frankly speaking, I’ve learned proper commands by configuring first it in CLI, then grabbing output through get-config command provided before.
Let’ check that:
|
*A:VSR# show router interface |
The third configuration step is related to configuration of ISIS. Initial check confirms that it isn’t configured:
|
*A:VSR# show router isis status |
That’s desired output and we go further with NETCONF:
|
<?xml version=”1.0″ encoding=”UTF-8″?> |
Looks promising. Now we check in Nokia (Alcatel-Lucent) SR OS CLI at SR1 again the status of ISIS:
|
*A:VSR# show router isis status |
New ISIS process is up and running now.
Basic configuration of SR1 is done and we switch further to Cisco IOS XR router XR3…
Configuring Cisco IOS XR using NETCONF
… which will be covered in the next article, as current article is already quite long.
Here are Nokia (Alcatel-Lucent) NETCONF XML messages, which we have used to configure SR1: 096_config_Nokia_NETCONF
Lessons learned
Reverse engineering is tool that always helps all type of engineers, especially if there is lack of documentation. So, try, modify and try again!
Conclusion
For sure the main advantage of NETCONF comes, when you develop your own NETCONF client/plugin as part of your NMS (or just basic scripts) or use existing one. Because the ultimate goal is to make the life of network engineers easier through automatisation and abstraction, which is reachable only in conjunction with proper scripting. But I hope you understand the overall idea, how NETCONF is working Nokia (Alcatel-Lucent) SR OS, so you might already have ideas how to use it for your tasks. Cisco IOS XR will be covered in the next article Take care and good bye!
P.S.
If you have further questions or you need help with your networks, I’m happy to assist you, just send me message.
Support us
BR,
Anton Karneliuk
I have a basic issue, when i run the command the ssh command with netconf, this is the output i get, It seems there are limited capabilities defined in my SR OS, is there a way to add more capabilities?
urn:ietf:params:netconf:base:1.0
urn:ietf:params:netconf:capability:writable-running:1.0
15
]]>]]>
Hi Ankur,
No, possibility is something embedded into your OS version. Which Nokia (Alcatel-Lucent) VSR do you have?
BR,
Anton
Hi Anton
Have you encounter anything similar to Yang Modelling Kit from Cisco on Nokia SR-OS?
BR.
Nik
Hi Nik,
What do you mean by YANG Modelling Kit? If you refer to Nokia Yang modules, they were going to publish them as soon as they are fully ready, what was the point for SR OS 16.0.R1 release. To be honest, I haven’t seen them released but I hope it will happen in near future.
BR,
Anton
Hello Anton,
Could you help me with Nokia NETCONF, based on article https://karneliuk.com/2017/11/sdn-sandbox-6-netconfyang-for-nokia-sr-os-and-cisco-ios-xr-part-1/
I’m trying to send hello message (after successful connection and getting advertisement of capabilities) but seems like it stuck in console on the client side. All counters on the router (/show system netconf counters) a zeros and router doesn’t send any reply.
…..
……
s-wlangw&revision=2018-01-10
urn:nokia.com:sros:ns:yang:sr:major-release-16
14
]]>]]>
urn:ietf:params:netconf:base:1.1
]]>]]>
// Nothing here
…..
……
Hi Maxim,
The router doesn’t respond to hello, cause by nature it’s you (client), who is responding to hello from the router, which includes capabilities. It means, that after you have sent hello, you need to send already some messages with content (get or edit-config for instance).
BR,
Anton
Hi Anton, I’m facing the issue that the NOKIA SR device is not advertising the network-instance-l2 as its capability since it is a sub-module. As a result the Opendaylight controller does not able to form the schema context resulting in import error for the corresponding sub-module. Do you have any idea on how to solve this issue. Thanks!
Hello Vigesh,
I haven’t tried to use ODL controller, but all Nokia supports it advertises in its capabilities. If some capabilities are missing, I’d recommend:
1. Check how the configuration on Nokia in OpenConfig module looks like. If you can configure that in general, that is already good.
2. Check on the ODL side, how it could configure the L2 part over the the general openconfig-network-instance module.
Cheers,
Anton