From johan.borch at gmail.com  Thu Jul  2 08:19:15 2020
From: johan.borch at gmail.com (john doe)
Date: Thu, 2 Jul 2020 14:19:15 +0200
Subject: [j-nsp] MX SCBE firmware error
Message-ID: <CAB_jNCQNsja0a8=95qaANtEJBY2c7uD7e1P-mc=CSV9oivJ_Nw@mail.gmail.com>

Hi

I just started up an SCBE we had on the shelf, has anyone seen this error
before?

Major CB 0 SG2P Revision unsupported

CB 0             REV 20   750-031391    Enhanced MX SCB

Isn't the firmware usually bundled with software upgrades? Is there a
way to upgrade the SCBE?

Johan

From jared at puck.nether.net  Thu Jul  2 09:12:52 2020
From: jared at puck.nether.net (Jared Mauch)
Date: Thu, 2 Jul 2020 09:12:52 -0400
Subject: [j-nsp] MX SCBE firmware error
In-Reply-To: <CAB_jNCQNsja0a8=95qaANtEJBY2c7uD7e1P-mc=CSV9oivJ_Nw@mail.gmail.com>
References: <CAB_jNCQNsja0a8=95qaANtEJBY2c7uD7e1P-mc=CSV9oivJ_Nw@mail.gmail.com>
Message-ID: <36597B20-51AC-4765-AE2C-78ED889BC750@puck.nether.net>

Is this a newer one?  I?ve seen vendors release revised boards that have the same part number but require newer software.

- Jared

> On Jul 2, 2020, at 8:19 AM, john doe <johan.borch at gmail.com> wrote:
> 
> Hi
> 
> I just started up an SCBE we had on the shelf, has anyone seen this error
> before?
> 
> Major CB 0 SG2P Revision unsupported
> 
> CB 0             REV 20   750-031391    Enhanced MX SCB
> 
> Isn't the firmware usually bundled with software upgrades? Is there a
> way to upgrade the SCBE?
> 
> Johan
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


From johan.borch at gmail.com  Thu Jul  2 15:02:44 2020
From: johan.borch at gmail.com (john doe)
Date: Thu, 2 Jul 2020 21:02:44 +0200
Subject: [j-nsp] MX SCBE firmware error
In-Reply-To: <36597B20-51AC-4765-AE2C-78ED889BC750@puck.nether.net>
References: <CAB_jNCQNsja0a8=95qaANtEJBY2c7uD7e1P-mc=CSV9oivJ_Nw@mail.gmail.com>
 <36597B20-51AC-4765-AE2C-78ED889BC750@puck.nether.net>
Message-ID: <CAB_jNCR_3rQvNNPKKMMhhP1=q+EPokj_rt5AWN6A3PvbUO7dWQ@mail.gmail.com>

No it's an older card, but I can't find firmware requirements anywhere.

Johan

On Thu, Jul 2, 2020 at 3:13 PM Jared Mauch <jared at puck.nether.net> wrote:

> Is this a newer one?  I?ve seen vendors release revised boards that have
> the same part number but require newer software.
>
> - Jared
>
> > On Jul 2, 2020, at 8:19 AM, john doe <johan.borch at gmail.com> wrote:
> >
> > Hi
> >
> > I just started up an SCBE we had on the shelf, has anyone seen this error
> > before?
> >
> > Major CB 0 SG2P Revision unsupported
> >
> > CB 0             REV 20   750-031391    Enhanced MX SCB
> >
> > Isn't the firmware usually bundled with software upgrades? Is there a
> > way to upgrade the SCBE?
> >
> > Johan
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>

From robhass at gmail.com  Sun Jul  5 09:28:09 2020
From: robhass at gmail.com (Robert Hass)
Date: Sun, 5 Jul 2020 15:28:09 +0200
Subject: [j-nsp] MX80 upgrade path 18.4R
In-Reply-To: <CAMhV5+WRuNtzLjo=SFc9qQPK6GX7qBDyr5=A4PQMMv5wPn3EpQ@mail.gmail.com>
References: <CALNfFTFJF0pN6A58xrskOaE0_sLwSrg7rQs5jyMoBRr58Knckg@mail.gmail.com>
 <CAMhV5+WRuNtzLjo=SFc9qQPK6GX7qBDyr5=A4PQMMv5wPn3EpQ@mail.gmail.com>
Message-ID: <CALNfFTG6hOYoNmtJNqpUD_YSXvKzFmg0YanrqLY9B3yA8h+Rvg@mail.gmail.com>

Thanks for all the replies. Managed to upgrade 17 units. So I'm sharing -
my path for that upgrade:
10.4R -> 13.3R -> 15.1R -> 18.4R

Just ensured there is enough space on /var partition (remove unused files
in /var/tmp and old junos in /var/pkg/sw)

Rob

On Mon, Jun 15, 2020 at 6:41 PM Leon Kramer <leonkramer at gmail.com> wrote:

> Hi,
>
> +1 for recommending doing a backup of config, a complete reinstallation of
> the device and restore of config.
> More than once I experienced strange issues after updates or reboots which
> were entirely gone after reinstallation.
>
> Kind Regards
>
>
>
>
>
> Am So., 14. Juni 2020 um 11:02 Uhr schrieb Robert Hass <robhass at gmail.com
> >:
>
>> Hi
>> I have old MX80 running 10.4R14.2.
>> I would like to upgrade it to 18.4R.
>> But what upgrade I should use ?
>>
>> 10.4R -> 15.1R and to 18.4R ?
>>
>> Rob
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>

From ghenry at suretec.co.uk  Sun Jul  5 09:34:47 2020
From: ghenry at suretec.co.uk (Gavin Henry)
Date: Sun, 5 Jul 2020 14:34:47 +0100
Subject: [j-nsp] MX80 upgrade path 18.4R
In-Reply-To: <CALNfFTG6hOYoNmtJNqpUD_YSXvKzFmg0YanrqLY9B3yA8h+Rvg@mail.gmail.com>
References: <CALNfFTFJF0pN6A58xrskOaE0_sLwSrg7rQs5jyMoBRr58Knckg@mail.gmail.com>
 <CAMhV5+WRuNtzLjo=SFc9qQPK6GX7qBDyr5=A4PQMMv5wPn3EpQ@mail.gmail.com>
 <CALNfFTG6hOYoNmtJNqpUD_YSXvKzFmg0YanrqLY9B3yA8h+Rvg@mail.gmail.com>
Message-ID: <CAPcb_GKWhYY4SxMYZw6BWQGWBUG2qixD+XHfxhRSze_LzQGJ_Q@mail.gmail.com>

Hi Robert,

Have you seen any memory usage improvements yet? We're on v14 and need to
upgrade or get a pair of mx204 for our second PoP, to match our first PoP.

Thanks.

From robhass at gmail.com  Mon Jul  6 06:37:46 2020
From: robhass at gmail.com (Robert Hass)
Date: Mon, 6 Jul 2020 12:37:46 +0200
Subject: [j-nsp] MX80 upgrade path 18.4R
In-Reply-To: <CAPcb_GKWhYY4SxMYZw6BWQGWBUG2qixD+XHfxhRSze_LzQGJ_Q@mail.gmail.com>
References: <CALNfFTFJF0pN6A58xrskOaE0_sLwSrg7rQs5jyMoBRr58Knckg@mail.gmail.com>
 <CAMhV5+WRuNtzLjo=SFc9qQPK6GX7qBDyr5=A4PQMMv5wPn3EpQ@mail.gmail.com>
 <CALNfFTG6hOYoNmtJNqpUD_YSXvKzFmg0YanrqLY9B3yA8h+Rvg@mail.gmail.com>
 <CAPcb_GKWhYY4SxMYZw6BWQGWBUG2qixD+XHfxhRSze_LzQGJ_Q@mail.gmail.com>
Message-ID: <CALNfFTE=5d9gn712M5HqnS3HHeA_qJRtxOvztdrsYP1cdnB5aA@mail.gmail.com>

Hi
14% more memory is used compared to 10.4R. How many full-views you have in
RIB ?
Rob



On Sun, Jul 5, 2020 at 3:35 PM Gavin Henry <ghenry at suretec.co.uk> wrote:

> Hi Robert,
>
> Have you seen any memory usage improvements yet? We're on v14 and need to
> upgrade or get a pair of mx204 for our second PoP, to match our first PoP.
>
> Thanks.
>

From ghenry at suretec.co.uk  Mon Jul  6 06:42:03 2020
From: ghenry at suretec.co.uk (Gavin Henry)
Date: Mon, 6 Jul 2020 11:42:03 +0100
Subject: [j-nsp] MX80 upgrade path 18.4R
In-Reply-To: <CALNfFTE=5d9gn712M5HqnS3HHeA_qJRtxOvztdrsYP1cdnB5aA@mail.gmail.com>
References: <CALNfFTFJF0pN6A58xrskOaE0_sLwSrg7rQs5jyMoBRr58Knckg@mail.gmail.com>
 <CAMhV5+WRuNtzLjo=SFc9qQPK6GX7qBDyr5=A4PQMMv5wPn3EpQ@mail.gmail.com>
 <CALNfFTG6hOYoNmtJNqpUD_YSXvKzFmg0YanrqLY9B3yA8h+Rvg@mail.gmail.com>
 <CAPcb_GKWhYY4SxMYZw6BWQGWBUG2qixD+XHfxhRSze_LzQGJ_Q@mail.gmail.com>
 <CALNfFTE=5d9gn712M5HqnS3HHeA_qJRtxOvztdrsYP1cdnB5aA@mail.gmail.com>
Message-ID: <CAPcb_GLZN+UK5T_0cKsS4ZcA0cbwPhoqdthrSTf+E=tkPdJ8sQ@mail.gmail.com>

Thanks. Tons. May just go to the MX204 then.

From eng.mssk at gmail.com  Mon Jul  6 14:05:26 2020
From: eng.mssk at gmail.com (Mohammad Khalil)
Date: Mon, 6 Jul 2020 21:05:26 +0300
Subject: [j-nsp] MX104 Segregated Process
Message-ID: <CANU9EVyO=JfYv+EtSo0KgOnaUt0CiRN=CRK-gqJssVNWxHDCQg@mail.gmail.com>

Greetings
I am working on RFP and am proposing MX104 MS-MIC for edge deployment.
What I have been asked is in Cisco ESP , there is a separate process for
each function such as for NAT there is a process , for IPSEC this is a
process.
In MX104 , is there a segregated process for each service?

Thanks

From davidm at futureinquestion.net  Tue Jul  7 02:42:30 2020
From: davidm at futureinquestion.net (David Monosov)
Date: Tue, 7 Jul 2020 08:42:30 +0200
Subject: [j-nsp] MX104 Segregated Process
In-Reply-To: <CANU9EVyO=JfYv+EtSo0KgOnaUt0CiRN=CRK-gqJssVNWxHDCQg@mail.gmail.com>
References: <CANU9EVyO=JfYv+EtSo0KgOnaUt0CiRN=CRK-gqJssVNWxHDCQg@mail.gmail.com>
Message-ID: <a22cf41b-0b07-158d-6382-60e38bf6ca17@futureinquestion.net>

Hi Mohammad!

JunOS is modular (overview of the various processes at
https://www.juniper.net/documentation/en_US/junos/topics/reference/general/junos-os-processes.html).
Much of the functionality you are interested in, however, is contained inside a
single `adaptive-services` process.

There is generally a considerable gap between compartmentalization as it is
currently implemented by various vendors in their network operating systems and
the paradigm of each protocol/function-peer pair as a discrete process that can
crash independently.

For procurement purposes, it may be worth considering if a function-segmented
modular approach is, in fact, likely to improve reliability in your particular
scenario.

In edge deployments, functions are often stacked (for example, NAT, then IPSec,
then dynamic routing). In such scenarios, from the perspective of a packet, a
failure of any one function would disrupt the service as a whole - and
additional de-coupling can create new and difficult to troubleshoot
de-synchronization bugs between processes. This distinction, thus, may prove
less important or beneficial than it first appears.

--
Sincerely,

David Monosov

On 06/07/2020 20:05, Mohammad Khalil wrote:
> Greetings
> I am working on RFP and am proposing MX104 MS-MIC for edge deployment.
> What I have been asked is in Cisco ESP , there is a separate process for
> each function such as for NAT there is a process , for IPSEC this is a
> process.
> In MX104 , is there a segregated process for each service?
> 
> Thanks
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 

From baldur at gigabit.dk  Thu Jul  9 07:48:16 2020
From: baldur at gigabit.dk (Baldur Norddahl)
Date: Thu, 9 Jul 2020 13:48:16 +0200
Subject: [j-nsp] DHCP relay monitoring
Message-ID: <c4c4701d-f632-c6c2-2a30-4e8e635cd7f5@gigabit.dk>

Hello

On one of my MX204 routers the DHCP relay crashes after some running 
time and the process stops. It is not restarted automatically but will 
start again with the following command:

admin at gc-edge1> restart dhcp-service
error: Junos Dynamic Host Configuration Protocol process is not running
Junos Dynamic Host Configuration Protocol process started, pid 72256

I can open a case with JTAC for the cause of the crash, but I am 
thinking about how to monitor the relay. None of my current monitoring 
tools detects this situation and it is actually quite critical. With no 
relay the customers DHCP lease may expire. To a certain extend the 
customers will be using unicast to the DHCP server and not many will 
feel it right away, but soon enough we will have customers that can not 
get online after rebooting their CPE etc.

What options do we have for monitoring running processes on the router? 
Are there other processes than DHCP that should be monitored too?

Regards,

Baldur



From juniper-nsp at daork.net  Thu Jul  9 09:03:44 2020
From: juniper-nsp at daork.net (Nathan Ward)
Date: Fri, 10 Jul 2020 01:03:44 +1200
Subject: [j-nsp] DHCP relay monitoring
In-Reply-To: <c4c4701d-f632-c6c2-2a30-4e8e635cd7f5@gigabit.dk>
References: <c4c4701d-f632-c6c2-2a30-4e8e635cd7f5@gigabit.dk>
Message-ID: <A49ABFF3-FC92-4119-9EBB-3EAB57E906F7@daork.net>


> On 9/07/2020, at 23:48, Baldur Norddahl <baldur at gigabit.dk> wrote:
> 
> Hello
> 
> On one of my MX204 routers the DHCP relay crashes after some running time and the process stops. It is not restarted automatically but will start again with the following command:

What version are you on? Are you running IPv6? PPP with IPv6 over the top?

> admin at gc-edge1> restart dhcp-service
> error: Junos Dynamic Host Configuration Protocol process is not running
> Junos Dynamic Host Configuration Protocol process started, pid 72256
> 
> I can open a case with JTAC for the cause of the crash, but I am thinking about how to monitor the relay. None of my current monitoring tools detects this situation and it is actually quite critical. With no relay the customers DHCP lease may expire. To a certain extend the customers will be using unicast to the DHCP server and not many will feel it right away, but soon enough we will have customers that can not get online after rebooting their CPE etc.
> 
> What options do we have for monitoring running processes on the router? Are there other processes than DHCP that should be monitored too?

One option I?ve used for very similar sounding issues is doing this on the DHCP server, collecting stats for requests per giaddr and alerting when they?re suddenly low.

You might see something in the logs when DHCP crashes and can alarm on that with your chosen syslog system.

JUNIPER-JDHCP-MIB may be useful - though when the DHCP process is dead you may get polling timeouts. If your polling system can alarm on that you might get usefulness there.
 
--
Nathan Ward


From cma at cmadams.net  Thu Jul  9 09:24:22 2020
From: cma at cmadams.net (Chris Adams)
Date: Thu, 9 Jul 2020 08:24:22 -0500
Subject: [j-nsp] DHCP relay monitoring
In-Reply-To: <c4c4701d-f632-c6c2-2a30-4e8e635cd7f5@gigabit.dk>
References: <c4c4701d-f632-c6c2-2a30-4e8e635cd7f5@gigabit.dk>
Message-ID: <20200709132422.GA15581@cmadams.net>

Once upon a time, Baldur Norddahl <baldur at gigabit.dk> said:
> What options do we have for monitoring running processes on the
> router? Are there other processes than DHCP that should be monitored
> too?

JUNOS implements many of the standard SNMP MIBs, which include
information about open TCP/UDP ports, so you could monitor
UDP-MIB::udpLocalAddress.0.0.0.0.67.  If dhcp-relay is running, that
variable should return 0.0.0.0; if not, the variable won't exist.

-- 
Chris Adams <cma at cmadams.net>

From thowe at bendtel.net  Thu Jul  9 11:48:22 2020
From: thowe at bendtel.net (Tim Howe)
Date: Thu, 9 Jul 2020 08:48:22 -0700
Subject: [j-nsp] DHCP relay monitoring
In-Reply-To: <c4c4701d-f632-c6c2-2a30-4e8e635cd7f5@gigabit.dk>
References: <c4c4701d-f632-c6c2-2a30-4e8e635cd7f5@gigabit.dk>
Message-ID: <20200709084822.0b57385f@Morty>

On Thu, 9 Jul 2020 13:48:16 +0200
Baldur Norddahl <baldur at gigabit.dk> wrote:

> [snip]
> 
> I can open a case with JTAC for the cause of the crash, but I am 
> thinking about how to monitor the relay.

	In the past I have used traceoptions, which was helpful.

Under system, processes, dhcp-service, traceoptions I have done:
  file DHCP.log size 100m files 3;
  level all;              
  flag all;

	You can then look at that file.  There will be a lot of info.

This works on my ACX5048.  I have not tried on an MX.

--TimH

From martin at jumation.com  Thu Jul  9 13:58:32 2020
From: martin at jumation.com (Martin Tonusoo)
Date: Thu, 9 Jul 2020 20:58:32 +0300
Subject: [j-nsp] DHCP relay monitoring
In-Reply-To: <20200709084822.0b57385f@Morty>
References: <c4c4701d-f632-c6c2-2a30-4e8e635cd7f5@gigabit.dk>
 <20200709084822.0b57385f@Morty>
Message-ID: <CAHy0MsccdtYF8KqCOGhKoNj7jDhK7H-Ymsr=TD8fdj4QRZpYSg@mail.gmail.com>

Hi,

> On one of my MX204 routers the DHCP relay crashes after some running time
and the process stops.

if you are looking for a temporary workaround, then you could periodically
check if the jdhcpd process is running and if it isn't, then restart it.
Something like this:
https://gist.github.com/tonusoo/084ac04cab30151ce7d2911a13320838
Does the jdhcpd log something when it crashes? Perhaps a better approach
would be to trigger the restart based on the jdhcpd (traceoptions) log
message as the process will get restored pretty much immediately.


WBR,
Martin

From defir1932 at gmail.com  Fri Jul 24 04:00:43 2020
From: defir1932 at gmail.com (Jim Alias)
Date: Fri, 24 Jul 2020 09:00:43 +0100
Subject: [j-nsp] MX SCBE firmware error
In-Reply-To: <CAB_jNCR_3rQvNNPKKMMhhP1=q+EPokj_rt5AWN6A3PvbUO7dWQ@mail.gmail.com>
References: <CAB_jNCQNsja0a8=95qaANtEJBY2c7uD7e1P-mc=CSV9oivJ_Nw@mail.gmail.com>
 <36597B20-51AC-4765-AE2C-78ED889BC750@puck.nether.net>
 <CAB_jNCR_3rQvNNPKKMMhhP1=q+EPokj_rt5AWN6A3PvbUO7dWQ@mail.gmail.com>
Message-ID: <CAAR0xkbp_WOZDFgTkLOZm33aHVk4SYCg5HP2v8YvR5Cue+eCBg@mail.gmail.com>

See https://kb.juniper.net/InfoCenter/index?page=content&id=KB26889 (requires
a Juniper login). You could be hitting a PR, or the card is physically
damaged.

Also try restarting the CB:

* To ?reset a Control Board?, for example on an MX480:
* Run the CLI command ?request chassis cb slot # offline?,
* Wait 30 seconds.
* Then follow with the CLI command ?request chassis cb slot # online?.

On Thu, Jul 2, 2020 at 8:07 PM john doe <johan.borch at gmail.com> wrote:

> No it's an older card, but I can't find firmware requirements anywhere.
>
> Johan
>
> On Thu, Jul 2, 2020 at 3:13 PM Jared Mauch <jared at puck.nether.net> wrote:
>
> > Is this a newer one?  I?ve seen vendors release revised boards that have
> > the same part number but require newer software.
> >
> > - Jared
> >
> > > On Jul 2, 2020, at 8:19 AM, john doe <johan.borch at gmail.com> wrote:
> > >
> > > Hi
> > >
> > > I just started up an SCBE we had on the shelf, has anyone seen this
> error
> > > before?
> > >
> > > Major CB 0 SG2P Revision unsupported
> > >
> > > CB 0             REV 20   750-031391    Enhanced MX SCB
> > >
> > > Isn't the firmware usually bundled with software upgrades? Is there a
> > > way to upgrade the SCBE?
> > >
> > > Johan
> > > _______________________________________________
> > > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> >
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

From baldur at gigabit.dk  Fri Jul 24 06:55:23 2020
From: baldur at gigabit.dk (Baldur Norddahl)
Date: Fri, 24 Jul 2020 12:55:23 +0200
Subject: [j-nsp] vrrp on a vpls / ps interface
Message-ID: <c9191832-5d18-655a-26b8-916461a225e4@gigabit.dk>

Hello

I noticed that VRRP on a ps interface does not seem to work. Is there 
anything I can do about that or is that not supported?

This is on MX204. Exact same configuration is working fine on et-0/0/0.16.

admin at gc-edge1> show configuration interfaces ps2
anchor-point {
 ??? lt-0/0/0;
}
flexible-vlan-tagging;
unit 0 {
 ??? description Server;
 ??? encapsulation ethernet-vpls;
}
unit 16 {
 ??? description "Server CGN";
 ??? vlan-tags outer 99 inner 16;
 ??? family inet {
 ??????? address 100.127.254.2/24 {
 ??????????? vrrp-group 159 {
 ??????????????? virtual-address 100.127.254.1;
 ??????????????? priority 10;
 ??????????????? preempt;
 ??????????????? accept-data;
 ??????????? }
 ??????????? vrrp-group 164 {
 ??????????????? virtual-address 100.127.254.7;
 ??????????????? priority 10;
 ??????????????? preempt;
 ??????????????? accept-data;
 ??????????? }
 ??????? }
 ??? }
}

admin at gc-edge1> show vrrp
Interface???? State?????? Group?? VR state VR Mode?? Timer??? Type Address
et-0/0/0.14?? up??????????? 161?? master?? Active????? A? 0.113 lcl??? 
10.0.1.159
vip??? 10.0.1.160
et-0/0/0.14?? up??????????? 162?? backup?? Active????? D? 2.825 lcl??? 
10.0.1.159
vip??? 10.0.1.1
mas??? 10.0.1.158
(etc... ps2.16 is not here)

