Correct, a little review.
The Routing Engine(s) are the control plane, they build the routing table based on all of the information given to it by whatever protocols are configured, and it also builds the forwarding table. The routing engine will then copy it's version of the forwarding table to the appropriate PFE'(s) (forwarding plane).
All in all, the RE has a copy of the routing table and the forwarding table, and all of the PFE's have their respective forwarding entries to be used to actually forward traffic.
show route
- will display the routing table.
show route forwarding-table
- will show the routing engine's version
of the forwarding table
show pfe route ip
- will show the forwarding table/entries that are
actually installed in each PFE.
So this means that in latter case there is no RE<->PFE communication?
Yes, but lets be clear. In the case of show pfe route ip
, the RE still has to communicate with the PFE to query their version of the forwarding table, but it will not query its own copy of the forwarding table.
I'll be happy to update my answer if necessary.
UPDATE: As of 16.1 this is possible with the following configuration:
set system login idle-timeout n
Where n
is the number of minutes.
https://www.juniper.net/documentation/us/en/software/junos/network-mgmt/topics/ref/statement/idle-timeout--edit-system-login.html
For versions of code prior to 16.1, the following answer still works.
Setting idle-timeout for root directly from the CLI is not possible, unfortunately.
I wrote an event script that does what you need.
Basically, every 5 minutes it checks:
- If root is logged in via console (verified by a "-" in the FROM
section of "show system users")
- If root is logged in, has it been
idle for 15 minutes or more (checked in seconds, so 900 seconds).
- If
all of those requirements are met, issue "request system logout
terminal $TERM" (uses whatever terminal is present in the information
the script pulled).
Non-XML version of what is pulled:
jhead@VPN-EP1> show system users
4:02PM up 2:56, 2 users, load averages: 0.07, 0.02, 0.00
USER TTY FROM LOGIN@ IDLE WHAT
root v0 - 3:55PM 6 cli
jhead p0 172.16.67.1 1:09PM - -cli (cli)
You can see a closer representation of what information the script parses by issuing:
show system users | display xml
The Script Itself: (filename: terminate-idle-root.slax
)
/*
* Author : Jordan Head
* Company : Juniper Networks
* Version : 1.0
* Last Modified : December 13, 2015
* Platform : all
*
* Description : This event script periodically checks for root user sessions logged in
* via out-of-band console that have been idle for 15 minutes or more, and terminates the session.
*
*/
version 1.0;
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";
import "../import/junos.xsl";
var $event-definition = {
<event-options> {
<generate-event> {
<name> "5-minute-delay";
<time-interval> "300";
}
<policy> {
<name> "terminate-idle-root";
<events> "5-minute-delay";
<then> {
<event-script> {
<name> "terminate-idle-root.slax";
}
}
}
}
}
match / {
<op-script-results> {
var $root_user = "root";
var $idle_time = "900";
var $from = "-";
var $show-system-users-output = <get-system-users-information>;
var $show-system-users = jcs:invoke($show-system-users-output);
for-each ($show-system-users/uptime-information/user-table/user-entry) {
var $user_check = ./user;
var $idle_time_check = ./idle-time/@junos:seconds;
var $from_check = ./from;
var $tty = ./tty;
if ($user_check == $root_user && $idle_time_check >= $idle_time && $from_check == $from) {
var $terminate_root_console = <command> "request system logout terminal " _ $tty;
expr jcs:invoke($terminate_root_console);
}
}
}
}
Applying the Script:
If the commit is successful, it means that the script's syntax is valid.
jhead@VPN-EP1> configure exclusive
warning: uncommitted changes will be discarded on exit
Entering configuration mode
[edit]
jhead@VPN-EP1# set event-options event-script file terminate-idle-root.slax
[edit]
jhead@VPN-EP1# commit and-quit
commit complete
Exiting configuration mode
Hope this helps, feel free to comment if anything is unclear and I'll be happy to update my answer.
Just a final note: @bob is right, that should work. I've just seen console appliances that maintain a connection, but allow access to the box itself so it wouldn't terminate. If you're doing a typical setup, his solution will work - but I've seen implementations where it wouldn't.
Adjusting Timeout for root Shells:
Just wanted to add one more quick thing someone brought to my attention.
If you're concerned with idle timeout on root user shell sessions (not CLI), you can jump into a shell and set:
set autologout=X ## Where X is the number of minutes of idle time before session is terminated.
You add/edit the file /etc/csh.login
Best Answer
The string shown in the
password
field of user and root accounts in the Junos configuration is not the password encrypted, but a salted MD5 hash of the password.A hash by nature is a one-way function - in other words, there is no functional way to take a hash and convert it back to the original password.
When you log into the box, the password you enter is run through the same hashing algorithm (with the salt for that user account applied) and the results are compared - if they match, then Junos knows that the password you entered must be the same as the one that generated the hash that is stored in the configuration.
Regarding the
secret
permission bit in Junos: this allows you to view sections of the configuration that contain these hashes - if you do not have thesecret
permission bit set, you will not see any of them - it does not show the original passwords.I'm not sure why you need to see the password in plaintext format even if you are backing up configuration?
If you restore a backed up configuration to the box, the hash will remain the same and your password will continue to work.