[c-nsp] IOS firewall on 7500 vip -- not supported??

[Rodney Dunn]

On Tue, May 03, 2005 at 10:57:24AM -0400, Joe Maimon wrote:
> 
> 
> Rodney Dunn wrote:
> > Joe,
> > 
> > We don't recommend folks do IPSEC on a 75xx (you can configure
> > it but it's no distributed and we don't test it).  That may
> > be what they are referencing.
> 
> I dont recommend it either. Been there done that, seen nasty ATM cell 
> loss on PVC's carrying ipsec traffic to the box, didnt get any support.
> 
> Still cannot understand why a) ipsec is allowed b) ipsec is not 
> supported  c) even when it causes outages in "unrelated" functions.

I've said it before. It's IPSEC session to the box for management.

> 
> > 
> > Or they may be talking about IP INSPECT. I'm not sure how much
> > of that code is in the dCEF path or not but regardless the
> > box shouldn't crash when it's enabled.
> 
> I am not quite certain either, but I suspect on this box I see little to 
>   none dCEF switching of CBAC'd traffic. However this issue is a bug.
> 
> CSCsa64848
> 
Ok..the bug is filed and and it's assigned.

> 
> > If anything it should
> > (for this box at least) punt the packets to the RSP for handling.
> > 
> Yep, CBAC/NBAR. And it does work. The question is what has happened now 
> that it is not "supported"? I have been getting support on this for 
> quite some time.

If it crashes the box it's a bug. Simple as that and should be fixed.

> 
> What would you do to support customers who did not want simple ACL 
> protection but real session tracking? (Everyone buying "Managed 
> Internet") VRF-Lite to pixen?
> 
> > I wish we could move the box to a fully distributed path and
> > drop anything that has to be punted to make the switching
> > vectors simpler. But that would be a big move and we'll never do
> > it.
> > 
> There are many things that to an outsider like me seem to be 
> "intentionaly" left out of the dCEF switching path. I am happy I have 
> them at all.
> 
> Perhaps that would be motivation for a seperate train. However, people 
> dont seem to appreciate te lack of supported features for the GSR (hence 
> the 7600 as an attempt to replace the 7500) and 7500 is kindof a legacy 
> platform now.
> 
> I can appreciate it would be a whole lot easier for cisco to support a 
> simpler switching path with less features. Thats what their competitors 
> do. But "less features" to the best of my recollection has never been a 
> Cisco selling point.
> 
> If more powerfull RSP were available, I wouldnt mind doing feature 
> processing there. The problem is that the RSP16 is almost the cost of a 
> NPE-G1 and not quite as powerfull.
> 
> > What is the case number?
> 
> Coming in seperately.
> 
> > Can you do "clear count" and get a couple snapshots of "sh int stat"
> > for the interface you have ip inspect on and let's see if you
> > are dCEF switching packets to/from that interface?
> > 
> 
> Basically all interfaces that have an egress ACL with an ending line of 
> deny ip any any have a corresponding ip inspect <name> in (its also 
> using reflexive acl for the protocols that cbac does not support.
> 
> I will take a look and see what I can find.
> 
> > Bottom line is I never recommend anyone run a feature on a 75xx
> > that is not fully distributed and their box should have VIPs with
> > the CPU power and memory to do those features in the distributed path.
> 
> Well I wouldnt recommend it to anyone either, except if they are 
> prepared to re-evaluate their capacity based on their RSP.
> 
> > 
> > Rodney 
> > 
> > 
> > 
> > 
> > On Tue, May 03, 2005 at 07:34:33AM -0400, Joe Maimon wrote:
> > 
> >>Hello All,
> >>
> >>I have just been emailed from TAC concerning an ongoing issue where 
> >>H.323 inspection in 12.3 T series causes router crashes and in the 
> >>message was this gem.
> >>
> >>"
> >>I'm from the Architecture team, so I don't have significant expertise in
> >>Security. I've been told the IOS Firewall feature is not supported on VIP's.
> >>"
> >>
> >>Does anyone quite know what this means? I have seen it working fine.
> >>
> >>Thanks,
> >>
> >>Joe
> >>_______________________________________________
> >>cisco-nsp mailing list  cisco-nsp at puck.nether.net
> >>https://puck.nether.net/mailman/listinfo/cisco-nsp
> >>archive at http://puck.nether.net/pipermail/cisco-nsp/
> > 
> > 
> >