Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread 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

Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread 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

Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread 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

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

2020-01-22 Thread 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

[j-nsp] rest api - limit ip sources

2020-01-22 Thread 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"

Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread 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

Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread 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

Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread 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,

Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread 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.

Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread 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

Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread 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

Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread 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...

Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread 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

Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread 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

Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread 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

Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread 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 ___

Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread 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

Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread 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. >

Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread 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

Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread 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

Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread 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

Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread 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

Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread 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

Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread 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

Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread 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

Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread 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

Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread 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

Re: [j-nsp] ACX5448 & ACX710

2020-01-22 Thread 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