Re: [j-nsp] NETCONF vs.
Phil Shafer writes:
>my ($method, %args) = @_;
One typo: s/$method/$fn/ on this line. Then you can:
use Net::Netconf::Device;
my %args = (
"change" => "attribute",
"commit-scripts" => "attribute",
"compare" => "attribute",
"database" => "attribute",
"database-path" => "attribute",
"format" => "attribute",
"inherit" => "attribute",
"key" => "attribute",
"configuration" => "dom",
);
Net::Netconf::Device::add_method("get_configuration", %args);
We'll get this fix (and defs for the *configuration RPCs) in asap.
Thanks,
Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] NETCONF vs.
Chuck Anderson writes:
>Using NETCONF with Perl Net::Netconf::Manager, I'm trying to get the
>candidate configuration to see what changed before issuing a commit
>request so I can avoid "empty" commits after doing a "replace"
>operation on a subtree. I see that NETCONF defines a standard
> call, and I believe is a
>legacy/proprietary Junos call. There is a example in the
>documentation, but there doesn't appear to be a way to see what was
>changed in the candidate config vs. the committed config:
Yes, JUNOS supports all the older API calls side-by-side with the
standard NETCONF API. When we were working on the NETCONF standard,
my preference was for full words, and the concensus was "we'll use
full word but 'config' is a word", which I thought was odd, but was
happy find it allowed us to use our configuration-as-a-full-word
versions in a slick backwards compatible way.
>But I can't for the life of me figure out how to pass the various
>attributes inside the tag with Perl. How does one
>map the attributes INSIDE a tag to the Perl API call as below?
The module needs a means of adding methods, as well as methods for
the legacy API calls.
>
I'm not sure this is really what you what. This will return the
full configuration with "junos:changed='changed'" attributes on any
element that's changed. You might be better served with the "compare"
attribute on the get-configuration RPC, which returns the text-based
diff-like format. It's not usable in terms of XML content, but
will only return the changed items. If the output is empty, then
you don't need to commit.
But that still leaves you with the same problem, how to put attributes
on the RPC. You need something in Device.pm like:
sub add_method
{
my %map = (
'no-args' => $NO_ARGS,
'toggle' => $TOGGLE,
'toggle-no' => $TOGGLE_NO,
'string' => $STRING,
'dom' => $DOM,
'attribute' => $ATTRIBUTE,
'url' => $URL_STRING,
'dom-string' => $DOM_STRING,
);
my ($method, %args) = @_;
my %info;
foreach my $field (keys(%args)) {
$info{$field} = $map{$args{$field}};
}
$methods{$fn} = \%info;
}
My perl's a bit rusty and I need to bug out for the day, but that's
the gist of it. I'll proof it and get it added to Device.pm asap.
Then you can add_method('get-configuration') with the proper content.
Thanks,
Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] NETCONF vs.
On Wed, Sep 21, 2016 at 03:26:40PM -0400, Chuck Anderson wrote: > This doesn't work: > > $res = $jnx->get_configuration(changed => 'changed', compare => 'rollback', > database => 'candidate'); > > because that generates this: > > > > candidate > rollback > changed > > > > when I need it to be this: > > >changed="changed"> > > After a close reading of the Perl Net::Netconf::Device code, I've come to the conclusion that what I want to do is impossible with that API as written, unless I modify it to add a get_configuration method that accepts attributes. I will either need to switch back to the JUNOScript Perl API or change my approach. It seems like this would be a common operation--commit my changes if anything was actually changed during a merge/replace operation, rollback otherwise. Perhaps something could be built-in that does this. Even from the CLI I often do "show | compare" followed by "rollback" and "exit" if there are no actual changes after e.g. a "replace pattern" or "load merge" operation. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] NETCONF vs.
Have you just tried to just compare source=>running to source=>candidate from get_config? -- Tim On Wed, Sep 21, 2016 at 2:26 PM, Chuck Anderson wrote: > Using NETCONF with Perl Net::Netconf::Manager, I'm trying to get the > candidate configuration to see what changed before issuing a commit > request so I can avoid "empty" commits after doing a "replace" > operation on a subtree. I see that NETCONF defines a standard > call, and I believe is a > legacy/proprietary Junos call. There is a example in the > documentation, but there doesn't appear to be a way to see what was > changed in the candidate config vs. the committed config: > > https://www.juniper.net/techpubs/en_US/junos16.1/ > topics/task/program/netconf-perl-client-application- > submitting-requests.html > > The API call I want to make is documented here: > > https://www.juniper.net/documentation/en_US/junos14.1/ > topics/reference/tag-summary/netconf-junos-xml-protocol- > get-configuration.html > > But I can't for the life of me figure out how to pass the various > attributes inside the tag with Perl. How does one > map the attributes INSIDE a tag to the Perl API call as below? > > database="candidate"> > > This doesn't work: > > $res = $jnx->get_configuration(changed => 'changed', compare => > 'rollback', database => 'candidate'); > > because that generates this: > > > > candidate > rollback > changed > > > > when I need it to be this: > > >changed="changed"> > > > > Thanks. > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] NETCONF vs.
No, I'm trying to have the router do the compare server-side. On Wed, Sep 21, 2016 at 02:52:42PM -0500, Tim Jackson wrote: > Have you just tried to just compare source=>running to source=>candidate > from get_config? > > -- > Tim > > On Wed, Sep 21, 2016 at 2:26 PM, Chuck Anderson wrote: > > > Using NETCONF with Perl Net::Netconf::Manager, I'm trying to get the > > candidate configuration to see what changed before issuing a commit > > request so I can avoid "empty" commits after doing a "replace" > > operation on a subtree. I see that NETCONF defines a standard > > call, and I believe is a > > legacy/proprietary Junos call. There is a example in the > > documentation, but there doesn't appear to be a way to see what was > > changed in the candidate config vs. the committed config: > > > > https://www.juniper.net/techpubs/en_US/junos16.1/ > > topics/task/program/netconf-perl-client-application- > > submitting-requests.html > > > > The API call I want to make is documented here: > > > > https://www.juniper.net/documentation/en_US/junos14.1/ > > topics/reference/tag-summary/netconf-junos-xml-protocol- > > get-configuration.html > > > > But I can't for the life of me figure out how to pass the various > > attributes inside the tag with Perl. How does one > > map the attributes INSIDE a tag to the Perl API call as below? > > > > > database="candidate"> > > > > This doesn't work: > > > > $res = $jnx->get_configuration(changed => 'changed', compare => > > 'rollback', database => 'candidate'); > > > > because that generates this: > > > > > > > > candidate > > rollback > > changed > > > > > > > > when I need it to be this: > > > > > >> changed="changed"> > > > > > > > > Thanks. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] NETCONF vs.
Using NETCONF with Perl Net::Netconf::Manager, I'm trying to get the candidate configuration to see what changed before issuing a commit request so I can avoid "empty" commits after doing a "replace" operation on a subtree. I see that NETCONF defines a standard call, and I believe is a legacy/proprietary Junos call. There is a example in the documentation, but there doesn't appear to be a way to see what was changed in the candidate config vs. the committed config: https://www.juniper.net/techpubs/en_US/junos16.1/topics/task/program/netconf-perl-client-application-submitting-requests.html The API call I want to make is documented here: https://www.juniper.net/documentation/en_US/junos14.1/topics/reference/tag-summary/netconf-junos-xml-protocol-get-configuration.html But I can't for the life of me figure out how to pass the various attributes inside the tag with Perl. How does one map the attributes INSIDE a tag to the Perl API call as below? This doesn't work: $res = $jnx->get_configuration(changed => 'changed', compare => 'rollback', database => 'candidate'); because that generates this: candidate rollback changed when I need it to be this: Thanks. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] NETCONF vs SNMP for monitoring
Phil Mayers writes: > 4. Finally, you may find that bulk data collection - e.g. all the >counters, all the ARP / ethernet switching table entries - is quicker >over Netconf. SNMP results need to be OID-sorted which can be slow, but >also the TCP transport can end up being faster than UDP. Test and see >which works, but also beware faster collection may mean higher CPU on >the monitored device. SNMP is good for quick responses, but can be problematic for bulk data collections. Take a look at the accounting profiles feature in JUNOS, which can collect values locally on the RE and transfer them on size or time thresholds via ftp, http, or scp. Profiles can record interface states, RE states, MIB variables, or have custom values supplied by on-box scripts. The trade offs are delayed transfer, but less impact on the device, and you get values even during networking issues/outages. There's an NCE write-up at: http://www.juniper.net/techpubs/en_US/junos11.4/information-products/topic-collections/nce/accounting-profiles-statistics-logging/accounting-profiles-statistics-logging.pdf Thanks, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] NETCONF vs SNMP for monitoring
On 30/08/14 17:30, Tyler Christiansen wrote:
SNMP is less resource-intensive and faster than NETCONF. I would use SNMP
for the things you can and NETCONF for the things you can't. If you
I would agree with this, based on our extensive playing. We tend to
monitor with SNMP, configure with Netconf/Junoscript.
Couple of additional points:
1. Sometimes the SNMP MIB is really horribly organised either from a
performance point of view ("OIDs shall be ordered by prime factorial of
birth date" - hateful if you need to fetch a whole table of 10k rows to
get one item) or needing to fetch a jillion separate tables to get the
final result. In this case, Netconf *may* be faster but...
2. ...you need to account for the overhead of setup/teardown of the
Netconf session, particularly the SSH/HTTPS key exchange. On low-end
devices (EX3300) the CPU were sluggish enough that we opted for plain
TCP transport Junoscript, relying on the firewalled management VLAN for
security. Try to catch everything in one Netconf session - Tyler's point
about async/threading is very relevant here.
3. Occasionally you'll find things not exposed over SNMP; obviously
then Netconf
4. Finally, you may find that bulk data collection - e.g. all the
counters, all the ARP / ethernet switching table entries - is quicker
over Netconf. SNMP results need to be OID-sorted which can be slow, but
also the TCP transport can end up being faster than UDP. Test and see
which works, but also beware faster collection may mean higher CPU on
the monitored device.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] NETCONF vs SNMP for monitoring
I consider wait time to be part of resources (and thus resource-intensive). Especially if queries on your NMS start to build up because you're waiting on responses. I haven't read that paper thoroughly, but it looks like it's specifically comparing SNMP and NETCONF for the purpose of configuration management--not monitoring. For configuration management, NETCONF wins hands down. If you're looking strictly for Juniper, there are a number of NETCONF libraries that will give you easy access to the RPCs. https://github.com/juniper?query=netconf As far as which RPCs you can make, if there's something specific you want, just log into the Juniper device and type the command, then: | display xml rpc If you need to know how to parse it, then leave off `rpc`. For other vendors, someone else will have to pipe in as I haven't worked with other vendors. Hypothetically, you should be able to use the same RPCs and parsing for any vendor. In practice, though, this isn't the case (just look at NETCONF on IOS for a perfect example). --tc On Sat, Aug 30, 2014 at 9:45 AM, Morgan McLean wrote: > Yea multithreading would be the way to go, it's not very intensive, just > sits hanging out waiting for its response. I was reading a paper somebody > wrote on performance for SNMP vs NETCONF, which is here: > http://morse.colorado.edu/~tlen5710/11s/11NETCONFvsSNMP.pdf . Seems to > suggest as workload increases, netconf becomes more favorable. I haven't > tested it in depth; in fact I'm having trouble finding documentation on the > different calls I can make. > > Thanks, > Morgan > > > On Sat, Aug 30, 2014 at 11:30 AM, Tyler Christiansen > wrote: > >> SNMP is less resource-intensive and faster than NETCONF. I would use >> SNMP for the things you can and NETCONF for the things you can't. If you >> consider NETCONF, it would probably be best to do so in a threaded, >> asynchronous, or multi-process fashion. I've seen a few SNMP pollers that >> don't use threads or multiple processes or callbacks, and they can get away >> with it. I don't think NETCONF can. >> >> --tc >> >> >> On Sat, Aug 30, 2014 at 9:01 AM, Morgan McLean wrote: >> >>> Hi all, >>> >>> Just curious if anybody opts to use netconf instead of snmp for >>> monitoring >>> purposes? Any known downsides? >>> >>> SNMP seems to never really be up to date with everything that you might >>> want to have a peek at. >>> >>> Thanks, >>> Morgan >>> ___ >>> juniper-nsp mailing list juniper-nsp@puck.nether.net >>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>> >> >> > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] NETCONF vs SNMP for monitoring
Yea multithreading would be the way to go, it's not very intensive, just sits hanging out waiting for its response. I was reading a paper somebody wrote on performance for SNMP vs NETCONF, which is here: http://morse.colorado.edu/~tlen5710/11s/11NETCONFvsSNMP.pdf . Seems to suggest as workload increases, netconf becomes more favorable. I haven't tested it in depth; in fact I'm having trouble finding documentation on the different calls I can make. Thanks, Morgan On Sat, Aug 30, 2014 at 11:30 AM, Tyler Christiansen wrote: > SNMP is less resource-intensive and faster than NETCONF. I would use SNMP > for the things you can and NETCONF for the things you can't. If you > consider NETCONF, it would probably be best to do so in a threaded, > asynchronous, or multi-process fashion. I've seen a few SNMP pollers that > don't use threads or multiple processes or callbacks, and they can get away > with it. I don't think NETCONF can. > > --tc > > > On Sat, Aug 30, 2014 at 9:01 AM, Morgan McLean wrote: > >> Hi all, >> >> Just curious if anybody opts to use netconf instead of snmp for monitoring >> purposes? Any known downsides? >> >> SNMP seems to never really be up to date with everything that you might >> want to have a peek at. >> >> Thanks, >> Morgan >> ___ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> > > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] NETCONF vs SNMP for monitoring
SNMP is less resource-intensive and faster than NETCONF. I would use SNMP for the things you can and NETCONF for the things you can't. If you consider NETCONF, it would probably be best to do so in a threaded, asynchronous, or multi-process fashion. I've seen a few SNMP pollers that don't use threads or multiple processes or callbacks, and they can get away with it. I don't think NETCONF can. --tc On Sat, Aug 30, 2014 at 9:01 AM, Morgan McLean wrote: > Hi all, > > Just curious if anybody opts to use netconf instead of snmp for monitoring > purposes? Any known downsides? > > SNMP seems to never really be up to date with everything that you might > want to have a peek at. > > Thanks, > Morgan > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] NETCONF vs SNMP for monitoring
Hi all, Just curious if anybody opts to use netconf instead of snmp for monitoring purposes? Any known downsides? SNMP seems to never really be up to date with everything that you might want to have a peek at. Thanks, Morgan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
