RE: Juniper hardware recommendation

[Jean St-Laurent via NANOG]

Good monitoring softwares allow to do "preprocessing" before storing the 
monitored data in database.

Saku's formula should work well in this case.

I use Zabbix for monitoring big infrastructure. It has many advantages like:

- Push or pull metrics (dmz friendly)
- Can use many proxies (scale well)
- preprocessing of data (fix vendors mess)
- alert based on business logic through templates ( proactive instead of 
reactive)
- open source and have enterprise support (always nice to be able to call 1800 
zabbix in case of emergency)
- agent, agentless, discovery, snmp, java/jmx, telnet, ipmi, web scenarios, etc 
(never face a coirner-case that can't be monitored so far)

Really awesome at infrastructure level.

Jean

-Original Message-
From: NANOG  On Behalf Of Saku Ytti
Sent: May 17, 2021 3:34 AM
To: Sander Steffann 
Cc: Michael Fiumano ; nanog list 
Subject: Re: Juniper hardware recommendation

On Mon, 17 May 2021 at 00:22, Sander Steffann  wrote:

> How do you normalise? Use L2 or L3 octets stats, and use the number of 
> packets to calculate the L2 and/or L1 overhead the stats are missing?
> Or do you have a better way?

That's the way one of my employers did it, and I can't think of a better way.

bytes += PPS*overhead

Overhead is likely 20bytes (preamble, SFD, ifg). But it could also be 24B 
(FCS/CRC might be missing in what otherwise is claimed to be L2).
You may need a lab to confirm what exactly is being counted.

This adjustment could be in DB or it could be render-time, both have pro and 
con.

--
  ++ytti

Re: Juniper hardware recommendation

[Saku Ytti]

On Mon, 17 May 2021 at 00:22, Sander Steffann  wrote:

> How do you normalise? Use L2 or L3 octets stats, and use the number of
> packets to calculate the L2 and/or L1 overhead the stats are missing?
> Or do you have a better way?

That's the way one of my employers did it, and I can't think of a better way.

bytes += PPS*overhead

Overhead is likely 20bytes (preamble, SFD, ifg). But it could also be
24B (FCS/CRC might be missing in what otherwise is claimed to be L2).
You may need a lab to confirm what exactly is being counted.

This adjustment could be in DB or it could be render-time, both have
pro and con.

-- 
  ++ytti

Re: Juniper hardware recommendation

[Sander Steffann]

Hi!

On Sat, 2021-05-15 at 11:38 +0300, Saku Ytti wrote:
> Juniper has worked like this since day1 and shockingly the world
> doesn't care, people really don't care for accuracy. CLI and SNMP are
> both L3. If you want to report L2 'set chassis fpc N pic N
> account-layer2-overhead'.
> 
> However, who decided that L2 is right? To me only L1 is right, I
> don't care about L2 at all. So any system I'd use, I'd normalise the
> data to L1.
> 
> Ethernet on minimum size packets
> L1 - 100%
> L2 -  76%
> L3 -  24%
> 
> Not sure why 76 is better than 24. Both are wrong and will cause
> operational confusion because people think the link is not congested.
> This is extremely poorly understood even by professionals, so poorly
> that people regularly think you can't get 100% utilisation, because
> you can't unless you normalise stats to L1 rate.

How do you normalise? Use L2 or L3 octets stats, and use the number of
packets to calculate the L2 and/or L1 overhead the stats are missing?
Or do you have a better way?

Cheers,
Sander



signature.asc
Description: This is a digitally signed message part

Re: Juniper hardware recommendation

[Jon Lewis]

On Sun, 16 May 2021, Colton Conor wrote:


Looks like its replacement is the 5120 series. The question is does the 5120 
have the same limitations and similar chipset? 


Severly limited TCAM makes use of ACLs challenging.

--
 Jon Lewis, MCP :)   |  I route
 StackPath, Sr. Neteng   |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Juniper hardware recommendation

[Mark Tinka]

All sounds like a bit of Broadcom to me :-).

Mark.

On 5/16/21 14:56, Colton Conor wrote:
Looks like its replacement is the 5120 series. The question is does 
the 5120 have the same limitations and similar chipset?


On Sun, May 16, 2021 at 7:06 AM Jason Healy 
mailto:jhe...@suffieldacademy.org>> wrote:


To echo Alain's comments earlier, the Juniper QFX 5100 series is
stable, once you figure out all the shortcomings of the chipset. 
We aren't doing anything fancy, but have certainly bumped into our
share of issues that have no workaround because it's a limitation
of the physical hardware.  Since we're talking about counters, see
if you can spot the error with IPv6 accounting in the output from
our 5100 below (about 50% of our traffic is v6):

    Transit statistics:
     Input  bytes  :      284315487788005            412457312 bps
     Output bytes  :       39937401090441             29417528 bps
     Input  packets:         231391925059                39552 pps
     Output packets:          88278182551                10809 pps
     IPv6 transit statistics:
      Input  bytes  :                   0
      Output bytes  :                   0
      Input  packets:                   0
      Output packets:                   0


;-)

I believe the 5100 just announced EOL
(https://support.juniper.net/support/eol/product/qfx_series/
); I
haven't had time to look at the replacement models to see if they
behave any better.

Jason

Re: Juniper hardware recommendation

[Colton Conor]

Looks like its replacement is the 5120 series. The question is does the
5120 have the same limitations and similar chipset?

On Sun, May 16, 2021 at 7:06 AM Jason Healy 
wrote:

