Re: [j-nsp] Unwanted newline characters in Netconf XML

[Tore Anderson]

Hi Dave,

* Dave Bell 

> It certainly looks like a bug to me. I've tested it in our lab on an
> MX running 12.3R8, and get the same problem as you.
> 
> Interestingly this conflicts with their documentation:
> "The NETCONF server returns the information in XML-tagged format,
> which is identical to the output displayed in the CLI when you include
> the | display xml option after the operational mode command."
> http://www.juniper.net/documentation/en_US/junos13.2/topics/task/operational/netconf-operational-request-output-format.html
> 
> Clearly this is not identical!

Thanks for this pointer. I think I'll have to go to JTAC with this one
and references like these does help (in case they try to claim it's
working as intended).

> Have you tried upgrading to a later version of JunOS?

Tried now. Same behaviour in 15.1R2.

> With actually no information about what you are actually trying to do,
> I don't see there being a massive issue with stripping out new lines.
> I can't think of anything other than comments that might allow a line
> break.

Yeah, if  is the only thing that can contain newlines,
then I'd be fine with a hack like «$xml =~ s/\n//mg» before feeding the
output to the XML parser since I'm not interested in comments anyway.

> In fact I've just been playing with trying to put a line break in a
> comment, and that doesn't even seem to work!

Works fine for me? Even in JUNOS versions as old as 11.4. Try:

{master:1}[edit]
tore@lab-ex4200# load merge terminal
[Type ^D at a new line to end input]
/* This is a
 * multi-line
 * comment.
 */
protocols{} 
[edit]
  'protocols'
warning: statement has no contents; ignored
load complete

{master:1}[edit]
tore@lab-ex4200# show | compare 
[edit]
+  /* This is a
+   * multi-line
+   * comment.
+   */
   protocols { ... }

{master:1}[edit]
tore@lab-ex4200# show | display xml | find junos:comment   
/* This is a
 * multi-line
 * comment.
 */


Some whitespace has appeared out of nowhere in this XML output too...

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

Re: [j-nsp] SNMP OID for CPU temperature

[Rajendra Maharjan]

Hi Michael,

Thanks for the info.


Regards,
Rajendra Maharjan


On Dec 1, 2015, at 9:39 PM, Michael Hare  wrote:

> show chassis environment | display xml

___
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

[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

[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

[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] SNMP OID for CPU temperature

[Michael Hare]

In my experience the MIB doesn't list all possible instrumentation points.  
Although the below may have enough for you, we've resorted to parsing "show 
chassis environment | display xml"

-Michael

> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
> Rajendra Maharjan
> Sent: Tuesday, December 01, 2015 1:18 AM
> To: Dale Shaw 
> Cc: juniper-nsp 
> Subject: Re: [j-nsp] SNMP OID for CPU temperature
> 
> Hi Dale,
> 
> I am on MX router and temperature value given by snmp walk is of RE which
> we are already using. But there is no any oid that points out CPU Temperature
> run show snmp mib walk jnxOperatingTemp
> jnxOperatingTemp.1.1.0.0 = 0
> jnxOperatingTemp.2.1.0.0 = 58
> jnxOperatingTemp.2.2.0.0 = 48
> jnxOperatingTemp.4.1.0.0 = 0
> jnxOperatingTemp.4.1.1.0 = 0
> jnxOperatingTemp.4.1.2.0 = 0
> jnxOperatingTemp.4.1.3.0 = 0
> jnxOperatingTemp.4.1.4.0 = 0
> jnxOperatingTemp.4.1.5.0 = 0
> jnxOperatingTemp.6.1.0.0 = 72
> jnxOperatingTemp.6.1.1.0 = 55
> jnxOperatingTemp.6.1.2.0 = 70
> jnxOperatingTemp.6.1.3.0 = 73
> jnxOperatingTemp.7.1.0.0 = 72
> jnxOperatingTemp.7.2.0.0 = 72
> jnxOperatingTemp.7.3.0.0 = 72
> jnxOperatingTemp.8.1.1.0 = 0
> jnxOperatingTemp.8.1.2.0 = 0
> jnxOperatingTemp.8.2.1.0 = 0
> jnxOperatingTemp.8.2.2.0 = 0
> jnxOperatingTemp.8.3.1.0 = 0
> jnxOperatingTemp.9.1.0.0 = 56
> jnxOperatingTemp.20.1.1.0 = 0
> jnxOperatingTemp.20.2.1.0 = 0
> jnxOperatingTemp.20.2.2.0 = 0
> jnxOperatingTemp.20.3.1.0 = 0
> 
> #run show chassis routing-engine
> Routing Engine status:
>   Slot 0:
> Current state  Master
> Election priority  Master (default)
> Temperature 56 degrees C / 132 degrees F
> CPU temperature 67 degrees C / 152 degrees F
> 
> 
> Regards,
> Rajendra Maharjan
> 
> 
> On Dec 1, 2015, at 12:26 PM, Dale Shaw  wrote:
> 
> > show snmp mib walk jnxOperatingTemp
> 
> ___
> 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

[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

[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] Unwanted newline characters in Netconf XML

[Phil Mayers]

On 01/12/15 14:07, Phil Mayers wrote:


Yuck. Does it happen if you send the same command over Junoscript rather
than Netconf? I don't see this on Junoscript talking to 11.4R7.5 or
13.2X51-D35.3. It might be a Netconf-specific thing.



...but I do see it over netconf. Sigh, looks like another Junoscript != 
Netconf issue :o(

___
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

[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 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] Unwanted newline characters in Netconf XML

[Phil Mayers]

On 01/12/15 13:21, Tore Anderson wrote:

I'm assuming this must be a JUNOS bug?

$ echo '' | ssh -s lab-ex netconf
[...]
http://xml.juniper.net/junos/12.3R10/junos";>
http://xml.juniper.net/junos/12.3R10/junos-interface"; 
junos:style="normal">


ge-0/0/0

[...]


Yuck. Does it happen if you send the same command over Junoscript rather 
than Netconf? I don't see this on Junoscript talking to 11.4R7.5 or 
13.2X51-D35.3. It might be a Netconf-specific thing.

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

Re: [j-nsp] Unwanted newline characters in Netconf XML

[Dave Bell]

It certainly looks like a bug to me. I've tested it in our lab on an
MX running 12.3R8, and get the same problem as you.

Interestingly this conflicts with their documentation:
"The NETCONF server returns the information in XML-tagged format,
which is identical to the output displayed in the CLI when you include
the | display xml option after the operational mode command."
http://www.juniper.net/documentation/en_US/junos13.2/topics/task/operational/netconf-operational-request-output-format.html

Clearly this is not identical!

Have you tried upgrading to a later version of JunOS?

With actually no information about what you are actually trying to do,
I don't see there being a massive issue with stripping out new lines.
I can't think of anything other than comments that might allow a line
break. In fact I've just been playing with trying to put a line break
in a comment, and that doesn't even seem to work!

Regards,
Dave

On 1 December 2015 at 13:21, Tore Anderson  wrote:
> I'm assuming this must be a JUNOS bug?
>
> $ echo '' | ssh -s lab-ex netconf
> [...]
>  xmlns:junos="http://xml.juniper.net/junos/12.3R10/junos";>
>  xmlns="http://xml.juniper.net/junos/12.3R10/junos-interface"; 
> junos:style="normal">
> 
> 
> ge-0/0/0
> 
> [...]
>
> The newline characters immediately following  and preceeding
>  becomes part of the node value - that is, the interface name
> becomes "\nge-0/0/0\n" instead of "ge-0/0/0". (This does not happen
> only with interface names, pretty much any value is wrapped in these
> newline characters.)
>
> This in turn makes using XPath with expressions such as for example
> «//physical-interface[name="ge-0/0/0"]» to fail miserably.
>
> A simple workaround is to strip all the newline characters from the XML
> string before feeding it to the XML parser. But that of course will
> also break nodes may actually contain newlines -  comes
> to mind, are there others?
>
> I'm far from being an expert on XML or Netconf for that matter, so I'm
> wondering if anyone else on the list ran into this issue (surely yes?)
> and if so if there's a better way to deal with it?
>
> Interestingly, running "show interfaces | display xml" from the JUNOS
> shell looks much better:
>
> http://xml.juniper.net/junos/12.3R10/junos";>
>  xmlns="http://xml.juniper.net/junos/12.3R10/junos-interface"; 
> junos:style="normal">
> 
> ge-0/0/0
> [...]
>
> If I could only convince the Netconf service to give me its replay
> formatted in this way instead everything would have worked well.
>
> Tore
> ___
> 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

[j-nsp] Unwanted newline characters in Netconf XML

[Tore Anderson]

I'm assuming this must be a JUNOS bug?

$ echo '' | ssh -s lab-ex netconf
[...]
http://xml.juniper.net/junos/12.3R10/junos";>
http://xml.juniper.net/junos/12.3R10/junos-interface"; 
junos:style="normal">


ge-0/0/0

[...]

The newline characters immediately following  and preceeding
 becomes part of the node value - that is, the interface name
becomes "\nge-0/0/0\n" instead of "ge-0/0/0". (This does not happen
only with interface names, pretty much any value is wrapped in these
newline characters.)

This in turn makes using XPath with expressions such as for example
«//physical-interface[name="ge-0/0/0"]» to fail miserably.

A simple workaround is to strip all the newline characters from the XML
string before feeding it to the XML parser. But that of course will
also break nodes may actually contain newlines -  comes
to mind, are there others?

I'm far from being an expert on XML or Netconf for that matter, so I'm
wondering if anyone else on the list ran into this issue (surely yes?)
and if so if there's a better way to deal with it?

Interestingly, running "show interfaces | display xml" from the JUNOS
shell looks much better:

http://xml.juniper.net/junos/12.3R10/junos";>
http://xml.juniper.net/junos/12.3R10/junos-interface"; 
junos:style="normal">

ge-0/0/0
[...]

If I could only convince the Netconf service to give me its replay
formatted in this way instead everything would have worked well.

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

 

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

[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

[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