Re: [j-nsp] Change in host-name / domain-name behaviour - LLDP System Name / SNMP sysName

[Phil Shafer]

James Stapley writes:
>Not sure if we're the first people to notice this, but there seems to be a
>change in the way Junos deals with FQDN, host-name and domain-name with our
>latest kit.

These are the fixes for two PRs:

  PR 1383295 Domain name is not reported as part of the LLDP sysname
 in "show lldp neighbor" command
  PR 1384065 sysName of system mib does not include domain name

The sysName brings up into conformance with the standard suggestion:
"By convention, this is the node's fully-qualified domain name",
while the LLDP fix brings up into conformance with "the rest of the
vendors".

While backward compatibility is a priority, these were PRs and
intentional fixes to move toward standard behavior, and I'm told
they were in the release notes as customer visible changes.

HTH

Thanks,
 Phil

P.s.: No, I've no idea why 1384065 is marked confidential.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] break statement in SLAX

[Phil Shafer]

Martin T writes:
>> Now I want to process only the first three integers which are less
>> than 5. As I understand, for-each loop does not support breaking out
>> from the loop so I did it like this:

Yes, for-each lacks a break, but while can help.

>In addition, it would require a protection against an endless loop
>inside the while loop. Something like this:
>
>if ( $n > count($int_ns) ) {
>set $m = 4;
>}

You can hang inside a while loop forever.  While that's not it's
goal, it's occasionally useful.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How to trim the text node of a specific element node in SLAX node-set?

[Phil Shafer]

Martin T writes:
>Thanks Phil! I wasn't aware of the mode statement. However, as I don't
>see a performance benefit, then solution in my initial e-mail looks
>bit simpler.

It always depends on the rules and the structure of the contents
you are converting, but when someone says "I want to traverse this
hierarchy looking for ...", then apply-templates/mode is normally
a pretty good answer.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] [c-nsp] show ospf lsdb - topology drawing

[Phil Shafer]

serge vautour writes:
>Went down this road before and ended up developing something in house. One
>key thing we wanted was a way to display the nodes on a map based on GPS
>coordinates. Has anyone ever seen a tool that does this? Obviously some
>input file with "node to GPS coordinate" is required.

FWIW, you can use [system location] to record this data on device,
which might help make it available, easier to keep up to date,
audit, share, etc.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] why is "show log messages | last 10" so slow?

[Phil Shafer]

Saku Ytti writes:
>The 'last 50' is purely CLI construct. The
>designers could have chosen that 'last N' is passed to RPC always as
>an argument, and never implemented in CLI, and each RPC call has to
>implement it. It is debatable which is the right call.

That's fairly accurate.  Most of the UI pipes are implemented in
the CLI, allowing them to be used interactively, like the "m"
keystroke at the automore prompt being equivalent to the "match"
pipe, "e" == "except", etc:

---(Help for CLI automore)---
Clear all match and except strings:  c or C
Display all line matching a regexp: m or M 
Display all lines except those matching a regexp:   e or E 
Display this help text:   h
Don't hold in automore at bottom of output:   N
Hold in automore at bottom of output: H
Move down half display:   TAB, d, or ^D
Move down one line: Enter, j, ^N, ^X, ^Z, or Down-Arrow
Move down one page:Space, f, ^F, or Right-Arrow
Move to bottom of output: G, ^E, or End
Move to top of output:   g, ^A, or Home
Move up half display:   u or ^U
Move up one line: k, Delete, Backspace, ^P, or Up-Arrow
Move up one page:  b, ^B, or Left-Arrow
Quit automore: q, Q, ^K
Redraw display:^L or ^R
Repeat a keystroke command 1 to 9 times:  Meta-1..9
Repeat last search:   n
Save output to a file:s or S 
Search backwards thru the output: ?
Search forwards thru the output:  /
---(End of Help)---

FWIW, I use this extensively to match/except my way to the source of
a problem, then clear to see the complete log.

For "last", this isn't really vital, but it's worth notice that the
display is really showing the  lines of the display, but the
complete display is buffered and available in automore, so you can
page backward ("b") through it.  This means it's more like the G
in more/less, that "tail".

It also means the CLI goes thru the cost of recording the complete
input data set.  If you want to avoid this cost, use the "no-more"
pipe:

user@cli> show log messages | last 5 | no-more
Oct 30 09:52:55  mgd[38686]: UI_DBASE_LOGIN_EVENT: User 'phil' entering 
configuration mode
Oct 30 09:52:59  mgd[38686]: UI_DBASE_LOGOUT_EVENT: User 'phil' exiting 
configuration mode
Oct 30 10:00:36  hassisd[4105]: CHASSISD_SNMP_TRAP6: SNMP trap generated: Power 
Supply failed (jnxContentsContainerIndex 2, jnxContentsL1Index 1, 
jnxContentsL2Index 0, jnxContentsL3Index 0, jnxContentsDescr PEM 0, 
jnxOperatingState/Temp 6)

Note that this tosses you back to the CLI prompt instead of keeping
you at the automore prompt.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How to trim the text node of a specific element node in SLAX node-set?

[Phil Shafer]

Martin T writes:
>I need to trim the text node of a specific element node in SLAX. All
>other elements should remain as in the original node-set. At the
>moment, I do it like this:

Use apply-templates and a distinct mode to traverse the entire
hierarchy and apply rules to rebuild content, like:

version 1.2;

main  {
var $alphabet :=  {
 {
 "bbb  ";
 "ccc  ";
}
 {
 "ddd  ";
 "fff  ";
}
}

var $new = {
apply-templates $alphabet {
mode "trim";
}
}

 { copy-of $new; }
}

match text() {
mode "trim";

if (name(..) == "d") {
 translate(., " ", "");
} else {
copy-of .;
}
}

match @* | * | processing-instruction() | comment() {
mode "trim";

copy-node {
apply-templates * |@* | text() | processing-instruction() | comment() {
mode "trim";
}
}
}

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] deleting ntp server from config, perhaps a bug?

[Phil Shafer]

Jared Mauch writes:
>The ability of routers to use DNS for service names is getting to be more of a 
>soft-requirement => hard requirement these days.  I may want to configure a 
>DNS name for my BMP/KFAFKA magic and have it fail over if we renumber the 
>machine (for example).

Yup, this one's on my list of features I haven't added yet.  The
plan was to have the value contain both the DNS and the address so
we (a) always have an address, and (b) can re-resolve at some
specific future time.  It's less of an issue for NTP, but imagine
having DNS fail for your syslog server and not getting logs.  The
re-resolve would be an explicit action, done at the user's direction
(or via event policy, etc).

Anyway, it would look something like:

[edit system ntp]
drew@charlie# show
server 0.pool.ntp.org%216.230.228.242;
server 1.pool.ntp.org%45.79.109.111;
server 2.pool.ntp.org%172.98.193.44;
server 3.pool.ntp.org%69.195.159.158;

where the junos system components would see only the address, but
the UI would hold both and "request system configuration resolve"
would perform the magic.  There'd be an "opt in" knob to turn on
this new behavior, so API clients (and humans) wouldn't freak at
these hybrid values.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] deleting ntp server from config, perhaps a bug?

[Phil Shafer]

Drew Weaver writes:
>I added 0.pool.ntp.org, 1.pool.ntp.org, 2.pool.ntp.org, 3.pool.ntp.org to 
>system ntp on an MX80 running JunOS 15.

I am unable to reproduce this, and it's pretty basic ui functionality,
so I'm a bit puzzled.  I'll keep looking but are you seeing this
broken behavior anywhere else in the config?  Can I get the specific
version number?

Is this a lab box?  If so, can you copy your database files
(/var/db/j*) to a backup location and run "mgd -I" (from the shell)
to rebuild it?  If that succeeds, open a support case with JTAC and
give them both the backup and rebuilt files and we can take a look
and see what failed.

Sorry I don't have a better answer at this point, but this ability
to delete specific statements is a core piece of ui functionality
and I can explain its failure.  Hopefully the data files will show
us.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] set:difference() function in SLAX returns different results while input node-sets are the same

[Phil Shafer]

Martin T writes:
>I encountered an interesting behavior where set:difference() function
>does not work when node-set variable is manually defined like this:

Two issues: first is that it is really comparing nodes not contents,
looking to see if the exact references are equal, so comparing:

var $x := {
 "a";
 {
 "a";
}
}

so a and b/a are distinct nodes and comparing them will compare
the specific nodes, not caring that they both contain "a".

Second, the ":=" operators make result tree fragments (RTF) which
are the bane of XSLT.  They are not node sets, but behave similarly,
sort of.  For details see:

http://juniper.github.io/libslax/slax-manual.html#result-tree-fragments

The outcome is that you'll often need "$var/*" to get to the contents
of the node-set.

See the attached example, where $v3 works and $v2 doesn't.

Thanks,
 Phil


% cat /tmp/foo.slax
version  1.2;

