[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