Now, I'm not sure about you, but I have been a ScreenOS firewall CLI engineer for a few years, and always loved that you can do most commands in one liner. Then I started working with JunOS, and was irritated that you had to either type very long or multiple command expressions, or go into different hierarchies to make changes.
But after maybe 3-4 months, while moving back and forth between ScreenOS and JunOS, it became more clear, that the programmers of JunOS, actually put some thought in it.
In ScreenOS you lack the good overview of the configuration unless you want to look at the set/unset commands in the actual config. in JunOS you get a fairly good overview thanks to its hierarchy view.
Together with groups and routing instances, the JunOS is quite powerful.
Though, I can still admit, that working with JunOS devices as a Firewall sucks. This is due to the WebGUI of JunOS is bad compared to ScreenOS. But if you work mostly with routing and policy statements, JunOS is the King.
I'm not going to go into details of how to configure different examples, but if you have any specific issue, don;t hesitate to comment or email me.
What I want to share with you, the most powerful commands that speaks for JunOS is the following,
[edit] show | compare --- shows you the difference between candidate configuration and running configuration.
[edit] commit check --- verifies your candidate confing with running config to ensure there is nothing missing to get an IPSEC up, security zone interface missing etc.
[edit] commit confirmed <min>(default 10 min) --- this is the best command ever, this will commit the changes, and if you for some reason loose connection to the device, or something gets completely screwed up, the config will revert to the previous config. You can compare this with "Set timer", but you wont have to set, and then cancel in case you succeed with your config.
In ScreenOS and Cisco, when you punch a command, it takes affect directly, JunOS does not. You will work in a Candidate configuration, that you can choose to commit later, or at a certain time.
And if you are even more sure, with tested config change, you can upload a piece of configuration with SCP(SSH file transfer), and then merge the config with existing with the help of scripts. Say for example you have a new SNMP settings, but dont want to manually go into each one, and you dont have JunOS Space(Juniper mgmt software for JunOS devices). Then you can create the SNMP config in your lab router, save that portion as a file, then script to SCP it over with "commit confirmed 1 min", with expected results of "Commit succeeded", then commit again, and your done. you can push out new config to 100 devices with 1 script.
Have fun!
But after maybe 3-4 months, while moving back and forth between ScreenOS and JunOS, it became more clear, that the programmers of JunOS, actually put some thought in it.
In ScreenOS you lack the good overview of the configuration unless you want to look at the set/unset commands in the actual config. in JunOS you get a fairly good overview thanks to its hierarchy view.
Together with groups and routing instances, the JunOS is quite powerful.
Though, I can still admit, that working with JunOS devices as a Firewall sucks. This is due to the WebGUI of JunOS is bad compared to ScreenOS. But if you work mostly with routing and policy statements, JunOS is the King.
I'm not going to go into details of how to configure different examples, but if you have any specific issue, don;t hesitate to comment or email me.
What I want to share with you, the most powerful commands that speaks for JunOS is the following,
[edit] show | compare --- shows you the difference between candidate configuration and running configuration.
[edit] commit check --- verifies your candidate confing with running config to ensure there is nothing missing to get an IPSEC up, security zone interface missing etc.
[edit] commit confirmed <min>(default 10 min) --- this is the best command ever, this will commit the changes, and if you for some reason loose connection to the device, or something gets completely screwed up, the config will revert to the previous config. You can compare this with "Set timer", but you wont have to set, and then cancel in case you succeed with your config.
In ScreenOS and Cisco, when you punch a command, it takes affect directly, JunOS does not. You will work in a Candidate configuration, that you can choose to commit later, or at a certain time.
And if you are even more sure, with tested config change, you can upload a piece of configuration with SCP(SSH file transfer), and then merge the config with existing with the help of scripts. Say for example you have a new SNMP settings, but dont want to manually go into each one, and you dont have JunOS Space(Juniper mgmt software for JunOS devices). Then you can create the SNMP config in your lab router, save that portion as a file, then script to SCP it over with "commit confirmed 1 min", with expected results of "Commit succeeded", then commit again, and your done. you can push out new config to 100 devices with 1 script.
Have fun!