For When You Can't Have The Real Thing
[ start | index | login ]
start > Juniper > EX4200 > Useful Commands

Useful Commands

Created by dave. Last edited by dave, 6 years and 43 days ago. Viewed 15,397 times. #6
[diff] [history] [edit] [rdf]
labels
attachments
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?

>>http://kb.juniper.net/InfoCenter/index?page=content&id=KB16810

no comments | post comment
This is a collection of techical information, much of it learned the hard way. Consider it a lab book or a /info directory. I doubt much of it will be of use to anyone else.

Useful:


snipsnap.org | Copyright 2000-2002 Matthias L. Jugel and Stephan J. Schmidt