Olive up and running :)

Finaly after a few days playing I have Olive running inside of GNS three and able to see other devices

So this is the start of some juniper certs I hope.

I have to say first impressions are not brilliant (has only been about a hour or two of hands on with JunOS), coming from Cisco it all seems a lot of faffing around in and out of the tree structure and not easy to "guess" your way around. I mean to set an ip address on an interface you have to go under the interface under the unit, under the family and then under the ip4 settings. and by having so many branches looking at the configuration is harsh!

I do like the idea of ability to roll back changes, but that in its self adds complexities to working with them.

From what I had hear I was expecting some thing a bit special from it, but I am currently at a loss as to what the hype is about, Don't get me wrong it seems a good solid system, I was jsut expecting some thing a bit more.

Well I will study and get my foundation cert and then maybe I will have had a change of heart.

after all it can't heat to get up to speed on juniper

Find more posts tagged with

Comments

Ryan82

Congrats, and welcome to the dark side. Give it some time and you will be hooked! Honestly I enjoy working on Juniper and Cisco equally.

Good luck!

DevilWAH wrote: »

Finaly after a few days playing I have Olive running inside of GNS three and able to see other devices

So this is the start of some juniper certs I hope.

I have to say first impressions are not brilliant (has only been about a hour or two of hands on with JunOS), coming from Cisco it all seems a lot of faffing around in and out of the tree structure and not easy to "guess" your way around. I mean to set an ip address on an interface you have to go under the interface under the unit, under the family and then under the ip4 settings. and by having so many branches looking at the configuration is harsh!

I do like the idea of ability to roll back changes, but that in its self adds complexities to working with them.

From what I had hear I was expecting some thing a bit special from it, but I am currently at a loss as to what the hype is about, Don't get me wrong it seems a good solid system, I was jsut expecting some thing a bit more.

Well I will study and get my foundation cert and then maybe I will have had a change of heart. after all it can't heat to get up to speed on juniper

networker050184

I felt the same way at first when I started messing with JUNOS. You will get a hold of the hierarchy before long and start to appreciate the flexibility. The best part IMO is the batch updates. You can make all your changes and then commit them at once. No jumping through hoops like on a Cisco to make sure you put every command in the exact order without locking yourself out of the box. Not sure why Cisco won't get this going.

DevilWAH

networker050184 wrote: »

I felt the same way at first when I started messing with JUNOS. You will get a hold of the hierarchy before long and start to appreciate the flexibility. The best part IMO is the batch updates. You can make all your changes and then commit them at once. No jumping through hoops like on a Cisco to make sure you put every command in the exact order without locking yourself out of the box. Not sure why Cisco won't get this going.

But how does this help really, you can still lock you self out of the box if you commit the wrong config, I have a habit on Cisco of running "relaod in xxxmin" before i do any config, same as you can do on the juniper. And i prefer the instance application of cisco, makes trouble shooting faster. this is the bit of juniper that annoys me most lol

lrb

True you can do the reload in xx command but this certainly doesn't help when you have to execute 2 or more commands in the exact order (you can always use tclsh I guess) before you can finish off a change. The best example that springs to mind is changing a VRF on an interface; once you change the VRF it removes the IP address of the interface so you can really easily lock yourself out if your not careful. In this case, reload in xx only gets you back to the pre-VRF change state.

As for navigating the hierarchy, you can always do a show | display set from wherever you are and it will give you the complete command that you would have to run if you were in the top of the hierarchy (i.e. [edit]) which is good if you don't like doing something like:
[edit]
edit interfaces
[edit interfaces]
edit ge-0/0/0.0 family inet
[edit interfaces ge-0/0/0.0 family inet]
set address x.x.x.x/yy

You can always just do:
[edit]
set interfaces ge-0/0/0 unit 0 family inet address x.x.x.x/yy

networker050184 wrote: »

Not sure why Cisco won't get this going.

In IOS-XR they have the ability to do batch updates - pity that we aren't afforded the same luxury with IOS.

zoidberg

It really comes down to personal preference, familiarity, and usability. I will throw out the standard disclaimer that I work for Juniper. However, I don't like Junos because I work for Juniper, I work for Juniper because I liked Junos.

Junos can be different and awkward at the start, but with some time I'm sure it will grow on you.

The configuration model of Junos provides a lot of flexibility and safeguards. I would say Junos can do much better than scheduling a device reload before making changes. Take a look at the "commit confirmed" command if you haven't already. Ideally, if you plan your changes properly, you should never need either feature. But, when things go bad, I would rather have my router automatically rollback my configurations than reload itself. If I killed management access to my box somehow with my change, I don't want to take a service hit while my router reloads when all it needs to do is undo my last couple commands. That's just silly downtime in today's networks.

Making and then committing configuration versus instantaneous configuration changes? No matter how good you are, everyone has had one of those "oh crap!" moments after immediately entering a command. Using commits gives you a safety buffer. A chance to review your changes for any mistakes with a "show | compare" before they go into affect. I don't need a typo or a bad copy/paste disrupting my network.

What about complex changes? I don't want to stress over doing commands in the order of A B C or C A B or B C A because doing them in different orders will have different impacts on the network. When you need to schedule a convergence hit with your customers weeks in advance, they seem to care if that hit ends up being a single 15 second hit or three 10 seconds ones, and you start stressing about how to effectively make a batch of changes all at once.

Does it slow down troubleshooting? Yes? No? I guess it depends on how you troubleshoot. Does it take longer to bounce an interface? Ya, it does. Sometimes commits can take some time and slow you down. But, how many commits do you need to do? A rapid fire burst of configuration changes (try this, commit, try this, commit, try this, commit, try this, commit, try this, commit, etc) is not the best strategy and could introduce more problems. But at least Junos will save the last 50 configurations for you so you can postmortem the problem and later go back and normalize the network.

And like lrb just mentioned, even Cisco is going this way. XR makes you commit.

zoidberg

Anyhoo, with all that said, welcome to the wonderful world of Junos. Hope you enjoy it! There are plenty of people here to help you along the way.

There are so many different network vendors and OS' out there these days that there are always good things and bad things with each of them. Don't take what I say to mean I hate everything not-Junos. I've played with so many different vendors, and I would prolly place IOS next on my list after Junos. Just be glad you're not playing with TiMOS

I don't miss that!