Yes, you read that tittle correctly. If i do not have the LOG keyword on the deny any any and the end of the inbound ACL, then TCP connections to PAT exposed services ("ip nat inside source static tcp x.x.x.x ppp y.y.y.y ppp extendable") randomly fail. The inbound packet passes the ACL (you can see the match counter increment), a NAT translation is formed ("sh ip nat tra" ports match those sniffed using wire-shark when trying to diagnose problem), but what happens to the packet after that is anybody's guess. Then just to confuse the heck out of me other TCP connections with the same source ip / port will sometimes succeed. No, I haven't sniffed the LAN side as yet. Now ACL logging will cause a packet to be process-switched instead of fast / CEF switched and this is where I have been focusing my investigations.
This connection is an Ethernet hand-off of a fibre service /31 masked on gi0/2 of the NPE. We advertise 2 x /28 subnets to the provider via BGP and they inject us with 0.0.0.0. There is a PPPoE backup circuit to the same provider on gi0/1 of the NPE. both the dialer bound to gi0/1 and gi0/2 use the same inbound ACL. If traffic is routed in the fibre service on gi0/2 (BGP active), the problem manifests. If I shut down BGP and the traffic then flows in the PPPoE connection on Di1/Gi0/1 everything is hunk-dory tickety-boo ! Are Dialer interfaces process-switched by default ??? I didn't think so. Current image(c7200p-adventerprisek9-mz.12-24.T4) should be able to do CEF on dialer.
Has anyone else seen this super-weird behavior and have a fix ? At present the traffic volume is low and the NPE-G2 can handle it on its ear (CPU <10% most of the time)..... but its jut not right. and of course my logs being spammed with deny messages will preclude me from noticing anything important in there.
Open to ideas, suggestions, different way of looking at the problem, alignment of planets, etc. this is doing my head in. I'll prepare an obfuscated copy of the config if anyone is interested.