Thanks,

Baldur



From rwf at loonybin.net  Mon Jul 27 23:05:44 2020
From: rwf at loonybin.net (Rob Foehl)
Date: Mon, 27 Jul 2020 23:05:44 -0400 (EDT)
Subject: [j-nsp] BGP output queue priorities between RIBs/NLRIs
Message-ID: <alpine.LFD.2.23.451.2007272200340.76649@bugs.loonybin.net>

Anyone know the secret to getting BGP output queue priorities working 
across multiple NLRIs?

Had trouble with EVPN routes getting stuck behind full refreshes of the v4 
RIB, often for minutes at a time, which causes havoc with the default DF 
election hold timer of 3 seconds.  Bumping those timers up to tens of 
minutes solves this, but... poorly.

The documentation[1] says:

"In the default configuration, that is, when no output-queue-priority 
configuration or policy that overrides priority exists, the routing 
protocol process (rpd) enqueues BGP routes into the output queue per 
routing information base (RIB). [...] While processing output queues, the 
BGP update code flushes the output queue for the current RIB before moving 
on to the next RIB that has a non-empty output queue."

I've tried about a dozen combinations of options, and cannot get any other 
result with inet/evpn routes in the same session -- inet.0 routes always 
arrive ahead of *.evpn.0.  Am I missing something[2], or is that text not 
quite accurate?

-Rob


[1] https://www.juniper.net/documentation/en_US/junos/topics/topic-map/bgp-route-prioritization.html

[2] Highlight reel of failed attempts, all on 19.2R2 thus far:

- "show bgp output-scheduler" is empty without top-level "protocols bgp
   output-queue-priority" config, regardless of anything else

- Top-level "protocols bgp family evpn signaling" priority config -- and
   nothing else within that stanza -- broke every v6 session on the box,
   even with family inet6 explicitly configured under those groups

- Per-group family evpn priority config would show up under "show bgp
   group output-queues" and similar, but adding family inet would cause the
   NLRI evpn priority output to disappear

- Policy-level adjustments to any of the above had no effect between NLRIs

- "show bgp neighbor output-queue" output always looks like this:

   Peer: x.x.x.x+179 AS 20021 Local: y.y.y.y+52199 AS n
     Output Queue[1]: 0            (inet.0, inet-unicast)

   Peer: x.x.x.x+179 AS 20021 Local: y.y.y.y+52199 AS n
     Output Queue[2]: 0            (bgp.evpn.0, evpn)

   ...which seems to fit the default per-RIB behavior as described.


From jhaas at juniper.net  Tue Jul 28 09:45:49 2020
From: jhaas at juniper.net (Jeffrey Haas)
Date: Tue, 28 Jul 2020 09:45:49 -0400
Subject: [j-nsp] BGP output queue priorities between RIBs/NLRIs
In-Reply-To: <alpine.LFD.2.23.451.2007272200340.76649@bugs.loonybin.net>
References: <alpine.LFD.2.23.451.2007272200340.76649@bugs.loonybin.net>
Message-ID: <025A93F2-E5CC-4359-B2D9-E6D6A0A82D37@juniper.net>

See below:

> On Jul 27, 2020, at 11:05 PM, Rob Foehl <rwf at loonybin.net> wrote:
> 
> [External Email. Be cautious of content]
> 
> 
> Anyone know the secret to getting BGP output queue priorities working
> across multiple NLRIs?
> 
> Had trouble with EVPN routes getting stuck behind full refreshes of the v4
> RIB, often for minutes at a time, which causes havoc with the default DF
> election hold timer of 3 seconds.  Bumping those timers up to tens of
> minutes solves this, but... poorly.
> 
> The documentation[1] says:
> 
> "In the default configuration, that is, when no output-queue-priority
> configuration or policy that overrides priority exists, the routing
> protocol process (rpd) enqueues BGP routes into the output queue per
> routing information base (RIB). [...] While processing output queues, the
> BGP update code flushes the output queue for the current RIB before moving
> on to the next RIB that has a non-empty output queue."
> 
> I've tried about a dozen combinations of options, and cannot get any other
> result with inet/evpn routes in the same session -- inet.0 routes always
> arrive ahead of *.evpn.0.  Am I missing something[2], or is that text not
> quite accurate?
> 
> -Rob
> 
> 
> [1] https://www.juniper.net/documentation/en_US/junos/topics/topic-map/bgp-route-prioritization.html
> 
> [2] Highlight reel of failed attempts, all on 19.2R2 thus far:
> 
> - "show bgp output-scheduler" is empty without top-level "protocols bgp
>  output-queue-priority" config, regardless of anything else
> 
> - Top-level "protocols bgp family evpn signaling" priority config -- and
>  nothing else within that stanza -- broke every v6 session on the box,
>  even with family inet6 explicitly configured under those groups

If you're simply trying to prioritize evpn differently than inet unicast, simply having a separate priority for that address family should have been sufficient.

Can you clarify what you mean "broke every v6 session"?

I think what you're running into is one of the generally gross things about the address-family stanza and the inheritance model global => group => neighbor.  If you specify ANY address-family configuration at a given scope level, it doesn't treat it as inheriting the less specific scopes; it overrides it.

FWIW, the use case of "prioritize a family different" is one of the things this was intended to address.  Once you have a working config you may find that you want to do policy driven config and use the route-type policy to prioritize the DF related routes in its own queue.  That way you're not dealing with the swarm of ARP related routes.

-- Jeff



> 
> - Per-group family evpn priority config would show up under "show bgp
>  group output-queues" and similar, but adding family inet would cause the
>  NLRI evpn priority output to disappear
> 
> - Policy-level adjustments to any of the above had no effect between NLRIs
> 
> - "show bgp neighbor output-queue" output always looks like this:
> 
>  Peer: x.x.x.x+179 AS 20021 Local: y.y.y.y+52199 AS n
>    Output Queue[1]: 0            (inet.0, inet-unicast)
> 
>  Peer: x.x.x.x+179 AS 20021 Local: y.y.y.y+52199 AS n
>    Output Queue[2]: 0            (bgp.evpn.0, evpn)
> 
>  ...which seems to fit the default per-RIB behavior as described.
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!Xqncm4WhWcDxEBmq2G8Oj_x0PGbBfFynQ62E2OyAj00qIuijy3p3IqwTnSifXP8$


From michael.hare at wisc.edu  Tue Jul 28 11:25:50 2020
From: michael.hare at wisc.edu (Michael Hare)
Date: Tue, 28 Jul 2020 15:25:50 +0000
Subject: [j-nsp] BGP output queue priorities between RIBs/NLRIs
In-Reply-To: <alpine.LFD.2.23.451.2007272200340.76649@bugs.loonybin.net>
References: <alpine.LFD.2.23.451.2007272200340.76649@bugs.loonybin.net>
Message-ID: <BN8PR06MB5761A0C967E5643627CF1096F9730@BN8PR06MB5761.namprd06.prod.outlook.com>

I'm quite interesting in this topic as I am in the same boat.  I have problems similar to Rob in 18.3R3.

We do have jtac support but I haven't contacted them; a time/priority issue so far.

- "show bgp output-scheduler" is empty without top-level "protocols bgp output-queue-priority" config, regardless of anything else
= same here, so I pasted a canonical top level from https://www.juniper.net/documentation/en_US/junos/topics/topic-map/bgp-route-prioritization.html]
= I'm not sure I get the significance of the defaults section if priority has a token assignment; what ends up in low/medium/high by default?  Is his related to assignment via policy-statement?

        protocols {
            bgp {
                output-queue-priority {
                    expedited update-tokens 100;
                    priority 1 update-tokens 1;
                    priority 2 update-tokens 10;
..
..
                    priority 15 update-tokens 75;
                    priority 16 update-tokens 80;
                    defaults {
                        low priority 1;
                        medium priority 10;
                        high expedited;
                    }
                }
            }
        }

Anyway, I tried the following under lab iBGP, for fun, to prioritize VPN-ish things before global [for us internet is NOT in VRF].

Group: iBGP-reflector-client-v4
                    family inet-vpn {
                        unicast {
                            output-queue-priority priority 10;
                            route-refresh-priority priority 4;
                            withdraw-priority priority 16;
                        }
                    }
                    family inet6-vpn {
                        unicast {
                            output-queue-priority priority 10;
                            route-refresh-priority priority 4;
                            withdraw-priority priority 16;
                        }
                    }
                    family evpn {
                        signaling {
                            output-queue-priority priority 11;
                            route-refresh-priority priority 5;
                            withdraw-priority expedited;
                        }
                    }


And output [below] is implying on the first nlri in the list has priority.  Where is the priority output for evpn and inet6-vpn-unicast?  With this technique must you do a different group per NLRI?  

Lastly the lack of counters and reliance on gauges makes it really difficult to determine what is going .

@lab # run show bgp group output-queues iBGP-reflector-client-v4 
Group Type: Internal    AS: 65400                  Local AS: 65400
  Name: iBGP-reflector-client-v4 Index: 4          Flags: <Export Eval>
  Export: [ flowspec-advertise select-iBGP-reflector-routes next-hop-self accept-selected-routes ] 
  Options: <Confed>
  Holdtime: 0
  NLRI inet-vpn-unicast: 
    OutQ: priority 10 RRQ: priority 4 WDQ: priority 16 

  Total peers: 2        Established: 2
  $rrip1+179
  $rrip2+179
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0               
                                 12          0
inetflow.0           
                                  0          0
bgp.l3vpn.0          
                                  6          0
bgp.l3vpn-inet6.0    
                                  6          0
bgp.evpn.0           
                                 38          0
L3VPN-9105.inet.0    
                                  1          0
L3VPN-9105.inet6.0   
                                  1          0
L3VPN-9104.inet.0    
                                  1          0
L3VPN-9104.inet6.0   
                                  1          0
EVPN-9100.evpn.0     
                                 31          0
EVPN-9101.evpn.0     
                                  3          0
__default_evpn__.evpn.0 
                                  4          0

[FIN]

-Michael


> -----Original Message-----
> From: juniper-nsp <juniper-nsp-bounces at puck.nether.net> On Behalf Of Rob
> Foehl
> Sent: Monday, July 27, 2020 10:06 PM
> To: juniper-nsp at puck.nether.net
> Subject: [j-nsp] BGP output queue priorities between RIBs/NLRIs
> 
> Anyone know the secret to getting BGP output queue priorities working
> across multiple NLRIs?
> 
> Had trouble with EVPN routes getting stuck behind full refreshes of the v4
> RIB, often for minutes at a time, which causes havoc with the default DF
> election hold timer of 3 seconds.  Bumping those timers up to tens of
> minutes solves this, but... poorly.
> 
> The documentation[1] says:
> 
> "In the default configuration, that is, when no output-queue-priority
> configuration or policy that overrides priority exists, the routing
> protocol process (rpd) enqueues BGP routes into the output queue per
> routing information base (RIB). [...] While processing output queues, the
> BGP update code flushes the output queue for the current RIB before moving
> on to the next RIB that has a non-empty output queue."
> 
> I've tried about a dozen combinations of options, and cannot get any other
> result with inet/evpn routes in the same session -- inet.0 routes always
> arrive ahead of *.evpn.0.  Am I missing something[2], or is that text not
> quite accurate?
> 
> -Rob
> 
> 
> [1] https://www.juniper.net/documentation/en_US/junos/topics/topic-
> map/bgp-route-prioritization.html
> 
> [2] Highlight reel of failed attempts, all on 19.2R2 thus far:
> 
> - "show bgp output-scheduler" is empty without top-level "protocols bgp
>    output-queue-priority" config, regardless of anything else
> 
> - Top-level "protocols bgp family evpn signaling" priority config -- and
>    nothing else within that stanza -- broke every v6 session on the box,
>    even with family inet6 explicitly configured under those groups
> 
> - Per-group family evpn priority config would show up under "show bgp
>    group output-queues" and similar, but adding family inet would cause the
>    NLRI evpn priority output to disappear
> 
> - Policy-level adjustments to any of the above had no effect between NLRIs
> 
> - "show bgp neighbor output-queue" output always looks like this:
> 
>    Peer: x.x.x.x+179 AS 20021 Local: y.y.y.y+52199 AS n
>      Output Queue[1]: 0            (inet.0, inet-unicast)
> 
>    Peer: x.x.x.x+179 AS 20021 Local: y.y.y.y+52199 AS n
>      Output Queue[2]: 0            (bgp.evpn.0, evpn)
> 
>    ...which seems to fit the default per-RIB behavior as described.
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

From rwf at loonybin.net  Wed Jul 29 06:38:02 2020
From: rwf at loonybin.net (Rob Foehl)
Date: Wed, 29 Jul 2020 06:38:02 -0400 (EDT)
Subject: [j-nsp] BGP output queue priorities between RIBs/NLRIs
In-Reply-To: <025A93F2-E5CC-4359-B2D9-E6D6A0A82D37@juniper.net>
References: <alpine.LFD.2.23.451.2007272200340.76649@bugs.loonybin.net>
 <025A93F2-E5CC-4359-B2D9-E6D6A0A82D37@juniper.net>
Message-ID: <alpine.LFD.2.23.451.2007290612100.76649@bugs.loonybin.net>

On Tue, 28 Jul 2020, Jeffrey Haas wrote:

>> - "show bgp output-scheduler" is empty without top-level "protocols bgp
>>  output-queue-priority" config, regardless of anything else
>>
>> - Top-level "protocols bgp family evpn signaling" priority config -- and
>>  nothing else within that stanza -- broke every v6 session on the box,
>>  even with family inet6 explicitly configured under those groups
>
> If you're simply trying to prioritize evpn differently than inet unicast, simply having a separate priority for that address family should have been sufficient.

Right, that's what I took away from the docs...  No luck in any case, 
starting from the "simplest" of just adding this:

set protocols bgp group X family evpn signaling output-queue-priority expedited

That'll produce this in "show bgp group output-queues" for that group:

   NLRI evpn:
     OutQ: expedited RRQ: priority 1 WDQ: priority 1

...but that's it, and no change in behavior.  Same config for family inet 
in the same group would show NLRI inet: output, and no more evpn if both 
were configured.  Still no change.

> Can you clarify what you mean "broke every v6 session"?

For that one, it shut down every session on the box that didn't explicitly 
have family inet / family evpn configured at the group/neighbor level, 
refused all the incoming family inet sessions with NLRI mismatch (trying 
to send evpn only), and made no attempt to reestablish any of the family 
inet6 sessions.

> I think what you're running into is one of the generally gross things about the address-family stanza and the inheritance model global => group => neighbor.  If you specify ANY address-family configuration at a given scope level, it doesn't treat it as inheriting the less specific scopes; it overrides it.

In that specific case, yes; maybe I didn't wait long enough, but this was 
only an experiment to see whether setting something under global family 
evpn would do anything different -- and had about the expected result, 
given the way inheritance works.  (This was the least surprising result 
out of everything I tried.  I have logs, if you want 'em.)

> FWIW, the use case of "prioritize a family different" is one of the things this was intended to address.  Once you have a working config you may find that you want to do policy driven config and use the route-type policy to prioritize the DF related routes in its own queue.  That way you're not dealing with the swarm of ARP related routes.

Eventually, yes -- same for certain classes of inet routes -- but for now 
I'd have been happy with "just shove everything EVPN into the expedited 
queue".  I couldn't get them ahead of inet, and it was a many-minute wait 
for anything else to arrive, so pretty easy to observe...

-Rob


>> - Per-group family evpn priority config would show up under "show bgp
>>  group output-queues" and similar, but adding family inet would cause the
>>  NLRI evpn priority output to disappear
>>
>> - Policy-level adjustments to any of the above had no effect between NLRIs
>>
>> - "show bgp neighbor output-queue" output always looks like this:
>>
>>  Peer: x.x.x.x+179 AS 20021 Local: y.y.y.y+52199 AS n
>>    Output Queue[1]: 0            (inet.0, inet-unicast)
>>
>>  Peer: x.x.x.x+179 AS 20021 Local: y.y.y.y+52199 AS n
>>    Output Queue[2]: 0            (bgp.evpn.0, evpn)
>>
>>  ...which seems to fit the default per-RIB behavior as described.

From mark.tinka at seacom.com  Wed Jul 29 09:41:33 2020
From: mark.tinka at seacom.com (Mark Tinka)
Date: Wed, 29 Jul 2020 15:41:33 +0200
Subject: [j-nsp] ACX5448 & ACX710 - Update!
In-Reply-To: <CAMDdSzOtLD+7rk9+ftyukb1MBk9FooeMV+Y68texmiikZiRpNg@mail.gmail.com>
References: <223399a3-b0fd-7b07-fe99-9f98ccca62b5@seacom.mu>
 <CACqnVtYEr0f_eCJzbY5_pcZ7KA4Xx4DemDU1jVsP5Fy0GwEUsg@mail.gmail.com>
 <64460d1e-1d2d-d00b-427c-40aac5e6cd4e@seacom.mu>
 <CAAeewD9QTzdG1MSjeNrEaxkO_b0B0xGPo4f65YX=mBKueB6Mhg@mail.gmail.com>
 <21ab8cf5-0318-14b4-a009-ef478d3c40d2@seacom.mu>
 <CAMDdSzOtLD+7rk9+ftyukb1MBk9FooeMV+Y68texmiikZiRpNg@mail.gmail.com>
Message-ID: <1bc55d32-1035-d9e1-33b0-8a7e0dc31220@seacom.com>

So an update on this thread...

Juniper went ahead and made the ACX710 a DC-only box. So if you are an
AC house, you're in deep doo-doo (which is us).

DC, for large scale deployment in the Metro? Makes zero sense to me.

Apparently, no way around this; which, to me, smells of the box being
built for some larger operator (like mobile), who primarily have DC
plants. And that's it - no other options for anyone else.

Oh, these vendors...

I haven't yet seen an ACX710 outside of a PDF, but deep scouring on the
Internet led me to this:

???
https://portal.nca.org.gh/search_type_approval_view_details.php?typeApproveDetailID=2244

Some kind of type approval with National Communications Authority of Ghana.

Mark.


From eric at atlantech.net  Wed Jul 29 09:49:32 2020
From: eric at atlantech.net (Eric Van Tol)
Date: Wed, 29 Jul 2020 13:49:32 +0000
Subject: [j-nsp] ACX5448 & ACX710 - Update!
In-Reply-To: <1bc55d32-1035-d9e1-33b0-8a7e0dc31220@seacom.com>
References: <223399a3-b0fd-7b07-fe99-9f98ccca62b5@seacom.mu>
 <CACqnVtYEr0f_eCJzbY5_pcZ7KA4Xx4DemDU1jVsP5Fy0GwEUsg@mail.gmail.com>
 <64460d1e-1d2d-d00b-427c-40aac5e6cd4e@seacom.mu>
 <CAAeewD9QTzdG1MSjeNrEaxkO_b0B0xGPo4f65YX=mBKueB6Mhg@mail.gmail.com>
 <21ab8cf5-0318-14b4-a009-ef478d3c40d2@seacom.mu>
 <CAMDdSzOtLD+7rk9+ftyukb1MBk9FooeMV+Y68texmiikZiRpNg@mail.gmail.com>
 <1bc55d32-1035-d9e1-33b0-8a7e0dc31220@seacom.com>
Message-ID: <7742B083-CFAD-4C35-A81E-1282354B90E7@atlantech.net>

We ran into this, too. We signed up to beta test at the beginning of this year and nowhere, not even in discussions with our SE (who also wasn't told by Juniper), was it mentioned it was a DC-only device. Imagine my surprise when I received the box and it was DC only. Such a disappointment.

-evt

?On 7/29/20, 9:43 AM, "juniper-nsp on behalf of Mark Tinka" <juniper-nsp-bounces at puck.nether.net on behalf of mark.tinka at seacom.com> wrote:

    So an update on this thread...

    Juniper went ahead and made the ACX710 a DC-only box. So if you are an
    AC house, you're in deep doo-doo (which is us).

    DC, for large scale deployment in the Metro? Makes zero sense to me.

    Apparently, no way around this; which, to me, smells of the box being
    built for some larger operator (like mobile), who primarily have DC
    plants. And that's it - no other options for anyone else.

    Oh, these vendors...

    I haven't yet seen an ACX710 outside of a PDF, but deep scouring on the
    Internet led me to this:


    https://portal.nca.org.gh/search_type_approval_view_details.php?typeApproveDetailID=2244

    Some kind of type approval with National Communications Authority of Ghana.

    Mark.

    _______________________________________________
    juniper-nsp mailing list juniper-nsp at puck.nether.net
    https://puck.nether.net/mailman/listinfo/juniper-nsp


From mark.tinka at seacom.com  Wed Jul 29 10:23:53 2020
From: mark.tinka at seacom.com (Mark Tinka)
Date: Wed, 29 Jul 2020 16:23:53 +0200
Subject: [j-nsp] ACX5448 & ACX710 - Update!
In-Reply-To: <7742B083-CFAD-4C35-A81E-1282354B90E7@atlantech.net>
References: <223399a3-b0fd-7b07-fe99-9f98ccca62b5@seacom.mu>
 <CACqnVtYEr0f_eCJzbY5_pcZ7KA4Xx4DemDU1jVsP5Fy0GwEUsg@mail.gmail.com>
 <64460d1e-1d2d-d00b-427c-40aac5e6cd4e@seacom.mu>
 <CAAeewD9QTzdG1MSjeNrEaxkO_b0B0xGPo4f65YX=mBKueB6Mhg@mail.gmail.com>
 <21ab8cf5-0318-14b4-a009-ef478d3c40d2@seacom.mu>
 <CAMDdSzOtLD+7rk9+ftyukb1MBk9FooeMV+Y68texmiikZiRpNg@mail.gmail.com>
 <1bc55d32-1035-d9e1-33b0-8a7e0dc31220@seacom.com>
 <7742B083-CFAD-4C35-A81E-1282354B90E7@atlantech.net>
Message-ID: <20da5077-591f-d344-d6f2-9eb97c996e4a@seacom.com>



On 29/Jul/20 15:49, Eric Van Tol wrote:
> We ran into this, too. We signed up to beta test at the beginning of this year and nowhere, not even in discussions with our SE (who also wasn't told by Juniper), was it mentioned it was a DC-only device. Imagine my surprise when I received the box and it was DC only. Such a disappointment.

The messaging we got from them earlier in the year about trying out
their new Metro-E box was that we would be happy with it, considering
that every Metro-E solution they've thrown at us since 2008 has fallen
flat, splat!

Come game-time, even our own SE was blindsided by this DC-only support
on the ACX710. Proper show-stopper.

At any rate, the story is that they should be pushing out some new
ACX7xxx boxes from next year, which should have AC support (to you
psych. majors: more for the general public, and not the custom-built
ACX710).

I'm not sure I can be that patient, so I'm sniffing at Nokia's new
Metro-E product line. The problem is so far, as with Juniper and Cisco,
they've gone down the Broadcom route (some boxes shipping with Qumran,
others with Jericho 2, and on-paper, they are already failing some of
our forwarding requirements.

It's not easy...

Mark.


From baldur at gigabit.dk  Wed Jul 29 14:18:10 2020
From: baldur at gigabit.dk (Baldur Norddahl)
Date: Wed, 29 Jul 2020 20:18:10 +0200
Subject: [j-nsp] ACX5448 & ACX710 - Update!
In-Reply-To: <20da5077-591f-d344-d6f2-9eb97c996e4a@seacom.com>
References: <223399a3-b0fd-7b07-fe99-9f98ccca62b5@seacom.mu>
 <CACqnVtYEr0f_eCJzbY5_pcZ7KA4Xx4DemDU1jVsP5Fy0GwEUsg@mail.gmail.com>
 <64460d1e-1d2d-d00b-427c-40aac5e6cd4e@seacom.mu>
 <CAAeewD9QTzdG1MSjeNrEaxkO_b0B0xGPo4f65YX=mBKueB6Mhg@mail.gmail.com>
 <21ab8cf5-0318-14b4-a009-ef478d3c40d2@seacom.mu>
 <CAMDdSzOtLD+7rk9+ftyukb1MBk9FooeMV+Y68texmiikZiRpNg@mail.gmail.com>
 <1bc55d32-1035-d9e1-33b0-8a7e0dc31220@seacom.com>
 <7742B083-CFAD-4C35-A81E-1282354B90E7@atlantech.net>
 <20da5077-591f-d344-d6f2-9eb97c996e4a@seacom.com>
Message-ID: <CAPq_dj-iYs5ES2YL3HuiNrmM+2G_0L0_c6oPvCmmP1GzLzKRcg@mail.gmail.com>

I am planning to deploy ACX710 with maybe 20 units (which for us is a huge
number). We would have ordered DC in any case, so that is a non issue. We
will have them at CO buildings were DC is what you get and maybe in the
future in road side cabinets, where DC is the easy way to have some battery
backup.

I am also going to get a few ACX5448 for our datacentre locations. I am
still considering getting some AC to DC powersupplies for the ACX710
because the cost saving is considerable. It is not like finding AC to DC
devices is hard - every laptop comes with one (yea I know too little
voltage).

Our purpose is to replace our MPLS core with new gear that has deep buffers
and better support for traffic engineering etc. These will be P and PE
routers mostly doing L2VPN. We will have a 100G ring topology of ACX710
devices moving MPLS packets and terminating L2VPN.

Seems to be a perfect fit to me. I am not interested in the older ACX
devices which lacks buffers and is probably not much better than the gear
we want to replace.

Regards

Baldur


ons. 29. jul. 2020 16.25 skrev Mark Tinka <mark.tinka at seacom.com>:

>
>
> On 29/Jul/20 15:49, Eric Van Tol wrote:
> > We ran into this, too. We signed up to beta test at the beginning of
> this year and nowhere, not even in discussions with our SE (who also wasn't
> told by Juniper), was it mentioned it was a DC-only device. Imagine my
> surprise when I received the box and it was DC only. Such a disappointment.
>
> The messaging we got from them earlier in the year about trying out
> their new Metro-E box was that we would be happy with it, considering
> that every Metro-E solution they've thrown at us since 2008 has fallen
> flat, splat!
>
> Come game-time, even our own SE was blindsided by this DC-only support
> on the ACX710. Proper show-stopper.
>
> At any rate, the story is that they should be pushing out some new
> ACX7xxx boxes from next year, which should have AC support (to you
> psych. majors: more for the general public, and not the custom-built
> ACX710).
>
> I'm not sure I can be that patient, so I'm sniffing at Nokia's new
> Metro-E product line. The problem is so far, as with Juniper and Cisco,
> they've gone down the Broadcom route (some boxes shipping with Qumran,
> others with Jericho 2, and on-paper, they are already failing some of
> our forwarding requirements.
>
> It's not easy...
>
> Mark.
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

From mark.tinka at seacom.com  Wed Jul 29 17:18:47 2020
From: mark.tinka at seacom.com (Mark Tinka)
Date: Wed, 29 Jul 2020 23:18:47 +0200
Subject: [j-nsp] ACX5448 & ACX710 - Update!
In-Reply-To: <CAPq_dj-iYs5ES2YL3HuiNrmM+2G_0L0_c6oPvCmmP1GzLzKRcg@mail.gmail.com>
References: <223399a3-b0fd-7b07-fe99-9f98ccca62b5@seacom.mu>
 <CACqnVtYEr0f_eCJzbY5_pcZ7KA4Xx4DemDU1jVsP5Fy0GwEUsg@mail.gmail.com>
 <64460d1e-1d2d-d00b-427c-40aac5e6cd4e@seacom.mu>
 <CAAeewD9QTzdG1MSjeNrEaxkO_b0B0xGPo4f65YX=mBKueB6Mhg@mail.gmail.com>
 <21ab8cf5-0318-14b4-a009-ef478d3c40d2@seacom.mu>
 <CAMDdSzOtLD+7rk9+ftyukb1MBk9FooeMV+Y68texmiikZiRpNg@mail.gmail.com>
 <1bc55d32-1035-d9e1-33b0-8a7e0dc31220@seacom.com>
 <7742B083-CFAD-4C35-A81E-1282354B90E7@atlantech.net>
 <20da5077-591f-d344-d6f2-9eb97c996e4a@seacom.com>
 <CAPq_dj-iYs5ES2YL3HuiNrmM+2G_0L0_c6oPvCmmP1GzLzKRcg@mail.gmail.com>
Message-ID: <f2d66d86-e3ff-6eb3-1d7f-78647301e207@seacom.com>



On 29/Jul/20 20:18, Baldur Norddahl wrote:
> I am also going to get a few ACX5448 for our datacentre locations. I am
> still considering getting some AC to DC powersupplies for the ACX710
> because the cost saving is considerable. It is not like finding AC to DC
> devices is hard - every laptop comes with one (yea I know too little
> voltage).

If you are deploying 20, not a major issue.

If you're deploying several-hundred or several-thousands units, this is
not a small issue.

Mark.

From miletotalesgter at gmail.com  Wed Jul 29 18:53:05 2020
From: miletotalesgter at gmail.com (mt)
Date: Wed, 29 Jul 2020 19:53:05 -0300
Subject: [j-nsp] ACX5448 & ACX710 - Update!
In-Reply-To: <f2d66d86-e3ff-6eb3-1d7f-78647301e207@seacom.com>
References: <223399a3-b0fd-7b07-fe99-9f98ccca62b5@seacom.mu>
 <CACqnVtYEr0f_eCJzbY5_pcZ7KA4Xx4DemDU1jVsP5Fy0GwEUsg@mail.gmail.com>
 <64460d1e-1d2d-d00b-427c-40aac5e6cd4e@seacom.mu>
 <CAAeewD9QTzdG1MSjeNrEaxkO_b0B0xGPo4f65YX=mBKueB6Mhg@mail.gmail.com>
 <21ab8cf5-0318-14b4-a009-ef478d3c40d2@seacom.mu>
 <CAMDdSzOtLD+7rk9+ftyukb1MBk9FooeMV+Y68texmiikZiRpNg@mail.gmail.com>
 <1bc55d32-1035-d9e1-33b0-8a7e0dc31220@seacom.com>
 <7742B083-CFAD-4C35-A81E-1282354B90E7@atlantech.net>
 <20da5077-591f-d344-d6f2-9eb97c996e4a@seacom.com>
 <CAPq_dj-iYs5ES2YL3HuiNrmM+2G_0L0_c6oPvCmmP1GzLzKRcg@mail.gmail.com>
 <f2d66d86-e3ff-6eb3-1d7f-78647301e207@seacom.com>
Message-ID: <e082529d-b483-23bc-f57e-1fd2b6d0a312@gmail.com>

Exactly!!!

my SE confirmed that there the ACX710 will be shipped with only DC power 
supply.

I really don't know what the Juniper engineering team are thinking, they 
are forgetting the basic things. They're focusing on a unique customer 
requirement, and for me this is a absurd.

mt

Em 29/07/2020 18:18, Mark Tinka escreveu:
>
> On 29/Jul/20 20:18, Baldur Norddahl wrote:
>> I am also going to get a few ACX5448 for our datacentre locations. I am
>> still considering getting some AC to DC powersupplies for the ACX710
>> because the cost saving is considerable. It is not like finding AC to DC
>> devices is hard - every laptop comes with one (yea I know too little
>> voltage).
> If you are deploying 20, not a major issue.
>
> If you're deploying several-hundred or several-thousands units, this is
> not a small issue.
>
> Mark.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

From shamen.snyder at gmail.com  Wed Jul 29 22:17:39 2020
From: shamen.snyder at gmail.com (Shamen Snyder)
Date: Wed, 29 Jul 2020 22:17:39 -0400
Subject: [j-nsp] ACX5448 & ACX710 - Update!
In-Reply-To: <1bc55d32-1035-d9e1-33b0-8a7e0dc31220@seacom.com>
References: <223399a3-b0fd-7b07-fe99-9f98ccca62b5@seacom.mu>
 <CACqnVtYEr0f_eCJzbY5_pcZ7KA4Xx4DemDU1jVsP5Fy0GwEUsg@mail.gmail.com>
 <64460d1e-1d2d-d00b-427c-40aac5e6cd4e@seacom.mu>
 <CAAeewD9QTzdG1MSjeNrEaxkO_b0B0xGPo4f65YX=mBKueB6Mhg@mail.gmail.com>
 <21ab8cf5-0318-14b4-a009-ef478d3c40d2@seacom.mu>
 <CAMDdSzOtLD+7rk9+ftyukb1MBk9FooeMV+Y68texmiikZiRpNg@mail.gmail.com>
 <1bc55d32-1035-d9e1-33b0-8a7e0dc31220@seacom.com>
Message-ID: <CACqnVtYTZT-z9yBAQYK53C4KvPZU-dqyLkOEm0oNcm9wi+Smdg@mail.gmail.com>

The Juniper Bolan architecture is suppose to have an AC variant.

 Hardened (-40C to 65C), compact (445m x 221mm x 250mm) form factor ?
suitable for cabinets in pre-aggregation network layer
? 2 Routing Engine slots, 1:1 redundant control and forwarding/switching
plane
? 320Gb/s and 2.4 Tb/s RP Variants; Full FIB with 2.4Tb/s RP ? 1.5M FIB
? Flexibility of 7 (DC versions) or 6 (AC versions) line card slots
? 8x1GE/10GE
? 8 x 10/25GE
? 2x40GE/100GE
? 4x40/100GE (C-Temp)

I haven?t been following it much, but may be worth poking your SE on.

On Wed, Jul 29, 2020 at 9:43 AM Mark Tinka <mark.tinka at seacom.com> wrote:

> So an update on this thread...
>
> Juniper went ahead and made the ACX710 a DC-only box. So if you are an
> AC house, you're in deep doo-doo (which is us).
>
> DC, for large scale deployment in the Metro? Makes zero sense to me.
>
> Apparently, no way around this; which, to me, smells of the box being
> built for some larger operator (like mobile), who primarily have DC
> plants. And that's it - no other options for anyone else.
>
> Oh, these vendors...
>
> I haven't yet seen an ACX710 outside of a PDF, but deep scouring on the
> Internet led me to this:
>
>
>
> https://portal.nca.org.gh/search_type_approval_view_details.php?typeApproveDetailID=2244
>
> Some kind of type approval with National Communications Authority of Ghana.
>
> Mark.
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

From shamen.snyder at gmail.com  Wed Jul 29 22:48:57 2020
From: shamen.snyder at gmail.com (Shamen Snyder)
Date: Wed, 29 Jul 2020 22:48:57 -0400
Subject: [j-nsp] ACX5448 & ACX710 - Update!
In-Reply-To: <CAPq_dj-iYs5ES2YL3HuiNrmM+2G_0L0_c6oPvCmmP1GzLzKRcg@mail.gmail.com>
References: <223399a3-b0fd-7b07-fe99-9f98ccca62b5@seacom.mu>
 <CACqnVtYEr0f_eCJzbY5_pcZ7KA4Xx4DemDU1jVsP5Fy0GwEUsg@mail.gmail.com>
 <64460d1e-1d2d-d00b-427c-40aac5e6cd4e@seacom.mu>
 <CAAeewD9QTzdG1MSjeNrEaxkO_b0B0xGPo4f65YX=mBKueB6Mhg@mail.gmail.com>
 <21ab8cf5-0318-14b4-a009-ef478d3c40d2@seacom.mu>
 <CAMDdSzOtLD+7rk9+ftyukb1MBk9FooeMV+Y68texmiikZiRpNg@mail.gmail.com>
 <1bc55d32-1035-d9e1-33b0-8a7e0dc31220@seacom.com>
 <7742B083-CFAD-4C35-A81E-1282354B90E7@atlantech.net>
 <20da5077-591f-d344-d6f2-9eb97c996e4a@seacom.com>
 <CAPq_dj-iYs5ES2YL3HuiNrmM+2G_0L0_c6oPvCmmP1GzLzKRcg@mail.gmail.com>
Message-ID: <CACqnVtbWioUaZF_DOk-c1RO8ce+DELVbD2R29QiUw=FvoKVR5w@mail.gmail.com>

Heads up on the ACX5448. There is a major LDP bug in the recommend code
19.3R2-S3.

LDP hellos are punted to the RE In queue rx-unknown-mc instead of
rxq-l3-nc-hi.

A major shift in multicast on our network dropped LDP neighbors.

The issue doesn?t happen in 20.2R1 if you find it?s stable (I haven?t). I
believe the PR is PR1503469 and should be going into 19.3R3.




On Wed, Jul 29, 2020 at 2:20 PM Baldur Norddahl <baldur at gigabit.dk> wrote:

> I am planning to deploy ACX710 with maybe 20 units (which for us is a huge
> number). We would have ordered DC in any case, so that is a non issue. We
> will have them at CO buildings were DC is what you get and maybe in the
> future in road side cabinets, where DC is the easy way to have some battery
> backup.
>
> I am also going to get a few ACX5448 for our datacentre locations. I am
> still considering getting some AC to DC powersupplies for the ACX710
> because the cost saving is considerable. It is not like finding AC to DC
> devices is hard - every laptop comes with one (yea I know too little
> voltage).
>
> Our purpose is to replace our MPLS core with new gear that has deep buffers
> and better support for traffic engineering etc. These will be P and PE
> routers mostly doing L2VPN. We will have a 100G ring topology of ACX710
> devices moving MPLS packets and terminating L2VPN.
>
> Seems to be a perfect fit to me. I am not interested in the older ACX
> devices which lacks buffers and is probably not much better than the gear
> we want to replace.
>
> Regards
>
> Baldur
>
>
> ons. 29. jul. 2020 16.25 skrev Mark Tinka <mark.tinka at seacom.com>:
>
> >
> >
> > On 29/Jul/20 15:49, Eric Van Tol wrote:
> > > We ran into this, too. We signed up to beta test at the beginning of
> > this year and nowhere, not even in discussions with our SE (who also
> wasn't
> > told by Juniper), was it mentioned it was a DC-only device. Imagine my
> > surprise when I received the box and it was DC only. Such a
> disappointment.
> >
> > The messaging we got from them earlier in the year about trying out
> > their new Metro-E box was that we would be happy with it, considering
> > that every Metro-E solution they've thrown at us since 2008 has fallen
> > flat, splat!
> >
> > Come game-time, even our own SE was blindsided by this DC-only support
> > on the ACX710. Proper show-stopper.
> >
> > At any rate, the story is that they should be pushing out some new
> > ACX7xxx boxes from next year, which should have AC support (to you
> > psych. majors: more for the general public, and not the custom-built
> > ACX710).
> >
> > I'm not sure I can be that patient, so I'm sniffing at Nokia's new
> > Metro-E product line. The problem is so far, as with Juniper and Cisco,
> > they've gone down the Broadcom route (some boxes shipping with Qumran,
> > others with Jericho 2, and on-paper, they are already failing some of
> > our forwarding requirements.
> >
> > It's not easy...
> >
> > Mark.
> >
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

From daniel at shunoshu.net  Thu Jul 30 02:33:52 2020
From: daniel at shunoshu.net (Daniel Verlouw)
Date: Thu, 30 Jul 2020 08:33:52 +0200
Subject: [j-nsp] ACX5448 & ACX710 - Update!
In-Reply-To: <20da5077-591f-d344-d6f2-9eb97c996e4a@seacom.com>
References: <223399a3-b0fd-7b07-fe99-9f98ccca62b5@seacom.mu>
 <CACqnVtYEr0f_eCJzbY5_pcZ7KA4Xx4DemDU1jVsP5Fy0GwEUsg@mail.gmail.com>
 <64460d1e-1d2d-d00b-427c-40aac5e6cd4e@seacom.mu>
 <CAAeewD9QTzdG1MSjeNrEaxkO_b0B0xGPo4f65YX=mBKueB6Mhg@mail.gmail.com>
 <21ab8cf5-0318-14b4-a009-ef478d3c40d2@seacom.mu>
 <CAMDdSzOtLD+7rk9+ftyukb1MBk9FooeMV+Y68texmiikZiRpNg@mail.gmail.com>
 <1bc55d32-1035-d9e1-33b0-8a7e0dc31220@seacom.com>
 <7742B083-CFAD-4C35-A81E-1282354B90E7@atlantech.net>
 <20da5077-591f-d344-d6f2-9eb97c996e4a@seacom.com>
Message-ID: <CAALQXVJ_4-sdCP+HbYHF_AyWF=KsN0y14R9G3UMNnViNALFOWQ@mail.gmail.com>

Hi Mark,

On Wed, Jul 29, 2020 at 4:24 PM Mark Tinka <mark.tinka at seacom.com> wrote:
> I'm not sure I can be that patient, so I'm sniffing at Nokia's new
> Metro-E product line. The problem is so far, as with Juniper and Cisco,
> they've gone down the Broadcom route (some boxes shipping with Qumran,
> others with Jericho 2, and on-paper, they are already failing some of
> our forwarding requirements.

which Nokia platform are you looking at? 7250 IXR is also
Qumran/Jericho, Nokia is just hiding it everywhere they can...

  --Daniel.

From mark.tinka at seacom.com  Thu Jul 30 03:22:34 2020
From: mark.tinka at seacom.com (Mark Tinka)
Date: Thu, 30 Jul 2020 09:22:34 +0200
Subject: [j-nsp] ACX5448 & ACX710 - Update!
In-Reply-To: <e082529d-b483-23bc-f57e-1fd2b6d0a312@gmail.com>
References: <223399a3-b0fd-7b07-fe99-9f98ccca62b5@seacom.mu>
 <CACqnVtYEr0f_eCJzbY5_pcZ7KA4Xx4DemDU1jVsP5Fy0GwEUsg@mail.gmail.com>
 <64460d1e-1d2d-d00b-427c-40aac5e6cd4e@seacom.mu>
 <CAAeewD9QTzdG1MSjeNrEaxkO_b0B0xGPo4f65YX=mBKueB6Mhg@mail.gmail.com>
 <21ab8cf5-0318-14b4-a009-ef478d3c40d2@seacom.mu>
 <CAMDdSzOtLD+7rk9+ftyukb1MBk9FooeMV+Y68texmiikZiRpNg@mail.gmail.com>
 <1bc55d32-1035-d9e1-33b0-8a7e0dc31220@seacom.com>
 <7742B083-CFAD-4C35-A81E-1282354B90E7@atlantech.net>
 <20da5077-591f-d344-d6f2-9eb97c996e4a@seacom.com>
 <CAPq_dj-iYs5ES2YL3HuiNrmM+2G_0L0_c6oPvCmmP1GzLzKRcg@mail.gmail.com>
 <f2d66d86-e3ff-6eb3-1d7f-78647301e207@seacom.com>
 <e082529d-b483-23bc-f57e-1fd2b6d0a312@gmail.com>
Message-ID: <4c58e636-3497-9cc1-dde8-e80da01c333f@seacom.com>



On 30/Jul/20 00:53, mt wrote:
> Exactly!!!
>
> my SE confirmed that there the ACX710 will be shipped with only DC
> power supply.
>
> I really don't know what the Juniper engineering team are thinking,
> they are forgetting the basic things. They're focusing on a unique
> customer requirement, and for me this is a absurd.

They are clearly envying the model of the other vendor right down the
road in San Jose...

Mark.

From mark.tinka at seacom.com  Thu Jul 30 03:23:18 2020
From: mark.tinka at seacom.com (Mark Tinka)
Date: Thu, 30 Jul 2020 09:23:18 +0200
Subject: [j-nsp] ACX5448 & ACX710 - Update!
In-Reply-To: <CACqnVtYTZT-z9yBAQYK53C4KvPZU-dqyLkOEm0oNcm9wi+Smdg@mail.gmail.com>
References: <223399a3-b0fd-7b07-fe99-9f98ccca62b5@seacom.mu>
 <CACqnVtYEr0f_eCJzbY5_pcZ7KA4Xx4DemDU1jVsP5Fy0GwEUsg@mail.gmail.com>
 <64460d1e-1d2d-d00b-427c-40aac5e6cd4e@seacom.mu>
 <CAAeewD9QTzdG1MSjeNrEaxkO_b0B0xGPo4f65YX=mBKueB6Mhg@mail.gmail.com>
 <21ab8cf5-0318-14b4-a009-ef478d3c40d2@seacom.mu>
 <CAMDdSzOtLD+7rk9+ftyukb1MBk9FooeMV+Y68texmiikZiRpNg@mail.gmail.com>
 <1bc55d32-1035-d9e1-33b0-8a7e0dc31220@seacom.com>
 <CACqnVtYTZT-z9yBAQYK53C4KvPZU-dqyLkOEm0oNcm9wi+Smdg@mail.gmail.com>
Message-ID: <1c51149e-aac2-8d0a-fe15-098f80fb9d10@seacom.com>



On 30/Jul/20 04:17, Shamen Snyder wrote:
> The Juniper Bolan architecture is suppose to have an AC variant.
>
> ?Hardened (-40C to 65C), compact (445m x 221mm x 250mm) form factor ?
> suitable for cabinets in pre-aggregation network layer
> ? 2 Routing Engine slots, 1:1 redundant control and
> forwarding/switching plane
> ? 320Gb/s and 2.4 Tb/s RP Variants; Full FIB with 2.4Tb/s RP ? 1.5M FIB
> ? Flexibility of 7 (DC versions) or 6 (AC versions) line card slots
> ? 8x1GE/10GE
> ? 8 x 10/25GE
> ? 2x40GE/100GE
> ? 4x40/100GE (C-Temp)
>
> I haven?t been following it much, but may be worth poking your SE on.

That is too heavy for a Metro-E deployment.

Mark.

From mark.tinka at seacom.com  Thu Jul 30 03:49:21 2020
From: mark.tinka at seacom.com (Mark Tinka)
Date: Thu, 30 Jul 2020 09:49:21 +0200
Subject: [j-nsp] ACX5448 & ACX710 - Update!
In-Reply-To: <CAALQXVJ_4-sdCP+HbYHF_AyWF=KsN0y14R9G3UMNnViNALFOWQ@mail.gmail.com>
References: <223399a3-b0fd-7b07-fe99-9f98ccca62b5@seacom.mu>
 <CACqnVtYEr0f_eCJzbY5_pcZ7KA4Xx4DemDU1jVsP5Fy0GwEUsg@mail.gmail.com>
 <64460d1e-1d2d-d00b-427c-40aac5e6cd4e@seacom.mu>
 <CAAeewD9QTzdG1MSjeNrEaxkO_b0B0xGPo4f65YX=mBKueB6Mhg@mail.gmail.com>
 <21ab8cf5-0318-14b4-a009-ef478d3c40d2@seacom.mu>
 <CAMDdSzOtLD+7rk9+ftyukb1MBk9FooeMV+Y68texmiikZiRpNg@mail.gmail.com>
 <1bc55d32-1035-d9e1-33b0-8a7e0dc31220@seacom.com>
 <7742B083-CFAD-4C35-A81E-1282354B90E7@atlantech.net>
 <20da5077-591f-d344-d6f2-9eb97c996e4a@seacom.com>
 <CAALQXVJ_4-sdCP+HbYHF_AyWF=KsN0y14R9G3UMNnViNALFOWQ@mail.gmail.com>
Message-ID: <025d74b5-c057-4208-9e50-9d5393b42077@seacom.com>



On 30/Jul/20 08:33, Daniel Verlouw wrote:

>
> which Nokia platform are you looking at? 7250 IXR is also
> Qumran/Jericho, Nokia is just hiding it everywhere they can...

All of Nokia's revised Metro-E platforms are Broadcom-based. It appears
to be the gentleman's handshake amongst all the equipment vendors that
Metro-E be cheap & cheerful, so they are all doing Broadcom.

We are looking at all of them:

  * IXR-e = Qumran UX
  * IXR-E = Qumran AX
  * IXR-s = Qumran MX
  * IXR-R4 = Qumran AX
  * IXR-R6 = Qumran MX
  * IXR-Xs = Jericho 2
  * IXR-X1 = Jericho 2

The Qumran units probably won't go anywhere with us. There is better
hope with the Jericho 2 unit, but even then, we are already seeing
fundamental issues on paper.

It's like I've been saying for some time now... if all the vendors are
going to be using the same chip for a platform in the same area of the
network, then the only differentiator is going to be what code customers
like to work with. Within the traditional vendors, I don't think that
matters much because their code is mature and well understood within the
networking community.

What you hear from the traditional vendors is that they "have the best
relationship with Brodacom vis-a-vis how they work with their SDK to
make the chip do what they want better than their competitors". If they
are all saying the same thing in that regard, not sure how true it is.

Ultimately, if you are going to end up with the same hardware issues
across all vendor platforms (unless some vendors decide to do clever but
costly things like recirculation, e.t.c.), what is the real value, then?

Mark.


From baldur at gigabit.dk  Thu Jul 30 04:19:34 2020
From: baldur at gigabit.dk (Baldur Norddahl)
Date: Thu, 30 Jul 2020 10:19:34 +0200
Subject: [j-nsp] ACX5448 & ACX710 - Update!
In-Reply-To: <f2d66d86-e3ff-6eb3-1d7f-78647301e207@seacom.com>
References: <223399a3-b0fd-7b07-fe99-9f98ccca62b5@seacom.mu>
 <CACqnVtYEr0f_eCJzbY5_pcZ7KA4Xx4DemDU1jVsP5Fy0GwEUsg@mail.gmail.com>
 <64460d1e-1d2d-d00b-427c-40aac5e6cd4e@seacom.mu>
 <CAAeewD9QTzdG1MSjeNrEaxkO_b0B0xGPo4f65YX=mBKueB6Mhg@mail.gmail.com>
 <21ab8cf5-0318-14b4-a009-ef478d3c40d2@seacom.mu>
 <CAMDdSzOtLD+7rk9+ftyukb1MBk9FooeMV+Y68texmiikZiRpNg@mail.gmail.com>
 <1bc55d32-1035-d9e1-33b0-8a7e0dc31220@seacom.com>
 <7742B083-CFAD-4C35-A81E-1282354B90E7@atlantech.net>
 <20da5077-591f-d344-d6f2-9eb97c996e4a@seacom.com>
 <CAPq_dj-iYs5ES2YL3HuiNrmM+2G_0L0_c6oPvCmmP1GzLzKRcg@mail.gmail.com>
 <f2d66d86-e3ff-6eb3-1d7f-78647301e207@seacom.com>
Message-ID: <1ab133ec-ede1-9c7a-3d7a-8400e0644978@gigabit.dk>



On 29.07.2020 23.18, Mark Tinka wrote:
> On 29/Jul/20 20:18, Baldur Norddahl wrote:
>> I am also going to get a few ACX5448 for our datacentre locations. I am
>> still considering getting some AC to DC powersupplies for the ACX710
>> because the cost saving is considerable. It is not like finding AC to DC
>> devices is hard - every laptop comes with one (yea I know too little
>> voltage).
> If you are deploying 20, not a major issue.
>
> If you're deploying several-hundred or several-thousands units, this is
> not a small issue.
>

Not going to claim what is or is not a small issue for anyone here. Just 
saying that one rack unit external power supplies are plentiful and 
cheap. Like this one (just the first result on Google):

https://www.simplypowersupply.com/Rack-Mount-Power-Supply/RCP-1000-48-Meanwell-48Vdc-1000W-Rack-Mount-Power-Supply.aspx

We only have two datacentre locations and for those two location I would 
consider getting something like that. But I am probably going to go with 
the ACX5448 anyway because I could find a use for the extra 100G ports.

The 20 locations are at the incumbents CO locations where 48 volt DC 
with battery and sometimes generator backup is what you get. You could 
get 230V AC at these locations but it would be without backup.

In the future I might also get some locations in street cabinets, where 
I would put a standard DC UPS of the kind where you have a couple 12V 
batteries in series to make up the 48 volt, the equipment connected 
directly to the battery bank and a charger continuously charging the 
batteries. This is very cheap and extremely stable. The ACX710 device is 
environmentally hardened and clearly made for exactly that kind of 
deployment.

I see that ACX710 is not as much made for a specific customer as it is 
NOT made for a group of customers: the datacenter customers are supposed 
to buy the more expensive ACX5448. But said datacenter customers can 
spend one rack unit on an external DC powersupply and go with it anyway.

Regards,

Baldur

From mark.tinka at seacom.com  Thu Jul 30 04:29:36 2020
From: mark.tinka at seacom.com (Mark Tinka)
Date: Thu, 30 Jul 2020 10:29:36 +0200
Subject: [j-nsp] ACX5448 & ACX710 - Update!
In-Reply-To: <1ab133ec-ede1-9c7a-3d7a-8400e0644978@gigabit.dk>
References: <223399a3-b0fd-7b07-fe99-9f98ccca62b5@seacom.mu>
 <CACqnVtYEr0f_eCJzbY5_pcZ7KA4Xx4DemDU1jVsP5Fy0GwEUsg@mail.gmail.com>
 <64460d1e-1d2d-d00b-427c-40aac5e6cd4e@seacom.mu>
 <CAAeewD9QTzdG1MSjeNrEaxkO_b0B0xGPo4f65YX=mBKueB6Mhg@mail.gmail.com>
 <21ab8cf5-0318-14b4-a009-ef478d3c40d2@seacom.mu>
 <CAMDdSzOtLD+7rk9+ftyukb1MBk9FooeMV+Y68texmiikZiRpNg@mail.gmail.com>
 <1bc55d32-1035-d9e1-33b0-8a7e0dc31220@seacom.com>
 <7742B083-CFAD-4C35-A81E-1282354B90E7@atlantech.net>
 <20da5077-591f-d344-d6f2-9eb97c996e4a@seacom.com>
 <CAPq_dj-iYs5ES2YL3HuiNrmM+2G_0L0_c6oPvCmmP1GzLzKRcg@mail.gmail.com>
 <f2d66d86-e3ff-6eb3-1d7f-78647301e207@seacom.com>
 <1ab133ec-ede1-9c7a-3d7a-8400e0644978@gigabit.dk>
Message-ID: <ac2e9e48-403b-cd0a-461b-88169f4b4959@seacom.com>



On 30/Jul/20 10:19, Baldur Norddahl wrote:

> Not going to claim what is or is not a small issue for anyone here.
> Just saying that one rack unit external power supplies are plentiful
> and cheap. Like this one (just the first result on Google):
>
> https://www.simplypowersupply.com/Rack-Mount-Power-Supply/RCP-1000-48-Meanwell-48Vdc-1000W-Rack-Mount-Power-Supply.aspx
>
>
> We only have two datacentre locations and for those two location I
> would consider getting something like that. But I am probably going to
> go with the ACX5448 anyway because I could find a use for the extra
> 100G ports.
>
> The 20 locations are at the incumbents CO locations where 48 volt DC
> with battery and sometimes generator backup is what you get. You could
> get 230V AC at these locations but it would be without backup.
>
> In the future I might also get some locations in street cabinets,
> where I would put a standard DC UPS of the kind where you have a
> couple 12V batteries in series to make up the 48 volt, the equipment
> connected directly to the battery bank and a charger continuously
> charging the batteries. This is very cheap and extremely stable. The
> ACX710 device is environmentally hardened and clearly made for exactly
> that kind of deployment.

We considered all possible powering options before deciding that the
ACX710 is a show-stopper.

Rectifiers. UPS's. Solar. Solar + batteries. The works.

Over hundreds of sites dealing with thousands of devices, it's not going
to work. We'll spend too much time and money maintaining power, it
doesn't make sense.


>
> I see that ACX710 is not as much made for a specific customer as it is
> NOT made for a group of customers: the datacenter customers are
> supposed to buy the more expensive ACX5448. But said datacenter
> customers can spend one rack unit on an external DC powersupply and go
> with it anyway.

The ACX710 was clearly built for one or two mobile network operators.
There is no doubt about that.

Juniper have been making boxes that support both AC and DC for yonks.
Hardened and regular. What's so special about the ACX710? In 2020?

Mark.

From baldur at gigabit.dk  Thu Jul 30 06:35:57 2020
From: baldur at gigabit.dk (Baldur Norddahl)
Date: Thu, 30 Jul 2020 12:35:57 +0200
Subject: [j-nsp] ACX5448 & ACX710 - Update!
In-Reply-To: <ac2e9e48-403b-cd0a-461b-88169f4b4959@seacom.com>
References: <223399a3-b0fd-7b07-fe99-9f98ccca62b5@seacom.mu>
 <CACqnVtYEr0f_eCJzbY5_pcZ7KA4Xx4DemDU1jVsP5Fy0GwEUsg@mail.gmail.com>
 <64460d1e-1d2d-d00b-427c-40aac5e6cd4e@seacom.mu>
 <CAAeewD9QTzdG1MSjeNrEaxkO_b0B0xGPo4f65YX=mBKueB6Mhg@mail.gmail.com>
 <21ab8cf5-0318-14b4-a009-ef478d3c40d2@seacom.mu>
 <CAMDdSzOtLD+7rk9+ftyukb1MBk9FooeMV+Y68texmiikZiRpNg@mail.gmail.com>
 <1bc55d32-1035-d9e1-33b0-8a7e0dc31220@seacom.com>
 <7742B083-CFAD-4C35-A81E-1282354B90E7@atlantech.net>
 <20da5077-591f-d344-d6f2-9eb97c996e4a@seacom.com>
 <CAPq_dj-iYs5ES2YL3HuiNrmM+2G_0L0_c6oPvCmmP1GzLzKRcg@mail.gmail.com>
 <f2d66d86-e3ff-6eb3-1d7f-78647301e207@seacom.com>
 <1ab133ec-ede1-9c7a-3d7a-8400e0644978@gigabit.dk>
 <ac2e9e48-403b-cd0a-461b-88169f4b4959@seacom.com>
Message-ID: <01359472-22c6-d52c-9e90-f2d37977bf1a@gigabit.dk>



On 30.07.2020 10.29, Mark Tinka wrote:
> The ACX710 was clearly built for one or two mobile network operators.
> There is no doubt about that.
>
> Juniper have been making boxes that support both AC and DC for yonks.
> Hardened and regular. What's so special about the ACX710? In 2020?
>

To be fair there are more than two Juniper customers world wide that are 
using 48V DC. To my knowledge DC power is very common in the telco world.

What is special about ACX710 is probably the price point. They want a 
device for a certain market without loosing the ability to sell a higher 
priced device for another market.

Regards,

Baldur


From luis at luisbalbinot.com  Thu Jul 30 06:53:38 2020
From: luis at luisbalbinot.com (Luis Balbinot)
Date: Thu, 30 Jul 2020 07:53:38 -0300
Subject: [j-nsp] ACX5448 & ACX710 - Update!
In-Reply-To: <01359472-22c6-d52c-9e90-f2d37977bf1a@gigabit.dk>
References: <223399a3-b0fd-7b07-fe99-9f98ccca62b5@seacom.mu>
 <CACqnVtYEr0f_eCJzbY5_pcZ7KA4Xx4DemDU1jVsP5Fy0GwEUsg@mail.gmail.com>
 <64460d1e-1d2d-d00b-427c-40aac5e6cd4e@seacom.mu>
 <CAAeewD9QTzdG1MSjeNrEaxkO_b0B0xGPo4f65YX=mBKueB6Mhg@mail.gmail.com>
 <21ab8cf5-0318-14b4-a009-ef478d3c40d2@seacom.mu>
 <CAMDdSzOtLD+7rk9+ftyukb1MBk9FooeMV+Y68texmiikZiRpNg@mail.gmail.com>
 <1bc55d32-1035-d9e1-33b0-8a7e0dc31220@seacom.com>
 <7742B083-CFAD-4C35-A81E-1282354B90E7@atlantech.net>
 <20da5077-591f-d344-d6f2-9eb97c996e4a@seacom.com>
 <CAPq_dj-iYs5ES2YL3HuiNrmM+2G_0L0_c6oPvCmmP1GzLzKRcg@mail.gmail.com>
 <f2d66d86-e3ff-6eb3-1d7f-78647301e207@seacom.com>
 <1ab133ec-ede1-9c7a-3d7a-8400e0644978@gigabit.dk>
 <ac2e9e48-403b-cd0a-461b-88169f4b4959@seacom.com>
 <01359472-22c6-d52c-9e90-f2d37977bf1a@gigabit.dk>
Message-ID: <CAFsaiiPxC+80JuA-25Q3hApQD+KEJnKUBK1_neU5G269_2-GGQ@mail.gmail.com>

I work with telecom companies for years and DC is the standard for pretty
much all of them. If you have a small shelter or container you can deploy
an UPS DC system with a handful of batteries that will last for hours and
will not take much space. Look inside a mobile node B station and you?ll
only find DC power.

All major IDCs will provide you -48VDC too.

And to save a bit of money on power efficiency during the years.

Luis

On Thu, 30 Jul 2020 at 07:38 Baldur Norddahl <baldur at gigabit.dk> wrote:

>
>
> On 30.07.2020 10.29, Mark Tinka wrote:
> > The ACX710 was clearly built for one or two mobile network operators.
> > There is no doubt about that.
> >
> > Juniper have been making boxes that support both AC and DC for yonks.
> > Hardened and regular. What's so special about the ACX710? In 2020?
> >
>
> To be fair there are more than two Juniper customers world wide that are
> using 48V DC. To my knowledge DC power is very common in the telco world.
>
> What is special about ACX710 is probably the price point. They want a
> device for a certain market without loosing the ability to sell a higher
> priced device for another market.
>
> Regards,
>
> Baldur
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

From mark.tinka at seacom.com  Thu Jul 30 09:05:35 2020
From: mark.tinka at seacom.com (Mark Tinka)
Date: Thu, 30 Jul 2020 15:05:35 +0200
Subject: [j-nsp] ACX5448 & ACX710 - Update!
In-Reply-To: <01359472-22c6-d52c-9e90-f2d37977bf1a@gigabit.dk>
References: <223399a3-b0fd-7b07-fe99-9f98ccca62b5@seacom.mu>
 <CACqnVtYEr0f_eCJzbY5_pcZ7KA4Xx4DemDU1jVsP5Fy0GwEUsg@mail.gmail.com>
 <64460d1e-1d2d-d00b-427c-40aac5e6cd4e@seacom.mu>
 <CAAeewD9QTzdG1MSjeNrEaxkO_b0B0xGPo4f65YX=mBKueB6Mhg@mail.gmail.com>
 <21ab8cf5-0318-14b4-a009-ef478d3c40d2@seacom.mu>
 <CAMDdSzOtLD+7rk9+ftyukb1MBk9FooeMV+Y68texmiikZiRpNg@mail.gmail.com>
 <1bc55d32-1035-d9e1-33b0-8a7e0dc31220@seacom.com>
 <7742B083-CFAD-4C35-A81E-1282354B90E7@atlantech.net>
 <20da5077-591f-d344-d6f2-9eb97c996e4a@seacom.com>
 <CAPq_dj-iYs5ES2YL3HuiNrmM+2G_0L0_c6oPvCmmP1GzLzKRcg@mail.gmail.com>
 <f2d66d86-e3ff-6eb3-1d7f-78647301e207@seacom.com>
 <1ab133ec-ede1-9c7a-3d7a-8400e0644978@gigabit.dk>
 <ac2e9e48-403b-cd0a-461b-88169f4b4959@seacom.com>
 <01359472-22c6-d52c-9e90-f2d37977bf1a@gigabit.dk>
Message-ID: <84398a97-3a8b-55a2-980a-41f0f936ec3b@seacom.com>



On 30/Jul/20 12:35, Baldur Norddahl wrote:

> To be fair there are more than two Juniper customers world wide that
> are using 48V DC. To my knowledge DC power is very common in the telco
> world.

DC is common, agreed. I just tend to avoid it.

During my Malaysia days, I found the company running kit on DC. When we
did the revamp of the network, we moved all of that to AC. Saved plenty
of space, simplified wiring and troubleshooting, and we were more native
with the data centres we housed in.

Same thing happened when I moved down to South Africa. Everything was on
DC, including the servers. Moved all that to AC, much to the delight of
our Facilities manager. Adding a UPS to support AC backup vs. adding
batteries and rectifiers, was good news.

More and more carrier-neutral data centres are now preferring AC. They
still do offer DC, but it's a whole thing that can cost extra depending
on where you are. I suppose it makes sense given that the cloud bags
need space, and they don't generally run their servers on DC.

There are some carrier-neutral DC's that don't offer any DC at all. All
they'll give you is footprint to deploy your own rectifier.


>
> What is special about ACX710 is probably the price point. They want a
> device for a certain market without loosing the ability to sell a
> higher priced device for another market.

I actually found out the reason why the ACX710 exists the way it does.
It's not what any of us think it is.

Suffice it to say, this box was built for mobile operators. 5G and what-not.

Mark.


From mark.tinka at seacom.com  Thu Jul 30 09:07:52 2020
From: mark.tinka at seacom.com (Mark Tinka)
Date: Thu, 30 Jul 2020 15:07:52 +0200
Subject: [j-nsp] ACX5448 & ACX710 - Update!
In-Reply-To: <CAFsaiiPxC+80JuA-25Q3hApQD+KEJnKUBK1_neU5G269_2-GGQ@mail.gmail.com>
References: <223399a3-b0fd-7b07-fe99-9f98ccca62b5@seacom.mu>
 <CACqnVtYEr0f_eCJzbY5_pcZ7KA4Xx4DemDU1jVsP5Fy0GwEUsg@mail.gmail.com>
 <64460d1e-1d2d-d00b-427c-40aac5e6cd4e@seacom.mu>
 <CAAeewD9QTzdG1MSjeNrEaxkO_b0B0xGPo4f65YX=mBKueB6Mhg@mail.gmail.com>
 <21ab8cf5-0318-14b4-a009-ef478d3c40d2@seacom.mu>
 <CAMDdSzOtLD+7rk9+ftyukb1MBk9FooeMV+Y68texmiikZiRpNg@mail.gmail.com>
 <1bc55d32-1035-d9e1-33b0-8a7e0dc31220@seacom.com>
 <7742B083-CFAD-4C35-A81E-1282354B90E7@atlantech.net>
 <20da5077-591f-d344-d6f2-9eb97c996e4a@seacom.com>
 <CAPq_dj-iYs5ES2YL3HuiNrmM+2G_0L0_c6oPvCmmP1GzLzKRcg@mail.gmail.com>
 <f2d66d86-e3ff-6eb3-1d7f-78647301e207@seacom.com>
 <1ab133ec-ede1-9c7a-3d7a-8400e0644978@gigabit.dk>
 <ac2e9e48-403b-cd0a-461b-88169f4b4959@seacom.com>
 <01359472-22c6-d52c-9e90-f2d37977bf1a@gigabit.dk>
 <CAFsaiiPxC+80JuA-25Q3hApQD+KEJnKUBK1_neU5G269_2-GGQ@mail.gmail.com>
Message-ID: <02e0bbf7-427e-2c1a-1876-9796bb646640@seacom.com>



On 30/Jul/20 12:53, Luis Balbinot wrote:
> I work with telecom companies for years and DC is the standard for pretty
> much all of them. If you have a small shelter or container you can deploy
> an UPS DC system with a handful of batteries that will last for hours and
> will not take much space. Look inside a mobile node B station and you?ll
> only find DC power.
>
> All major IDCs will provide you -48VDC too.
>
> And to save a bit of money on power efficiency during the years.

We run cable landing stations across Africa, so yes, we do use DC for
those as well. Very familiar with the use-case.

We just find AC simpler and easier to work with at 3rd party data
centres as well as Metro commercial buildings, for routers, switches,
servers and such appliances. Dropping a UPS at those sites is far
simpler than deploying DC.

Mobile networks use DC heavily, this is well-known. Which is why I said,
this box was made for them.

Mark.