[c-nsp] ASR920 Opinions

[James Bensley]

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.