[c-nsp] netflow accouting incompatibilities (on vaccess if)

[Oliver Boehmer (oboehmer)]

Gert Doering <> wrote on Tuesday, June 07, 2005 10:45 PM:

> Hi,
> 
> ist there a document somewhere that describes under which conditions
> netflow exporting suddenly can go inactive on virtual-access
> interfaces? 
> 
> Is it dependend on CEF?

likely, but it should also

> While pinging the customer, the flow cache definitely doesn't have
> anything for the interface in question:
> 
> Cisco#sh ip cache flow | inc 292
> Cisco#
> 
> (packets going *to* the customer's IP are accounted elsewhere, so
> won't show up here)
> 
> For other virtual-access interfaces, that do NOT have "compression
> mppc" 
> in there, Netflow accounting does work (and IP CEF is enabled).
> 
> Am I right in assuming that
> 
>   - mppc compression is incompatible with CEF ?
>   - CEF is essential for netflow accounting  (in 12.3(x)) ?
> 
>   -> so "user requests mppc -> netflow is silently deactivated"
> 
> Nasty surprise.

mppc forces everything to process path, IIRC. But IMHO netflow should
still work in this case.

> As a workaround: is there a way to force-deny CCP requests on our
> Cisco?  I can't seem to find a setting in the virtual-template that
> will reject compression - "no compress" will just make it "not
> request" compression (but obviously not reject it - that's already
> set).  Any tips what I overlooked?

the LNS will reject CPP (i.e. compression) unless it has "compress .."
enabled on the vtemplate:

interface Virtual-Template1
 ip unnumbered Loopback0
 no keepalive
 peer default ip address pool cisco.com
 ppp authentication chap pap callin
 ppp direction callin
end

*Jun  8 05:03:40.959: Vi1 CCP: I CONFREQ [Not negotiated] id 1 len 10
*Jun  8 05:03:40.959: Vi1 CCP:    MS-PPC supported bits 0x00000001
(0x120600000001)
*Jun  8 05:03:40.959: Vi1 LCP: O PROTREJ [Open] id 1 len 16 protocol CCP
(0x80FD0101000A120600000001)

	oli