Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Colton Conor]

Stephen,

Which RE is that on the MX480? The RE2000 or the quad core one?

On Wed, Dec 2, 2015 at 4:42 AM, Stepan Kucherenko  wrote:

> Should've put it here in the first post, got already asked about it
> offlist couple of times.
>
> I was testing it on MX80 with slow RE, so obviously numbers will change on
> faster REs but difference will still be there.
>
> ~1.5min taking full table from MX480 (nice RE, 85k updates)
> ~3min from 7600 (old and slow RE, 89k updates)
> almost 5min from ASR9k (nice RE, 450k updates)
>
> It'll be even more noticeable when Junos will be able to run rpd on a
> dedicated core.
>
>
>
> Keep in mind that it's still not actual convergence time, Junos is still
> lagging with FIB updates long after that.
>
> Sadly I was unable to find my old convergence test numbers but krt queue
> was dissipating for at least couple of minutes after BGP converged. I case
> you're wondering if it was the known rpd bug with low krt priority - no, I
> tested it after it was fixed. Not that I'd call it "fixed".
>
> And that's what I don't like about MX-es :-) Not sure if it's faster or
> slower on ASR9k though.
>
>
> On 02.12.2015 12:30, James Bensley wrote:
>
>> On 1 December 2015 at 17:29, Stepan Kucherenko  wrote:
>>
>>> My biggest gripe with ASR9k (or IOS XR in particular) is that Cisco
>>> stopped
>>> grouping BGP prefixes in one update if they have same attributes so it's
>>> one
>>> prefix per update now (or sometimes two).
>>>
>>> Transit ISP we tested it with pinged TAC and got a response that it's
>>> "software/hardware limitation" and nothing can be done.
>>>
>>> I don't know when this regression happened but now taking full feed from
>>> ASR9k is almost twice as slow as taking it from 7600 with weak RE and 3-4
>>> times slower than taking it from MX.
>>>
>>> I'm not joking, test it yourself. Just look at the traffic dump. As I
>>> understand it, it's not an edge case so you must see it as well.
>>>
>>> In my case it was 450k updates per 514k prefixes for full feed from
>>> ASR9k,
>>> 89k updates per 510k prefixes from 7600 and 85k updates per 516k prefixes
>>> from MX480. Huge difference.
>>>
>>> It's not a show stopper but I'm sure it must be a significant impact on
>>> convergence time.
>>>
>>
>> How long timewise is it taking you to converge?
>>
>> Last time I bounced a BGP session to a full table provider it took sub
>> 1 minute to take in all the routes. I wasn't actually timing so I
>> don't know how long exactly.
>>
>> Cheers,
>> James.
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Stepan Kucherenko]

Some RE-S-1800X4, yeah.

ASR9k has RSP440, so quad core x86 as well. Comparable I think.

Not sure about 7600 but definitely something old.

02.12.2015 19:18, Colton Conor пишет:

Stephen,

Which RE is that on the MX480? The RE2000 or the quad core one?

On Wed, Dec 2, 2015 at 4:42 AM, Stepan Kucherenko > wrote:

Should've put it here in the first post, got already asked about it
offlist couple of times.

I was testing it on MX80 with slow RE, so obviously numbers will
change on faster REs but difference will still be there.

~1.5min taking full table from MX480 (nice RE, 85k updates)
~3min from 7600 (old and slow RE, 89k updates)
almost 5min from ASR9k (nice RE, 450k updates)

It'll be even more noticeable when Junos will be able to run rpd on
a dedicated core.



Keep in mind that it's still not actual convergence time, Junos is
still lagging with FIB updates long after that.

Sadly I was unable to find my old convergence test numbers but krt
queue was dissipating for at least couple of minutes after BGP
converged. I case you're wondering if it was the known rpd bug with
low krt priority - no, I tested it after it was fixed. Not that I'd
call it "fixed".

And that's what I don't like about MX-es :-) Not sure if it's faster
or slower on ASR9k though.


On 02.12.2015 12:30, James Bensley wrote:

On 1 December 2015 at 17:29, Stepan Kucherenko > wrote:

My biggest gripe with ASR9k (or IOS XR in particular) is
that Cisco stopped
grouping BGP prefixes in one update if they have same
attributes so it's one
prefix per update now (or sometimes two).

Transit ISP we tested it with pinged TAC and got a response
that it's
"software/hardware limitation" and nothing can be done.

I don't know when this regression happened but now taking
full feed from
ASR9k is almost twice as slow as taking it from 7600 with
weak RE and 3-4
times slower than taking it from MX.

I'm not joking, test it yourself. Just look at the traffic
dump. As I
understand it, it's not an edge case so you must see it as well.

In my case it was 450k updates per 514k prefixes for full
feed from ASR9k,
89k updates per 510k prefixes from 7600 and 85k updates per
516k prefixes
from MX480. Huge difference.

It's not a show stopper but I'm sure it must be a
significant impact on
convergence time.


How long timewise is it taking you to converge?

Last time I bounced a BGP session to a full table provider it
took sub
1 minute to take in all the routes. I wasn't actually timing so I
don't know how long exactly.

Cheers,
James.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp



___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Mark Tinka]

On 1/Dec/15 17:49, john doe wrote:

>  
>
>
> Yeah, I was just referring to cli experience. commits, rollback, hierarchy 
> within. Prior XR IOS was wall of text, no?

Still is, but you get used to working with what you have :-).

Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Mark Tinka]

On 1/Dec/15 18:43, Adam Vitkovsky wrote:

