Re: [j-nsp] Experiences with QFX5110/QFX5120 (martini l2circuit w/tag manipulation)

[Colton Conor]

Jason,

Did you ever get any feedback or implement this on the QFX's?

On Tue, May 14, 2019 at 9:00 PM Jason Lixfeld  wrote:

> Hey there,
>
> I’m starting to test martini l2circuits on a QFX5110 (17.3R3-S4.2).  I’m
> looking at possibly using these boxes, or QFX5120s on a larger scale to
> terminate these types of circuits on other QFX’ or Cisco
> ME3600/ASR920/ASR9000.
>
> These l2circuits could be in either port-based mode or vlan-based mode (I
> believe the JunOS nomenclature is ethernet-ccc encap and vlan-ccc encap,
> respectively).
>
> The vlan-based use cases could include tag pop/push/swap on inner and/or
> outer tags of either 802.1ad and 802.1q encapsulated frames.
>
> These boxes would participate in an LDP based MPLS network, pinned up with
> BFD’d IS-IS, and protected with rLFA.
>
> I’ve reviewed MPLS feature support[1] and MPLS limitation[2] docs for the
> QFX platform, and nothing immediately jumps out from a features or
> limitations perspective, but I’d appreciate any real-world feedback on the
> good, bad, and ugly.
>
> Thanks in advance!
>
> [1]
> https://www.juniper.net/documentation/en_US/junos/topics/concept/mpls-features-qfx-series-overview.html
> [2]
> https://www.juniper.net/documentation/en_US/junos/topics/reference/general/mpls-limitations-qfx-series.html
>
> ___
> 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] ACX Questions

[Colton Conor]

I just received an off list email stating that the ACX5048 does support
l2circuit (LDP signaled). Is this the same feature as Ethernet-over-MPLS
(L2 circuit)? If so why is it showing this feature is not supported on ACX
(or MX for that matter)? Is the feature explorer incorrect?
https://apps.juniper.net/feature-explorer/feature-info.html?fKey=6620=Ethernet-over-MPLS%20(L2%20circuit)


I do see
20.3R1
Starting in Junos OS Release 20.3R1, support for Layer 2 circuit to provide
Layer 2 VPN and VPWS with LDP signaling.

On Fri, Apr 16, 2021 at 8:52 AM Colton Conor  wrote:

> Thanks all for this information. Aaron I had my client run this same
> command on their QFX5100, and it too has max 3 labels. It seems the issue
> is that the client needs a layer 2 transport over a layer 3 network. VPLS
> is the logical choice, and the ACX5048 supports this according to the
> Juniper Feature Explorer. The QFX5100, however, does not. What layer 2 over
> Layer 3 option do you recommend for the QFX5100 to talk to an ACX5048 or
> MX204 on the other end?
> It looks like the QFX5100 supports Ethernet-over-MPLS (L2 circuit). Is
> this an alternative to VPLS? ACX and MX does not support Ethernet-over-MPLS
> (L2 circuit) however. It seems there is no common protocol that both the
> QFX and ACX/MX share in common under the Virtual Private Networks (VPNs)
> section of the feature explorer. Is there any solution other than replacing
> the QFX with ACX's or MX's?
>
>
> https://apps.juniper.net/feature-explorer/select-platform.html?category=Switching=1#family==31705100=QFX5100=20.4R1=1093=0.10700692867685069=Junos%20OS
>
>
> On Wed, Apr 14, 2021 at 12:51 AM  wrote:
>
>> Of the interfaces configured for mpls on this acx, they show max labels 3
>>
>>
>>
>> me@5048> show mpls interface detail | grep "Interface|labels"
>> Interface: ae0.0
>>   Maximum labels: 3
>> Interface: ae40.0
>>   Maximum labels: 3
>> Interface: xe-0/0/0.0
>>   Maximum labels: 3
>> Interface: ge-0/0/3.0
>>   Maximum labels: 3
>> Interface: ge-0/0/5.0
>>   Maximum labels: 3
>> Interface: ge-0/0/13.0
>>   Maximum labels: 3
>> Interface: ge-0/0/18.0
>>   Maximum labels: 3
>> Interface: ge-0/0/24.0
>>   Maximum labels: 3
>> Interface: ge-0/0/38.0
>>   Maximum labels: 3
>>
>> me@5048> show system information
>> Model: acx5048
>> Family: junos
>> Junos: 17.4R2-S11
>> Hostname: 5048
>>
>>
>>
>> -Aaron
>>
>>
>>
>>
>>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX Questions

[Colton Conor]

Thanks all for this information. Aaron I had my client run this same
command on their QFX5100, and it too has max 3 labels. It seems the issue
is that the client needs a layer 2 transport over a layer 3 network. VPLS
is the logical choice, and the ACX5048 supports this according to the
Juniper Feature Explorer. The QFX5100, however, does not. What layer 2 over
Layer 3 option do you recommend for the QFX5100 to talk to an ACX5048 or
MX204 on the other end?
It looks like the QFX5100 supports Ethernet-over-MPLS (L2 circuit). Is this
an alternative to VPLS? ACX and MX does not support Ethernet-over-MPLS (L2
circuit) however. It seems there is no common protocol that both the QFX
and ACX/MX share in common under the Virtual Private Networks (VPNs)
section of the feature explorer. Is there any solution other than replacing
the QFX with ACX's or MX's?

https://apps.juniper.net/feature-explorer/select-platform.html?category=Switching=1#family==31705100=QFX5100=20.4R1=1093=0.10700692867685069=Junos%20OS


On Wed, Apr 14, 2021 at 12:51 AM  wrote:

> Of the interfaces configured for mpls on this acx, they show max labels 3
>
>
>
> me@5048> show mpls interface detail | grep "Interface|labels"
> Interface: ae0.0
>   Maximum labels: 3
> Interface: ae40.0
>   Maximum labels: 3
> Interface: xe-0/0/0.0
>   Maximum labels: 3
> Interface: ge-0/0/3.0
>   Maximum labels: 3
> Interface: ge-0/0/5.0
>   Maximum labels: 3
> Interface: ge-0/0/13.0
>   Maximum labels: 3
> Interface: ge-0/0/18.0
>   Maximum labels: 3
> Interface: ge-0/0/24.0
>   Maximum labels: 3
> Interface: ge-0/0/38.0
>   Maximum labels: 3
>
> me@5048> show system information
> Model: acx5048
> Family: junos
> Junos: 17.4R2-S11
> Hostname: 5048
>
>
>
> -Aaron
>
>
>
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX Questions

[Colton Conor]

Is there a Juniper SE that has the ability to answer these questions?

On Fri, Apr 9, 2021 at 12:49 PM Colton Conor  wrote:

> For the ACX line, what is the Maximum number of MPLS labels in a packet’s
> label stack (push, pop, and swap operations)? Specifically, mostly
> interested in the ACX5048 and ACX2200's
>
> I found the following chart for the QFX line, and it was extremely
> helpful. I haven't been able to find the same information for the ACX Line
> however:
> https://www.juniper.net/documentation/en_US/junos/topics/reference/general/mpls-scaling-values-qfx-series.html
>
>
> Can anyone confirm or deny if the ACX5048's hardware is identical to the
> QFX5100? My understanding is they run a different JUNOS load on them, but
> hardware wise they are extremely similar. On the hardware side, is there
> anything in the ACX5048 that would allow more  MPLS labels in a packet’s
> label stack than the QFX5100?
>
> For the ACX line, do they support streaming telemetry? I am not sure
> exactly what to look for on the streaming telemetry support for the ACX. I
> basically just want to see realtime interface and optical stats. Which JTI
> feature is that?
>
> For the ACX5000, there are only 3 items listed under the Junos Telemetry
> Interface section.
>
>
> https://apps.juniper.net/feature-explorer/select-platform.html?category=Routing=1#family==10105000=ACX5000=20.4R1=1093=0.42180881218269106=Junos%20OS
>
> For comparison, the QFX 5100 shows 21 different features under the JTI
> Section:
>
> https://apps.juniper.net/feature-explorer/select-platform.html?category=Switching=1#family==31705100=QFX5100=20.4R1=1093=0.566764714896294=Junos%20OS
>
> Which feature am I looking for? Yes, I know this will require a collector
> of some sort.
>
>
>
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] ACX Questions

[Colton Conor]

For the ACX line, what is the Maximum number of MPLS labels in a packet’s
label stack (push, pop, and swap operations)? Specifically, mostly
interested in the ACX5048 and ACX2200's

I found the following chart for the QFX line, and it was extremely helpful.
I haven't been able to find the same information for the ACX Line however:
https://www.juniper.net/documentation/en_US/junos/topics/reference/general/mpls-scaling-values-qfx-series.html


Can anyone confirm or deny if the ACX5048's hardware is identical to the
QFX5100? My understanding is they run a different JUNOS load on them, but
hardware wise they are extremely similar. On the hardware side, is there
anything in the ACX5048 that would allow more  MPLS labels in a packet’s
label stack than the QFX5100?

For the ACX line, do they support streaming telemetry? I am not sure
exactly what to look for on the streaming telemetry support for the ACX. I
basically just want to see realtime interface and optical stats. Which JTI
feature is that?

For the ACX5000, there are only 3 items listed under the Junos Telemetry
Interface section.

https://apps.juniper.net/feature-explorer/select-platform.html?category=Routing=1#family==10105000=ACX5000=20.4R1=1093=0.42180881218269106=Junos%20OS

For comparison, the QFX 5100 shows 21 different features under the JTI
Section:
https://apps.juniper.net/feature-explorer/select-platform.html?category=Switching=1#family==31705100=QFX5100=20.4R1=1093=0.566764714896294=Junos%20OS

Which feature am I looking for? Yes, I know this will require a collector
of some sort.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Juniper Healthbot

[Colton Conor]

Is anyone using the free version of Healthbot, and do you find it useful
for monitoring your network? The documentation says: HealthBot Standard
(Free)—This is the free model solution and is available for customers that
have a valid support contract. No license is required.

Are the limitations they put in place of the free version so limiting that
its not worth it until you pay for the advanced and premium options?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Junos OS Evolved

[Colton Conor]

So is Junos OS Evolved available for the MX routers? How would you go from
regular Junos to Junos OS Evolved on a MX 240/480/960 for example?

On Fri, Oct 9, 2020 at 11:38 AM Saku Ytti  wrote:

> Hey Colton,
>
> > I was unaware of Junos OS Evolved until recently. At what version did
> > regular Junos evolve into Junos OS Evolved? Is there a certain version
> > where after that version, everything ongoing is Junos OS Evolved?
>
> I think EVO appeared in 19.1, but in most cases you don't have a
> choice, you either install classic or you install evo.  New platforms
> already only have EVO options and older platforms only have classic
> options.
>
> --
>   ++ytti
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Junos OS Evolved

[Colton Conor]

I was unaware of Junos OS Evolved until recently. At what version did
regular Junos evolve into Junos OS Evolved? Is there a certain version
where after that version, everything ongoing is Junos OS Evolved?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] How to pick JUNOS Version

[Colton Conor]

How do you plan which JUNOS version to deploy on your network? Do you stick
to the KB21476 - JTAC Recommended Junos Software Versions or go a different
route? Some of the JTAC recommended code seems to be very dated, but that
is probably by design for stability.
https://kb.juniper.net/InfoCenter/index?page=content=KB21476=METADATA

Just wondering if JUNOS will ever go to a unified code model like Arista
does? The amount of PR's and bug issues in JUNOS seems overwhelming. Is
this standard across vendors? I am impressed that Juniper takes the times
to keep track of all these issues, but I am unimpressed that there are this
many bugs.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Junos Telemetry Interface

[Colton Conor]

Do you have any information on the license part numbers and the MSRP for
the licenses? Usually this is in the datasheets, but I don't see it
anywhere.

Any clarification on the free version would be appreciated.

On Tue, Apr 14, 2020 at 4:33 AM Roger Wiklund 
wrote:

> Yepp, then you have to go payed version and buy a HB license per device
> you want to monitor.
>
> /Roger
>
> On Mon, Apr 13, 2020 at 11:43 PM Colton Conor 
> wrote:
>
>> Healthbot looks interesting. However, most of our Juniper gear we buy is
>> used, so I doubt we have a support contract on it. Is healthbot still an
>> option?
>>
>> On Mon, Apr 13, 2020 at 4:22 PM Roger Wiklund 
>> wrote:
>>
>>> Hi
>>>
>>> Check out Juniper Healthbot. It can consume Netconf, SNMP, Syslog,
>>> Native and OpenConfig, also works with Cisco.
>>> Still pretty fresh product but has potential. 3.0 should be released
>>> soonish. Freemium approach where you can use basic features for free as
>>> long as you have a service contract for the device you want to monitor.
>>> Payed version has more features.
>>>
>>>
>>> https://www.juniper.net/documentation/en_US/healthbot/topics/topic-map/healthbot-rules-n-playbooks-map.html
>>>
>>> note: Some errors in the documentation above that I have flagged,
>>> OpenConfig, iAgent/Netconfig and SNMP can of course be used both inband and
>>> out of band.
>>>
>>> /Roger
>>>
>>> On Mon, Apr 13, 2020 at 11:07 PM Colton Conor 
>>> wrote:
>>>
>>>> Roger,
>>>>
>>>> Thanks for the information. It seem like most all of these
>>>> telemetry and flow solutions require service providers to build their own
>>>> solutions ontop of InfluxDB or Elasticsearch. Do you know if there are any
>>>> newer NMS platforms our there that are built ontop of InfluxDB or
>>>> Elasticsearch? Basically, we don't want to do it ourselves, and would
>>>> prefer to buy a solution. However, talking to someone like SolarWinds for
>>>> example, and they said they don't currently support streaming telemetry,
>>>> and its not on their road map at the moment?
>>>>
>>>> On Mon, Apr 13, 2020 at 3:23 PM Roger Wiklund 
>>>> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> Native sensors:
>>>>>
>>>>> https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/sensor-edit-services-analytics.html
>>>>>
>>>>> OpenConfig sensors:
>>>>>
>>>>> https://www.juniper.net/documentation/en_US/junos/topics/reference/general/junos-telemetry-interface-grpc-sensors.html
>>>>>
>>>>> Plugins to consume JTI for common open sources tools:
>>>>>
>>>>> https://www.juniper.net/documentation/en_US/junos/topics/concept/jti-opensource-plugins.html
>>>>>
>>>>> Personally I run OpenConfig with Telegraf + InfluxDB + Grafana.
>>>>>
>>>>> Telegraf has a built-in input plugin for Juniper Openconfig, so it
>>>>> takes like 5 minutes to enable.
>>>>>
>>>>> https://github.com/influxdata/telegraf/tree/master/plugins/inputs/jti_openconfig_telemetry
>>>>>
>>>>> OpenNTI is good for demo/test but not really suitable for production.
>>>>>
>>>>> /Roger
>>>>>
>>>>> On Mon, Apr 13, 2020 at 5:46 AM Aaron Gould  wrote:
>>>>>
>>>>>> You’re welcome Colton.  I understand there are 2 different ways to do
>>>>>> telemetry on Juniper.  One called Native and the other called
>>>>>> gRPC/openconfig.  I’ve done the Native form.  I think the native form is 
>>>>>> a
>>>>>> configured form where by which the network device constantly streams the
>>>>>> sensor objects… and conversely, the gRPC form is subscription based where
>>>>>> the management app/computer, subscribes to the network device to receive
>>>>>> telem data objects.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I understand the native form to be executed in hardware near the
>>>>>> monitored object….and because of this, highly scalable.And the
>>>>>> grpc/openconfig form runs on re cpu.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I don’t think w

Re: [j-nsp] Junos Telemetry Interface

[Colton Conor]

Healthbot looks interesting. However, most of our Juniper gear we buy is
used, so I doubt we have a support contract on it. Is healthbot still an
option?

On Mon, Apr 13, 2020 at 4:22 PM Roger Wiklund 
wrote:

> Hi
>
> Check out Juniper Healthbot. It can consume Netconf, SNMP, Syslog, Native
> and OpenConfig, also works with Cisco.
> Still pretty fresh product but has potential. 3.0 should be released
> soonish. Freemium approach where you can use basic features for free as
> long as you have a service contract for the device you want to monitor.
> Payed version has more features.
>
>
> https://www.juniper.net/documentation/en_US/healthbot/topics/topic-map/healthbot-rules-n-playbooks-map.html
>
> note: Some errors in the documentation above that I have flagged,
> OpenConfig, iAgent/Netconfig and SNMP can of course be used both inband and
> out of band.
>
> /Roger
>
> On Mon, Apr 13, 2020 at 11:07 PM Colton Conor 
> wrote:
>
>> Roger,
>>
>> Thanks for the information. It seem like most all of these telemetry and
>> flow solutions require service providers to build their own solutions
>> ontop of InfluxDB or Elasticsearch. Do you know if there are any newer NMS
>> platforms our there that are built ontop of InfluxDB or Elasticsearch?
>> Basically, we don't want to do it ourselves, and would prefer to buy a
>> solution. However, talking to someone like SolarWinds for example, and they
>> said they don't currently support streaming telemetry, and its not on their
>> road map at the moment?
>>
>> On Mon, Apr 13, 2020 at 3:23 PM Roger Wiklund 
>> wrote:
>>
>>> Hi
>>>
>>> Native sensors:
>>>
>>> https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/sensor-edit-services-analytics.html
>>>
>>> OpenConfig sensors:
>>>
>>> https://www.juniper.net/documentation/en_US/junos/topics/reference/general/junos-telemetry-interface-grpc-sensors.html
>>>
>>> Plugins to consume JTI for common open sources tools:
>>>
>>> https://www.juniper.net/documentation/en_US/junos/topics/concept/jti-opensource-plugins.html
>>>
>>> Personally I run OpenConfig with Telegraf + InfluxDB + Grafana.
>>>
>>> Telegraf has a built-in input plugin for Juniper Openconfig, so it takes
>>> like 5 minutes to enable.
>>>
>>> https://github.com/influxdata/telegraf/tree/master/plugins/inputs/jti_openconfig_telemetry
>>>
>>> OpenNTI is good for demo/test but not really suitable for production.
>>>
>>> /Roger
>>>
>>> On Mon, Apr 13, 2020 at 5:46 AM Aaron Gould  wrote:
>>>
>>>> You’re welcome Colton.  I understand there are 2 different ways to do
>>>> telemetry on Juniper.  One called Native and the other called
>>>> gRPC/openconfig.  I’ve done the Native form.  I think the native form is a
>>>> configured form where by which the network device constantly streams the
>>>> sensor objects… and conversely, the gRPC form is subscription based where
>>>> the management app/computer, subscribes to the network device to receive
>>>> telem data objects.
>>>>
>>>>
>>>>
>>>> I understand the native form to be executed in hardware near the
>>>> monitored object….and because of this, highly scalable.And the
>>>> grpc/openconfig form runs on re cpu.
>>>>
>>>>
>>>>
>>>> I don’t think we’ve gotten native telemetry to work on ACX.  But I have
>>>> it running on MX960’s.
>>>>
>>>>
>>>>
>>>> I understand the grpc/openconfig method requires you to download some
>>>> code/software to the network device.
>>>>
>>>>
>>>>
>>>> Collector I use is the OpenNTI project.  Grafana (web ui) (or a less
>>>> known Cronograf, which I actually use and like), InfluxDB (TSDB), fluentd,
>>>> and other components.  I must credit Dave, my coworker and resident Linux
>>>> genius in assisting my with the server side collector setup.  Some
>>>> helpful/related links below….
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> https://puck.nether.net/pipermail/juniper-nsp/2018-October/036602.html
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> https://openeye.blog/2017/06/26/using-opennti-as-a-collector-for-streaming-telemetry-from-juniper-devices-part-1/
>>>>
>>>>
>&

Re: [j-nsp] Junos Telemetry Interface

[Colton Conor]

Roger,

Thanks for the information. It seem like most all of these telemetry and
flow solutions require service providers to build their own solutions
ontop of InfluxDB or Elasticsearch. Do you know if there are any newer NMS
platforms our there that are built ontop of InfluxDB or Elasticsearch?
Basically, we don't want to do it ourselves, and would prefer to buy a
solution. However, talking to someone like SolarWinds for example, and they
said they don't currently support streaming telemetry, and its not on their
road map at the moment?

On Mon, Apr 13, 2020 at 3:23 PM Roger Wiklund 
wrote:

> Hi
>
> Native sensors:
>
> https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/sensor-edit-services-analytics.html
>
> OpenConfig sensors:
>
> https://www.juniper.net/documentation/en_US/junos/topics/reference/general/junos-telemetry-interface-grpc-sensors.html
>
> Plugins to consume JTI for common open sources tools:
>
> https://www.juniper.net/documentation/en_US/junos/topics/concept/jti-opensource-plugins.html
>
> Personally I run OpenConfig with Telegraf + InfluxDB + Grafana.
>
> Telegraf has a built-in input plugin for Juniper Openconfig, so it takes
> like 5 minutes to enable.
>
> https://github.com/influxdata/telegraf/tree/master/plugins/inputs/jti_openconfig_telemetry
>
> OpenNTI is good for demo/test but not really suitable for production.
>
> /Roger
>
> On Mon, Apr 13, 2020 at 5:46 AM Aaron Gould  wrote:
>
>> You’re welcome Colton.  I understand there are 2 different ways to do
>> telemetry on Juniper.  One called Native and the other called
>> gRPC/openconfig.  I’ve done the Native form.  I think the native form is a
>> configured form where by which the network device constantly streams the
>> sensor objects… and conversely, the gRPC form is subscription based where
>> the management app/computer, subscribes to the network device to receive
>> telem data objects.
>>
>>
>>
>> I understand the native form to be executed in hardware near the
>> monitored object….and because of this, highly scalable.And the
>> grpc/openconfig form runs on re cpu.
>>
>>
>>
>> I don’t think we’ve gotten native telemetry to work on ACX.  But I have
>> it running on MX960’s.
>>
>>
>>
>> I understand the grpc/openconfig method requires you to download some
>> code/software to the network device.
>>
>>
>>
>> Collector I use is the OpenNTI project.  Grafana (web ui) (or a less
>> known Cronograf, which I actually use and like), InfluxDB (TSDB), fluentd,
>> and other components.  I must credit Dave, my coworker and resident Linux
>> genius in assisting my with the server side collector setup.  Some
>> helpful/related links below….
>>
>>
>>
>>
>>
>> https://puck.nether.net/pipermail/juniper-nsp/2018-October/036602.html
>>
>>
>>
>>
>>
>>
>> https://openeye.blog/2017/06/26/using-opennti-as-a-collector-for-streaming-telemetry-from-juniper-devices-part-1/
>>
>>
>>
>>
>>
>>
>> https://www.juniper.net/documentation/en_US/junos/topics/concept/junos-telemetry-interface-oveview.html
>>
>> look under “telemetry sensors and data models”
>>
>>
>>
>>
>>
>>
>> https://community.grafana.com/t/how-to-send-juniper-router-telemetry-to-grafana/11071/9
>>
>>
>>
>>
>>
>> -Aaron
>>
>>
>>
>>
>>
>> From: Colton Conor [mailto:colton.co...@gmail.com]
>> Sent: Saturday, April 11, 2020 9:05 AM
>> To: Aaron Gould
>> Cc: Juniper List
>> Subject: Re: [j-nsp] Junos Telemetry Interface
>>
>>
>>
>> Aaron,
>>
>>
>>
>> Thanks, this is indeed helpful. What collector are you using to store and
>> view this telemetry data? Also, have you had any luck with getting JTI to
>> work on your ACX gear? This only JTI feature is see for the ACX line
>> according to the feature explorer is:
>> https://apps.juniper.net/feature-explorer/feature-info.html?fKey=8978 <
>> https://apps.juniper.net/feature-explorer/feature-info.html?fKey=8978=Specify%20Routing%20Instance%20for%20JTI>
>> =Specify%20Routing%20Instance%20for%20JTI I am not sure if that means it
>> fully supports JTI or not.
>>
>>
>>
>>
>>
>> On Fri, Apr 10, 2020 at 11:53 AM Aaron Gould  wrote:
>>
>> Not sure if this is what you are looking for, but here are some of the
>> sensor agents that I enabled on my MX routers
>>
>> Maybe it's the linecard or interface specific ones that give me the bi

[j-nsp] Juniper Networks AppFormix

[Colton Conor]

Is anyone using Juniper Networks® AppFormix, and what are your thoughts on
the platform? How does it compare to a more traditional NMS such as
SolarWinds?

How much does Juniper Networks® AppFormix cost? I can't seem to find
pricing on licencing this platform.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Junos Telemetry Interface

[Colton Conor]

Aaron,

Thanks, this is indeed helpful. What collector are you using to store and
view this telemetry data? Also, have you had any luck with getting JTI to
work on your ACX gear? This only JTI feature is see for the ACX line
according to the feature explorer is:
https://apps.juniper.net/feature-explorer/feature-info.html?fKey=8978=Specify%20Routing%20Instance%20for%20JTI
I
am not sure if that means it fully supports JTI or not.


On Fri, Apr 10, 2020 at 11:53 AM Aaron Gould  wrote:

> Not sure if this is what you are looking for, but here are some of the
> sensor agents that I enabled on my MX routers
>
> Maybe it's the linecard or interface specific ones that give me the bits in
> bits out utilization graphs.
>
> set services analytics sensor my-sensor-14 server-name my-grafana-srvr
> set services analytics sensor my-sensor-14 export-name my-exprt-prfl
> set services analytics sensor my-sensor-14 resource
> /junos/system/linecard/interface/
> set services analytics sensor my-sensor-1 server-name my-grafana-srvr
> set services analytics sensor my-sensor-1 export-name my-exprt-prfl
> set services analytics sensor my-sensor-1 resource
> /junos/system/linecard/packet/usage/
> set services analytics sensor my-sensor-2 server-name my-grafana-srvr
> set services analytics sensor my-sensor-2 export-name my-exprt-prfl
> set services analytics sensor my-sensor-2 resource
> /junos/system/linecard/cpu/memory/
> set services analytics sensor my-sensor-12 server-name my-grafana-srvr
> set services analytics sensor my-sensor-12 export-name my-exprt-prfl
> set services analytics sensor my-sensor-12 resource
> /junos/system/linecard/fabric/
> set services analytics sensor my-sensor-15 server-name my-grafana-srvr
> set services analytics sensor my-sensor-15 export-name my-exprt-prfl
> set services analytics sensor my-sensor-15 resource
> /junos/system/linecard/interface/logical/usage/
> set services analytics sensor my-sensor-17 server-name my-grafana-srvr
> set services analytics sensor my-sensor-17 export-name my-exprt-prfl
> set services analytics sensor my-sensor-17 resource
> /junos/system/linecard/npu/memory/
> set services analytics sensor my-sensor-18 server-name my-grafana-srvr
> set services analytics sensor my-sensor-18 export-name my-exprt-prfl
> set services analytics sensor my-sensor-18 resource
> /junos/system/linecard/npu/utilization/
> set services analytics sensor my-sensor-19 server-name my-grafana-srvr
> set services analytics sensor my-sensor-19 export-name my-exprt-prfl
> set services analytics sensor my-sensor-19 resource
> /junos/system/linecard/optics/
> set services analytics sensor my-sensor-21 server-name my-grafana-srvr
> set services analytics sensor my-sensor-21 export-name my-exprt-prfl
> set services analytics sensor my-sensor-21 resource
> /junos/system/linecard/services/inline-jflow/
> set services analytics sensor my-sensor-13 server-name my-grafana-srvr
> set services analytics sensor my-sensor-13 export-name my-exprt-prfl
> set services analytics sensor my-sensor-13 resource
> /junos/system/linecard/firewall/
>
> -Aaron
>
> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> Of
> Colton Conor
> Sent: Thursday, April 9, 2020 3:25 PM
> To: Juniper List
> Subject: [j-nsp] Junos Telemetry Interface
>
> Instead of monitoring Juniper equipment by SNMP with 5 minute polling we
> would like to use streaming telemetry to monitor the devices in real-time.
> This requires the Junos Telemetry Interface.
>
> Looking in the Juniper Feature Explorer, Junos Telemetry Interface is not a
> feature, but rater a whole category in the feature explorer, with multiple
> features under it. What feature am I looking for to be able to monitor the
> interfaces in real-time, and see how much bandwidth flows across them
> similar to SNMP?
>
> The ACX platforms only support the Specify Routing Instance for JTI
> feature?
> ___
> 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] Junos Telemetry Interface

[Colton Conor]

Instead of monitoring Juniper equipment by SNMP with 5 minute polling we
would like to use streaming telemetry to monitor the devices in real-time.
This requires the Junos Telemetry Interface.

Looking in the Juniper Feature Explorer, Junos Telemetry Interface is not a
feature, but rater a whole category in the feature explorer, with multiple
features under it. What feature am I looking for to be able to monitor the
interfaces in real-time, and see how much bandwidth flows across them
similar to SNMP?

The ACX platforms only support the Specify Routing Instance for JTI
feature?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX5448 & ACX710

[Colton Conor]

Mark,

So which box is best to just get customers a simple IP, but has all the
management and metro-e requirements you need?



On Fri, Jan 24, 2020 at 1:53 AM Mark Tinka  wrote:

>
>
> On 24/Jan/20 08:49, Saku Ytti wrote:
>
> >
> > When we asked JNPR why Jericho instead of Paradise, as we see these
> > chips for the same market, JNPR told that main motivation was OAM
> > features which they lack in Paradise but need in metro.
>
> The OAM story came up as well, as being the major improvements from
> Trident to Jericho.
>
> If I'm honest, given that everything has gone IP + Cloud, the demand for
> VPN's - as we've known them - is no longer there, really. Well, at least
> in our market anyway. At which point we introduce the fresh buzzword for
> 2020 - "SD-WAN". Oooh, but don't forget, we now have "SD-LAN" and
> "SD-WLAN". Just keeps getting better and better.
>
> In short, we don't really have a huge OAM demand simply because our
> customers just want simple IP. They just want to get to their Instagram.
>
> 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] ACX5448 & ACX710

[Colton Conor]

What is Cisco's upgrade path from the ASR920 if you need more 10G ports?

On Thu, Jan 23, 2020 at 2:52 PM Mark Tinka  wrote:

>
>
> On 23/Jan/20 16:00, Shamen Snyder wrote:
>
> > I have been following the ACX 710 for a while now. We have a use case
> > in rural markets where we need a dense 10G hardened 1 RU box.
> >
> > Looks like a promising box, hope the price is right. If not we may
> > have to jump to Cisco ASR920s
>
> If I'm honest, what I've noticed with most traditional vendors selling
> Broadcom-based boxes is they are touting "price" as the killer use-case
> for those boxes. For me, I'm not unwilling to spend a little bit more if
> I can sleep at night knowing I have data plane parity between a
> Broadcom-based box and an in-house-based box from the same traditional
> vendor.
>
> But time and time again, almost like clockwork, Broadcom-based boxes are
> being marketed as "Multi-Gigabit" and "Multi-Terabit" platforms with a
> gazillion ports at half the price of the "normal" box. What good is all
> that hardware if a simple feature doesn't work as I've known it to
> before "enhancing my network"?
>
>
> >
> > 4 100/40G (can be channelized to 4x25G or 4x10G) interfaces, 24 1/10G
> > interfaces. Broadcom QAX chipset. 320Gbps of throughput. 3GB buffer.
>
> What I saw about the ACX710 is it has a small FIB. Since we are used to
> filtering what enters our ASR920 FIB (and the ACX710 has about 12.8
> times that), that's not a show-stopper.
>
> 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] ACX5448 & ACX710

[Colton Conor]

We too have the ACX5048 and QFX5100's, and have been unhappy with them
both. They both have the same Trident II chip set, but run different code
which is annoying to say the least.  Not to mention these aren't really
built for Metro-E deployments. They are not hardened, so datacenter only.
Plus, the don't support 23 inch racks nor 2 post racks. Makes them hard to
put in a customers site.

I looked at the ASR920 just now, it has too few 10G ports on it. The NCS
540 seems to be more ideal for our needs. Does the NCS 540 fit the bill?

On Wed, Jan 22, 2020 at 10:05 AM Alexandre Guimaraes <
alexandre.guimar...@ascenty.com> wrote:

> Mark and gents.
>
> Juniper really doesn't care about Metro services, since ACX5048,
> "The Promissed" equipment that was ready to solve our problems regarding
> port density and functions, but... ACX5048 doesn't work as expected as
> Giuliano said(Giuliano is my SE), We brought some ACX5048... in less than a
> month of operation, we remove those box from network, they became a layer2
> switch only. So Juniper release the new ACX, but the problems still the
> same.
>
> From my perspective, they don't have time to develop a good
> software and they just release anything for us thinking that someday, they
> will correct the software of the new hardwar, and we will be happy, but
> they just forget that we provide services and we have SLA. I have my
> personal cents about this subject...
>
> MX, maybe, is the most stable hardware/software that they had in
> this moment. But there is no good density of ports, or we had to choose
> what type of ports we had to work on with, I can't accept this, a
> MPC7E-MRATE working with only 4 100Gb ports... (aahhh this is because de
> backplane bla bla bla bla) hardware release with bad development to run
> against market... to not lose the market.
>
> Other problem that I have here, is with QFX5100 platform, using a
> functionality(version 14.1X53-D35.3), that they remove at the newest
> release software, and, they(Juniper) don't had solution for that and, they
> really don't care
>
> Now I have a big problem in large scale, since I have hundreds of
> QFX5100, can't upgrade due that, and JTAC don't support that old release
> anymore.
>
> And, I don't want to talk about QFX5120 deception...
>
>
> This is my cent, and my feelings about.
>
>
> Att
> Alexandre
>
>
> Em 22/01/2020 12:41, "juniper-nsp em nome de Mark Tinka" <
> juniper-nsp-boun...@puck.nether.net em nome de mark.ti...@seacom.mu>
> escreveu:
>
>
>
> On 22/Jan/20 17:17, Eric Van Tol wrote:
>
> >
> > Which is something many of us smaller providers have been begging
> them for YEARS to make. Hopefully it doesn't have restrictions on port
> configurations like the MX204 or weird filtering limitations like the
> original ACX boxes. The ASR920 is popular for a reason - they are
> rock-solid, offered decent port configurations, sensible and reasonably
> priced licensing, small form-factor and features decent enough for an
> access MPLS device.
>
> And, custom silicon that does, pretty much, what you're used to seeing
> on IOS XE boxes.
>
> Juniper, I've realized, are really not interested in the Metro-E space.
> I know it's great to think merchant silicon is the answer to get into
> that space, but it doesn't look to me like they will be bother the
> ASR920 anytime soon.
>
> Mark.
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=d3qAF5t8mugacLDeGpoAguKDWyMVANad_HfrWBCDH1s=TU6hC3CmliVPupj04_YNYHTF5VVsspISdyOjUEnr2TM=r-fSdwLUay6e6rXEc7nibhLO1FNxOw1U62KPIFpFeF4=
>
>
> ___
> 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] l2circuit between QFX-5110 & MX204 - one way traffic

[Colton Conor]

Liam,

Did you ever get this worked out?

On Thu, Jul 18, 2019 at 12:25 PM Philippe Girard <
philippe.gir...@metrooptic.com> wrote:

> Hello
>
> Some important information:
>
> Top level encapsulation flex-eth and flex-vlan-tagging is not supported on
> QFabric (QFX family) devices. That means you can't use a port that does ccc
> with any other type of encap, i.e. vlan-bridge, ext-vlan-br, or set family
> inet on a unit. Only MX with trio chipset can do that. If you did at *any
> other point* configure some other units on there with different encaps,
> traffic will remain one way. There is also a PR on the use of flex stuff on
> QFX that states that at some points labels are not getting programmed
> properly and circuit will stop working.
>
> You don't need family ccc in the unit, only encap vlan-ccc
>
> You should remove and RSVP-TE and static LSP config that you have to start
> fresh and make it work only with LDP, then add complexity.
>
> The pop/push operation on the unit is there to get a pure ethernet frame
> to slap the LDP tag onto and possibly deliver untagged on the other side.
> It's not necessary if you also deliver on a simple tagged unit on the other
> side. The difference in the core network will be between ETHERNET-CCC and
> VLAN-CCC. You don't need to force the encasulation type in config, this is
> automatic from what you set on both sides.
>
> Also, don't do ignore-mtu, but set the mtu to what you want as a value
> lower than the physical interface mtu, the same on both sides.
>
> I don't think QFX supports control-word.
>
> Examples of what works:
>
> Xe-X
> vlan-tagging;
> mtu 9216;
> encapsulation vlan-ccc;
> unit 538 {
> encapsulation vlan-ccc;
> no-traps;
> vlan-id 538;
> input-vlan-map pop;
> output-vlan-map push;
> }
>
> interface xe-0/0/36.538 {
> virtual-circuit-id 13911065;
> no-control-word;
> mtu 9000;
> }
>
> If you do use pop/push on the unit, make sure it's there on both sides.
> You can also deliver untagged on the other side by doing something like
> this. It will push the frame out untagged since you removed it accepting
> the packet initially. Keep in mind this dedicates the port to that service.
>
> mtu 9216;
> encapsulation ethernet-ccc;
> unit 0 {
> no-traps;
> family ccc;
> }
>
> interface xe-0/0/12.0 {
> virtual-circuit-id 1385956;
> no-control-word;
> mtu 9000;
> }
>
> MX can have top flex-ethernet and flex-vlan tagging and mix and match
> stuff. For the rest, config must stay the same.
>
> Keep your stuff simple, leave as much as you can to the system to figure
> out unless you absolutely need to force.
>
> Cheers.
>
> -Original Message-
> From: juniper-nsp  On Behalf Of Liam
> Farr
> Sent: July 18, 2019 11:26 AM
> To: Heng Chai, Tan 
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] l2circuit between QFX-5110 & MX204 - one way traffic
>
> Hi,
>
> Tried as follows;
>
> liam@NA-QFX5110-1# show interfaces xe-0/0/9 description "Temp Link to
> Arista"; vlan-tagging; mtu 9216; encapsulation flexible-ethernet-services;
> unit 123 {
> encapsulation vlan-ccc;
> vlan-id 123;
> input-vlan-map pop;
> output-vlan-map push;
> family ccc;
> }
>
> liam@NA-QFX5110-1# show protocols l2circuit neighbor 192.168.68.3 {
> interface xe-0/0/9.123 {
> virtual-circuit-id 123;
> no-control-word;
> ignore-mtu-mismatch;
> pseudowire-status-tlv;
> }
> }
>
> liam@WN-MX204-1# show interfaces xe-0/1/3 description "ISPCO-WN-PVE-1
> C0/F3 enp6s0f1"; flexible-vlan-tagging; mtu 9216; encapsulation
> flexible-ethernet-services; unit 123 {
> encapsulation vlan-ccc;
> vlan-id 123;
> input-vlan-map push;
> output-vlan-map pop;
> family ccc;
> }
>
> liam@WN-MX204-1# show protocols l2circuit neighbor 192.168.68.5 {
> interface xe-0/1/3.123 {
> virtual-circuit-id 123;
> no-control-word;
> ignore-mtu-mismatch;
> pseudowire-status-tlv;
> }
> }
>
> When I removed the l2circuit encapsulation altogether from both ends I got
> an EM -- encapsulation mismatch on the l2circuit
>
> I also tried encapsulation internetworking / ethernet-vlan / ethernet
>
>
> At some point I did get mac learning both ways in that at the QFX end I
> could see mac from the MX end, but haven't successfully managed to pass
> icmp / ping.
>
>
> NA-ARISTA#show mac address-table vlan 123
>   Mac Address Table
> --
>
> VlanMac Address   TypePorts  Moves   Last Move
> ---   -  -   -
>  1233606.b737.b463DYNAMIC Et91   0:18:11 ago
>  1236c3b.6bf0.9b0fDYNAMIC Et41   8:55:37 ago
> Total Mac Addresses for this criterion: 2
>
>
>   Multicast Mac Address Table
> --
>
> VlanMac Address   Type   

Re: [j-nsp] 40Gig Ether for MX480

[Colton Conor]

John did you google this?
https://www.juniper.net/documentation/en_US/release-independent/junos/topics/reference/general/mic-mx-series-40-gigabit-ethernet-qsfp.html


On Thu, Jul 18, 2019 at 5:59 PM John Brown  wrote:

> Hi,
> I have a client that is wanting a 40Gig ether handoff.   What would
> folks recommend for
> an interface on a MX480 system?
>
> The customer is also asking if we need to handle G.709 FEC
>
> Thoughts and tips appreciated.
>
> --
> Respectfully,
>
> John Brown, CISSP
> Managing Member, CityLink Telecommunications NM, LLC
> ___
> 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] Link establishment issues with 1Gbps SX/LX SFPs on QFX5110

[Colton Conor]

Do you know when this will be fixed in the mainline releases? I have no
clue what  3.5R1-S4.1 is?

On Fri, Jun 28, 2019 at 2:22 PM Timothy Creswick 
wrote:

> For anyone interested in this, JTAC released to us 3.5R1-S4.1 for the
> satellite devices (I don't believe this will be generally available until
> tomorrow). This addresses the issue and confirms that there were 2 or 3
> different PRs relating to the Broadcom chipset being incorrectly programmed
> by Junos.
>
> Some output, testing with a variety of 1Gbps optics (coded SX, LX, uncoded
> BX, LX and SX).
>
> > show chassis hardware satellite
> Hardware inventory:
> Item Version  Part number  Serial number Description
> FPC 100  REV 27   650-061152   WS37183X  QFX5110-48S-4C
>   PIC 0  REV 27   650-061152   WS37183X  48x10G-4x100G
> Xcvr 0   850nm740-011782   F--X  SFP-SX
> Xcvr 2   1310nm   740-011783   F--X  SFP-LX10
> Xcvr 4NON-JNPR VS51208X
> SFP-1000BASE-BX10-D
> Xcvr 6NON-JNPR VS60930X  SFP-LX10
> Xcvr 8NON-JNPR VS50930X  SFP-SX
>
> > show interfaces ge-100/0/[02468] terse
> Interface   Admin Link ProtoLocal Remote
> ge-100/0/0  upup
> ge-100/0/2  upup
> ge-100/0/4  upup
> ge-100/0/6  upup
> ge-100/0/8  upup
>
> > show configuration interfaces
> ge-100/0/0 {
> unit 0;
> }
> ge-100/0/2 {
> unit 0;
> }
> ge-100/0/4 {
> unit 0;
> }
> ge-100/0/6 {
> unit 0;
> }
> ge-100/0/8 {
> unit 0;
> }
>
> # bcmshell ps 1,3,5,7,9
>
> HW (unit 0)
>  ena/speed/ link autoSTP  lrn
> inter   max  loop
>port  linkduplex scan neg?   state   pause  discrd ops
>  face frame  back
>ge0(  1)  up  1G  FD   HW  Yes  Forward  NoneF
>  GMII  1518
>ge1(  3)  up  1G  FD   HW  Yes  Forward  NoneF
>  GMII  1518
>ge2(  5)  up  1G  FD   HW  Yes  Forward  NoneF
>  GMII  1518
>ge3(  7)  up  1G  FD   HW  Yes  Forward  NoneF
>  GMII  1518
>ge4(  9)  up  1G  FD   HW  Yes  Forward  NoneF
>  GMII  1518
>
> We note that now changing the auto-negotiate state in Junos correctly
> updates the underlying chipset and link negotiation works correctly.
> Interface is shown as GMII which we understand to be correct also.
>
> All-in, pretty terrible that - as far as we can tell - 1Gbps ports have
> *never worked* on QFX5110 properly in all the four basic combinations (i.e.
> SX and LX at both auto- and no-auto negotiation) until this release. Quite
> how Juniper have been shipping the hardware for so long in that state is a
> mystery to me.
>
>
> Tim
> ___
> 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] acx5048 message - fpc0 brcm_pkt_fp_thread

