Mailing List Archive

On 23.10.2019 13:50, Patrick M. Hausen wrote:
> Hi all,
>
> would you recommend the 4461 to run a handful of
> full feeds for v4 and v6? The model seems to be quite
> affordable compared to ASR 9000 series routers and
> throughput is not our main concern for upstream.
I guess it partly depends on the line speed you use. As for BGP, we have
at least one customer where we're running 4431 (with 8GB RAM) with dual
full feed ... works fine for a 500G uplink ...
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

> On 23 Oct 2019, at 13:50, Patrick M. Hausen <hausen@punkt.de> wrote:
>
> Hi all,
>
> would you recommend the 4461 to run a handful of
> full feeds for v4 and v6? The model seems to be quite
> affordable compared to ASR 9000 series routers and
> throughput is not our main concern for upstream.

It will do fine. Memory and performance shouldn’t be an issue until you
reach around 7Gbps (with BOOST license, if you’re not running virtual
containers).

If that’s not enough, consider ASR 1001X/1001HX.

—
./
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Hi all,

> Am 27.10.2019 um 01:36 schrieb ?ukasz Bromirski <lukasz@bromirski.net>:
>
>> On 23 Oct 2019, at 13:50, Patrick M. Hausen <hausen@punkt.de> wrote:
>>
>> Hi all,
>>
>> would you recommend the 4461 to run a handful of
>> full feeds for v4 and v6? The model seems to be quite
>> affordable compared to ASR 9000 series routers and
>> throughput is not our main concern for upstream.
>
> It will do fine. Memory and performance shouldn’t be an issue until you
> reach around 7Gbps (with BOOST license, if you’re not running virtual
> containers).
>
> If that’s not enough, consider ASR 1001X/1001HX.

Our supplier recommended refurbished 9001 or 9006 to get the best
bang for the buck. Would you agree with that?

Could someone kindly clue me in about the 32bit vs 64bit platform
„issue“ if there is one? I would not want to invest into a platform
with EOL already on the horizon. Those 6500 have been running way
too long.

Pointers of course welcome.

Thanks in advance,
Patrick
--
punkt.de GmbH Internet - Dienstleistungen - Beratung
Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100
76133 Karlsruhe info@punkt.de http://punkt.de
AG Mannheim 108285 Gf: Juergen Egeling

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On Mon, 28 Oct 2019 at 10:31, Patrick M. Hausen <hausen@punkt.de> wrote:

> Our supplier recommended refurbished 9001 or 9006 to get the best
> bang for the buck. Would you agree with that?

That'll set you back about the same as new MX204, you need to be
really committed CSCO shop to go with ASR9001. I would not consider
that at all, even if it had to be Cisco.

> Could someone kindly clue me in about the 32bit vs 64bit platform
> „issue“ if there is one? I would not want to invest into a platform
> with EOL already on the horizon. Those 6500 have been running way
> too long.

There will be no new platforms shipping 32b. If I was Cisco, I'd spend
only critical support NRE on it, because I wouldn't want to invest
expensive NRE on platform I'm not actually selling.

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Hi!

> Am 28.10.2019 um 09:40 schrieb Saku Ytti <saku@ytti.fi>:
> That'll set you back about the same as new MX204, you need to be
> really committed CSCO shop to go with ASR9001. I would not consider
> that at all, even if it had to be Cisco.

Thanks for that recommendation.

I’m not allergic to Juniper nor any other vendor, although it is traditional IOS
that I know inside-out. But I do know my basics, so switching product is
not an issue, really.

When I look at Juniper I quickly find this:

https://www.juniper.net/us/en/products-services/routing/mx-series/datasheets/1000597.page

And here - just like Cisco - they feature all sorts of fancy numbers that are
all completely irrelevant to us. The smallest platform in that table features
four times the peak bandwidth we *could* use with our 5x 1G/s connections,
which we are currently utilizing at less than 500 M/s in total ...

Yet the only numbers I am really interested in are:

How many routes will each of these systems hold in the data plane?
And how many full-feed BGP peers can it handle in the control plane?

And these are not in this effing table!

This is frustrating …

