[j-nsp] Very disappointed with Juniper

Michael Loftis mloftis at wgops.com
Mon Apr 17 18:22:10 EDT 2006



--On April 8, 2006 12:09:56 PM -0500 "W. Kevin Hunt" 
<khunt at huntbrothers.com> wrote:

> Hmm...
> I've been lurking for 3 weeks trying to decide if our next border router
>   should be another Cisco 12k or a Juniper.  We acquired a Juniper M20
> during the acquisition of a defunct carrier's assets, so I'd like to use
> it but I'm not "comfortable" enough with it yet to put it on the border
> and "learn it" while it's there.
>
> I manage 2 - 12012's right now and am somewhat disappointed in the
> feature set available on them.
> I have a few questions regarding Juniper as I've never had the pleasure
> of sitting at the console of one :
>
> 1.) JUNOS seems steeped in BSD, one of my favorite OS's, is it true you
> can run FreeBSD compiled binaries on JUNOS ?

Up to 7.5 -- they went/are going to signed bins.

> 2.) How is "controller redundancy" handled on the Juniper platform?

Ahh, I'll leave that to others as I'm not 100% clear.  The Juni has an RE 
(Routing Engine), one or more FEBs or CFEBs(M7i, M10i) (either in a load 
sharing or redundant config).

>
> 3.) Anyone here had to deal with 6-8 mpps ddos attacks on a Juniper, and
>   if so, was the juniper cli responsive during the attacks, and what
> mitigation abilities did the Juniper give you?  I'm accustomed to just
> plain ios acl's for mitigation which is tough when there are 8-9 hundred
> sources.

Yes.  It works fine.  Because there's a REAL CONTROL PLANE.  Unlike Cisco. 
One of my three main filters for all inbound and outbound traffic is 800 
lines by itself.  I've others of something like 200-500 each, probably 2k 
entries total.  'ACLs' (prefix-lists, or firewall rules in juniland) are 
done in hardware when applied as a filter.  There's almost no practical 
limit.  There are individuals who've reduced an entire 165k BGP table to 
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.

You still have to have a clear pipe to the Routing Engine (control plane) 
either IB or OOB, but even if it's being directly attacked all incoming 
traffic can easily be rate limited, and in fact is by default, in the 
hardware at the packet forwarding plane.  You can go take a look at the 
Secure JunOS template at Cymru 
http://www.cymru.com/gillsr/documents/junos-template.pdf -- any filter 
applied to lo0 applies to the whole RE, but is done *in hardware*.

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 
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.

> 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.




More information about the juniper-nsp mailing list