[Colton Conor]

Aaron,

What version are you running on?

On Mon, Dec 10, 2018 at 4:07 PM Aaron Gould  wrote:

> Wanted to circle back with y'all... this message...
>
> fpc0 brcm_pkt_fp_thread:700 FP thread is unscheduled for more than 30ms.
> Sleep time: 44ms.^M
>
> ...seemed to be coupled with, or somewhat related to other messages seen
> within a 12 hour period of...
>
> Nov 28 12:30:10  my-ACX5048 /kernel: swapping out newsyslog[80273] target:
> 12979 free: 8908
> Nov 28 12:30:10  my-ACX5048 /kernel: swapping out sh[80271] target: 12979
> free: 8908
> Nov 28 12:30:10  my-ACX5048 /kernel: swapping out smihelperd[1722] target:
> 12979 free: 8908
> Nov 28 12:30:10  my-ACX5048 /kernel: swapping out pmond[1720] target: 12979
> free: 8908
> Nov 28 12:30:10  my-ACX5048 /kernel: swapping out tnp.sntpd[1712] target:
> 12979 free: 8908
> ...several others
> Nov 28 12:30:10  my-ACX5048 /kernel: swapping out sdk-mgmtd[1562] target:
> 12979 free: 8908
> Nov 28 12:30:10  my-ACX5048 /kernel: swapping out inetd[1558] target: 12979
> free: 8908
> Nov 28 12:30:10  my-ACX5048 /kernel: swapping out mgd[1557] target: 12979
> free: 8908
> Nov 28 12:30:10  my-ACX5048 /kernel: swapping out watchdog[1553] target:
> 12979 free: 8908
> Nov 28 12:30:10  my-ACX5048 /kernel: swapping out cron[1472] target: 12979
> free: 8908
>
>
> ...interestingly, when I saw these messages, there was occasions about
> 10-12
> hours later, serious customer-affecting issues on a couple of my
> ACX5048's... hard to telnet/ssh to it, customer complaints, etc.
>
> Btw, we saw memory ramping up on these ACX5048's over a years time,
> gradually in an ever-increasing manner... looking much like a memory
> leaking
> process
>
> Much appreciation to the Juniper JTAC for finding jdhcpd with "show system
> processes extensive no-forwarding" and then instructing me to bounce it
> with
> "restart dhcp-service gracefully"
>
> Whew.  Memory was released immediately!  From 85% to 50%.  That'll buy me
> some time to work on upgrading Junos to a fix version/jtac recommended
> release.
>
> - Aaron
>
> ___
> 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] Junos Telemetry Interface (JTI)

[Colton Conor]

Guys,

I wanted to follow up and see how things are going with JTI?

Also, it has been brought to my attention that OpenNMS supports JTI. I was
not aware of that, so I figured I would share with others:
https://docs.opennms.org/opennms/branches/develop/guide-admin/guide-admin.html#ga-telemetryd


On Thu, Oct 11, 2018 at 12:24 PM Aaron1  wrote:

> Yes Niall, lets stay in touch.
>
> Thanks Tom, I’ll have to look at Panoptes
>
> Aaron
>
> > On Oct 11, 2018, at 8:18 AM, Tom Beecher  wrote:
> >
> > Related, my company open sourced a tool we've been working on for
> network telemetry at NANOG in Vancouver. I'm 95% sure that a JTI receiver
> is functional on our internal builds, but they're still working on a few
> things with streaming receivers generally, so it's not yet in the public
> repo. May be something that can meet your needs at some point if you wanted
> to keep an eye on it.
> >
> > https://github.com/yahoo/panoptes
> >
> >> On Thu, Oct 11, 2018 at 9:02 AM Niall Donaghy 
> wrote:
> >> Fantastic news Aaron!
> >>
> >> That tallies with our experience of deploying the 'bundle' version of
> OpenNTI
> >> for Junos ST.
> >>
> >> We look forward to your shared experiences as you kick the tyres and -
> >> hopefully - incorporate this into your NMS/procedures. :)
> >>
> >> Many thanks,
> >> Niall
> >>
> >>
> >> -----Original Message-
> >> From: Aaron Gould [mailto:aar...@gvtc.com]
> >> Sent: 11 October 2018 13:59
> >> To: juniper-nsp@puck.nether.net
> >> Cc: James Burnett ; Niall Donaghy
> >> ; 'Colton Conor' 
> >> Subject: RE: [j-nsp] Junos Telemetry Interface (JTI)
> >>
> >> Wanted to circle back with y'all... I finally got this working...thanks
> to
> >> techmocha10 (see below) and my linux coworker genius (Dave),
> >>
> >> I'll just copy/paste a post I just made...
> >>
> >>
> https://forums.juniper.net/t5/vMX/Telemetry-data-is-not-streaming-from-Juniper-vMX-17-4R1-16/m-p/375996#M923
> >>
> >>
> >> I got telemetry streaming working using this site ... I have a couple
> MX960's
> >> streaming telemetry to the suite of software provided in this Open-NTI
> project
> >> spoken of on this techmocha blog site.  I think my previous problems
> were
> >> related to conflicting installs as myself and my coworker had
> loaded
> >> individual items and then the open-nti suite (which i understand is a
> docker
> >> container with all the items like grafana, fluentd, chronograf,
> influxdb,
> >> etc) anyway, we started with a fresh install Ubunto virtual machine
> and
> >> *only* loaded Open-NTI and it works.
> >>
> >>
> >> I do not know or understand all of the innerworkings of it at this
> point, but
> >> am quickly learning, even while writing this post... I'm currently
> using
> >> Chronograf hosted at port  and browsing the Data Explorer function
> and
> >> seeing some nice graphs.  (I'm wondering if Chrongraf is simply an
> alternative
> >> to Grafana gui front end, unsure) There seems to be tons of items to
> monitor
> >> and analyze, and I'm currently only sending the following sensor
> resource from
> >> the MX960 and there are several more that can be sent
> >> /junos/system/linecard/interface/
> >>
> >>
> >> I am sending the telemetry from the MX960 using UDP transport and GPB
> format
> >> to port 5 and source port 2 (mx960-1) and 21112 (mx960-2).  I'm
> unsure
> >> that I had to use unique source ports... as I wonder if the source-ip
> would
> >> have been sufficient to make the streaming sources unique in the
> Open-NTI
> >> server.
> >>
> >>
> >> Looking at the techmocha pictures, and the "docker ps" command on the
> linux
> >> server, and now this new-found techmocha link (see "deconstructed"
> below)
> >> apparently FluentD is the TSDB (time series db) that is
> receiving/ingesting
> >> the *Native* streaming form of telemetry from my MX960's on udp port
> 5 and
> >> looks like fluentd hands off that data to InfluxDB port 8086 (which i
> think
> >> happens internally at that server).  (I'm not evening talking about the
> other
> >> form of jti telemetry using openconfig and grpcI've yet to do that
> and
> >> don't know why I would exactly...which i beleive is ingested using
> telegraf,
> >&g

[j-nsp] Inline Active Flow Monitoring IPFIX vs Junos Telemetry Interface (JTI)

[Colton Conor]

What is the difference between the Inline Active Flow Monitoring using
IPFIX compared to the Junos Telemetry Interface (JTI)?

Both of these seem to be a push technology that pushes data to a collector
vs a pull data model like SNMP which is good. But what is the difference
between the two? I know Junos Telemetry Interface (JTI) is newer and not as
well supported across Juniper devices.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper Buffer Bloat

[Colton Conor]

Benny,

So does putting an in-line X86 box that supports FQ-Codel before the DSLAM
solve the problem in your point of view? It would have to know for each
subscriber what their speed was of course to do the proper rate limiting.
If this device did rate limiting both on downstream and upstream would
there be any reason to also have a fq-codel enabled CPE?

Are there any commercial vendors that use FQ-codel in their products since
Juniper clearly does not?

On Thu, Oct 18, 2018 at 10:01 AM Benny Lyne Amorsen 
wrote:

> James Bensley  writes:
>
> > It is actually enough to use fq-codel on the CPE only, to fix
> > bufferbloat, nothing is required on the provider side, that is the
> > whole point, the CPE buffers are too large, so fq-codel in the core
> > doesn't make sense as there should be minimal bufferbloat there.
>
> The CPE can't do anything if a large flow fills up the pipe. If the
> packets are dropped before the CPE sees them, it does not get to pick
> which ones are nice and which ones aren't. It can hope that the "bad"
> flow happens to be TCP so the packet loss induced by fq-codel causes it
> to back off, but it might not be.
>
> > A by-product of using fq-codel on the CPE (because it is both AQM and
> > packet scheduling combined!) is that when you configure it and
> > configure it to ~99% of the actual speed UP and DOWN it will actually
> > have positive effects on both upload and download before either your
> > PE policer kicks in or the WAN link drops packets due to congestion,
> > the PE doesn't need to do anything.
>
> Again, that is great if your flows are well-behaved TCP or rate-adapting
> UDP.
>
> > Unless my understanding is wrong, fq-codel schedules the outbound
> > packets and will allow you to fill your link in the downstream with
> > multiple concurrent IP flows without anyone of them being starved by
> > another.
>
> As long as the flows react well to packet loss.
>
> > My own tests confirmed this on my home ADSL, I could smash
> > the link with torrents and still watch NetFlix without issue. There
> > are some examples you can see here:
> > https://www.bufferbloat.net/projects/codel/wiki/RRUL_Rogues_Gallery/
>
> I do not doubt that you can get very far by shaping at the wrong end of
> the link. You absolutely can. But it means you depend on a) knowing the
> constant speed of the link and b) your flows being nice.
>
> It cannot work reliably if there is WAN-side congestion, which makes it
> less useful for cable or (non-point-to-point) wireless networks. In
> those cases, fq-codel on the CPE side will believe that the downstream
> pipe still has room, so it will not throttle the flows.
>
>
> /Benny
>
> ___
> 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] Juniper Buffer Bloat

[Colton Conor]

I am sorry I didn't mean to start an argument on the list.

For clarification, the DSLAM uplinks (10G) and backplane doesn't have a
limit that we are hitting. However, the CO DSL ports is the first place
where there is a limit. Example

10G Internet Connect ---> 10 G Port on Juniper MX204 > 10G Uplink
on Adtran TA 5K DSLAM -20Mbps Download / 1Mbps upload DSL
Connection>Customer DSL Modem in Bridge Mode>1G Ethernet Wan Router

In this scenario, I bottleneck would be the 20Mbps port on the DSLAM in the
central office. That is where the buffers would start to build up for
downstream traffic right? On the upstream side, traffic would start to
buffer on the Customers DSL modem? In both secenatios, the DSLAM and
Customer's DSL modem have limited knobs to modify, so if I wanted to
implement something like fq-codel it would have to be done before the DSLAM
for downstream traffic, and after the DSL modem for upstream traffic right?
Ideally I would like to rate limit both up and downstream before the DSLAM
as we don't always have control of the CPE equipment.







On Thu, Oct 18, 2018 at 7:02 AM James Bensley  wrote:

> On Thu, 18 Oct 2018 at 10:36, Benny Lyne Amorsen
>  wrote:
> >
> > James Bensley  writes:
> >
> > > If customers have WAN links that are slower than their LAN links -
> > > that is where fq-codel was designed to be implemented and that is why
> > > it should be implemented on the CPE. Let's be clear because to me
> > > there is no place for it in the core:
> > >
> > > If your customers have a WAN link that is slower than their LAN
> > > connectivity the congestion occurs on the WAN link and this is why
> > > fq-codel works best on the CPE WAN interface (you would normally shape
> > > the CPE WAN interface to just below the WAN link speed and use
> > > fq-codel for queuing so that it kicks in before you hit the WAN link
> > > speed and start dropping packets, the CPE has visibility of the WAN
> > > interface usage and buffer usage).
> >
> > This is great for upstream traffic, as seen from the customer. It is the
> > wrong solution for the downstream. Downstream you need the PE or the
> > DSLAM to do the right thing, or you will be shaping traffic AFTER the
> > bottleneck, with all the usual problems of that approach.
>
> Hi Benny,
>
> This is not correct. Again we are being unclear here (maybe my
> fault!). What I was saying above was:
>
> > > If your customers have a WAN link that is slower than their LAN
> > > connectivity the congestion
>
> Should have been bufferbloat ^
>
> > > occurs on the WAN link and this is why
> > > fq-codel works best on the CPE WAN interface (you would normally shape
> > > the CPE WAN interface to just below the WAN link speed and use
> > > fq-codel for queuing so that it kicks in before you hit the WAN link
> > > speed and start dropping packets, the CPE has visibility of the WAN
> > > interface usage and buffer usage).
>
> The OP asked about fq-codel in Juniper tin for bufferbloat. When using
> fq-codel (in my experience which was my home ADSL line with OpenWRT
> router) one has to tell fq-codel the link speed (so as I said above,
> you set it to slightly lower than your link speed so that it kicks in
> before packets are dropped). It is actually enough to use fq-codel on
> the CPE only, to fix bufferbloat, nothing is required on the provider
> side, that is the whole point, the CPE buffers are too large, so
> fq-codel in the core doesn't make sense as there should be minimal
> bufferbloat there. As Saku mentioned buffers should be kept small
> inside your provider network, this is a great short video on this
> subject: https://www.youtube.com/watch?v=y3mkhUq-cO4
>
> A by-product of using fq-codel on the CPE (because it is both AQM and
> packet scheduling combined!) is that when you configure it and
> configure it to ~99% of the actual speed UP and DOWN it will actually
> have positive effects on both upload and download before either your
> PE policer kicks in or the WAN link drops packets due to congestion,
> the PE doesn't need to do anything. Unless my understanding is wrong,
> fq-codel schedules the outbound packets and will allow you to fill
> your link in the downstream with multiple concurrent IP flows without
> anyone of them being starved by another. My own tests confirmed this
> on my home ADSL, I could smash the link with torrents and still watch
> NetFlix without issue. There are some examples you can see here:
> https://www.bufferbloat.net/projects/codel/wiki/RRUL_Rogues_Gallery/
>
> 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] Juniper Buffer Bloat

[Colton Conor]

So what kind of classification queues do you use for the customer traffic
assuming its all just best effort internet traffic?


So what do you think about an inline X86 sever running linux with fq-codel
installed before the Multi-service access node? That is basically what
preseem.com is doing for the wireless isp market.



On Wed, Oct 17, 2018 at 6:30 PM Benny Lyne Amorsen 
wrote:

> Colton Conor  writes:
>
> > Benny,
> >
> > Great information! So what would you do to avoid congest on access
> > networks? Example DSLAM's fed by 10G links. The 10G link is no where near
> > capacity, but customers are individually maxing out their 20Mbps by 1Mbps
> > DSL connection. Would you use DPI, fq-codel, or something else?
>
> The approach $dayjob went with is to classify customer traffic into 3
> queues plus one for network control, and then do RED with a size-limited
> queue per subif. It works well  when traffic gets classified
> correctly. Tuning RED is challenging and it is tempting to increase
> buffer size to give RED a bit more of a chance to react smoothly.
>
> Even so, one aggressive flow can be quite detrimental to everything else
> in the samme traffic class.
>
> fq-codel would achieve better results with much less work.
>
>
> /Benny
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper Buffer Bloat

[Colton Conor]

Benny,

Great information! So what would you do to avoid congest on access
networks? Example DSLAM's fed by 10G links. The 10G link is no where near
capacity, but customers are individually maxing out their 20Mbps by 1Mbps
DSL connection. Would you use DPI, fq-codel, or something else? Yes, we
know about DSL bonding, GPON, and other access technologies that provide
more speed, but that is not always economically viable.



On Wed, Oct 17, 2018 at 5:57 PM Benny Lyne Amorsen 
wrote:

> Colton Conor  writes:
>
> > I am more wondering how to do this properly on the provider edge
> > side. I mentioned backbone/core before, and I really meant to say
> > provider edge. On the provider edge, that is mostly Juniper, so we
> > can't just implement fq-codel. So the question lines does Juniper have
> > anything like fq-codel? I know Juniper has the ability to shape
> > downstream traffic, but can it do it in a manner that doesn't increase
> > latency like fq-codel?
>
> You can avoid increasing latency by making the per-queue size
> sufficiently small. The MX can do Random Early Drop, so it is right at
> where the state of the art was before the bufferbloat project. If you
> tune it perfectly, you can probably get close to the "codel" part of
> fq-codel. The advantage of codel over RED is primarily that codel
> can do the same job without tuning.
>
> However, the MX does not have anything resembling the flow queue part of
> fq-codel -- the part where it is determined which flows are causing the
> queue to fill. This is the part where header information for each packet
> is hashed and the packet is placed in one of (by default) 1024
> queues. The MX does currently do that kind of thing, but the hashing
> part could certainly be done with a software upgrade -- aggregated
> ethernet and similar does it already. However, it would soon run out of
> hardware queues. It is typical to use 4 or 8 queues per subinterface on
> an MX, a long way from the 1024 that fq-codel likes.
>
>
> /Benny
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper Buffer Bloat

[Colton Conor]

Benny,

That is what I was thinking. Throttle the customer upstream traffic at the
CPE so they can't upload anymore traffic into the network, and throttle
their downstream traffic at the provider edge (PE) or access switch so they
can't congest any more links than required.

For fq-codel on the CPE, fq-codel runs on linux / openwrt, so there are
many options there.

I am more wondering how to do this properly on the provider edge side. I
mentioned backbone/core before, and I really meant to say provider edge. On
the provider edge, that is mostly Juniper, so we can't just implement
fq-codel. So the question lines does Juniper have anything like fq-codel? I
know Juniper has the ability to shape downstream traffic, but can it do it
in a manner that doesn't increase latency like fq-codel?

On Wed, Oct 17, 2018 at 4:50 PM Benny Lyne Amorsen 
wrote:

> James Bensley  writes:
>
> > I'm pretty sure Juniper don't have anything like fq-codel in any of
> > their products however, the place to do that would be on the CPE or
> > edge access switch/router not your core.
>
> The CPE is a great place to put fq-codel for upstream traffic. For
> downstream traffic you need the PE device to do the queueing. Having
> fq-codel available with hierarchical queueing on the MX would be
> amazing.
>
> Apart from that, Juniper does make CPE devices...
>
>
> /Benny
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper Buffer Bloat

[Colton Conor]

James,

Thanks for the response. However, if you are just shaping at the CPE, then
there could be bottlenecks between the CPE and core router causing the
bufferbloat right? Example, if you have a wireless network, DSL network,
CMTS network, etc you bottleneck is going to be that wireless accesses
point, that DSLAM, or that CMTS, and not the CPE. Packets are going to
build up on the access device not the CPE right?





On Wed, Oct 17, 2018 at 3:06 PM James Bensley  wrote:

>
>
> On 17 October 2018 20:53:44 CEST, Colton Conor 
> wrote:
> >I was wondering if Juniper supports anything like fq-codel to prevent
> >buffer bloat? Specifically we would like to do rate shaping and
> >subscriber
> >management on core Juniper MX's. However, most network devices do
> >simple
> >buffers and queuing that does not work well compared to fq-codel and
> >newer
> >algorithms. Does anyone have advice when it comes to Juniper?
>
> Hi Colton,
>
> I'm pretty sure Juniper don't have anything like fq-codel in any of their
> products however, the place to do that would be on the CPE or edge access
> switch/router not your core.
>
> Normally one would rate limit the customer on CPE LAN ingress and egress
> if you're doing multi-colour policing, or CPE WAN ingress and egress if
> just hard policing, or CPE WAN egress and PE egress if doing shaping. You
> don't want your customer to blast traffic into your network and this have
> to carry those packets across your core only to them drop them on your
> expensive  subscriber management box.
>
> One normally wants to drop excess packets as close to the source as
> possiblr. So for that reason you want fq-codel on your CPE.
>
> Cheers,
> James.
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Juniper Buffer Bloat

[Colton Conor]

I was wondering if Juniper supports anything like fq-codel to prevent
buffer bloat? Specifically we would like to do rate shaping and subscriber
management on core Juniper MX's. However, most network devices do simple
buffers and queuing that does not work well compared to fq-codel and newer
algorithms. Does anyone have advice when it comes to Juniper?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Junos Telemetry Interface (JTI)

