[c-nsp] ASR920 Opinions

[Erik Sundberg]

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/