Showing results for 
Search instead for 
Did you mean: 
nyein chan tun

IOS 12.4-19 can resolve CSCse34097 bug (for voice ) ?

@ Steven Holl

    I refered to this dicussion .

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.

So i want to know it can resolve CSCse34097 bug ?

Thanks alot & best regard.

David Hailey

A few things:

1) Look the bug up in the Cisco bug toolkit and it will provide versions of IOS in which this was fixed as follows:

Fixed-In Fixed-in

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.


Please rate helpful posts!

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.