>
> I'd like to ask Mark and users of MX as peering routers (in a scaled 
> configuration) do you put every peer into separate group and you don't mind 
> or perceive any inefficiencies during BGP convergence resulting from many 
> update groups?
> Or you start with several peer groups and group peers based on common egress 
> policies into those and don't mind a peer flapping if it's policy needs to be 
> adjusted and the peer is being put into its own update group?

We run BGP on the MX chassis', as well as the MX80.

We are just deploying our first MX104, but I expect that perform like
the MX80 control- and management plane-wise anyway.

To answer your question, each eBGP peer is a separate group for us, even
when they are sharing the same inbound and outbound routing policies.
It's just easier to manage that way, and we do that mostly for the
flexibility in case we need to do some peer-specific things.

No performance issue on the x86-based MX's. The MX80 is just slow, but
this is in general. I'm not certain it is due to our BGP group strategy,
but I also have no empirical data to dispute this. We are talking
hundreds of BGP groups on MX80's, as we use those more for peering than
our MX480's (which are more for customer edge).

Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[James Bensley]

On 1 December 2015 at 14:14, Mark Tinka  wrote:
>
>
> On 1/Dec/15 15:03, john doe wrote:
>
>>
>>
>> I think price wise MX is a better deal. ASR fully loaded with cards and 
>> licences for various services gets expensive fast.
>
> Depends what cards you are loading in there.
>
> If you're packing an ASR1000 with Ethernet line cards, then you get what
> you deserve.
>
> If you need dense Ethernet aggregation, the ASR9000 and MX are better
> than the ASR1000.
>
> If you need a mix-and-match, the ASR1000 is better than the ASR9000 or MX.

With the exception of LAGs (IMO) as port-channels on the ASR1000
series does not support QoS very well at all on them;

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_mqc/configuration/xe-3s/qos-mqc-xe-3s-book/qos-eth-int.html#GUID-95630B2A-986E-4063-848B-BC0AB7456C44


Cheers,
James.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Stepan Kucherenko]

Should've put it here in the first post, got already asked about it 
offlist couple of times.


I was testing it on MX80 with slow RE, so obviously numbers will change 
on faster REs but difference will still be there.


~1.5min taking full table from MX480 (nice RE, 85k updates)
~3min from 7600 (old and slow RE, 89k updates)
almost 5min from ASR9k (nice RE, 450k updates)

It'll be even more noticeable when Junos will be able to run rpd on a 
dedicated core.




Keep in mind that it's still not actual convergence time, Junos is still 
lagging with FIB updates long after that.


Sadly I was unable to find my old convergence test numbers but krt queue 
was dissipating for at least couple of minutes after BGP converged. I 
case you're wondering if it was the known rpd bug with low krt priority 
- no, I tested it after it was fixed. Not that I'd call it "fixed".


And that's what I don't like about MX-es :-) Not sure if it's faster or 
slower on ASR9k though.


On 02.12.2015 12:30, James Bensley wrote:

On 1 December 2015 at 17:29, Stepan Kucherenko  wrote:

My biggest gripe with ASR9k (or IOS XR in particular) is that Cisco stopped
grouping BGP prefixes in one update if they have same attributes so it's one
prefix per update now (or sometimes two).

Transit ISP we tested it with pinged TAC and got a response that it's
"software/hardware limitation" and nothing can be done.

I don't know when this regression happened but now taking full feed from
ASR9k is almost twice as slow as taking it from 7600 with weak RE and 3-4
times slower than taking it from MX.

I'm not joking, test it yourself. Just look at the traffic dump. As I
understand it, it's not an edge case so you must see it as well.

In my case it was 450k updates per 514k prefixes for full feed from ASR9k,
89k updates per 510k prefixes from 7600 and 85k updates per 516k prefixes
from MX480. Huge difference.

It's not a show stopper but I'm sure it must be a significant impact on
convergence time.


How long timewise is it taking you to converge?

Last time I bounced a BGP session to a full table provider it took sub
1 minute to take in all the routes. I wasn't actually timing so I
don't know how long exactly.

Cheers,
James.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[James Bensley]

On 1 December 2015 at 17:29, Stepan Kucherenko  wrote:
> My biggest gripe with ASR9k (or IOS XR in particular) is that Cisco stopped
> grouping BGP prefixes in one update if they have same attributes so it's one
> prefix per update now (or sometimes two).
>
> Transit ISP we tested it with pinged TAC and got a response that it's
> "software/hardware limitation" and nothing can be done.
>
> I don't know when this regression happened but now taking full feed from
> ASR9k is almost twice as slow as taking it from 7600 with weak RE and 3-4
> times slower than taking it from MX.
>
> I'm not joking, test it yourself. Just look at the traffic dump. As I
> understand it, it's not an edge case so you must see it as well.
>
> In my case it was 450k updates per 514k prefixes for full feed from ASR9k,
> 89k updates per 510k prefixes from 7600 and 85k updates per 516k prefixes
> from MX480. Huge difference.
>
> It's not a show stopper but I'm sure it must be a significant impact on
> convergence time.

How long timewise is it taking you to converge?

Last time I bounced a BGP session to a full table provider it took sub
1 minute to take in all the routes. I wasn't actually timing so I
don't know how long exactly.

Cheers,
James.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[James Bensley]

On 2 December 2015 at 09:17, Mark Tinka  wrote:
>
>
> On 1/Dec/15 17:49, john doe wrote:
>
>>
>>
>>
>> Yeah, I was just referring to cli experience. commits, rollback, hierarchy 
>> within. Prior XR IOS was wall of text, no?
>
> Still is, but you get used to working with what you have :-).

IOS does support configuration reverting and rollbacks, not in exactly
the same way as IOS-XR/Junos but I always use it when workingon the
production network. Just enable configuration archiving:

conf t
 archive
  path sup-bootdisk:/config-backup-
  maximum 10
  write-memory
  end
wr



conf term lock revert timer 20

%ARCHIVE_DIFF-5-ROLLBK_CNFMD_CHG_BACKUP: Backing up current running
config to sup-bootdisk:/config-backup-Nov-25-2015-23-04-57.804-UTC-166

%ARCHIVE_DIFF-5-ROLLBK_CNFMD_CHG_START_ABSTIMER: User: james.bensley:
Scheduled to rollback to config
sup-bootdisk:/config-backup-Nov-25-2015-23-04-57.804-UTC-166 in 20
minutes


! config changes goes here

end


! Check everythign is OK, then confirm the changes to cancel the rollback timer,
! If I make a big boo boo that cuts me off, the config will roll back
after 20 mins (as above)
! without me confirming it

configure confirm


! Oh no, I haven't made such a big mistake that I've been disconnected
! but actually I do need to rollback

configure replace
sup-bootdisk:/config-backup-Nov-25-2015-23-04-57.804-UTC-166 list

Nov 25 2015 23:25:17.479 UTC:
%ARCHIVE_DIFF-5-ROLLBK_CNFMD_CHG_ROLLBACK_START: Start rolling to:
sup-bootdisk:/config-backup-Nov-25-2015-23-04-57.804-UTC-166



Cheers,
James.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Mark Tinka]

On 2/Dec/15 11:44, James Bensley wrote:

> With the exception of LAGs (IMO) as port-channels on the ASR1000
> series does not support QoS very well at all on them;
>
> http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_mqc/configuration/xe-3s/qos-mqc-xe-3s-book/qos-eth-int.html#GUID-95630B2A-986E-4063-848B-BC0AB7456C44

Anything IOS and IOS XE is utterly and completely rubbish when it comes
to policing and general QoS on LAG's. Again, this is where the MX (Trio
+ Junos) outshines them all.

We've been doing some work with Cisco in trying to get better QoS and
policing on LAG's on IOS and IOS XE systems, but this won't happen soon.
It's one of the biggest flaws in IOS and IOS XE today, if you ask me.

For now, we try to avoid having to run LAG's on links that require
complex QoS and policing features on IOS and IOS XE boxes. Other than
that, peachy...

Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Adam Vitkovsky]

Hi,

> Of Mark Tinka
> Sent: Tuesday, December 01, 2015 2:24 PM
> As a peering router, I don't mind either - we deploy MX's, ASR1000's and
> ASR9000's in this role, and happy with either of them.
>
I'd like to ask Mark and users of MX as peering routers (in a scaled 
configuration) do you put every peer into separate group and you don't mind or 
perceive any inefficiencies during BGP convergence resulting from many update 
groups?
Or you start with several peer groups and group peers based on common egress 
policies into those and don't mind a peer flapping if it's policy needs to be 
adjusted and the peer is being put into its own update group?
Thanks.

adam


Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[heasley]

Tue, Dec 01, 2015 at 04:23:33PM +0200, Mark Tinka:
> > XR is very JunOS like.
> 
> Hmmmh, not quite.
> 
> There are still some major cosmetic differences, and a few similarities,
> and definitely different fundamental architectural principles.
> 
> Both are okay for their platforms, but I wouldn't go as far as saying
> they "alike".

I believe that they are vastly different; just from a usability/user-friendly
PoV, though both have blemishes.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Stepan Kucherenko]

My biggest gripe with ASR9k (or IOS XR in particular) is that Cisco 
stopped grouping BGP prefixes in one update if they have same attributes 
so it's one prefix per update now (or sometimes two).


Transit ISP we tested it with pinged TAC and got a response that it's 
"software/hardware limitation" and nothing can be done.


I don't know when this regression happened but now taking full feed from 
ASR9k is almost twice as slow as taking it from 7600 with weak RE and 
3-4 times slower than taking it from MX.


I'm not joking, test it yourself. Just look at the traffic dump. As I 
understand it, it's not an edge case so you must see it as well.


In my case it was 450k updates per 514k prefixes for full feed from 
ASR9k, 89k updates per 510k prefixes from 7600 and 85k updates per 516k 
prefixes from MX480. Huge difference.


It's not a show stopper but I'm sure it must be a significant impact on 
convergence time.


On 01.12.2015 20:08, heasley wrote:

Tue, Dec 01, 2015 at 04:23:33PM +0200, Mark Tinka:

XR is very JunOS like.


Hmmmh, not quite.

There are still some major cosmetic differences, and a few similarities,
and definitely different fundamental architectural principles.

Both are okay for their platforms, but I wouldn't go as far as saying
they "alike".


I believe that they are vastly different; just from a usability/user-friendly
PoV, though both have blemishes.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Adam Vitkovsky]

Hi Colton,

> Of Colton Conor
> Sent: Tuesday, December 01, 2015 4:00 AM
> I have looked and priced both platforms from Juniper and Cisco. Both would
> require two routers for true redundancy as expected. Cisco said instead of
> getting two 9001s, why not look at the ASR9010. They had a promo for free
> RSPs if you buy two cards. The price of the ASR9010 with two cards was just
> about the same price as two 9001s. And a much better deal than the MX104
> fully licensed with two REs and similar cards.
>
> So is looking at something like the ASR9010 worth it even if you only need
> 30Gbps northbound for now? I know for the OP space is a concern so the
> ASR9010, but for those of you with plenty of space what is your overall
> thoughts?
>
ASR9010 is much better product than MX960 -i.e. much better than MX104, so if 
space or power consumption is not a concern I wouldn’t think twice.
My experience is that most of the backbones need to upgrade part or all of 
their backbone links capacity shortly after the initial build out anyways.

