said by cramer:terribly skewed, and in my opinion, incorrect perception.
IME, not entirely... if you're doing things the way Juniper expects, which in 99% of cases would be "normal", the hidden/built-in defaults work. But in those 1% fringe cases, you run into odd things to be changed -- eg. IPSec timers. (try running IPSec between junipers over a sat link!)
if you justify an opinion based on experiences seen 1% of the time -- i can't help you there.
i can say the same for cisco -- if you try to run things other than the way that cisco "expects" you to, then you're stuck trying to find out issues (one needn't look much past copp and hwrl on the c6k for proof of this).
there is a different thought process that goes into the design and configuration of the network. look at the differences that juniper assigns to a/d with respect to bgp as compared to cisco. look at the way that juniper handles marking of packets (egress, by the way) and compare that to how cisco marks (ingress, or egress, depending on code, platform, linecard, etc). neither one is "right" or "wrong" -- its what fits your network and the way that you engineer around things. again -- discounting juniper because of a single experience (or ~1% of experience) is a dogmatic following of vendor ideology and not what should be done in a true "best of breed" network.
i'm not a juniper supporter. i work for a *very* large cisco gold partner. we make a metric $hit-ton of money hocking cisco product. if you look past marketing fluff and cisco-spin -- you'll realize that cisco, juniper, and even other vendors, have a valid place in the network depending on use case and requirements. isn't that why we all have the rfp process, after all?
q.