With Satya Narra and Xander Thuijs
Welcome to the Cisco Support Community. This is an opportunity to learn and ask questions about software installation, SMU installation, ASR9000 architecture, installing satellite (ASR9000 nv), and troubleshooting of the Cisco ASR 9000 Series Aggregation Services Routers with experts Satya Narra and Xander Thuijs.
The Cisco ASR 9000 Series Aggregation Services Routers product family offers a significant added value compared to the prior generations of carrier Ethernet routing offerings. The Cisco ASR 9000 Series is an operationally simple, future-optimized platform using next-generation hardware and software.
Satya Narra is a network consulting engineer and specialist in ASR9000 deployments for service provider networks. He is an expert in many technology areas, including IP routing, MPLS, BGP, OSPF, multicast, system architecture, and network design. Satya has a master of science degree in electrical engineering from Wichita State University, Wichita, KS. He started his career as a customer support engineer in TAC/HTTS supporting some of the biggest networks, including Comcast, Citi, Amazon, JPMorgan, AT&T, Vodofone, and others.
Xander Thuijs is a principal engineer for the Cisco ASR 9000 Series and Cisco IOS-XR product family at Cisco. He is an expert and advisor in many technology areas, including IP routing, WAN, WAN switching, MPLS, multicast, BNG, ISDN, VoIP, Carrier Ethernet, System Architecture, network design and many others. He has more than 20 years of industry experience in carrier Ethernet, carrier routing, and network access technologies. Xander holds a dual CCIE certification (number 6775) in service provider and voice technologies. He has a master of science degree in electrical engineering from Hogeschool van University in Amsterdam.
Remember to use the rating system to let Satya and Xander know if you have received an adequate response.
Satya might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation in Service Providers community, sub-community, XR OS and Platforms discussion forum shortly after the event. This event lasts through February 14, 2014. Visit this forum often to view responses to your questions and the questions of other community members.
1- When will the RSP-880 be available?
This is part of the "Tomahawk" (NP5) delivery which is end of this year.
2- Is the CSC-CE VRFand CSC-PE VRF supported on the same chassis/line card?
Yes there wouldnt be any restrictions
3- How to troublehsoot hardware drops?
there are quite a few good documents on that here on the support forums in this xr and os platform section.
for instance: https://supportforums.cisco.com/docs/DOC-15552 you may like.
Also check and download cisco live presentation 2904 from the CL site from Orlando 2013 that you may like with even more detail and fabric stuff in it.
Xander Thuijs CCIE #6775
ASR9000, CRS, NCS6000 & IOS-XR
Thanks a lot for your reply.
Regarding point 2, just to make one thing clear: what i am looking for is linking two CSC VRFs on the same router (by importing/exporting RTs). Meaning that I have multiple CE sites that need to connect to a central site but over CSC topology. This does not pose a problem i guess when the CE VRF and CENTRAL VRF are on different PE, but I have a situation where the CE VRF will coexist on the PE that holds the CENTRAL VRF.
Is there any limitation to achieve CSC here?
it sounds like you want to import multiple route-targets on the VRF on the CSC-PE side, is that correct?
If so, I dont see any restrictions necessarily.
Although I haven't seen this tested personally, based on the implementation I am not seeig any obstacles either yet.
One question I have though is, howcome the necessity of linking the two vrf's on the PE side, you could do that on the CSC-CE side too, right? then it saves some bw on the PE/CE link in case there is inter vrf traffic.
the setup is as following:
We have multiple ISP (ISP1 and ISP2) clients connected to the asme CSC_PE_A. Each ISP is in a unique VRF. as well on CSC_PE_A we have the INTERNET_PE that is part of the INTERNET VRF.
The setup i am looking for is to allow the loopback of the ISPx PE and INTERNET_PE to be transported over the CSC_PE_X, in order to establish multihop EBGP and advertise the required prefixes between ISP_X_ASBR and INTERNET_PE only.... these prefixes must not be installed in any of the CSC_PE.
A linecard with fixed interfaces is not mix and match. although the Tomahawk linecard family can break out from 100G to 40G (2) or 10G (10) per port, there is not much flexibility beyond that.
a Modular linecard provides for a sort of SIP/SPA model, whereby you have a carrier (the MODx linecard) and a "spa" or MPA to provide the interface types you like/need.
name family NPU's BW/pps
MOD80 typhoon 2 (1 per bay) 60G/npu 45Mpps/Npu
MOD160 typhoon 4 (2 per bay) 60G/npu 45Mpps/Npu
MOD200 tomahawk 1 (shared between both bays) 200G/npu 200Mpps/Npu
MOD400 tomahawk 2 (1 per bay) 200G/npu 200Mpps/Npu
so if you have an 8x100 fixed linecard, that one can produce 800G of traffic.
a mod400 can carry 400G of traffic, so if you load it well with the right MPA's you'd only need 2xMOD400.
(I say load it well here, because if you load one bay with a 2x1G MPA, you may need a few more ;)
I dont have colleteral ready for the new RSP and linecards yet.
The new RSP merely has a faster CPU (of course), and an updated fabric to support the new higher density linecards
(eg 48x10, 6x100G) which are then Tomahawk based (NP5).
The features are mainly driven by the ucode of the NP. and these linecards will have more room for more features and of course faster speeds (in terms of BW and PPS).
I think that by spring/summer this year we should be able to post some stuff out for the new cards with more details as we are still working on a lot of things for the launch later/nearing the end of this year.
The mLACP switchover method can be modified using the following CLI:
RP/0/0/CPU0:IOSXR(config)#interface bundle-ether 1 mlacp switchover type ? brute-force Force switchover by disabling all local member links revertive Revert based on configured priority values RP/0/0/CPU0:ios(config)#interface bundle-ether 1 mlacp switchover type
These options(and the default, when this configuration is not present) are mutually exclusive, and the configuration must match on the bundle on both POA's. They determine the dynamic priority manamgement or brute force mechanism is used, and whether the behaviour is revertive or non-revertive.
Dynamic Priority Management
Switchover is acheved gracefully by modifying the LACP port priorites.
This does not involve any priority changes. When using brute force, the operational priority always matches the configured priority. A Switchover is performed when the bundle goes down on the active POA. A switchover is also performed, If active-minimum-links is not satisfied, it brings down other active links on this bundle to force a switchover completely to other PoA.
You can configure the MC-LAG in Revertive switchover mode. It means, whenever higher priority links are available, it forces an automatic switchover to that PoA.
By default switchover is non-revertive. It means, bundle does not fail back to the original active PoA except when a subsequent failure is encountered. In this mode, POA's do not consider to be primary and secondary, only active or standby. The configured priorities are only used to determine which POA is initally active.
I have some nice detail about MC-LAG here too in case you're interested in that topic:
In addition, with asr9k nvEdge (aka cluster) you can link 2 separate devices as one logical entity, this means
that you dont need MC-LAG but can use an active active bundle with members on each rack/separate device and eliminate the complex technology of MCLAG and its needs. the two racks dont need to be in the physical location.
If you are interested in the cluster concept here is something on that:
Xander Thuijs CCIE #6775
ASR9000, CRS, NCS6000 & IOS-XR