http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-policing/19645-policevsshape.html

Release Notes for the Cisco ASR 900 Router

http://www.cisco.com/c/en/us/td/docs/routers/asr903/release/notes/asr903_3S_rel_notes.html

http://www.cisco.com/c/en/us/products/collateral/routers/asr-903-series-aggregation-services-routers/data_sheet_c78-715296.html

---

“Cisco IOS XE on Cisco ASR 920 Series Router (ASR-920-24SZ-IM) supports upgradeable firmware for field programmable hardware devices such as interface modules (IMs) and upgrades IM FPGA when ever there is an upgrade.”

http://www.cisco.com/c/en/us/td/docs/routers/asr920/hardware/chassis/guide/ASR920-Chassis-SW/SW_Install_Upgrade.html

 

ASR920 FPGA version support is explained a little more here; http://www.cisco.com/c/en/us/td/docs/routers/asr920/release/notes/ASR920_rel_notes/intro.html

---

show facility-alarm status

System Totals  Critical: 0  Major: 0  Minor: 0

---

 

> It seems quite scalable and seems to have a nice path to higher

> density ethernet with the RSP3 supporting (8) 10 gig, (2) 40 gig and

> (1) 100 gig

 

Yea, the 10G port density is pretty awesome with RSP3.  100Gig IMA requires CPAK though.

 

>

> What do y’all know about this 902,903,907 ?   I want it for my

> distribution/aggregation of L2 and L3, vpls (manual and bgp ad), vpnv4

> and future vpnv6.

 

Right now, we roll 903, 902 and 920s for simple L2 Metro-E backhaul, nothing fancy and it works really well for us.  We also use it for VPLS and no problem there either.

 

The only caveat we ran into is lack of hash options for LACP/port-channels.  Not really easy to load-balance if a subscriber has LACP’d bundle into one of these.  There is no support for 5-tuple hash, nor MPLS label hash like on Cat65/68k Sup2T or ASR 9k series on bundles; you only get src-dst IP/mac.

 

 

Lastly, (it’s not really ASR 90x problem) it uses IOS XE, which means if you are running 6PE and have ASR 90x in the label switching path, it will reply to IPv6 traceroute with FFFF::ipv4, instead of using IPv6 address you have configured in the transiting interfaces on the box.  We typically configure IPv6 interface on core interfaces, even if we’re running 6PE and have no IPv6 routing protocols in the core.

On IOS XR, NXOS and JUNOS, P routers in the path will always pick the configured interface IPv6 address to respond to v6 traceroute; IOS XE and Classic will always pick FFFF::ipv4 and it’s quite annoying as it breaks traceroute on several operating systems (i.e. FreeBSD) that conform to RFC which does not permit FFFF:: from the wire.

Cisco switches don’t just look at the last x bits, they use a proprietary algorithm to do the hashing. I don’t have the liberty to provide details, however I can confirm that it’s an actual algorithm and not just “last x bits”. The following document confirms too:

http://www.cisco.com/c/en/us/support/docs/lan-switching/etherchannel/12023-4.html

L2TPv3 works fairly well (better than I expected). I did some lab testing on it last year before deploying it for a customer where I had no other choice. I’d always pushed it to the side in favour of MPLS pseudowires and prior to last year I had only used it where I had to and the requirement was minimal (minimal traffic volume).

 

Last year I had a customer than needed multiple 100Mbps L2 links for backing up data using a layer 2 application/service. Any typical Cisco

ISRG2 like will process L2TPv3 in hardware so I dropped some 1941’s in and it “just worked”. They max out their 100Mbps fibres ever night with L2TPv3 tunnels between sites.

 

If you use port based L2TPv3 tunnels on the built in interfaces they do support the forwarding of layer 2 control frames too, so spanning-tree, CDP, LAG/LACP, UDLD etc also work. I’m now about to deliver this again possibly with 2921s for higher throughput for another customer and this customer will be runing STP or LACP, we’ve tested both in the lab and the different failure scenarios and it all “just works”. They can just add additional VLANs on their switch trunks facing the 2921s and extend extra VLANs between sites without input from me, port based if ignorant and just transport whatever it recieves.

 

My only gripe is no layer 2 QoS.

http://null.53bits.co.uk/index.php?page=mst-refresh

 

http://null.53bits.co.uk/index.php?page=l2tpv3-port-based-xconnect

 

http://null.53bits.co.uk/index.php?page=l2tpv3-rpw

 

I did some testing with bridges too when spanning tree is present, as I don’t normally use them in such a scenario. You may need to use bridges in a scenario where you are extending layer 2 through something like an ISR-G2, IRB does interfere so it’s no advised:

http://null.53bits.co.uk/index.php?page=l2-bridging

 

Cheers,

James.

Cheers,

James.

It was changed in 12.2(33)SXH – when the PFC hits exception on TCAM, it’ll switch “exception” packets (packets to destination that’s outside of known TCAM programmed entries) with a mls hardware-limiter set to 10kpps

Related to TCAM reallocation, make sure the SP bootvar’s config register matches the RP bootvar’s config register. In tech-speak, ‘sh bootv | i eg’ should match ‘rem com sw sh bootv | i eg’.

If it doesn’t, “conf t; config-register 0x2142; end; conf t; config-register 0x2102; end; copy run start” and recheck. A mismatch in how the SP pre-configures itself is immaterial for the basics of IOS configuration stuff, but fatal with respect to TCAM; the box will forcibly reload after 5 minutes endlessly until fixed.

——

>  IPv4                – 768k

>  MPLS                – 16k (default)

>  IPv6 + IP Multicast – 64k

 

Aim for 64k IPv6 routes (2 byte boundary)