Kind regards,
Patrick
--
punkt.de GmbH Internet - Dienstleistungen - Beratung
Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100
76133 Karlsruhe info@punkt.de http://punkt.de
AG Mannheim 108285 Gf: Juergen Egeling

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On Mon, Oct 28, 2019 at 09:30:43AM +0100, Patrick M. Hausen wrote:
>
> Our supplier recommended refurbished 9001 or 9006 to get the best
> bang for the buck. Would you agree with that?
>
> Could someone kindly clue me in about the 32bit vs 64bit platform
> ???issue??? if there is one? I would not want to invest into a platform
> with EOL already on the horizon. Those 6500 have been running way
> too long.

If this is a new deployment, don't bother with 9001, or 9006 with 32-bit kit components.

Both of these are going EOL.

If you need new entry level ASR9K at similar price points as 9001, talk to your account
team about ASR-9901-120G. It's 64-bit and licensed to same capacity as fully loaded
9001 (120 Gbps).

Note however that compared to MX204, ASR9901 takes about double the power footprint, but
does provide different set of port configuration to MX204, which may or may not be useful
to you (24x 10GE + 2x 100GE vs. 8x 10GE + 3x 100GE useable).


9006 makes sense if you are upgrading an existing 32-bit installation to 64-bit compatible
cards, or if 10RU is really the only rack space you have available (and you don't mind the
lack of longevity to support denser line cards). For new deployment, you'd really want
9906, but at this point, you're spending deep. Definitely not 9001 pricing level.

James
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On 28/Oct/19 14:20, Patrick M. Hausen wrote:

>
> Yet the only numbers I am really interested in are:
>
> How many routes will each of these systems hold in the data plane?
> And how many full-feed BGP peers can it handle in the control plane?
>
> And these are not in this effing table!
>
> This is frustrating …

It doesn't immediately strike me that you have spent any time speaking
with Juniper or one of their partners about your needs and what product
in their arsenal comes close to your requirements.

There is nothing wrong with getting advice from this group, but half the
work is speaking with the experts on the product (the manufacturers) and
the other half is the real-world (where this list, and others like it,
come in).

So to be frustrated about what is not published on a web site just
screams to me of finding an excuse not to consider the platform.

Many of us here spend countless hours in vendor labs and EBC's when we
could be out having a nice dinner with our friends and families, so we
can obtain an unbiased and fair view of the kit we want to buy to build
and operate our networks. I'd suggest doing a bit of this legwork before
concluding on whether a vendor is right for you or not.

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Hi,

On Mon, Oct 28, 2019 at 04:42:35PM +0200, Mark Tinka wrote:
> Many of us here spend countless hours in vendor labs and EBC's when we
> could be out having a nice dinner with our friends and families, so we
> can obtain an unbiased and fair view of the kit we want to buy to build
> and operate our networks.

But this should not be an excuse for a vendor not publishing basic
things like "the forwarding hardware on <this generation foo> can
handle 4.13 trillion IPv4 entries, unless you use IPv6, in which case
it goes down to only 22.000".

FIB is fairly easy here.

"How many full table feeds will fit into the RIB" is more complicated
(as it depends on more factors than sheer "number of prefixes" but
also paths, attributes, churn = CPU usage, etc.) - but even there a
rough number is easy to publish.


And, of course, "for this platform, we offer the following 3 different
licenses, which do <this>, <that> and <somethingelse>" - this is particularily
annoying for the MX204, where I have yet to find something on Juniper's
page that explains "if you want to use the MX204 for <X>, you need to
buy <that license>".

gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de

Hi Mark,

> Am 28.10.2019 um 15:42 schrieb Mark Tinka <mark.tinka@seacom.mu>:
> It doesn't immediately strike me that you have spent any time speaking
> with Juniper or one of their partners about your needs and what product
> in their arsenal comes close to your requirements.

Because I wanted an unbiased field tested recommendation.
But you do have a point here - probably that will be my next step.

Kind regards,
Patrick
--
punkt.de GmbH Internet - Dienstleistungen - Beratung
Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100
76133 Karlsruhe info@punkt.de http://punkt.de
AG Mannheim 108285 Gf: Juergen Egeling

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On 28/Oct/19 16:54, Gert Doering wrote:

>
> But this should not be an excuse for a vendor not publishing basic
> things like "the forwarding hardware on <this generation foo> can
> handle 4.13 trillion IPv4 entries, unless you use IPv6, in which case
> it goes down to only 22.000".