adam


Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[john doe]

 

 Hey mate, 

 

 What was the reason? 

 

 From what I can gather 9K is pretty much a copy of MX range. 

 

Considering the MX960 shipped before the ASR9000, doubtful. 




Yup, that's what I wrote )



 

 XR is very JunOS like. 

 

Hmmmh, not quite. 

 

There are still some major cosmetic differences, and a few similarities, 

and definitely different fundamental architectural principles. 

 

Both are okay for their platforms, but I wouldn't go as far as saying 

they "alike". 


Yeah, I was just referring to cli experience. commits, rollback, hierarchy 
within. Prior XR IOS was wall of text, no?


 

 Real curious how these boxes do in the wild since looks i'll be doing lots 
of SP related stuff in the near future. 

 

As a BNG, the MX struggled for a long time. The ASR9000 was slightly 

better at this; although between the two, the ASR1000 is likely to be a 

more sensible option if you want a BNG that has "experience". 

 


Hm, I hear good things about Subscriber management on MX for config options and 
scale.

Some are still running ERX boxes to this day. 





Overall, they both have their places. Personally, in 2015, I prefer the 

MX as an edge router, especially after we got the Policy Map feature 

(ingress QoS marking for various protocols) introduced into Junos. What 

puts me off the ASR9000 is the long IOS XR upgrade process (which I 

could live with if I was asked) and the poor implementation at LAG-based 

policing (deal-breaker). 

 

As a peering router, I don't mind either - we deploy MX's, ASR1000's and 

ASR9000's in this role, and happy with either of them. 

 


Thanks for taking time to write this up.







 

Mark. 

 





___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Saku Ytti]

On 1 December 2015 at 14:14,   wrote:
>> ASR9010 is much better product than MX960 -i.e. much better than
>> MX104, so if space or power consumption is not a concern I wouldn�1ryt
>> think twice.
>
> People clearly have differing opinions on this issue. We got rid of
> our ASR9010s and kept our MX960s. YMMV.

I would certainly go with MX rather than ASR9k as well. But for any
enterprisy stuff, ASR1k any day before SRX.

-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[sthaug]

> ASR9010 is much better product than MX960 -i.e. much better than
> MX104, so if space or power consumption is not a concern I wouldn$,1ry(Bt
> think twice.

People clearly have differing opinions on this issue. We got rid of
our ASR9010s and kept our MX960s. YMMV.

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[john doe]

Hey mate,

What was the reason? 

>From what I can gather 9K is pretty much a copy of MX range.

XR is very JunOS like.

Real curious how these boxes do in the wild since looks i'll be doing lots of 
SP related stuff in the near future.
Sent using Zoho Mail






 On Tue, 01 Dec 2015 13:14:47 +0100 sth...@nethelp.nowrote  




 ASR9010 is much better product than MX960 -i.e. much better than 

 MX104, so if space or power consumption is not a concern I wouldn 1ryt 

 think twice. 

 

People clearly have differing opinions on this issue. We got rid of 

our ASR9010s and kept our MX960s. YMMV. 

 

Steinar Haug, Nethelp consulting, sth...@nethelp.no 





___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[john doe]

On 30/Nov/15 22:56, Amos Rosenboim wrote: 

 

 I don't think ASR1K is comparable to MX. 

 

I think the ASR1000 is comparable to the MX104 specifically. 

 

Both are platforms that are suited to a mix of Ethernet and non-Ethernet 

ports in a cost-effective manner. 

 

Where the ASR1000 edges our the MX104 is that there are various variants 

of the chassis, supporting low-, mid- and high-end forwarding 

capacities, native additional services such as IPSec, NAT, e.t.c.




I think price wise MX is a better deal. ASR fully loaded with cards and 
licences for various services gets expensive fast.



 

 The Juniper platform we position against ASR1K is the Juniper SRX. 

 

That is not really the ideal comparison, if you ask me. If you want to 

pit something against the SRX, for better or worse, I'd do the ASA. 

 

Mark. 




Buddy runs SRX in small SP as a NAT box. Pretty happy with it. Also apparently 
better multicast performance than ASA.

Had a customer running SRX 650 with full BGP and MPLS on top of FW/VPN.  I 
don't think ASA can do the same.

I had some tests on high end ASA back in 09. Couldn't do line rate 10Gbps 
across all packet sizes. We ended up using ASR 1K for it. 

Now with all the NG stuff I'm very skeptical about the future of ASA aka PIX 
v2. Sure they've sandwiched it with SourceFire, but wasn't it tried before with 
ASA CX?





___ 

juniper-nsp mailing list juniper-nsp@puck.nether.net 

https://puck.nether.net/mailman/listinfo/juniper-nsp 





___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Mark Tinka]

On 1/Dec/15 15:06, john doe wrote:

> Hey mate,
>
> What was the reason? 
>
> >From what I can gather 9K is pretty much a copy of MX range.

Considering the MX960 shipped before the ASR9000, doubtful.

>
> XR is very JunOS like.

Hmmmh, not quite.

There are still some major cosmetic differences, and a few similarities,
and definitely different fundamental architectural principles.

Both are okay for their platforms, but I wouldn't go as far as saying
they "alike".

>
> Real curious how these boxes do in the wild since looks i'll be doing lots of 
> SP related stuff in the near future.

The MX960 shipped first. The ASR9000 followed.

The MX gained ground quickly (you can thank the Cisco 6500/7600 for
that), and software matured quite well (until the mess that was Junos
10.x).

The ASR9000 took a while to mature. Those that deployed had lots of
faith and patience. Eventually (and particularly after Cisco and Juniper
agreed to both support LDP and BGP as a signaling and auto-discovery
protocol for l2vpn's), the ASR9000 quickly caught up and were adopted by
networks.

As a BNG, the MX struggled for a long time. The ASR9000 was slightly
better at this; although between the two, the ASR1000 is likely to be a
more sensible option if you want a BNG that has "experience".

Overall, they both have their places. Personally, in 2015, I prefer the
MX as an edge router, especially after we got the Policy Map feature
(ingress QoS marking for various protocols) introduced into Junos. What
puts me off the ASR9000 is the long IOS XR upgrade process (which I
could live with if I was asked) and the poor implementation at LAG-based
policing (deal-breaker).

As a peering router, I don't mind either - we deploy MX's, ASR1000's and
ASR9000's in this role, and happy with either of them.

YMMV.

Mark.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Mark Tinka]

On 1/Dec/15 14:59, Saku Ytti wrote:

> I would certainly go with MX rather than ASR9k as well. But for any
> enterprisy stuff, ASR1k any day before SRX.

+1.

Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Mark Tinka]

On 1/Dec/15 11:35, Adam Vitkovsky wrote:

>
> ASR9010 is much better product than MX960

Before 2015, I'd have said marginally better. But after 2015, I think I
prefer the MX chassis' to the ASR9000.

Apart from the rather heavy IOS XR and its long upgrade times, reliably
policing on LAG's is important to me. The Juniper way of implementing
this is quite elegant, while IOS XR takes a bit of a "take it or leave
it" attitude.

Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Mark Tinka]

On 1/Dec/15 15:03, john doe wrote:

>
>
> I think price wise MX is a better deal. ASR fully loaded with cards and 
> licences for various services gets expensive fast.

Depends what cards you are loading in there.

If you're packing an ASR1000 with Ethernet line cards, then you get what
you deserve.

If you need dense Ethernet aggregation, the ASR9000 and MX are better
than the ASR1000.

If you need a mix-and-match, the ASR1000 is better than the ASR9000 or MX.


>  
>
>
> Buddy runs SRX in small SP as a NAT box. Pretty happy with it. Also 
> apparently better multicast performance than ASA.
>
> Had a customer running SRX 650 with full BGP and MPLS on top of FW/VPN.  I 
> don't think ASA can do the same.
>
> I had some tests on high end ASA back in 09. Couldn't do line rate 10Gbps 
> across all packet sizes. We ended up using ASR 1K for it. 
>
> Now with all the NG stuff I'm very skeptical about the future of ASA aka PIX 
> v2. Sure they've sandwiched it with SourceFire, but wasn't it tried before 
> with ASA CX?

I think it has been discussed both on c-nsp and j-nsp - firewalls (can
be, but) aren't routers.

If you want a firewall, you'll trade routing features.

If you want a router, you won't have all the firewall features.

The ASR1000, for me, as a good in-between consolation. The ASA and SRX
are just too "firewally" to be reasonable routers. If you use them as
routers, you get what you deserve.

Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Adam Vitkovsky]

> From: Mark Tinka [mailto:mark.ti...@seacom.mu]
> Sent: Tuesday, December 01, 2015 2:11 PM
> On 1/Dec/15 11:35, Adam Vitkovsky wrote:
> > ASR9010 is much better product than MX960
>
> Before 2015, I'd have said marginally better. But after 2015, I think I prefer
> the MX chassis' to the ASR9000.
>
> Apart from the rather heavy IOS XR and its long upgrade times, reliably
> policing on LAG's is important to me. The Juniper way of implementing this is
> quite elegant, while IOS XR takes a bit of a "take it or leave it" attitude.
>
Well as I said many times LAGs are tricky :)
Therefore QOS on LAGs is tricky as well,
e.g. if you police the VLAN to 120M on a 4x10G LAG each link gets only 40M if 
more than 40M worth of streams gets hashed on one link you get into trouble.
And it takes quite a fiddling to get Juniper LAGs failover/recover under 50ms.


adam



Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Nitzan Tzelniker]

Regarding CGNAT the MX104 can have MS-MIC that can do all of the
PBA/NAPT/ALG/EIM features for near 10G

Nitzan


On Mon, Nov 30, 2015 at 4:06 PM, Payam Chychi  wrote:

> Asr1000 line are solid if needed for nat
>
> --
> Payam Chychi
> Solution Architect
>
>
> On Monday, November 30, 2015 at 5:57 AM, Saku Ytti wrote:
>
> > On 30 November 2015 at 15:39, Adam Vitkovsky 
> wrote:
> >
> > Hey Adam,
> >
> > > I think this can be alleviated with BGP provider edge link
> protection(Cisco BGP PIC Edge)/BGP PIC Edge(Cisco BGP PIC Core).
> > > However in Junos this is available only for VRFs.
> > >
> >
> >
> > You'll be happy to hear it got into 15.1 for INET \o/
> >
> > > That's right Trio's LU is just better, it can cope with any
> combination of features enabled with only small performance hit compared to
> A9k's NPU.
> > > However if QX chip is used the whole LU performance advantage is
> jeopardized (but at least the degradation is deterministic).
> > >
> >
> >
> > My main woe is not feature parity or inherent capability of
> > Trio/EZ/nPower, it's more that once JNPR ships something, it'll work
> > on all Trio kit. Cisco is coming up _really_ good troubleshooting
> > tooling for ASR9k, but they'll arrive at different pace (or maybe not
> > at all) at different engines, which is completely understandable for
> > this low-level stuff.
> >
> > > Also the basic Junos documentation is incomplete and getting some deep
> level information is next to impossible.
> >
> > ACK. This is not mentioned often enough, Cisco is doing pretty good
> > job in documents.
> >
> > > And what about ASR903 it's very similar product to MX104.
> >
> > Dunno, I'd say it's more similar to ACX1k, both are running BRCM
> > Enduro? Looking forward to Waris' webinar.
> >
> > --
> > ++ytti
> > ___
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> >
>
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Mark Tinka]

On 30/Nov/15 21:18, Nitzan Tzelniker wrote:

> Regarding CGNAT the MX104 can have MS-MIC that can do all of the
> PBA/NAPT/ALG/EIM features for near 10G

I've never been keen on adding more expensive hardware to existing
expensive hardware to do something that ought to be supported inline.

This is why the ASR1000 is a better option, IMHO.

Mark.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Amos Rosenboim]

I don't think ASR1K is comparable to MX.
The Juniper platform we position against ASR1K is the Juniper SRX.

Amos

Sent from my iPhone

On 30 Nov 2015, at 22:05, Mark Tinka 
> wrote:



On 30/Nov/15 21:18, Nitzan Tzelniker wrote:

Regarding CGNAT the MX104 can have MS-MIC that can do all of the
PBA/NAPT/ALG/EIM features for near 10G

I've never been keen on adding more expensive hardware to existing
expensive hardware to do something that ought to be supported inline.

This is why the ASR1000 is a better option, IMHO.

Mark.

___
juniper-nsp mailing list 
juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Mark Tinka]

On 1/Dec/15 06:00, Colton Conor wrote:

> I have looked and priced both platforms from Juniper and Cisco. Both would
> require two routers for true redundancy as expected. Cisco said instead of
> getting two 9001s, why not look at the ASR9010. They had a promo for free
> RSPs if you buy two cards. The price of the ASR9010 with two cards was just
> about the same price as two 9001s. And a much better deal than the MX104
> fully licensed with two REs and similar cards.
>
> So is looking at something like the ASR9010 worth it even if you only need
> 30Gbps northbound for now? I know for the OP space is a concern so
> the ASR9010, but for those of you with plenty of space what is your overall
> thoughts?

The ASR9010 isn't bad (although you probably want to be looking at the
ASR99xx line moving forward), but if the OP is still looking at NAT,
then not an ideal platform because he'll have to buy another service
line card to do the NAT offload. This takes up even more space and adds
cost.

Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Colton Conor]

I have looked and priced both platforms from Juniper and Cisco. Both would
require two routers for true redundancy as expected. Cisco said instead of
getting two 9001s, why not look at the ASR9010. They had a promo for free
RSPs if you buy two cards. The price of the ASR9010 with two cards was just
about the same price as two 9001s. And a much better deal than the MX104
fully licensed with two REs and similar cards.

So is looking at something like the ASR9010 worth it even if you only need
30Gbps northbound for now? I know for the OP space is a concern so
the ASR9010, but for those of you with plenty of space what is your overall
thoughts?

Other options might be a used MX240 with older RE's and DPC cards.




On Mon, Nov 30, 2015 at 4:34 AM, john doe  wrote:

> Hey guys,
>
> Working on a project here and it's more or less SP focused,
>
> Which is not a muscle I've worked on lately, mostly been doing campus
> stuff.
>
>
>
> Looking at MX104 vs ASR 9001 as a potential solution.
>
> Requirements are fairly straightforward  - 1GE to collect customers and
> 10GE going northbound (up to 30 Gbps), full MPLS and IP stack, possibly
> Carrier NAT.
>
> Customer wants a box that will give them most room to grown in terms of
> scale/features. And we can't go full modular since rack space is big pain
> for these guys. Price is also an issue (as usual)
>
> I heard good stuff about Juniper SP gear, while not so complimentary
> things of ASR. But that was when platform was introduced and they had all
> sorts of IOS-XR adventures.
>
> Would love to hear some input from here as vendor claims are conflicting
> (nothing new here I guess)
>
>
>
> Cheers
>
>
>
> p.s.
>
> Anyone with experience on ISSU on these platforms?
>
> I've done some googling and it seems like on both platforms it's dependent
> upon line cards you use.
>
> Plus most of the stuff I found was covering big chassis systems, not the
> low range.
>
>
>
>
>
> Sent using Zoho Mail
>
>
>
>
>
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Mark Tinka]

On 30/Nov/15 22:56, Amos Rosenboim wrote:

> I don't think ASR1K is comparable to MX.

I think the ASR1000 is comparable to the MX104 specifically.

Both are platforms that are suited to a mix of Ethernet and non-Ethernet
ports in a cost-effective manner.

Where the ASR1000 edges our the MX104 is that there are various variants
of the chassis, supporting low-, mid- and high-end forwarding
capacities, native additional services such as IPSec, NAT, e.t.c.

> The Juniper platform we position against ASR1K is the Juniper SRX.

That is not really the ideal comparison, if you ask me. If you want to
pit something against the SRX, for better or worse, I'd do the ASA.

Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Mark Tinka]

On 30/Nov/15 12:34, john doe wrote:

> Hey guys,
>
> Working on a project here and it's more or less SP focused,
>
> Which is not a muscle I've worked on lately, mostly been doing campus stuff.
>
>
>
> Looking at MX104 vs ASR 9001 as a potential solution.
>
> Requirements are fairly straightforward  - 1GE to collect customers and 10GE 
> going northbound (up to 30 Gbps), full MPLS and IP stack, possibly Carrier 
> NAT.
>
> Customer wants a box that will give them most room to grown in terms of 
> scale/features. And we can't go full modular since rack space is big pain for 
> these guys. Price is also an issue (as usual)
>
> I heard good stuff about Juniper SP gear, while not so complimentary things 
> of ASR. But that was when platform was introduced and they had all sorts of 
> IOS-XR adventures.
>
> Would love to hear some input from here as vendor claims are conflicting 
> (nothing new here I guess)

The MX104 has dual RE's, while the ASR9001 only one RP.

The current MX104 RE's are quite slow, but since they are modular, the
unit could get a quicker one in the future.

The ASR9001 has more capacity (120Gbps) vs. the MX104 which is only 80Gbps.

The MX104 has 4x modular slots while the ASR9001 has only 2x.

The ASR9001 is physically smaller than the MX104, so if rack space is
tight, the Cisco is a better option.

Feature-wise, Junos and IOS XR won't let you down. Your decision factors
are most likely going to be price.

Personally, if you're going to be running policers on LAG's, Junos on
the Trio chipset is better than what Cisco currently have.

Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Mark Tinka]

On 30/Nov/15 13:27, Saku Ytti wrote:

> For either of these NAT is bit awkward, as it's going to have to go
> via separate service card anyhow. Unless you could live with 1:1 NAT,
> but I believe CarrierNAT implies NAPT.
> If all traffic is NAPTed traffic, you might want  to go with ASR1k instead.

Agree - if you want NAT, the ASR1000 is the ideal platform for this.

The ASR1000 line has just got a refresh as well, so from a scaling
perspective, you've got both the low- and high-end options.

Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Cisco ASR 9001 vs Juniper MX104

[john doe]

Hey guys,

Working on a project here and it's more or less SP focused,

Which is not a muscle I've worked on lately, mostly been doing campus stuff.



Looking at MX104 vs ASR 9001 as a potential solution.

Requirements are fairly straightforward  - 1GE to collect customers and 10GE 
going northbound (up to 30 Gbps), full MPLS and IP stack, possibly Carrier NAT.

Customer wants a box that will give them most room to grown in terms of 
scale/features. And we can't go full modular since rack space is big pain for 
these guys. Price is also an issue (as usual)

I heard good stuff about Juniper SP gear, while not so complimentary things of 
ASR. But that was when platform was introduced and they had all sorts of IOS-XR 
adventures.

Would love to hear some input from here as vendor claims are conflicting 
(nothing new here I guess)



Cheers



p.s.

Anyone with experience on ISSU on these platforms?

I've done some googling and it seems like on both platforms it's dependent upon 
line cards you use.

Plus most of the stuff I found was covering big chassis systems, not the low 
range.





Sent using Zoho Mail






___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Saku Ytti]

On 30 November 2015 at 12:34, john doe  wrote:

Hey,

> Looking at MX104 vs ASR 9001 as a potential solution.
>
> Requirements are fairly straightforward  - 1GE to collect customers and 10GE 
> going northbound (up to 30 Gbps), full MPLS and IP stack, possibly Carrier 
> NAT.

For either of these NAT is bit awkward, as it's going to have to go
via separate service card anyhow. Unless you could live with 1:1 NAT,
but I believe CarrierNAT implies NAPT.
If all traffic is NAPTed traffic, you might want  to go with ASR1k instead.

> Customer wants a box that will give them most room to grown in terms of 
> scale/features. And we can't go full modular since rack space is big pain for 
> these guys. Price is also an issue (as usual)
>
> I heard good stuff about Juniper SP gear, while not so complimentary things 
> of ASR. But that was when platform was introduced and they had all sorts of 
> IOS-XR adventures.
>
> Would love to hear some input from here as vendor claims are conflicting 
> (nothing new here I guess)

For ASR9001 and MX104 I would definitely choose MX104. Both boxes have
serious problems, but MX maybe less so. Largest problem MX has is that
it's decoupling route HW insertion and readvertisement in SW+HW, so in
scaled BGP environment you're going to do some blackholing during
convergence. This may be minor inconvenience or major headeache.
HW in MX104 is simpler, as it's fabricless, which I think is very good
thing as long as you can get away with it, distributed architecture is
just harmful.

I think Trio is better story than ASR9k engine story, it's still same
microcode and fundamentally same design from oldest MPC1 to newest
MPC, unlike ASR9k which is making jump to entirely new engine, and
even Trio to EZChip, I think Trio wins.

JunOS and IOS-XR are both terrible in their own way. I have more faith
in JunOS today than in IOS-XR.

JunOS is very conservative, run-to-completion single threaded RPD
(much same design as IOS XE), which in theory requires very very good
code quality to pull it off, and in JunOS the code quality issues
related to run-to-completion flat model manifests as 'RPD slips',
where you might lose your IGP because commit took too long.
IOS-XR is architecturally more modern, but they likely made some
architectural design flaws, as the platform seems to have quite large
amount of state errors. Perhaps Barney was wrong, perhaps newer isn't
always better.

 I think most innovation is to be made in control-plane software.
Everything today is basically awfully fragile hacks.

> Anyone with experience on ISSU on these platforms?

Yes. Don't.

-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Mark Tinka]

On 30/Nov/15 15:39, Adam Vitkovsky wrote:

> Yes XR is more modern and as a consequence there are a lot of things/features 
> that makes your life easier that I miss in Junos.

If only IOS XR was as easy to upgrade as Junos. All that modularity is
still a pain, even in 2015.

> Technology wise Junos is trailing XR, so any feature introduced into XR is 
> going to be available in Junos only on releases that are more towards the 
> bleeding edge.

This is one of my biggest issues with Junos, particularly in the days of
Junos 10.x.

Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Saku Ytti]

