And i can't enter & reply this topic , so i start new discussion. Now I got new IOS c2800nm-spservicesk9-mz.124-19.bin , in previous , u suggest to upgrade 124-25c , but i can't get it and now i got only 124-19 IOS.
2) Look at the release notes for the 12.4 mainline (you didn't state that you were running a T train so I'll assume you mean mainline) and it will list Resolved Caveats in each version of code. Search for the bug you noted and you'll see it shows up as resolved in a number of early 12.4 mainline codes. You should also check the release notes for your specific version. The link is here:
3) I don't know what version of code you are currently on but this is a pretty severe bug so it would warrant some testing. If you can recreate in a lab environment and then fix via code upgrade, that's ideal. If you can't, then you may have to just upgrade to what you can get and based on info from Bug toolkit and release notes, judge for yourself whether you are confident that upgrading the code will fix the issue. From what I see in giving a cursory look tonight, I think you should be able to get a version of code that works for you.
Yes, the bug is fixed in 12.4(19). I don't know why you aren't able to find a later mainline release (12.4(25c) for your platform. Mainline carries the same featureset throughout the life of the train, so if they built 12.4(1), in theory, you should be able to find 12.4(25c) for the platform. Unless if the platform went end of SW maintenence within the last couple years.
The way you know where this bug is fixed. You find the interim that it was fixed in. This will be a decimal notation. Find the highest release with a decimal value in parenthesis. Make sure you look for the one without a T if you aren't running a T release.
For this bug, it is:
That means that the fix will go in the next release after this, which is 12.4(10). So any release at or above 12.4(10) will have the fix. You can also see from the release field that we also double committed it to 12.4(3e), but it wasn't until 12.4(10) that *every* release will have this fix. This bug also made it into the first release of 12.4(8), which is weird since the diffs went into 12.4(9) code. They must have pulled the 12.4(9) branch before 12.4(8) was released, and rushed a commit since it is a severe bug.
Likewise, for 12.4T code, you see it went into:
That means any T release at 12.4(10)T or higher will have the fix. Since 10T wasn't built, 12.4(11)T would be the first public fix with the release for 12.4T code.
Hope this helps understanding releases in the future. It's a little easier with the 15.x code, since we don't double commit in the mainline branch anymore.
loadbalancing is one of the more complex items in hardware forwarding. of course we have talked about it many years on cisco live (id 2904) with ever incrementing more detail. and there is the support forum article on loadbalancing.
IntroductionArchitecture Building BlocksIOS-XR RoutersConfigurationPerformance VerificationOptimizationStrict timerSome more verificationThe CollectorInfluxDBDatabase statistics and HealthClosing comments
This document was written in collaboration with:
IOS-XR MPLS TE Auto Tunnel Backup Bandwidth Protection Current Implementation of MPLS TE Auto Tunnel BackupPotential issue with current implementation of MPLS TE auto tunnel backupEnhancement to MPLS TE auto backup in IOS XR 7.5.1Supported HardwareConfig ...
we are trying to monitor the Cisco 9148s SFP status, and have get the Sensor's dBm value from the CISCO-ENTITY-SENSOR-MIB table, meanwile , it has an Index value like "30000xxxx",such as "30001773", entsensorValueTable but we can't sure how to l...
Check out our latest release on Cisco Routed Optical Networking solution. Listen: https://smarturl.it/CCRS8E24Follow us: https://twitter.com/ciscochampion Disruptive network transformation may only happen once a decade. First movers c...