If you block the traffic at the interface level using ACL, then other features are allowed to process the packets. Remember, ACL process the packets almost before all the features VPN, NAT, etc.
By configuring at control plane, you allow the traffic to processed by the other IOS features and then, come to control plane. In fact,Cisco does recommend to filter the control traffic using other features. Snippet from http://www.cisco.com/web/about/security/intelligence/understanding-cppr.html Drop Packets Prior to CPPr There are several points in the path of the packet prior to CPPr where undesirable packets can and should be dropped. The following considerations can help administrators reduce the number of packets that reach CPPr: - *Interface ACLs and Unicast RPF:* Consider points where interface ACLs and Unicast RPF can be employed. - *IP Options Handling:* Use the *ip options drop* command (where supported) to prevent IP packets with options from reaching the control plane. - *ACL Logging:* Use of the *ip access-list logging interval* * interval-in-ms* command will rate limit ACL logging punts (which will need to be processed by the CPU). This method is particularly effective when logging packets that are denied by an ACL. - *Unnecessary services:* Disable unnecessary services to minimize the number of packets that are punted to the CPU. With regards Kings On Mon, Nov 22, 2010 at 11:41 PM, Eugene Pefti <[email protected]>wrote: > I’m still not getting one may be an essential detail about CPPr. > > Can someone show me its point or benefit in a situation like this. Cisco > guide says that > > “The port-filtering feature provides for policing/dropping of packets going > to closed or nonlistening TCP/UDP ports” > > I’m OK with it. Then we know that the path of packet processing starts with > ACL applied to the interface. If this ACL drops the packet which we don’t > want to allow then why would we need CPPr? > > > > i.e. my ACL allows Web, HTTPs, and SSH incoming from outside. The ACL is > applied to the outside interface and then all other traffic is silently > dropped regardless of whether the router’s control-plane has more open > ports. Similar fashion for the outbound traffic arriving from inside. > > > > Why would I care about CPPr at all ? No other traffic that we might control > with the host subinterface of CPPr will even reach the route processor. > > Please show me the situation that would make me say – Yes, you are right, I > would need to deploy CPPr host subinterface protection. > > > > Eugene > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Vybhav > Ramachandran > *Sent:* Sunday, November 21, 2010 8:16 PM > *To:* Johan Bornman > *Cc:* OSL Security > > *Subject:* Re: [OSL | CCIE_Security] Control-plane > > > > Hello Johan, > > > > You are right. The special "port-filter" and "queue-threshold" policy-maps > can only be applied on the control-plane "HOST" subinterface. > > > > Along with this, what i meant by Management Plane protection was using the > "management-interface" command > http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/htsecmpp.html > > > > Using Management plane protection , you can control what managment > protocols ( ex : telnet , ssh , http , etc ) are allowed on specific > physical interfaces on the router. This is only possible on the > "control-plane HOST subinterface" > > > > Cheers, > > TacACK > > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
