cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1039
Views
0
Helpful
2
Replies

PIX 525 upgrade v6.0 to v6.2(1) or v6.2(2)?

scothartman
Level 1
Level 1

I have been upgrading the code on all our PIXs.

I've been moving to 6.2 code for the added functions and the updated capability of PDM to support VPN and grouping.

The bulk of the firewalls are 515s but I do have a pair of 525s currently running 6.0(1).

In the open caveats for 6.2(2) is... CSCdx89579 PIX 525 Crashes intermittently.

The release notes for the earlier version 6.2(1) does not have a caveat for 525 crashes.

My question:

Was this caveat introduced in 6.2(2) or just not discovered in 6.2(1) ? If it was introduced in 6.2(2) then I can at least move to 6.2(1) for this pair. Does anyone know how often and under what circumstances this happens?

Thanks,

Scot

1 Accepted Solution

Accepted Solutions

gfullage
Cisco Employee
Cisco Employee

This bug is only seen in a failover pair, and even then only when say, one person does a "write standby" on one PIX and someone else does a "write mem" on the other. Basically when two commands are issued at the same time, this *may* happen. Very rare, only seen by one customer by the looks of it.

This bug is in 6.1 also, in fact it was first found in that code, which is why it appears in the 6.2 release notes. In fact, it's also been resolved in 6.0 code meaning the bug was in that, it's just that no-one ran into it then.

It has been fixed and integrated into a few interim releases of code, no release versions as yet. You can open a TAC case if you like and request one of these versions (they'll be able to look it up no problem provided you give them the bug ID). Of course then you'll be running interim code, it's up to you whether you want to do that or not.

View solution in original post

2 Replies 2

gfullage
Cisco Employee
Cisco Employee

This bug is only seen in a failover pair, and even then only when say, one person does a "write standby" on one PIX and someone else does a "write mem" on the other. Basically when two commands are issued at the same time, this *may* happen. Very rare, only seen by one customer by the looks of it.

This bug is in 6.1 also, in fact it was first found in that code, which is why it appears in the 6.2 release notes. In fact, it's also been resolved in 6.0 code meaning the bug was in that, it's just that no-one ran into it then.

It has been fixed and integrated into a few interim releases of code, no release versions as yet. You can open a TAC case if you like and request one of these versions (they'll be able to look it up no problem provided you give them the bug ID). Of course then you'll be running interim code, it's up to you whether you want to do that or not.

Thanks for the response.

Sometimes it's helpful just to know the conditions that cause a bug so you can make an informed decision.

I appreciate the time and detail of the response. Very helpful.

I'll run with the 6.2(2) since I can control the condition of when the commands are run.

Thanks.

Review Cisco Networking products for a $25 gift card