Re: [j-nsp] How to catch invalid value/option for a command in SLAX script?
* Phil Shafer > 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. Ah, so you're the one to blame for the mounds of torn-out hair around my desk... ;-) There are more of these yet to be fixed, unfortunately. For example: $ echo '' | ssh -s lab-ex4200 netconf [...] http://xml.juniper.net/junos/15.1R4/junos";> http://xml.juniper.net/junos/15.1R4/junos-interface"; junos:style="normal"> ge-0/0/0 [...] This in turn means that XPath expressions such as «/physical-interface[name="ge-0/0/0"]» don't work, which is a _major_ pain in the arse. http://www.juniper.net/documentation/en_US/junos15.1/topics/task/operational/netconf-operational-request-output-format.html states that «the NETCONF server returns the information in XML-tagged format, which is identical to the output displayed in the CLI when you include the | display xml option after the operational mode command», which is simply not true. Compare with the above output: $ ssh lab-ex4200 'show interfaces | display xml' http://xml.juniper.net/junos/15.1R4/junos";> http://xml.juniper.net/junos/15.1R4/junos-interface"; junos:style="normal"> ge-0/0/0 [...] There's also something fishy going on with whitespace magically appearing inside tags. I'll demonstrate. First I add a comment to the config: $ cat << EOF | ssh lab-ex4200 -s netconf > > > > > /* This is a multi-line > * comment whose lines are > * NOT indented in any way */ > > > > > > ]]>]]> > EOF Fetching this comment back via NetConf works as expected: $ echo '' | ssh lab-ex4200 -s netconf [...] /* This is a multi-line * comment whose lines are * NOT indented in any way */ Fetching it via CLI and «| display xml» on the other hand: $ ssh lab-ex4200 'show configuration | display xml' [...] /* This is a multi-line * comment whose lines are * NOT indented in any way */ wtf? I tried my luck with JTAC on these issues in case 2015-1202-0037 last year, but that didn't go anywhere useful. Maybe you can open an internal bug issue or something instead and hopefully these issues will get fixed eventually. Tore ___ 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?
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
[j-nsp] Basic NAT44 on MS-MPC implementation help
Hi all. I've gone through quite a few pages of juniper techpubs, but I'm having a problem figuring out how to correctly implement your standard, run of the mill NAT (ipv4) using an MS-MPC-128 Part of this may be design or topology related, and I was wondering if someone could help me figure out a solution. WAN-CORE (MX960)<-ae1->EX4500 So I have a couple of ports on the EX4500's with different RFC6598 (CGNAT Range) subnets on them (routed ports), for various different things (say range1, range2, range3, etc) All I want to do, is route any traffic coming in to the CORE from range1/2/3/etc to a certain /32 (a different /32 for each range). Pretty simple, your basic NAT setup. My problem I think is how to apply this in somewhat a transparent fashion. Currently, what I've pulled up off the web seems to break all the things, as it seems like everything is getting forwarded through the ms-mpc interface. Here's what I have so far, if somebody could help me out real quick or show me another method it would be greatly appreciated. - customer ip range x.x.x.x range to snat to y.y.y.y set interfaces ae1 unit 0 family inet service input service-set CGNAT set interfaces ae1 unit 0 family inet service output service-set CGNAT set interfaces ms-3/0/0 unit 0 family inet set applications application-set accept-algs application junos-http set applications application-set accept-algs application junos-ftp set applications application-set accept-algs application junos-tftp set applications application-set accept-algs application junos-telnet set applications application-set accept-algs application junos-sip set services stateful-firewall rule centralolt01-data match-direction input-output set services stateful-firewall rule centralolt01-data term 1 from source-address x.x.x.x/24 set services stateful-firewall rule centralolt01-data term 1 from application-sets accept-algs set services stateful-firewall rule centralolt01-data term 1 then accept set services nat pool napt-pool address y.y.y.y/32 set services nat pool napt-pool port automatic auto set services nat rule nat-rule1 match-direction input set services nat rule nat-rule1 term nat-term1 from source-address x.x.x.x/24 // NAT for the customer side set services nat rule nat-rule1 term nat-term1 from application-sets accept-algs set services nat rule nat-rule1 term nat-term1 then translated source-pool napt-pool set services nat rule nat-rule1 term nat-term1 then translated translation-type napt-44 ___ 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?
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)
thanks,
Martin
On Sat, Jul 9, 2016 at 8:27 PM, Phil Shafer wrote:
> 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
