Re: [j-nsp] SRX VPLS learning domains

[Tom Storey]

Ive been through this myself. The short of it is that you will need a
VPLS instance for each VLAN you wish to carry on SRX.

I dont remember the exact details, but the MX do some "magic" to
automatically carry multiple VLANs through a single VPLS instance,
whereas the SRX do not.

Try as you might, you probably wont get it to work and will waste
countless hours on it (unless theyve changed something in more recent
JunOS versions...) :-)

On 24 December 2015 at 23:26, Dan Rimal  wrote:
> Hi,
>
> I am trying to pass multiple VLAN via single VPLS routing instance and
> assume separate learning domain for every single VLAN. I tried knob
> "vlan-id all" under routing instance without success. O MX series it
> works, it create multiple learning domain, on SRX 240 (second site) nope
> and same MAC from different VLANs collide. Is it some SRX limitation or
> something like this?
>
> Junos 12.1X46-D35 on SRX240B
>
> My config:
>
> ge-0/0/3 {
> vlan-tagging;
> mtu 1590;
> encapsulation flexible-ethernet-services;
> unit 512 {
> description CE-facing-1;
> encapsulation vlan-vpls;
> vlan-id 512;
> family vpls {
> policer {
> input vpls-10m;
> output vpls-10m;
> }
> }
> }
>
>unit 513 {
> description CE-facing-1;
> encapsulation vlan-vpls;
> vlan-id 513;
> family vpls {
> policer {
> input vpls-10m;
> output vpls-10m;
> }
> }
> }
>
>
>VPLS-ALGO-V512 {
> instance-type vpls;
> interface lt-0/0/0.0;
> interface ge-0/0/3.512;
> interface ge-0/0/3.513;
> vlan-id all;
> route-distinguisher 31.41.176.64:512;
> vrf-target target:36736:512;
> protocols {
> vpls {
> site-range 4;
> mac-table-size {
> 128;
> packet-action drop;
> }
> no-tunnel-services;
> site j3r-512 {
> site-identifier 2;
> interface ge-0/0/3.512;
> interface ge-0/0/3.513;
> interface lt-0/0/0.0;
> }
> connectivity-type ce;
> }
> }
> }
>
>
> Thanks,
>
> Dan
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] NETCONF 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] NETCONF in Junos

[Stepan Kucherenko]

>
> 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.


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.


Then again, it starts cli as root which is an expensive operation in itself.

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







___
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

[j-nsp] SRX VPLS learning domains

[Dan Rimal]

Hi,

I am trying to pass multiple VLAN via single VPLS routing instance and
assume separate learning domain for every single VLAN. I tried knob
"vlan-id all" under routing instance without success. O MX series it
works, it create multiple learning domain, on SRX 240 (second site) nope
and same MAC from different VLANs collide. Is it some SRX limitation or
something like this?

Junos 12.1X46-D35 on SRX240B

My config:

ge-0/0/3 {
vlan-tagging;
mtu 1590;
encapsulation flexible-ethernet-services;
unit 512 {
description CE-facing-1;
encapsulation vlan-vpls;
vlan-id 512;
family vpls {
policer {
input vpls-10m;
output vpls-10m;
}
}
}

   unit 513 {
description CE-facing-1;
encapsulation vlan-vpls;
vlan-id 513;
family vpls {
policer {
input vpls-10m;
output vpls-10m;
}
}
}


   VPLS-ALGO-V512 {
instance-type vpls;
interface lt-0/0/0.0;
interface ge-0/0/3.512;
interface ge-0/0/3.513;
vlan-id all;
route-distinguisher 31.41.176.64:512;
vrf-target target:36736:512;
protocols {
vpls {
site-range 4;
mac-table-size {
128;
packet-action drop;
}
no-tunnel-services;
site j3r-512 {
site-identifier 2;
interface ge-0/0/3.512;
interface ge-0/0/3.513;
interface lt-0/0/0.0;
}
connectivity-type ce;
}
}
}


Thanks,

Dan

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

Re: [j-nsp] NETCONF in Junos

[Phil Mayers]

On 24/12/2015 09:10, Phil Shafer wrote:


The real value is that the API comes for free, since it's using the
same internal plumbing.  This means that when a feature ships in
the CLI, it's immediately available in the API.  No lag.  No
additional cost.  No missing bits.  It's literally all there (with
the exception of terminal-oriented commands like "monitor interface",
etc).


I keep having to explain to other vendors and fellow engineers why this 
approach is so valuable, and so inherently superior to off-box 
middleware "API" solutions or obfuscated "SDK" blobs.


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.


In the example I've given I think that command might be an alias to 
"show virtual-chassis status" as the output is identical and "| dis xml 
rpc" does work there. I've come across a few others, but memory is 
failing me this close to Christmas!



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


You should be justly proud of it. JunOS has its faults, but it's API and 
config model are the best in the industry by a very large margin IMO.


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.


But both of those are trivial to resolve, compared to (say) running 
expect against an ever-changing human-readable CLI!


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