spidey07, have you ever used gated? If so, the config syntax might look a little familiar.
Basically, you start life with a BSD getty prompt, but logging in with the right username and password runs a shell named "cli" and you'll never have to know there's a BSD underneath. show commands look similar enough to Cisco and there's help including the Cisco-like ? which will get you surprisingly far.
configuration - you type "config" to enter config mode. From there, it's all "edit <foo>" where <foo> is the config nesting statement you want to edit, and it drops you into that config nesting level.
Config syntax is nested. This is like some parts of an IOS config but much more so. So you'll have something like this:
protocols {
ospf {
area 0.0.0.0 {
interface fpx0.0 {
blah;
}
}
}
}
and you can "edit protocols", "edit protocols ospf" etc., and move up/down levels.
Here's the cool part. This alone is worth buying Juniper over Cisco for. You go edit stuff and make changes. Then, once you're done, you run "commit". That's the point where your config changes actually effect state changes in the running system, NOT when you edit one particular line. Who here hasn't been burned badly by gear that has complex configurations where multiple lines of the config interrelate, but the box executes every line when you enter it? Juniper gets this right.
But wait, there's more! You have pretty much a full RCS/CVS underneath storing the config. You can do 'rollback' to revert to the previous version, and you can do things like see the diff and log of the config file - who did what when, it's all kept in the history. No more config changes that break things that nobody admits to having done.
JunOS was built to be more multiprotocol from the start, so get used to having to tell it that you intend a certain bit of configuration bet interpreted as IPv4 (or just IP) config. You might not be used to that.
Otherwise, it's really not hard. The way the config files work is definitely different from everything you've used before, but once you pick it up it's not difficult to work with and the way that JunOS does it is really that much better. The config syntax itself is different, but it's not hard to pick up, there are manuals and examples out there and ?-help will get you far. If you know networking already and can configure something like IOS, you can figure out the JunOS way to do it - same concepts, just a bit different syntax. The JunOS syntax has the advantage of starting from scratch cleanly, while with IOS you have to memorize a lot of quirks (so is that a forward or reverse netmask?).
I have been told by folks at several large ISPs who use a lot of JunOS boxes that the introduction of those boxes and training the staff, while it had to be an organized program and all that, went very smoothly. People who already know IOS can pick it up quickly as long as they're willing to learn, and many folks end up liking JunOS better.
Incidentally, if you've been around in the networking business, you've learned how Cisco are bold liars about performance specifications on your boxes, and how you have to over-engineer your networks to compensate. From what I've seen, Juniper is honest about their specs and you can actually design your network based on them. It makes network design much easier. They have the usual kinds of interfaces you're used to, various speeds of POS and Ethernet and such. The only thing you can't get from Juniper last I checked is any Ethernet L2-switching capability, like the Cisco EtherSwitch modules. They're L3+ boxes only.
If you have specific questions, feel free to ask. It's kinda hard to explain how to use a box in a post.
FYI all, Netscreen products are completely different from JunOS products and as far as I know share no code. Netscreen products have a horrid CLI.
Hardware wise, you get a chassis, power supplies, routing engine (CPU), and usually you use Flexible PIC Concentrator (FPC) line cards into which you stick Physical Interface Card (PIC) modules. I guess theoretically there are line cards that go directly into the slots but in practice it's all PICs. If you're buying today's gear in the M series it's pretty straightforward; there's legacy modules that have wacky limitations. I think the T series and J series are also straightforward but have no experience with them.
The M7i and M10i are a bit wacky in that there's a NP daughtercard (advanced services or something) that is either built-in or it's not and it can't be added later, and it's an expensive added-cost option. So check what features you need and see if you need that. I think it does things like some kinds of firewall/NAT stuff and some kinds of billing stuff, and maybe some IDS kinds of stuff. When I looked into it last it was all stuff I didn't want a core router to do. I believe there's an equivalent card for the bigger boxes that can be added later.
There was a huge gap in performance between the top of the J-series and the M7i. They appear to have newer/faster '50' J-series boxes that might close this gap. This was a big problem for me, because a lot of the needs I have that a Juniper box could fill nicely fall in the range between 100Mb/s and 1000Mb/s of real capacity.
jlazzaro, different models have different storage. I think they stopped putting in hard drives and LS120 drives, could be wrong about that. I think they used something like the M-Systems Disk-On-Chip devices as the boot flash originally, and now they probably use CF. I don't get to touch JunOS boxes currently, too many of my customers are total Cisco zealots (one vendor's sales people wine and dine the executives, and one hardly calls you back. Guess which one gets pushed hard by the executive staff?).
Juniper getting into Verizon was a big deal. I think the MCI/Worldcom/UUNet acquisition smoothed that a bit. With some of VZ's newer offerings like their MPLS services and FIOS, VZ has needs that Cisco doesn't have boxes at all well suited for, and so I think they pretty much had to do it. In general, though, Verizon is a heavily Cisco shop and I believe that is a management/cultural thing.
As far as ISPs in general having Juniper boxes, there was a period where Cisco fumbled badly at the high-end, and while Cisco kept trying to sell expensive routers and line cards that couldn't go much faster, Juniper delivered the performance levels that the carriers wanted. That was a big driver for Juniper. The ISPs who stayed Cisco-only in that time period couldn't scale their backbones, or at least had to do complex engineering and use more boxes of less density. Cisco has improved, but they retain a well deserved reputation for underengineering their products.