var $v1 := {
 {
 "99";
}
 {
 "100";
}
 {
 "101";
}
 {
 "102";
}
}
var $v2 := {
 {
 "99";
}
}
var $v3 = $v1/*[1];

main  {
 {
copy-of set:difference($v1/*, $v2/*);
}
 {
copy-of set:difference($v1/*, $v3);
}
}
% slaxproc -g -E -d /tmp/foo.slax
sdb: The SLAX Debugger (version 0.22.0)
Type 'help' for help
(sdb) c


  

  99


  100


  101


  102

  
  

  100


  101


  102

  

Script exited normally.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Configuration database stuck with mgd crashing

[Phil Shafer]

Aaron Gould writes:
>Maybe "commit full"

"commit full" helps when daemons miss config changes (which they
shouldn't) or if you just want to say "because I said so", but it
needs a functioning database, provided by MGD.  In this case, MGD
has corrupted the database (due to a software bug) and the assert
means that it's unable to do anything useful with the database since
it's corrupted and cannot be trusted.  "mgd -I" is the "nuke the
entire site from orbit" option.  It rebuilds the schema and the
database from scratch and reloads the entire contents.  It's the
only way to be sure.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Is it possible to pass apostrophe character(ASCII dec code 39) as an argument value to SLAX script?

[Phil Shafer]

Martin T writes:
>aren't you using grave accent("echo -e "\x60"") character? I was using
>"echo -e "\x27"" character.

Doh!  I read apostrophe (even named the script apos.slax) but my
brain turned into backtick.

Yes, this looks like a JUNOS bug:

root@box> op apos char "'"
''':(null):(2) Invalid expression
error: runtime error
error: Evaluating user parameter char failed

The underlaying slax library handles it correctly:

% slaxproc -E -n cs-examples/apos.slax -g -a char "'"


  got: '


But it looks like this is explicitly handled in slaxproc.c:

quote = strrchr(pvalue, '\"') ? '\'' : '\"';
tvalue[0] = quote;
memcpy(tvalue + 1, pvalue, plen);
tvalue[plen + 1] = quote;
tvalue[plen + 2] = '\0';

This logic doesn't appear in the JUNOS driver (/usr/libexec/ui/cscript).
I'll open a PR for this.

There is a limitation in XSLT that one can't mix strings with both
single and double quotes.  Strange but true.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Is it possible to pass apostrophe character(ASCII dec code 39) as an argument value to SLAX script?

[Phil Shafer]

Martin T writes:
>Is it possible to pass apostrophe character(ASCII dec code 39) as an
>argument value to SLAX script? I have tried to escape it, but it does
>not seem to work:

Quote it:

version 1.2;

param $char = "-";

main  {
 "got: " _ $char;
}

root@box> op apos char "`"
got: `

root@box>

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] format of minimum and maximum value of math:random() in SLAX

[Phil Shafer]

Martin T writes:
>thanks! I didn't know about floor() function in XSLT/SLAX. However,
>looks like in extremely rare cases math:random() can return 1 because
>according to https://...
>random number calculation can be "(double)RAND_MAX /
>(double)RAND_MAX". So final solution should be "floor(math:random() *
>16) mod 16".

Interesting.  The spec says "The math:random function returns a
random number from 0 to 1", which is less than clear about the
inclusivity of the range.  Looks like other implementations (msxml)
call the javascript Math.random() function, which returns [0, 1),
but libxslt returns [0, 1] (inclusive on both ends of the range).

The "mod 16" will give you slightly more 0s than strictly random.
If you care, you might want a custom function, like:

function my:random () {
var $x = math:random();
if ($x != 1) {
result $x;
} else {
result my:random();
}
}

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] format of minimum and maximum value of math:random() in SLAX

[Phil Shafer]

Michael Loftis writes:
>idk if there's a floor function but the general solution is floor(rand() *
>16) when rand() produces values 0-1(exclusive) IE if random does not
>generate 1.0 - dunno implementation details for slax

Yes, XPath has a floor() function that can be used directly in SLAX.

https://www.w3.org/TR/1999/REC-xpath-19991116/#section-Number-Functions

So you'd say:

var $res = floor(rand() * 16);

Also see the "number" statement for additional number-formatting
options:

http://libslax.readthedocs.io/en/latest/content.html#the-number-statement

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] negation operator in SLAX

[Phil Shafer]

Timur Maryin writes:
>On 18-Jun-18 20:40, Phil Shafer wrote:
>> "!" and "not" are identical.  The "!" is just syntactic sugar that
>> turns "! x " into "not(x)", as you can see in the code:
>Was it always like this?

Yup.  SLAX is all about syntactic sugar.  Well, mostly, anyway.
There are extension functions and mutable variables also.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] terminate endless loop in SLAX

[Phil Shafer]

Martin T writes:
>Thanks Phil! So in short, at the moment "terminate" statement inside
>the while loop works in a way that when "terminate" statement is
>executed, then immediately next iteration of while loop is started if
>while expression returns true and this will loop infinitely? If this
>while expression returns false, then terminate statement was the last
>thing processed by the script and script exits. At least based on my
>tests it seems to work like that.

Yes, which does inspire a reasonable (if ugly) workaround:

Bock % cat /tmp/foo.slax
version 1.2;

match / {
mvar $working = true();

 {
while ($working) {
set $working = false();
terminate "doa";
}
}
}
Bock % slaxproc -E -g /tmp/foo.slax
doa


Bock %

Hope this helps.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] terminate endless loop in SLAX

[Phil Shafer]

Martin T writes:
>Hi!
>
>Is there a way to terminate endless loop in SLAX? For example, if I
>configure something as simple as that:
>
>match / {
> {
>while ( true() ) {
>terminate;
>}

It's processing the terminate, but then it continues to "skip" over
the rest of the entries, thinking that it's a set of nodes instead
of a condition.  So it really, really, quickly loops forever.  Doh!

I'll open a bug report and work on the fix.  There is no workaround.
Apologies for the problem.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SLAX scripts configured with apply-groups will not source refresh

[Phil Shafer]

Chris Wopat writes:
>Everything seems to work fine, with one exception - you cannot refresh
>the scripts using their defined source. These commands don't even attempt
>...
>Is there an additional config knob required to tweak, or is this simply
>broken for some reason? This was tested on MX 16.1R7, QFX 14.1X53-D47.3,
>and EX 12.3R12-S7.

Nope, that's just a bug.  My refresh function isn't using the
inheritance hook.

You can refresh them individually ("set groups whatever ... refresh"),
if that helps as a work-around until the bug's fixed.

Please have your AM open a PR for it, or let me know and I'll open
it for you.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] negation operator in SLAX

[Phil Shafer]

Martin T writes:
>Oh, yes. I forgot the not() function. I made a small comparison
>between not(), jcs:empty() and ! using five data types in SLAX:

"!" and "not" are identical.  The "!" is just syntactic sugar that
turns "! x " into "not(x)", as you can see in the code:

https://github.com/Juniper/libslax/blob/master/libslax/slaxparser-xp.y#L164

>5) Empty RTF:
>"not( $rtf )" returns false, which is an expected result because even
>an empty RTF converts to true. "jcs:empty( $rtf )", to my surprise,
>returns true. According to documentation, RTF is always considered to
>not be empty. "! $rtf" returns false.

RTFs are exactl the reason I made jcs:empty(), since it bugs me
that boolean($rtf) is true.

  http://juniper.github.io/libslax/slax-manual.html#slaxis-empty

And "bugs" is too weak a word.  Imho, RTFs are the chief source of
slax/xslt violations of the Principal of Least Astonishment.

% cat /tmp/foo.slax
version 1.2;

var $a :=  {
   "b";
}

main  {
var $x = { copy-of $a/z; }
var $y = $a/z;

 boolean($x);
 boolean($y);
}
% slaxproc -g -E /tmp/foo.slax


  true
  false


See also the ":=" assignment operator, which helps avoid RTFs:

  http://juniper.github.io/libslax/slax-manual.html#colon-equals

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Managing large route-filter-lists

[Phil Shafer]

Brian Rak writes:
>Trip report:
>
>Don't use these for massive IRR configs.
>
>There's seemingly no garbage collection done on IRR configs, so you'll 
>be having to wipe the database via shell and start over around once a 
>week (we've got a config that's about 100k lines, and we only change the 
>BGP peers that actually have changes in IRR)
>
>They have a size limit of 400mb, and that's pretty easy to hit. Once you 
>hit that size limit, you'll start getting weird errors back when 
>changing the normal configuration (it *seems* like it ends up committing 
>a fraction of the ephemeral configs, so for us it complaints about 
>missing communities and policy statements)
>
>I'm considering changing over to prefix-lists (instead of 
>route-filter-lists), and moving to the dynamic DB instead. I'm not even 
>sure if this will help :/

This is definitely not expected behavior.  Please reply offlist
with details and we start investigating the issues you are seeing.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Managing large route-filter-lists

[Phil Shafer]

Brian Rak writes:
>The downside seems to be that these can blow up the router somehow... 

Not blow up, but obfuscate.  Imagine a user (or support person) who
is unaware that ephemeral databases are in use and resorts to pulling
out hair, muttering profanity, and sticking pins in their "Mr. Phil
Voodoo Doll" (tm) [batteries sold separately] when their "show
configuration" output doesn't correlate to their true operational
state.   The warning is more about "yes, I'm aware" than about
voiding warranties, explosions, or sharks with lasers.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] If there's anyone from Juniper on the list.....

[Phil Shafer]

Karsten Thomann via juniper-nsp writes:
>Who can get a message over to the Documentation group, it would
>be great if you could update the doc on the "insert" command to
>note that you have to create the object first, and then move it
>with the insert.
>
>May be common knowledge to old hands, but I'm still learning the
>ins and outs of JunOS. Looking at the doc, it seems that the order
>of operations would be this:
>
>edit firewall family inet filter foo
>insert term bar before term xyzzy
>error: statement 'bar' not found
>
>But it's actually this:
>
>edit firewall family inet filter foo
>set term bar from source-prefix-list source
>set term bar from destination-prefix-list dest
>set term bar from protocol tcp
>set term bar from destination-port ssh
>insert term bar before term xyzzy

This is fallout from the fact that "term bar" is a statement that
can't exist without contents.  Internally we call these "remove-empty"
and in the YANG terminology, they are called an equally-cryptic
"non-presence container".  But the results are the same: you can't have
an empty "term":

[edit firewall filter foo]
user@cli# set term bar
^
missing argument.

[edit firewall filter foo]
user@cli# set term bar ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  filter   Filter to include
> from Define match criteria
> then Action to take if the 'from' condition is matched
[edit firewall filter foo]
user@cli# set term bar

There must be something inside "term" for it to make any sense.
When you delete the last item under a "term", the "term" is removed
automatically.

In comparison, a non-remove-empty statement, like "ip-options"
does the "create on insert" behavior that you're after.

[edit firewall filter foo term last]
user@cli# insert from ip-options stream-id before route-record

[edit firewall filter foo term last]
user@cli# show
from {
ip-options [ stream-id route-record ];
}

If we allowed "insert term new-term before term old-term", then
we'd make it and immediately remove it, which would be quite
annoying.  So we prevent the referencing of non-existent
remove-empty statements.

I'll pass all this along to the doc team so we can make it more
clear in the documentation.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] certificates and configuration on MX-like devices

[Phil Shafer]

Chris Morrow writes:
>it would have helped a bit of the error was more clear :( helped me
>anyway.  I think it'd also be nice if I could have loaded the key in
>one element and cert in another... everyone who requires them jammed
>together does the ordering differently from the last person :(

We're calling openssl's validation functions and reporting any
errors returned, since we want our code (in the UI) to be as
well-separated from the innards of ssl as possible.  The "load-key-file"
accepts the key and cert in either order, rewriting them in the
"standard" openssl format.

>thnx! it does (as you say next) not include the key (which has to have
>it's passprhase removed) in the pem file, it uses the load-from-file option 
>which may
>not be the preferred manner for the particular operator.

Yes, assigning the value directly is less forgiving, since it doesn't
perform validation.  But IIRC the key/cert order still doesn't matter.
We write the value directly into /var/etc/ssl/local/ (with the "\n"s
unescaped).

>it also seems to suggest that using self-signed certs is ok (it's not,
>really it's not... setup your own ca, mint certs from it, verify certs
>on connect) a note in the docs that: "self signed certs invite people
>to mitm your control/monitoring comms with your network... it invites
>people to be you on your network and do what you can do...you don't
>want that to happen, right?" would be great to see.

True.  I'll pass this along.

>I'm unsure how I would  have found this document 'quickly', I did several 
>searches for:
>  "streaming telemetry ssl certificate"

FWIW, I googled "junos ssl local certificates" and got a ton of
pki-related entries, so did "junos ssl local certificates -pki"
and the docs were the first item returned.

>spreading the configuration requirements far and wide in the
>support/docs seems counter-productive to letting people self-help to a
>solution :( it's a shame that the docs aren't more clear and more
>centralized.

Completely agree.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] certificates and configuration on MX-like devices

[Phil Shafer]

Chris Morrow writes:
>ok, cool! so you want cert then key, great! (not clear on the
>format... but..)

The easiest way to add certs to config is with the "load-key-file"
knob:

[edit]
phil@box# set security certificates local foo load-key-file ?
Possible completions:
File (URL) containing an SSL certificate and private key 
in PEM format
[edit]
phil@box# set security certificates local foo load-key-file /tmp/my.cert

[edit]
phil@box# show | compare
[edit security certificates local]
 self { ... }
+foo {
+"-BEGIN PRIVATE KEY-\n\n-END CERTIFICATE-\n"; ## 
SECRET-DATA
+}

Adding "set security certificates apply-flags omit" will also help
you smile:

[edit]
phil@box# show security
certificates { /* OMITTED */ };

>ok.. so that's actually: "Private key and Certificate string" It's
>also not simple to find docs on this at the juniper support site :(

Here's a too-late-to-help-this-time URL:

https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/ex-series-ssl-certificates-generating.html

It fails to mention that both sections are needed, though this
kb article does:

https://kb.juniper.net/InfoCenter/index?page=content=KB19726==LIST

>If your primary/first interaction with 'documentation' is the
>command-line usage, then ffs please be precise.

Apologies for this.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Ansible juniper_junos -add license module?

[Phil Shafer]

adamv0...@netconsultings.com writes:
>The problem is I need to hit enter after the license is passed and then also
>^D (ctrl+D) at the end and I'm not sure how would I go about doing that in
>junos_command. 

Not sure why these aren't documented but the functionality is there.
Here's the JUNOS DDL (think "YANG"):

command add-license {
help "Add license keys from file, local or from server";
action acceptable mgd mgd_is_product_licensed;
action execute mgd mgd_add_license_mgd;
xml-name request-license-add;
odl-tag add-license-results;
argument source {
help "URL of source license key file";
type string;
}
argument key-data {
help "License key data";
type string;
}
}
command save-license {
help "Save license keys to file, local or to server";
action acceptable mgd mgd_is_product_licensed;
xml-name request-license-save;
odl-tag none;
action execute mgd mgd_save_license_mgd;
argument destination {
help "URL of destination license key file";
type string;
}
}

The "xml-name" statement gives the name of the RPC used to access
this command, which means the  RPC adds a
license from either a  URL or a  string, and the
 exports license data to a  URL.

In SLAX, that looks something like:

var $rpc =  {
 $my-data;
}

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] repeat a character in SLAX certain number of times

[Phil Shafer]

Martin T writes:
>..or for example, in Bash I could do "for i in $(seq $x); do echo -n =; done; 
>echo". What is the most elegant way to do this in SLAX? At the moment I solved 
>it with this:

You can brute force it with a loop or a recursive function (below),
but best to use the exslt extension function "str:padding":

var $x = str:padding(168, "=");

FWIW, the brute force patterns are:

var $x = {
for-each (1 ... $count) {
expr $char;
}
}

var $x = call padding($char, $count);

where:

template padding ($char = " ", $count = 0) {
if ($count > 0) {
expr $char;
call padding($char, $count = $count - 1);
}
}

Running these with the profiler should easily convince you that the
extension function is the best answer.  Just showing the others for
educational purposes.  And because the conference call I'm on is
rather dull.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] predicates in if statement expression in SLAX

[Phil Shafer]

Martin T writes:
>Is there a difference between following two if statement expressions:
>if ($node-set/foo/bar == "klm") {
>..and:
>if ($node-set[foo/bar == "klm"]) {

If there is, I'm missing it.

The first expression selects a set of "bar" nodes and then returns
true if any of them are "klm".  The second selects a set of first-level
nodes under $node-set named "foo" with a "bar" child that equals
"klm".  While the two expressions build different types (boolean
.vs. node-set), the resulting booleans should be equivalent: either
way the result will be false if $node-set contains no "foo" nodes
which contain "bar" children that equal "klm".

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Conditional statement in XPath predicates

[Phil Shafer]

Jonathan Looney writes:
>Actually, come to think of it, this (while untested) will probably work and
>be much simpler:
>
>param $interface = "undef";
>
>for-each ($result/physical-interface[$interface == "undef" || name == 
>$interface]) {

Yup.  The ternary operator ("?:") turns into an , so it's
not suitable for all expression locations.  SLAX is actually hiding quite
a fair bit of XSLT plumbing behind "?:".

% slaxproc --slax-to-xslt --partial --name -
var $x = favorite-color ? "blue" : "green";
^D

  

  


  

  

http://xml.libslax.org/slax; name="x" 
select="slax:value($slax-ternary-1)"/>

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] certain commands executed on CLI provide additional information over corresponding RPCs

[Phil Shafer]

Martin T writes:
>However, the actual point of my question was, that where do "show ipv6
>neighbors" and similar commands take the column names and the answer
>seems to be, that this is hard-coded in the binary. For example
>nd6info in case of "show ipv6 neighbors".

No, this isn't true.  The CLI uses descriptions provided by the
developer to turn XML into human-readable text.  Use "show ipv6
neighbors | display xml" to see the raw XML.  The nd6info utility
can generate it's own text version, but the UI plumbing invokes it
with the "-X" option to make XML content instead.  The two are
likely similar, but the CLI doesn't use the text from nh6info.  The
idea is to push all UI content into a single consistent code path.

FYI: You might want to take a look at libxo which allows binaries
to generate both XML and text (and HTML and JSON) from the same
source code path.

http://juniper.github.io/libxo/libxo-manual.html

This is now part of FreeBSD, so one can say "df --libxo:XP" and get
pretty-printed XML output on a stock BSD system.

(And no, we haven't moved nd6info over to libxo yet, but we should.)

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] certain commands executed on CLI provide additional information over corresponding RPCs

[Phil Shafer]

Martin T writes:
>http://xml.juniper.net/junos/16.1R2/junos;>
>
>
>IPv6 Address
>
>2001:db8:cfe:0:192:168:222:55
>

One of the goals of the API was to keep "meta data" out of the data,
both to make it simpler and to keep the size down.  Repeating headers
like this would be especially bad.  Plus there's some hope of
becoming multi-lingual.  Okay, small hope, but still.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Publish API data over SNMP

[Phil Shafer]

Saku Ytti writes:
>As a user I'd be comfortable at stability which matches display
>XML/JSON stability, and I think that level of stability would be
>implied.

Unfortunately not, since MIBs use numeric identifier for fields,
so if a developer inserts "leaf foxtrot" between "leaf echo" and
"leaf geronimo" (where it really belongs) then the MIB ordering has
changed and the numbers and all off.  The MIB generator would need
the numbers from the previous release to generate useful numbers.

>All this relies on my assumption that JNPR is machine generating
>JSON/XML stuff automatically for new commands, and 100% coverage is
>guaranteed. If this is true, same way this CLI-MIB could be machine
>generated.

The XML content is generated by the component, so the "show route"
is forwarded to RPD, who emits the XML response.  MGD forwards that
to the API client or to the CLI, who turns it into text.  The JSON
generation (and the "format='text'") is done as a "filter" (in the
unix sense of the word) to the output stream coming back to the API
client.

>In practice I rarely use MIBs, and if CLI would offer 'show
>class-of-service fabric statistic | display oid', that would be good
>enough for me. So not even having MIB wouldn't bother me. My only use
>case for MIBs is when I try to find what OID to poll, actual tooling
>does not load MIBs.

Well, if this is a "one off", we have two potential solutions.  First
is the utility MIB, which holds simple name/value pairs, with the name
being the key.  An intermittent event script can record a value into
the utility mib and an SNMP client can retrieve it.  More info is at:


https://www.juniper.net/documentation/en_US/junos/topics/task/operational/snmp-best-practices-utility-mib-using.html

The other path is "snmp scripts" where one can associate an OID
with a script that is run to generate data for that OID.  More info
is at:


https://www.juniper.net/documentation/en_US/junos/topics/concept/junos-script-automation-snmp-script-overview.html

>> The second issue (which is mostly my lack of snmp depth) is how
>> to ensure the results of multiple queries are given data from the
>> same RPC results.  Looking at "show chassis environment" results
>> should give consistent output.
>
>I'm not sure I understand the problem or question.

My concern was with ensuring that a PDU containing requests for the
value of "foxtrot" and "geronimo" get these values from the same
RPC output, instead of issuing the RPC twice, which makes more work
and my give inconsistent results.  Sorry if my previous explanation
(and perhaps this one as well ;^) wasn't clear.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] initialize multiple mutable variables in SLAX with the same value

[Phil Shafer]

Martin T writes:
>I would like to initialize multiple mutable variables with the same
>value. I could initialize variables one by one like this:

There's no sort of run-time variable naming like this in SLAX.
Variable names are just plain tokens (qnames).

If your data is an array, consider using a single variable
that contains a set of values, like:

var $x := {
 "one";
 "two";
 "three";
}

so $x[1] is "one" (position() is 1-origin).  This allows
building data like:

var $x := {
for-each (some/other/thing) {
 .;
}
}

But this makes updating a single array member difficult.

The root of this is that XSLT (and SLAX) use a very different
programming model than traditional languages, one that lends itself
to recursion and immutable variables.  In general, you are better
off following that model.

That said, sometimes it's easier to thing of a problem in traditional
patterns.  For more background on mutable variables into SLAX:

http://juniper.github.io/libslax/slax-manual.html#mutable-variables-2

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] certain commands executed on CLI provide additional information over corresponding RPCs

[Phil Shafer]

Martin T writes:
>I have noticed that certain commands executed on CLI provide some
>additional information over corresponding RPCs. For example "show ipv6
>neighbors" or "show system storage" on CLI show column names while XML
>output does not contain this data. Why is that so?

Both the CLI and RPC content contain the same information, but the
CLI takes the data supplied by the RPC and displays it using rules
specified by the developer.  These rules include column headers,
field titles, and other gritty little details.

But these are "display" features.  The API is meant to allow access
to the data, and to make that data the same data used by the CLI,
so the API is complete, up-to-date, well-tested, and useful.

If you want to use the API to get pure text data, we do have the
'format="text"' attribute that can be put on an RPC.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] understaning the copy-node in SLAX

[Phil Shafer]

Martin T writes:
>Thanks! And this technique is useful in case cli process expects an
>element node(for example "interface-information") to have additional
>attribute nodes(for example "junos:style="terse"")? Does it provide
>any advantages over statically specifying the attribute node?

No, there's really no advantage.  I almost didn't bother including
it in the language; it's just there for completeness.  "element
name()" gives identical functionality.

>For
>example, here I rewrote two named templates and a match template of an
>op script example from "Automating Junos Administration" book:

Can you give a page number?

>template handle-logical-intf($family) {
> {
>for-each (*[name() != "address-family"]) {
>copy-of .;
>}
>for-each (address-family[address-family-name=$family]) {
>copy-of .;
>}
>}
>}

You might want:

 {
copy-of @*;
for-each ...

... to copy the attributes off the current node.

Using "copy-node" here gives you a means of avoiding hardcoding
the name, but that's pretty unimportant for code like this where
the functionality is so closely tied to the name.

If the W3C had given copy-node a target xpath or an interesting
default content template (like the identity template), then it would
be more useful.  But it doesn't.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] understaning the copy-node in SLAX

[Phil Shafer]

Martin T writes:
>When I run this with traceoptions enabled, then I can see that "a="12" b="34" c="56"/>" is present in the output document. I guess
>that this inner for-each loop, based on my example, expands to this:
>
>copy-node {
>attribute "a" {
>expr 12;
>}
>attribute "b" {
>expr 34;
>}
>attribute "c" {
>expr 56;
>}
>}
>
>Now "copy-node" does its shallow copy and copies "abc" element node
>and specified three attribute nodes to result tree. Am I correct?

copy-node create a node with the target (default .) name which you
can then populate with contents:

https://www.w3.org/TR/1999/REC-xslt-19991116#copying

The xsl:copy element provides an easy way of copying the current
node. Instantiating the xsl:copy element creates a copy of the
current node. The namespace nodes of the current node are
automatically copied as well, but the attributes and children
of the node are not automatically copied. The content of the
xsl:copy element is a template for the attributes and children
of the created node; the content is instantiated only for nodes
of types that can have attributes or children (i.e. root nodes
and element nodes).

It's rather like:

element name() {
...
}

>In
>addition, why does copy-node run only once despite the fact that it is
>in the for-each loop? Is it because copy-node discards all the child
>elements of its current node and thus there are no more element
>nodes(, ,  based on my example) to loop through?

It's simpler than that; it's copying the current node, so there's
only one of them.  The nested "for-each" hits all the current node's
attributes, so you end up with:

% cat /tmp/foo.slax
version 1.2;

var $results := {
 {
 {
 "foo";
}
}
}

main  {
for-each ($results/abc) {
copy-node {
for-each (@*) {
attribute name(.) {
expr .;
}
}
}
}
}
% slaxproc -E -g /tmp/foo.slax


  

Bock %

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] understanding the root container element of node-set in SLAX

[Phil Shafer]

