Pix 7.04 Upgrade, should I implement failover before or after?

S

Stinn

[H]ard|Gawd
Joined
Jul 13, 2001
Messages
1,796
Quick question and hopefully someone can give me some guidance. We currently have a single pix firewall as our main firewall. We decided we need to have redundancy so we have a second one now to do failover with. However it's also been decided to go to the newest software version(7.04) at the same time(we have the memory upgrade). The only thing I'm wondering is would it be better to do the failover FIRST and then the software upgrade or do the software upgrade individually and then do the failover.
I have been told to do the failover first but I don't exactly trust the source of it.
Thanks in advance.
 
Just taking a guess, I'd say you'd want the latest and greatest software installed before making the failover change, in case there are improvements in the software to handle the failover. I've been too leary to update my PIXes to the 7 code after hearing a horror story or two about the upgrade killing a PIX. Let us all know how it goes.
 
I agree on the upgrade prior to doing the failover config.

You also don't want to make too many changes at one time. Harder to troubleshoot that way if something breaks.
 
hey. just to throw in my 2 cents, i would not even upgrade to 7.0 without thoroughly testing it. 7.0 is a huge step up and introduces many new changes in the configs and extra features. the last thing you want to do is upgrade and possibly break a config becuase downgrading an IOS is a pure pain in the ass.
 
We have a backup firewall(an old GB1000) just in case the pix does go down for some reason during the upgrade. I thought it made the most sense to do the upgrade before the failover but I wasn't sure. I'll keep reading their upgrade guide in case something is in there. Anyone else who may have done this it would be great to hear from them.
 
Do not upgrade to 7.0 on a production box unless you can afford the network to be down for several hours, as it is a very real possibility that you will encounter bugs.

That said, do the failover config after you upgrade. Also make sure you go through the new config line-by-line and make sure that everything was converted. The upgrade script did not parse and convert everything when I did it, but that was also on 7.0.1.

Make sure you read the tech notes on the TAC website concerning 7.0. There are a lot of changes you need to be aware of. Example: Larger-than-advertised MSS values were allowed in PIX 6.x, it is denied in 7.x unless you explicity allow it. These are things you need to be aware of, because things will start breaking and you'll think they're bugs, and TAC will tell you that they're actually poorly documented "features." Where I work, a lot of websites were broken because of the LTA MSS values outlined above. It took me a while before I figured it out (before TAC did :)).
 
Boscoh said:
Do not upgrade to 7.0 on a production box unless you can afford the network to be down for several hours, as it is a very real possibility that you will encounter bugs.

That said, do the failover config after you upgrade. Also make sure you go through the new config line-by-line and make sure that everything was converted. The upgrade script did not parse and convert everything when I did it, but that was also on 7.0.1.

Make sure you read the tech notes on the TAC website concerning 7.0. There are a lot of changes you need to be aware of. Example: Larger-than-advertised MSS values were allowed in PIX 6.x, it is denied in 7.x unless you explicity allow it. These are things you need to be aware of, because things will start breaking and you'll think they're bugs, and TAC will tell you that they're actually poorly documented "features." Where I work, a lot of websites were broken because of the LTA MSS values outlined above. It took me a while before I figured it out (before TAC did :)).
Click to expand...
Thanks for the advice. I will be putting in our backup firewall while I do the upgrade so there will be only a minor downtime. Hopefully all will go well and I will be back up and running the pix in no time.
I have to take the pix down either way because I need to toss the new ram in it. I found cisco's article on LTA MSS issue and have bookmarked it just incase we run into the that issue. Did you have alot of websites give you troubles with the LTA MSS or was it few and far between? I'm only asking because if it was pretty common then I will apply the fix during the downtime otherwise I'll do it in the days after.
 
We ran into it mainly on sites with extensive applications built into them...such as Java and ASP. We're in the oil business, we log into a lot of sites with historical and real-time data...so, lots of applets. Of the 20 or so "common" sites that we access on a daily basis, about a quarter of them had problems. IIRC, FedEx's web-based shipping label app also did not function until we made the change.

We also ran into the LTA MSS issue in dealing with connections made over satellite links into our network. So we had to adjust things for those users too.

[edit]
Another problem we had that actually JUST got resolved was with out-of-order TCP packets. We were noticing that a lot of our satellite users were getting packets dropped. I couldn't see any pattern to it other than o-o-o packets. Cisco finally came back and said that with 7.x, the PIX will only buffer 2 o-o-o packets in a stream. After that, it will drop the packets. The number of o-o-o packets the firewall will accept is not configurable on a PIX, but it is on an ASA. I still dont understand that, I guess maybe the buffer on the PIX isnt configurable...or it could be attributed to the ASA having more horsepower to reorder more packets. At any rate, 'show asp drop' will become your friend. Use it often, and use it in conjuction with the drop-type modifier in the 'capture' command to see what traffic is being dropped for what reason. If you start having that problem, your only recourse will be to downgrade back to 6.x, disable inspection for the particular protocol if you can, buy an ASA (or something else), or try to work with the ISP in resolving their chronic out-of-order problem (good luck). Since the connections were always retried, we rarely saw anything completely fail because of this. It was extremely annoying though.
 
I found one of those things!! It's a small gotcha but it is a gotcha.
In the 6.3 config we had these two statics(along with others that don't matter right now):
Code: 
name 192.168.0.1 asp1_mail
...
static (inside,outside) 1.1.1.1 asp1_mail netmask 255.255.255.255 0 0 
static (inside,outside) 1.1.1.2 asp1_mail netmask 255.255.255.255 0 0
So basically we have one server acting like two to the real world.
However in 7.04 it won't let me do this it gives me an error that the second static(1.1.1.2) is a duplicate static or some such. So it won't allow me to translate multiple external ips to one internal ip. This seems like somethign I should be able to do, and I'm sure it's possible it's just a matter of figuring out how to do it now.
Anyone have a suggestion for me?
 
You must log in or register to reply here.
Back
Top