Hello my friend,
We continue the previous article about NETCONF/YANG. Today we’ll speak mainly about Cisco XR implementations and differences that it has from Nokia (Alcatel-Lucent) SR OS. To be honest, differences are tremendous so fasten your seatbelts.
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. |
Disclaimer
I strongly recommend you to learn my previous article about NETCONF/YANG, where I explain lab setup and initial configuration that should be done at Cisco IOS XR router in order to work NETCONF. Without reading that article you might lose some important facts and therefore you end up with not working lab.
Cisco IOS XR and YANG data model
I must admit that one of the reasons, besides the length, why I have ended the previous article, was the necessity to dig deeper into realization of NETCONF at Cisco IOS XR. It’s much different and all the reverse engineering magic hasn’t worked. Thanks to Frank I have got some useful insights from Cisco. In particular, he pointed to the blog of his colleague Ahmed, who works in the field of network programmability.
First of all, thanks to that blog I have learned that in Cisco IOS XR markup of the messages are done using newer RFC6242. In Nokia (Alcatel-Lucent) SR OS we have used RFC6241, and therefore my initial tests were unsuccessful. The point is that only hello message should end with “]]>]]>” symbols. In RFC6242 you need to inform shell, how many characters you want to send in advance, before you send your message. The new end symbol is “##”. Take a look at the example below:
Probably I’m doing not in the most optimum way, but still 🙂 So according to RFC6242 we start any message besides HELLO with “#number_of_char”.
number_of_char = number of characters (including space) + number of lines -1
We calculate number of lines, because for SSH there is invisible character “end_of_string”, which is also calculated. If you are familiar with programming or Linux shell, it’s expressed there as “\n”. We put “-1” at the end, because we don’t take into account “end_of_string” in the last string.
The second crucial point, which also has taken a lot of time from my life, is that Cisco IOS XR requires you to use YANG data model, so you need to know and understand it. As you see in the image above, we have something “interface-configurations xmlns=”http://cisco.com/ns/yang/Cisco-IOS-XR-ifmgr-cfg””. ”Xmlns” point you to appropriate data model, whereas “interface-configurations” is part of this module, which needs to be called in order you get result. The question that I had was about “where to find the module name and how to get to know, which should be called from that module. The answer to the first part is quite easy; during initial HELLO exchange the router sends supported capabilities including name of all supported modules. The answer to the second part took me some time, and now I’m happy to share my findings with you.
Cisco shares its data model per IOS XR release on the corresponding page at GitHub. As I’m working with Cisco IOS XRv release 6.1.2 I provided link to it, but you can easily navigate to another version if necessary.
Then you need to find module you are interested in. There two types of modules: “cfg”, which are related to setting or getting the configuration from router, and “oper”, which are related to actual live data. Continuing the example above, I take module “Cisco-IOS-XR-ifmgr-cfg”.
Then we open this file to see, what we have inside. For now, the important part is the description, as it has explanation of contained modules (actually, commands we need to write in our message):
So far so good. Now we have all the information to construct proper NETCONG messages using YANG data model for Cisco IOS XRv. Let’s do that!
Configuring Cisco IOS XR using NETCONF
Just to refresh the point we have started in the previous article, we’ll connect from our management server to Cisco IOS XRv console through SSH on specific NETCONF port with specific keyword:
|
Rtr Base ISIS Instance 0 Status |
As soon as we good HELLO from Cisco IOS XR router we enter our HELLO message and press Enter (don’t press ENTER before).
Important: after you have entered the HELLO message and pressed Enter to send it, DON’T press Enter anymore. Otherwise the SSH session will be closed
|
… |
I’ve marked our HELLO message with bold so that you see that I haven’t pressed Enter before.
Now we step into normal set/get process keeping in mind information about YANG and message framing we have discussed before. I mark with the bold our GET-CONFIG message, so you can easily identify it in the overall packet flow:
|
… |
Cisco answers us with list of the configured interfaces as it’s set in the running-config.
There is no overall “show run” through NETCONF with YANG data model comparing to Nokia (Alcatel-Lucent) SR OS.
There reason is that YANG model for Cisco IOS XR is set of modules, where each module performs certain tasks. Technically you can achieve the same level if you screen all “cfg” modules, collect related commands and create big GET-CONFIG requests with all modules mentioned separately.
Just to recall, we are configuring the following basic topology, with ISIS interconnecting our routers:
Following the same logic as we did for Nokia (Alcatel-Lucent) SR OS earlier, we create loopback interface at Cisco IOS XR router XR3. Again, our message is in bold.
Important: press Enter before typing the message, otherwise the SSH session will be closed.
|
… |
If the action is successful, we just receive OK as confirmation. What is also relevant, as you might see, I call additional YANG models to configure IPv4 and IPv6 addresses. The same information was in the output above, when I performed GET-CONFIG. Let’s check what we have configured from the XR3 router itself:
|
RP/0/0/CPU0:ios#show ipv4 interface brief |
There is no new interface configured. But why? The answer is that in Cisco IOS XR world we need to commit configuration, after we enter it. It isn’t applied automatically, at least in NETCONF on Cisco IOS XR 6.1.2. In the document at Cisco website I have found separate NETCONF operation “commit”. So, after we have entered the configuration and get OK back, send new message to commit provided configuration:
|
… |
I hope you don’t forget to press Enter before you start typing your message.
We do another attempt to check, which interfaces our Cisco IOS XR router XR3 has as configured now:
|
RP/0/0/CPU0:ios#show ipv4 interface brief |
We got it!
The next step is to add physical interface facing SR1 so that we’ll have connectivity (our messages are in bold):
|
… |
If we have logging enabled in Cisco IOS XR router XR3, we’ll see immediately the following message, which indicated that new interface is created:
|
RP/0/0/CPU0:Nov 28 10:34:52.501 : ifmgr[228]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/0.13, changed state to Up |
We need to create also corresponding bridge in Linux, what we do without any NETCONF/YANG:
|
[root@localhost ~]# |
Now we can try toping from SR1 to XR3 and check, if the connectivity is established:
|
A:VSR# ping 10.11.33.33 |
So far, so good. After we have established basic connectivity on the interface level between Nokia (Alcatel-Lucent) SR OS router SR1 and Cisco IOS XR router XR3. we’ll configure ISIS in order to provide connectivity between their loopbacks:
|
… |
Let’s check routing table at Cisco IOS XR router XR3:
|
RP/0/0/CPU0:XR3#show route ipv4 isis |
And finally we make connectivity check:
|
RP/0/0/CPU0:XR3#ping 10.0.0.11 so 10.0.0.33 |
Brilliant! We have managed to configure connectivity between Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR using NETCONF/YANG!
Monitoring of Cisco IOS XR by NETCONF/YANG
As I have spent a lot of time digging into NETCONF/YANG on Cisco IOS XR over last 2 weeks, I feel I must show you some more useful stuff.
So far we have used three basic NETCONF operations: GET-CONFIG. EDIT-CONFIG and COMMIT. But you can use NETCONF also for tracking real time data from your router. In Nokia (Alcatel-Lucent) we have used CLI commands directly, because I’m not (yet) familiar with YANG data model for SR OS. For Cisco IOS XR we’ll use these “oper” modules, which describe how to use some operational data.
I’ve tried some basic commands. For example, we want to get information about interaces and their L1/L2 parameters. In CLI you will type “show interfaces” to do that. Here we got this information by NETCONF with appropriate YANG data model:
|
… |
I have significantly reduced the output, because it takes 10 pages in MS word to show it. This data is very useful for network monitoring, operation and optimisation, what is just the nutshell of SDN. Take a look at the following files, which provides some other examples: 098_net_show isis 098_net_show interfaces 098_net_show ipv4 interfaces
If you have opened ISIS example, you see there unfiltered all data that is somehow related to ISIS. For sure, you can build more precise request to get precise answer, but this long output is good example that shows, how many useful real-time information you can collect through NETCONF using YANG data model.
For final configuration I only provide Linux bridge and NETCONF messages, which we have used and not only: 098_config_final_linux 098_config_Cisco_XR_NETCONF
Lessons learned
Using NETCONF/YANG on Cisco IOS XR requires a lot of patience. You do something wrong, like forget press Enter or press Enter, where it isn’t needed, you will close the session. If you enter not exact number of characters in your message, you will close the session. So, just try, try and try again.
Conclusion
In this and the previous article we have covered NETCONF, both with RFC 6241 and 6242 framing, both with clear XML and YANG data models. Now we definitely have understanding, what it can gives us. SDN is more just a new protocol. It’s a new paradigm in the network world, new way of thinking about service’s implementation, operation and optimisation. Besides NETCONF/YANG we have recently covered BGP-LS, PCEP, Segment Routing and SR-TE. All these technologies are just a pieces of puzzle in the overall picture called SDN in service provider networks. From time to time I’ll be back to this topic providing you additional info, how existing technologies can be newly used for SDN. 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.
BR,
Anton Karneliuk
Useful (and used) links
https://www.linkedin.com/pulse/netconf-rfc-6242-protocol-tutorial-ahmed-n-abeer/
https://github.com/YangModels/yang/tree/master/vendor/cisco/xr/612
https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r6-0/sysman/configuration/guide/b-sysman-cg-60xasr9k/b-sysman-cg-60xasr9k_chapter_010111.pdf
https://tools.ietf.org/html/rfc6242
https://www.cisco.com/c/en/us/td/docs/iosxr/ncs6000/datamodels/b-programmability-cg-ncs6000-61x/b-programmability-cg-ncs6000-61x_chapter_010.pdf
https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/data-models/guide/b-data-models-config-guide-asr9000/b-data-odels-config-guide-asr9000_chapter_010.html
https://www.cisco.com/c/en/us/td/docs/optical/ncs1000/60x/b_Datamodels_cg_ncs1000.pdf
https://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-3/xml/schemas/XR_XML_Schemas_CRS_430.html