> To echo Alain's comments earlier, the Juniper QFX 5100 series is stable,
> once you figure out all the shortcomings of the chipset.  We aren't doing
> anything fancy, but have certainly bumped into our share of issues that
> have no workaround because it's a limitation of the physical hardware.
> Since we're talking about counters, see if you can spot the error with IPv6
> accounting in the output from our 5100 below (about 50% of our traffic is
> v6):
>
> Transit statistics:
>  Input  bytes  :  284315487788005412457312 bps
>  Output bytes  :   39937401090441 29417528 bps
>  Input  packets: 23139192505939552 pps
>  Output packets:  8827818255110809 pps
>  IPv6 transit statistics:
>   Input  bytes  :   0
>   Output bytes  :   0
>   Input  packets:   0
>   Output packets:   0
>
>
> ;-)
>
> I believe the 5100 just announced EOL (
> https://support.juniper.net/support/eol/product/qfx_series/); I haven't
> had time to look at the replacement models to see if they behave any better.
>
> Jason

Re: Juniper hardware recommendation

[Jason Healy]

To echo Alain's comments earlier, the Juniper QFX 5100 series is stable, once 
you figure out all the shortcomings of the chipset.  We aren't doing anything 
fancy, but have certainly bumped into our share of issues that have no 
workaround because it's a limitation of the physical hardware.  Since we're 
talking about counters, see if you can spot the error with IPv6 accounting in 
the output from our 5100 below (about 50% of our traffic is v6):

Transit statistics:
 Input  bytes  :  284315487788005412457312 bps
 Output bytes  :   39937401090441 29417528 bps
 Input  packets: 23139192505939552 pps
 Output packets:  8827818255110809 pps
 IPv6 transit statistics:
  Input  bytes  :   0
  Output bytes  :   0
  Input  packets:   0
  Output packets:   0


;-)

