Hi Jason, We're running several, primarily as PE's facing external networks, with ISIS, LDP, BGP, VPNv4, IPv6 (not 6VPE) and EoMPLS. So far, no major issues, we're running 03.16.04.S or 03.16.05.S. Core facing interfaces are IP only, not trunks attached to BDI's. My only concern up to this point is the buffer size. The PDF "Handling Microburst on Cisco ASR920" outlines steps to mitigate it but the commands do not work on the versions I'm running. It hasn't been a problem yet, but we'll see.
-- Stephen On 2017-12-19 1:31 PM, Jason Lixfeld wrote: > Hey all, > > With the ME3600 EOL, we’re looking to start deploying ASR920s. These boxes > would run 100% L3 on the core facing sides (at 10 or 20Gbps), and aside from > the odd corner case, 100% L3 on the customer facing side. > > Some of the more major features they’d run would be: > ISIS > LDP > BFD > BGP-VPNv4 > BGP-VPNv6 (6VPE) > BGP Selective Route Download > IPv6* > ACL (ingress and egress)* > Per-VRF label mode > EoMPLS > FAT-PW > VRF aware DHCP Relay w/option 82 stamping (device, port (EFP?), VLAN) > VRF aware DHCP Server > > Corner cases would include BGP signalled VPLS w/BGP-AD, and l2protocol > support for peer/forward/tunnel primarily on CDP and STP-type frames, as > required. > > *ME3600s cannot support simultaneous configuration of egress ACLs and IPv6. > I’ve heard that the ASR920 resources are carved up differently, where this is > no longer a problem. > > My understanding is that the ASR920 behaves more like an ASR1000 than an > ME3600 in terms of how L2 is implemented (ie: no more global vlan table, vlan > database, etc and all EFP/bridge-domain based). Also, I understand that > these boxes have Netflow to some degree, but a cursory look at the > documentation seems to suggest that you need to set the SDM profile to video > (which affects the device scale as it re-configured the TCAM) if you want to > enable Netflow? > > I know this isn't the first time a “what are your experiences with these > boxes like?” thread has made the rounds, but I wanted to throw it out again > to see how much has changed since the last time it circulated. So, while we > wait for some of these guys for the lab, I’m looking for some feedback on > what to expect from these boxes in terms of reliability (hardware and > software), feature limitations/gotchas, a good, reliable code version, and > anything else someone might want to share about these guys, good, bad or > indifferent. > > Thanks again, in advance. > _______________________________________________ > cisco-nsp mailing list cisco-nsp@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
