01-29-2014 05:05 PM
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.
02-03-2014 12:16 AM
Dear Satya,
Kindly I have a few questions:
1- When will the RSP-880 be available?
2- Is the CSC-CE VRFand CSC-PE VRF supported on the same chassis/line card?
3- How to troublehsoot hardware drops?
Thanks a lot for your support.
Best regards,
Michel.
02-03-2014 05:18 AM
Michel,
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.
regards
xander
Xander Thuijs CCIE #6775
Principal Engineer
ASR9000, CRS, NCS6000 & IOS-XR
02-03-2014 06:30 AM
Hi Xander,
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?
Thanks,
Michel.
02-03-2014 07:08 AM
Hey Michel,
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.
cheers!
xander
02-05-2014 03:50 AM
Hi Xander,
the setup is as following:
(ISP1_ASBR)----------_____
(ISP2_ASBR)----------_____|----------(CSC_PE_A)----------(INTERNET PE)
|
(ISP3_ASBR)------------------------------(CSC_PE_B)
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.
Best regards,
Michel.
02-05-2014 05:06 AM
that should be possible Michel, the only hmm moment I have is when you mentioned that the customer networks should
not be in the CSC PE... I am not sure how that is going to work then...
Here are some visualizations as to how it would come together:
04-11-2017 12:21 PM
I have a question, what's the equivalence between Mod cards and line cards.
e.g.
if I use 4 x 20 X10 G cards (ASR 9000 20-port 10GE Modular Port Adapter), and 1 8x100G card (ASR 9000 8-port 100GE)
How many 400G Modular Linecard would I need ?
04-11-2017 01:00 PM
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.
To describe:
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 ;)
cheers!
xander
02-03-2014 10:41 AM
Where can I find more information the the RSP-880? What are the majore enhancements and features that it will provide?
Thank you.
02-03-2014 01:20 PM
Hi Tomek,
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.
regards
xander
02-03-2014 03:21 PM
Thanks Xander
02-05-2014 04:08 PM
Hi Satya,
Thank you for this helpful discussion. Could you please explain MC-LAG Switchover types? Appreciate your help on this.
Thank you.
Lisa
02-05-2014 04:55 PM
Hi Lisa,
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.
Brute force
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.
Revertive
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.
Non-revertive
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.
Regards,
--SN
02-06-2014 04:22 AM
I have some nice detail about MC-LAG here too in case you're interested in that topic:
https://supportforums.cisco.com/docs/DOC-34856
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:
https://supportforums.cisco.com/docs/DOC-34114
regards
xander
Xander Thuijs CCIE #6775
Principal Engineer
ASR9000, CRS, NCS6000 & IOS-XR
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide