Subject: [BEHAVE] Logging: address exhaustion and port exhaustion events

From: Tom Taylor <[email-masked]>
Date: Sun, 29 Sep 2013 04:22:41 -0400

In the -04 pass for the SYSLOG logging document, I added the following 
text in the section describing the address pool threshold events:

<begin>

The high-water-mark threshold event provides a warning that the
address-port combinations offered by the pool are nearing exhaustion.
Upon exhaustion, packets may be dropped because no address has enough
free port values left to be allocated to an address mapping ("address
exhaustion"). This applies to the case of "paired" pooling behaviour
[RFC4787], where typically an address will not be
allocated unless it has a sufficient number of free ports.
Alternatively, packets will be dropped simply because no address in the
pool has a free port number for the required protocol ("port
exhaustion").

Packets dropped due to address exhaustion are included in the amounts
provided by the following NAT MIB counters:
   o globally, natResourceErrors in the natCounters table;

   o per protocol, natProtocolResourceErrors in natProtocolTable;

   o per subscriber, natSubscriberResourceErrors in
     natSubscribersTable.>

Packets dropped due to port exhaustion are counted in the following
NAT MIB counters:
   o globally, natOutOfPortErrors in the natCounters table;
   o per protocol, natProtocolOutOfPortErrors in natProtocolTable;
   o per subscriber, natSubscriberOutOfPortErrors in
     natSubscribersTable.

<end>

First question: do people agree with the proposed definitions of address 
exhaustion and port exhaustion? If so, we have operational definitions a 
NAT can work with in generating both counts and logs.

Second question: our current OAM-related events are all based on 
administratively-set limits and thresholds. Should the address 
exhaustion and port exhaustion events also be logged?

Tom Taylor

---

From: Simon Perreault <[email-masked]>
Date: Sun, 29 Sep 2013 11:52:52 +0200

> NAT can work with in generating both counts and logs.

Looks good to me!

> exhaustion and port exhaustion events also be logged?

I'm not sure. What I would expect people to do is graph the counters of 
port allocations/deallocations so as to produce a graph of pool usage. 
Based on historical usage you can make plans for future dimensioning of 
the pools. Exhaustion events are not much more useful. If you're 
interested in the immediate effects of exhaustion events, then you have 
the drop counters.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca