[c-nsp] ASR920 Opinions

[Spyros Kakaroukas]

Hello,

We've also been doing something similar for about a year now, and we're pretty happy with it. We're only installing defaults ( pointing towards large boxes that do install the full table ) , prefixes originated inside our own AS ( could probably divide those to multiple hierarchies, but they're not that many at the moment ) and eBGP customer prefixes.

As for the boxes themselves, we're using ISIS/LDP/RSVP/6PE/BFD/MP-BGP with BGP-SD/EoMPLS/L2PT. Running the 3.16S tree, no major issues so far.

My thoughts and words are my own.

Spyros

________________________________________
From: cisco-nsp <cisco-nsp-bounces at puck.nether.net> on behalf of Erik Sundberg <ESundberg at nitelusa.com>
Sent: Friday, December 22, 2017 1:47 AM
To: James Bensley; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASR920 Opinions

I found a good example of BGP-SD

https://www.cisco.com/c/dam/en/us/products/collateral/routers/asr-920-series-aggregation-services-router/asr920-full-internet-routing-capability.pdf



-----Original Message-----
From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of James Bensley
Sent: Thursday, December 21, 2017 5:02 PM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASR920 Opinions

Hi Jason,

I would second what everyone else has already said; we're using version 3.16.something (can't remember off the top of my head) on probably a couple of hundred ASR920s; usually edge PE services:
L3 VPNs (IPv4, 6PE)
L2 VPNs (mostly pseudowires, just a tiny bit of VPLS on these, we avoid VPLS if possible but it does work) BGP OSPF LDP FRR/LFA/rLFA Per-VRF label mode as you mentioned

The only problem we have with them is the tiny FIB size, 20K IPv4 routes off the top of my head. If you're "unlucky" and PoP a site with a few large customers with lots of routes in their relevant customer VRFs you'll blow the TCAM long before you run out of ports of bandwidth.

As was mentioned below for full table Internet...

On 21 December 2017 at 17:17, Mark Tinka <mark.tinka at seacom.mu> wrote:
>
>
> On 20/Dec/17 00:36, Erik Sundberg wrote:
>
>>
>> One down side is the 20K IPv4/IPv6 Route limit. So no full routes and we also place a RT Filter on our VPNv4 sessions back to the core.
>
> BGP-SD is your friend.
>
> We hold a full IPv4/IPv6 table on each of them in RAM, which a handful
> of useful routes in FIB. Works great!
>
> It means we can offer our customers a native eBGP session with a full
> BGP table from the ASR920, i.e., no need for an eBGP Multi-Hop session
> into the "clever" core.

However no Internet in a VRF here (yet!) and BGP-SD only works on the global routing table for the ME3600X/ME3800X, so I assume it's the same for the ASR920, meaning when we reach Internet-in-a-VRF deployment coverage == 100% we'll be stuffed.

But the full Internet table isn't really a problem for us, as others have mentioned you can pseudowire a customer back somewhere or run multi-hop BGP etc, but with only 20K FIB entries in TCAM we run out of TCAM just from a few large customer VRFs, which is frustrating. We run some of our MEs with the IP SDM profile which gives them 4K more IPv4 entries in TCAM (24K total), which is more than the ASR920s. That could be one more medium sized customer or several smaller ones, extra that we could fit on the device (in terms of the number of routes that customer has).

Overall a good stable MPLS-to-the-access layer box, but the TCAM limits make it more suited for layer 2 agg then layer 3 agg.

Someone mentioned the micro-burst thing and using "queue-limit percent 100" command; that command eventually hit the ME3600X/ME3800X's so we rolled that into our default templates back then because we had 10G back-haul links to the devices with 1G access facing circuits. When the ASR920 dropped we were hot on it with putting that command doing into our default ASR920 templates from the start, as we'd been bitten already by micro-burts on the MEs. This issue was fairly serious for us as we often have for example, a DSLAM hanging off of one or more of the 1G ports, customers are trunked up from the DSLAMs with say a 10M EFM circuit, so you've actually got a 10G back-haul then a shaper on the ME or ASR down to 10M for that VLAN on that 1G link, that's actually two more orders of magnitude smaller than 10G > 1G.
"queue-limit percent 100" is a life safer. It's not perfect but works pretty well.

Cheers,
James.
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


This e-mail and any attachment(s) contained within are confidential and are intended only for the use of the individual to whom they are addressed. The information contained in this communication may be privileged, or exempt from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete the communication without retaining any copies. Connecticore SA is not responsible for, nor endorses, any opinion, recommendation, conclusion, solicitation, offer or agreement or any information contained in this communication.