Re: [j-nsp] ACX5448 & ACX710

[Mark Tinka]

On 23/Jan/20 08:38, Saku Ytti wrote:

>
> The new Cisco 8000 series ships with new, thinner variant of IOS-XR
> (it is not same IOS-XR 7 that ASR9k will run). Potentially this
> thinner IOS-XR could find home in Catalyst and ISR. As a customer, I'm
> not sure if that is what I want. I think I may actually just want
> monolithic IOS-XEd with _proper_ commit and BGP-API (so I can
> implement policy language in language of my choice)

I'm with you on this.


> I suspect long term they intend to replace ASR9k with 8k series. But
> GSR is still sold, by the time 8k is replaced, there probably still
> are few ASR9k customers, so overlap will be thing for long long time.

It does make sense to converge a lot of IP/MPLS functionality around a
single box that is versatile enough to support it. Juniper have had wild
success with the MX since 2007, and you see it doing a lot of things in
many areas of the network to a point of making all their other (larger)
platforms almost irrelevant.

If Cisco feel converging a lot of stuff into the 8000 makes sense, I'd
say they should do it. I'm not sure the market still wants too many
boxes doing too many things in an era where operators are struggling to
keep equipment spending at levels where they were 10, 15, 20 years ago.

This is one of the reasons operators with enough in-house coding skill
are seriously looking to build (or already building) their own routers
with DPDK on white boxes + friends, even if those solutions may be
proprietary and used in targeted deployments, e.g., distributed
low-scale edge, e.t.c. Vendors need to wake up and realize they can't be
the only ones not willing to feel the impact of an age where the kids
don't want to pay for data.

Mark.

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

Re: [j-nsp] ACX5448 & ACX710

[Mark Tinka]

On 23/Jan/20 08:38, Saku Ytti wrote:

> The new Cisco 8000 series ships with new, thinner variant of IOS-XR
> (it is not same IOS-XR 7 that ASR9k will run). Potentially this
> thinner IOS-XR could find home in Catalyst and ISR. As a customer, I'm
> not sure if that is what I want. I think I may actually just want
> monolithic IOS-XEd with _proper_ commit and BGP-API (so I can
> implement policy language in language of my choice)

I'm with you on this.


> I suspect long term they intend to replace ASR9k with 8k series. But
> GSR is still sold, by the time 8k is replaced, there probably still
> are few ASR9k customers, so overlap will be thing for long long time.

It does make sense to converge a lot of IP/MPLS functionality around a
single box that is versatile enough to support it. Juniper have had wild
success with the MX since 2007, and you see it doing a lot of things in
many areas of the network to a point of making all their other (larger)
platforms almost irrelevant.

If Cisco feel converging a lot of stuff into the 8000 makes sense, I'd
say they should do it. I'm not sure the market still wants too many
boxes doing too many things in an era where operators are struggling to
keep equipment spending at levels where they were 10, 15, 20 years ago.

This is one of the reasons operators with enough in-house coding skill
are seriously looking to build (or already building) their own routers
with DPDK on white boxes + friends, even if those solutions may be
proprietary and used in targeted deployments, e.g., distributed
low-scale edge, e.t.c. Vendors need to wake up and realize they can't be
the only ones not willing to feel the impact of an age where the kids
don't want to pay for data.

Mark.


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

Re: [j-nsp] ACX5448 & ACX710

[Saku Ytti]

On Wed, 22 Jan 2020 at 20:46, Mark Tinka  wrote:

> Personally, I think IOS XR is too heavy for the Metro.

The new Cisco 8000 series ships with new, thinner variant of IOS-XR
(it is not same IOS-XR 7 that ASR9k will run). Potentially this
thinner IOS-XR could find home in Catalyst and ISR. As a customer, I'm
not sure if that is what I want. I think I may actually just want
monolithic IOS-XEd with _proper_ commit and BGP-API (so I can
implement policy language in language of my choice)

> So the Cisco 8000 is their attempt, I feel, to lure customers that need
> something larger than an MX or ASR9000 in the core or dense edge, but
> are not large enough to justify the PTX or NCS6000. I could be wrong,
> but that's my 1+1.

I suspect long term they intend to replace ASR9k with 8k series. But
GSR is still sold, by the time 8k is replaced, there probably still
are few ASR9k customers, so overlap will be thing for long long time.


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

Re: [j-nsp] rest api - limit ip sources

[Martin Tonusoo]

Hi Aaron,

> Anyone know how to limit ip addresses *in subnet notation* that are able
to communicate with the rest api ?

This does not seem to be possible with "allowed-sources". IPv4 addresses
specified under "allowed-sources" are used in /mfs/var/etc/lighttpd.conf
configuration file in regular expression not match(!~) which does not
support subnet mask. In theory, one could specify the network as regex, but
this is not supported by Junos XML Schema which requires the value of
"allowed-sources" to be ipv4addr(
https://www.juniper.net/documentation/en_US/junos-sdk/10.2/DDLRefGuide/op_type_ip_addresses.html),
i.e the only value "allowed-sources" accepts is an IPv4 address.

Can't you use RE firewall filters?

In addition, at least in Junos 18.2R1.9 the filtering implementation based
on the client IPv4 address is faulty. For example, if one allows following
two addresses:

user> show configuration system services rest control
allowed-sources [ 10.5.5.123 10.5.5.25 ];

user>

.. then this translates to lighttpd conditional configuration below:

root@:/var/home/user # head -4 /mfs/var/etc/lighttpd.conf
server.document-root = "/www/null"
$HTTP["remoteip"] !~ "10.5.5.25|10.5.5.123" {
url.access-deny = ( "" )
}
root@:/var/home/user #

However, this doesn't permit just 10.5.5.123 and 10.5.5.25, but also for
example 10.5.5.250 or 10.5.5.254.


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

[j-nsp] rest api - limit ip sources

[Aaron Gould]

Anyone know how to limit ip addresses *in subnet notation* that are able to
communicate with the rest api ?

 

 

rest api allowed-source - how to use subnet notation

 

 

{master:0}[edit]

agould@eng-lab-5048-2# set system services rest control allowed-sources
"123.123.0.64/26"

^

invalid input at '/26' in ip address '123.123.0.64/26' at '123.123.0.64/26'

 

{master:0}[edit]

agould@eng-lab-5048-2# set system services rest control allowed-sources
[123.123.0.64 /26]

error: invalid ip address or hostname: /26: /26

 

{master:0}[edit]

agould@eng-lab-5048-2# set system services rest control allowed-sources
[123.123.0.64/26]

error: invalid input at '/26' in ip address '123.123.0.64/26':
123.123.0.64/26

 

*** this works, but it's only one IP address, and I need to allow many more.

 

{master:0}[edit]

agould@eng-lab-5048-2# set system services rest control allowed-sources
123.123.0.80

 

{master:0}[edit]

 

 

 

-Aaron

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

Re: [j-nsp] ACX5448 & ACX710

[Mark Tinka]

On 22/Jan/20 20:39, Tim Durack wrote:

> If you can stomach the BU wars, UADP is a nice ASIC - I think the Cat9k has
> legs, but the Enterprise BU is definitely in a parallel universe. I asked
> about porting XR to run on UADP. That didn't really go over well.

Personally, I think IOS XR is too heavy for the Metro.


> I am wary of NCS due to the merchant silicon and general uncertainty - why
> announce the Cisco 8000 with no family loyalty? Looks like a replacement to
> me.

Just like the PTX, Cisco will target-sell the NCS6000 to specific large
carriers, predominantly in the U.S. Those will be specific deals behind
closed doors. They will continue to build the box in small numbers for
those customers, but they'll rely on the "edge" routers for the majority
of their business, just like Juniper do with the MX.

So the Cisco 8000 is their attempt, I feel, to lure customers that need
something larger than an MX or ASR9000 in the core or dense edge, but
are not large enough to justify the PTX or NCS6000. I could be wrong,
but that's my 1+1.

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

Re: [j-nsp] ACX5448 & ACX710

[Tim Durack]

We have a very small deployment of ASR920 running 16.12. Work well for us,
and we do some pretty kinky/exotic stuff: small scale BNG, Internet in VRF,
selective FIB, port-based DHCPv4/v6/PD, IP unnumbered, IPoDWDM...

If you can stomach the BU wars, UADP is a nice ASIC - I think the Cat9k has
legs, but the Enterprise BU is definitely in a parallel universe. I asked
about porting XR to run on UADP. That didn't really go over well.

I am wary of NCS due to the merchant silicon and general uncertainty - why
announce the Cisco 8000 with no family loyalty? Looks like a replacement to
me.

Tim:>

On Wed, Jan 22, 2020 at 1:18 PM Colton Conor  wrote:

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

Re: [j-nsp] ACX5448 & ACX710

[Colton Conor]

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

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

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

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

Re: [j-nsp] ACX5448 & ACX710

[Mark Tinka]

On 22/Jan/20 18:48, Gert Doering wrote:

>
> If you do more than "basic packet switching" the ASR920 is so
> amazingly buggy...  so having an alternative in this space for
> "basic IP/IPv6/MPLS routing for little money" would be certainly
> welcome.

This is what I've been saying since 2009.

Cisco had the ME3600X/3800X, and the only real competitor at the time
was the Brocade CES/CER2000 NetIron.

Juniper missed the mark.

Fast forward to 2020, Cisco have the ASR920 and there is no real
competitor from any vendor that can challenge them, really.

Again, Juniper missed the mark.

One thing Juniper have been certain about telling me - they do not plan
to create a MX204-Lite.

Not. Going. To. Happen.

For them, their Metro-E solution is the ACX - and judging from past
performance, my level of faith is very low. When a vendor tells me that,
"Well, the new Broadcom chip is miles better than the old Broadcom
chip", I get the feeling that in 2030, they will still be using that
very same line.

If Cisco can develop a custom chip for the ASR920 that can be sold for a
decent price and still do the work in the field, Juniper's refusal, to
me, is rooted in their bedrock internal principles... the same ones that
made them famous for, "A single Junos for all our boxes". We know how
well that turned out.

Mark.



signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX5448 & ACX710

[Gert Doering]

Hi,

On Wed, Jan 22, 2020 at 05:41:19PM +0200, Mark Tinka wrote:
> but it doesn't look to me like they will be bother the ASR920 anytime soon.

If you do more than "basic packet switching" the ASR920 is so
amazingly buggy...  so having an alternative in this space for
"basic IP/IPv6/MPLS routing for little money" would be certainly
welcome.

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


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

Re: [j-nsp] ACX5448 & ACX710

[Rob Foehl]

On Wed, 22 Jan 2020, Saku Ytti wrote:


On Wed, 22 Jan 2020 at 11:48, Rob Foehl  wrote:


TE / TE++ and auto-bandwidth


Still broken?  Been hearing excuses about why these don't work on merchant
silicon boxes since the EX3200...


Excuses seems strong word, it implies you know what merchant silicon
EX3200 has and it implies you know it can push two and swap, which it
can't.


autobw never worked on EX3200 and similar vintage because they'd 
periodically dump impossible values into the statistics files and then try 
to do reservations near integer-width limits.  Who implied anything about 
needing more than one label?


-Rob


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

Re: [j-nsp] ACX5448 & ACX710

[Alexandre Guimaraes]

Mark and gents.

Juniper really doesn't care about Metro services, since ACX5048, "The 
Promissed" equipment that was ready to solve our problems regarding port 
density and functions, but... ACX5048 doesn't work as expected as Giuliano 
said(Giuliano is my SE), We brought some ACX5048... in less than a month of 
operation, we remove those box from network, they became a layer2 switch only. 
So Juniper release the new ACX, but the problems still the same.

From my perspective, they don't have time to develop a good software 
and they just release anything for us thinking that someday, they will correct 
the software of the new hardwar, and we will be happy, but they just forget 
that we provide services and we have SLA. I have my personal cents about this 
subject...

MX, maybe, is the most stable hardware/software that they had in this 
moment. But there is no good density of ports, or we had to choose what type of 
ports we had to work on with, I can't accept this, a MPC7E-MRATE working with 
only 4 100Gb ports... (aahhh this is because de backplane bla bla bla bla) 
hardware release with bad development to run against market... to not lose the 
market.

Other problem that I have here, is with QFX5100 platform, using a 
functionality(version 14.1X53-D35.3), that they remove at the newest release 
software, and, they(Juniper) don't had solution for that and, they really don't 
care 

Now I have a big problem in large scale, since I have hundreds of 
QFX5100, can't upgrade due that, and JTAC don't support that old release 
anymore. 

And, I don't want to talk about QFX5120 deception...


This is my cent, and my feelings about.


Att
Alexandre


Em 22/01/2020 12:41, "juniper-nsp em nome de Mark Tinka" 
 escreveu:



On 22/Jan/20 17:17, Eric Van Tol wrote:

> 
> Which is something many of us smaller providers have been begging them 
for YEARS to make. Hopefully it doesn't have restrictions on port 
configurations like the MX204 or weird filtering limitations like the original 
ACX boxes. The ASR920 is popular for a reason - they are rock-solid, offered 
decent port configurations, sensible and reasonably priced licensing, small 
form-factor and features decent enough for an access MPLS device.

And, custom silicon that does, pretty much, what you're used to seeing
on IOS XE boxes.

Juniper, I've realized, are really not interested in the Metro-E space.
I know it's great to think merchant silicon is the answer to get into
that space, but it doesn't look to me like they will be bother the
ASR920 anytime soon.

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

https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp=DwICAg=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=d3qAF5t8mugacLDeGpoAguKDWyMVANad_HfrWBCDH1s=TU6hC3CmliVPupj04_YNYHTF5VVsspISdyOjUEnr2TM=r-fSdwLUay6e6rXEc7nibhLO1FNxOw1U62KPIFpFeF4=


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

Re: [j-nsp] ACX5448 & ACX710

[Mark Tinka]

On 22/Jan/20 17:17, Eric Van Tol wrote:

> 
> Which is something many of us smaller providers have been begging them for 
> YEARS to make. Hopefully it doesn't have restrictions on port configurations 
> like the MX204 or weird filtering limitations like the original ACX boxes. 
> The ASR920 is popular for a reason - they are rock-solid, offered decent port 
> configurations, sensible and reasonably priced licensing, small form-factor 
> and features decent enough for an access MPLS device.

And, custom silicon that does, pretty much, what you're used to seeing
on IOS XE boxes.

Juniper, I've realized, are really not interested in the Metro-E space.
I know it's great to think merchant silicon is the answer to get into
that space, but it doesn't look to me like they will be bother the
ASR920 anytime soon.

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

Re: [j-nsp] ACX5448 & ACX710

[Eric Van Tol]

On 1/22/20, 10:08 AM, "juniper-nsp on behalf of Mark Tinka" 
 wrote:
According to Juniper, it's targeted as an IP/MPLS router for the Metro
and similar applications.

It is meant to compete with Cisco's ASR920 and NCS540 boxes, as Juniper
have no plans to develop a lite version of the MX204.

Which is something many of us smaller providers have been begging them for 
YEARS to make. Hopefully it doesn't have restrictions on port configurations 
like the MX204 or weird filtering limitations like the original ACX boxes. The 
ASR920 is popular for a reason - they are rock-solid, offered decent port 
configurations, sensible and reasonably priced licensing, small form-factor and 
features decent enough for an access MPLS device.

Trying to get more info from my SE, but likely will not be able to share it due 
to NDA, as it's not yet a released product.

-evt

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

Re: [j-nsp] ACX5448 & ACX710

[Mark Tinka]

On 22/Jan/20 16:01, adamv0...@netconsultings.com wrote:

> And no " TE / TE++ and auto-bandwidth"?
>
> -seems like ACX5448 is targeted as a CPE box or a L2 switch, 

According to Juniper, it's targeted as an IP/MPLS router for the Metro
and similar applications.

It is meant to compete with Cisco's ASR920 and NCS540 boxes, as Juniper
have no plans to develop a lite version of the MX204.

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

Re: [j-nsp] ACX5448 & ACX710

[Saku Ytti]

On Wed, 22 Jan 2020 at 16:09, Robert Raszuk  wrote:

> CPE with its datasheet not even mentioning IPSec/DTLS hardware support ...
> LOL what year do we have ?

It is not CPE, it's metrobox. Jericho doesn't do IPsec in year 2020.

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

Re: [j-nsp] ACX5448 & ACX710

[Robert Raszuk]

CPE with its datasheet not even mentioning IPSec/DTLS hardware support ...
LOL what year do we have ?

On Wed, Jan 22, 2020 at 3:01 PM  wrote:

> > Giuliano C. Medalha
> > Sent: Tuesday, January 21, 2020 8:24 PM
> >
> > Hello
> >
> > We did some initial lab teste using 5448 for a client and we have
> checked with
> > JUNIPER.
> >
> > The major problems we found for our client environment:
> >
> > - No support for FAT  (no roadmap);
> > - No support for Entropy Label  (no roadmap);
> > - No support for Output Policer or HQOS for VPLS / L2Circuit (no
> roadmap);
> > - ACX does not support load balance parsing the payload on lag interface
> (no
> > roadmap);
> > - Some problems with arp flooding for the main CPU (initial JUNOS
> releases
> > but I think they have solve it);
> > - IRB on VPLS is not supported;
> > - Not possible to monitor the real-time traffic on sub-interfaces using
> CLI
> > (only with SNMP)
> >
> > It is good to check with them to see if those functions would work ate
> some
> > new releases (some day ...).
> >
> And no " TE / TE++ and auto-bandwidth"?
>
> -seems like ACX5448 is targeted as a CPE box or a L2 switch,
>
> ...unsubscribe
>
> adam
>
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX5448 & ACX710

[Saku Ytti]

On Wed, 22 Jan 2020 at 16:01,  wrote:

> And no " TE / TE++ and auto-bandwidth"?
>
> -seems like ACX5448 is targeted as a CPE box or a L2 switch,

It's metro box but appetite for more. There is no reason why it
wouldn't do TE/autoBW, if you wave bags of money at JNPR, you'll get
it.

> ...unsubscribe

Remember how it took >5years to get EoMPLS on ASR1k? 19.4 was RLS2 for
ACX5448. What is right way to release boxes

- release with the features the customer who buys them wanted
- release after you have feature parity


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

Re: [j-nsp] ACX5448 & ACX710

[adamv0025]

> Giuliano C. Medalha
> Sent: Tuesday, January 21, 2020 8:24 PM
> 
> Hello
> 
> We did some initial lab teste using 5448 for a client and we have checked with
> JUNIPER.
> 
> The major problems we found for our client environment:
> 
> - No support for FAT  (no roadmap);
> - No support for Entropy Label  (no roadmap);
> - No support for Output Policer or HQOS for VPLS / L2Circuit (no roadmap);
> - ACX does not support load balance parsing the payload on lag interface (no
> roadmap);
> - Some problems with arp flooding for the main CPU (initial JUNOS releases
> but I think they have solve it);
> - IRB on VPLS is not supported;
> - Not possible to monitor the real-time traffic on sub-interfaces using CLI
> (only with SNMP)
> 
> It is good to check with them to see if those functions would work ate some
> new releases (some day ...).
> 
And no " TE / TE++ and auto-bandwidth"?

-seems like ACX5448 is targeted as a CPE box or a L2 switch, 

...unsubscribe

adam


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

Re: [j-nsp] ACX5448 & ACX710

[Saku Ytti]

On Wed, 22 Jan 2020 at 11:48, Rob Foehl  wrote:

> TE / TE++ and auto-bandwidth
>
> Still broken?  Been hearing excuses about why these don't work on merchant
> silicon boxes since the EX3200...

Excuses seems strong word, it implies you know what merchant silicon
EX3200 has and it implies you know it can push two and swap, which it
can't.

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

Re: [j-nsp] ACX5448 & ACX710

[Rob Foehl]

On Wed, 22 Jan 2020, Giuliano C. Medalha wrote:


TE / TE++ and auto-bandwidth


Still broken?  Been hearing excuses about why these don't work on merchant 
silicon boxes since the EX3200...


-Rob


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

Re: [j-nsp] ACX5448 & ACX710

[Giuliano C. Medalha]

Thanks a lot

Forgot to put the following on the list:

TE / TE++ and auto-bandwidth

We will ask them the roadmap for these features too.



Get Outlook for iOS

From: juniper-nsp  on behalf of Saku Ytti 

Sent: Wednesday, January 22, 2020 5:49:50 AM
To: Mark Tinka 
Cc: Juniper List 
Subject: Re: [j-nsp] ACX5448 & ACX710

On Wed, 22 Jan 2020 at 10:06, Mark Tinka  wrote:

> > When were you communicated these? They differ significantly from what
> > was communicated to me.
>
> Saku, would you mind sharing what issues you know about these (and others)?

I've not tested nor paid much attention, but the information I have is
that FAT is roadmapped, unsure of the other stuff as much of it is not
relevant to me.

--
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fjuniper-nspdata=02%7C01%7Cgiuliano%40wztech.com.br%7C4e373f01744e438c535208d79f1835b6%7C584787b077bd4312bf8815412b8ae504%7C1%7C0%7C637152798679559514sdata=KyXYR5LrmaEQJ30ILxsvV2wftgd3dG2%2F1I%2Fo1qRZOvc%3Dreserved=0

WZTECH is registered trademark of WZTECH NETWORKS.
Copyright © 2018 WZTECH NETWORKS. All Rights Reserved.

IMPORTANTE:
As informações deste e-mail e o conteúdo dos eventuais documentos anexos são 
confidenciais e para conhecimento exclusivo do destinatário. Se o leitor desta 
mensagem não for o seu destinatário, fica desde já notificado de que não poderá 
divulgar, distribuir ou, sob qualquer forma, dar conhecimento a terceiros das 
informações e do conteúdo dos documentos anexos. Neste caso, favor comunicar 
imediatamente o remetente, respondendo este e-mail ou telefonando ao mesmo, e 
em seguida apague-o.

CONFIDENTIALITY NOTICE:
The information transmitted in this email message and any attachments are 
solely for the intended recipient and may contain confidential or privileged 
information. If you are not the intended recipient, any review, transmission, 
dissemination or other use of this information is prohibited. If you have 
received this communication in error, please notify the sender immediately and 
delete the material from any computer, including any copies.

WZTECH is registered trademark of WZTECH NETWORKS.
Copyright © 2018 WZTECH NETWORKS. All Rights Reserved.

IMPORTANTE:
As informações deste e-mail e o conteúdo dos eventuais documentos anexos são 
confidenciais e para conhecimento exclusivo do destinatário. Se o leitor desta 
mensagem não for o seu destinatário, fica desde já notificado de que não poderá 
divulgar, distribuir ou, sob qualquer forma, dar conhecimento a terceiros das 
informações e do conteúdo dos documentos anexos. Neste caso, favor comunicar 
imediatamente o remetente, respondendo este e-mail ou telefonando ao mesmo, e 
em seguida apague-o.

CONFIDENTIALITY NOTICE:
The information transmitted in this email message and any attachments are 
solely for the intended recipient and may contain confidential or privileged 
information. If you are not the intended recipient, any review, transmission, 
dissemination or other use of this information is prohibited. If you have 
received this communication in error, please notify the sender immediately and 
delete the material from any computer, including any copies.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX5448 & ACX710

[Saku Ytti]

On Wed, 22 Jan 2020 at 10:06, Mark Tinka  wrote:

> > When were you communicated these? They differ significantly from what
> > was communicated to me.
>
> Saku, would you mind sharing what issues you know about these (and others)?

I've not tested nor paid much attention, but the information I have is
that FAT is roadmapped, unsure of the other stuff as much of it is not
relevant to me.

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

Re: [j-nsp] ACX5448 & ACX710

[Mark Tinka]

On 22/Jan/20 10:03, Giuliano C. Medalha wrote:

> Hello
>
> Good morning
>
> We did the tests last year in our lab
>
> The roadmap position for some features must be changed from there.
>
> It is a good think ... to check again with juniper sales rep ... to have a 
> better view about these features and new roadmaps and new dates
>
> We are going to ask for an update again because all these features are so 
> important to us.

Would be most grateful if you can let us know when you hear back from
Juniper on these, Giuliano. Thanks.

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

Re: [j-nsp] ACX5448 & ACX710

[Mark Tinka]

On 22/Jan/20 08:26, Saku Ytti wrote:

>
> When were you communicated these? They differ significantly from what
> was communicated to me.

Saku, would you mind sharing what issues you know about these (and others)?

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

Re: [j-nsp] ACX5448 & ACX710

[Mark Tinka]

On 21/Jan/20 21:58, Luis Balbinot wrote:

> The 5448 and the 5048 are quite different. I have several 5048 in my
> plant and when we questioned Juniper about a replacement with 100G
> interfaces their engineers compared the config template from our 5048s
> and said the 5448 wasn't capable of doing some of the RSVP and RPM
> stuff we were doing on the 5048. This was about 6 months ago.

We are not an RSVP house, but these are things I'd like to know.

Thanks for the feedback.

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

Re: [j-nsp] ACX5448 & ACX710

[Mark Tinka]

On 21/Jan/20 21:44, Aaron Gould wrote:
> I've had an ACX5448 in my lab on loaner for over a year.  I need to refresh
> myself on how well it performed.  I have the little-brother ACX5048,
> probably 50 of them all over my network doing quite well.  Pretty sure those
> are not Trio based.

If memory serves, the ACX5048 is based on the Trident II. So it should
be markedly different from the ACX5448, which is Jericho 2-based.


> Never heard of the ACX710, but see it in slide 22 here ...
> https://senetsy.ru/upload/juniper-summit-2019/5G-ready_Transport_Networks_Ev
> genii_Bugakov_Juniper.pdf
> ACX710 and ACX753.  I'm curious about interfaces and modules and
> capabilities of both of them.

Let me see if I can remember this - the ACX710 should be 24x 1/10Gbps
ports + 2x 100Gbps uplinks (could be double that).

The ACX753 is chassis-based, and built for hardened requirements in the
Metro and RAN.

Both are shipping middle of 2020.

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

Re: [j-nsp] ACX5448 & ACX710

[Giuliano C. Medalha]

Hello

Good morning

We did the tests last year in our lab

The roadmap position for some features must be changed from there.

It is a good think ... to check again with juniper sales rep ... to have a 
better view about these features and new roadmaps and new dates

We are going to ask for an update again because all these features are so 
important to us.

Thanks



Get Outlook for iOS

From: Saku Ytti 
Sent: Wednesday, January 22, 2020 3:26:38 AM
To: Giuliano C. Medalha 
Cc: jnsp list 
Subject: Re: [j-nsp] ACX5448 & ACX710

On Tue, 21 Jan 2020 at 22:24, Giuliano C. Medalha
 wrote:

> - No support for FAT  (no roadmap);
> - No support for Entropy Label  (no roadmap);
> - No support for Output Policer or HQOS for VPLS / L2Circuit (no roadmap);
> - ACX does not support load balance parsing the payload on lag interface (no 
> roadmap);
> - Some problems with arp flooding for the main CPU (initial JUNOS releases 
> but I think they have solve it);
> - IRB on VPLS is not supported;
> - Not possible to monitor the real-time traffic on sub-interfaces using CLI 
> (only with SNMP)

When were you communicated these? They differ significantly from what
was communicated to me.

--
  ++ytti

WZTECH is registered trademark of WZTECH NETWORKS.
Copyright © 2018 WZTECH NETWORKS. All Rights Reserved.

IMPORTANTE:
As informações deste e-mail e o conteúdo dos eventuais documentos anexos são 
confidenciais e para conhecimento exclusivo do destinatário. Se o leitor desta 
mensagem não for o seu destinatário, fica desde já notificado de que não poderá 
divulgar, distribuir ou, sob qualquer forma, dar conhecimento a terceiros das 
informações e do conteúdo dos documentos anexos. Neste caso, favor comunicar 
imediatamente o remetente, respondendo este e-mail ou telefonando ao mesmo, e 
em seguida apague-o.

CONFIDENTIALITY NOTICE:
The information transmitted in this email message and any attachments are 
solely for the intended recipient and may contain confidential or privileged 
information. If you are not the intended recipient, any review, transmission, 
dissemination or other use of this information is prohibited. If you have 
received this communication in error, please notify the sender immediately and 
delete the material from any computer, including any copies.

WZTECH is registered trademark of WZTECH NETWORKS.
Copyright © 2018 WZTECH NETWORKS. All Rights Reserved.

IMPORTANTE:
As informações deste e-mail e o conteúdo dos eventuais documentos anexos são 
confidenciais e para conhecimento exclusivo do destinatário. Se o leitor desta 
mensagem não for o seu destinatário, fica desde já notificado de que não poderá 
divulgar, distribuir ou, sob qualquer forma, dar conhecimento a terceiros das 
informações e do conteúdo dos documentos anexos. Neste caso, favor comunicar 
imediatamente o remetente, respondendo este e-mail ou telefonando ao mesmo, e 
em seguida apague-o.

CONFIDENTIALITY NOTICE:
The information transmitted in this email message and any attachments are 
solely for the intended recipient and may contain confidential or privileged 
information. If you are not the intended recipient, any review, transmission, 
dissemination or other use of this information is prohibited. If you have 
received this communication in error, please notify the sender immediately and 
delete the material from any computer, including any copies.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp