The primary use case of this solution is for the internal network, covering our entire office.
The deployment model we are using is on-premises.
The primary use case of this solution is for the internal network, covering our entire office.
The deployment model we are using is on-premises.
What I like most about this solution is that it is secure.
They need to have more marketing in Egypt.
The technical support in Egypt needs to be improved because I was struggling to get technical support.
Having documentation provided in Arabic would be nice, but not necessary, as most everyone speaks and understands English well enough.
I would like to have customer support on the ground.
This solution is stable.
This solution is scalable.
We have approximately twenty users, most of them are engineers.
It was very difficult to get technical support, here in Egypt.
There is no local support available.
Previously we used Cisco. From my understanding and from what I was told, it was complex, hard to handle, not customer familiar or customer friendly.
The initial setup is straightforward and it's easier than Cisco.
We did not implement this solution through a vendor, we had one of the team members do it. It wasn't that difficult.
I would rate this solution a seven out of ten.
The primary use is as a datacenter, as aggregation and access switches. They are also used in wireless nodes in the core switch segment receiving all last mile services, as in optical fiber.
Juniper supports all our connectivity infrastructure in our datacenter, supporting optimal availability and performance for services.
The Virtual Chassis, because you have a centralized administration of a set of switches which makes the operation more efficient.
Support prices and licensing scheme need to be improved to allow some features to be purchased at lower costs, for example, RPM.
We previously used Cisco.
We evaluated Brocade.
After being primarily a Cisco user for many years, I find the switch to Juniper refreshing. The CLI is intuitive and I appreciate the hierarchy of the various configuration groups to be much more organized. I also think it is better with regard to config checking, and ensuring that the items entered into the config work with the rest of the config. For example if you happen to forget a line in a policy, or make an error in referencing a particular object, it will not let you commit the config. I know there are pros and cons of both configs, but once you get used to Juniper, you can see the benefit of why they organized it the way they did.
Both are decent products. I prefer Juniper for the following reasons:
1) Cleaner separation of data plane from control plane. Higher end Cisco devices are better at this but most of the lower end products still seem to be more integrated than I like.
2) The Hierarchical config design means I can make changes only in areas that concern me without necessarily impacting other areas.
3) Easier rollback when one makes mistakes
4) I think there are less bugs/vulnerabilities in Junos vs IOS.
5) iOS has too many flavors leads to confusion with deployment.
One more advantage of junos over iOS. Juniper adheres closer to the standards than Cisco. Epigraph is nice, auto rp is cool, but with the less protocols in the standards it's much earlier to configure junos.
Either vendor has a switch that will do the job. However I perferer Juniper due to
a. rollback is quick and easy in the event of issues arising from chnages
b. easier fault finding (once you get your head around how its implemented)
c. no need check the switch to find which OS feature set is installed and if memory / flash upgrade is required - its all in the OS with very few licenses (usually none) required to get full functionality if you have select the correct product in the first place
d. Hierarchical config is much easier to follow - great concept that most programmers can pickup quickly
e. don't need to learn different variants of the CLI as is required on IOS (even HP manage to stay relatively consistent there)
f. decent speed stacking interfaces on enterprise grade switches (particular 4x00 series)
g. more function for $ (at retail prices)
h. closer to standards than Cisco - easier interoperability in multi vendor environment
i. does not have legacy protocols that are not used or so rarely used that they don't matter in the day and age
Purchase and implementation of Cisco maintenance process is MUCH simpler to the end customer
Worked on both brands for a number of years.
Overall, the equipment is pretty good and more affordable than some other solutions. I found it to be difficult to make the transition from CISCO to Juniper as far as the CLI goes, maybe thats just me. I also had more than one instance where a switch would just stop working and I would have to reload the firmware on it and reconfigure it to get it back up and running. This caused me to purchase backup devices to minimize downtime and really cut into the cost savings over CISCO.
There's a learning curve for sure but it's definitely a better CLI and it appears Cisco agrees going by the changes in IOS-XR. Once you get your heard round using a tiered structure it just makes more sense. Config tools that JunOS offers like copy, replace and move are really handy if you learn how to use them. These can save you a lot of time. What else...
Commit check / confirm / comment
rollback
traceroute monitor
monitor interface
stacking of pipe "|" commands for example: show interface | match xe | match error
Show configuration | display set
I strongly advise you start looking at and backing up configs using the later format. Sometimes the standard hierarchical display can be easier to read and spot mistakes but for copy and pasting config it's much easier to use the "set" display format. Avoiding using "load merge terminal" will save you headaches IMHO.
Once you learn the power of all the show and config command options start looking at JunOS Scripts - then you'll be blown away.
Also if you have access Juniper offer a IOS to JunOS conversion tool... i2j.juniper.net/release/index.jsp
We use the product in data centers.
The tool's most valuable feature is stability.
Juniper EX Series Ethernet Switches is not cheap. The tool needs improvement in UI.
The tool is very stable.
Juniper EX Series Ethernet Switches' scalability is high.
I rate the tool's deployment a ten out of ten.
I rate Juniper EX Series Ethernet Switches a ten out of ten.

Hi, well to your point about rollbacks, the benefits of this feature are quite obvious in that they provide a fail safe mechanism should your changes inadvertently isolate you from a remote device due to some unforeseen error/mistake (it happens!).
I often hear people compare this age old Junos feature to Cisco's "reload in|at x" command, however if the difference isn't already obvious, that command results is a device reload, whereas Junos rollbacks do not. Picture a scenario whereby your action isolates you from a remote device yet that device is still carrying production traffic loads. In this scenario, the user of rollback would be able to regain access to the device without impact to traffic through the device, whereas the user of the reload command would see an outage. Consider a worst case scenario whereby the device fails to complete its boot cycle and there my friend you have hell on your hands. May as well pack your stuff into a box and grab your coat at that point.