[Colton Conor]

Aaron,

Yes, OpenNTI includes Grafana.
https://techmocha.blog/2017/06/26/using-opennti-as-a-collector-for-streaming-telemetry-from-juniper-devices-part-1/

Doesn't Grafana require alot of work to get all the sensors setup though?
AKA its not as simple as an SMNP walk with established NMS software
providers?

Anyone for Juniper than can comment on the ACX series supporting JTI? An
ACX5048  is hardware wise identical to the QFX5100, and the QFX5100
support's JTI. So it has to be just software right?



On Fri, Sep 28, 2018 at 9:11 AM Aaron1  wrote:

> I think Grafana is also capable of receiving this Telemetry info
>
> Maybe someone else can share how to make that work
>
> I’m also wanting to use JTI in ACX, And wondering if that capability is
> coming soon
>
> https://grafana.com/
>
> https://github.com/brunorijsman/juniper-grafana
>
>
>
> Aaron
>
> On Sep 28, 2018, at 8:44 AM, Colton Conor  wrote:
>
> Dave,
>
> Yep, it looks like  the video is mentioning SevOne that's them thanks
> https://www.sevone.com/streamingdatacollectors
>
>
>
> On Fri, Sep 28, 2018 at 8:34 AM Dave Bell  wrote:
>
> Sounds like SevOne to me (https://www.sevone.com/)
>
>
> On Fri, 28 Sep 2018 at 14:08, Colton Conor  wrote:
>
>
> Are there any third party network monitoring systems capable of
>
> interacting
>
> with Junos Telemetry Interface (JTI)? Many of the third party systems are
>
> SNMP and ICMP based, but we are looking for more real-time metrics. We
>
> could set the SNMP polling to intervals of less than a minute, but I
>
> assume
>
> that doesn't work very well and why JTI was released?
>
>
> I am aware of OpenNTI, but that doesn't seems to be a commercially
>
> supported platform and it is missing the elements of a true NMS from what
>
> I
>
> can tell.
>
>
> This YouTube video mentions Juniper working with partners, they even
>
> mention one, but I can't make out the name at time 11:48. Can anyone
>
> translate? https://www.youtube.com/watch?v=BeprCbmuqLA
>
>
> Does anyone know why the entire ACX line does not have Junos Telemetry
>
> Interface (JTI)? Is this a coming feature to the ACX platform?
>
>
> Besides SNMP, ICMP, and JTI, are there any other protocols that can be
>
> used
>
> for networking monitoring and management in Juniper that I am unaware of?
>
> ___
>
> 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] Junos Telemetry Interface (JTI)

[Colton Conor]

Dave,

Yep, it looks like  the video is mentioning SevOne that's them thanks
https://www.sevone.com/streamingdatacollectors



On Fri, Sep 28, 2018 at 8:34 AM Dave Bell  wrote:

> Sounds like SevOne to me (https://www.sevone.com/)
>
> On Fri, 28 Sep 2018 at 14:08, Colton Conor  wrote:
>
>> Are there any third party network monitoring systems capable of
>> interacting
>> with Junos Telemetry Interface (JTI)? Many of the third party systems are
>> SNMP and ICMP based, but we are looking for more real-time metrics. We
>> could set the SNMP polling to intervals of less than a minute, but I
>> assume
>> that doesn't work very well and why JTI was released?
>>
>> I am aware of OpenNTI, but that doesn't seems to be a commercially
>> supported platform and it is missing the elements of a true NMS from what
>> I
>> can tell.
>>
>> This YouTube video mentions Juniper working with partners, they even
>> mention one, but I can't make out the name at time 11:48. Can anyone
>> translate? https://www.youtube.com/watch?v=BeprCbmuqLA
>>
>> Does anyone know why the entire ACX line does not have Junos Telemetry
>> Interface (JTI)? Is this a coming feature to the ACX platform?
>>
>> Besides SNMP, ICMP, and JTI, are there any other protocols that can be
>> used
>> for networking monitoring and management in Juniper that I am unaware of?
>> ___
>> 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] Junos Telemetry Interface (JTI)

[Colton Conor]

Are there any third party network monitoring systems capable of interacting
with Junos Telemetry Interface (JTI)? Many of the third party systems are
SNMP and ICMP based, but we are looking for more real-time metrics. We
could set the SNMP polling to intervals of less than a minute, but I assume
that doesn't work very well and why JTI was released?

I am aware of OpenNTI, but that doesn't seems to be a commercially
supported platform and it is missing the elements of a true NMS from what I
can tell.

This YouTube video mentions Juniper working with partners, they even
mention one, but I can't make out the name at time 11:48. Can anyone
translate? https://www.youtube.com/watch?v=BeprCbmuqLA

Does anyone know why the entire ACX line does not have Junos Telemetry
Interface (JTI)? Is this a coming feature to the ACX platform?

Besides SNMP, ICMP, and JTI, are there any other protocols that can be used
for networking monitoring and management in Juniper that I am unaware of?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Juniper vs Arista

[Colton Conor]

We have used Juniper for a long time across various lines. What I have
noticed is on the JTAC recommend version website piratically all of their
product lines are running on different code trains. They all run Junos yes,
but they all have different features. It seems like Juniper has a different
software development team for every product.

Arista's sales engineering are claiming that their entire product line runs
EOS, and there is a single firmware file for all products. Does anyone know
if that is true, and how that compares to the way Juniper does things?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Mounting a QFX5100 or ACX5048 on 2 Post Rack

[Colton Conor]

Brian, are you talking about this kit:
https://www.racksolutions.com/2-post-rack-rails.html



On Thu, Aug 2, 2018 at 11:25 AM, Nelson, Brian 
wrote:

> Yes, I have these kits in production, without the back cable mgmt rail.
> Work just fine. They are beefier than the pictures depict.
>
> Brian Nelson
>
> On 08/02/2018 10:08 AM, Colton Conor wrote:
> > Tim,
> >
> > Have you used this 2 post rack rails with the QFX5100? It looks like this
> > rail kit has a back plate, does the power cables fit through those holes?
> > This QFX5100 is long.
> >
> >
> >
> > On Wed, Aug 1, 2018 at 5:48 PM, Tim Jackson 
> wrote:
> >
> >> https://www.racksolutions.com/2-post-rack-rails.html
> >>
> >> --
> >> Tim
> >>
> >> On Wed, Aug 1, 2018 at 5:39 PM, Colton Conor 
> >> wrote:
> >>
> >>> We are constantly having to mount these larger switches to two post
> racks.
> >>> To my knowledge Juniper does not make 2 post mounting brackets for
> these
> >>> switches. Does anyone have any recommendations on a shelf or something
> to
> >>> hold these up? We are dealing with 19 and 23 inch racks.
> >>> ___
> >>> 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
> >
>
>
> --
> Supervisor
> Computing Systems Support
> Dept of Computer Science
>
> ___
> 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] Mounting a QFX5100 or ACX5048 on 2 Post Rack

[Colton Conor]

Tim,

Have you used this 2 post rack rails with the QFX5100? It looks like this
rail kit has a back plate, does the power cables fit through those holes?
This QFX5100 is long.



On Wed, Aug 1, 2018 at 5:48 PM, Tim Jackson  wrote:

> https://www.racksolutions.com/2-post-rack-rails.html
>
> --
> Tim
>
> On Wed, Aug 1, 2018 at 5:39 PM, Colton Conor 
> wrote:
>
>> We are constantly having to mount these larger switches to two post racks.
>> To my knowledge Juniper does not make 2 post mounting brackets for these
>> switches. Does anyone have any recommendations on a shelf or something to
>> hold these up? We are dealing with 19 and 23 inch racks.
>> ___
>> 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] Mounting a QFX5100 or ACX5048 on 2 Post Rack

[Colton Conor]

Chuck,

We put them in the center, and even cut them, but overall the 4 post rack
brackets that come with the QFX5100 are flimsy as hell.

On Wed, Aug 1, 2018 at 6:09 PM, Chuck Anderson  wrote:

> Just put the rack brackets back towards the middle of the sides so the
> switch is hangs further forward.  The weight is more balanced and it works
> fine.
>
> On Wed, Aug 01, 2018 at 06:39:43PM -0400, Colton Conor wrote:
> > We are constantly having to mount these larger switches to two post
> racks.
> > To my knowledge Juniper does not make 2 post mounting brackets for these
> > switches. Does anyone have any recommendations on a shelf or something to
> > hold these up? We are dealing with 19 and 23 inch racks.
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Mounting a QFX5100 or ACX5048 on 2 Post Rack

[Colton Conor]

Chris,

So the EX4200 rack ears fit on the QFX5100?



On Wed, Aug 1, 2018 at 8:19 PM, Chris Wopat  wrote:

> We still use EX4200 rack ears and center mount them. Holes line up, works
> fine. I believe it's "EX-RMK". It's more problematic to flush mount it as
> one always needs some support on the rear- usually a small shelf on the
> back side, like the small shelf used to mount an MX480.
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Mounting a QFX5100 or ACX5048 on 2 Post Rack

[Colton Conor]

We are constantly having to mount these larger switches to two post racks.
To my knowledge Juniper does not make 2 post mounting brackets for these
switches. Does anyone have any recommendations on a shelf or something to
hold these up? We are dealing with 19 and 23 inch racks.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] QFX5100 vs ACX5048

[Colton Conor]

Strange we had no issues upgrading from  17.3R2 from  15.1X.

On Tue, Jul 17, 2018 at 2:27 PM, Gustavo Santos 
wrote:

> Yes... Exactly.
>
> I upgraded to 17.3R2 and was a total mess. And had to downgrade to 15.1X
> train.
>
>
> On Wed, Jul 4, 2018 at 11:31 AM Colton Conor 
> wrote:
>
>> Gustavo,
>>
>> We you say " Another problem was upgrading to the lastest Junos JTAC
>> recommended that made the ACX5048 unusable... ( Junos was unable to find
>> the physical ports..)  We had to downgrade to get it back working again.."
>> what version was this as JTAC recently changed their recommended version?
>> It seem everyone on this thread is talking about software train  15.1X54.
>>
>> However, the current JTAC recommended version is Junos 17.3R2 as of 14
>> May 2018. Why is everyone running  15.1X54 code?
>>
>> Has anyone upgraded to  Junos 17.3R2 on the ACX's? No matter the model,
>> all ACX's current recommended is now  Junos 17.3R2
>>
>>
>> On Mon, Jul 2, 2018 at 8:11 AM, Gustavo Santos 
>> wrote:
>>
>>> I had some issues with ACX5048 , the most noticable was arp packets from
>>> pure L2 vlans and VPLS punting to CPU and flooding the default arp policer
>>> police..
>>> JTAC was able to reproduce the issue and gave us an option to disable
>>> default arp policer until they release a service release to fix this issue
>>> that was solved indeed.
>>>
>>> Another problem was upgrading to the lastest Junos JTAC recommended that
>>> made the ACX5048 unusable... ( Junos was unable to find the physical
>>> ports..)  We had to downgrade to get it back working again..
>>>
>>> On Sun, Jul 1, 2018 at 8:05 PM Alexandre Guimaraes <
>>> alexandre.guimar...@ascenty.com> wrote:
>>>
>>>> Better in terms of concept. In term of usage, i still investing in
>>>> qfx5100
>>>>
>>>> Acx5058 Suppose to be a promise of a new future, unfortunately, with
>>>> all problematic of the qfx5100 hardware, the acx5048 leak vlan till the
>>>> last breath of cpu after that, all deamons and services going down
>>>> up and down, up and down.
>>>>
>>>> I never more brought one peace ACX5048 after jtac didnt responds why
>>>> and solution for the leaking...( I have only two acx5048 and hundreds on
>>>> QFX...).
>>>>
>>>> The new promise is the new acx5448. No vlan leaking, a good load
>>>> balance(ae) algorithm, full of this full of that a lot of promise.
>>>>
>>>> Let’s see...
>>>>
>>>> att
>>>> Alexandre
>>>>
>>>> Em 1 de jul de 2018, à(s) 19:31, Colton Conor 
>>>> escreveu:
>>>>
>>>> > What is the main difference between these two boxes? Hardware wise
>>>> they
>>>> > look identical. Is there anything on the hardware side that makes the
>>>> > ACX5048 better than a QFX5100, or is it only software related?
>>>> > ___
>>>> > 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] QFX5100 vs ACX5048

[Colton Conor]

Nick,

Why does it say
*Resolved In* 16.2R1-S7 16.2R3 17.1R2 17.1R3 17.2R2 *17.3R1*
17.3R1 came before the now current JTAC recommend  *17.3R2 right? *

On Wed, Jul 11, 2018 at 6:39 AM, Nick Ryce  wrote:

> Sorry I thought I had.
>
>
>
> We hit this https://prsearch.juniper.net/InfoCenter/index?page=
> prcontent=PR1280492
>
>
>
> This is being resolved in 17.3R3 which is due for release in a couple of
> weeks.
>
>
>
> N
>
>
>
> *From: *Colton Conor 
> *Date: *Wednesday, 11 July 2018 at 12:30
> *To: *Nick Ryce 
> *Cc: *Gustavo Santos , Aaron ,
> Juniper List 
> *Subject: *Re: [j-nsp] QFX5100 vs ACX5048
>
>
>
> Nick,
>
>
>
> Did you find the PR for this memory leak?
>
>
>
> On Wed, Jul 4, 2018 at 11:02 AM, Nick Ryce 
> wrote:
>
> If you use BFD, do not upgrade to 17.3R2 as there is a memory leak.  Will
> find the PR.
>
> N
>
>
> On 04/07/2018, 15:31, "juniper-nsp on behalf of Colton Conor" <
> juniper-nsp-boun...@puck.nether.net on behalf of colton.co...@gmail.com>
> wrote:
>
>  Gustavo,
>
> We you say " Another problem was upgrading to the lastest Junos JTAC
> recommended that made the ACX5048 unusable... ( Junos was unable to
> find
> the physical ports..)  We had to downgrade to get it back working
> again.."
> what version was this as JTAC recently changed their recommended
> version?
> It seem everyone on this thread is talking about software train
> 15.1X54.
>
> However, the current JTAC recommended version is Junos 17.3R2 as of 14
> May
> 2018. Why is everyone running  15.1X54 code?
>
> Has anyone upgraded to  Junos 17.3R2 on the ACX's? No matter the
> model, all
> ACX's current recommended is now  Junos 17.3R2
>
>
> On Mon, Jul 2, 2018 at 8:11 AM, Gustavo Santos 
> wrote:
>
> > I had some issues with ACX5048 , the most noticable was arp packets
> from
> > pure L2 vlans and VPLS punting to CPU and flooding the default arp
> policer
> > police..
> > JTAC was able to reproduce the issue and gave us an option to disable
> > default arp policer until they release a service release to fix this
> issue
> > that was solved indeed.
> >
> > Another problem was upgrading to the lastest Junos JTAC recommended
> that
> > made the ACX5048 unusable... ( Junos was unable to find the physical
> > ports..)  We had to downgrade to get it back working again..
> >
> > On Sun, Jul 1, 2018 at 8:05 PM Alexandre Guimaraes <
> > alexandre.guimar...@ascenty.com> wrote:
> >
> >> Better in terms of concept. In term of usage, i still investing in
> qfx5100
> >>
> >> Acx5058 Suppose to be a promise of a new future, unfortunately,
> with all
> >> problematic of the qfx5100 hardware, the acx5048 leak vlan till the
> last
> >> breath of cpu after that, all deamons and services going
> down up
> >> and down, up and down.
> >>
> >> I never more brought one peace ACX5048 after jtac didnt responds
> why and
> >> solution for the leaking...( I have only two acx5048 and hundreds on
> >> QFX...).
> >>
> >> The new promise is the new acx5448. No vlan leaking, a good load
> >> balance(ae) algorithm, full of this full of that a lot of
> promise.
> >>
> >> Let’s see...
> >>
> >> att
> >> Alexandre
> >>
> >> Em 1 de jul de 2018, à(s) 19:31, Colton Conor <
> colton.co...@gmail.com>
> >> escreveu:
> >>
> >> > What is the main difference between these two boxes? Hardware
> wise they
> >> > look identical. Is there anything on the hardware side that makes
> the
> >> > ACX5048 better than a QFX5100, or is it only software related?
> >> > ___
> >> > 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
>
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] QFX5100 vs ACX5048

[Colton Conor]

Nick,

Did you find the PR for this memory leak?

On Wed, Jul 4, 2018 at 11:02 AM, Nick Ryce  wrote:

> If you use BFD, do not upgrade to 17.3R2 as there is a memory leak.  Will
> find the PR.
>
> N
>
> On 04/07/2018, 15:31, "juniper-nsp on behalf of Colton Conor" <
> juniper-nsp-boun...@puck.nether.net on behalf of colton.co...@gmail.com>
> wrote:
>
>  Gustavo,
>
> We you say " Another problem was upgrading to the lastest Junos JTAC
> recommended that made the ACX5048 unusable... ( Junos was unable to
> find
> the physical ports..)  We had to downgrade to get it back working
> again.."
> what version was this as JTAC recently changed their recommended
> version?
> It seem everyone on this thread is talking about software train
> 15.1X54.
>
> However, the current JTAC recommended version is Junos 17.3R2 as of 14
> May
> 2018. Why is everyone running  15.1X54 code?
>
> Has anyone upgraded to  Junos 17.3R2 on the ACX's? No matter the
> model, all
> ACX's current recommended is now  Junos 17.3R2
>
>
> On Mon, Jul 2, 2018 at 8:11 AM, Gustavo Santos 
> wrote:
>
> > I had some issues with ACX5048 , the most noticable was arp packets
> from
> > pure L2 vlans and VPLS punting to CPU and flooding the default arp
> policer
> > police..
> > JTAC was able to reproduce the issue and gave us an option to disable
> > default arp policer until they release a service release to fix this
> issue
> > that was solved indeed.
> >
> > Another problem was upgrading to the lastest Junos JTAC recommended
> that
> > made the ACX5048 unusable... ( Junos was unable to find the physical
> > ports..)  We had to downgrade to get it back working again..
> >
> > On Sun, Jul 1, 2018 at 8:05 PM Alexandre Guimaraes <
> > alexandre.guimar...@ascenty.com> wrote:
> >
> >> Better in terms of concept. In term of usage, i still investing in
> qfx5100
> >>
> >> Acx5058 Suppose to be a promise of a new future, unfortunately,
> with all
> >> problematic of the qfx5100 hardware, the acx5048 leak vlan till the
> last
> >> breath of cpu after that, all deamons and services going
> down up
> >> and down, up and down.
> >>
> >> I never more brought one peace ACX5048 after jtac didnt responds
> why and
> >> solution for the leaking...( I have only two acx5048 and hundreds on
> >> QFX...).
> >>
> >> The new promise is the new acx5448. No vlan leaking, a good load
> >> balance(ae) algorithm, full of this full of that a lot of
> promise.
> >>
> >> Let’s see...
> >>
> >> att
> >> Alexandre
> >>
> >> Em 1 de jul de 2018, à(s) 19:31, Colton Conor <
> colton.co...@gmail.com>
> >> escreveu:
> >>
> >> > What is the main difference between these two boxes? Hardware
> wise they
> >> > look identical. Is there anything on the hardware side that makes
> the
> >> > ACX5048 better than a QFX5100, or is it only software related?
> >> > ___
> >> > 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
>
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SNMP NMS support of Junos VLAN MIBs

[Colton Conor]

Chuck,

Did this Junos issue ever get resolved?

On Wed, Dec 9, 2015 at 10:31 AM, Chuck Anderson  wrote:

> Has anyone tried to use or implement polling of the Q-BRIDGE-MIB on
> any Juniper products, using either commercial or open source NMS
> software or custom in-house software?  What has been your experience
> of the Juniper support of those SNMP products to correctly report
> Port/VLAN memberships and VLAN/MAC FDB information?
>
> Juniper EX-series (at least EX2200,3200,4200) 12.x and earlier has a
> working Q-BRIDGE-MIB (dot1qVlanStaticEgressPorts) and JUNIPER-VLAN-MIB
> (jnxExVlan).  Because Q-BRIDGE-MIB refers only to internal VLAN
> indexes, you need to use both MIBs to get Port/VLAN mappings including
> the 802.1Q VLAN tag ID (jnxExVlanTag).  This means custom software, or
> an NMS vendor willing to implement the Juniper Enterprise MIBs.
>
> All other Juniper Junos platforms only have Q-BRIDGE-MIB, but it is
> broken (doesn't follow RFC 4363 standard PortList definition, instead
> storing port indexes as ASCII-encoded, comma separated values),
> apparently for a very long time.  So again, you need custom software
> or an NMS vendor willing to implement the broken Juniper version of
> Q-BRIDGE-MIB (along with detecting which implementation is needed on
> any particular device).  This hasn't been a problem for us and in fact
> went unnoticed, because we never cared to poll VLAN information from
> our MX routers, only EX switches.
>
> But now EX-series (and QFX-series) 13.x and newer with ELS have
> dropped the Enterprise JUNIPER-VLAN-MIB (a good thing to not require
> Enterprise MIBs to get the VLAN tag ID) and have adopted the broken
> Q-BRIDGE-MIB that all the other Junos platforms have been using (a
> very bad thing).  I'm pushing to have Juniper fix this, but their
> concern is that it may break SNMP software that has been assuming the
> broken Q-BRIDGE-MIB implementation for all these years.
> ___
> 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] QFX5100 vs ACX5048

