[c-nsp] NPE G1, CEF and ACLs and high CPU

[bill fumerola]

[ reading through quickly, just some ACL pointers.. ]

On Mon, Sep 08, 2008 at 09:15:31PM +0100, Mateusz B?aszczyk wrote:
> ! deny rogue IPs (it is interesting how many catches are here)
> deny ip 10.0.0.0 .... any
> deny ip 192... any
> deny ip host 0.0.0.0 any

this breaks PMTUD. icmp messages from poorly addressed routers still
need to get back to your hosts.

> etc....
> ! deny spoofing us...
> deny ip OURBLOCK1 any
> deny ip OURBLOCK2 any

move to the top.

> ! pings and traceroute
> permit icmp any any

either permit the specific ICMPs required for end to end communication
to work and permit the rest after your anti-spoof, or just move this
towards the top.

> permit udp any any range 32xxx 34xxx

rarely used, moved towards the bottom.

> ! transit providers
> permit tcp host THEM1 host US1 eg bgp
> permit tcp host THEM1 eq bgp host US1
> ! Internet eXchanges - bgp/msdp
> permit tcp THEM2 WCARD2 host US2  eg bgp
> permit tcp THEM2 WCARD2 eq bgp host US2
> deny ip any US1
> deny ip any US2

rarely used, move towards bottom. consider removing the port-specific
portions and see if you can get your ISP to use the TTL hack.

> ! some legacy stuff
> permit ip any host XXX

move towards the top.

> ! deny access to infrastructure
> deny ip any NETWORK_1
> ...
> deny ip any NETWORK_N

<hack>
sometimes, you can null route these blocks and use policy route-maps
that set next-hop for your local device and/or management networks
that allow the forwarding plane take care of discarding these
</hack>

> permit ip any any

and here's where the majority of your traffic matches - at the bottom.
this will kill performance. consider the trade-off of adding a:

permit tcp any any established

towards the top of your config. that rule will catch the majority of
most networks' traffic. your deny rules below will still prevent SYN
packets from getting through to your infrastructure space. yes, your
'infrastructure' will be open to ACK floods and other such things, but
you can deploy other measures to assist with that. for example: ACLs on
the interfaces facing your management network instead.

also, if you run a service that represents the bulk of your traffic on
that device, add a short-circuit rule for that service higher at the
top, even if a rule with wider reach allows the same later.

> any significant advantage over entry-level 6500/7600?

6500/7600 will be way less order dependent and you'll be able to have
much longer ACLs. in my experience, on software platforms 99% of your
traffic should either be permitted or denied in the first 5 or so rules
or you're going to see serious performance problems.

consider using 'access-list compiled' if your platform/IOS support it.

distribute your ACLs as much as possible. take a multi layered approach.
know your device's strengths and weaknesses when it comes to filtering
and exploit those.

-- bill