Martin T writes:
>for-each ($results/abc) {
> name(.);
>}
>
>..then "abc" is printed while I would expect "klm". Is this RTF
>container-element also named "abc"? However, for example,
>"$results/abc/abc" does not match anything.

"for-each" whiffles thru the list of elements that have the name
"abc", so "name(.)" ("the name of the current context node") will
always be "abc".  Since there are no "abc" elements under "abc",
"abc/abc" won't match anything.

I always tell folks to read Xpaths from the end element, so "a/b/c"
means 'any element named "c" parented by any element named "b"
parented by any element named "a" parented by the current context'.
Or "d[x==1]/e[y==2]" is 'any element named "e" that has an "y"
element that is equal to 2, which is parented by an element named
"d" which have an element named "x" which is equal to 1'.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How is SLAX "version" statement internally used?

[Phil Shafer]

Martin T writes:
>"version" statement in SLAX script is mandatory and argument for
>version statement has to be either 1.0 or 1.1. Based on my testing,
>1.2 works as well for example in Junos 16.1R2.11. However, is there
>any difference between "version 1.0" and "version 1.1"? For example,
>in Junos 16.1R2.11 one could define "version 1.0" and still use
>functionality introduced in SLAX 1.1 like mutable variables or for
>loops. How is "version" statement used by cscript/mgd?

At this point, it's strictly informational.  I don't want to "break"
a script because it uses a new feature, so I don't do enforcement.
Mainly it's used for output during "slaxproc --write-version"
processing, which can convert between versions.

http://libslax.readthedocs.io/en/latest/distribution.html#slaxproc-the-slax-processor

http://libslax.readthedocs.io/en/latest/notes.html#slax-version-information

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] tl1 transaction language

[Phil Shafer]

jayshankar nair via juniper-nsp writes:
>I am looking for tl1 implementation in C/Linux. Is there any implementation 
>available. Also i am looking for good documentation. Can i connect to 
>tl1daemon by simple socket programming and send command and receive response.

Wow!  I've not heard of TL1 in a long time.  It was actually on the
list of possible protocols when we built our initial API back in
1998 or so.  We thought it was one of the one customers would want,
but no one ever asked for it so it was dropped and mostly forgotten.

I don't know of any C libraries for TL1, but my guess is that at
this stage you'd be better off teaching your NMS to work with current
technologies (NETCONF and YANG) than to teach your devices TL1.

What application are you looking to interface with?

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] *humor*. MX480 sound card options

[Phil Shafer]

Matthew Crocker writes:
>/usr/sbin/alsactl: save_state:1590: No soundcards found...

That's only needed for screaming protocols.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Junos 10.0 SLAX question

[Phil Shafer]

Alexander Shikoff writes:
>var $str = '"';
>var $str = '\"';
>both result to an error.

It's a bug, fixed in modern SW.  I don't know of a work-around.
Apologies

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Comparison strangeness with annotations

[Phil Shafer]

Per Westerlund writes:
>Sorry about not providing version information. I have now verified this 
>on a few more systems (below) and repose my question about the 
>difference between operational and configuration mode: bug or feature?

Bug:

[edit]
user@cli# annotate system "one"

[edit]
user@cli# commit
commit complete

[edit]
user@cli# show | compare rollback 1
[edit]
+  /* one */
   system { ... }

[edit]
user@cli# quit
Exiting configuration mode

user@cli> show system rollback compare 0 1
[edit]
   system { ... }

Not sure why "show system rollback" is turning off the "compare
comments" flag, but, well, it is.  Please have your AM open a PR
on this, or let me know and I'll open one directly.

FWIW: "show configuration" gets this right:

user@cli> show configuration | compare rollback 1
[edit]
+  /* one */
   system { ... }

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Set system no-ping-time-stamp

[Phil Shafer]

"Valentini, Lucio" writes:
>The question 
>is, what do the other commands do ? Juniper does not seem to provide examples. 
>I never
>see the time stamp in the ping response anyway.

These config knobs set sysctl variables in the FreeBSD kernel to
instruct it on how to behave.  The values are then propagated from
the kernel to the PFEs as needed.  You're right, they are woefully
underdocumented.  Here's some info on them:

set system no-multicast-echo
sysctl: net.inet.icmp.bmcastecho
meaning: do not respond to ICMP packets sent to IP broadcast addresses

set system no-redirects
sysctl: net.inet.ip.redirect
meaning: do not send IP redirects

set system no-ping-record-route
sysctl: net.inet.ip.ip_rr (JUNOS specific, I think)
meaning: do not add record route data to ip packets (not ping specific)

set system no-ping-time-stamp
sysctl: net.inet.ip.ip_ts (JUNOS specific, I think)
meaning: do not add timestamps to ip packets (not ping specific)

Despite the names, the last two are _not_ ping/icmp related, but
just turn off ip options processing for these two options.  The
brevity of the names makes me fairly sure they are JUNOS additions.

I'll get these added to the docs.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] disaccord in output of "df" and "df " in Junos

[Phil Shafer]

Vincent Bernat writes:
>Unfortunately, there is no "stat" command that would help to have a
>better picture. df will "stat" the file you provide to get the device it
>is stored on and there search the device and its mountpoint to display the
>result.

You'll see the same behavior for symlinks:

% df /var /var/etc
Filesystem 1K-blocks Used   Avail Capacity  Mounted on
/dev/ad1s1f 35389060 26987142 557079483%/var
/dev/md12206141211132 1885368 1%/mfs
% ls -dl /var /var/etc
drwxr-xr-x  36 root  wheel  1024 Oct 10 23:46 /var/
lrwxr-xr-x   1 root  wheel12 Oct 10 23:46 /var/etc@ -> /mfs/var/etc

(on my m7i)

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] libcurl for SLAX missing HTTPS/SSL support?

[Phil Shafer]

Jeff Wheeler writes:
>I was hoping to call an API by HTTPS from a script.  To my surprise,
>libcurl on vSRX 15.1X49-D60.7 on AWS doesn't support SSL, and neither
>does fetch, etc.

In "classic" JUNOS, the ssl library is provided by the jcrypto
package, which ships as part of the "domestic" software bundles.
I'd assume there's something similar for SRX, where the "export"
version lacks strong encryption and the "domestic" version has it.
Check your "show version" output and talk with your AM re: getting
ssl-capable sw.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] execute a command in SLAX script which does not have XML RPC equivalent available

[Phil Shafer]

Looks like a bug to me.  Please have your AM PR it for us.

Thanks,
 Phil



Martin T writes:
>Jonathan, Phil,
>
>thank you for replies!  RPC does what I desire
>for example in Junos versions 13.3R4.6 and 13.3R9.13 but not in
>14.1R7.4. In 14.1 release for example following code:
>
>  var $request_system_license_save_cmd =  {
> "/tmp/key" ;
>  }
>  var $request_system_license_save_results = jcs:invoke(
>$request_system_license_save_cmd );
>
>..creates a file /tmp/key with no content:
>
>-rw---  1 root  wheel  0 Nov 25 10:18 key
>
>
>On the other hand, "request system license save /tmp/key" CLI command
>writes the key into the file. According to "Junos OS 14.1 XML API
>Operational Developer Reference" the "" is
>supported on MX series. Is this a bug? Or am I doing something wrong?
>
>
>thanks,
>Martin
>
>On Wed, Aug 17, 2016 at 1:19 AM, Phil Shafer <p...@juniper.net> wrote:
>> Martin T writes:
>>>I have a SLAX script where I execute "request system license save
>>>ftp://root:passwd@10.11.12.5; command.
>>
>> [Background: the UI comes in two pieces.  The CLI process handles
>> terminal I/O, key-bindings, automore, file transfers, and not much
>> else.  The real brain resides in MGD, which understands commands,
>> RPCs, how to parse them and what to do with them.]
>>
>> The "request system license save" command uses both halves.  MGD
>> asks CLI to do the transfer, and then MGD does with real work.
>>
>> SLAX scripts use the API directly, so it cannot perform the
>> file-transfer.
>>
>> The fix is to pass a local file name to the "request system license
>> save" command RPC and then do the transfer explicitly using the
>>  RPC.
>>
>> Thanks,
>>  Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] how to disconnect/kill tcp session from juniper router

[Phil Shafer]

Alexander Arseniev writes:
>Someone is brute-forcing Your router password, and that is very common 
>nowadays. Good loopback filter would prevent this.

Amen to this and all your other points, esp re: avoiding telnet in
favor of ssh.

Also you can use "system services ssh no-passwords;" to prevent
password use under ssh, but this _requires_ that you have ssh keys
installed for every user under [system login user authentication].
You'll still get connections, which can be blocked using filters,
but you can sleep better at night knowing that brute force password
attacks will fail (after you delete telnet/ftp/etc).  Passwords
continue to function on the console and for non-ssh protocols.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Leaking OSPF routes into ISIS

[Phil Shafer]

Hugo Slabbert writes:
>I generally create an explicit 'reject-all' policy and stick that at the=20
>end of policy lists, rather than nesting the reject within an existing=20
>policy.  It's a bit clearer.

You can also do this with a config group, since they are added (to lists)
after the foreground config:

Something like:

groups default-reject policy-options policy-statement <*> then reject;
protocols apply-groups default-reject;

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NETCONF vs.

[Phil Shafer]

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.

[Phil Shafer]

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] execute a command in SLAX script which does not have XML RPC equivalent available

[Phil Shafer]

Martin T writes:
>I have a SLAX script where I execute "request system license save
>ftp://root:passwd@10.11.12.5; command.

[Background: the UI comes in two pieces.  The CLI process handles
terminal I/O, key-bindings, automore, file transfers, and not much
else.  The real brain resides in MGD, which understands commands,
RPCs, how to parse them and what to do with them.]

The "request system license save" command uses both halves.  MGD
asks CLI to do the transfer, and then MGD does with real work.

SLAX scripts use the API directly, so it cannot perform the
file-transfer.

The fix is to pass a local file name to the "request system license
save" command RPC and then do the transfer explicitly using the
 RPC.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] "replace pattern" Command & White Spaces

[Phil Shafer]

Mark Tinka writes:
>I'll work with "sed" in the FreeBSD CLI itself. A little more involved,
>but will get the job done.

You could use an op script, if you want to say completely in the
CLI.  See attached.

Thanks,
 Phil


version 1.2;

var $conn = jcs:open();
param $pattern;
param $with;

var $pat = "(.*)" _ $pattern _ "(.*)";

main  {
var $rpc = ;
var $res = jcs:execute($conn, $rpc);
var $new := {
for-each (jcs:break-lines($res)) {
var $re = jcs:regex($pat, .);
if ($re) {
expr $re[2] _ $with _ $re[3] _ "\n";
} else {
expr . _ "\n";
}
}
}
var $rpc2 =  {
 $new;
}
var $res2 = jcs:execute($conn, $rpc2);
copy-of $res2;
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] "replace pattern" Command & White Spaces

[Phil Shafer]

Saku Ytti writes:
>Consider you have metric 42, you want to change that to 43. Now you
>probably don't want to risk changing every 42 => 43, because 42 could
>be used in many context. So you'd maybe want to do replace "metric 42"
>"metric 43", you can't, it won't have visibility on syntax/keyword
>'metric', only on the variable/value '42'.

Yup, it's field-oriented, since it's making changes in the database
directly; we're not generating text, pattern matching, and then
making change payloads.  Instead we're traversing the database,
pattern matching each "leaf" in the database.  So you get "^" and
"$", but not keywords like metric.  It's definitely a trade-off,
but we've never really hidden the fact that we're not really keeping
the data in a straight text file.

FWIW, 'replace pattern "foo bar" with "moo"' work fine for me.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How to catch invalid value/option for a command in SLAX script?

[Phil Shafer]

Martin T writes:
>Thanks for the reply! Did I understand you correctly that "if(
>$variable == "usb0\ninvalid value" ) {" is actually "if( string(
>$variable ) == "usb0\ninvalid value" ) {" and the string() inserts a
>newline at the beginning and in the end of the string? Based on the
>debugger output it looks like so:
>
>(sdb) p string( $variable )
>[string] "
>usb0
>invalid value
>"
>(sdb) p string( $variable ) == "usb0\ninvalid value"
>[boolean] false
>(sdb) p string( $variable ) == "\nusb0\ninvalid value\n"
>[boolean] true
>(sdb)

Yes and no:  SLAX (and the XSLT and XPath standards it's built on)
use "type promotion" to turn objects of differing types into the same
to be able to compare them.  See the fifth paragraph in:

https://www.w3.org/TR/xpath/#booleans

But the newlines are my fault.  The initial XML output for JUNOS
generated newlines after each tag open/close/data call to ease
debugging for developers, and also because I thought it would make
the XML->text renderer in the CLI easier.  By the time I realized
the latter was false, the former was shipping.  So XML output from
JUNOS looked like:


data


which means that leading and trailing newlines are present on some
data fields.  It's been corrected in many places, and some libraries
have options to automatically remove them.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How to catch invalid value/option for a command in SLAX script?

[Phil Shafer]

Martin T writes:
>I have a following simple SLAX script which executes "show system
>snapshot media usb0" command in an environment where "usb0" option for
>"show system snapshot" command is unavailable:

I can't reproduce this on my test box ("command is not valid on the m7i"),
but the best way to investigate this would be to use the debugger,
stop on the "==" line, and print the contents of $variable.

Reached breakpoint 2, at /tmp/foo.slax:21
foo.slax:21: if( $variable == "usb0\ninvalid value" ) {
(sdb) p $variable
[node-set] (1)
http://xml.juniper.net/xnm/1.1/xnm; 
xmlns:xnm="http://xml.juniper.net/xnm/1.1/xnm;>

command is not valid on the m7i



My guess is that the implicit string() call in the equals test is
getting you.

Consider using contain() instead of equals::

(sdb) p string($variable) == "\n\ncommand is not valid on m7i\n\n"
[boolean] false

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] protect ssh and telnet

[Phil Shafer]

Vincent Bernat writes:
>On which attribute can SSH keys be served?

Apologies.  I shot my mouth off.  JUNOS does not currently support
this.  And RADIUS, being cleartext, is not suitable.

LDAP (w/ SSL) would be a better solution, using something like:

https://github.com/AndriiGrytsenko/openssh-ldap-publickey

which plugs into openssh using the "AuthorizedKeysCommand" sshd_config
statement.  But JUNOS doesn't ship openldap, so the only way to
make this work would be an external web server can proxies requests
into LDAP.  The AuthorizedKeysCommand would be a script that makes
the HTTP request and formats the results.  The above LPK script
could be put inside a perl web framework like Mojolicious.

It's a bit of rough plumbing, but until we can ship openldap (or
you run the non-veriexec JUNOS), that's likely the best answer.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] protect ssh and telnet

[Phil Shafer]

Aaron writes:
>I'm new to Juniper. and I'm looking to protect ssh/telnet on all interfaces
>on my juniper ACX5048's.

First comment is: if you want security, don't allow telnet.
Force the use of ssh.

Me, I don't even like allowing passwords.  JUNOS now supports the
"system services ssh no-passwords" knob to force the use of ssh
keys over text passwords.  And your radius server will happily serve
ssh keys.  Force the move away from passwords.

The "lo0" filter covers traffic to the routing engine.  Any filter
applied to lo0 will block/allow only that traffic.

More generally, take a look at the "secure junos template" from
Team Cymru:

http://www.team-cymru.org/templates.html

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] "load replace" junoscript login class permissions

[Phil Shafer]

Jared Mauch writes:
>Try "load update" first.
>That should be much faster than load replace.

"load update" is faster than "load override", since under the covers,
it keeps the old config and finds the delta between the new config
and the old, allowing the system to see only the changed bits of
the config.  "load override" wipes the old and loads the new.

"load merge" is identical to "load replace", with the exception
that "load replace" honors "replace:" tags, where "merge" ignores
them.

> On Feb 22, 2016, at 9:06 PM, Chuck Anderson  wrote:
>Otherwise we get a failure trying to replace the prefix-list.  I don't
like this because now a rogue script could mess with the entire
policy-options hierarchy.

Consider using a config group, where the group would be completely
"owned" by this app, and the junoscript user would be able to only
write to that group, but to the entire contents.  Then only apply
that group where appropriate.  If your "AUTO-*" list is static, you
could put "apply-groups auto-app" under each specific prefix list;
otherwise, you'd need to put in under policy-options.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Anyone tried ThreatStop on Juniper integration?

[Phil Shafer]

Chuck Anderson writes:
>I assume by "ephemeral" database, you mean "configure dynamic" to edit
>the dynamic-db?

Yup, exactly.

>Unfortunately, it appears that dynamic-db only works
>for BGP policies, not firewall filters.  Also, a bigger problem IMO is
>that the dynamic database is not synchronized to the backup RE.

It's being expanded (16.1?).

>Do you have any clever workarounds for either of these two
>limitations?

What sw vers are you running?

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] | display inheritance vs. logical-systems

[Phil Shafer]

This is now PR 1160955.

Thanks,
 Phil



Phil Shafer writes:
>Yes, it's a bug.  Please have your account team open a PR or let
>me know and I'll open it.  From a quick look, the firewall data
>model has the right reference, but it's not working, likely broken
>somewhere in my (ui) code.
>
>Thanks,
> Phil
>
>
>
>Chuck Anderson writes:
>>An interesting CLI bug:
>>
>>"show configuration | display inheritance" doesn't find prefix lists
>>that are referenced via configuration groups that are applied inside a
>>logical-system, but the configuration commits and works correctly:
>>
>>MX_RE0# show groups DROP-RESERVED-SOURCES 
>>logical-systems {
>><*> {
>>firewall {
>>family inet {
>>filter <*> {
>>term DROP-RESERVED-SOURCES {
>>from {
>>source-prefix-list {
>>RESERVED-ADDRESSES;
>>}
>>}
>>then {
>>count DROP-RESERVED-SOURCES;
>>discard;
>>}
>>}
>>}
>>}
>>}
>>}
>>}
>>
>>MX_RE0# show logical-systems LSYS1 policy-options prefix-list 
>>RESERVED-ADDRESSES 
>>10.0.0.0/8;
>>172.16.0.0/12;
>>192.168.0.0/16;
>>
>>MX_RE0# show logical-systems LSYS1 firewall family inet filter CUST-IN 
>>apply-groups DROP-RESERVED-SOURCES;
>>
>>MX_RE0# show logical-systems LSYS1 firewall family inet filter CUST-IN | 
>>display inheri
>t
>>ance 
>>##
>>## 'DROP-RESERVED-SOURCES' was inherited from group 'DROP-RESERVED-SOURCES'
>>##
>>term DROP-RESERVED-SOURCES {
>>##
>>## 'from' was inherited from group 'DROP-RESERVED-SOURCES'
>>##
>>from {
>>source-prefix-list {
>>##
>>## 'RESERVED-ADDRESSES' was inherited from group 
>> 'DROP-RESERVED-SOURCES'
>>##
>>RESERVED-ADDRESSES; ## 'RESERVED-ADDRESSES' is not defined
>>}
>>}
>>##
>>## 'then' was inherited from group 'DROP-RESERVED-SOURCES'
>>##
>>then {
>>##
>>## 'DROP-RESERVED-SOURCES' was inherited from group 
>> 'DROP-RESERVED-SOURCES'
>>##
>>count DROP-RESERVED-SOURCES;
>>##
>>## 'discard' was inherited from group 'DROP-RESERVED-SOURCES'
>>##
>>discard;
>>}
>>}
>>
>>Notice the comment "## 'RESERVED-ADDRESSES' is not defined".  It is
>>defined...
>>___
>>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] Shutdown an interface based on CRC errors

[Phil Shafer]

Robert Hass writes:
>I'm looking for function which can shutdown an interface if CRC error
>threshold will be overdraft. Is any existing command for this in JunOS for
>MX and EX platforms ?

I'm not an SNMP hacker (and I don't play one on TV) but RMON can get
you half way there.  Tell SNMP to monitor the variable using something like:

[edit snmp rmon]
alarm 1 {
interval 10;
variable etherStatsCRCAlignErrors.515;
sample-type absolute-value;
rising-threshold 1;
falling-threshold 500;
rising-event-index 1;
}
event 1 {
type log;
}

Then put an event scirpt for a trigger:

[edit event-options]
policy monitor-crc {
events snmpd_rmon_eventlog;
then {
event-script monitor-events.slax;
}
}

But I've not been able to find out what the actual event looks like.  The
online help says:

phil@cli> help syslog SNMPD_RMON_EVENTLOG
Name:  SNMPD_RMON_EVENTLOG
Message:   
Help:  RMON event completed
Description:   The indicated remote monitoring (RMON) event completed.
Type:  Event: This message reports an event, not an error
Severity:  warning
Facility:  LOG_DAEMON

which isn't really great.  I'd assume the $$.message has what you
need encoded in a text string, but you'll need to get a sample to
be sure.

Then build an RPC to deactive the specific interface and commit it.
You might even be able to do this direct in the event policy using
simple commands.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] | display inheritance vs. logical-systems

[Phil Shafer]

Yes, it's a bug.  Please have your account team open a PR or let
me know and I'll open it.  From a quick look, the firewall data
model has the right reference, but it's not working, likely broken
somewhere in my (ui) code.

Thanks,
 Phil



Chuck Anderson writes:
>An interesting CLI bug:
>
>"show configuration | display inheritance" doesn't find prefix lists
>that are referenced via configuration groups that are applied inside a
>logical-system, but the configuration commits and works correctly:
>
>MX_RE0# show groups DROP-RESERVED-SOURCES 
>logical-systems {
><*> {
>firewall {
>family inet {
>filter <*> {
>term DROP-RESERVED-SOURCES {
>from {
>source-prefix-list {
>RESERVED-ADDRESSES;
>}
>}
>then {
>count DROP-RESERVED-SOURCES;
>discard;
>}
>}
>}
>}
>}
>}
>}
>
>MX_RE0# show logical-systems LSYS1 policy-options prefix-list 
>RESERVED-ADDRESSES 
>10.0.0.0/8;
>172.16.0.0/12;
>192.168.0.0/16;
>
>MX_RE0# show logical-systems LSYS1 firewall family inet filter CUST-IN 
>apply-groups DROP-RESERVED-SOURCES;
>
>MX_RE0# show logical-systems LSYS1 firewall family inet filter CUST-IN | 
>display inherit
>ance 
>##
>## 'DROP-RESERVED-SOURCES' was inherited from group 'DROP-RESERVED-SOURCES'
>##
>term DROP-RESERVED-SOURCES {
>##
>## 'from' was inherited from group 'DROP-RESERVED-SOURCES'
>##
>from {
>source-prefix-list {
>##
>## 'RESERVED-ADDRESSES' was inherited from group 
> 'DROP-RESERVED-SOURCES'
>##
>RESERVED-ADDRESSES; ## 'RESERVED-ADDRESSES' is not defined
>}
>}
>##
>## 'then' was inherited from group 'DROP-RESERVED-SOURCES'
>##
>then {
>##
>## 'DROP-RESERVED-SOURCES' was inherited from group 
> 'DROP-RESERVED-SOURCES'
>##
>count DROP-RESERVED-SOURCES;
>##
>## 'discard' was inherited from group 'DROP-RESERVED-SOURCES'
>##
>discard;
>}
>}
>
>Notice the comment "## 'RESERVED-ADDRESSES' is not defined".  It is
>defined...
>___
>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] SLAX/Curl is html-entity-encoding content