I believe the 5100 just announced EOL 
(https://support.juniper.net/support/eol/product/qfx_series/); I haven't had 
time to look at the replacement models to see if they behave any better.

Jason

Re: Juniper hardware recommendation

[Saku Ytti]

On Sat, 15 May 2021 at 13:00, Mark Tinka  wrote:

> Because end users will demand compensation and lawyer time for only
> getting 195Mbps on their 200Mbps service. 195Mbps is not 200Mbps.

Customers and operators both have very little idea what they are
doing. Most people have no idea what the policer are accounting for.
And everything still works, without anyone understanding what they are
doing. So mostly it's not a problem if you're doing L1, L2 or L3.

Of course your 100M physical interface is limited to L1 rate of 100M.
If you provision that as VLAN of 100M service, should you sell now L1,
L2 or L3 of 100M? What are. you doing? (No you you, passive you, you
are not representative, nanog is not representative, the passive you
doesn't know which they are selling, and which they are selling
changes with hardware upgrades, and they don't know it).


-- 
  ++ytti

Re: Juniper hardware recommendation

[Mark Tinka]

On 5/15/21 10:38, Saku Ytti wrote:


Not sure why 76 is better than 24. Both are wrong and will cause
operational confusion because people think the link is not congested.
This is extremely poorly understood even by professionals, so poorly
that people regularly think you can't get 100% utilisation, because
you can't unless you normalise stats to L1 rate.


Because end users will demand compensation and lawyer time for only 
getting 195Mbps on their 200Mbps service. 195Mbps is not 200Mbps.


I've seen operators over-provision services simply to quiet-down the 
noise, i.e., they'll provision 210Mbps for a 200Mbps service. We don't 
do this, but I encourage all of my competitors to do so.


The example I always give is that if there were no seats on an aircraft, 
it'd carry significantly more people than otherwise advertised.


We try hard to educate customers about how the higher layers eat away at 
the lower ones re: capacity, and that's just how the system works. There 
probably isn't a single man-made technology that offers 100% efficiency. 
So I'm not about to go out of business giving you the optical illusion 
that my corner of earth will make it so. In the end, it's easier to just 
let those customers go than spend human hours and money placating them.


Mark.

Re: Juniper hardware recommendation

[Saku Ytti]

Hey Michael,

> If accurate interface stats are important to you, MX’s don’t support accurate 
> SNMP Interface Utilization, ie they don’t comply with RFC2665/3635, which 
> seems like a fairly basic thing to do but they decided not to, and has been 
> impactful to me in the past.  So, any SNMP monitoring of an interface will 
> always show less utilization than what is actually occurring, possibly 
> leading to a false sense of security, or delay in augmentation.  Would also 
> affect usage based billing, if you do that.

Juniper has worked like this since day1 and shockingly the world
doesn't care, people really don't care for accuracy. CLI and SNMP are
both L3. If you want to report L2 'set chassis fpc N pic N
account-layer2-overhead'.

However, who decided that L2 is right? To me only L1 is right, I don't
care about L2 at all. So any system I'd use, I'd normalise the data to
L1.

Ethernet on minimum size packets
L1 - 100%
L2 -  76%
L3 -  24%

Not sure why 76 is better than 24. Both are wrong and will cause
operational confusion because people think the link is not congested.
This is extremely poorly understood even by professionals, so poorly
that people regularly think you can't get 100% utilisation, because
you can't unless you normalise stats to L1 rate.

-- 
  ++ytti

RE: Juniper hardware recommendation

[Adam Thompson]

At least it isn’t Arista, where SVI egress counters are disabled by default, 
and once enabled count everything UNLESS the packet egresses via a LAG!  Talk 
about being “impactful”, we’re having to buy new routers to insert behind them, 
just to count packets so we can bill accurately, and for that matter, have 
traffic graphs that work at all.  :-(

Adam Thompson
Consultant, Infrastructure Services
[[MERLIN LOGO]]<https://www.merlin.mb.ca/>
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athomp...@merlin.mb.ca<mailto:athomp...@merlin.mb.ca>
www.merlin.mb.ca<http://www.merlin.mb.ca/>

From: NANOG  On Behalf Of 
Michael Fiumano
Sent: Friday, May 14, 2021 12:06 PM
To: nanog@nanog.org
Subject: RE: Juniper hardware recommendation

If accurate interface stats are important to you, MX’s don’t support accurate 
SNMP Interface Utilization, ie they don’t comply with RFC2665/3635, which seems 
like a fairly basic thing to do but they decided not to, and has been impactful 
to me in the past.  So, any SNMP monitoring of an interface will always show 
less utilization than what is actually occurring, possibly leading to a false 
sense of security, or delay in augmentation.  Would also affect usage based 
billing, if you do that.

https://www.juniper.net/documentation/us/en/software/junos/network-mgmt/topics/topic-map/snmp-mibs-and-traps-supported-by-junos-os.html

For M Series, T Series, and MX Series, the SNMP counters do not count the 
Ethernet header and frame check sequence (FCS). Therefore, the Ethernet header 
bytes and the FCS bytes are not included in the following four tables:

ifInOctets

ifOutOctets

ifHCInOctets

ifHCOutOctets


Thanks,
Michael Fiumano

From: NANOG On Behalf Of Mark Tinka
Sent: Monday, May 10, 2021 10:25 AM
To: nanog@nanog.org<mailto:nanog@nanog.org>
Subject: Re: Juniper hardware recommendation


On 5/10/21 16:19, aar...@gvtc.com<mailto:aar...@gvtc.com> wrote:
I prefer MX204 over the ACX5048.  The ACX5048 can’t add L3 interface to an mpls 
layer 2 type of service.  There are other limitations to the ACX5048 that cause 
me to want to possibly replace them with MX204’s.  But in defense of the 
ACX5048, we have gotten some good mileage (a few years now) of good resi/busi 
bb over vrf’s and also carrier ethernet for businesses and lots of cell 
backhaul… so they are good for that.  I’ve heard the ACX5448 was even better.

Trio will always provide better features, but come with the price tag to boot.


I’m looking at the MX240 for the SCB3E MPC10E hefty with 100 gig ports

You might want to look at the MX10003, in that case, as well. We are deploying 
those for 100Gbps service (customer-facing). Works out cheaper than offering 
100Gbps service on the MX240/480/960 for the same task.

Mark.

RE: Juniper hardware recommendation

[Michael Fiumano]

If accurate interface stats are important to you, MX’s don’t support
accurate SNMP Interface Utilization, ie they don’t comply with
RFC2665/3635, which seems like a fairly basic thing to do but they decided
not to, and has been impactful to me in the past.  So, any SNMP monitoring
of an interface will always show less utilization than what is actually
occurring, possibly leading to a false sense of security, or delay in
augmentation.  Would also affect usage based billing, if you do that.



https://www.juniper.net/documentation/us/en/software/junos/network-mgmt/topics/topic-map/snmp-mibs-and-traps-supported-by-junos-os.html



For M Series, T Series, and MX Series, the SNMP counters do not count the
Ethernet header and frame check sequence (FCS). Therefore, the Ethernet
header bytes and the FCS bytes are not included in the following four
tables:



ifInOctets



ifOutOctets



ifHCInOctets



ifHCOutOctets





Thanks,

Michael Fiumano



*From:* NANOG *On Behalf Of *Mark Tinka
*Sent:* Monday, May 10, 2021 10:25 AM
*To:* nanog@nanog.org
*Subject:* Re: Juniper hardware recommendation





On 5/10/21 16:19, aar...@gvtc.com wrote:

I prefer MX204 over the ACX5048.  The ACX5048 can’t add L3 interface to an
mpls layer 2 type of service.  There are other limitations to the ACX5048
that cause me to want to possibly replace them with MX204’s.  But in
defense of the ACX5048, we have gotten some good mileage (a few years now)
of good resi/busi bb over vrf’s and also carrier ethernet for businesses
and lots of cell backhaul… so they are good for that.  I’ve heard the
ACX5448 was even better.


Trio will always provide better features, but come with the price tag to
boot.




I’m looking at the MX240 for the SCB3E MPC10E hefty with 100 gig ports


You might want to look at the MX10003, in that case, as well. We are
deploying those for 100Gbps service (customer-facing). Works out cheaper
than offering 100Gbps service on the MX240/480/960 for the same task.

Mark.

Re: Juniper hardware recommendation

[Vincent Bernat]

In addition to the QSA, note that 40G LR optics are using CWDM. You can
therefore get 1270, 1290, 1310 and 1330 out of the optic. Not the
favorites channels, but if that's OK for you, configure it as a 4x10G on
the Juniper side.
-- 
Make it clear before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)

-Original Message-
From: Adam Thompson 
Sent: 14 mai 2021 13:30 GMT
Subject: RE: Juniper hardware recommendation
To: Bjørn Mork
Cc: nanog@nanog.org

> OK, enough people have pointed it out :-).
>
> Clearly I was wrong about the MX 2K family, I missed the SFP+ MIC completely. 
>  That is good to know.
>
> However, the MX 10k family still only shows as being compatible with
> two QSFP cards. And yes, you can get a QSFP-SFP+ breakout cable, but
> those don't let you use SFP+ CWDM/DWDM transceivers.
>
> -Adam
>
> Adam Thompson
> Consultant, Infrastructure Services
> MERLIN
> 100 - 135 Innovation Drive
> Winnipeg, MB, R3T 6A8
> (204) 977-6824 or 1-800-430-6404 (MB only)
> athomp...@merlin.mb.ca
> www.merlin.mb.ca
>
>> -Original Message-
>> From: Bjørn Mork 
>> Sent: Saturday, May 8, 2021 6:32 AM
>> To: Adam Thompson 
>> Cc: Javier Gutierrez Guerra ; nanog@nanog.org
>> Subject: Re: Juniper hardware recommendation
>> 
>> Adam Thompson  writes:
>> 
>> 
>> >   * Skip the MX 2k/10k series – they don’t support SFP+ interfaces!
>> 
>> https://apps.juniper.net/hct/model/?component=MX2K-MPC6E
>> https://apps.juniper.net/hct/model/?component=MIC6-10G
>> 
>> 
>> Bjørn

Re: Juniper hardware recommendation

[Nick Hilliard]

Adam Thompson wrote on 14/05/2021 15:44:

I did not know such a thing existed!  Cool!  Holy murdering your port density, 
though.  Ouch$$$.


oh the port wastage is completely criminal, but it can be a handy last 
resort.


Nick

RE: Juniper hardware recommendation

[Adam Thompson]

I did not know such a thing existed!  Cool!  Holy murdering your port density, 
though.  Ouch$$$.

Adam Thompson
Consultant, Infrastructure Services
MERLIN
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athomp...@merlin.mb.ca
www.merlin.mb.ca

> -Original Message-
> From: Nick Hilliard 
> Sent: Friday, May 14, 2021 9:40 AM
> To: Adam Thompson 
> Cc: nanog@nanog.org
> Subject: Re: Juniper hardware recommendation
> 
> Adam Thompson wrote on 14/05/2021 14:30:
> > However, the MX 10k family still only shows as being compatible with
> > two QSFP cards.  And yes, you can get a QSFP-SFP+ breakout cable, but
> > those don't let you use SFP+ CWDM/DWDM transceivers.
> you can also get QSA adapters to convert from a QSFP form factor port to a
> SFP+ port.  This should allow SFP+ WDM transceivers.
> 
> Nick

Re: Juniper hardware recommendation

[Nick Hilliard]

Adam Thompson wrote on 14/05/2021 14:30:

However, the MX 10k family still only shows as being compatible with
two QSFP cards.  And yes, you can get a QSFP-SFP+ breakout cable, but
those don't let you use SFP+ CWDM/DWDM transceivers.
you can also get QSA adapters to convert from a QSFP form factor port to 
a SFP+ port.  This should allow SFP+ WDM transceivers.


Nick

Re: Juniper hardware recommendation

[Saku Ytti]

On Fri, 14 May 2021 at 16:33, Adam Thompson  wrote:

> However, the MX 10k family still only shows as being compatible with two QSFP 
> cards.  And yes, you can get a QSFP-SFP+ breakout cable, but those don't let 
> you use SFP+ CWDM/DWDM transceivers.

Talk to your account team, you can get the card you want for testing,
with support in 21.2R1.

-- 
  ++ytti

RE: Juniper hardware recommendation

[Adam Thompson]

OK, enough people have pointed it out :-).

