06-24-2003 06:32 PM - edited 02-20-2020 10:49 PM
The bug "CSCdx90840" was first found in "6.1(3.105), 6.2(1.104)" versions and was fixed in "6.3(1), 6.2(2.100), 6.1(4.100), 6.0(4.100), 6.3(0.100)" versions, based from the Bug Tool Search results.
If you will look at the PIX OS 6.2(2) Release Notes (below), you will see that this bug is still under the "Open Caveats".
http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_62/relnotes/pixrn622.htm#88643
Anybody out there who can help me clear these things out a little?
Also, how I do verify the "6.2(2.100)" version? Or should I say, how do I correctly verify/interpret this version number format.
Thanks in advance.
Solved! Go to Solution.
06-24-2003 10:50 PM
If the bug was fixed in 6.2(2.100) then it is NOT fixed in 6.2(2), therefore the Release Notes are correct.
Anything with a .100 or .101 or whatever number in the version is called an interim release. When a main release gets put out on CCO, it'll be just, let's say, 6.2(2). From that point on the developers will continue to fix old bugs and fix any new bugs found in this new release. As they do so they'll create interim versions, the first interim of 6.2(2) will be 6.2(2.100), this'll generally contain a few bug fixes. Then they'll create 6.2(2.101) based on 6.2(2.100), this'll contain a few more bug fixes. This continues until at some point they decide to release 6.2(3), the next major release, this will contain all the bug fixes fixed in the 6.2(2.1xx) interim releases.
Interim releases are not put out on CCO, but may be given to customers hitting a specific bug by the TAC. There's currently lots of customers running interim releases, although we always suggest to them to upgrade to the next major release when it comes out.
So, for your bug, it was first fixed in 6.2(2.100), which was built AFTER 6.2(2), although it is directly based on it, and just contains a few bug fixes (actually I just checked and it contains 10 bug fixes, of which CSCdx90840 is one of them).
Hope I haven't confused you even more.
06-24-2003 10:50 PM
If the bug was fixed in 6.2(2.100) then it is NOT fixed in 6.2(2), therefore the Release Notes are correct.
Anything with a .100 or .101 or whatever number in the version is called an interim release. When a main release gets put out on CCO, it'll be just, let's say, 6.2(2). From that point on the developers will continue to fix old bugs and fix any new bugs found in this new release. As they do so they'll create interim versions, the first interim of 6.2(2) will be 6.2(2.100), this'll generally contain a few bug fixes. Then they'll create 6.2(2.101) based on 6.2(2.100), this'll contain a few more bug fixes. This continues until at some point they decide to release 6.2(3), the next major release, this will contain all the bug fixes fixed in the 6.2(2.1xx) interim releases.
Interim releases are not put out on CCO, but may be given to customers hitting a specific bug by the TAC. There's currently lots of customers running interim releases, although we always suggest to them to upgrade to the next major release when it comes out.
So, for your bug, it was first fixed in 6.2(2.100), which was built AFTER 6.2(2), although it is directly based on it, and just contains a few bug fixes (actually I just checked and it contains 10 bug fixes, of which CSCdx90840 is one of them).
Hope I haven't confused you even more.
06-24-2003 11:21 PM
"Hope I haven't confused you even more."
No, not at all. You've explained it very well and I thank you for that. Now I can explain it clearly to our customer.
If you wouldn't mind, the bug tool only mentioned (for CSCdx90840):
"It is the failover environment, and, in the case of the high
network of load, PIX outputs and reboots the following messages."
We haven't actually encountered the bug but we would like to avoid this as well as other bugs that the customer might encounter based on their current requirements. Please correct me if I'm wrong, but my interpretation of what's written above is that the PIX will reboot once the bug is encountered.
I believe in what most people say that "If it is not broken, don't fix it", but our customer is quite sensitive so would you recommend that we upgrade to 6.3?
Thanks again.
06-25-2003 04:39 AM
In general, upgrading to a new release to fix bugs which aren't affecting you isn't a good idea. Sure, a reboot bug isn't a good thing and you want to select a release that has the fewest bugs. Your best bet is to search the 6.3.1 bug base and see what offending items you find there.
However, 6.3.1 is a brand new release with alot of new features. Generally speaking, a version with a few dot-releases (6.2.2, 6.0.4) is more stable than a the first release of a new version (6.3.1) as a lot of the bugs will have been found and fixed in each revision. (6.2.1, 6.2.2: 6.0.1, 6.0.2, 6.0.3 etc)
Feautres are important also..... If you need a feature from 6.3.1, then it is your best image. If stability is more important than features, then select one of the GD releases such as 6.1.4.
-Shannon
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