[Colton Conor]

 Gustavo,

We you say " Another problem was upgrading to the lastest Junos JTAC
recommended that made the ACX5048 unusable... ( Junos was unable to find
the physical ports..)  We had to downgrade to get it back working again.."
what version was this as JTAC recently changed their recommended version?
It seem everyone on this thread is talking about software train  15.1X54.

However, the current JTAC recommended version is Junos 17.3R2 as of 14 May
2018. Why is everyone running  15.1X54 code?

Has anyone upgraded to  Junos 17.3R2 on the ACX's? No matter the model, all
ACX's current recommended is now  Junos 17.3R2


On Mon, Jul 2, 2018 at 8:11 AM, Gustavo Santos  wrote:

> I had some issues with ACX5048 , the most noticable was arp packets from
> pure L2 vlans and VPLS punting to CPU and flooding the default arp policer
> police..
> JTAC was able to reproduce the issue and gave us an option to disable
> default arp policer until they release a service release to fix this issue
> that was solved indeed.
>
> Another problem was upgrading to the lastest Junos JTAC recommended that
> made the ACX5048 unusable... ( Junos was unable to find the physical
> ports..)  We had to downgrade to get it back working again..
>
> On Sun, Jul 1, 2018 at 8:05 PM Alexandre Guimaraes <
> alexandre.guimar...@ascenty.com> wrote:
>
>> Better in terms of concept. In term of usage, i still investing in qfx5100
>>
>> Acx5058 Suppose to be a promise of a new future, unfortunately, with all
>> problematic of the qfx5100 hardware, the acx5048 leak vlan till the last
>> breath of cpu after that, all deamons and services going down up
>> and down, up and down.
>>
>> I never more brought one peace ACX5048 after jtac didnt responds why and
>> solution for the leaking...( I have only two acx5048 and hundreds on
>> QFX...).
>>
>> The new promise is the new acx5448. No vlan leaking, a good load
>> balance(ae) algorithm, full of this full of that a lot of promise.
>>
>> Let’s see...
>>
>> att
>> Alexandre
>>
>> Em 1 de jul de 2018, à(s) 19:31, Colton Conor 
>> escreveu:
>>
>> > What is the main difference between these two boxes? Hardware wise they
>> > look identical. Is there anything on the hardware side that makes the
>> > ACX5048 better than a QFX5100, or is it only software related?
>> > ___
>> > 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

[j-nsp] QFX5100 vs ACX5048

[Colton Conor]

What is the main difference between these two boxes? Hardware wise they
look identical. Is there anything on the hardware side that makes the
ACX5048 better than a QFX5100, or is it only software related?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX204 ballpark

[Colton Conor]

I received a quote for right at 40k for two of them with J-Care.

On Sun, May 27, 2018 at 3:31 AM, Edward Dore <
edward.d...@freethought-internet.co.uk> wrote:

>
> On 27/05/2018, 09:28, "juniper-nsp on behalf of Vincent Bernat" <
> juniper-nsp-boun...@puck.nether.net on behalf of ber...@luffy.cx> wrote:
>
>  ❦ 27 mai 2018 13:24 +0700, Mark Tees  :
>
> > Not sure if it’s licensed on FIB usage but I’m trying to gain an
> idea on
> > both full table and partial table options.
>
> For full FIB (or RIB?), you need the S-MX104-ADV-R2 license whose
> public
> price is 2. However, the limitation is not enforced (you cannot
> even
> add the license to the system, it's just a piece of paper). This kind
> of
> license limitation doesn't exist with the MX80 (or with any other MX
> from the same era). This license can be part of a bundle (you should
> definitely look at bundles for the MX104, the pricing doesn't make much
> sense). If you buy it separately, Juniper easily does at least 30% on
> licenses. Personnally, I wouldn't pay anything for such a license since
> the MX104 slow routing engine is unable to handle an Internet-sized FIB
> without important downtimes during changes (1-2 minutes). You'll have
> to
> select the routes you install in FIB if you want to minimize impacts
> during changes and you'll need to be below the licensing limit (256k
> routes I think).
>
> I can't say anything about current pricing because I've bought mine
> more
> than 3 years ago, but you should also consider if a MX204 or a MX150
> would fit your needs. The routing engines are far more capable on these
> (but they are a fixed chassis with only one routing engine).
>
> Mark asked about the MX204, not the MX104.
>
> Edward Dore
> Freethought Internet
>
>
>
> ___
> 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] Going Juniper

[Colton Conor]

Mike,

For 20K you can get a new MX204 (not to be confused with MX240). However, I
don't think the MX204 support CGNAT if needed, but I could be wrong. But I
wouldn't touch a MX80 or MX104 if buying new.

On Mon, Apr 9, 2018 at 8:45 PM,  wrote:

> Greetings,
>
> I am looking for some advice concerning juniper as an edge router.
>
> I see there is a terrific amount of used mx104 and mx240 out there
> and the specs all seem great. What I'm looking to do is have 2x 10g
> feeds, route bgp, do flow exporting, and do a certain amount of ingress
> filtering to protect the network from ddos.Id even like to do cgnat for
> up to 5000 users but not sure if a single box setup would be wise.
>
> I just don't have a handle on the various juniper platforms and
> route engine options. Love to keep this under $20,000 and get a load of
> 10g interfaces. Anyone here can tell me what I should be looking for?
>
> Mike-
> ___
> 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] Power ON?

[Colton Conor]

Wait are the shipping these units now?

On Mon, Apr 2, 2018 at 2:29 PM, Chuck Anderson  wrote:

> Cool.  Is there another parameter specify which VM to power-on, maybe a
> service VM?
>
> I wonder why the MX150 doesn't have any vmhost commands.  It would come in
> handy for some issues.
>
> On Mon, Apr 02, 2018 at 02:00:33PM -0500, Chris Adams wrote:
> > Working on a new MX204, I noticed this:
> >
> > user@router> request vmhost power-o?
> > Possible completions:
> >   power-offPower off the software on RE
> >   power-on Power on the system
> >
> > Really?  The RE VM can tell the VM host to power ON? :)
> ___
> 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] MX80 v MX104

[Colton Conor]

I was about to say check out the MX204 or MX150 if it meets the need. These
are newer boxes.

Anyone have an idea what the list price is for both of these boxes? Do they
have locked features, or special upgrades like the MX5-80 had?

On Fri, Dec 1, 2017 at 12:54 PM, Raphael Maunier 
wrote:

> Go for MX204 : https://www.juniper.net/us/en/products-services/routing/mx-
> series/mx204/
>
> RFS 02/2018
>
> Raphael
>
> On 01/12/2017 19:42, "juniper-nsp on behalf of Jerry Jones" <
> juniper-nsp-boun...@puck.nether.net on behalf of jjo...@danrj.com> wrote:
>
> Go with MX104
>
> Form factor much better. nothing on the back, have option for second
> RE if desired, RE is slightly better, 2 more MIC slots, cost is generally
> less on 104 than 80, if using ay 10G then it for sure should be, and if I
> remember correct 104 is quieter, but have not played on 80 for some timen
> ow as ony use 104s for last couple years
>
>
> On Dec 1, 2017, at 12:09 PM, Catalin Dominte <
> catalin.domi...@nocsult.net> wrote:
>
> MX104 has 4gb Memory and MX80 comes with 2. If you are running full BGP
> tables, you might want to consider this too.
>
>
> *Catalin Dominte | Senior Network Consultant*
>
> Nocsult Ltd  | 11 Castle Hill  |  Maidenhead  |  Berkshire  |  SL6
> 4AA  |
> Phone:  +44 (0)1628 302 007
>
> VAT registration number: GB 180957674  |  Company registration number:
> 08886349
> P Please consider the environment - Do you really need to print this
> email?
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
> PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received this in error, please contact the sender and delete the email
> and
> its attachments from all computers.
>
> On 1 December 2017 at 18:03:15, Alain Hebert (aheb...@pubnix.net)
> wrote:
>
>Hi,
>
>Beside the extra RE-slot of the 104 and a few more slots.
>
>
>Is there any more drawback (beside the knowned hella slow RE which
> is the same as the 104) of opting for the MX80?
>
>It looks like 4 10Gb XFP + 2 slot of 2 10Gb XFP is the maximum in
> the 80 case.  Which will be viable for the project.
>
>
>PS: With a small budget, and they're buying 2 boxes anyway... and
> they're not interested in MS-MIC
>
> --
> -
> Alain Hebert aheb...@pubnix.net
> PubNIX Inc.
> 50 boul. St-Charles
> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
> Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443
>
> ___
> 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
>
>
> ___
> 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] ACX5048 - 40 gbps ER 40 km optic

[Colton Conor]

So why go with this then? You could litterally do a passive mux and 4 10G
colored optics for much much less than that. Check out FS.com

On Tue, Oct 10, 2017 at 4:41 PM, Gustavo Santos <gustkil...@gmail.com>
wrote:

> Here in Brazil where everything costs a lot more than US because of
> taxes,  about U$2485 per module.
>
> 2017-10-09 23:53 GMT-03:00 Colton Conor <colton.co...@gmail.com>:
>
>> How much do those cost? We have used many of the 10KM optics in out
>> ACX5048, but never the 40KM due to cost. It seems much cheaper to use 4
>> colored SFP+'s?
>>
>> On Mon, Oct 9, 2017 at 8:16 AM, Gustavo Santos <gustkil...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> It's an ER4 , LR4 is just the label precision coded for compatibility.
>>> The module part name is PRE-QSFP-ER4
>>>
>>> 2017-10-04 19:57 GMT-03:00 Aaron Gould <aar...@gvtc.com>:
>>>
>>> > Hey that’s good to know Gustavo… but LR4 , is that shorter than 40 km ?
>>> >
>>> >
>>> >
>>> > -Aaron
>>> >
>>> >
>>> >
>>> ___
>>> 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] ACX5048 - 40 gbps ER 40 km optic

[Colton Conor]

How much do those cost? We have used many of the 10KM optics in out
ACX5048, but never the 40KM due to cost. It seems much cheaper to use 4
colored SFP+'s?

On Mon, Oct 9, 2017 at 8:16 AM, Gustavo Santos  wrote:

> Hi,
>
> It's an ER4 , LR4 is just the label precision coded for compatibility.
> The module part name is PRE-QSFP-ER4
>
> 2017-10-04 19:57 GMT-03:00 Aaron Gould :
>
> > Hey that’s good to know Gustavo… but LR4 , is that shorter than 40 km ?
> >
> >
> >
> > -Aaron
> >
> >
> >
> ___
> 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] Juniper PTX1000

[Colton Conor]

Lets not forget, the list price for a limited PTX1000 is $650,000. Even
with a substantial 95 percent off list discount, it is nowhere close to the
same ballpark as the Arista solution.

Because Arista has no other routing solution out there, I think they have a
pricing advantage. The spent almost nothing on the hardware since its a
Broadcom Jericho chipset, and can focus on the software. Plus, they don't
have to worry about cannibalizing their routing sales because they only
have one routing product. Unlike Cisco/Juniper, who have to make sure they
don't price their products too low making people jump ship from one of
their routing lines to another.

On Tue, Dec 20, 2016 at 1:21 PM, Saku Ytti  wrote:

> On 20 December 2016 at 18:42,   wrote:
>
> > Both CRS-X and NCS6k are powered by nPower X1e NPU.
> > And my understanding is that it's Homogeneous(Same PPE type) MPSoC i.e.
> Symmetric MultiProcessing (SMP), much like all the chips out there (used in
> ASR9k or MX and PTX, ...).
> > The difference I understand is in the instruction set that the PPE is
> running.
> > And my guess is that threads on each PPE are using run to completion
> scheduling.
> > Let me know your thoughts please.
> >
> > And by pipeline with regards to NPU design I understand pipelining of
> arrays of PPEs where each array in the pipeline consists of PPEs dedicated
> to a specific function(parse search modify). -like in ASR9k.
>
> Current gen ASR9k, EZchip, is like Trio, ALU FP or Huawei Solar, many
> identical cores, fully programmable, essentially you're only limited
> by time in what you can do. Where as NCS5k/Arista/Jericho, PTX are
> ASIC/pipelines, with much more specialised hardware with lot less
> flexibility, but what they do do, they do far more efficiently, which
> means denser boxes are pragmatic.
> Roughly speaking pipeline/ASIC is great for core, DC, in Edge you
> often may require richer features offered by NPU designs, and density
> isn't that crucial.
>
>
> --
>   ++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] Juniper PTX1000

[Colton Conor]

Thats the actual quote I got on one a while back. Pricing might have
change. About half the price was for the hardware, and the other half was
for the full software.

Tell me another platform for $28k that has 6 100G ports, and 48 10G ports,
and can do full BGP routing for 28K.

On Sat, Dec 17, 2016 at 3:03 AM, Raphael Mazelier <r...@futomaki.net> wrote:

>
>
> On 17/12/2016 05:28, Colton Conor wrote:
>
>> Aaron,
>>
>> About 28k including hardware, license, and 12 months of support. Not bad
>> for as many ports as it has, and full BGP.
>>
>>
> Hum interesting. Price list or ?
> A bit expensive I think for this type of box, for half the price we begun
> to talk...
>
>
> --
> Raphael Mazelier
>
> ___
> 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] Juniper PTX1000

[Colton Conor]

Aaron,

About 28k including hardware, license, and 12 months of support. Not bad
for as many ports as it has, and full BGP.

On Fri, Dec 16, 2016 at 3:24 PM, Jesper Skriver  wrote:

> On Fri, Dec 16, 2016 at 02:45:14PM -0600, Aaron wrote:
> > Ah, thanks Jesper... you know how much those 7280's cost ? (just
> ballpark)
>
> No idea, sorry.
>
> /Jesper
> ___
> 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] ACX5048 - vlan-map conflict with routing-instance with vlan-id tags

[Colton Conor]

Daniel,

What did you end up going with?

On Thu, Apr 21, 2016 at 1:35 PM, Daniel Verlouw  wrote:

> Hi Aaron,
>
> On Thu, Apr 21, 2016 at 7:48 PM, Aaron  wrote:
> > [edit vlans vlan10 interface]
> >   'ge-0/0/38.17'
> > interface with input/output vlan-maps cannot be added to a
> routing-instance with a vlan-id/vlan-tags configured
> > error: commit failed: (statements constraint check failed)
>
> The error msg is pretty clear :) did you try my first suggestion which
> was simply to remove the input/output-vlan-maps ? So:
>
> set interfaces ge-0/0/38 flexible-vlan-tagging
> set interfaces ge-0/0/38 encapsulation flexible-ethernet-services
> set interfaces ge-0/0/38 unit 17 encapsulation vlan-bridge
> set interfaces ge-0/0/38 unit 17 vlan-id 17
> set vlans vlan10 interface ge-0/0/38.17
> set vlans vlan10 l3-interface irb.10
> set vlans vlan10 vlan-id 10
>
> I'm fairly sure this worked when we PoC'd it (don't have my notes
> handy, and we didn't go for the ACX5k in the end, so can't try it
> again). The interface is automatically config'd for a vlan swap
> to/from vlan 10 in this case.
>
>   -- Daniel.
> ___
> 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] MX104 capabilities question

[Colton Conor]

Saku,

Can you expand on what you mean by the following quote: "I think they are
fundamentally able to produce less buggy code than
JNPR or CSCO. They are doing some of the classic mistakes, like
insisting market that they have single image like JNPR highlighted as
big competitive advantage over CSCO back in the day. But they'll need
to get rid of this message when moving to 64b or then they need to
screw people running older HW not capable for 32b."

My understanding is right now they indeed do have a single downloadable
file no matter which arista switch model you have. Is that not the case?
Are you saying this file is 32 bit and not 64? That would suprise me since
I beleive most of their recent switches have more than 8GB of RAM in them.

On Thu, Jun 9, 2016 at 8:39 AM, Saku Ytti  wrote:

> On 9 June 2016 at 15:54, Mark Tinka  wrote:
>
> > But is the IP and MPLS code mature enough for real-world use?
>
> It's getting there, customer by customer. It's not there for me. I
> expect Arista to be serious player in SP segment in a <2 years.
>
> As Arista is still controlled by owners who work there on daily basis,
> they can do things well, instead of seeking immediate gratification
> while adding technological debt. And none of them are in their first
> rodeo, are financially independent so I don't think they're interested
> in doing big exit, I think they're solely motivated in building great
> company and a great product. How long this issue will persist is
> anyone's guess.
>
> They do something quite different than JNPR or CSCO. I think
> programming language is important, and I think C is terrible language,
> because it's very hard to write quality code on.
> Arista isn't really using C, mostly C++ and good portion of that is
> machine generated from their own proprietary state description
> language. They also heavily unit test and automate black-box testing.
>
> I think they are fundamentally able to produce less buggy code than
> JNPR or CSCO. They are doing some of the classic mistakes, like
> insisting market that they have single image like JNPR highlighted as
> big competitive advantage over CSCO back in the day. But they'll need
> to get rid of this message when moving to 64b or then they need to
> screw people running older HW not capable for 32b.
>
> I wish someone would do something even more novel, like create full
> routing suite in Erlang. But from what we have now in the market, I
> think Arista is most innovative.
>
> --
>   ++ytti
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX3400 switches, QSFP+ breakout

[Colton Conor]

Why?

On Wed, Jun 15, 2016 at 9:18 AM, Nitzan Tzelniker <
nitzan.tzelni...@gmail.com> wrote:

> Like the EX4300 the 40GE ports cannot be channelized to 4 x 10G
>
> Nitzan
>
>
> On Wed, Jun 15, 2016 at 4:31 PM, Jim Troutman 
> wrote:
>
> > Anyone have any experience or opinions on the EX3400 switches?
> >
> > Can anyone confirm that the software supports breaking out a QSFP+ ports
> > into 4x SFP+ (like with a QFX-QSFP-DACBO-1M) and configure as separate 10
> > GigE interfaces?
> >
> > My SE says he thinks so, because QSFP+ specs are same as on the QFX, but
> > I'd like confirmation from someone who has actually done it.
> >
> > --
> > Jim Troutman,
> > jamesltrout...@gmail.com
> > 800-605-0192 (main)
> > ___
> > 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] MX104 capabilities question

[Colton Conor]

Aaron,

I think the big thing the ACX5048 is lacking is the ability to hold a full
routing table compared to the MX104 and ASR9001. Remember the ACX5048 has a
Broadcom Trident II chipset.

A better question is would you consider an Arista 7280R in place of a MX104
or ASR9001. The Arista 7280R can accept full routes, and has a very similar
pricepoint. Not to mention 48 10G ports, and 6 100G ports.

On Wed, Jun 8, 2016 at 9:58 AM, Aaron  wrote:

> I realize these are 2 totally different style boxes, but I'll ask anyway...
>
> An ACX5048 with (72) 10 gig ports (or... (48) 10 gig ports with (6) 40 gig
> ports) at ~$15K ...
>
> Would anyone consider putting a ACX5048 in place of a MX104/ASR9k ?
>
> - Aaron
>
>
> ___
> 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] RE-S-X6-64G-BB

[Colton Conor]

Alright, so if not upgrading from a previous Juniper box (buying new),
would you at this point not take the newer RE's that are the same price as
the older?

On Thu, May 26, 2016 at 5:16 AM, Mark Tinka  wrote:

>
>
> On 26/May/16 11:52, raf wrote:
>
> >
> > Ah ok. This RE come with a new embeded network card for the mngt, and
> > Freebsd 6 does have not support for it; and juniper would not make the
> > effort to backport it.
> > Juniper want their customer to test their new code. It can be scary
> > for op, and understand the conservatism for this kind of stuff.
> > However I don't think 15 is such a big change. Ok the underlaying OS
> > have a big jump in version and junos begun to use SMP.
> > But only for separate process, so from a sysadmin point of view it
> > should be safe (as I m really confident with the stability of freebsd10).
> > Junos 16 with the separate thread in rpd will be a other story I think.
>
> Well, the upgrade to Junos 15 is not straightforward as well:
>
>
> http://www.juniper.net/documentation/en_US/junos15.1/topics/task/installation/junos-os-upgrading-kernel-freebsd10.html
>
> 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] RE-S-X6-64G-BB

[Colton Conor]

So how long before Junos 15.1R4 or higher will be the offical JTAC
Recommended Junos Software Version for MX Series with NG MPCs? Right now
it's Junos 14.1R7

On Wed, May 25, 2016 at 12:28 PM, Daniel Verlouw 
wrote:

> Hi,
>
> On Wed, May 25, 2016 at 7:06 PM, Saku Ytti  wrote:
> > Longer time before it's end of support, better resell value on top of
> > normal better scale and convergence.
>
> definitely good and valid points, however are you willing to deploy
> (what I consider) bleeding-edge code in your network to support the
> latest and greatest HW? I'm most certainly not, have plenty of issues
> today with so-called 'stable' releases...
>
>   --Daniel.
> ___
> 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] RE-S-X6-64G-BB

[Colton Conor]

Besides swapping the inter processor out for a new one, and adding more and
faster ram, is there really any other big differences?

On Wed, May 25, 2016 at 11:44 AM, Michael Still <stillwa...@gmail.com>
wrote:

>
>
> On Wed, May 25, 2016 at 12:31 PM, Colton Conor <colton.co...@gmail.com>
> wrote:
>
>> Assuming we are not going to be using these new RE's to load any 3rd party
>> software on them, the RE-S-X6-64G-BB will just be a quicker processor with
>> more ram compared to an older RE right? Are there any other benefits?
>> Juniper is offering the RE-S-X6-64G-BB for the same price as
>> the RE-S-1800X4-32G. Not sure why one would not go with the new RE with
>> more ram?
>>
>
> Couple reasons. First is that this is pretty shiny new product and it's a
> good idea to expect bugs to be found in it. Second is that it requires you
> to run much newer / less well baked code than a lot of people are
> comfortable with in their networks. Combine these two and there's going to
> be lots of hesitation on these for 6 months or so. The 1800 has been a real
> workhorse on this platform for a few years now and has proven to be a
> pretty good RE and still good for the majority of the uses cases out there.
>
>
>
> --
> [stillwa...@gmail.com ~]$ cat .signature
> cat: .signature: No such file or directory
> [stillwa...@gmail.com ~]$
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] RE-S-X6-64G-BB

[Colton Conor]

Assuming we are not going to be using these new RE's to load any 3rd party
software on them, the RE-S-X6-64G-BB will just be a quicker processor with
more ram compared to an older RE right? Are there any other benefits?
Juniper is offering the RE-S-X6-64G-BB for the same price as
the RE-S-1800X4-32G. Not sure why one would not go with the new RE with
more ram?

On Wed, May 25, 2016 at 9:34 AM, Saku Ytti  wrote:

> On 25 May 2016 at 17:10, raf  wrote:
>
> Hey,
>
> > On this point I disagree. Virtualization add a layer and a little
> overhead,
> > but nowadays it's a mature and stable technologies.
> > And splitting things and decoupling them are always a good things for
> me. I
> > talk about junos which was a relatively complex architecture; and
> splitting
> > them between muliple vm(s) shoud be good.
> > Two other point come in my mind : the opportunity to have an second
> virtual
> > standby RE, which it good for upgrade.
> > Or something I haven't considered at first, the reborn of real logicial
> > systems (multi tenant).
>
> I'm not sure we disagree. You're talking about virtualisation like
> we're moving components off JunOS into separate VM's, but this is not
> what is happening. These VM's are marketed to be there mostly for
> external/3rd party applications.
> Surely we agree, adding 3rd party VM on router cannot increase reliability.
>
> If vendors would be doing, what you're hoping, distributing their own
> control-plane in multiple VM (IOS-XR is sort of doing this, in LXC
> containers). Then I really have to ask, if you can talk between VM or
> LXC, why not talk over network, and have your compute separately for
> those components.
>
> > Yep unfortunately. I really think rpd design must be rethink-ed.
>
> I don't think anything major is being done to rpd in the roadmap,
> other than more threads on the single process.
>
> > Sure; but often network components are relatively isolated of the rest of
> > the DCs, so running all of them on a big hypervisor close to the
> forwarding
> > engine make sense (at least for me).
>
> Adding 1RU dell server to the rack wouldn't a problem. And perhaps
> this is options we can do in future, buy forwarding-plane box and then
> hook control-plane hardwares over ethernet to it. If we can separate
> control-plane on multiple VM, we can also do this. And I like the
> latter option even more.
>
> > Ah completely agree on this. Perhaps running small utilites vm (DNS,
> tools);
> > but corner case use.
>
> I don't see those corner cases as particularly useful. I can't help to
> wonder, is VM a white-label play in disguise? Are some customers not
> running IOS-XR/JunOS at all, just not starting that VM, instead
> running own VM with under NDA documents how to program the hardware?
> Or is the 3rd party VM just marketing gimmick, because they get VM
> 'for free', as they need it for their own infrastructure, to provide
> better redundancy, upgradability and loose coupling to underlaying
> control-plane HW. So as it is going to be there anyhow, no harm done
> investing some marketing efforts to see if market figures out if there
> is application for 3rd party VMs.
>
> --
>   ++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] EX4600 Vs QFX 5100 VS ACX 5048

[Colton Conor]

Adam,

I think because of the price point of the ASR903 just is not there. These
Juniper ACX5048's can be bought for under $5,000 new. The ASR903 with a
hefty discount was in the $15k range with like one line card. Even if you
fully populated the 903 it wouldn't have the same amount of ports as a
ACX5048. It would have more redundancy, and the ability to have a 100G
uplinks however.

On Thu, May 12, 2016 at 8:02 AM, Adam Vitkovsky 
wrote:

> Wondering why no one mentioned ASR903 with RSP3.
>
> It can do 100GE per slot (8x10Ge/2x40GE/1x100GE) and there are 6 slots.
> Two RSPs two PSUs (only FAN tray is single point of failure).
> And feature wise it should do everything that ASR920 does.
>
> Compared to Juniper the only drawback is the FIB scale which apparently is
> just 192,512 IPv4 routes.
>  -I guess the reason behind this is that if they would increase that it
> would compete with ASR9K line.
>
>
> 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] EX4600 Vs QFX 5100 VS ACX 5048

[Colton Conor]

Aaron,

Have you tested any of the OAM features on the ACX5048 like Y.1564,
802.3ah, 802.1ag, Y.1731, Two-Way Active Measurement Protocol (TWAMP) and
RFC2544? Do you have smaller ACX's like the 2200 connected to the ACX5048?
Are you using Juniper MX routers in your network as well?

On Tue, May 10, 2016 at 11:11 AM, Aaron  wrote:

> Hi Colton, first please understand that my motivation was to replace ~40
> cisco me3600’s eventually… we have deployed our cisco me3600’s as mpls pe’s
> with eline, elan, etree in eline pw ldp flavors and bgp ad w/ldp sig vpls
> flavors… and vpnv4/6 (junos speak inet/inet6) for mpls l3vpn’s… we needed
> more 10 gig interfaces as our FTTH subs were consuming lots of bw.  So I
> wanted an mpls edge box about 1 or 2 U high around the same price as the
> ME3600’s it would replace and bunches of 10 gig interface with some 40/100
> gig uplinks if possible.
>
>
>
> we compared...
>
>
>
> - Juniper ACX5048 – in lab
>
> - Juniper MX104 – in lab
>
> - Juniper EX4550 – in lab
>
> - Cisco ASR903 – in lab
>
> - Cisco ASR9001 – on paper
>
> - Cisco ASR903 – in lab
>
> - Cisco ASR920 (2 versions – in lab
>
> - Cisco NCS5001 (skywarp) – in lab
>
>
>
> I think the closest thing to the ACX5048 was the Cisco NCS5001…. But it
> was a dog in the lab trial.  Seriously, I had LLDP global config freeze up
> my ssh/telnet sessions… then l2vpn had serious issues and so did l3vpn.
> That ncs5k was not ready from prime time in the state (hw/xr sw) that I had
> it in.
>
>
>
> We went with the acx5048.  We bought (14) of them
>
>
>
> I just spent the last few days testing various mpls l2vpn architectures so
> that I can confidently proceed with installing them.  (I was told they
> support lots of stuff and I proved out **some** of it last fall, but I
> needed to get more experience on it… now I feel a bit better with the
> eline, elan, etree ideas if have now introducing the acx5048 into my mpls
> cloud with other 9k’s and me3600’s.
>
>
>
> Are there other mpls pe’s out there on the market ?  probably so…. I
> didn’t have time to test them all
>
>
>
> -Aaron
>
>
>
>
>
>
>
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4600 Vs QFX 5100 VS ACX 5048

[Colton Conor]

Aaron,

Thanks for the reply. Sounds like you compared the Juniper and Cisco
solutions, and landed on the Juniper ACX 5048. I guess my question is,
besides Juniper and Cisco, are there any other vendors worth looking into
that could realistically compete with the ACX5048? Sounds like your network
today is Cisco and Juniper only for routing which is fine and the standard,
but I am wondering what other options there are in this market.

There are ton's of other plain ethernet switches on the market with this
same Trident II chipset with 48 10G ports and 6 40G ports. But the control
plane and software side is what worries me compared to the Juniper
solution. Lots of whitebox solutions, but not sure if the software is there
from these open source third party network operating systems.

Anything from Ciena, Huawei, ALU, etc? Brocade doesn't have anything in
this price point or port count.

On Tue, May 10, 2016 at 11:11 AM, Aaron  wrote:

> Hi Colton, first please understand that my motivation was to replace ~40
> cisco me3600’s eventually… we have deployed our cisco me3600’s as mpls pe’s
> with eline, elan, etree in eline pw ldp flavors and bgp ad w/ldp sig vpls
> flavors… and vpnv4/6 (junos speak inet/inet6) for mpls l3vpn’s… we needed
> more 10 gig interfaces as our FTTH subs were consuming lots of bw.  So I
> wanted an mpls edge box about 1 or 2 U high around the same price as the
> ME3600’s it would replace and bunches of 10 gig interface with some 40/100
> gig uplinks if possible.
>
>
>
> we compared...
>
>
>
> - Juniper ACX5048 – in lab
>
> - Juniper MX104 – in lab
>
> - Juniper EX4550 – in lab
>
> - Cisco ASR903 – in lab
>
> - Cisco ASR9001 – on paper
>
> - Cisco ASR903 – in lab
>
> - Cisco ASR920 (2 versions – in lab
>
> - Cisco NCS5001 (skywarp) – in lab
>
>
>
> I think the closest thing to the ACX5048 was the Cisco NCS5001…. But it
> was a dog in the lab trial.  Seriously, I had LLDP global config freeze up
> my ssh/telnet sessions… then l2vpn had serious issues and so did l3vpn.
> That ncs5k was not ready from prime time in the state (hw/xr sw) that I had
> it in.
>
>
>
> We went with the acx5048.  We bought (14) of them
>
>
>
> I just spent the last few days testing various mpls l2vpn architectures so
> that I can confidently proceed with installing them.  (I was told they
> support lots of stuff and I proved out **some** of it last fall, but I
> needed to get more experience on it… now I feel a bit better with the
> eline, elan, etree ideas if have now introducing the acx5048 into my mpls
> cloud with other 9k’s and me3600’s.
>
>
>
> Are there other mpls pe’s out there on the market ?  probably so…. I
> didn’t have time to test them all
>
>
>
> -Aaron
>
>
>
>
>
>
>
>
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4600 Vs QFX 5100 VS ACX 5048

[Colton Conor]

Tim,

Do you use IP Infusion software today? I have never heard of them, but I
like the software feature set I see on their website with MPLS and MEF
features. However, I doubt the white box plus their software will be any
less than the Juniper solution, but I could be surprised.

On Tue, May 10, 2016 at 8:46 AM, Tim Jackson <jackson@gmail.com> wrote:

> You might be able to buy some off the shelf (E.g. Acton or quanta etc)
> white box Trident 2 box and look IP Infusion for an OS on it. It may be
> cost competitive and have almost all of the features..
> On May 10, 2016 8:31 AM, "Colton Conor" <colton.co...@gmail.com> wrote:
>
>> Aaron,
>>
>> Just wondering if you company compared any other products from other
>> vendors against the ACX5048? Is there anything else on the market with
>> this
>> high of port count, for this low of a price, with this amount of features?
>>
>> On Mon, May 9, 2016 at 11:52 AM, Aaron <aar...@gvtc.com> wrote:
>>
>> > Thanks Raphael,
>> >
>> > My core links are untagged typically... in rare case I'll tag, and it
>> > doesn't seem to be a problem, I haven't done that on acx5048 yet
>> >
>> > Ok I did MEF EPL (eline port based carrying any and all vlans, tagged
>> and
>> > untagged...) works. I shut and deactivate core bgp for this test to
>> prove
>> > that it's purely igp, mpls, ldp to make it work.  Ce-ce pings and
>> > l2protocols seem to be fine ( I tested cdp and stp for CE to CE and it's
>> > fine )...of course the config's below are the MPLS PE's... the ce's I
>> > mention are not shown anywhere here.
>> >
>> >
>> > ---3600
>> >
>> > interface GigabitEthernet0/15
>> >
>> >  switchport trunk allowed vlan none
>> >
>> >  switchport mode trunk
>> >
>> >  load-interval 30
>> >
>> >  service instance 1 ethernet
>> >
>> >   encapsulation default
>> >
>> >   l2protocol forward
>> >
>> >   xconnect 10.101.12.245 999 encapsulation mpls
>> >
>> > --- ACX5048
>> >
>> > set protocols l2circuit neighbor 10.101.12.251 interface ge-0/0/38.0
>> > virtual-circuit-id 999
>> >
>> > set interfaces ge-0/0/38 encapsulation ethernet-ccc
>> >
>> > set interfaces ge-0/0/38 unit 0 family ccc
>> >
>> > - Aaron
>> >
>> >
>> > ___
>> > 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] EX4600 Vs QFX 5100 VS ACX 5048

[Colton Conor]

Aaron,

Just wondering if you company compared any other products from other
vendors against the ACX5048? Is there anything else on the market with this
high of port count, for this low of a price, with this amount of features?

On Mon, May 9, 2016 at 11:52 AM, Aaron  wrote:

> Thanks Raphael,
>
> My core links are untagged typically... in rare case I'll tag, and it
> doesn't seem to be a problem, I haven't done that on acx5048 yet
>
> Ok I did MEF EPL (eline port based carrying any and all vlans, tagged and
> untagged...) works. I shut and deactivate core bgp for this test to prove
> that it's purely igp, mpls, ldp to make it work.  Ce-ce pings and
> l2protocols seem to be fine ( I tested cdp and stp for CE to CE and it's
> fine )...of course the config's below are the MPLS PE's... the ce's I
> mention are not shown anywhere here.
>
>
> ---3600
>
> interface GigabitEthernet0/15
>
>  switchport trunk allowed vlan none
>
>  switchport mode trunk
>
>  load-interval 30
>
>  service instance 1 ethernet
>
>   encapsulation default
>
>   l2protocol forward
>
>   xconnect 10.101.12.245 999 encapsulation mpls
>
> --- ACX5048
>
> set protocols l2circuit neighbor 10.101.12.251 interface ge-0/0/38.0
> virtual-circuit-id 999
>
> set interfaces ge-0/0/38 encapsulation ethernet-ccc
>
> set interfaces ge-0/0/38 unit 0 family ccc
>
> - Aaron
>
>
> ___
> 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] EX4600 Vs QFX 5100 VS ACX 5048

[Colton Conor]

Mark,

Which problems does the ACX5048 have today? I realize there are multiple
models, but I specifically am talking about the ACX5048.

Also, Comcast is deploying the ACX2200 for their 2Gbps fiber to the
home/business product. I assume that means they are low cost devices.

So ASR920 vs Juniper ACX, what features are missing that you are getting
with the Cisco that you don't get with the Juniper? I realize this is an
unfair match. The ASR920 tops out at 6 10G interfaces. The ACX5048 has 48
10G and 6 40G interfaces. Price wise, both cost about the same to activate
6 10G ports on each. On the Juniper the 6 40G ports are enabled on the base
license.

On Tue, May 3, 2016 at 3:07 PM, Mark Tinka  wrote:

>
>
> On 3/May/16 16:22, Saku Ytti wrote:
>
> > What is reasonable price? How much less than 3500EUR it needs to cost?
>
> Oooh, it can cost less :-).
>
>
> > Also if you look at actual CAPEX costs of running say mobile network,
> > the cost of IP equipment simply does not matter.
>
> Fair point - if it's a mobile network, budget for some IP routers may
> not be an issue.
>
> >  It matters to your BU
> > and thus your budget, but that is very narrow-minded planning, if
> > upper management does not see that you need more budget to do it right
> > and it does not impact bottom line, then you didn't do your homework
> > when choosing your employer.
>
> Agree.
>
> > I'm pretty sure the are MUCH happier with MX80 than they would have
> > been with Whales. I don't think Whales even support everything they
> > do, certainly didn't back then. They use NG-MVPN, seamless MPLS, L3
> > MPLS VPN at scale, per-vlan HQoS, RSVP-TE with affinity and list goes
> > on.
>
> Most of this supported on the ME3600X/3800X. The only one I know that is
> lacking is NG-MVPN support. Cisco kept pushing Rosen our way to avoid
> developing NG-MVPN on the ME3600X/3800X. Eventually, they got bored of
> the platform and put all their energy into the ASR920, which has NG-MVPN
> support natively.
>
>
> > I disagree. ASR1k does stateful firewalling, NAPT, crypto etc. None of
> > these what MX104 can do, unless you count putting another cpu in the
> > box with MS-MIC.
> > I don't think JNPR really has anything to compete against ASR1k.
>
> Fair enough.
>
> I was looking more at general routing features (we would not use an edge
> router as a firewall).
>
> The main competitor we needed for the ASR1000 was a box that could
> combine both high speed Ethernet and low speed non-Ethernet interfaces
> in the same chassis at a cost that makes sense. The ASR1000 does that
> very well, and for now, the MX104 does that well too.
>
> But I agree that when it comes to other high-touch features, the ASR1000
> kicks the MX104 hard!
>
>
> > ACX is definitely their competitor, may not be there for your
> > application (and this may be true for some other applications, someone
> > may not be able to do on ASR920 what ACX2k does), but both problems
> > are solvable by throwing money at it.
>
> I've asked Juniper to solve the problems on the ACX. They flat-out refused.
>
> They won't say I never gave them a chance - more times than they deserve.
>
> 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] EX4600 Vs QFX 5100 VS ACX 5048

[Colton Conor]

Mark,

Which ASR920 model do you use, and do they all operate the same? Based on
the model comparison there is not much difference between them, but it does
look like the ASR-920-12SZ-IM has a Quad-core 1.2 GHz where the rest of the
models have a Dual-core 1 GHz.

Looks like the ASR-920-12SZ-IM has the ability to add a 1 port 10G IM card
making 5 10G ports total. The ASR-920-24SZ-IM has the ability to support
the 2 port 10G IM card, for a total of 6 10G ports. Kind of surprising
since the ASR-920-12SZ-IM has the faster processor.  Both the
ASR-920-24SZ-IM and ASR-920-12SZ-IM have the same list price of $7,000 from
Cisco.

Model comparision here:
http://www.cisco.com/c/en/us/products/routers/asr-920-series-aggregation-services-router/models-comparison.html

On Tue, May 3, 2016 at 8:27 AM, Mark Tinka  wrote:

>
>
> On 3/May/16 14:43, Harald F. Karlsen wrote:
>
> >
> > I would say it depends on the market they aim for. If they could price
> > a small form-factor Trio-based device to compete with the smaller ASRs
> > (or even ME switches) they could ramp up production and hence decrease
> > production cost. I really think a lot of service providers want MPLS
> > closer to the edge and I think it's a big market for anyone who makes
> > a MPLS-capable device with a proper FIB, decent control-plane and
> > proper MPLS features (P2MP LSPs would be nice).
>
> The ASR920 supports p2mp RSVP-TE LSP's as well as mLDP.
>
> Actually, we dropped the ACX purely because of lack of this.
>
>
> > Someone smarter than me should figure out how to create such a device
> > without cannibalizing their existing products.
>
> That's my approach. If a business is hungry enough for a market, they'll
> do the work.
>
>
> >
> > TLDR; I want to replace my metro switches with proper MPLS routers and
> > only spend marginally more on it. I personally think there's a big
> > market for whoever makes such a device.
>
> The market is massive.
>
> > I agree. Lower height and depth is of course better, but I agree that
> > depth is the biggest concern for a lot of telcos. For datacenters,
> > height is usually the biggest concern. A lot of SPs operate in both
> > domains so it's all about finding the best compromise (or maybe two
> > different SKUs?).
>
> The ASR920 is slightly less deep than the MX104 (23.9cm for the ASR920
> and 24.13cm for the MX104). The 1U is the cherry on top.
>
> 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] EX4600 Vs QFX 5100 VS ACX 5048

[Colton Conor]

Jerry,

Can you go into more details about the ACX's "many more MPLS and CE
features compared to the QFX" The QFX already has many more MPLS features
than an EX4600.

The ACX juniper seems to sell at a high price premium compared to the
QFX5100. Same hardware, just different stand of Junos. I want to know what
enhanced features the ACX has over the QFX5100.

On Fri, Apr 29, 2016 at 1:06 PM, Jerry Jones <jjo...@danrj.com> wrote:

> The ACX has many more MPLS and CE features compared to the QFX.
>
>
> On Apr 29, 2016, at 11:35 AM, Colton Conor <colton.co...@gmail.com> wrote:
>
> Besides port count and expansion modules, what is the main differences
> between these three Juniper switches (actually Juniper has the ACX under
> their router section on their website). I believe all three use Broadcom
> Trident II chips.
>
> This Juniper doc says:
>
> Even though QFX5100 and EX4600 Switches use the same chipset, MPLS support
> differs.EX4600 switches support only basic MPLS functionality while QFX5100
> switches support some of the more advanced features. See “MPLS Feature
> Support on QFX Series and EX4600 Switches” on page 17 for details.
>
> http://www.juniper.net/techpubs/en_US/junos14.1/information-products/pathway-pages/ex4600/mpls.pdf
>
> The ACX seems interesting. I know it is MEF 2.0 certified while the other
> two are not. Besided MEF certification I would like to know how it differs
> from the QFX5100 as the port count is identical.
>
> Does anyone have experience with these three platforms?
> ___
> 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] EX4600 Vs QFX 5100 VS ACX 5048

[Colton Conor]

So that would replace what, their currently MX5 through MX240 line of
products? Why would Juniper do that when they already have products that
meet those specifications? Don't get me wrong I would love to see the same
box, but I just have a hard time believing big J and C are going to make a
small dense box like we all want at a competitive price point. They might
be forced to with Arista's new offerings however.

