[j-nsp] SLAX script, redefining variables
Hi all. It seems that older SLAX implementations dont have the ability to redefine variable (Juniper is calling them immutable variables). This is apparently fixed in 1.1 on JunOS12+ boxes with something called a mutable variable (defined with mvar instead of var) but all of the boxes I am using are not on JunOS12+ yet. Has anyone found a way to collect a whole bunch of information, and then display it at the end of the script, rather than duplicating their output code 50 times to handle the various exceptions? e.g. a script I am writing grabs the tx/rx figures for optics and lists them, along with the description of the interface, so I can run my op script and get a list of power levels, grep for destination devices etc and see whats happening with my circuits. But there are a couple of exceptions that I hit along the way: 1) Descriptions arent always on the physical interface, so if theres no description there I need to look at a logical interface, which is usually unit 0 in my case 2) SONET interfaces dont use the same variable to store the rx power figure as ethernet interfaces, so depending on the interface type I need to look at a different variable for the rx power figure To handle these exceptions would be quite easy if I could simply use a bunch of IF blocks to test for the various locations of the information I want, set them in to variables, and then at the end dump it out to the screen. But without being able to redefine a variable, and with variables defined inside an IF block not being accessible outside of that IF block, I will need to reproduce my output code numerous times. Anyone know of a solution? Thanks Tom ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SLAX script, redefining variables
On 07/06/13 09:54, Tom Storey wrote: But without being able to redefine a variable, and with variables defined inside an IF block not being accessible outside of that IF block, I will need to reproduce my output code numerous times. Move the output code to a function? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SLAX script, redefining variables
The checks can be embedded into if/for-each constructs, see example here
https://code.google.com/p/junoscriptorium/source/browse/trunk/library/public/op/display/op-show-lsp-interface/op-show-lsp-interface.slax
if ($ifdescrdb/logical-interface[name == $if]/description) {
The above means that only IFLs whose name XML tag matches a string stored
in variable $if will be processed.
HTH
Thanks
Alex
- Original Message -
From: Tom Storey t...@snnap.net
To: juniper-nsp@puck.nether.net
Sent: Friday, June 07, 2013 9:54 AM
Subject: [j-nsp] SLAX script, redefining variables
Hi all.
It seems that older SLAX implementations dont have the ability to redefine
variable (Juniper is calling them immutable variables). This is apparently
fixed in 1.1 on JunOS12+ boxes with something called a mutable variable
(defined with mvar instead of var) but all of the boxes I am using are not
on JunOS12+ yet.
Has anyone found a way to collect a whole bunch of information, and then
display it at the end of the script, rather than duplicating their output
code 50 times to handle the various exceptions?
e.g. a script I am writing grabs the tx/rx figures for optics and lists
them, along with the description of the interface, so I can run my op
script and get a list of power levels, grep for destination devices etc
and
see whats happening with my circuits.
But there are a couple of exceptions that I hit along the way:
1) Descriptions arent always on the physical interface, so if theres no
description there I need to look at a logical interface, which is usually
unit 0 in my case
2) SONET interfaces dont use the same variable to store the rx power
figure as ethernet interfaces, so depending on the interface type I need
to
look at a different variable for the rx power figure
To handle these exceptions would be quite easy if I could simply use a
bunch of IF blocks to test for the various locations of the information I
want, set them in to variables, and then at the end dump it out to the
screen.
But without being able to redefine a variable, and with variables defined
inside an IF block not being accessible outside of that IF block, I will
need to reproduce my output code numerous times.
Anyone know of a solution?
Thanks
Tom
___
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 script, redefining variables
Duh. Thats what happens when you spend all night coding, you forget silly little things. :-P Theres still some duplication of the function call, but I guess thats better than nothing. Would much prefer to do a bulk collection and then a dump at the end. I'll take this route for the time being. On 7 June 2013 11:43, Phil Mayers p.may...@imperial.ac.uk wrote: On 07/06/13 09:54, Tom Storey wrote: But without being able to redefine a variable, and with variables defined inside an IF block not being accessible outside of that IF block, I will need to reproduce my output code numerous times. Move the output code to a function? __**_ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/**mailman/listinfo/juniper-nsphttps://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 script, redefining variables
Tom Storey writes:
It seems that older SLAX implementations dont have the ability to redefine
variable (Juniper is calling them immutable variables).
Not my term; it's a limited of XSLT, on which SLAX is based.
Some details (and implementation notes on the new mvars) can
be found here:
http://code.google.com/p/libslax/wiki/ImmutableVariables
This is apparently
fixed in 1.1 on JunOS12+ boxes with something called a mutable variable
(defined with mvar instead of var) but all of the boxes I am using are not
on JunOS12+ yet.
SLAX-1.1 is in 12.2. You can also get it (for offline use) from
libslax.googlecode.com and juise.googlecode.com. libslax is the
base language. juise adds JUNOS-specific bits like the jcs:*
functions.
[Yes, we're in the process of moving to github, but not done yet]
Has anyone found a way to collect a whole bunch of information, and then
display it at the end of the script, rather than duplicating their output
code 50 times to handle the various exceptions?
I'm not quite following; can you share your script?
e.g. a script I am writing grabs the tx/rx figures for optics and lists
them, along with the description of the interface, so I can run my op
script and get a list of power levels, grep for destination devices etc and
see whats happening with my circuits.
But there are a couple of exceptions that I hit along the way:
1) Descriptions arent always on the physical interface, so if theres no
description there I need to look at a logical interface, which is usually
unit 0 in my case
You can put logic inside the var, like:
var $desc = {
if (description) {
expr description;
} else if (../description) {
expr ../description;
} else {
expr --;
}
}
For this specific case, there's the jcs:first-of() function to
shorten this:
var $desc = jcs:first-of(description, ../description, --);
where jcs:first-of returns the first non-null argument.
But you can use this like:
var $links := {
for-each (link) {
link {
name name;
description jcs:first-of(description, ../description, --);
/* ... */
}
}
}
to build custom data structures.
Also there's always the original model from XSLT of apply-templates
and recursive traversal:
http://my.safaribooksonline.com/book/xml/0596003722/selecting-and-traversing/xsltckbk-chp-4-sect-7
2) SONET interfaces dont use the same variable to store the rx power
figure as ethernet interfaces, so depending on the interface type I need to
look at a different variable for the rx power figure
var $power = {
if (type == aa) {
expr where/ever/it/is/stored;
} else if (type == bb) {
expr some/where/else;
} else {
expr -;
}
}
Hope this helps..
Thanks,
Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] What is this ethernet switching trace telling us?
We're trying to troubleshoot an odd issue and this log output makes it appear that a MAC address is flipping between interfaces. There are other interfaces involved later in the logs. I'm starting to think this isn't telling us what we think it's telling us. Does this indicate that the MAC address really is being learned from multiple interfaces? The confusing thing about the logs is the mention of l3nh. Is that layer three next hop? If so, why are we seeing that in ethernet-level trace options and what is the significance? I'm a little confused. Here is an example: Jun 4 13:07:22.953201 Attempt to add vlan sbc-core mac 00:08:25:fa:3c:82, ifname ge-0/0/6.0, pnac_status 0, 0 Jun 4 13:07:22.953312 vlan sbc-core mac 00:08:25:fa:3c:82 (tag 40), iif = ge-0/0/6.0: present in FDB Jun 4 13:07:22.953374 (3, 00:08:25:fa:3c:82) next-hop index change [1344 - 1328] Jun 4 13:07:22.953562 KRT enqueue FDB (3, 00:08:25:fa:3c:82) nh-index 1328 Jun 4 13:07:22.953712 krt_dequeue: type FDB op change 3, 00:08:25:fa:3c:82 Direct nh 1328 Jun 4 13:07:22.954372 l3nh_fdb_notify: FDB CHANGE vlan sbc-core mac 00:08:25:fa:3c:82 Jun 4 13:21:18.041160 Attempt to add vlan sbc-core mac 00:08:25:fa:3c:82, ifname ge-0/0/5.0, pnac_status 0, 0 Jun 4 13:21:18.041271 vlan sbc-core mac 00:08:25:fa:3c:82 (tag 40), iif = ge-0/0/5.0: present in FDB Jun 4 13:21:18.041332 (3, 00:08:25:fa:3c:82) next-hop index change [1328 - 1327] Jun 4 13:21:18.041670 Attempt to add vlan sbc-core mac 00:08:25:fa:3c:82, ifname ge-0/0/6.0, pnac_status 0, 0 Jun 4 13:21:18.041767 vlan sbc-core mac 00:08:25:fa:3c:82 (tag 40), iif = ge-0/0/6.0: present in FDB Jun 4 13:21:18.041807 (3, 00:08:25:fa:3c:82) next-hop index change [1327 - 1328] Jun 4 13:21:18.041962 KRT enqueue FDB (3, 00:08:25:fa:3c:82) nh-index 1328 It looks to me like the MAC address is jumping around. What do you think? Thanks, John ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] What is this ethernet switching trace telling us?
Are you running spanning tree ? Sent from my iPhone On Jun 7, 2013, at 18:37, Gavin Henry ghe...@suretec.co.uk wrote: Is this a server connected via two ports? Sent from my iPad 2 On 7 Jun 2013, at 23:12, John Neiberger jneiber...@gmail.com wrote: Also, another interesting thing about this is that the output of show ethernet mac-learning-log stops at April 13th. I have no idea why. If a MAC address were jumping around, we'd see it in the MAC learning log...if it were up to date. What would cause a Juniper switch to stop logging to the MAC learning log? By the way, this is an EX4200 running 10.4R6.5. On Fri, Jun 7, 2013 at 4:07 PM, John Neiberger jneiber...@gmail.com wrote: We're trying to troubleshoot an odd issue and this log output makes it appear that a MAC address is flipping between interfaces. There are other interfaces involved later in the logs. I'm starting to think this isn't telling us what we think it's telling us. Does this indicate that the MAC address really is being learned from multiple interfaces? The confusing thing about the logs is the mention of l3nh. Is that layer three next hop? If so, why are we seeing that in ethernet-level trace options and what is the significance? I'm a little confused. Here is an example: Jun 4 13:07:22.953201 Attempt to add vlan sbc-core mac 00:08:25:fa:3c:82, ifname ge-0/0/6.0, pnac_status 0, 0 Jun 4 13:07:22.953312 vlan sbc-core mac 00:08:25:fa:3c:82 (tag 40), iif = ge-0/0/6.0: present in FDB Jun 4 13:07:22.953374 (3, 00:08:25:fa:3c:82) next-hop index change [1344 - 1328] Jun 4 13:07:22.953562 KRT enqueue FDB (3, 00:08:25:fa:3c:82) nh-index 1328 Jun 4 13:07:22.953712 krt_dequeue: type FDB op change 3, 00:08:25:fa:3c:82 Direct nh 1328 Jun 4 13:07:22.954372 l3nh_fdb_notify: FDB CHANGE vlan sbc-core mac 00:08:25:fa:3c:82 Jun 4 13:21:18.041160 Attempt to add vlan sbc-core mac 00:08:25:fa:3c:82, ifname ge-0/0/5.0, pnac_status 0, 0 Jun 4 13:21:18.041271 vlan sbc-core mac 00:08:25:fa:3c:82 (tag 40), iif = ge-0/0/5.0: present in FDB Jun 4 13:21:18.041332 (3, 00:08:25:fa:3c:82) next-hop index change [1328 - 1327] Jun 4 13:21:18.041670 Attempt to add vlan sbc-core mac 00:08:25:fa:3c:82, ifname ge-0/0/6.0, pnac_status 0, 0 Jun 4 13:21:18.041767 vlan sbc-core mac 00:08:25:fa:3c:82 (tag 40), iif = ge-0/0/6.0: present in FDB Jun 4 13:21:18.041807 (3, 00:08:25:fa:3c:82) next-hop index change [1327 - 1328] Jun 4 13:21:18.041962 KRT enqueue FDB (3, 00:08:25:fa:3c:82) nh-index 1328 It looks to me like the MAC address is jumping around. What do you think? Thanks, John ___ 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] What is this ethernet switching trace telling us?
I just checked and we do not have spanning tree enabled on this switch or its partner. We have two switches with a 10-gig link between them. Each switch is connected to a different upstream router. The device in question is a session border controller for VoIP. It is a chassis with multiple four-port NICs that are in redundant pairs. Two four-port cards connect to one switch and the other two connect to the second switch. The cards use virtual IPs and MAC addresses. If a failover is required, an entire four-port card fails to the card connected to the other switch. At that point the NIC is supposed to send gratuitous ARPs to repopulate the MAC address table with the correct location. Based on the ethernet switching trace logs, it looks to us like the virtual MAC addresses on those NICs are regularly jumping around between interfaces, which is definitely not supposed to be happening. We're now stuck in a battle between Juniper and the SBC vendor over whose equipment is misbehaving. I wanted to make sure we were correctly interpreting those trace logs. I'm also still curious about why the MAC learning log is not updating. There hasn't been a new entry in the log in nearly two months, which just can't be true. Thanks! John On Fri, Jun 7, 2013 at 5:05 PM, Harold 'Buz' Dale buz.d...@usg.edu wrote: Are you running spanning tree ? Sent from my iPhone On Jun 7, 2013, at 18:37, Gavin Henry ghe...@suretec.co.uk wrote: Is this a server connected via two ports? Sent from my iPad 2 On 7 Jun 2013, at 23:12, John Neiberger jneiber...@gmail.com wrote: Also, another interesting thing about this is that the output of show ethernet mac-learning-log stops at April 13th. I have no idea why. If a MAC address were jumping around, we'd see it in the MAC learning log...if it were up to date. What would cause a Juniper switch to stop logging to the MAC learning log? By the way, this is an EX4200 running 10.4R6.5. On Fri, Jun 7, 2013 at 4:07 PM, John Neiberger jneiber...@gmail.com wrote: We're trying to troubleshoot an odd issue and this log output makes it appear that a MAC address is flipping between interfaces. There are other interfaces involved later in the logs. I'm starting to think this isn't telling us what we think it's telling us. Does this indicate that the MAC address really is being learned from multiple interfaces? The confusing thing about the logs is the mention of l3nh. Is that layer three next hop? If so, why are we seeing that in ethernet-level trace options and what is the significance? I'm a little confused. Here is an example: Jun 4 13:07:22.953201 Attempt to add vlan sbc-core mac 00:08:25:fa:3c:82, ifname ge-0/0/6.0, pnac_status 0, 0 Jun 4 13:07:22.953312 vlan sbc-core mac 00:08:25:fa:3c:82 (tag 40), iif = ge-0/0/6.0: present in FDB Jun 4 13:07:22.953374 (3, 00:08:25:fa:3c:82) next-hop index change [1344 - 1328] Jun 4 13:07:22.953562 KRT enqueue FDB (3, 00:08:25:fa:3c:82) nh-index 1328 Jun 4 13:07:22.953712 krt_dequeue: type FDB op change 3, 00:08:25:fa:3c:82 Direct nh 1328 Jun 4 13:07:22.954372 l3nh_fdb_notify: FDB CHANGE vlan sbc-core mac 00:08:25:fa:3c:82 Jun 4 13:21:18.041160 Attempt to add vlan sbc-core mac 00:08:25:fa:3c:82, ifname ge-0/0/5.0, pnac_status 0, 0 Jun 4 13:21:18.041271 vlan sbc-core mac 00:08:25:fa:3c:82 (tag 40), iif = ge-0/0/5.0: present in FDB Jun 4 13:21:18.041332 (3, 00:08:25:fa:3c:82) next-hop index change [1328 - 1327] Jun 4 13:21:18.041670 Attempt to add vlan sbc-core mac 00:08:25:fa:3c:82, ifname ge-0/0/6.0, pnac_status 0, 0 Jun 4 13:21:18.041767 vlan sbc-core mac 00:08:25:fa:3c:82 (tag 40), iif = ge-0/0/6.0: present in FDB Jun 4 13:21:18.041807 (3, 00:08:25:fa:3c:82) next-hop index change [1327 - 1328] Jun 4 13:21:18.041962 KRT enqueue FDB (3, 00:08:25:fa:3c:82) nh-index 1328 It looks to me like the MAC address is jumping around. What do you think? Thanks, John ___ 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] What is this ethernet switching trace telling us?
Here is another example of the same type of thing. In this case, a MAC address appears to be jumping from one four-port card to another on the same switch. Port 5 is connected to one NIC, while port 8 is on another four-port NIC and should never, ever use the MAC address we're learning on port 5. Do these logs really indicate that the MAC is being learned on those interfaces, or is it cryptically trying to tell us something else? I don't want to assume. Jun 7 23:21:15.686871 Attempt to add vlan sbc-core mac 00:08:25:fa:3c:91, ifname ge-0/0/8.0, pnac_status 0, 0 Jun 7 23:21:15.686981 vlan sbc-core mac 00:08:25:fa:3c:91 (tag 40), iif = ge-0/0/8.0: present in FDB Jun 7 23:21:15.687048 (3, 00:08:25:fa:3c:91) next-hop index change [1330 - 1329] Jun 7 23:21:15.687172 Attempt to add vlan sbc-core mac 00:08:25:fa:3c:91, ifname ge-0/0/5.0, pnac_status 0, 0 Jun 7 23:21:15.687267 vlan sbc-core mac 00:08:25:fa:3c:91 (tag 40), iif = ge-0/0/5.0: present in FDB Jun 7 23:21:15.687501 (3, 00:08:25:fa:3c:91) next-hop index change [1329 - 1330] Jun 7 23:21:15.687672 KRT enqueue FDB (3, 00:08:25:fa:3c:91) nh-index 1330 Jun 7 23:21:15.687732 l3nh_fdb_notify: FDB CHANGE vlan sbc-core mac 00:08:25:fa:3c:91 Jun 7 23:21:49.269317 Attempt to add vlan sbc-core mac 00:08:25:fa:3c:91, ifname ge-0/0/5.0, pnac_status 0, 0 Jun 7 23:21:49.269427 vlan sbc-core mac 00:08:25:fa:3c:91 (tag 40), iif = ge-0/0/5.0: present in FDB Jun 7 23:21:49.269583 KRT enqueue FDB (3, 00:08:25:fa:3c:91) nh-index 1330 Jun 7 23:21:49.269646 krt_dequeue: type FDB op change 3, 00:08:25:fa:3c:91 Direct nh 1330 Jun 7 23:21:49.270539 l3nh_fdb_notify: FDB CHANGE vlan sbc-core mac 00:08:25:fa:3c:91 Jun 7 23:37:09.776588 Attempt to add vlan sbc-core mac 00:08:25:fa:3c:91, ifname ge-0/0/8.0, pnac_status 0, 0 Jun 7 23:37:09.776953 vlan sbc-core mac 00:08:25:fa:3c:91 (tag 40), iif = ge-0/0/8.0: present in FDB Jun 7 23:37:09.777140 (3, 00:08:25:fa:3c:91) next-hop index change [1330 - 1329] On Fri, Jun 7, 2013 at 6:30 PM, John Neiberger jneiber...@gmail.com wrote: I just checked and we do not have spanning tree enabled on this switch or its partner. We have two switches with a 10-gig link between them. Each switch is connected to a different upstream router. The device in question is a session border controller for VoIP. It is a chassis with multiple four-port NICs that are in redundant pairs. Two four-port cards connect to one switch and the other two connect to the second switch. The cards use virtual IPs and MAC addresses. If a failover is required, an entire four-port card fails to the card connected to the other switch. At that point the NIC is supposed to send gratuitous ARPs to repopulate the MAC address table with the correct location. Based on the ethernet switching trace logs, it looks to us like the virtual MAC addresses on those NICs are regularly jumping around between interfaces, which is definitely not supposed to be happening. We're now stuck in a battle between Juniper and the SBC vendor over whose equipment is misbehaving. I wanted to make sure we were correctly interpreting those trace logs. I'm also still curious about why the MAC learning log is not updating. There hasn't been a new entry in the log in nearly two months, which just can't be true. Thanks! John On Fri, Jun 7, 2013 at 5:05 PM, Harold 'Buz' Dale buz.d...@usg.eduwrote: Are you running spanning tree ? Sent from my iPhone On Jun 7, 2013, at 18:37, Gavin Henry ghe...@suretec.co.uk wrote: Is this a server connected via two ports? Sent from my iPad 2 On 7 Jun 2013, at 23:12, John Neiberger jneiber...@gmail.com wrote: Also, another interesting thing about this is that the output of show ethernet mac-learning-log stops at April 13th. I have no idea why. If a MAC address were jumping around, we'd see it in the MAC learning log...if it were up to date. What would cause a Juniper switch to stop logging to the MAC learning log? By the way, this is an EX4200 running 10.4R6.5. On Fri, Jun 7, 2013 at 4:07 PM, John Neiberger jneiber...@gmail.com wrote: We're trying to troubleshoot an odd issue and this log output makes it appear that a MAC address is flipping between interfaces. There are other interfaces involved later in the logs. I'm starting to think this isn't telling us what we think it's telling us. Does this indicate that the MAC address really is being learned from multiple interfaces? The confusing thing about the logs is the mention of l3nh. Is that layer three next hop? If so, why are we seeing that in ethernet-level trace options and what is the significance? I'm a little confused. Here is an example: Jun 4 13:07:22.953201 Attempt to add vlan sbc-core mac 00:08:25:fa:3c:82, ifname ge-0/0/6.0, pnac_status 0, 0 Jun 4 13:07:22.953312 vlan sbc-core mac 00:08:25:fa:3c:82 (tag 40), iif = ge-0/0/6.0: present in FDB Jun 4 13:07:22.953374 (3,