[Phil Shafer]

Ola Thoresen writes:
>It seems to work OK, except that the content is "html-encoded", which 
>causes errors when "the other end" don't expect it.

Use the "uexpr" statement to avoid escaping:

http://juniper.github.io/libslax/slax-manual.html#uexpr

 {
   uexpr $query;
}

Deep knowledge is here:

https://www.w3.org/TR/xslt#disable-output-escaping

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] apply-macro to set named communities on static routes?

[Phil Shafer]

Chuck Anderson writes:
>On Thu, Jan 28, 2016 at 02:16:52PM -0500, Chuck Anderson wrote:
>> Does anyone know why Junos doesn't accept named communities for static
>> routes?  This doesn't work:
>> 
>> set routing-options static route 192.0.2.0/24 community TEST
>> set policy-options community TEST members 65000:100
>> 
>> Instead we are forced to put the value directly:
>> 
>> set routing-options static route 192.0.2.0/24 community 65000:100
>
>Does anyone have any ideas on how to use a commit script to implement
>named communities on static routes?  Maybe with apply-macro?  I would
>love to see suggestions on how this might be implemented... Thanks!

Something like:

---
version 1.2;

ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0;;

import "../import/junos.xsl";

match configuration {
var $top = .;

for-each (routing-options/static/route/apply-macro[name == "community"]) {
var $delta := {
for-each (data/name) {
var $name = .;
for-each ($top/policy-options/community[name == $name]/members) 
{
 .;
}
}
}

if ($delta/community) {
call jcs:emit-change($dot = .., $content = $delta,
 $tag = "transient-change");
}
}
}



With this content:

[edit routing-options static route 192.0.2.0/24]
phil@dent# show
apply-macro community {
TEST;
}
next-hop 1.1.1.1;

-

adds this transient change:

[edit routing-options static route 192.0.2.0/24]
+community [ 65000:100 100:200 ];

--

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Anyone tried ThreatStop on Juniper integration?

[Phil Shafer]

Frank Sweetser writes:
>(For the curious, they integrate by installing some shell scripts on the 
>underlying FreeBSD level.  The scripts pull down customer specific lists of IP 
>addresses, and dynamically create slax scripts to update a set of prefix lists 
>in the local config to match.)

Very cool!  I've never heard of them, but seems like a great service.
I do see a kb article warning about performance issues:

  https://kb.juniper.net/InfoCenter/index?page=content=KB25813=search

But most of these issues can be mitigated.  For example, they change
config using "cat command-file | cli" which churns the change bits
in the database even when nothing changes; using "load update" will
solve that.  In addition, between JUNOS-12.1 and 15.1 we've done a
lot with commit performance which will help.

Another fix would be the use of the ephemeral database, which keeps
transient data away from human config, and allows us to avoid saving
it in juniper.conf (and the expense of writing it on every commit).

I've sent ThreatStop an offer to help with the incorporation of
these suggestions.  But if the bad-guys.list is available via http,
then we can make an event script that downloads it and "load updates"
it into the ephemeral database fairly easily.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] understand the index in jcs:break-lines() function in SLAX

[Phil Shafer]

Martin T writes:
>However, script above returns an empty line.

$line is a node-set, but you are making a string out of it.  XPath
specifies that when you turn a node-set into a string, it "is
converted to a string by returning the string-value of the node in
the node-set that is first in document order. If the node-set is
empty, an empty string is returned."

The numbering is "origin 1", so $line[1] is the first element, but
because the output starts with a newline, we know that $line[1]
will be empty.  You can confirm this in the debugger:

(sdb) p $line
[node-set] (6)

MAC address information:
  Public base address 00:19:e2:91:e4:00
  Public count1008
  Private base address00:19:e2:91:e7:f0
  Private count   16

(sdb) p $line[1]
[node-set] (1)


(sdb) p $line[4]
[node-set] (1)
  Public count1008

I ran your script on my mac using "juise -d @my-router your-script.xml"
and stepped thru to line 9.  You get the same debugger using "op
invoke-debugger" under JUNOS.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] sequential commands in SLAX

[Phil Shafer]

Martin T writes:
>/* rlogin to second RE */
>var $cmd_login_other_re =  "request routing-engine login
>other-routing-engine";
>var $cmd_login_other_re_results = jcs:invoke( $cmd_login_other_re );

If you want to talk to the other RE (or any remote host), you'll need
jcs:open() which returns a connection.  To talk to the other RE, you'll
need to know its hostname or ip address.

var $other-re = "re2";
var $conn = jcs:open($other-re);
var $res = jcs:execute($conn, $rpc);
...

>/* print out the name of the second RE */
> $junos-context//routing-engine-name;

The $junos-context will remain the local machine's context values.

>/* exit rlogin session */
>var $cmd_quit_other_re =  "quit";
>var $cmd_quit_other_re_results = jcs:invoke( $cmd_quit_other_re );
>Why doesn't such approach work?

The API is layered tightly over the CLI, but it's not the CLI.  It's
meant to be mode-less and RPC oriented.  Instead of passing commands
over a terminal, you pass RPCs to the host's MGD directly and get
XML back.  Details are available in the "Day One" guides:

http://www.juniper.net/us/en/training/jnbooks/day-one/automation-series/

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] read CLI "banner" XML element value with SLAX script

[Phil Shafer]

Martin T writes:
>Junos has "banner" XML element under "rpc-reply" and "cli" hierarchy:

This is really only available between cli and mgd.  It's internal
and we shouldn't display it at all during "display xml".  There's
a PR to stop showing it.

Like Jonathan said, the $junos-context is a better source.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Could JUNOS script accept 2 variable to generate a filter name

[Phil Shafer]

Diogo Montagner writes:
>Try this:
> _ $users _ $meter;

Yes, "_" is a valid character to have in a variable name, so
you must have spaces around it.  And it's a good idea for
readability anyway.

You can use "slaxproc --format" to format slax scripts into standard
style (read: what Phil likes), which uses lots of spaces.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NETCONF in Junos

[Phil Shafer]

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.

Ah, the third class, where the developer didn't give a name for
the RPC in their data model.  The content's XMLified, and you
can access it via the  RPC, but there's no name given
for it.  I'll open a PR for this one (PR 1150044).

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NETCONF in Junos

[Phil Shafer]

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 specific destination was extremely slow until 
>I've removed " table inet.0" from it, so I thought that it might 
>actually ssh to itself in some strange way.

Yes, it definitely needs fixed.  Please have your account team
open a PR for this.

>Well...every system has its quirks. And was written by people, some of 
>whom are lazy and/or motivated by deadline.

Engineering is all about tradeoffs, but this one's disappointing.  We'll
get it fixed.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NETCONF in Junos

[Phil Shafer]

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
have issues with are in two classes: those with functionality written
in the CLI (interactive commands) and those that use odd features
that don't normally require rendering.  The second class is rare
but annoying.  An example would be "show route advertising-protocol
bgp 10.1.2.3", which uses a mechanism for nesting parameters, which
are awkward and rarely used.  There's a PR for this and we're fixing
it.  I've not heard of an issue with "show virtual-chassis", and
it does not fit into either of these two classes.  Not good.

>FWIW the only two things I can cite as dislikes are the 
>infinite-stream-of-XML for Junoscript (solved in Netconf of course) and 
>the somewhat inexplicable embeddeing of the running software version (as 
>opposed to a semantic version) into the various /junos-* XML namespaces, 
>which makes them a bit of a bore to process with a namespace-strict XML 
>library.

This "simple document view" was one of the things we wanted to fix
when we took our XML API to the IETF, along with a framing mechanism
and some more flexible namespace constructs.  Initially we only got
one out of three addressed, but have finally gotten a framing
mechanism (in rfc6242) and YANG will allow us to move away from
version-specific namespace.  It's definitely taken too long to get
there, but it's happening.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NETCONF in Junos

[Phil Shafer]

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
>executes "show version" in Junos CLI) do not travel internally over
>SSH as remote calls would, do they?

Yes, JUNOS is built around NETCONF.  More precisely, the plumbing
in JUNOS is what NETCONF was based on.  We built (way back in
JUNOS-4.1) an API on top of our CLI infrastructure as a no-additional-cost
perk of our heavy use of meta-data.  Our config data is all described
in data models (read: YANG) so we can easily emit our data in text,
XML, or JSON.

The JUNOS UI consists of two major pieces, the CLI and MGD.  The
CLI really just handles the terminal.  It does command line input
processing (emacs keybindings) and output rendering (xml-to-text
and automore).  There's not just in the CLI itself.  It's about as
dumb as I could make it.  All the real magic happens in the MGD
daemon.

CLI and MGD talk to each other over a unix-domain socket, so there's
no SSH overhead for CLI commands.

When you issue a command at the CLI, the CLI packages it up and
ships it (in XML) to MGD (the management daemon) who parses it into
an internal form.  When an API client send XML to a JUNOS device,
MGD builds the same internal form.

>From that point on, the code path of the command/RPC is shared.
It's forwarded to the responsible subcomponent (e.g. RPD), who emits
an XML response, which is forwarded back to the CLI or API client.

The CLI would then convert that XML into text for human readers.
(The "display xml" pipe really just turns off that rendering in the
CLI and the "display xml rpc" pipe really just returns that "internal
form" object mentioned above to the CLI, who renders it.)

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 (with
the exception of terminal-oriented commands like "monitor interface",
etc).

Our use of meta-data also means that we can more easily implement
UI features like config groups, "deactivate", and "protect" since
their implementation is entirely within the UI.

It also means (moving forward) that our forthcoming loadable YANG
features will ride for free over the same plumbing.

Sorry if this got a bit long, but honestly it was a soft pitch and
I couldn't resist bragging about my baby.  ;^)

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] understand "version" and "ns"(namespace) statements in SLAX scripts

[Phil Shafer]

Martin T writes:
>While I understand the idea of namespace in XML, then what is the
>point of those statements in SLAX scripts? In addition, how does the
>"version" statement work?

The version statement indicates the version of SLAX being used.  It
also confirms that the input is in fact a slax script.

There are currently three minor revisions of SLAX: 1.0, 1.1, and 1.2.
1.2 is completely backward compatible with 1.0 and 1.1, and 1.1 is
completely backward compatible with 1.0.

SLAX-1.1 adds all XSLT concepts directly to SLAX, where in 1.0 one
had to use the "xsl" namespace to access them (e.g. ),
as well as a debugger.  Details are in:

https://github.com/Juniper/libslax/wiki/NewIn1-1

I don't have as nice a write up for 1.2, but it adds two key things:
JSON-style data and data as arguments.  These allow code like:

var $x = {
"this": "that",
"one": 1
}
call my-template($rpc = );

There also a "main" statement that allows one to say:

main  {
call emit-my-output();
}

Note that the "--write-version" option to slaxproc can be used
to convert between versions:

% cat /tmp/foo.slax
version 1.2;

main  {
var $x = {
"this": "that",
"one": 1
}
call my-template($rpc = );
}
% slaxproc --format --write-version 1.0 /tmp/foo.slax
version 1.0;

match / {
 {
var $x = {
 "that";
 "1";
}
var $slax-temp-arg-1 = ;

call my-template($rpc = slax-ext:node-set($slax-temp-arg-1));
}
}

>ns junos = "http://xml.juniper.net/junos/*/junos;;
>ns xnm = "http://xml.juniper.net/xnm/1.1/xnm;;
>ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0;;
>ns ext = "http://xmlsoft.org/XSLT/namespace;;

The "ns" statement defines XML namespaces using the xmlns attribute.
The SLAX docs for it are here:

http://juniper.github.io/libslax/slax-manual.html#ns

and the XSLT docs are here:

http://www.w3.org/TR/xml-names11/#concepts

Note that the junos namespace is a bit "magic", in that when the
jcs:invoke and jcs:execute functions read data, they convert between
the version-specific namespace used by JUNOS into the "/*/" value
used above in the "ns junos" statement.  This removes the burden/pain
of namespaces and makes them much more useful.

Also in SLAX-1.2, namespaces are a bit simplified, so a script does
not need to explicitly name a namespace that implements extension
functions, since the extension function libraries will record their
information when they are installed.  For example, the "curl" and "bit"
namespaces (used to access libraries that ship with libslax) are automatically
discovered without the need for an explicit "ns" statement.  You
can see these discovered values using "slaxproc --format":

% cat /tmp/foo.slax
version 1.2;

main  {
expr bit:from-int(32, 10);
}
% slaxproc --format /tmp/foo.slax
version 1.2;

ns bit extension = "http://xml.libslax.org/bit;;

main  {
expr bit:from-int(32, 10);
}

The full docs for slax are available as part of the libslax
project on github:

   http://juniper.github.io/libslax/slax-manual.html

The "juise" project adds the juniper-specific libraries and a
program (called juise) that simplifies invoking op scripts
against a junos box.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NETCONF in Junos

[Phil Shafer]

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 fine
detail, but I just wanted to be precise.  This setup allows us to
render into other formats as well, including the normal braces-based
text or "set" format:

phil@rtr> show configuration | display ?
Possible completions:
  changed  Tag changes with junos:changed attribute (XML only)
  commit-scripts   Show data after commit scripts have been applied
  detail   Show configuration data detail
  inheritance  Show inherited configuration data and source group
  json Show output in JSON format
  max-depthMaximum depth of configuration data
  omit Emit configuration statements with the 'omit' option
  rfc5952  Display IPv6 addresses as per RFC 5952 specifications
  set  Show 'set' commands that create configuration
  xml  Show output as XML tags

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NETCONF in Junos

[Phil Shafer]

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 
>'super-user'
>mgd[68498]: UI_LOGIN_EVENT: User 'root' login, class 'super-user' [68498], 
>ssh-connectio
>n ' 60259  22', client-mode 'cli'
>mgd[68498]: UI_CMDLINE_READ_LINE: User 'root', command 'show route summary | 
>display xml
> | grep table-name '
>mgd[68498]: UI_LOGOUT_EVENT: User 'root' logout
>mgd[62935]: UI_CHILD_STATUS: Cleanup child '/bin/sh', PID 68494, status 0
>
>Obviously I don't login under root, but somehow my CLI spawns a shell, then 
>sshes to its
>elf under root (?) using my credentials (?) to do a single command. Then it 
>logs out. Ev
>ery time I request something about route tables.

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, we run something like
"ifinfo -n" or look at internal MGD info.  This completion for the "table"
argument is just some suboptimal code.

Note that the ssh-connection information being logged does not mean
that we're invoking a new ssh session, just that we're reporting
the current info.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Could JUNOS OP Script support generate firewall filter term and added before original one?

[Phil Shafer]

Chen Jiang writes:
>I have a requirement from end user that want to automate firewall filter
>configuration procedure, that means they want to use OP script to generate
>a customized firewall filter term and added it before the last "deny all"
>term.

Steve Hulshof suggestion re: using config groups is a great one,
since it removes the possibility of error.  The group plumbing will
ensure the ordering of terms so your "default-all" term ends up last.

But you can use the normal  payload to control ordering:

http://www.juniper.net/documentation/en_US/junos15.1/topics/task/configuration/junos-xml-protocol-configuration-data-elements-reordering.html

For your case, this would be something like:

var $conf =  {
 {
 {
 {
 "new-term";
 {
 "new-term";

}   }   }   }   }

Hmm. you can also insert="first" and insert="last" (with no
identifiers), but that doesn't seem to have made it into the docs.
Sorry about that.  Now PR 1148401.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Phil Shafer]

Stepan Kucherenko writes:
>But let's say we want to add another address for another client
>
>[edit interfaces ge-0/0/0 unit 0]
>cli# set family inet address 6.7.8.9/10
>
>[edit interfaces ge-0/0/0 unit 0]
>сli# comment "Client Y" [ESC-,]
>
>family inet {
>/* Client Y */
>address 1.2.3.4/5;
>address 6.7.8.9/10;
>}
>
>Correct ?

No, each object in the database can have its own comment attached,
and since the two addresses are distinct objects, each can carry a
comment, like:

[edit]
phil@dent# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
/* one */
address 10.1.2.3/30;
/* two */
address 10.4.5.6/30;
}
}
}

>set protocols bgp group ix-v4 type external import [ reject-some-prefixes 
>///don't like 
>them// set-community //for further filtering// ] peer-as X neighbor 1.2.4.5 
>//location//
> export customers-only //please don't delete this//

Personally, I dislike this.  It makes command lines less readable and
more likely to cause errors.

But along the same line, I have kicked around the idea of making
"load" be truly interactive, so I could to stuff like:

[edit]
cli# load terminal merge interactive
[Type ^D at a new line to end input]
protocols bgp group foo local?
Possible completions:
  local-addressAddress of local end of BGP session
> local-as Local autonomous system number
  local-interface  Local interface for IPv6 link local EBGP peering
  local-preference Value of LOCAL_PREF path attribute
protocols bgp group foo local-as ?
Possible completions:
Autonomous system number in plain number or 'higher 
16bits'.'Lower 16 bits' (asdot notation) format
  aliasTreat this AS as an alias to the system AS
  loopsMaximum number of times this AS can be in an AS path 
(1..10)
  no-prepend-global-as  Do not prepend global autonomous-system number in 
advertised paths
  private  Hide this local AS in paths learned from this peering
protocols bgp group foo local-as 42;
^D
load complete

This would allow set-ish style (since the UI really doesn't need the
braces on input) as well as allowing the placement of comments:

[edit]
cli# load terminal merge interactive
[Type ^D at a new line to end input]
protocols bgp /* foo is cool */ group foo /* local-as is also */ local-as 42;
/* You can also put braces here */
protocols {
   bgp {
  /* goo is not */
  group goo { local-as 51; }}}
^D
load complete


But I need to work out what (and how) would get redrawn when you
type "?" deep under braces (like at the "51" above).  I can't emit
the [edit] line, but just redrawing the current line doesn't give
the context the way I'd like it to.  Perhaps a distinct key to give
the content-as-edit-line?

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Phil Shafer]

Stepan Kucherenko writes:
>What else...oh, annotate ! It's clunky and not very easy to use.

Yes, annotate is a sore spot.  I made the grammar production:

K_ANNOTATE annotate_target T_STRING

with the expectation that I'd be able to coerce a path into the
target, but it didn't happen.  I should have done it as:

K_ANNOTATE T_STRING annotate_target

and then allow anything as a target, like:

cli# annotate "Client X" interfaces ge-0/0/0.0 family inet address 1.2.3.4/5

but can't make that work without making a new command ("comment"?).

>I wish we could just add a comment in the end of a line instead, like 
>"set interface ge-0/0/0.0 family inet address x.x.x.x/y //client X" and 
>then see "x.x.x.x/y //client X" and the same line when asking for 
>|display set.

We generate line comments in JUNOS, so we need to discard them (and
comments before close braces) to prevent out-of-date comments from
getting loaded as real annotations.

Hmm  I should make a M-, keybinding to copy all arguments from the
previous command so you can:

[edit interfaces ge-0/0/0 unit 0]
cli# set family inet address 1.2.3.4/5

[edit interfaces ge-0/0/0 unit 0]
cli# comment "Client X" [ESC-,]

and it will insert the "family inet address 1.2.3.4/5" from
the previous "set" command.

This is similar to the existing M-. and M-/ bindings.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] purpose of "commit check"?

[Phil Shafer]

Chuck Anderson writes:
>On Thu, Oct 01, 2015 at 12:30:51AM +0300, Martin T wrote:
>> So in order to sum this up, "commit check" makes sense at least in
>> following cases:
>> 
>> 1) confirm "commit confirmed" action. This does not waste a rollback.
>> 2) test errors for configuration which will be saved and committed later
>> 3) make intermediate syntax checks in case of large configurations in
>> order to make sure that configuration applied to candidate
>> configuration so far is fine
>> 4) use "commit check" to trigger commit scripts
>5) coordinate commits across multiple devices to be sure they will all
>succeed at the same time when the final commits are given

Similarly pre-checking a "commit at" makes sense.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] purpose of "commit check"?

[Phil Shafer]

Tom Storey writes:
>o/t but is there any difference between "show | compare" and "show | diff" ?

Nope, it's just an alias, similar to "grep" for "match".  I didn't think
I could teach my fingers not to type the unix names.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] purpose of "commit check"?

[Phil Shafer]

Aaron Dewell writes:
>Yes, the commit will fail if commit check would have also failed.

Yup, "commit check" just passes a flag into the commit logic which
triggers an early return.

>I tend to use commit 
>check as a check on myself when I've done a big cut-and-paste, or when 
>creating a bunch
>of objects.

"show | compare" is also useful for this sort of verification.

>The time to fail of commit check is less than commit if there are 
>discrepancies.  

This shouldn't be true, given that they share the same logic.

>>> If yes, then what is the point of "commit check"?

Doing a pre-check before a commit is mostly about working up the
confidence that you're not going to break something.  We've got
"commit confirmed" to help with this also.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] event-options to modify configuration

[Phil Shafer]

Chen Jiang writes:
change-configuration {
retry count 3 interval 1;
commands {
set interface ge-1/0/0 description test;

Try changing interface to interfaces in this line.  The
commands need to be explicit/exact.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Arguments for commit scripts

[Phil Shafer]

Yup, apply-macro is the perfect spot for stuffing data.  Consider using
a top-level apply-macro with a name indicating your script, and then
the value under it:

apply-macro my-script-name {
my-parameter my-value;
other-paramer other-value;
}

Then you'll need something in your script like:

match / {
op-script-results {
var $params := {
call get-params();
}
var $my-parameter = $params/data[name == my-parameter]/value;
var $other-parameter = $params/data[name == other-parameter]/value;
}
}

template get-params ($name = my-script-name) {
var $rpc = get-configuration database=committed {
configuration {
apply-macro {
name $name;
}
}
}
var $config = jcs:invoke($rpc);
var $params = $config/apply-macro;

copy-of $params;
}

The share-data script in the Junoscriptorium has some of these elements,
if that helps for reference.

https://github.com/Juniper/junoscriptorium/tree/master/library/juniper/op/network/share-data

Thanks,
 Phil





Tim Jackson writes:
Use an apply-macro..

--
Tim

On Wed, Mar 18, 2015 at 3:27 PM, Ross Vandegrift r...@kallisti.us wrote:
 Hi all,

 Working on a commit script with a regex that might need occasional updates.
 Ideally, this could be stored in the config, and loaded at run-time.
 Possible?

 If not: any catches with abusing annotate to provide this?

 Thanks,
 Ross

 ___
 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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] how to see users

[Phil Shafer]

Aaron writes:
But how do I show users that are configured without viewing it in the config
file? 

Not sure if the issue is config db or config mode, but if that latter:

show configuration system login |match ^user

|display inheritance might also be desired.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Comments display (annote command) via show command !!

[Phil Shafer]

Harri Makela via juniper-nsp writes:
http://www.juniper.net/techpubs/en_US/junos10.1/information-products/topic-collections/s
wconfig-cli/topic-20962.html
is there any command which can show us the comments which we have added via 
annote com
mand other than configuration mode ?

Not sure what you are asking for.  You want to see just the comments, not
the config?  You want to see comments added since the last commit?  If
you want comments without the data, you can:

show configuration | match /\*|#

But without the context, the output is, well, useless.

You can add | except ## to remove the line comments added by JUNOS itself,
like:

## Warning: 'exclude' is deprecated
## SECRET-DATA
## Last commit: 2015-02-10 18:05:53 EST by phil

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] show system boot-messages

[Phil Shafer]

show system boot-messages == file show /var/run/dmesg.boot

where /etc/rc says:

   # Keep a copy of the boot messages around
   dmesg  /var/run/dmesg.boot

Thanks,
 Phil


Scott Granados writes:
Can't you execute the dmesg command from the shell and watch the output there?

On Jan 20, 2015, at 1:38 PM, Saku Ytti s...@ytti.fi wrote:

 On (2015-01-20 11:26 +), Adam Vitkovsky wrote:
 
 Hey Adam,
 
 I assume the cmd show system boot-messages shows just the Junos booting 
 process
 Is there a way to see the whole boot dumps- you know HW booting 
 (MPCs/PEMs/SCBs/REs) 
-or is that even recorded somewhere please?
 
 You need to observe console port during boot to see all. For MPC connect to
 them 'start shell pfe direct fpcX' before booting.
 
 -- 
  ++ytti
 ___
 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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Has anyone else tried this?

[Phil Shafer]

Or with the number of recruiters ;^)

Ob.Haiku:

Haikus are magic
Springing from your CLI
Wasting half your day


Paul Goyette writes:
Yeah, but it didn't scale with our number of employees!



-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Chris Adams
Sent: Monday, October 06, 2014 08:23 PM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Has anyone else tried this?

Once upon a time, Dovid B do...@telecurve.com said:
 root@gw3.nj1 show version and haiku
 Hostname: gw3.nj1
 Model: srx240h2
 JUNOS Software Release [12.1X44-D30]
 
 
 My session is dead:
 Forgot to commit confirm.
 Where are my car keys?

That one is good, but show version and blame was better. :)
-- 
Chris Adams c...@cmadams.net
___
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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BGP Peer formatting

[Phil Shafer]

Ben Dale writes:
 https://github.com/dfex/DFEXjunoscripts/blob/master/show-bgp-neat.slax

Very cool!

Hey Phil, when can we have git native in Junos?!  ; )

How about:

op url 
https://raw.githubusercontent.com/dfex/DFEXjunoscripts/master/show-bgp-neat.slax

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BGP Peer formatting

[Phil Shafer]

Ben Dale writes:
Okay, one small caveat to this script - it looks like the use of mutable 
variables (mvar
 and set) was only introduced in SLAX 1.1 / Junos 12.2, so it's actually not 
 going to wo
rk on older versions of Junos.

I know 11.4 is the trusted choice for most people on MX at the moment, so when 
I get som
e time I'll attempt a mind-bending re-write using the older immutable var 
format.

In this case, you don't need the mvars.  Let sum() do the iteration:

for-each ($neighbour-list/bgp-peer) {
output jcs:printf(%-20s%-15s%-12s%-10s%-10s%-10s%-10s%-5s,
peer-address,
peer-as,
peer-state,
elapsed-time,
sum(bgp-rib/active-prefix-count),
sum(bgp-rib/received-prefix-count),
sum(bgp-rib/accepted-prefix-count),
description);   
}

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

[Phil Shafer]

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] Authentication Keys

[Phil Shafer]

Alexander Arseniev writes:
Putting password ONLY in a web form so it cannot be attributed to a 
particular router/company/person - harmless. Use public VPN to hide Your 
source IP if You are concerned about security - 

Even then, you've no idea if your password is being added to someone's
dictionary.   Using the perl code avoids this issue.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Netconf namespaces

[Phil Shafer]

Phil Mayers writes:
I guess. What about rpc payloads, thinking in particular config XML blocks?

We'll ignore incoming namespaces there as well, but should be
generating proper standard XML.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Netconf namespaces

[Phil Shafer]

Phil Mayers writes:
OTOH I've seem XML come back from some devices like this:
rpc-reply
   namspaced:tag
  ...
i.e. no xmlns for the namespace on a tag. This is just broken, and 
really hard to deal with using normal XML libraries.

Yes, that would definitely be a bug.

I don't think netconf wants to end up like XMPP where you have to use a 
custom XML parser and serialiser just to make it go, at which point you 
might as well not have used XML. We're still early enough into Netconf 
that we might be able to dodge that, if enough people push back on it.

Definitely not.  NETCONF should be real standard XML content.

  ns junos = http://xml.juniper.net/junos/*/junos;;

Yeah, that's kind of annoying... I do wonder why you didn't rev the 
version number on dialect changes rather than software version cahnges, 
but I guess it's too late to go back on that one.

We wanted to have specific XSD to match each version of JUNOS, so
if we add (or remove) an enumeration from a leaf, or extent the range,
or add a new leaf, you can validate your configuration against an
XSD (or YANG module) that's specific to your version of JUNOS.

In retrospect, perhaps I should have used an out-of-band mechanism
for this.  But I was trying to use as much of the standard bits as
possible.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Netconf namespaces

[Phil Shafer]

Phil Mayers writes:
The fundamental question is: are namespaces used incorrectly all over 
the place in Netconf?

JUNOS has some namespace issues, suffering from both pre-rfc
implementation problems and attempts to re-use the underlaying
Junoscript XML API code.  PR 826463 is addressing these.

I've looked at the PyEZ and ncclient code, and basically they seem to 
take the approach of just throwing away all namespace information. This 
seems icky to me, and make me wonder if Netconf is going to be another 
SOAP - so many implementation errors that interop ends up being a mess 
of special casing and workarounds.

Namespaces are a two-edged sword, and while they are great for
telling you _exactly_ what data you are seeing, this exactness
is often painful.

For example, each version of JUNOS uses a unique namespace, and
we publish specific data models (DTDs, XSDs, and soon YANG) for
each specific version.  But a namespace like:

http://xml.juniper.net/junos/13.3I0/junos

means that an XPath expression (or the XSL script containing it)
would need that specific URI to match, which can be a maintenance
issue.  For SLAX, I replace the version with * to make a namespace
that can be used across versions:

ns junos = http://xml.juniper.net/junos/*/junos;;

This is just an example and is disjoint from the issues in PR 826463,
where we mistakenly put elements from junos in netconf space and
vice versa.

Thanks,
 Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] sshd log messages !!

[Phil Shafer]

Ben Dale writes:
set system services ssh port 1024-65535
...
maybe an allow-sources might be a bit more useful in this instance?  Less 
sophisticate
d users tend to shoot themselves in the foot with firewall filters quite 
regularly.

Would a firewall filter on lo0 be a better answer for this?
Dropping packets in hardware prevents intruders having any
impact on the RE.

Thanks,
 Phil

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to clear bgp neighbor

[Phil Shafer]

Saku Ytti writes:
But I'm generally against downward-compatibility, it hurts innovation and
creates codebase complexity creep (i.e. bugs). I'm all for regularly exploding
everything.
In JunOS case, between major version, you could state that all bets are off
with backward compatibility and fix crimes of those who became before us(tm).
But I understand my opinion is not popular one and would not pass marketing.

Our original strategy was to help customers to move to the most
modern software release, mainly as a means of reducing support
costs [1].  So anything that would impact someone moving to modern
software is bad, including retooling and debugging applications and
automations that used to work perfectly [2].  We want to enable
customers to build these tools, with the assumption that automation
reduces customer OPEX and allows deployment of the high-touch
services where JUNOS can really shine.

This is also the motivation behind the XML APIs (e.g. NETCONF) which
allow you to move from regex-based screen scraping of CLI data to
being able to make elegant XPath experssions [3].  The goal is more
robust, stable, and supportable automations, both on box (with the
op/event/commit scripting facilities) and off box (with any NETCONF
client.

Sorry if I'm venturing toward shameless self promotion here, but
this really is an area we try to work at.  That's part of the
movation for asking if this one specific case is sufficiently
irritating to break our own rules.

Thanks,
 Phil

[1] It also enhances feature deployment; there's nothing worse that
bragging about a new feature like the refresh pipe or the protect
command to customers that don't have plans for near-term upgrades.

[2] Okay, debugging a script that *used* to work is definitely
worse.  As is trying to look at a regex and sleuth out what the
original author was trying to extract.  Or finding out the regex
broke because the new release added new information to the CLI
output.  In fact, there's a lot of things worse.

[3] Obligatory simple example (in SLAX):

for $ifname ($config/protocols/ospf/interface/name) {
if (not($config/protocols/ldp/interface[name == $ifname])) {
call error($message = missing LDP config for  _ $ifname);
}
}

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] proposed changes to clear bgp neighbor

[Phil Shafer]

Juniper users,

We've been asked to make a change the clear bgp neighbor command
to make the neighbor or all argument mandatory.  The root cause
is the severe impact of clear bgp neighbor and the increasing
accidental use of this command without a specific neighbor.

In general, we avoid changing commands to add mandatory arguments,
but my feeling is that the impact and severity of this specific
command makes this an acceptable occasion for such a change.

I'm looking for feedback about this change.  My working assumption
is that clear bgp neighbor is a sufficiently rare command and
would not be used in automation/scripts, so the impact of making
the neighbor/all argument mandatory would be minimal.  Is this
assumption accurate?

Thanks,
 Phil

[I've set reply-to to myself to avoid impacting the list]

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to clear bgp neighbor

[Phil Shafer]

Jerzy Pawlus writes:
  1. Would it be possible to clear bgp neighbor command do nothing?
 after applying above change.

We could have it say something like Oh no you didn't!, but
I'd rather use the CLI completion to get users to see that
something more is needed.

  2. You can add an option under protocol bgp allowing to choose
 the syntax of the clear bgp neighbor command

Sure, but I'm trying to avoid the scenario when the user has to
turn on a config knob to get us to do the obviously right thing.

Thanks,
 Phil

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] proposed changes to clear bgp neighbor

[Phil Shafer]

ryanL writes:
it's a nice-to-have, maybe? but this sounds more like an opportunity for
you to sell some JNCIA courses. i mean, how long has junos been around now?

Not selling anything; just trying to solve a problem multiple
customers have reported and escalated.  I'm a software developer,
working on the UI code (CLI, MGD, configuration, XML API, scripting)
for 17+ years.

JUNOS 3.0 (the first release with the ui code) shipped during the
summer of 1998, IIRC.

Thanks,
 Phil

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] batch on junos ?

[Phil Shafer]

Depending on your purpose and whether this is a one-off or a
continuing need, JUNOS has a number of tools to help you.

For a simple command, others have already pointed out that
you can pipe commands to ssh.  You can also use a command
line to give multiple commands:

ssh my-router configure; set system host-name foo; commit

For a longer-term need, you can make scripts using the JUNOS Automation
features (notably op scripts):

var $connection = jcs:open();
var $configuration = configuration {
system {
host-name foo;
}
}
var $res = jcs:load-configuration($connection, $configuration);

The jcs:load-configuration template will load and commit the
contents of the $configuration variable.

For more information, see the Recommended Reading sidebar on:

 https://www.juniper.net/us/en/community/junos/script-automation/

Also note that you can now run script in SLAX (the language used for
on-box scripting) using the juise package (github.com/Juniper/juise).

Thanks,
 Phil


R S writes:
Is there a way to run a sort of .bat on SRX junos ?

I mean, to run a single command from cli to do some actions (set xxx/ set yyy/ 
commit ch
eck / commit) ?

This is useful to be runned by NOC for scheduled action every day.

Tks


 
___
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