On Mon, May 2, 2016 at 4:19 AM, Harald F. Karlsen  wrote:

> On 30.04.2016 11:49, Mark Tinka wrote:
>
>> When the vendors figure out how to deliver cheap 10Gbps ports on custom
>> chips in a 1U chassis, I'll be the first one to buy.
>>
>
> +1
>
> I'd love to see a 1U (or 2U 300mm deep) TRIO-based metro device with >20
> 1/10G interfaces (with proper buffers and QoS) and 2-4 40/100G interfaces.
> Preferably with a decent control-plane as well (Intel Atom or Xeon) and at
> a competitive price.
>
> --
> Harald
>
> ___
> 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] EX4600 Vs QFX 5100 VS ACX 5048

[Colton Conor]

I will believe it when I see it. A small 1U box with say 24 10G ports would
kill the rest of their offerings, so I don't expect it to be low cost which
is needed for metro deployments.

On Sun, May 1, 2016 at 12:21 AM, Youssef Bengelloun-Zahr 
wrote:

> Hence a 1U "mini" version of the MLXe. It wouldn't be a CER box.
>
> Let's see what the futur holds.
>
> BR.
>
>
>
> > Le 1 mai 2016 à 00:02, Mark Tinka  a écrit :
> >
> >
> >
> >> On 30/Apr/16 21:14, Youssef Bengelloun-Zahr wrote:
> >>
> >>
> >> But the MLXe platform is a very capable Metro-E box with lots of the
> usual features.
> >
> > So is the MX480/960, ASR9010/9912, SR7750. Problem all these are too
> > large and cost too much for Metro-E applications.
> >
> > Mark.
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4600 Vs QFX 5100 VS ACX 5048

[Colton Conor]

Mark,

I looked at Brocade as well, but on their carrier ethernet page they only
list the CES which has max 4 10G ports. The only thing that has more than 4
10G ports and is MEF certified seems to be their larger MLXe routers. Those
are more built for core than metro access.


On Sat, Apr 30, 2016 at 4:49 AM, Mark Tinka <mark.ti...@seacom.mu> wrote:

>
>
> On 30/Apr/16 02:24, Colton Conor wrote:
>
> So the Cisco 5001 is the direct competitor to the Juniper ACX5048. Both
> seem to be based off the Broadcom Trident II.  Mark can you give me more
> details on the reasons why the Broadcom based offerings are such a bad
> option?
>
>
> I'm not saying the Broadcom chip is bad, I'm saying that if you are used
> to having a ton of features easily available and accessible on the MX Trio,
> you might be in for a shock on the Broadcom chip. We dumped the ACX because
> the chip could not do certain things we felt were important to us, and the
> ASR920 could (for more than half the price anyway). I know Aaron has been
> struggling with VLAN mapping on the ACX this last week. Although I'm not
> sure if that is related to the Broadcom chip, such capability is
> straightforward on the Trio chips.
>
>
> I know you like the ASR920, but 4 10G ports is not enough.
>
>
> True, but looking at the cost and features of the ASR920, and the value it
> gives us when running IP/MPLS services in the Access, it's cheaper for me
> to run dedicated dark fibre to a larger PoP for 10Gbps requirements in some
> places, or deploy DWDM pizza boxes alongside my ASR920's in others.
>
> For us, feature parity across all vendor equipment regardless of function,
> size or location is much more important than anything else.
>
> When the vendors figure out how to deliver cheap 10Gbps ports on custom
> chips in a 1U chassis, I'll be the first one to buy.
>
>
>
> Besides Cisco and Juniper solutions discussed, what else is out there that
> has more than 4 10G ports with these feature sets?
>
>
> Look at Brocade.
>
> I'm not sure what they are doing now, but back then, they had a solid 1U
> Metro-E box. We never bought it because we wanted to keep two vendors only
> in our network. Technically, the box was/is sound. But I'd definitely buy
> them for some specific use cases we are working on.
>
> Mark.
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4600 Vs QFX 5100 VS ACX 5048

[Colton Conor]

So the Cisco 5001 is the direct competitor to the Juniper ACX5048. Both
seem to be based off the Broadcom Trident II.  Mark can you give me more
details on the reasons why the Broadcom based offerings are such a bad
option? I know you like the ASR920, but 4 10G ports is not enough.

Aaron, do you think the problems with the NCS5001 still exists? How long
ago did you test those? And just to confirm those are not present on the
ACX5048?

Besides Cisco and Juniper solutions discussed, what else is out there that
has more than 4 10G ports with these feature sets?

On Fri, Apr 29, 2016 at 4:10 PM, Aaron <aar...@gvtc.com> wrote:

> Yw Colton
>
>
>
> Yes we are mostly cisco as we deployed an mpls network a few years back
> with asr9k core and me3600 distribution… asr901 at cell sites…
>
>
>
> Yes Colton cisco has 1U box, more about that below… NCS5K
>
>
>
> Agreed Colton the ASR920 tops out at too few 10 gig interfaces to be
> considered for my eval
>
>
>
> Business case ?  perhaps the primary driving factor was in our ftth
> broadband network where we are selling tons of bw to our subs….those calix
> e7 olt’s have dual 10 gig uplinks and will have more in the future… to keep
> up with the pace of BW consumption we needed more 10 gig interfaces in the
> distribution layer of our network… the current device there was Cisco’s
> ME3600 with only (2) 10 gig (4 on the CX model)
>
>
>
> We determined that we wanted (8) or more 10 gigs in an mpls capable box
> similar in size/function as the cisco me3600 that we widely deployed…
>
>
>
> We had deployed the ME3600 with MPLS L2VPN and L3VPN so we needed a box
> that could do that also.  We also deployed MEF-style eline, elan, etree
> services within the me3600’s and asr9k’s so I needed a box that could do
> that also.  (aka, vpls, vpws, bgp-ad w/ldp-sig auto-vpls)…also deployed was
> mpls l3vpn vrf for ipv4 (aka vpnv4, inet-vpn) and with plans to go to 6VPE
> (aka mpls l3vpn w/ipv6 support)… so yeah, I needed all that…
>
>
>
> we ruled out the cisco asr920 was it tops out with (6) 10 gig
>
>
>
> we ruled out the cisco ncs5k as it was problematic in its infancy.  I was
> attracted to this box with (~40) 10 gig and (4) 100 gig, but the problems
> were to great (bad issues with l3vpn and l2vpn) and some things just
> weren’t even there yet.
>
>
>
> We ruled out cisco asr903 and juniper mx104 style modular/larger boxes as
> me3600 replacements since they  were bigger… and not quite what we were
> looking for…
>
>
>
> We liked and settled on the juniper acx5048…
>
>
>
> Hope that helps…
>
>
>
> - Aaron
>
>
>
>
>
> *From:* Colton Conor [mailto:colton.co...@gmail.com]
> *Sent:* Friday, April 29, 2016 3:29 PM
> *To:* Aaron <aar...@gvtc.com>
> *Cc:* Jerry Jones <jjo...@danrj.com>; Juniper List <
> juniper-nsp@puck.nether.net>
>
> *Subject:* Re: [j-nsp] EX4600 Vs QFX 5100 VS ACX 5048
>
>
>
> Aaron,
>
>
> Thanks for the information and real world examples. Great to hear you got
> Cisco and Juniper to work together as well. Sounds like you had Cisco in
> your network today, and are adding Juniper. What was the business case or
> reason for this? Is it because Cisco does not have a similar MEF 10G 1U
> box? If they do I am not aware what model it is. Most are recommending an
> ASR920, but that only has like 4 10G interfaces.
>
>
>
> On Fri, Apr 29, 2016 at 3:06 PM, Aaron <aar...@gvtc.com> wrote:
>
> I recently purchased several ACX5048's and am testing and deploying them as
> we speak...all in all, I'm pleased thus far.  This is pretty much my first
> experience with Juniper/MPLS devices.
>
> I got a working scenario as of yesterday of EVPLAN (MEF-speak for ELAN with
> tagging on PE-CE handoff)...(basically VPLS Routing Instance with BGP AD
> and
> LDP Sig) the JTAC was helpful in understanding the PE-CE Junos Ethernet tag
> push/pop I needed.  This is interoperating with IOS XR (asr9k) and Classic
> IOS (ME3600).  One glitch was noticed but it might be a subtlety during
> service activation/change, but was also only seen on the 9k XR side as a
> down'd psuedowire... (j)tac cases are in the works to understand why that
> occurred.  Other than that acx5048, me3600, asr9k are working in a RFC4762
> VPLS scenario.
>
> I will say that JTAC did not know how to do this right away... it took them
> a day or more to figure it out.  JTAC said that this ACX5048 platform is
> fairly new and they are learning it as well.  (this was the person I talked
> to anyway)
>
> I have a working scenario with MPLS L3VPN on the ACX5048 also...
> inet-vpn...
> this is also interop'ing just fine with ME3600 and ASR9k...
>
&g

Re: [j-nsp] EX4600 Vs QFX 5100 VS ACX 5048

[Colton Conor]

Aaron,

Thanks for the information and real world examples. Great to hear you got
Cisco and Juniper to work together as well. Sounds like you had Cisco in
your network today, and are adding Juniper. What was the business case or
reason for this? Is it because Cisco does not have a similar MEF 10G 1U
box? If they do I am not aware what model it is. Most are recommending an
ASR920, but that only has like 4 10G interfaces.

On Fri, Apr 29, 2016 at 3:06 PM, Aaron <aar...@gvtc.com> wrote:

> I recently purchased several ACX5048's and am testing and deploying them as
> we speak...all in all, I'm pleased thus far.  This is pretty much my first
> experience with Juniper/MPLS devices.
>
> I got a working scenario as of yesterday of EVPLAN (MEF-speak for ELAN with
> tagging on PE-CE handoff)...(basically VPLS Routing Instance with BGP AD
> and
> LDP Sig) the JTAC was helpful in understanding the PE-CE Junos Ethernet tag
> push/pop I needed.  This is interoperating with IOS XR (asr9k) and Classic
> IOS (ME3600).  One glitch was noticed but it might be a subtlety during
> service activation/change, but was also only seen on the 9k XR side as a
> down'd psuedowire... (j)tac cases are in the works to understand why that
> occurred.  Other than that acx5048, me3600, asr9k are working in a RFC4762
> VPLS scenario.
>
> I will say that JTAC did not know how to do this right away... it took them
> a day or more to figure it out.  JTAC said that this ACX5048 platform is
> fairly new and they are learning it as well.  (this was the person I talked
> to anyway)
>
> I have a working scenario with MPLS L3VPN on the ACX5048 also...
> inet-vpn...
> this is also interop'ing just fine with ME3600 and ASR9k...
>
> I did a brief test with ELINE (mef speak for p-to-p pw) and seemed ok
>
> I have a few more things I need to test, but at this point I've been
> pleased
> with the ACX5048.
>
> I love the (48) 10 gig interfaces (6) 40 gig in a 1U size !
>
> - Aaron
>
> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> Of
> Jerry Jones
> Sent: Friday, April 29, 2016 1:07 PM
> To: Colton Conor <colton.co...@gmail.com>
> Cc: Juniper List <juniper-nsp@puck.nether.net>
> Subject: Re: [j-nsp] EX4600 Vs QFX 5100 VS ACX 5048
>
> The ACX has many more MPLS and CE features compared to the QFX.
>
>
> On Apr 29, 2016, at 11:35 AM, Colton Conor <colton.co...@gmail.com> wrote:
>
> Besides port count and expansion modules, what is the main differences
> between these three Juniper switches (actually Juniper has the ACX under
> their router section on their website). I believe all three use Broadcom
> Trident II chips.
>
> This Juniper doc says:
>
> Even though QFX5100 and EX4600 Switches use the same chipset, MPLS support
> differs.EX4600 switches support only basic MPLS functionality while QFX5100
> switches support some of the more advanced features. See "MPLS Feature
> Support on QFX Series and EX4600 Switches" on page 17 for details.
>
> http://www.juniper.net/techpubs/en_US/junos14.1/information-products/pathway
> -pages/ex4600/mpls.pdf
>
> The ACX seems interesting. I know it is MEF 2.0 certified while the other
> two are not. Besided MEF certification I would like to know how it differs
> from the QFX5100 as the port count is identical.
>
> Does anyone have experience with these three platforms?
> ___
> 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

[j-nsp] EX4600 Vs QFX 5100 VS ACX 5048

[Colton Conor]

Besides port count and expansion modules, what is the main differences
between these three Juniper switches (actually Juniper has the ACX under
their router section on their website). I believe all three use Broadcom
Trident II chips.

This Juniper doc says:

Even though QFX5100 and EX4600 Switches use the same chipset, MPLS support
differs.EX4600 switches support only basic MPLS functionality while QFX5100
switches support some of the more advanced features. See “MPLS Feature
Support on QFX Series and EX4600 Switches” on page 17 for details.
http://www.juniper.net/techpubs/en_US/junos14.1/information-products/pathway-pages/ex4600/mpls.pdf

The ACX seems interesting. I know it is MEF 2.0 certified while the other
two are not. Besided MEF certification I would like to know how it differs
from the QFX5100 as the port count is identical.

Does anyone have experience with these three platforms?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Full routes on MX5

[Colton Conor]

Eduardo,

So if I am reading that right, the box is using 96 percent of its memory?
It looks like it has 2 Million routes, so is that 4 full BGP
tables/upstream providers?

On Tue, Apr 26, 2016 at 1:17 PM, Eduardo Schoedler 
wrote:

> 2016-04-26 13:15 GMT-03:00 Javier Rodriguez :
> > Hi,
> >
> > How much memory is left available with one full table on a MX80?
> > I have a problem with routes at the process installation into the FIB
> (KRT)
> > and they remain pending for a long time. Do you know if this issue is
> > related to memory? How can i solve it?.
>
> Hi Javier,
>
> This router is a MX80.
> They also have an running logical-instance:
>
> login@rtr> show chassis routing-engine
> Routing Engine status:
> Temperature 45 degrees C / 113 degrees F
> CPU temperature 54 degrees C / 129 degrees F
> DRAM  2048 MB (2048 MB installed)
> Memory utilization  96 percent
> CPU utilization:
>   User   5 percent
>   Background 0 percent
>   Kernel10 percent
>   Interrupt  3 percent
>   Idle  82 percent
> Model  RE-MX5-T
> Load averages: 1 minute   5 minute  15 minute
>0.19   0.17   0.16
>
> login@rtr> show route summary
> Autonomous system number: x
> Router ID: x.x.x.x
>
> inet.0: 599618 destinations, 2057043 routes (591234 active, 16
> holddown, 133589 hidden)
>   Direct: 18 routes, 18 active
>Local: 17 routes, 17 active
> OSPF: 39 routes, 37 active
>  BGP: 2056944 routes, 591145 active
>   Static: 25 routes, 17 active
>
> inet6.0: 29364 destinations, 130976 routes (29363 active, 0 holddown,
> 290 hidden)
>   Direct: 20 routes, 13 active
>Local: 18 routes, 18 active
>OSPF3: 20 routes, 20 active
>  BGP: 130916 routes,  29311 active
>   Static:  2 routes,  1 active
>
> login@rtr:LS-GIGA> show route summary
> Autonomous system number: y
> Router ID: y.y.y.y
>
> inet.0: 110496 destinations, 195742 routes (110496 active, 13
> holddown, 0 hidden)
> Restart Complete
>   Direct:  3 routes,  3 active
>Local:  2 routes,  2 active
> OSPF:208 routes,208 active
>  BGP: 195529 routes, 110283 active
>
>
> --
> Eduardo Schoedler
> ___
> 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] MX80 base model

[Colton Conor]

Go with a MX104 not a MX80. New a MX104 is less expensive than a MX80.

On Mon, Apr 25, 2016 at 5:36 PM, Doug McIntyre  wrote:

> On Mon, Apr 25, 2016 at 06:20:45PM -0400, Satish Patel wrote:
> > I talked to one of vendore he gave me following price for MX80. Does
> > MX80 base model support 20G throughput? or do i need to buy license to
> > use more 20G?
>
> The MX80 allows 40Gbps throughput (or 80Gbps in Marketing speak).
>
> > in around $17k price. i will get following. Does 4x10GE fix port are
> > locked or i need to unlock them?
>
> The MX80 come with all ports licensed. You are confusing the MX20/MX40
> with the MX80, which are the port license restricted models, that are
> usually more expensive than the bas MX80 to start with.
>
> ___
> 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] MPC-3D-16XGE-SFPP-R-B VS MPC-3D-16XGE-SFPP

[Colton Conor]

What are the difference between these two cards?

Based on the descriptions found online, the MPC-3D-16XGE-SFPP-R-B offers
full scale L3 features whereas the MPC-3D-16XGE-SFPP offers reduced scale
L3 features and requires license to support full scale L3 routes and L3VPN.

What is the difference between full scale L3 vs reduced scale L3 in Juniper
terms?

I asked a reseller about this, and they mentioned that Juniper does not
software restrict the MPC-3D-16XGE-SFPP in the current code, so you might
as well buy the lower cost MPC-3D-16XGE-SFPP. He said you don't have to
input a license. Is this true?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Best Place to Buy Used Juniper

[Colton Conor]

Graham,

I have never seen this  http://junipercpo.net/ website until now. Are they
really any different than the rest of the used Juniper guys? How does their
pricing compare to what you see on eBay for example?

On Sat, Mar 26, 2016 at 5:44 PM, Graham Brown <juniper-...@grahambrown.info>
wrote:

> Hi Colton,
>
> The official used, Juniper-certified gear is available here:
> http://junipercpo.net/
>
> HTH,
> Graham
>
> Graham Brown
> Twitter - @mountainrescuer <https://twitter.com/#!/mountainrescuer>
> LinkedIn <http://www.linkedin.com/in/grahamcbrown>
>
> On 27 March 2016 at 06:10, Colton Conor <colton.co...@gmail.com> wrote:
>
>> Where is the best place to buy used Juniper gear?
>> ___
>> 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] Best Place to Buy Used Juniper

[Colton Conor]

Where is the best place to buy used Juniper gear?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Optimizing the FIB on MX

[Colton Conor]

Saku,

You seems to know a bit about processors to say the least.

What processor is in the Cisco 9001, and how does it compare to a MX104 in
terms of speed and BGP Performance?

What about a Cisco 9010 ASR9K Route Switch Processor with 440G/slot Fabric
and 6GB?

On Thu, Feb 18, 2016 at 8:12 AM, Saku Ytti <s...@ytti.fi> wrote:

> On 18 February 2016 at 15:31, Colton Conor <colton.co...@gmail.com> wrote:
> > So is the MX-104 processor really that underpowered? I have heard reports
> > that is was too underpowered for its pricepoint, and now I am starting to
> > believe it. Vincent what are your thoughts?
>
> Define underpowered?
>
> MX80 has 8572, also sported by platforms such as sup7, sup2t, nexus7k,
> me3600x, sfm3-12@alu
> RSP720, EX8200 RE have even slower spec cpu 8548
>
> MX104 has faster cpu than any of these, P5021. Yet RSP720 runs circles
> around MX104 in terms of BGP performance.
>
> I'd say it is underpowered for JunOS (All PPC's are, but is that HW or
> SW issue, that's debatable), but it really can't be considered
> particularly slow cpu in this market generally, especially during its
> launch year.
>
> --
>   ++ytti
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Optimizing the FIB on MX

[Colton Conor]

So is the MX-104 processor really that underpowered? I have heard reports
that is was too underpowered for its pricepoint, and now I am starting to
believe it. Vincent what are your thoughts?

On Wed, Feb 17, 2016 at 5:14 PM, Vincent Bernat  wrote:

>  ❦ 17 février 2016 22:56 GMT, Adam Vitkovsky  > :
>
> >> Being a bit unsatisfied with a pair of MX104 turning themselves as a
> blackhole
> >> during BGP convergence, I am trying to reduce the size of the FIB.
> >>
> > You mentioned earlier that this is a new installation so why not use
> > routing instance for Internet which allows you to use PIC with your
> > current version of code and save you all this trouble duck-taping the
> > solution together.
>
> You are right. I didn't understand your answer the first time as I
> thought that PIC was for "programmable integrated circuit", so I thought
> this was a plan for Juniper to fix the problem with some dedicated piece
> of hardware.
> --
> Truth is the most valuable thing we have -- so let us economize it.
> -- Mark Twain
> ___
> 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] MX960 Power Options

[Colton Conor]

So from what I gather, there are 4 AC power supplies, and each AC power
supply has two plugs. So thats not really going to change, its more what
power to order from the datacenter.

So can I get away with one A side 208V/ 30 AMP circuit and one B side
208V/30AMP circuit?

208V X 30AMP X .80 Max Load = 4,992 watts. That's a lot.

Are you saying I ideally need double this? Why?

On Mon, Jan 25, 2016 at 10:20 PM, Chuck Anderson <c...@wpi.edu> wrote:

> I recommend 4 x 208V.  The MX960 uses "power zones" in a 2+2
> arrangement where half of the chassis is powered by 2 PEMs, and the
> other half of the chassis is powered by the other 2 PEMs.  Make sure
> the 1st PEM for each zone is powered by the A feed, and the 2nd PEM
> for each zone is powered by the B feed.  For dual-input PEMs, you
> should put both inputs of a single PEM on the same branch circuit,
> either A or B.
>
> I would use two PDUs to break out the two 208V/30AMP outlets to
> multiple C19's (plus any C13's you need), and then use C19/C20 cords.
> Each branch circuit PDU will have 4 C19/C20 cords connected (2 PEMs x
> 2 inputs per PEM).  Alternatively you could use L6-20 PDU
> outlets/cords.
>
> On Mon, Jan 25, 2016 at 09:25:02PM -0600, Colton Conor wrote:
> > What are the options for powering a MX960 using AC power? The datacenter
> > provider is offering us power  in the following options:
> >
> > 120V/20AMP A/B Power
> > 120V/30AMP A/B Power
> > 208V/30AMP A/B Power
> >
> > We are leaning towards using a MX960 with 4 AC power supplies and limited
> > cards installed. More than likely we will order the 208V/30AMP A/B Power
> > from the datacenter, but want to know if this will be enough? What does
> > Juniper recommend?
> ___
> 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] MX960 Power Options

[Colton Conor]

Do most data center providers offer this 400V? The next step up from the
208V/30AMP A/B side was a 208V/30A/3-Phase Power A/B side. I have never
dealt with 3 phase before does the MX960 support 3 phase? Not sure if this
matters, but the 208V/30A/3-Phase Power is double the cost
of 208V/30A/Single Phase Power.

On Tue, Jan 26, 2016 at 9:57 AM, Youssef Bengelloun-Zahr <yous...@720.fr>
wrote:

> Hello Colton,
>
> For that kind of devices using lots of C19 plugs and high wattage PSU
> (>2kW), you can also go with 400V/30AMP power feeds.
>
> We find that solution more efficient for that particular case, for example
> when use power 4 blade chassis in a rack (two chassis per pair of plugsets).
>
> Best regards.
>
>
>
> 2016-01-26 16:50 GMT+01:00 Colton Conor <colton.co...@gmail.com>:
>
>> So from what I gather, there are 4 AC power supplies, and each AC power
>> supply has two plugs. So thats not really going to change, its more what
>> power to order from the datacenter.
>>
>> So can I get away with one A side 208V/ 30 AMP circuit and one B side
>> 208V/30AMP circuit?
>>
>> 208V X 30AMP X .80 Max Load = 4,992 watts. That's a lot.
>>
>> Are you saying I ideally need double this? Why?
>>
>> On Mon, Jan 25, 2016 at 10:20 PM, Chuck Anderson <c...@wpi.edu> wrote:
>>
>> > I recommend 4 x 208V.  The MX960 uses "power zones" in a 2+2
>> > arrangement where half of the chassis is powered by 2 PEMs, and the
>> > other half of the chassis is powered by the other 2 PEMs.  Make sure
>> > the 1st PEM for each zone is powered by the A feed, and the 2nd PEM
>> > for each zone is powered by the B feed.  For dual-input PEMs, you
>> > should put both inputs of a single PEM on the same branch circuit,
>> > either A or B.
>> >
>> > I would use two PDUs to break out the two 208V/30AMP outlets to
>> > multiple C19's (plus any C13's you need), and then use C19/C20 cords.
>> > Each branch circuit PDU will have 4 C19/C20 cords connected (2 PEMs x
>> > 2 inputs per PEM).  Alternatively you could use L6-20 PDU
>> > outlets/cords.
>> >
>> > On Mon, Jan 25, 2016 at 09:25:02PM -0600, Colton Conor wrote:
>> > > What are the options for powering a MX960 using AC power? The
>> datacenter
>> > > provider is offering us power  in the following options:
>> > >
>> > > 120V/20AMP A/B Power
>> > > 120V/30AMP A/B Power
>> > > 208V/30AMP A/B Power
>> > >
>> > > We are leaning towards using a MX960 with 4 AC power supplies and
>> limited
>> > > cards installed. More than likely we will order the 208V/30AMP A/B
>> Power
>> > > from the datacenter, but want to know if this will be enough? What
>> does
>> > > Juniper recommend?
>> > ___
>> > 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
>>
>
>
>
> --
> Youssef BENGELLOUN-ZAHR
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] MX960 Power Options

[Colton Conor]

What are the options for powering a MX960 using AC power? The datacenter
provider is offering us power  in the following options:

120V/20AMP A/B Power
120V/30AMP A/B Power
208V/30AMP A/B Power

We are leaning towards using a MX960 with 4 AC power supplies and limited
cards installed. More than likely we will order the 208V/30AMP A/B Power
from the datacenter, but want to know if this will be enough? What does
Juniper recommend?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX960 with 3 RE's?

[Colton Conor]

Mark,

Thanks for the information.What is the smallest non-DPC 10G card you would
recommend? I am probably going to have a hard to getting away with DPC due
to the cost. A 4 port 10G DPC card can be had for under $1K on the used
market.

On Wed, Jan 13, 2016 at 11:45 PM, Mark Tinka <mark.ti...@seacom.mu> wrote:

>
>
> On 14/Jan/16 02:07, Colton Conor wrote:
>
> Well it would be RE-S-2000-4096 running the JTAC Recommended Junos
> Software Version Junos 13.3R8 plus the standard (not enhanced SCBs).
>
> I know more memory and 64 bit is usually better, but how does this help in
> Junos? From past threads, we have concluded that Junos is currently single
> thread/core in most all situations, and the RE-S-2000-4096 is faster than
> the RE in a MX80 and MX104. What does the more cores and quadruple memory
> get you in the RE-S-1800X4-16G that you can not do on a RE-S-2000-4096?
>
> The use case for this box would be full BGP tables and routing with 4+
> providers on 10G ports, plus a couple of ports to a peering exchange.
>
>
> As others running the RE-S-2000 have confirmed, you can run a recent Junos
> release on that RE today, which is great.
>
> The 64-bit RE gives you more memory to hold more routes, but if you only
> need 4x full BGP feeds today, the RE-S-2000 should be fine. Naturally, the
> newer RE will provide longer-term support for later Junos releases
> (especially with the architectural differences between Junos 15 and
> anything else before it). But in your case, the RE-S-2000 should be just
> fine.
>
> I am wondering what features the DPC's lack in this situation.
>
>
> - Lots of QoS limitations on the DPC compared to Trio.
> - Multicast restrictions on the DPC vs. the Trio.
> - No support for inline jflow on the DPC.
> - Differences in Tunnel PIC support on the DPC vs. the Trio (Trio is
> more flexible).
> - There may also be differences in Carrier Ethernet capabilities.
>
> I think you can get away with the RE-S-2000, but if you can, stay away
> from the DPC, just for peace of mind.
>
> Mark.
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX960 with 3 RE's?

[Colton Conor]

Thanks for the replies, but I am not interested in the 16XGE card. The
configuration I am referencing would be this:
http://www.ebay.com/itm/Juniper-MX960BASE-AC-10x-DPC-R-4XGE-XFP-MS-DPC-1yrWrnty-Free-Ship-40x-10G-MX960-/351615023814?hash=item51dde37ac6:g:WUcAAOSwLVZViHc~

Should I run into any problems with that configuration? I believe
everything would run at line rate.

On Thu, Jan 14, 2016 at 7:13 PM, Christopher E. Brown <
chris.br...@acsalaska.net> wrote:

>
> We actually spent a couple years spooling up for a greenfield build of a
> network required
> to provide very tight SLAs on a per service bases.
>
> We were working with the MX BU directly for almost 2 years and constantly
> exchanging test
> results and loaner/testing cards.
>
> Per specs provided by the designers of the MPC2 and verified by our
> testing the worst case
> throughput per trio for a MPC2-3D per or 3D-Q is 31.7G, that is full
> duplex with every
> packet going to or from bus and every packet being min length. That is
> actual packet,
> after all internal overhead.
>
> Larger packets bring this closer but not all the way to 40G, and traffic
> hairpinning on
> same trio can take all the way to 40G.
>
> We did not investigate any impact of MCAST replication on this as MCAST
> replication is not
> part of the use case for us.
>
>
> When the same folks were asked about the 16XGE card and the 120G (and
> later 160G)
> performance it was indicated that there was an additional layer of
> logic/asics used to tie
> all 4 trios in the 16XGE to the bus and that these ASICs offloaded some of
> the bus related
> overhead handling from the TRIOs, freeing up enough capacity to allow each
> TRIO in the
> 16XGE to provide a full 40G duplex after jcell/etc overhead.
>
>
> On 1/14/2016 3:27 PM, Saku Ytti wrote:
> > On 15 January 2016 at 01:39, Christopher E. Brown
> >  wrote:
> >> The 30Gbit nominal (actual 31.7 or greater) limit per trio applies to
> the MPC1 and 2 cards
> >> but the quad trio interconnect in the 16XGE is wired up diff with
> additional helpers and
> >> can do the full 40G per bank.
> >
> >
> > Pretty sure this is not true. There are three factors in play
> >
> > a) memory bandwidth of trio (mq)
> > b) lookup performance of trio (lu)
> > c) fabric capacity
> >
> > With SCBE 16XGE isn't limited by fabric, but it's still limited by
> > memory bandwidth and lookup performance.
> >
> > Memory bandwidth is tricksy, due to how packets are split into cells,
> > if you have unlucky packet sizes, you're wasting memory bandwidth
> > sending padding, and can end up having maybe even that 30Gbps
> > performance, perhaps even less.
> > If you have lucky packet sizes, and you can do 40Gbps. For me, I work
> > with half-duplex performance of 70Gbps, and that's been safe bet for
> > me, in real environments.
> >
> > Then there is lookup performance, which is like 50-55Mpps, out of
> > 60Mpps of maximum possible.
> >
> >
> >
> > Why DPCE=>MPC is particularly bad, is because even though MQ could
> > accept 20Gbps+20Gbps from the fabrics DPCE is sending, it's not, it's
> > only accepting 13+13, but DPCE isn't using the last fabric to send the
> > remaining 13Gbps.
> > So if your traffic flow from single DPCE card (say 4x10GE LACP) is out
> > to single trio, you'll be limited to just 26Gbps out of 40Gbps.
> >
> > If your chassis is SCBE or just MPC1/MPC2 you can 'set chassis fabric
> > chassis redundancy-mode redundant', which causes MPC to use only two
> > of the fabrics, in which case it'll accept 20+20 from DPCE, allowing
> > you to get that full 40Gbps from DPCE.
> > But this also means, if you also have 16XGE and SCB, you can pretty
> > much use just half of the ports of 16XGE.
> >
> > If this is confusing, just don't run mixed box, or buy SCBE and run
> > redundant-mode.
> >
> >
> >
>
>
> --
> 
> Christopher E. Brown      desk (907) 550-8393
>  cell (907) 632-8492
> IP Engineer - ACS
> 
> ___
> 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] MX960 with 3 RE's?

[Colton Conor]

So assuming I got with something like this setup:
http://www.ebay.com/itm/Juniper-MX960BASE-AC-10x-DPC-R-4XGE-XFP-MS-DPC-1yrWrnty-Free-Ship-40x-10G-MX960-/351615023814?hash=item51dde37ac6:g:WUcAAOSwLVZViHc~

That has RE-2000's, Regular SCBs, and all DPC linecards. Would these all be
able to run at line rate?

On Thu, Jan 14, 2016 at 4:19 PM, Christopher E. Brown <
chris.br...@acsalaska.net> wrote:

>
> It is 120Gbit agg in a SCB system as the limit is 120G/slot.
>
> This is in the form of 30Gbit per TRIO and 1 TRIO per 4 ports.
>
> So, use 3 of 4 in each bank if you want 100% line rate.
>
> SCBE increases this to 160Gbit or better (depending on age of chassis)
> allowing for line rate on all 16.
>
>
> Agree, mixing DPC and MPC is a terrible idea.  Don't like DPC to begin
> with, but nobody in their right mind mixes DPCs and MPCs.
>
> On 1/14/16 13:09, Saku Ytti wrote:
> > On 14 January 2016 at 23:11, Mark Tinka  wrote:
> >
> > Hey,
> >
> >>> A surplus dealer recommended the MPC-3D-16XGE-SFPP-R-B, which is less
> >>> than $1k/port used.  But it only supports full bandwidth on 12 ports,
> >>> would be oversubscribed 4:3 if all 16 are in use.  They are Trio
> chipset.
> >
> >> I wouldn't be too concerned about the throughput on this line card. If
> >> you hit such an issue, you can easily justify the budget for better line
> >> cards.
> >
> > Pretty sure it's as wire-rate as MPC1, MPC2 on SCBE system.
> >
> > Particularly bad combo would be running with DPCE. Basically any
> > MPC+DPCE combo is bad, but at least on MPC1/MPC2 systems you can set
> > the fabric to redundancy mode. But with 16XGE+SCB you probably don't
> > want to.
> >
> > There is some sort of policing/limit on how many fabric grands MPC
> > gives up, like if your trio needs 40Gbps of capacity, and is operating
> > in normal mode (not redundancy) then it'll give 13.33Gbps of grands to
> > each SCB.
> > However as DPCE won't use the third one, DPCE could only send at
> > 26.66Gbps towards that 40Gbps trio. While MPC would happily send
> > 40Gbps to MPC.
> >
>
>
> --
> 
> Christopher E. Brown      desk (907) 550-8393
>  cell (907) 632-8492
> IP Engineer - ACS
> 
> ___
> 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] MX960 with 3 RE's?

[Colton Conor]

Well it would be RE-S-2000-4096 running the JTAC Recommended Junos Software
Version Junos 13.3R8 plus the standard (not enhanced SCBs).

I know more memory and 64 bit is usually better, but how does this help in
Junos? From past threads, we have concluded that Junos is currently single
thread/core in most all situations, and the RE-S-2000-4096 is faster than
the RE in a MX80 and MX104. What does the more cores and quadruple memory
get you in the RE-S-1800X4-16G that you can not do on a RE-S-2000-4096?

The use case for this box would be full BGP tables and routing with 4+
providers on 10G ports, plus a couple of ports to a peering exchange. I am
wondering what features the DPC's lack in this situation.

On Wed, Jan 13, 2016 at 4:11 PM, Tom Storey  wrote:

> On 13 January 2016 at 22:32, Mark Tinka  wrote:
> > A more current RE means you can run more recent Junos releases. I
> > haven't run the RE-S-2000 in a while, so not sure how well it's
> > supported by current Junos releases (someone else who has the older RE's
> > might want to chime in).
>
> Guess it depends how old an RE you are talking about, and how recent JunOS?
>
> Have seen RE-S-2000's running 13.3.
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX960 with 3 RE's?

[Colton Conor]

Just to confirm though, its the extra RE that is different and not
supported in this config right? The MX960 can use 3 SCB's at once, but only
2 REs? Or do I have the wrong too?



On Wed, Jan 13, 2016 at 8:16 AM, Mark Tinka  wrote:

>
>
> On 13/Jan/16 12:42, Jérôme Nicolle wrote:
>
> > Looks like the broker had a few spare SCB and REs and no functionnal
> > chassis to slap them in, so he invented a bundle and didn't fully test
> it.
>
> If the price is right, I'd take the extra RE and SCB as backup, in case
> not including them does not yield any significant saving.
>
> 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] MX960 with 3 RE's?

[Colton Conor]

Thanks for the overwhelming wealth of information.

So sounds like the ideal, supported setup would be a MX960 with 3 SBC, 2
RE-S-2000-4096, and redundant power supplies. For a recommended option, we
would have a third RE-S-2000-4096 as a spare (well really we should have a
spare for everything), and install this spare in the 3 SBC slot to just
hold the spare (it would not be powered or do anything, just be there for a
swap if one of the 2 installed RE's failed instead of sitting on a shelf
somewhere).

Are there any feature limitations I should be aware of using a MX960 with
the above configuration and older I beleive EOL'd DPC-R-4XGE-XFP
linecards?  For comparison's sake, I am upgrading from a MX80 using the 4
10G ports on the front of the MX80.

The RE-S-2000-4096 is more powerful than the RE built into the MX80 (and
MX104), and of course the MX960 has more redundancy. Just wondering on the
software and feature-set side if I am loosing anything assuming they are
running on same JUNOS version. Any gotchas to be concerned about using
RE-S-2000-4096, regular SBCs, and DPC-R-4XGE-XFPs line-cards? We are
pushing less than 80Gbps, so I the back plane capacity is of little concern.


On Wed, Jan 13, 2016 at 11:15 AM, Daniel Roesen  wrote:

> On Wed, Jan 13, 2016 at 09:06:55AM -0800, joel jaeggli wrote:
> > An mx960 has a full fabric with two SCBs.
>
> That depends on the specific MPCs used in the chassis. Some do get
> full performance only with all 3 SCBs.
>
> > it is n+1 redundant with 3. e.g. at that point you can swap one
> > without cutting the fabric bandwidth in half.
>
> Technically, with MPCs (unlike DPCs), when removing the third SCB
> you're removing 1/3rd of the fabric bandwidth as all traffic is
> sprayed across all forwarding planes (two per SCB).
>
> With DPCs, only two SCBs (thus four fabric planes) could be active,
> with the third SCB being hot standby.
>
> Best regards,
> Daniel
>
> --
> CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
> ___
> 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] MX960 with 3 RE's?

[Colton Conor]

Then how do they have 3 RE's listed and house in the picture? Is the 3 RE
in the 3 SBC just in there, but would not be powered on or usable?

On Tue, Jan 12, 2016 at 2:49 PM, Mark Tinka <mark.ti...@seacom.mu> wrote:

>
>
> On 12/Jan/16 22:40, Colton Conor wrote:
>
> > Is it possible to have 3 RE's in a MX960? For example:
> >
> http://www.ebay.com/itm/Juniper-MX960PREMIUM-DC-ECM-4x-PWR-MX960-DC-3x-SCB-MX960-3x-RE-S-2000-4096-/271739188162?hash=item3f44eaf3c2:g:Z~IAAOSwnDZT8lpv
> > shows 3s RE's installed?
> >
> > The documentation I have seen shows that a MX960 can have 3 SCB's, but it
> > mentions only 2 REs?
>
> The MX960 supports 3x SCB's for the switch fabric.
>
> However, only 2x SCB's can house RE's.
>
> >
> > How does the RE-S-2000-4096 compare to a RES-1800X4-16G?
>
> The latter is 64-bit, faster and supports more memory.
>
> >  How does a the
> > regular SCB compared to the Enhanced SCB?
>
> Faster switch fabric.
>
> Mark.
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] MX960 with 3 RE's?

[Colton Conor]

Is it possible to have 3 RE's in a MX960? For example:
http://www.ebay.com/itm/Juniper-MX960PREMIUM-DC-ECM-4x-PWR-MX960-DC-3x-SCB-MX960-3x-RE-S-2000-4096-/271739188162?hash=item3f44eaf3c2:g:Z~IAAOSwnDZT8lpv
shows 3s RE's installed?

The documentation I have seen shows that a MX960 can have 3 SCB's, but it
mentions only 2 REs?

How does the RE-S-2000-4096 compare to a RES-1800X4-16G? How does a the
regular SCB compared to the Enhanced SCB?
___
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]

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

[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

[j-nsp] RE-S-2000-4096

[Colton Conor]

How many full routes can two RE-S-2000-4096 in a MX480 support? How limited
is this older card? How does it compare to the RE found in the MX104 or
built into the MX80?

On the MX480, when do most make the decision to upgrade from the RE-S-2000-4096
to a RE-S-1800X4-16G? What does the extra processing and ram enabled on
this newer card?

Application would be peering on an internet exchange with content
providers, and 4 connections to Tier one networks.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Colton Conor]

Saku,

You seem to be very familiar with the major routing vendors implementations
on SMP. Do you consider the lack of SMP support on Juniper a reason not to
go with Juniper until implemented. Particularly interested to hear about
JunOS vs TimOS.

On Thu, Oct 8, 2015 at 10:13 AM, Saku Ytti  wrote:

> On 3 October 2015 at 03:41, Olivier Benghozi
>  wrote:
>
> Hey,
>
> > I have heard that:
> > 1) forget it about PowerPC CPUs (MX 80/104).
>
> This is shame, but completely understandable, give customers couple
> more years on old kit or force them to buy new kit? I'm afraid maybe
> no HW of current generation will get SMP support. I'm sure marketing
> is pondering lot how many customers would switch vendor versus how
> many customers would just buy new next-gen hardware when deciding
> which platforms to target for SMP.
>
> I honestly believe that SMP is weekend project for single developer on
> JunOS now that they've remedied the underlaying FreeBSD issues. Fixing
> rpd mess is certainly big deal. But just affinity to put RPD on its
> own core and rest on the other core on MX80/MX104 should be terribly
> trivial.
>
> Even radar plans for RPD + threads is far cry from what other vendors
> are doing already with SMP on XR, EOS and particularly TimOS. But
> still very nice that JNPR is finally doing something.
>
> --
>   ++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] Multi Core on JUNOS?

[Colton Conor]

Does anyone have an update on when Juniper will release SMP (symmetrical
multi processor) aka the ability to use multiple cores? Do you think the
second core on the MX80 or MX104 will ever be used? Does the RE-2000 in the
MX240/480 have one or 2 cores?

On Mon, May 11, 2015 at 7:04 AM, Mark Tinka  wrote:

>
>
> On 11/May/15 13:27, Olivier Benghozi wrote:
> >
> http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html
> <
> http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html
> >
> >
> > "Statement introduced in Junos OS Release 13.3 R4"
>
> We decided not to enable this now because I understand the plan is for
> 64-bit mode to become the default in later versions of Junos.
>
> 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