[c-nsp] Hardware for 'managed firewall'
Justin Shore
justin at justinshore.com
Wed Sep 30 09:06:14 EDT 2009
David Hughes wrote:
>
> Interesting. I thought NSM was much better than Cisco's CSM (and a hell
> of a lot cheaper).
You should really take a look at the new ADSM releases for the FWSMs.
It's actually pretty good. You have full control of all contexts if you
aim ADSM at the admin context. Of course I never use the GUI anyway so
what does that matter?
> As for FWSM's, after spending months trying to debug early versions that
> did random very bad things with traffic when in the same chassis as CSM
> linecards we decided never to touch them again :)
I don't have those LCs so I can't speak to that. They work fine with
ACE's though. We have only had 2 problems with the FWSMs. The first
was caused by IOS on the RP getting confused over which VLANs it was
supposed to be passing the FWSM (firewall-group). A reboot of the RP
was needed to fix it. The second was a FWSM that failed after a
lightning strike this past summer. DC power to the chassis wasn't ever
lost and none of the other LCs ever showed any signs of not working
right. However that LC failed within minutes of the power failure that
the strike caused so I think it has to be related. That required an
RMA. Other than that they've worked great for us.
We supply crypto in our 7600s for the data center with SSC-400 2G IPSec
SPAs. Now if you want to talk about a funky LC, let's talk about those
damn things. Our 3 biggest outages of our entire phone system (ILEC and
CLEC) were thanks to those damn IPSec cards. The AS SMEs that
configured them initially screwed up the config which caused 2 of the
outages. The 3rd one was a similar repeat thanks to the default VLAN
list being allowed on both virtual interfaces at once. Watching a RP
crash under the load of a single HSRP packet repeated several million
times per second is surreal at best. I spent 13 hours Sunday-Monday
morning troubleshooting a new problem with those LCs. Apparently the
crypto engine can't accept MPLS-labeled packets and route them properly.
A TCAM lookup sends them to the RP which drops them saying that it
can't do crypto. My TAC engineer is telling me that the features
enabled on the outward-facing interfaces are causing this. He's saying
that the interfaces can't have either MPLS enabled or have a
service-policy. How in the world do they expect a SP to use these
things if that's the case. Every interface in a SP environment will
have a service-policy on it and all interfaces except the CE-facing ones
are MPLS-enabled. Baffling.
Justin
More information about the cisco-nsp
mailing list