[c-nsp] pix 535 issues

[Łukasz Bromirski]

Jeff Kell wrote:

> We see this more often than I'd like, on a 515E (only 32Mb).
> Somewhere around 28-30k connections and new connections start to
> generate "memory allocation errors" in the logs, and the
> connection requests are ignored.

Because there's no room in RAM to track them. It solely depends on
memory and if You want to track high number of connections, either
upgrade to UR 515E or buy bigger box ;)

> You can watch connection counts (console, PDM, probably SNMP), or
> devise some means of analyzing the connections that are active to
> try to find the source[s].  Unfortunately, at least on PIX 6.3,
> there is no connection throttling mechanism like more recent IOS
> implementations. I don't know about 7.0.

First of all, in 6.x line there is option to tune timeouts for
inactive sessions from default 86000 seconds to something more sane
value. Life shows timeouts around 1-5 minutes are really OK
(especially if all Your applications do know how to use keepalives).

Second of all, You can limit number of NAT translations (also present
in 6.x line) with `nat [.....] max_conns'. This is for entire
subnet but You can easily configure few nat entries, not one for
all the network.

Third of all, if You'll enforce strict traffic filters for specific
services (excluding all NetBIOS/etc services) and can use uRPF
feature on interfaces, it also can drop down some trashy traffic.

However, I'll go with most of proactive QoS-centric features as close
to users, possibly on switches where they do connect. Shaping/policing
them on the internet gateway is last resort and simply does not scale.

-- 
this space was intentionally left blank    |            Łukasz Bromirski
you can insert your favourite quote here   |        lukasz:bromirski,net