[BEHAVE] Major NAT MIB Issue: Notifications and processor requirements at the agent
Tom Taylor <tom.taylor.stds@gmail.com> Sun, 26 October 2014 22:35 UTC
Return-Path: <tom.taylor.stds@gmail.com>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1140A1A1AE6; Sun, 26 Oct 2014 15:35:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level:
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lK2Fbg36-Szw; Sun, 26 Oct 2014 15:35:34 -0700 (PDT)
Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E545C1A1AE4; Sun, 26 Oct 2014 15:35:33 -0700 (PDT)
Received: by mail-ig0-f173.google.com with SMTP id r10so2932166igi.0 for <multiple recipients>; Sun, 26 Oct 2014 15:35:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=kj90dUtiPB1r1kjo4ZnVblzJUOzw/bPfzdmoOd3KbO4=; b=BBdr7ULXiWVYl0AFt99PwhZ6tdZSlV8efAqedFt1FIXvJFjbCqHw1cviwCQeCorbyy A4ndL1rxoDo+S0wGVYYy6zU4aqIq0bnIN/2fXDJsbgEn4leRMqYwRXZlCV2oFRdnQnt+ OIJDoyFskI00HvxGSn/GbM9E2qLwWkVURoTJRoUCO9M+xKB31MYT/iqGu9h7pEr5+ukL a0diadzUGcjtf5OgPRUy//k6ACY6n2p6rWrLfuIFtViFs3ZVqoLVqGFHa1vMLKEyM+M8 6KUKLdfKaTyAXFqSaku94mw1fIqTX+4kAj2wbBSDFfQpOUp4O3D4mYFjSICwJAscDUVA 5olA==
X-Received: by 10.107.167.66 with SMTP id q63mr18529929ioe.23.1414362933285; Sun, 26 Oct 2014 15:35:33 -0700 (PDT)
Received: from [192.168.0.102] ([216.254.166.33]) by mx.google.com with ESMTPSA id 8sm4117046igy.0.2014.10.26.15.35.32 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 Oct 2014 15:35:33 -0700 (PDT)
Message-ID: <544D772F.6060009@gmail.com>
Date: Sun, 26 Oct 2014 18:35:27 -0400
From: Tom Taylor <tom.taylor.stds@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "behave@ietf.org" <behave@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/behave/oNBYFax211LZ8gKv-l6HfX-CZo4
Subject: [BEHAVE] Major NAT MIB Issue: Notifications and processor requirements at the agent
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave/>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Oct 2014 22:35:36 -0000
A little terminology to start with: 1) A realm defines an addressing space. Simple NATs may support just two realms: internal and external. This is all that RFC 4008 supports. In more complex situations the NAT will support several or many realms. Individual realms in that case can be internal from the point of view of some hosts served by the NAT and external from the point of view of others. 2) An address mapping is an assignment of an address in a selected external realm to the address of a host in its internal realm. 3) An address and port mapping is a mapping between the address and port of a host in its internal realm for a given protocol to an address and port in a selected external realm. For mappings triggered by packets outgoing from the internal host, the external realm is selected based on the packet destination. For mappings triggered by packets incoming from an external realm, the external realm is the one from which the packet originated. 4) An address pool is a separately-managed set of addresses and ports/ICMP identifiers in a particular realm, available for assignment to the 'external' portion of a mapping. Pools can be used to ration the available external addresses to different realms and classes of subscribers. Where more than one pool has been assigned to the realm, policy determines which subscribers and/or services are mapped to which pool. The NAT MIB (draft-ietf-behave-nat-mib-11) currently has five notifications, which can be enabled and disabled through their respective threshold settings: - Address pool low threshold undershot -- reports under-utilization of an address pool - Address pool high threshold exceeded -- reports potential over-utilization of an address pool - Address mapping threshold exceeded -- reports potential exhaustion of addresses for the NAT instance as a whole - Address and port mapping threshold exceeded -- reports potential exhaustion of address plus port combinations for the NAT instance as a whole - Per-subscriber address and port mapping threshold exceeded -- can be used for troubleshooting (enabled for specific subscriber) or provisioning (enabled for all subscribers) Just as a preliminary, my personal view is that the notification relating to low pool utilization should not be there, and if the information is needed, it should be handled by the management application. Hence this one should be omitted from the discussion which follows. David Harrington in his review was concerned that these notifications involved calculations at the agent that were excessively demanding of processor capacity. This is especially true of the MIB's current algorithm for address pool utilization. More on that in a moment. Just for background, the MIB supports the following read-write hard limits, beyond which incoming packets are dropped rather than translated: - Maximum number of active address mappings - Maximum number of active address and port mappings - Maximum number of fragments awaiting reassembly - Maximum number of subscribers with active address and port mappings The resources that need monitoring in the NAT are NAT memory, address pool utilization, and processor capacity. The only item in the above list of notifications and limits that at least partially addresses processor capacity is the last limit, on number of active subscribers. Possibly, a notification and limit could be introduced based on the rate of change of the number of active mappings. The problem with NAT pool monitoring is that the pool actually contains two resources, addresses and ports, and how they get used up depends on RFC 4787 pooling behaviour. For the RECOMMENDED pooling behaviour of 'paired', port exhaustion occurs when all the ports for the desired protocol available to the subscriber on a mapped external address are used up, the NAT cannot (for reasons of policy or availability) assign additional ports to that subscriber on that same address, and the NAT cannot assign an additional address containing free ports to that subscriber. (This last condition is subject to discussion: is it port exhaustion or address exhaustion?) For a pooling behaviour of 'arbitrary', port exhaustion occurs when there is no available port for the desired protocol at any of the addresses in the pool. Clearly port exhaustion will be a rarer event in the 'arbitrary' case. draft-ietf-behave-nat-mib-11 triggers notifications based on the ratio of active address and port mappings using a given pool to the total number of address-port combinations made available by the pool, expressed as a percentage. As David Harrington pointed out, this makes a lot of demands on the agent processor. We have some alternatives: 1) No notification: leave any processing to the management application. 2) Trigger the high usage notification based on the rate of occurrence of out-of-port events, with the same threshold value for all pools. This is reasonably valid statistically for a low threshold (i.e., taking the view that any port exhaustion at all is actionable), but not terribly reliable in the 'paired' case, in that a single subscriber can dominate the results. 3) Trigger the high usage notification based on the rate of occurrence of out-of-port events, with a higher threshold value based on pool size (addresses x ports) and sharing ratio. This requires some mathematical analysis and per-pool configuration. What do people recommend? Tom Taylor
- [BEHAVE] Major NAT MIB Issue: Notifications and p… Tom Taylor
- Re: [BEHAVE] [OPSAWG] Major NAT MIB Issue: Notifi… Simon Perreault
- [BEHAVE] Out of port errors, resource errors in N… Tom Taylor
- Re: [BEHAVE] Out of port errors, resource errors … Simon Perreault
- Re: [BEHAVE] Out of port errors, resource errors … JF Tremblay
- Re: [BEHAVE] [OPSAWG] Out of port errors, resourc… Tom Taylor
- Re: [BEHAVE] [OPSAWG] Out of port errors, resourc… JF Tremblay
- Re: [BEHAVE] [OPSAWG] Out of port errors, resourc… Tom Taylor
- Re: [BEHAVE] [OPSAWG] Major NAT MIB Issue: Notifi… Randy Presuhn
- Re: [BEHAVE] [OPSAWG] Major NAT MIB Issue: Notifi… Tom Taylor