On 30 November 2015 at 15:39, Adam Vitkovsky  wrote:

Hey Adam,

> I think this can be alleviated with BGP provider edge link protection(Cisco 
> BGP PIC Edge)/BGP PIC Edge(Cisco BGP PIC Core).
> However in Junos this is available only for VRFs.

You'll be happy to hear it got into 15.1 for INET \o/

> That's right Trio's LU is just better, it can cope with any combination of 
> features enabled with only small performance hit compared to A9k's NPU.
> However if QX chip is used the whole LU performance advantage is jeopardized 
> (but at least the degradation is deterministic).

My main woe is not feature parity or inherent capability of
Trio/EZ/nPower, it's more that once JNPR ships something, it'll work
on all Trio kit. Cisco is coming up _really_ good troubleshooting
tooling for ASR9k, but they'll arrive at different pace (or maybe not
at all) at different engines, which is completely understandable for
this low-level stuff.

> Also the basic Junos documentation is incomplete and getting some deep level 
> information is next to impossible.

ACK. This is not mentioned often enough, Cisco is doing pretty good
job in documents.

> And what about ASR903 it's very similar product to MX104.

Dunno, I'd say it's more similar to ACX1k, both are running BRCM
Enduro? Looking forward to Waris' webinar.

-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Payam Chychi]

Asr1000 line are solid if needed for nat 

-- 
Payam Chychi
Solution Architect 


On Monday, November 30, 2015 at 5:57 AM, Saku Ytti wrote:

> On 30 November 2015 at 15:39, Adam Vitkovsky  
> wrote:
> 
> Hey Adam,
> 
> > I think this can be alleviated with BGP provider edge link protection(Cisco 
> > BGP PIC Edge)/BGP PIC Edge(Cisco BGP PIC Core).
> > However in Junos this is available only for VRFs.
> > 
> 
> 
> You'll be happy to hear it got into 15.1 for INET \o/
> 
> > That's right Trio's LU is just better, it can cope with any combination of 
> > features enabled with only small performance hit compared to A9k's NPU.
> > However if QX chip is used the whole LU performance advantage is 
> > jeopardized (but at least the degradation is deterministic).
> > 
> 
> 
> My main woe is not feature parity or inherent capability of
> Trio/EZ/nPower, it's more that once JNPR ships something, it'll work
> on all Trio kit. Cisco is coming up _really_ good troubleshooting
> tooling for ASR9k, but they'll arrive at different pace (or maybe not
> at all) at different engines, which is completely understandable for
> this low-level stuff.
> 
> > Also the basic Junos documentation is incomplete and getting some deep 
> > level information is next to impossible.
> 
> ACK. This is not mentioned often enough, Cisco is doing pretty good
> job in documents.
> 
> > And what about ASR903 it's very similar product to MX104.
> 
> Dunno, I'd say it's more similar to ACX1k, both are running BRCM
> Enduro? Looking forward to Waris' webinar.
> 
> -- 
> ++ytti
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> 


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Cisco ASR 9001 vs Juniper MX104

[Adam Vitkovsky]

Hi,

> Saku Ytti
> Sent: Monday, November 30, 2015 11:28 AM
> For ASR9001 and MX104 I would definitely choose MX104. Both boxes have
> serious problems, but MX maybe less so. Largest problem MX has is that it's
> decoupling route HW insertion and readvertisement in SW+HW, so in scaled
> BGP environment you're going to do some blackholing during convergence.
> This may be minor inconvenience or major headeache.
I think this can be alleviated with BGP provider edge link protection(Cisco BGP 
PIC Edge)/BGP PIC Edge(Cisco BGP PIC Core).
However in Junos this is available only for VRFs.

> HW in MX104 is simpler, as it's fabricless, which I think is very good thing 
> as
> long as you can get away with it, distributed architecture is just harmful.
>
> I think Trio is better story than ASR9k engine story, it's still same 
> microcode
> and fundamentally same design from oldest MPC1 to newest MPC, unlike
> ASR9k which is making jump to entirely new engine, and even Trio to EZChip,
> I think Trio wins.
That's right Trio's LU is just better, it can cope with any combination of 
features enabled with only small performance hit compared to A9k's NPU.
However if QX chip is used the whole LU performance advantage is jeopardized 
(but at least the degradation is deterministic).

> JunOS and IOS-XR are both terrible in their own way. I have more faith in
> JunOS today than in IOS-XR.
>
> JunOS is very conservative, run-to-completion single threaded RPD (much
> same design as IOS XE), which in theory requires very very good code quality
> to pull it off, and in JunOS the code quality issues related to run-to-
> completion flat model manifests as 'RPD slips', where you might lose your
> IGP because commit took too long.
Or you get random convergence times when adding links to bundle.

> IOS-XR is architecturally more modern, but they likely made some
> architectural design flaws, as the platform seems to have quite large amount
> of state errors. Perhaps Barney was wrong, perhaps newer isn't always
> better.
>
>  I think most innovation is to be made in control-plane software.
> Everything today is basically awfully fragile hacks.
>
Yes XR is more modern and as a consequence there are a lot of things/features 
that makes your life easier that I miss in Junos.
Technology wise Junos is trailing XR, so any feature introduced into XR is 
going to be available in Junos only on releases that are more towards the 
bleeding edge.
Also the basic Junos documentation is incomplete and getting some deep level 
information is next to impossible.

> > Anyone with experience on ISSU on these platforms?
>
> Yes. Don't.
>
Yeah the only platform out there that promises working ISSU are the NCS series 
from Cisco, but would love to hear the real world stories.


And what about ASR903 it's very similar product to MX104.

adam



Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp