Skip to main content

Useful Commands

Notes for Juniper EX4200 JunOS 10.1

Showing the config in "set" commands rather than brace-format

root@sa4-38# show | display set

Showing the difference between the running and uncommitted config:

root@sa4-39# show | compare

Discard uncommitted changes:

root@sa4-39# rollback 0

Switch control

When you ssh to a switch, you get a shell prompt on the firmware that is running a BSD variant. This is not the JunOS interface.

To get a JunOS interface:

root@single:RE:0% cli
{master:0}
root@single>

Virtual Chassis

(we call this "stack" internally.)

When you use the web interface, or ssh/telnet interface, you are connected to the global management interface. This is managed by the master of the Virtual Chassis. It identifies itself to you in the shell prompt:

root@stack:RE:3%

In this example, you are logged in as root to the virtual chassis which is named stack, connected to member switch 3.

  • RE means it is the master for the Virtual Chassis
  • BK means it is the backup master
  • LC means it is just a member switch (a Line Card)

Communicating directly with individual members

Most of the time you shouldn't need to interact with individual members of the Virtual Chassis. But if you do:

root@stack:RE:3% cli
{master:3}
root@stack> request session member 1

--- JUNOS 10.1R1.8 built 2010-02-12 17:24:20 UTC
root@stack:LC:1%

This gives you an OS-level shell on the member switch (in this case, member switch #1).

pfed_event_trace.log

With 10.1 there is a known issue with the /var/log/pfed_event_trace.log. This log eventually fills up the flash that is on the switch.

root@stack:BK:0% ls -l pf*
-rw-r--r--  1 root  wheel  124092367 Mar  8 12:55 pfed_event_trace.log
-rw-r--r--  1 root  wheel          0 Feb 12  2010 pfed_trace.log

The problem with this is when you go to commit a configuration change to the stack, it first tries to save a backup copy of the existing config for rollback purposes. And if the flash is full, the backup copy fails, and the commit attempt is aborted.

If you are trying to commit a configuration change to a virtual chassis, if any single member fails this commit process, the entire commit is aborted, and the switch rolls back the configuration to the pre-commit state.

So this is good (ie the failure mode is safe). The problem is, how do you find which switch is failing, and then correct the problem?

Back to top