I don't disagree, but while Patrick will find RIB/FIB performance
numbers fairly basic and expected, so will someone else about pps, as
will someone else about fan speed, as will another about rack depth, and
someone else about NEBS, and another about port density, and another
about licenses, and another about power, and another about block
diagrams, and and and...

You see where I am going with this.

I always take web site information as an overview. If my interest is
piqued and there isn't enough data online for me to reach a conclusion,
I reach out to the vendor.

Recently, I spent about 5 e-mails getting Cisco to confirm to me that
their new 9300 Catalyst Ethernet switches actually do support
egress/ingress policing. Even if their web site did (ambiguously) state
this, historically, Ethernet switches have usually only done ingress
policing and egress shaping, hence my ardent concern.

If we are trying to avoid speaking to the vendors (something I would
like to do, don't get me wrong), that's unlikely to happen.

Mark.

On 28/Oct/19 16:57, Patrick M. Hausen wrote:

>
> Because I wanted an unbiased field tested recommendation.

And that's great, but as you continue to operate your network, you won't
be able to run away from working with the vendors at some point or
other. Building that experience will quickly teach you how to sniff the
snake oil they try to feed you, so they don't waste your time when you
engage them.

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Hi,

On Mon, Oct 28, 2019 at 05:06:47PM +0200, Mark Tinka wrote:
> On 28/Oct/19 16:54, Gert Doering wrote:
>
> > But this should not be an excuse for a vendor not publishing basic
> > things like "the forwarding hardware on <this generation foo> can
> > handle 4.13 trillion IPv4 entries, unless you use IPv6, in which case
> > it goes down to only 22.000".
>
> I don't disagree, but while Patrick will find RIB/FIB performance
> numbers fairly basic and expected, so will someone else about pps, as
> will someone else about fan speed, as will another about rack depth, and
> someone else about NEBS, and another about port density, and another
> about licenses, and another about power, and another about block
> diagrams, and and and...
>
> You see where I am going with this.

I do, and all these are easy to document for the vendor. Get it right
once, follow the process for every new piece of hardware you bring to
market, win for everyone. There is even cost savings for the vendor
not having to answer the same question from 500 possibly interested
customers... (now, fan speed might not be *that* interesting, but
"noise level" certainly is).

> I always take web site information as an overview. If my interest is
> piqued and there isn't enough data online for me to reach a conclusion,
> I reach out to the vendor.
>
> Recently, I spent about 5 e-mails getting Cisco to confirm to me that
> their new 9300 Catalyst Ethernet switches actually do support
> egress/ingress policing. Even if their web site did (ambiguously) state
> this, historically, Ethernet switches have usually only done ingress
> policing and egress shaping, hence my ardent concern.

Specific hardware<=>feature combinations are certainly something that
need to be clarified individually.

Basic stuff (like "will it do BGP with a full table, will it handle
my throughput rate") shouldn't.

Actually Cisco is fairly good at documenting this (including rack depth,
weight, etc.), though half the answers for XR are hidden in supportforum
posts by Xander...

gert


--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de

On 28/Oct/19 17:11, Gert Doering wrote:


> (now, fan speed might not be *that* interesting, but
> "noise level" certainly is).

You make my point for me :-).

What you find boring, others might find interesting.

Remember the infamous "routerperformance.pdf" document that every
network engineer had to have back in the early 2000's? For the
uninitiated, here is a 2009 version of it:

   
https://community.cisco.com/t5/routing/cisco-router-performance/td-p/2715278?attachment-id=25450

You and I have been in the game long enough asking for this information
to be made available. Some vendors have tried (I dare say, Cisco does it
better than all of them), while others just don't get it. They all leave
a lot to be desired, but if they haven't been able to hack it since the
beginning, unlikely they will be doing that in a world dominated by IoT,
SD-WAN, SDN and Big Data :-).



> Actually Cisco is fairly good at documenting this (including rack depth,
> weight, etc.), though half the answers for XR are hidden in supportforum
> posts by Xander...

For me, Cisco do this best of everyone, agreed. But if they still can't
hack it, know which battles to pick.

There's a reason they give their SE's and AM's plenty of lunch + beer
budgets :-).

Mark.

On Mon, 28 Oct 2019 at 16:55, Gert Doering <gert@greenie.muc.de> wrote:

Hey,

> But this should not be an excuse for a vendor not publishing basic
> things like "the forwarding hardware on <this generation foo> can
> handle 4.13 trillion IPv4 entries, unless you use IPv6, in which case
> it goes down to only 22.000".
>
> FIB is fairly easy here.

In MX for example this is multidimensional answer. Same memory is used
for many things and having less A means you can have more B.

Here is one MX:

IMPC0(r33.labxtx01.us.bb-re1 vty)# show jnh 0 pool
Name MemType Total Used
(%) Free (%)

Next Hop EDMEM 2621440 2001912
76% 619528 24%
Bulk_DMEM 1048576 458976
43% 589600 57%
IDMEM 507904 391633
77% 116271 23%

Firewall EDMEM 2621440 35977
1% 2585463 99%

Counters EDMEM 6815744 3195230
46% 3620514 54%
IDMEM 12288 3798
30% 8490 70%

Services NH Bulk_DMEM 2097152 16397 <
1% 2080755 >99%

LMEM LMEM 128 128
100% 0 0%

HASH EDMEM 3937792 3937792
100% 0 0%
Bulk_DMEM 1675008 1675008
100% 0 0%

ENCAPS Bulk_DMEM 4259840 4259840
100% 0 0%

UEID_SPACE Bulk DMEM 1048576 129 <
1% 1048447 >99%

UEID_SHARED_SPACE Bulk DMEM 65536 2 <
1% 65534 >99%


Now either you test, or you acquire understanding what does EDMEM,
DMEM, IDMEM, LMEM mean and how does it apply to your scenario. And
once you upgrade platform you'll do all that again.

> "How many full table feeds will fit into the RIB" is more complicated
> (as it depends on more factors than sheer "number of prefixes" but
> also paths, attributes, churn = CPU usage, etc.) - but even there a
> rough number is easy to publish.

Perhaps it seems more complicated, because you understand it better.

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

> Saku Ytti
> Sent: Monday, October 28, 2019 3:38 PM
>
> On Mon, 28 Oct 2019 at 16:55, Gert Doering <gert@greenie.muc.de> wrote:
>
> Hey,
>
> > But this should not be an excuse for a vendor not publishing basic
> > things like "the forwarding hardware on <this generation foo> can
> > handle 4.13 trillion IPv4 entries, unless you use IPv6, in which case
> > it goes down to only 22.000".
> >
> > FIB is fairly easy here.
>
> In MX for example this is multidimensional answer. Same memory is used for
> many things and having less A means you can have more B.
>
I agree,
All these scaling and performance numbers you'll get from a vendor are
unidirectional, unless stated otherwise -meaning in pursuit of looking the
best possible in comparison to the competition these numbers were achieved
with the box running nothing else but the feature under test, so depending
on your setup you might get close or nowhere near to the published numbers.
So at the end of the day you still have to test yourself or pay vendor to
test your specific setup for you.
But that said smaller shops may need to rely on the vendor published numbers
and just take them with a grain of salt.
(and yes cisco is much better in publishing these, one can get juniper
numbers only under NDA -go figure).

To the OP's question,
Since you don't need throughput maybe vMX/cRDP or vXR 9000 with just couple
of gig of licenses would be an option?
That way you'll get all the internet proven BGP stack offered by the big
boxes for fraction of the price tailored to your BW needs.
But yes there's the who manages the server part unfortunately...

adam

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Hi!

> Am 29.10.2019 um 10:25 schrieb <adamv0025@netconsultings.com> <adamv0025@netconsultings.com>:
> Since you don't need throughput maybe vMX/cRDP or vXR 9000 with just couple
> of gig of licenses would be an option?
> That way you'll get all the internet proven BGP stack offered by the big
> boxes for fraction of the price tailored to your BW needs.
> But yes there's the who manages the server part unfortunately…

Managing servers is our core business and we are actively investigating
separating layers 2 and 3 again and using something like the BSD
router project for upstream BGP.

Have been running router-on-a-stick for years, the 6500 were our first
integrated platform.

