Re: [j-nsp] ACX5448 & ACX710 - Update!
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 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. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ACX5448 & ACX710 - Update!
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 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 : > > > > > > > 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@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 > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ACX5448 & ACX710 - Update!
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 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@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 - Update!
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@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 - Update!
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@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ACX5448 & ACX710 - Update!
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 : > > > 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@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 - Update!
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@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ACX5448 & ACX710 - Update!
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" 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@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 - Update!
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@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP output queue priorities between RIBs/NLRIs
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. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
