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.
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
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
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
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):
>
>
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
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
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,
Hi Mark,
On Wed, Jul 29, 2020 at 4:24 PM Mark Tinka 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
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
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
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
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
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
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
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.
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
On 24/Jan/20 19:24, Colton Conor wrote:
> Mark,
>
> So which box is best to just get customers a simple IP, but has all
> the management and metro-e requirements you need?
Well, anything sold for a Metro-E application nowadays, whether it
supports MPLS or not, will always have some kind of OAM
Mark,
So which box is best to just get customers a simple IP, but has all the
management and metro-e requirements you need?
On Fri, Jan 24, 2020 at 1:53 AM Mark Tinka wrote:
>
>
> On 24/Jan/20 08:49, Saku Ytti wrote:
>
> >
> > When we asked JNPR why Jericho instead of Paradise, as we see
On 24/Jan/20 08:49, Saku Ytti wrote:
>
> When we asked JNPR why Jericho instead of Paradise, as we see these
> chips for the same market, JNPR told that main motivation was OAM
> features which they lack in Paradise but need in metro.
The OAM story came up as well, as being the major
On Thu, 23 Jan 2020 at 22:52, Mark Tinka wrote:
> If I'm honest, what I've noticed with most traditional vendors selling
> Broadcom-based boxes is they are touting "price" as the killer use-case
When we asked JNPR why Jericho instead of Paradise, as we see these
chips for the same market, JNPR
On 23/Jan/20 23:17, quinn snyder wrote:
> That would be something like the NCS540.
> Its not an apples-to-apples comparison — as the 540 runs XR and the usual
> things that come with that. There were some threads about it in [c-nsp] —
> might be something to explore. I feel its a bit
On 23/Jan/20 23:02, Colton Conor wrote:
> What is Cisco's upgrade path from the ASR920 if you need more 10G ports?
NCS540, which for me, is a broken path.
We are pushing for other considerations, but I'm not holding my breath.
Mark.
___
juniper-nsp
> From: Mark Tinka
> Sent: Thursday, January 23, 2020 9:21 AM
>
> On 23/Jan/20 10:55, adamv0...@netconsultings.com wrote:
>
> > But it's gonna be your only choice if you want to do any sensible
> > automation (or Junos).
>
> Over the past 10 years of hearing about all the buzz words, it's very
That would be something like the NCS540.
Its not an apples-to-apples comparison — as the 540 runs XR and the usual
things that come with that. There were some threads about it in [c-nsp] —
might be something to explore. I feel its a bit heavyweight for the metro, but
it gives you
What is Cisco's upgrade path from the ASR920 if you need more 10G ports?
On Thu, Jan 23, 2020 at 2:52 PM Mark Tinka wrote:
>
>
> On 23/Jan/20 16:00, Shamen Snyder wrote:
>
> > I have been following the ACX 710 for a while now. We have a use case
> > in rural markets where we need a dense 10G
On 23/Jan/20 16:00, Shamen Snyder wrote:
> I have been following the ACX 710 for a while now. We have a use case
> in rural markets where we need a dense 10G hardened 1 RU box.
>
> Looks like a promising box, hope the price is right. If not we may
> have to jump to Cisco ASR920s
If I'm
I have been following the ACX 710 for a while now. We have a use case in
rural markets where we need a dense 10G hardened 1 RU box.
Looks like a promising box, hope the price is right. If not we may have to
jump to Cisco ASR920s
4 100/40G (can be channelized to 4x25G or 4x10G) interfaces, 24
I had that conversation the again other day - someone said they were
working on "automation" and when I probed deeper it revealed some (very
useful, albeit not scalable) scripting. 'You keep using that word. I do not
think it means what you think it means' seems to be the gist of most
"automation"
On 23/Jan/20 10:55, adamv0...@netconsultings.com wrote:
> But it's gonna be your only choice if you want to do any sensible automation
> (or Junos).
Over the past 10 years of hearing about all the buzz words, it's very
safe to say that "automation" is whatever it means to you :-).
Mark.
> Mark Tinka
> Sent: Wednesday, January 22, 2020 6:46 PM
>
> 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.
> Mark Tinka
> Sent: Thursday, January 23, 2020 7:01 AM
>
> 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
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
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
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
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
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
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,
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.
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
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
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...
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
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
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
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
___
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
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.
>
> 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
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
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
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 sharin
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
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
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
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
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
for an update again because all these features are so
important to us.
Thanks
Get Outlook for iOS<https://aka.ms/o0ukef>
From: Saku Ytti
Sent: Wednesday, January 22, 2020 3:26:38 AM
To: Giuliano C. Medalha
Cc: jnsp list
Subject: Re: [j-nsp] ACX5448 & ACX7
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
: jnsp list
Subject: Re: [j-nsp] ACX5448 & ACX710
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 cap
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
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.
Never heard of the ACX710, but see it in slide 22 here
Hi all.
My Juniper SE is pressuring me to test the ACX boxes per subject.
These are shipping with Jericoh 2c and Qumran 2c chip sets.
For anyone that has deployed these, are you happy, particularly if you
have previous Trio experience?
As some of you know, I generally shy away from merchant
63 matches
Mail list logo