So thanks ;-)
Patrick
--
punkt.de GmbH Internet - Dienstleistungen - Beratung
Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100
76133 Karlsruhe info@punkt.de http://punkt.de
AG Mannheim 108285 Gf: Juergen Egeling

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On Tue, 29 Oct 2019 at 11:25, <adamv0025@netconsultings.com> wrote:

> To the OP's question,
> Since you don't need throughput maybe vMX/cRDP or vXR 9000 with just couple
> of gig of licenses would be an option?
> That way you'll get all the internet proven BGP stack offered by the big
> boxes for fraction of the price tailored to your BW needs.
> But yes there's the who manages the server part unfortunately...

I'm my experience, in most network outfits the OPEX for compute infra
will eat alive the CAPEX delta of real routers. So you get inferior
performance, you eat compute resources and you pay more. As a very
large generalisation, I think these solutions are better for compute
shop doing networking than network shop doing compute.

XEON is very expensive NPU.

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

> From: Saku Ytti <saku@ytti.fi>
> Sent: Tuesday, October 29, 2019 10:07 AM
>
> On Tue, 29 Oct 2019 at 11:25, <adamv0025@netconsultings.com> wrote:
>
> > To the OP's question,
> > Since you don't need throughput maybe vMX/cRDP or vXR 9000 with just
> > couple of gig of licenses would be an option?
> > That way you'll get all the internet proven BGP stack offered by the
> > big boxes for fraction of the price tailored to your BW needs.
> > But yes there's the who manages the server part unfortunately...
>
> I'm my experience, in most network outfits the OPEX for compute infra will
> eat alive the CAPEX delta of real routers. So you get inferior performance,
> you eat compute resources and you pay more. As a very large generalisation,
> I think these solutions are better for compute shop doing networking than
> network shop doing compute.
>
> XEON is very expensive NPU.
>
Sure there's a BW rate above which NPU clearly wins,
But for low BW cases like the on in OP's case it's a no brainer even with massive server (total overkill for 10G) the 10G virtual is 8 times cheaper than the cheapest HW option.
I'm being vague on purpose here cause I think the list prices are under NDA.

adam

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On Tue, 29 Oct 2019 at 13:24, <adamv0025@netconsultings.com> wrote:

> Sure there's a BW rate above which NPU clearly wins,
> But for low BW cases like the on in OP's case it's a no brainer even with massive server (total overkill for 10G) the 10G virtual is 8 times cheaper than the cheapest HW option.
> I'm being vague on purpose here cause I think the list prices are under NDA.

I hear a lot of people buying MX204 for 15k and less, when they buy a
single unit, unsure if loss leader to get people to try JNPR.
Reasonable server like R840 set you back 7k. And then you actually
have to buy the vMX, which will put it around the 10k?
Obviously the Dell will have less ports and completely inferior
performance and in networking shops much higher OPEX.

Considering how cheap CAPEX is, I just don't see it.

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

> From: Saku Ytti <saku@ytti.fi>
> Sent: Tuesday, October 29, 2019 11:41 AM
>
> On Tue, 29 Oct 2019 at 13:24, <adamv0025@netconsultings.com> wrote:
>
> > Sure there's a BW rate above which NPU clearly wins, But for low BW
> > cases like the on in OP's case it's a no brainer even with massive server
> (total overkill for 10G) the 10G virtual is 8 times cheaper than the cheapest
> HW option.
> > I'm being vague on purpose here cause I think the list prices are under
> NDA.
>
> I hear a lot of people buying MX204 for 15k and less, when they buy a single
> unit, unsure if loss leader to get people to try JNPR.
> Reasonable server like R840 set you back 7k. And then you actually have to
> buy the vMX, which will put it around the 10k?
> Obviously the Dell will have less ports and completely inferior performance
> and in networking shops much higher OPEX.
>
> Considering how cheap CAPEX is, I just don't see it.
>
No you're right I wasn't really comparing apples to apples.
I was looking at list prices of fully licensed HW and comparing with base license SW and there's also the different discount rate on SW vs HW that brings both closer together.

But still I reckon one could do 100G with the R840 just fine, whereas OP would be fine with a few 1G ports, so if you tune the server HW for that (i.e. any old server would do)...
So all I'm saying is that sure mx204 vs vMX (both doing 400Gbps) -that's easy win for mx204
But mx204 vs vMX (both doing 4Gbps) -easy win for vMX I'd say

