Phil Shafer writes:
>Phil Mayers writes:
>>What's the cause of the few/occasional commands where "| dis xml rpc"
>>doesn't work (e.g. "show virtual-chassis | display xml rpc")? I'm
>>assuming CLI must know how to format it as XML to send it to MGD.
>
>I'll take a look when I get back from break.
Stepan Kucherenko writes:
>Huh. Interesting. Now that explains why it logs in as root but shows my
>ssh connection data. It does incur a huge performance penalty even
>without ssh though.
>
>My script that goes through all border routers and asks them for routes
>from all bgp peers to a
Phil Mayers writes:
>What's the cause of the few/occasional commands where "| dis xml rpc"
>doesn't work (e.g. "show virtual-chassis | display xml rpc")? I'm
>assuming CLI must know how to format it as XML to send it to MGD.
I'll take a look when I get back from break. The one's I know that
Martin T writes:
>Thanks! So as I understand, the general idea is that it doesn't matter
>much for Junos if the command is executed in the CLI or from the
>remote(management server) NETCONF manager, i.e. Junos is basically
>built around the NETCONF? However, local calls(for example if one
>
> Looks like an implementation issue. Our UI infrastructure allows
> our programmers to define completion functions to list acceptable
> values. Some schmuck's coded the completion function as this "sh -c show
> route summary| ..." command.
>
> This is definitely not typical. More typically,
Luke Flemington writes:
>The Junos configuration file is also represented as an XML file.
Just to be clear, the JUNOS config database is a object database. The
objects are describes by data models in such a way that we can render
them into XML, but the database is not an XML database. It's a
Stepan Kucherenko writes:
>Sometimes it does strange stuff with SSH internally though. Example:
>
>Let's say I do " show route table ?" at a router.
>
>Logs show:
>
>mgd[62935]: UI_CHILD_START: Starting child '/bin/sh'
>mgd[68498]: UI_AUTH_EVENT: Authenticated user 'root' at permission level
On 24/12/2015 09:10, Phil Shafer wrote:
The real value is that the API comes for free, since it's using the
same internal plumbing. This means that when a feature ships in
the CLI, it's immediately available in the API. No lag. No
additional cost. No missing bits. It's literally all there
Sometimes it does strange stuff with SSH internally though. Example:
Let's say I do " show route table ?" at a router.
Logs show:
mgd[62935]: UI_CHILD_START: Starting child '/bin/sh'
mgd[68498]: UI_AUTH_EVENT: Authenticated user 'root' at permission level
'super-user'
mgd[68498]:
Thanks!
Martin
On 12/21/15, Matt Bernstein via juniper-nsp wrote:
> On 21/12/2015 08:57, Martin T wrote:
>> Thanks! So as I understand, the general idea is that it doesn't matter
>> much for Junos if the command is executed in the CLI or from the
>>
On 21/12/2015 08:57, Martin T wrote:
Thanks! So as I understand, the general idea is that it doesn't matter
much for Junos if the command is executed in the CLI or from the
remote(management server) NETCONF manager, i.e. Junos is basically
built around the NETCONF? However, local calls(for
Hi,
if I execute for example "show version brief | display xml" command,
then the router returns:
http://xml.juniper.net/junos/12.3R6/junos;>
r1
m10i
m10i
junos
JUNOS Base OS boot [12.3R6.6]
/* additional data removed for
Hey Martin,
I’m not sure NETCONF is involved as such, but I think that’s the general idea.
From a Juniper automation doc:
> Junos management “under the hood” is based in XML. When you enter commands on
> the Junos CLI, commands are actually converted to XML-based Remote Procedure
> Calls
r-nsp-boun...@puck.nether.net] Im Auftrag von
Martin T
Gesendet: Montag, 21. Dezember 2015 02:26
An: juniper-nsp
Betreff: [j-nsp] NETCONF in Junos
Hi,
if I execute for example "show version brief | display xml" command, then
the router returns:
http://xml.juniper.net/junos/12.3R6/jun
14 matches
Mail list logo