[j-nsp] ASR1002 Comparitive

[Ben Steele]

While I agree with your comment I don't feel it is entirely true, neither us
know where this router is to be placed on the network or its full duties, we
just know it needs enough memory for a couple of full tables and can do up
to 300Mb/s with non-sampled netflow via ethernet interfaces.

Even as a public facing CE, consider the 3 BGP feeds to be 3 100Mb
connections to 3 different ISP's, each delivered via a 100Mb circuit, any
attack > 100Mbs is going to be dropped(tail-drop/rate-limit whatever method
the ISP implements) before it even makes it to the poor software-based
router and given the almost 300Mbs @ 64-byte spec I don't think it would
have a problem with it, usual CoPP applying.

Having said that I don't contest if money isn't so much an issue that a
hardware based solution is always going to be the better option if it
provides the feature set you require, but remember not everyone runs @
line-rate :)

On Wed, Nov 18, 2009 at 6:02 PM, Dobbins, Roland <rdobbins at arbor.net> wrote:

>
> On Nov 18, 2009, at 1:14 PM, Ben Steele wrote:
>
> > I can't see it having a problem with non-sampled netflow but if you are
> really worried about that
> > just ask your local SE when you purchase, is there a specific timer you
> need to run on your netflow to have such an issue with it?
>
> The issue with this software-based router won't be NetFlow; it'll be
> throughput, as you indicated, along with resiliency to attack.
>
> The day of public-facing software-based routers is really over, from an
> availability perspective.
>
> -----------------------------------------------------------------------
> Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
>
>    Injustice is relatively easy to bear; what stings is justice.
>
>                        -- H.L. Mencken
>
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>