adam

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

James,

> On 28 Oct 2019, at 13:35, James Jun <james@towardex.com> wrote:
>
> If this is a new deployment, don't bother with 9001, or 9006 with 32-bit kit components.
>
> Both of these are going EOL.

There are no such plans for now, and until at least July of 2020.
And yes, I’m with Cisco, this is official.

And please remember EOL is last stage - first, there’s EoS, and you
still can for a year buy the equipment. There’s couple of years (3 to 5)
of support.

In this specific setup, 32-bit OS won’t hurt, as BGP on 9001 and
9006’s RSP is perfectly capable of driving ~2M+ FIB and ~20M RIB
entries (if used with multiple BGP instances, 7M+ for single instance).

> If you need new entry level ASR9K at similar price points as 9001, talk to your account
> team about ASR-9901-120G. It's 64-bit and licensed to same capacity as fully loaded
> 9001 (120 Gbps).

That’s true of course. 9901 would be better entry-level choice with
years in front of it.

--
?ukasz Bromirski
CCIE R&S/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Patrick,

> On 28 Oct 2019, at 09:30, Patrick M. Hausen <hausen@punkt.de> wrote:
>
> Hi all,
>
>> Am 27.10.2019 um 01:36 schrieb ?ukasz Bromirski <lukasz@bromirski.net>:
>>
>>> On 23 Oct 2019, at 13:50, Patrick M. Hausen <hausen@punkt.de> wrote:
>>>
>>> Hi all,
>>>
>>> would you recommend the 4461 to run a handful of
>>> full feeds for v4 and v6? The model seems to be quite
>>> affordable compared to ASR 9000 series routers and
>>> throughput is not our main concern for upstream.
>>
>> It will do fine. Memory and performance shouldn’t be an issue until you
>> reach around 7Gbps (with BOOST license, if you’re not running virtual
>> containers).
>>
>> If that’s not enough, consider ASR 1001X/1001HX.
>
> Our supplier recommended refurbished 9001 or 9006 to get the best
> bang for the buck. Would you agree with that?

It will depend on your requirements. 9001 is small, deep, but powerful,
capable of pushing 120Gbps. ISR 4461 and ASR 1001X/1001HX
can’t match that (1001HX is 60Gbps) and for example can do
VPN crypto which 9001/9901 can’t (if you’re willing at some point in
future to terminate S2S/RA VPNs).

> Could someone kindly clue me in about the 32bit vs 64bit platform
> „issue“ if there is one? I would not want to invest into a platform
> with EOL already on the horizon. Those 6500 have been running way
> too long.

As I already responded to James, 9001 is not going EOL anytime
soon - at least not until June 2020. 32 bit is still an valid option and
will be for years to come - we have hundreds of thousands of systems
deployed with it.

*If* however you want to go for full-scale/future-proof design, either
go with ASR 1k or ASR 9901 (both of which run 64b code, IOS-XE and
IOS XR now).

And refurbished is only good if you don’t need official service & support.

--
?ukasz Bromirski
CCIE R&S/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On 29/10/2019 11:41, Saku Ytti wrote:
> I hear a lot of people buying MX204 for 15k and less, when they buy a
> single unit, unsure if loss leader to get people to try JNPR.


When I last looked at this, several years ago, the cost of support for
the Juniper MX (in this case, MX480) was ridiculous next to the cost of
the hardware. It amounted to paying a lunatic amount for the hardware,
but with a deposit and three instalments.

Hence, I bought ASR9k instead. Overall it was cheaper. The TCO of the
204 might be better; that wasn't available at the time.

--
Tom
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On Thu, 31 Oct 2019 at 13:31, Tom Hill <tom@ninjabadger.net> wrote:

> When I last looked at this, several years ago, the cost of support for
> the Juniper MX (in this case, MX480) was ridiculous next to the cost of
> the hardware. It amounted to paying a lunatic amount for the hardware,
> but with a deposit and three instalments.

This seems quite random, market/timing dependent what kind of OPEX
vendors are offering. But yes, sometimes it feels we're leasing the
equipment.


--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/