Cisco PIX and Gigabit
#1
Anyone ever experienced problmes with Cisco PIXes and Gigabit Interfaces (Fibre to Cat6500s and Cat4000s) ?
Seeing some very strange interface lock ups and other odd behaviour.
Deano
Seeing some very strange interface lock ups and other odd behaviour.
Deano
#6
Jeff
Its complicated. My infrastructure boundary is the Cat6500 Gig port. The pix and Cat4000 beyond is part of a managed service. Currently the guys looking after the PIXs seem reluctant to fully engage Cisco which is frustrating. (especially as the PIXs were part of a design done by a couple of Cisco SEs.)
Theres the usual finger pointing at each side of the boundary. but some of the problems are odd and unrepeatable. bouncing interfaces sometimes works - once or twice we've seen the PIX kernel panic and reload which cures it, other time reloads dont help.
Its all the more frustrating as we're not even putting 256K of traffic to them - let alone a gig
Juts wondering if anyone had played with the Gig interfaces before (not your home setup is it Jeff ?)
Deano
Its complicated. My infrastructure boundary is the Cat6500 Gig port. The pix and Cat4000 beyond is part of a managed service. Currently the guys looking after the PIXs seem reluctant to fully engage Cisco which is frustrating. (especially as the PIXs were part of a design done by a couple of Cisco SEs.)
Theres the usual finger pointing at each side of the boundary. but some of the problems are odd and unrepeatable. bouncing interfaces sometimes works - once or twice we've seen the PIX kernel panic and reload which cures it, other time reloads dont help.
Its all the more frustrating as we're not even putting 256K of traffic to them - let alone a gig
Juts wondering if anyone had played with the Gig interfaces before (not your home setup is it Jeff ?)
Deano
Trending Topics
#9
All fibre - 6500 is in hybrid (CatOS on Sup, IOS on MSFC). 6500 least doesnt give the option for auto on the gig ports. (Seen no end if issues with auto ont he 10/100 ports).
On one occasion we appeared to be getting arps between MSFC and PIX but no IP. reloads, port resets had no affect. Changed GBICs etc (full scratching **** and change anything mode). 20 mins later PIX kernel panicked and reloaded - worked perfectly - to me thats as typical of a Cisco Bug as I've seen.
Damn things are only there to do NAT. the F/W is being done by Nokias further down.
My view is a TAC case should have been raised a month ago . We cant see anything on Bug tracker but we'll keep plugging away.
RR - You have CSPM
Deano
On one occasion we appeared to be getting arps between MSFC and PIX but no IP. reloads, port resets had no affect. Changed GBICs etc (full scratching **** and change anything mode). 20 mins later PIX kernel panicked and reloaded - worked perfectly - to me thats as typical of a Cisco Bug as I've seen.
Damn things are only there to do NAT. the F/W is being done by Nokias further down.
My view is a TAC case should have been raised a month ago . We cant see anything on Bug tracker but we'll keep plugging away.
RR - You have CSPM
Deano
#10
Scooby Regular
Damn expensive NAT solutions....
Its unlikely that you'll find an answer without getting a TAC case raised....I'm assuming that you have all the latest versions of code etc ?
I love the fact that you are using a 1 Gig PIX (Its the 535 ?) as a NAT device and then firewalling further down into (I assume) a cluster of IP730s.....and that the PIX 'panics'.....
Not much help I'm afraid
Jeff
Its unlikely that you'll find an answer without getting a TAC case raised....I'm assuming that you have all the latest versions of code etc ?
I love the fact that you are using a 1 Gig PIX (Its the 535 ?) as a NAT device and then firewalling further down into (I assume) a cluster of IP730s.....and that the PIX 'panics'.....
Not much help I'm afraid
Jeff
#11
Jeff
Unfortunately Cisco were let loose with the spec sheets and design which was approved back in the midsts of time.
There are good reasons (historically our addressing is a "bag of ****") why we have to NAT separately. One "reason" for the PIXs was we could advertise our routes via RIP to save manual updates. Except the volume of RIP updates causes panics aswell so we had to turn it off.
I keep pushing for a TAC case but our "partner" is prevaricating.
Was really wondering if anyone else had seen Gig PIXs and ahd problems.
Unfortunately Cisco were let loose with the spec sheets and design which was approved back in the midsts of time.
There are good reasons (historically our addressing is a "bag of ****") why we have to NAT separately. One "reason" for the PIXs was we could advertise our routes via RIP to save manual updates. Except the volume of RIP updates causes panics aswell so we had to turn it off.
I keep pushing for a TAC case but our "partner" is prevaricating.
Was really wondering if anyone else had seen Gig PIXs and ahd problems.
#12
Scooby Regular
Well, I do think that the only people that will be able to help is Cisco themselves. You do appreciate that the Nokia boxes will do RIP/OSPF/BGP etc themselves (as well as NAT).
I'm not much help as the only devices that I've worked on with Gig (from a firewall perspective) are Netscreen 1000, Nokia IP730 and SonicWALL GX6500.....
Jeff
I'm not much help as the only devices that I've worked on with Gig (from a firewall perspective) are Netscreen 1000, Nokia IP730 and SonicWALL GX6500.....
Jeff
Thread
Thread Starter
Forum
Replies
Last Post