Clearly I was wrong about the MX 2K family, I missed the SFP+ MIC completely.  
That is good to know.

However, the MX 10k family still only shows as being compatible with two QSFP 
cards.  And yes, you can get a QSFP-SFP+ breakout cable, but those don't let 
you use SFP+ CWDM/DWDM transceivers.

-Adam

Adam Thompson
Consultant, Infrastructure Services
MERLIN
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athomp...@merlin.mb.ca
www.merlin.mb.ca

> -Original Message-
> From: Bjørn Mork 
> Sent: Saturday, May 8, 2021 6:32 AM
> To: Adam Thompson 
> Cc: Javier Gutierrez Guerra ; nanog@nanog.org
> Subject: Re: Juniper hardware recommendation
> 
> Adam Thompson  writes:
> 
> 
> >   * Skip the MX 2k/10k series – they don’t support SFP+ interfaces!
> 
> https://apps.juniper.net/hct/model/?component=MX2K-MPC6E
> https://apps.juniper.net/hct/model/?component=MIC6-10G
> 
> 
> Bjørn

Re: Juniper hardware recommendation

[Mark Tinka]

On 5/10/21 20:22, aar...@gvtc.com wrote:

Thanks Mark.  We have a ring of MX960’s currently and wanted to spare 
the parts with each other, between the 960’s and 240’s…. scb’s, re’s, 
mpc’s…




Ah, makes sense in that case, then.

Mark.

RE: Juniper hardware recommendation

[aaron1]

Thanks Mark.  We have a ring of MX960’s currently and wanted to spare the parts 
with each other, between the 960’s and 240’s…. scb’s, re’s, mpc’s…

 

-Aaron

 

Re: Juniper hardware recommendation

[Baldur Norddahl]

man. 10. maj 2021 16.20 skrev :

> I prefer MX204 over the ACX5048.  The ACX5048 can’t add L3 interface to an
> mpls layer 2 type of service.  There are other limitations to the ACX5048
> that cause me to want to possibly replace them with MX204’s.  But in
> defense of the ACX5048, we have gotten some good mileage (a few years now)
> of good resi/busi bb over vrf’s and also carrier ethernet for businesses
> and lots of cell backhaul… so they are good for that.  I’ve heard the
> ACX5448 was even better.
>

It is my understanding that acx5448 is much more capable than the older
acx5048. It will definitely do both l2vpn and l3vpn on mpls (what we use
acx5448 / acx710 for).

The main limitation is that it will not do full dfz table and not more
exotic stuff like subscriber management.

Regards

Baldur

Re: Juniper hardware recommendation

[Mark Tinka]

On 5/10/21 16:19, aar...@gvtc.com wrote:

I prefer MX204 over the ACX5048.  The ACX5048 can’t add L3 interface 
to an mpls layer 2 type of service.  There are other limitations to 
the ACX5048 that cause me to want to possibly replace them with 
MX204’s.  But in defense of the ACX5048, we have gotten some good 
mileage (a few years now) of good resi/busi bb over vrf’s and also 
carrier ethernet for businesses and lots of cell backhaul… so they are 
good for that.  I’ve heard the ACX5448 was even better.




Trio will always provide better features, but come with the price tag to 
boot.




I’m looking at the MX240 for the SCB3E MPC10E hefty with 100 gig ports



You might want to look at the MX10003, in that case, as well. We are 
deploying those for 100Gbps service (customer-facing). Works out cheaper 
than offering 100Gbps service on the MX240/480/960 for the same task.


Mark.

RE: Juniper hardware recommendation

[aaron1]

I prefer MX204 over the ACX5048.  The ACX5048 can’t add L3 interface to an mpls 
layer 2 type of service.  There are other limitations to the ACX5048 that cause 
me to want to possibly replace them with MX204’s.  But in defense of the 
ACX5048, we have gotten some good mileage (a few years now) of good resi/busi 
bb over vrf’s and also carrier ethernet for businesses and lots of cell 
backhaul… so they are good for that.  I’ve heard the ACX5448 was even better.

 

I’m looking at the MX240 for the SCB3E MPC10E hefty with 100 gig ports

 

-Aaron

 

Re: Juniper hardware recommendation

[Mark Tinka]

On 5/8/21 23:37, Baldur Norddahl wrote:



It is possible to get a 48V 6A DC power supply as a power brick laptop 
style. Just look at it as an external psu :-)


For the number of units we'd need to deploy, it doesn't make sense for us.

Easier to buy a UPS than try to convert AC to DC.




I will admit that we use them with 48 volt battery banks the way 
intended. It has become extremely cheap and easy to make your own with 
lithium iron phosphate batteries.


Yeah - I stopped messing around with DC for routers, switches and 
servers in 2007. Not going back to those days.


3 simple pins and a wall plug is all I need.

Mark.

Re: Juniper hardware recommendation

[Baldur Norddahl]

lør. 8. maj 2021 22.56 skrev Mark Tinka :

>
>
> On 5/8/21 22:50, Baldur Norddahl wrote:
>
> >
> > Maybe they did in the ACX710? Does most things except full routing table.
>
> We looked at it. Apart from supporting only DC power (which we don't
> like), it's Broadcom.
>
> Granted, there's a whole new line of ACX7XXX boxes they are putting out,
> one of which we shall be testing. So I'm giving Broadcom a chance.
>
> Mark.
>

It is possible to get a 48V 6A DC power supply as a power brick laptop
style. Just look at it as an external psu :-)

I will admit that we use them with 48 volt battery banks the way intended.
It has become extremely cheap and easy to make your own with lithium iron
phosphate batteries.

Regards

Baldur

Re: Juniper hardware recommendation

[Mark Tinka]

On 5/8/21 22:50, Baldur Norddahl wrote:



Maybe they did in the ACX710? Does most things except full routing table.


We looked at it. Apart from supporting only DC power (which we don't 
like), it's Broadcom.


Granted, there's a whole new line of ACX7XXX boxes they are putting out, 
one of which we shall be testing. So I'm giving Broadcom a chance.


Mark.

Re: Juniper hardware recommendation

[Baldur Norddahl]

lør. 8. maj 2021 09.16 skrev Mark Tinka :

>
>  I just wish Juniper could make an MX204-lite, one with more 10Gbps port
> density, e.t.c.
>

Maybe they did in the ACX710? Does most things except full routing table.

We use mx204 to carry the full tables and handle ip transit. And ACX5448 +
ACX710 with evpn, vpls, l3vpn and internal Internet tables.

Regards

Baldur

Re: Juniper hardware recommendation

[Bjørn Mork]

Adam Thompson  writes:


>   * Skip the MX 2k/10k series – they don’t support SFP+ interfaces!

https://apps.juniper.net/hct/model/?component=MX2K-MPC6E
https://apps.juniper.net/hct/model/?component=MIC6-10G


Bjørn

Re: Juniper hardware recommendation

[Mark Tinka]

On 5/8/21 09:22, Marco Paesani wrote:

Hi Mark,
PTX series are dedicated for core backbone like "P Provider"...


Yes, this is what we are using it for.


probably you just using it like "PE Provider Edge" in this role is 
much better than the MX series.


Not this. We have the MX480 for that role.

Mark.

Re: Juniper hardware recommendation

[Marco Paesani]

Hi Mark,
PTX series are dedicated for core backbone like "P Provider" probably you
just using it like "PE Provider Edge" in this role is much better than the
MX series.

My 2 cents

Ciao,

-

Marco Paesani




Skype: mpaesani
Mobile: +39 348 6019349
Success depends on the right choice !
Email: ma...@paesani.it




Il giorno sab 8 mag 2021 alle ore 09:17 Mark Tinka  ha
scritto:

>
>
> On 5/8/21 00:56, Mann, Jason via NANOG wrote:
>
> We are using MX204's as our internet routers and I want to replace our
> ASR's with them to be used as an aggregate circuit router. With the amount
> of 10G/40G/100G interface and the price point we have been happy with them.
> The big issue was learning Junos since we are cisco shop
>
>
> Terribly happy with the MX204. We've been running them for nearly 2 years
> now.
>
> I just wish Juniper could make an MX204-lite, one with more 10Gbps port
> density, e.t.c.
>
> We run it as a peering and Metro-E router.
>
> Mark.
>

Re: Juniper hardware recommendation

[Mark Tinka]

On 5/8/21 00:56, Mann, Jason via NANOG wrote:

We are using MX204's as our internet routers and I want to replace our 
ASR's with them to be used as an aggregate circuit router. With the 
amount of 10G/40G/100G interface and the price point we have been 
happy with them. The big issue was learning Junos since we are cisco shop


Terribly happy with the MX204. We've been running them for nearly 2 
years now.


I just wish Juniper could make an MX204-lite, one with more 10Gbps port 
density, e.t.c.


We run it as a peering and Metro-E router.

Mark.

Re: Juniper hardware recommendation

[Mark Tinka]

On 5/7/21 23:28, Javier Gutierrez Guerra wrote:

I need to do MPLS (vlls), VXLAN, Multicast, full routing tables, 
multiple VRFs, q-in-q, QoS




If it's a typical MPLS-based, BGP-free(ish) core router, you probably 
don't need it to do all of those things.


If it's a collapsed core (P/PE), then yes, you might.

Mark.

Re: Juniper hardware recommendation

[Mark Tinka]

On 5/7/21 23:14, Adam Thompson wrote:

If you don’t already know that you want a PTX, then you don’t want a 
PTX.  The product is fine, but niche, and has the same interface 
limitations as MX10k.


We are testing the PTX1000 as a core router. Not terribly unhappy so far.

Mark.

Re: Juniper hardware recommendation

[Saku Ytti]

On Sat, 8 May 2021 at 00:17, Adam Thompson  wrote:


>
>- Skip the MX480 (and up), it’s just too expensive.  Consider an
>EX9200 instead, which can do 90% of the same functions.  (If you can afford
>an MX480 or MX960, by all means, get one!)
>
> MX240 and MX480 cost 25k list price. Sheetmetal doesn't affect your price.
If you can't fit MX960 or MX480 to your rack buy MX240.


>
>- MX240 is reasonable, but dated.  A pair of MX204s in HA would make
>more sense, to me.
>
> MX960, MX480, MX240 all take the latest gen SCBE3 fabric and MPC10E
linecard.


>- Skip the MX 2k/10k series – they don’t support SFP+ interfaces!
>(“No 10G WDM for you!”)  Also no 1G, you need a separate step-down switch
>for that.  I don’t know what SP Juniper thinks they’re targeting with 
> these.
>
> MX2k of course does support SFP+, considering it takes all the linecard
MX240, MX480, MX960, except MPC10E.
MX10k, talk to your account team, you'll have your card RSN.


>- 1U/2U EX/QFX are reasonable edge devices as long as you’ve verified
>they can do what you need.  Not core-router class IMHO.
>
> This may require a very liberal definition of edge. Of course they are
very feature and scale poor devices. But it is usually the opposite, more
devices fit core role, than edge role, as edge is where the scale and
features are.


>- If you don’t already know that you want a PTX, then you don’t want a
>PTX.  The product is fine, but niche, and has the same interface
>limitations as MX10k.
>
> PTX is more competitor to J2 boxes, MX is more competitor to Lightspeed,
Solar and FP. Like you said for EX/QFX, it is true here also. For NPU based
boxes like Trio, you don't have to know very well what you're going do with
the boxes during their lifecycle, it'll work whatever it'll be. For
pipeline based boxes like PE/BT, you're taking much larger risk with some
CAPEX benefits.


>- ACX: MEF-compliant mini-MX, basically.  Edge device only, pairs well
>with an MX480 (IIRC).  Top-end are exceptions: ACX5k/7k might work,
>depending on what you need it to do.  Not normally deployed as a core
>router.
>
> ACX are merchant, BRCM J2 and below. So they have much more similar
position to PTX than ACX from silicon POV, but from marketing POV they are
seeking metro installations, your front-plate demand may drive you to ACX.

-- 
  ++ytti

Re: Juniper hardware recommendation

[Vincent Bernat]

 ❦  7 mai 2021 21:14 GMT, Adam Thompson:

>   * Skip the MX 2k/10k series – they don’t support SFP+ interfaces!
> (“No 10G WDM for you!”) Also no 1G, you need a separate step-down
> switch for that. I don’t know what SP Juniper thinks they’re targeting
> with these.

The 10k can take 10G SFP+ using an adapter. It works fine, but this can
feel like a waste. Something like that:

https://www.fs.com/fr/products/72582.html?attribute=2692=80750

This is seen as a 4x breakout cable.

>   * 1U/2U EX/QFX are reasonable edge devices as long as you’ve
> verified they can do what you need. Not core-router class IMHO.

QFX10k is different from the others. From my experience, it is very
capable and the "Q" versions are quite versatile (many port
configurations, cheap), but Juniper is trying to push the new PTXs with
the same hardware, but not the same price tag, this is a bit confusing.
I don't do MPLS, so I may not see its limitations, but it supports
several full views and is the flagship for BGP EVPN VXLAN implementation
for Juniper.
-- 
The devil can cite Scripture for his purpose.
-- William Shakespeare, "The Merchant of Venice"

Re: Juniper hardware recommendation

[Alain Hebert]

    Yeah,

Routers for the whole Alphabet Soup.

    MX204, MX960 are pretty much headache free.  Heck even MX240 could 
be a good start if you are on a budget.

    ( Watch for the EoL )


Distribution ( MPLS Alphabet Soup without VXLAN/EVPN )

    QFX5100 made us feel like being full time members of the Juniper QA 
Team.  But once your find ALL the limitation of their chipset, they 
won't fail you.
    ( Chipset limitations are not always handled by the configuration 
and rendered ports unusable until the device is rebooted ... Or make you 
wonder why the heck it ain't working until you find some notes in an 
obscure PR )


    We're going up to 100Gbps (and then 200Gbps) in distribution and 
we're feeling good about the QFX being able to handle it.


    PS: EVPN worked well in the Lab, but we're no using in our "scheme".

-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

On 5/7/21 6:56 PM, Mann, Jason via NANOG wrote:
We are using MX204's as our internet routers and I want to replace our 
ASR's with them to be used as an aggregate circuit router. With the 
amount of 10G/40G/100G interface and the price point we have been 
happy with them. The big issue was learning Junos since we are cisco shop



*From:* NANOG  on behalf of 
Javier Gutierrez Guerra 

*Sent:* Friday, May 7, 2021 2:54 PM
*To:* nanog@nanog.org 
*Subject:* [EXTERNAL] Juniper hardware recommendation

Hi,

Just out of curiosity, what would you recommend using for a core 
router/switch from Juniper?


MX208,480,10K

Datasheets show them all as very nice and powerful devices (although 
they do use a lot of rack space and side to side airflow is painful) 
but I’m just wondering here what most people use and how good or bad 
of an experience you have with it 


Thanks,

Javier Gutierrez Guerra

Network Analyst

CCNA R, JNCIA

Westman Communications Group

Phone: 204-717-2827

Email: guer...@westmancom.com 

WCG_Corp_Logo_horiz_cFullcolorHR [westmancom.com] 



cisco-certified-network-associate-routing-and-switching-ccna-routing-and-switching

Re: Juniper hardware recommendation

[Mann, Jason via NANOG]

We are using MX204's as our internet routers and I want to replace our ASR's 
with them to be used as an aggregate circuit router. With the amount of 
10G/40G/100G interface and the price point we have been happy with them. The 
big issue was learning Junos since we are cisco shop


From: NANOG  on behalf of Javier 
Gutierrez Guerra 
Sent: Friday, May 7, 2021 2:54 PM
To: nanog@nanog.org 
Subject: [EXTERNAL] Juniper hardware recommendation


Hi,

Just out of curiosity, what would you recommend using for a core router/switch 
from Juniper?

MX208,480,10K

Datasheets show them all as very nice and powerful devices (although they do 
use a lot of rack space and side to side airflow is painful) but I’m just 
wondering here what most people use and how good or bad of an experience you 
have with it 

Thanks,



Javier Gutierrez Guerra

Network Analyst

CCNA R, JNCIA

Westman Communications Group

Phone: 204-717-2827

Email: guer...@westmancom.com

[WCG_Corp_Logo_horiz_cFullcolorHR] 
[westmancom.com]



[cisco-certified-network-associate-routing-and-switching-ccna-routing-and-switching]

Re: Juniper hardware recommendation

[Stephen M]

Side to side airflow can be implemented in a front to rear environment with 
some baffling acting as intake from one side to exhaust out the other

Not ideal, but doable

//please pardon any brevities - sent from mobile//

From: NANOG  on behalf of 
Tony Wicks 
Sent: Friday, May 7, 2021 2:33:23 PM
To: 'Javier Gutierrez Guerra' 
Cc: nanog@nanog.org 
Subject: RE: Juniper hardware recommendation


You really should discuss this with you local Juniper rep in the first instance 
I would suggest.



From: NANOG  On Behalf Of Javier 
Gutierrez Guerra
Sent: Saturday, 8 May 2021 9:28 am
To: r...@rkhtech.org; nanog@nanog.org
Subject: RE: Juniper hardware recommendation



I need to do MPLS (vlls), VXLAN, Multicast, full routing tables, multiple VRFs, 
q-in-q, QoS

Anything with 1Tbs of throughput should be more than enough at this time for me

I also need it to be able to support 100G interfaces, 1G and 10G



Javier Gutierrez Guerra

Network Analyst

CCNA R, JNCIA

Westman Communications Group

Phone: 204-717-2827

Email: guer...@westmancom.com<mailto:guer...@westmancom.com>

[WCG_Corp_Logo_horiz_cFullcolorHR]<http://westmancom.com/personal/>



[cisco-certified-network-associate-routing-and-switching-ccna-routing-and-switching]



From: Ryan Hamel mailto:administra...@rkhtech.org>>
Sent: May 7, 2021 4:23 PM
To: Javier Gutierrez Guerra 
mailto:guer...@westmancom.com>>; 
nanog@nanog.org<mailto:nanog@nanog.org>
Subject: RE: Juniper hardware recommendation



CAUTION: This email is from an external source. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.

Hello!



We wouldn’t be able to give any sort of answer without knowing your current and 
future requirements. Each model has its own throughput classes, and sometimes a 
full on MX router isn’t required.



From: NANOG 
mailto:nanog-bounces+ryan=rkhtech@nanog.org>>
 On Behalf Of Javier Gutierrez Guerra
Sent: Friday, May 7, 2021 1:55 PM
To: nanog@nanog.org<mailto:nanog@nanog.org>
Subject: Juniper hardware recommendation



Hi,

Just out of curiosity, what would you recommend using for a core router/switch 
from Juniper?

MX208,480,10K

Datasheets show them all as very nice and powerful devices (although they do 
use a lot of rack space and side to side airflow is painful) but I’m just 
wondering here what most people use and how good or bad of an experience you 
have with it ??

Thanks,



Javier Gutierrez Guerra

Network Analyst

CCNA R, JNCIA

Westman Communications Group

Phone: 204-717-2827

Email: guer...@westmancom.com<mailto:guer...@westmancom.com>

[WCG_Corp_Logo_horiz_cFullcolorHR]<http://westmancom.com/personal/>



[cisco-certified-network-associate-routing-and-switching-ccna-routing-and-switching]

RE: Juniper hardware recommendation

[Tony Wicks]

You really should discuss this with you local Juniper rep in the first instance 
I would suggest.

 

From: NANOG  On Behalf Of Javier 
Gutierrez Guerra
Sent: Saturday, 8 May 2021 9:28 am
To: r...@rkhtech.org; nanog@nanog.org
Subject: RE: Juniper hardware recommendation

 

I need to do MPLS (vlls), VXLAN, Multicast, full routing tables, multiple VRFs, 
q-in-q, QoS

Anything with 1Tbs of throughput should be more than enough at this time for me

I also need it to be able to support 100G interfaces, 1G and 10G  

 

Javier Gutierrez Guerra

Network Analyst

CCNA R, JNCIA

Westman Communications Group

Phone: 204-717-2827

Email:  <mailto:guer...@westmancom.com> guer...@westmancom.com

 <http://westmancom.com/personal/> 

 



 

From: Ryan Hamel mailto:administra...@rkhtech.org> 
> 
Sent: May 7, 2021 4:23 PM
To: Javier Gutierrez Guerra mailto:guer...@westmancom.com> >; nanog@nanog.org <mailto:nanog@nanog.org> 
Subject: RE: Juniper hardware recommendation

 

CAUTION: This email is from an external source. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.

Hello!

 

We wouldn’t be able to give any sort of answer without knowing your current and 
future requirements. Each model has its own throughput classes, and sometimes a 
full on MX router isn’t required.

 

From: NANOG mailto:nanog-bounces+ryan=rkhtech@nanog.org> > On Behalf Of Javier 
Gutierrez Guerra
Sent: Friday, May 7, 2021 1:55 PM
To: nanog@nanog.org <mailto:nanog@nanog.org> 
Subject: Juniper hardware recommendation

 

Hi, 

Just out of curiosity, what would you recommend using for a core router/switch 
from Juniper?

MX208,480,10K

Datasheets show them all as very nice and powerful devices (although they do 
use a lot of rack space and side to side airflow is painful) but I’m just 
wondering here what most people use and how good or bad of an experience you 
have with it 

Thanks,

 

Javier Gutierrez Guerra

Network Analyst

CCNA R, JNCIA

Westman Communications Group

Phone: 204-717-2827

Email:  <mailto:guer...@westmancom.com> guer...@westmancom.com

 <http://westmancom.com/personal/> 

 



 

