That is correct. Even though the Cisco ASR 900-series and 920-series routers use IOS-XE, it's the carrier Ethernet flavor of XE. Configuring the service instances and BDI's is not difficult. Those videos are fairly short, and will fill you in on the config.
... View more

The ASR-920 doesn't support subinterfaces. You'll have to build out a service instance in a bridge domain and then use a BVI. I would highly recommend watching this video series for configuring interfaces on the ASR 920. While the purpose of the video series is to configure TDM pseudowires, they do cover configuring service instances and bridge domains with IP addresses as part of the underlay topology. A good aspect of these videos is that they provide best practice guidelines for these configurations. https://www.youtube.com/watch?v=47QUOaPnG64
... View more

Hello Support Crew, I am planning to upgrade a number of our ASR 9006's and 9010's from 5.1.3 to ?.?.?. Recommended version is 32-bit 6.4.2, given that we're running RSP-440-TR's and Typhoon LC's. However, there is a bug, CSCvm79236, which involves route reflectors not reflecting default routes within VRF's. While this bug is open for the 64-bit version, and has a SMU fix, it is not clear regarding the behavior on the 32-bit version. It would be helpful to either see a sample configuration that recreates the bug, or some other more specific information that would provide some guidance on the affected configuration. I have opened an SR, but so far we have not been able to definitively determine if our environment would be affected or not. We do pass default routes from customer VRF's, through our route reflectors, and on to other routers within those VRF's. I have created a lab with two ASR 9006's and one ASR 903, and have not yet been able to recreate the bug symptoms. 3650(cust) -> ASR9006(5.1.3) -> ASR9006(6.4.2(RR)) -> ASR903 Current SR is 687148012. Xander is aware, but appears to be out of pocket this week. Our first SMU request was rejected. Thanks, Phil.
... View more

We're preparing for a similar upgrade from 5.1.3 to 6.4.2 (32-bit). From my perspective, you shouldn't have issues with that RSP plan. In a similar fashion, I was planning on taking two pre-configured RSP's to each site, and would then have the original RSP's on-hand as the backout plan. But, after seeing your post, now realize it could be done with a single pre-configured RSP, and then re-insert the standby for sync'ing, once network is operationally verified. In my MOP, I will be disabling fpd autoupgrade prior to doing any work, and then manually run the upgrade commands as needed. Once all work is complete, I'll add the autoupgrade command back into the config. I'm still working on this in our lab, so it will be interesting to see what input is given from the Cisco team and other network engineers. Also be aware that there is a route reflector issue mentioned as a review for the 6.4.2 code. I verified this issue does exist with TAC, but I need to fully test in our lab in order to know if we'll be affected.
... View more

Thanks Sam. I'm still working through my process in the lab, but it is looking like one reload is going to be the best bet, which puts us at 6.1.4. But, based on the EOS page, even that isn't buying us much in terms of time. The other option my coworker mentioned is to upgrade and pre-configure two RSP's in our lab, and then simply swap them into production chassis's(sp?) during maintenance windows. That would allow us to get to 6.4.2 with effectively a single reload per production chassis. And, we would then have the removed RSP's still on 5.1.3 as a back-out plan, should we have issues. Thanks, Phil.
... View more

We have a group of 9006's and 9010's with RSP-440's and Typhoon LC's running 5.1.3. I was planning to upgrade this group to 6.4.2, based on Aleksandar's discussion: https://community.cisco.com/t5/service-providers-documents/ios-xr-release-strategy-and-deployment-recommendation/ta-p/3165422 But, given the time involved with jumping through 6.1.4 in the lab, I am considering stopping there, and then installing sp9. While this doesn't get us to the latest recommended release, it does get us into 6.x.x. Has anybody else made this jump from 5.1.x to 6.4.2? If so, how did it go, and do you have any recommendations? Is 6.1.4 a recommended place to land, or should it only be seen as a waypoint in the upgrade to 6.4.2? Thanks, Phil.
... View more

How are you confirming that this is not working? For instance, what is the result of "show bgp [vrf xxx] neighbor x.x.x.x advertised-routes" ? Does your ISP require any sort of IRR registration to allow them to receive routes? Do they rely on ARIN IRR's? Or, your ISP is looking for your routes, and not seeing any advertised to them?
... View more

ASR 9010 airflow is front-to-back. Regarding fan operation on the ASR 9010: The chassis contains two fan trays for redundancy (Figure 2-33 ). The fan trays are located one above the other below the card cage and are equipped with handles for easy removal. The chassis has a front-to-rear cooling path (Figure 2-27 ). The inlet is at the bottom front of the chassis, and the exhaust is at the upper rear. Each fan tray has 12 fans arranged in three groups of four fans each. Two fans of each group share a fan controller. The power supplied to the fan controller is 1:3 protected. A single fan failure has no impact on air flow because the other 11 fans will compensate for it. If the fan controller fails, there is a possibility of up to two fans failing; however, the design always has two fans operating in a row (three rows of fans) to compensate for the air speed. From: https://www.cisco.com/c/en/us/td/docs/iosxr/asr9000/hardware-install/overview-reference/b-asr9k-overview-reference-guide.html Overview and Physical Description Cooling System It doesn't address the normal fan speeds, but it does provide some detail on their operation.
... View more

That does look a lot better. Here is the datasheet list for the ASR 9000. The datasheets relative to your hardware will give you the nominal operating temperatures. https://www.cisco.com/c/en/us/products/routers/asr-9000-series-aggregation-services-routers/datasheet-listing.html
... View more

One question is whether this is a new install, or if this chassis has been running for a while with lower fan speeds, and then this is a new issue. If this has been in place with lower fan speeds, then it sounds like a fan tray issue. If this is a new install, and the fans appear to run high, you can check your altitude setting: admin show environment altitude The default is 1800m. The altitude setting adjusts the fan speeds to compensate for air density issues at higher altitudes. It can be adjusted through the "admin" configuration console. It also might be worth reviewing this post on a 9922 that was experiencing high card temperatures: https://community.cisco.com/t5/xr-os-and-platforms/high-card-temperature-on-chassis-asr-9922/td-p/2931257 Have you checked the fan trays for fans not spinning, as Sam suggested?
... View more

I would say that is not possible. Check out this talk from Cisco Live that dives into the 903 and RSP architecture. https://youtu.be/JyE0eLdt5sQ At 23 minutes in, Girish addresses the different RSP's, and you'll see that they handle the backplane in different manners. So, can you have two different RSP's in one chassis? Physically, yes. Will either of them function in that scenario? Maybe one would, but my bet is that the chassis would kick back an error on power-on.
... View more