Discussion:
[j-nsp] SNMP Ifindex persist
Farhan Jaffer
17 years ago
Permalink
Is there any equivalent command of IOS '*snmp-server ifindex persist*' in
JUNOS? OR any other alternate way to perform the same function?

Thanks & Regards
-FJ
Stacy W. Smith
17 years ago
Permalink
The equivalent functionality is enabled by default in JUNOS, and I'm
unaware of any way to turn it off.

--Stacy
Post by Farhan Jaffer
Is there any equivalent command of IOS '*snmp-server ifindex
persist*' in
JUNOS? OR any other alternate way to perform the same function?
Thanks & Regards
-FJ
Farhan Jaffer
17 years ago
Permalink
I don't think so. When my M40e rebooted, all if indexes changed.

-FJ
Post by Stacy W. Smith
The equivalent functionality is enabled by default in JUNOS, and I'm
unaware of any way to turn it off.
--Stacy
Post by Farhan Jaffer
Is there any equivalent command of IOS '*snmp-server ifindex
persist*' in
JUNOS? OR any other alternate way to perform the same function?
Thanks & Regards
-FJ
Jared Gull
17 years ago
Permalink
Farhan,

That's not typical. Generally speaking the snmp
ifindex information remains the same between reboots
and upgrades. I have seen rare situations where they
have changed (e.g. upgrading between certain versions)
but those situations are the exception and not the
norm.

Jared
...
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Stacy W. Smith
17 years ago
Permalink
Farhan,

You might be able to help pinpoint the issue by executing 'file show /
var/db/dcd.snmp_ix'.

/var/db/dcd.snp_ix is the file where SNMP ifindex information is
stored. The file is in a relatively human readable format and has a
comment at the top indicating the last time it was written.

As Jared said, the most likely culprit would be related to some
software upgrades.

lab at Denver> file show /var/db/dcd.snmp_ix
/*
* dcd-generated /var/db/dcd.snmp_ix
* Version: DCD release 8.4R2.4 built by builder on 2007-12-08
07:16:16 UTC
* Written: Wed Dec 26 22:58:12 2007
*/
<snip>

This probably goes without saying , but don't try to edit this file
directly.

--Stacy
...
Ying Zhang
17 years ago
Permalink
we have a M120 with dual REs. I noticed error messages on the log file

On the Master RE:
Jan 9 10:02:22 XX/kernel: pfe_listener_disconnect: conn dropped: listener
idx=4, tnpaddr=0x5, reason: none
Jan 9 10:02:53 XX/kernel: pfe_listener_disconnect: conn dropped: listener
idx=4, tnpaddr=0x5, reason: none
Jan 9 10:04:57 XX last message repeated 4 times
Jan 9 10:14:47 XX last message repeated 19 times
Jan 9 10:24:37 XX last message repeated 19 times
Jan 9 10:34:58 XX last message repeated 20 times


On the backkup RE
Jan 9 09:05:57 XX ksyncd[4123]: Not runnable attempt 0 reason: hard error
(errors: init_err connection_err)
Jan 9 09:06:28 XX ksyncd[4123]: Not runnable attempt 0 reason: hard error
(errors: init_err connection_err)
Jan 9 09:08:32 XX last message repeated 4 times
Jan 9 09:18:22 XX last message repeated 19 times
Jan 9 09:28:12 XX last message repeated 19 times
Jan 9 09:38:33 XX last message repeated 20 times
Jan 9 09:48:23 XX last message repeated 19 times
Jan 9 09:58:13 XX last message repeated 19 times

I googled it, seems it happens when the two REs running different versions
of software. But my two REs run the same version 8.4R2.4. Any sugguestions?

Thanks in advance.

Ying
/listinfo/juniper-nsp
Richard A Steenbergen
17 years ago
Permalink
Post by Ying Zhang
we have a M120 with dual REs. I noticed error messages on the log file
Jan 9 10:02:22 XX/kernel: pfe_listener_disconnect: conn dropped: listener
idx=4, tnpaddr=0x5, reason: none
Jan 9 10:02:53 XX/kernel: pfe_listener_disconnect: conn dropped: listener
idx=4, tnpaddr=0x5, reason: none
...
Post by Ying Zhang
I googled it, seems it happens when the two REs running different versions
of software. But my two REs run the same version 8.4R2.4. Any sugguestions?
Basically this message just means that the master RE saw the backup RE
disconnecting. TNP is the protocol used for communication between Juniper
PFE components, you can find out what the specific component is by looking
Post by Ying Zhang
grep tnp:5 /etc/tnp.hosts
tnp:5 re1

As for figuring out WHY, the backup RE itself will probably have a better
idea of what happened to cause the drop. It could be any number of things
really, not just a version mismatch in the inter-RE communication API, so
login to the backup RE and look at the logs there.
--
Richard A Steenbergen <ras at e-gerbil.net> http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Farhan Jaffer
17 years ago
Permalink
Yes. You are right. In my experience with Juniper routers, it was the first
time last week when the snmp if index changes after reboot.

Thanks for comments.

-FJ
...
Loading...