RE: Juniper hardware recommendation

[Javier Gutierrez Guerra]

I need to do MPLS (vlls), VXLAN, Multicast, full routing tables, multiple VRFs, 
q-in-q, QoS
Anything with 1Tbs of throughput should be more than enough at this time for me
I also need it to be able to support 100G interfaces, 1G and 10G

Javier Gutierrez Guerra
Network Analyst
CCNA R, JNCIA
Westman Communications Group
Phone: 204-717-2827
Email: guer...@westmancom.com<mailto:guer...@westmancom.com>
[WCG_Corp_Logo_horiz_cFullcolorHR]<http://westmancom.com/personal/>

[cisco-certified-network-associate-routing-and-switching-ccna-routing-and-switching]

From: Ryan Hamel 
Sent: May 7, 2021 4:23 PM
To: Javier Gutierrez Guerra ; nanog@nanog.org
Subject: RE: Juniper hardware recommendation


CAUTION: This email is from an external source. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.
Hello!

We wouldn’t be able to give any sort of answer without knowing your current and 
future requirements. Each model has its own throughput classes, and sometimes a 
full on MX router isn’t required.

From: NANOG 
mailto:nanog-bounces+ryan=rkhtech@nanog.org>>
 On Behalf Of Javier Gutierrez Guerra
Sent: Friday, May 7, 2021 1:55 PM
To: nanog@nanog.org<mailto:nanog@nanog.org>
Subject: Juniper hardware recommendation

Hi,
Just out of curiosity, what would you recommend using for a core router/switch 
from Juniper?
MX208,480,10K
Datasheets show them all as very nice and powerful devices (although they do 
use a lot of rack space and side to side airflow is painful) but I’m just 
wondering here what most people use and how good or bad of an experience you 
have with it 
Thanks,

Javier Gutierrez Guerra
Network Analyst
CCNA R, JNCIA
Westman Communications Group
Phone: 204-717-2827
Email: guer...@westmancom.com<mailto:guer...@westmancom.com>
[WCG_Corp_Logo_horiz_cFullcolorHR]<http://westmancom.com/personal/>

[cisco-certified-network-associate-routing-and-switching-ccna-routing-and-switching]

RE: Juniper hardware recommendation

[Ryan Hamel]

Hello!

 

We wouldn’t be able to give any sort of answer without knowing your current and 
future requirements. Each model has its own throughput classes, and sometimes a 
full on MX router isn’t required.

 

From: NANOG  On Behalf Of Javier 
Gutierrez Guerra
Sent: Friday, May 7, 2021 1:55 PM
To: nanog@nanog.org
Subject: Juniper hardware recommendation

 

Hi, 

Just out of curiosity, what would you recommend using for a core router/switch 
from Juniper?

MX208,480,10K

Datasheets show them all as very nice and powerful devices (although they do 
use a lot of rack space and side to side airflow is painful) but I’m just 
wondering here what most people use and how good or bad of an experience you 
have with it 

Thanks,

 

Javier Gutierrez Guerra

Network Analyst

CCNA R, JNCIA

Westman Communications Group

Phone: 204-717-2827

Email:   guer...@westmancom.com

  

 



 

RE: Juniper hardware recommendation

[Adam Thompson]

Hi, Javier!
MX series: Full-featured – sings, dances, walks the cat, etc. But painful 
racking (as you noted).  Very nice and comprehensive boxes otherwise.  
Interfaces are more expensive, but often modular and wider variety.
EX/QFX series: Nice switches, OK L3 routers.  Lots of limitations in MPLS and 
various other corner-case limitations.

My personal opinion:

  *   Skip the MX480 (and up), it’s just too expensive.  Consider an EX9200 
instead, which can do 90% of the same functions.  (If you can afford an MX480 
or MX960, by all means, get one!)
  *   MX240 is reasonable, but dated.  A pair of MX204s in HA would make more 
sense, to me.
  *   Skip the MX 2k/10k series – they don’t support SFP+ interfaces!  (“No 10G 
WDM for you!”)  Also no 1G, you need a separate step-down switch for that.  I 
don’t know what SP Juniper thinks they’re targeting with these.
  *   1U/2U EX/QFX are reasonable edge devices as long as you’ve verified they 
can do what you need.  Not core-router class IMHO.
  *   If you don’t already know that you want a PTX, then you don’t want a PTX. 
 The product is fine, but niche, and has the same interface limitations as 
MX10k.
  *   ACX: MEF-compliant mini-MX, basically.  Edge device only, pairs well with 
an MX480 (IIRC).  Top-end are exceptions: ACX5k/7k might work, depending on 
what you need it to do.  Not normally deployed as a core router.

My experience is that you never fill up an EX9208 or MX480 chassis, but the 
MX240 is too small.  YMMV.  MX480 line cards are stupid expensive compared to, 
well, everything else.

I’m probably out-of-date on some (or much) of my knowledge, let’s see what 
everyone else here has to say!

-Adam

Adam Thompson
Consultant, Infrastructure Services
[[MERLIN LOGO]]
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athomp...@merlin.mb.ca
www.merlin.mb.ca

From: NANOG  On Behalf Of 
Javier Gutierrez Guerra
Sent: Friday, May 7, 2021 3:55 PM
To: nanog@nanog.org
Subject: Juniper hardware recommendation

Hi,
Just out of curiosity, what would you recommend using for a core router/switch 
from Juniper?
MX208,480,10K
Datasheets show them all as very nice and powerful devices (although they do 
use a lot of rack space and side to side airflow is painful) but I’m just 
wondering here what most people use and how good or bad of an experience you 
have with it 
Thanks,

Javier Gutierrez Guerra
Network Analyst
CCNA R, JNCIA
Westman Communications Group
Phone: 204-717-2827
Email: guer...@westmancom.com
[WCG_Corp_Logo_horiz_cFullcolorHR]

[cisco-certified-network-associate-routing-and-switching-ccna-routing-and-switching]