[c-nsp] The Family of ASR902 - ASR903 - ASR907
James Jun
james at towardex.com
Tue Oct 27 18:22:28 EDT 2015
>
> 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.
Best,
james
More information about the cisco-nsp
mailing list