This small post will be about a little feature called “views”.
This feature is used to create a sort of profile, for which you could have a certain user do certain things. As you might know, the only way to do this previously was to use the priviledge level command. This command would in effect set the command to be available at a certain priviledge level. This can be very cumbersome to maintain, especially if you work in a large enterprise environment or a service provider.
I will use an example of such a scenario to demonstrate the goal of the view feature. First off, a very small topology to ease our life a bit when trying out different commands:
First of, a small config snippet on R1 to allow the telnet from R2:
Check out that it works before we start anything:
Okay, great! we have a working telnet session.
Scenario:
Lets imagine that we work in an enterprise where we have multiple network folks around. Some of them are senior engineers, others are junior engineers. We might have a company policy that states that junior engineers are only allowed to login and view a routers interface status, view the local logging buffer and bounce the interfaces. Nothing else, nothing more.
Back in the day, you would have to create a set of rules governing your policy regarding what priviledge level you wanted certain commands in. Administratively this is a nightmare.
Lets accomplish the above criteria using views!
First of, AAA is required in order to use views, lets enable it:
Secondly, to start off with, you need an enable password:
Then you enable the root view using the enable password:
Now, what we can do is to issue commands to the parser. Lets create a new profile:
So, we created the Junior view. Lets assign a password to enter this new view:
Great. Now lets see what the effect is, if we telnet into R1 from R2:
Oops! Remember that we enabled AAA on R1. This means that we must now have a username/password combination. Lets fix this on R1:
Lets try R2 again 🙂 :
Cool. We are onto the router. Now this is where the views come into play:
Now we are logged into the router, with the view Junior. Lets see what commands are available to us:
Not a whole lot 🙂
Lets add some functionality so the Junior Engineer can actually get some work done:
What this means, is that from the exec level prompt, the command “show interfaces” is allowed.
Lets try again from R2:
Great! that was one of our objectives. Now for the remaining two (show local logging and bounce interfaces):
Next, include the command “show logging” from the exec prompt. Allow us to use the command “configure terminal”, again from the exec prompt. Now from the configure prompt lets be able to use the interface command. This command needs both the “interface” by itself, and also the interface you will allow it to include commands under. At the interface level, we want to include both a shutdown and a no shutdown command.
And now, lets verify it:
Great! thats it. We can now create any username/password combination and tell the Junior engineer to use the view Junior in able to do the tasks at hand.
Please note that this is in my opinion a pretty buggy feature at times. For some commands, you must log out and back in again, and others you dont need to. It seems inconsistent sometimes, so use with care.
Hope that sheds some light on the View feature. Take care!