How’s everything going?
One of the coolest things about the routing plane there could be in IOS XR/ASR9K routers would be have dual/redundant independent RSPs. Could you tell me if there is any prospect of having the feature of the Full ISSU (zero-packet and zero-topology loss) on IOS XR? What is the real difficulty and the effort required to make it happen? We can have some hope? :-)
I think que routers are constantly making decisions, running algorithms, and updating the routing/ted database for the correct way for traffic to get to every destination possible. They do this to always have the quickest/most efficient route to the packet’s destination. The hardware responsible for this decision-making would be the RSPs? The paper of RSPs take the decisions based on every possible attribute of the route, then forward it’s choice for the best route to the forwarding plane in the router that actually do the work. The forwarding plane would be redundant (hence the need to make decisions on multiple routes for the same destination). The reason for this is maybe obvious. You don’t want traffic to stop in case of a hardware failure. The same goes for the routing plane. You don’t want to stop making routing decisions if your RSPs dies on you. You want to fail over to a redundant RSPs. There are a couple of ways to gracefully upgrade IOS XR on a ASR9K platform with redundant RSPs, but not with Full ISSU. Full XR ISSU would be typically the slowest and when it works, you never lose a packet. However, when and if fails, it fails miserably and typically involves consoling into the RSPs for some sort of disaster recovery. Owning Full ISSU could be great for ASR9K / IOS XR, agree?
It was nice to talk you again. Take care
All the best,
I'll let Xander answer this more thoroughly as he has been spearheading this and has some additional insights I may not.
In a nutshell this is one of the things we hear about very often, and we are listening, and we will have some good news for everyone with 5.3.1 next year (Xander correct me if I'm wrong).
As for challenges to ISSU I could talk about that at great length. ISSU is anything but easy, it relies on every process and feature to perfectly (perfect might not be the right word, but close to it) go from V1 to V2.
As well a lot of enhancements have been and are coming in the latest releases for regular upgrades to reduce downtime to easily <15 minutes. Just a year or two ago this was 20 or 30 minutes. And considering our code base is always growing I consider this a great achievement.
How’ve you been?
Thank you for all that detail and thanks for all your help, are very good news, I think there Full ISSU with true ISSU capabilities and improve time to reload, the system will greatly facilitate the lives of its users, it really is great news.
All the best,
What I know, this good news are related to NV cluster only, not standalone setups, but xander may elaborate on that in more detail...While I understand the argumentation that there are very complex hurdles in implementing ISSU, NX-OS does it quite well since many years, so the argumentation line is finite IMHO.
Perhaps the difficulty of BU is not directly linked to the difference where the IOS XR is based on QNX and NX-OS on a POSIX? There is no question in intrinsic its architecture and hence the difficulty to create a comprehensive system of Full ISSU via QNX? I'm only speculating.. :-)
I operate routers for carrier-class in large scale that are based on FreeBSD-based kernel and the full ISSU is native.. I believe that with time the IOS XR will become a good software, but still have to improve compare to other software like Linux, POSIX and FreeBSD-based kernels. In this way, the Linux, POSIX and FreeBSD-based kernels help facilitate modularity, high availability and service virtualization. In terms of features, there is decent parity there, that's all just based on standards. You're not going to find that much difference between IOS XR and other Linux, POSIX and FreeBSD-based kernels.
Roger is spot on!
The underlying OS/kernel play a huge part in how the system operates and what is possible, and is why NX-OS has ISSU but classic-XR does not have full support.
For cluster you are thinking of NVSSU which is not quite ISSU, but is very close (<1 minute traffic loss).
With that said NCS6K was our first XR platform to have a Linux kernel and full ISSU support, 9K will have Linux next year and also ISSU.
How’s everything going?
I believe that many improvements are being made, for this issue of ISSU perhaps the way that BU can then be IOS-XR running on a hypervisor (could be a Hyper-V, LDoms, Linux-VServer or KVM, this is a trend ) and perhaps necessary to build a new HW specially prepared for this, in this way understand that there may be a scale and greater flexibility in the ISSU process. I have no idea what effort or work for it, but I know that would be a huge gain for the IOS XR if this occurs.
All the best,
cool! awesome! great news.. :-)
I understand that if there is already this way, a next step might be tempted to replicate this older HW (Trident based + RSP-4G) and not just for the newest HW (based Typhoon based + RSP-440) that would guarantee a huge protection investment since the software versions are 5.x longer viable in these older HW, since there is a legacy base very large ASR9K with these old HW.
Take a look !