[j-nsp] Very disappointed with Juniper

[Saku Ytti]

On (2006-04-17 16:22 -0600), Michael Loftis wrote:

> Yes.  It works fine.  Because there's a REAL CONTROL PLANE.  Unlike Cisco. 

 I'm not sure which Cisco you're talking about. But this is rather
harsh simplification of the problematics when comparing the two
vendors, it's not really that easy. You can pick Cisco that will do 
what Juniper will not do (eg RFC3682 in hardware). And of course
it's easy vice versa to pick up GSR with IOS and say 'it sucks,
as it doesn't do control-plane protection in hardware'.
 As we've all seen from various test raports, when you know 
enought of the platform you're testing, you can make it look
bad.

 But yes, generally in real-life JNPR out-performans on avarage
the deployed Cisco's. I'd mainly say thats due to people are
running rather old Cisco gear, and JNPR doesn't have that much history,
so random JNPR you're end up working with will most probably be more
powerful work horse, giving the feeling that JNPR is superior box.

> firewall terms.  There isn't really a concept of a 'software switched' 
> packet in JunOS.  Everything is done "in hardware" (actually micro engines 
> or FPGA in some cases) either on the PICs, or FEBs, or ASM.

 There is exception CPU, just like GSR has LC CPU.

> http://www.cymru.com/gillsr/documents/junos-template.pdf -- any filter 
> applied to lo0 applies to the whole RE, but is done *in hardware*.

 CoPP (control plane policing) as cisco likes to call it, is done
in hardware in newer gear. Such as SUP720, GSR or CRS-1 with IOS-XR.
GSR with IOS will do it in LC CPU, because it has to support CoPP
in line cards that do not have forwarding asics at all, which IOS-XR
will not  do.

> General packet flow in a Juniper M series is documented at juniper 
> clue....can't remember URL right now but I'm sure someone will.  Thing of 
> any M series as a really fully distributed 7k or 12k ish chassis.  Packets 

 'M series' is really not appropriate here, they're not all fully
distributed. But yeah I guess if you'd have to compare M to some 
cisco architecture 12k would be closest.

> can't get punted to the RE unless they're destined for the RE...OK well 
> that's not 100% true, 99%, but they're rate limited to such an extent that 
> you won't experience performance issues.  Also the REs are generally a LOT 
> faster than the CPUs in the Cisco gear, and, they're ONLY there to handle 
> control plane.  Heck, an RE can go deadlock and the FEBs will keep routing 
> packets.  You lose all your control plane though in a situation like that.

 And this is one of my major griefs in Juniper, when control-plane
fails, it keeps on either blackholing or forwarding traffic to 
wrong (unupdated) destinations. Effectively even if I engineer
network to survive failure, I can't route around the problem
always. Think of GSR running out of memory in LC without 'external overload
signalling' configured. Very undesired for me. Much harder to troubleshoot
box that is 'sort of working', but you never know which prefix is going
where, and why. At least thats my experience of troubleshooting
JNPR with low memory condition compared to GSR. 
 My second worst grief is the 20 USD HDD's, that are not specced to 24/7
failing, and for some reason can bring whole RE down, but may or may
not keep forwarfing up (you really want forwarding down, when control
is down)
 And lack of innivation and progress in JNPR routing portfolio scares me,
it was really kick-ass innovation in 1999, but I haven't seen anything
much change since that. I'd really love to see 7600ish box with JunOS
CLI, without the few oddities I've mentioned, and IPII updated
for multiple lookups, GTSM, etc. 

> > 4.) What are the support and upgrade options on equipment that one did
> > not purchase "new".  i.e. we acquired this M40, it seems to have JUNOS
> > 4.1 on it.  What kind of expense am I looking at to get the latest JUNOS
> > on it and basic telephone support for it?
> 
> There won't be any unsual upgrade costs, a support license includes 
> software.

 Expect IPv6 feature license, license per ASM/AS-PIC feature (one
included in price). So Firewall/NAT/NetFlow are all separately 
billed features in it.


 Having said that. JNPR is good box, there is reason why we have both
in our network. Personally I belive JNPR's biggest assest is not the
hardware, reliability, predictability but it's the CLI with policy-language
and all, that's in my opinion where Cisco has most catching up to do.
 Hopefully they will back-port policy language from IOS-XR to IOS.

-- 
  ++ytti