[j-nsp] Juniper as a route-server

[Richard A Steenbergen]

On Thu, Dec 05, 2002 at 05:00:53PM -0000, Guy Davies wrote:
> 
> This is kind of using the Juniper as a server rather than a router.  That's
> not really what it was designed for.  It certainly doesn't do BGP the way
> Route servers do (e.g. hiding its AS, setting next-hop to someone else,
> creating views of the routing table based on routing policy).  Route servers
> are a somewhat specialised function which isn't really appropriate for a
> router.

Sorry if I was unclear, I meant a route-server as in a diagnostic box
which has a full iBGP mesh, where anyone can connect to look at your
routing policies and test connectivity (e.g. route-server.exodus.net,
route-server.ip.att.net, route-server.cerf.net, route-server.gblx.net,
etc etc etc).

However, you are right that it is indeed a server and not a router. Yet 
another function which could be better served if Juniper would legitimize 
that little fruit you put in your martini. :)

> How can I put this?  No, no, no, no, no!  There is no way to log into
> the box without an account and this is, without any doubt, a *very* good
> thing. Even if you have an account, if it has no password, then you
> can't get in (unless you've configured an SSH key in which case, the
> relevant user can login with no prompt using ssh).  If you're using a
> script, then you just need to make sure that you force the script to use
> the required user in SSH.

Nonsense, there is nothing wrong with intelligent operators having the 
power to elect a direct login to a specific account without a user or 
password. Crisco can do it, why Juniper would choose to under-power their 
authentication policies is beyond me.

> There's no concept of "enable" in JUNOS.  An account either has
> administrative privileges, or it doesn't.  It's a feature of each account
> based on the class.

Precisely, this creates a lack-of-feature, in that since you can't change 
users or privileges while connected to the CLI (short of going to a shell 
and su'ing, which isn't something I'm prepared to let the world have 
access to), it is much more difficult to run public services box.

> I suspect that quit or exit are default commands that cannot be turned on or
> off.  Since you're kind of screwed if you can logon but can't disconnect or
> can go down the config tree but can't get back up it to the root ;-)

Well, apparently you can turn it off at any rate. It's there if I don't 
deny anything. The documentation covers permissions for "quit" from config 
mode and "quit" from the shell, but not "quit" from the box. I'm guessing 
its an oversight in that noone ever ran it with an explicit allow, deny 
the rest configuration, but if there is something I'm doing wrong feel 
free to point it out. :)

-- 
Richard A Steenbergen <ras@e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)