I'm currently working on writing some automation around the ASR9K platform
and I've been looking at both the netconf and xml interfaces. Anyone have
experience with either?
It looks like the XML interface is much more feature rich, supporting both
config and operational state objects where netconf is limited to config
only.
Currently I'm leaning towards the xml interface, but netconf would come
with the appeal of using a standard and any libraries I write for it may be
usable with other platforms.
Thus spake Jeremy (jbaino@gmail.com) on Fri, Aug 01, 2014 at 03:07:19PM -0700:
I'm currently working on writing some automation around the ASR9K platform
and I've been looking at both the netconf and xml interfaces. Anyone have
experience with either?
It looks like the XML interface is much more feature rich, supporting both
config and operational state objects where netconf is limited to config
only.
Currently I'm leaning towards the xml interface,
I wasted a week of my life trying to get xml interface on n9k to work
correctly. I would never use it again, as it obviously gets no QA.
There is likely a fundamental design flaw in that the cli is not itself
an xml client like you see on other platforms. The XML interface, and
CLI (presumably netconf) may all be distinct clients to sysdb. I did
get (3) ddts' assigned, related to missing data compared to cli, endian
issues, etc. My recommendation is DO NOT USE IT.
I went back to screen scraping for ios-xr. Related to this and other
issues, all of our subsequent purchases have been MX.
I always preferred the displays where you have commands without all the
bracket garbage and just indented text for sub items.
On the MX the show configuration | display set is about as close as you
can get, but it¹s workable. Kudo¹s is that you can just dump it in as
well and get what you want. I think the only time I really get annoyed at
the JunOS configurations is when I¹m staring down any of their switches.
Did cisco bother to open any DDTSes on the issues you saw? I’ve found that they care very little about these “automation” issues because they have zero automation in their lab testing that reflects how someone truly uses a device. I’ve been through many iterations with Cisco on this front with their ARF teams, platform teams, BU teams, etc.. they all have to be a very strategic engagement to get these things properly fixed and made usable.
I am interested in anyone trying to use any of these agents.. I suspect they all worked before the RP went x86 and like you said, nobody tests them now.