[c-nsp] ASR920 Opinions

[Tim Durack]

We use ASR920-24 for a very small FTTX broadband deployment. We do Internet
in a VRF and use table filter "selective download" to install default only
in FIB. (This is belt-and-braces as we only send/receive default, but I
like the functionality.)

We also use the IOS-XE DHCP/DHCPv6 server. Works well enough for our needs.

I do wish the ASR920 flavor of ISO-XE supported port based DHCP address
allocation, as this along with ip unnumbered helps with IPv4 address
conservation. (BU isn't interested.)

If you can live with the Enterprise BU, Cat 3650/3850/9348 will give you 48
ports routed with full OSPF/MPLS/BGP/L3VPN...

Tim:>

On Thu, Dec 21, 2017 at 6:03 PM James Bensley <jwbensley at gmail.com> wrote:

> 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/
>