[c-nsp] Control-Plane CEF-exception subinterface

[Saku Ytti]

On (2006-09-18 10:59 -0400), German Martinez wrote:

> We are currently running 12.2(18).SXF3.  How can be indentify traffic
> destined to the CEF-exception subinterface while running our current
> IOS?  We have a COPP policy applied in some of our routers and

>From top of my head IP options, ACL's with LOG statement, RPF exception
ACL configured and naturally all receive packets, I'm probably still missing
something. 

> apparently when CEF is disabled in one of our LC -7600 architecture-
> our RP starts discarding packets destined to it :-(

When dCEF is disabled, all frames are software switched.

> How is the communication between LC and RP when a packet needs to be
> process switched?

I'm not 100% sure what is being asked here, but if dCEF is disabled in
7600/LC, you're not process switching, you're still CEF switching but in
software in MSFC. And indeed, frames that are punted for MSFC will be evaluted
against CoPP rules, even if they are just transit packets. Which is from my
point of view bit silly, example which I like to use is take IXP where you're
receiving packets violating your antispoofing ACL (that is packets from
your PA address coming in from IXP) you want to know which IXP neighbour
is sending these packets so you insert log-input statement to the deny ACE
for given PA, now, if you run CoPP you must permit the packet in CoPP
so that MSFC will be able to log and drop it, if it's not allowed by CoPP
it's dropped in hardware before MSFC has chance to see it.

However if you get CEF disabled from LC, you most probably don't care
if software switching works or not, if CoPP allows the packets through
or not, as MSFC can't handle the traffic levels anyhow. So real solution
would be feature from GSR 'router isis/external overload signalling' to
signal neighbour not to send you anything if you're not running dCEF.

-- 
  ++ytti