[c-nsp] Question about NAT Rate Limiting
Brian Feeny
signal at shreve.net
Tue Nov 16 11:20:58 EST 2004
Rodney,
Ok thanks, I will wait for the "all-hosts" option and use that.
Brian
On Nov 16, 2004, at 10:05 AM, Rodney Dunn wrote:
> The way I read the docs for that is it's either per host or per ACL.
>
> Setting NAT Rate Limits for Access Control Lists: Example
>
> The following example shows how to limit the access control list named
> "vrf3" to 100 NAT entries:
> Router(config)# ip nat translation max-entries list vrf3 100
>
> would mean for ACL number X you allow it to have Y translations.
> That would mean 1 ip with Y or Z ip's inside the subnet with Y for
> a total of 100 max.
>
> The host option is just a simple way of saying the same thing for
> a /32 ACL match.
>
> The CSCec16330 give you a global option to specify a per host max.
>
>
> If you can't identify the user all the time based on a static
> IP then the only thing you can do is limit "per ACL".
>
> You don't have a per-host option without CSCec16330.
>
> ip nat translation max-entries host is really just an ACL match
> with a /32 ACL applied.
>
> Rodney
>
>
>> Brian
>>
>>
>> On Nov 16, 2004, at 9:18 AM, Rodney Dunn wrote:
>>
>>> On Tue, Nov 16, 2004 at 08:34:21AM -0600, Brian Feeny wrote:
>>>>
>>>> Rodney,
>>>>
>>>> Yes "all-host" would do what I want. I assume this feature is
>>>> working.
>>>> Do you know, if the limit is reached, what is the behavior, do
>>>> older
>>>> entries get prematurely purged, or does attempts to create new
>>>> entries
>>>> just fail and the user must wait for older entries to time out?
>>>
>>> I just tested it. I set the per host limit to 2 and on the
>>> 3rd telnet through the box with debug ip nat I get:
>>>
>>> 101_#sh ip nat trans
>>> Pro Inside global Inside local Outside local Outside
>>> global
>>> tcp 10.10.10.1:11295 1.1.1.100:11295 4.4.4.103:23
>>> 4.4.4.103:23
>>> tcp 10.10.10.1:56730 1.1.1.100:56730 4.4.4.103:23
>>> 4.4.4.103:23
>>> 101_#
>>> *Nov 16 15:15:09.231: NAT*: s=1.1.1.100->10.10.10.1, d=4.4.4.103 [21]
>>> *Nov 16 15:15:10.391: NAT: administratively-defined entry limit
>>> reached (2)
>>> *Nov 16 15:15:10.403: NAT: administratively-defined entry limit
>>> reached (2)
>>> *Nov 16 15:15:10.403: NAT: translation failed (A), dropping packet
>>> s=1.1.1.100 d=4.4.4.103
>>>
>>>
>>>>
>>>> I have a customer doing NAT for an entire apartment complex on a
>>>> 1700
>>>> (I know, REALLY bad idea). One of these users is running some emule
>>>> type program that feels it needs to scan the entire internet on a
>>>> udp
>>>> port searching for other emule people. Its creating translation
>>>> entries so fast (udp has default timeout of like 5 min) and
>>>> consuming
>>>> the memory (32MB) before they can start to expire.
>>>
>>> Yep. That's exactly what this is supposed to fix.
>>>
>>>>
>>>> I mainly wish to deploy this feature to prevent this user from
>>>> taking
>>>> down the router, and not have to put a global cap on everyone. To
>>>> me,
>>>> this is more a policy problem and not a technical one, but the
>>>> apartment managers aren't dealing with the situation appropriately
>>>> so
>>>> I
>>>> am trying to work up a technical solution.
>>>
>>> I made a mistake below. :( This didn't make it in the code in time
>>> for 12.3(11)T. It went in 12.3(11.1)T so it will be in the next
>>> T release on CCO. If you would like to test this some since I was
>>> involved with the development of this I could probably get you
>>> an image to try. Contact me offline if you are interested in
>>> trying it out.
>>>
>>> Rodney
>>>
>>>
>>>> Brian
>>>>
>>>>
>>>> On Nov 15, 2004, at 9:10 PM, Rodney Dunn wrote:
>>>>
>>>>> I filed a request for this just for this reason:
>>>>>
>>>>> CSCec16330
>>>>> Internally found moderate defect: Resolved (R)
>>>>> Request ability to limit per user NAT entries
>>>>>
>>>>>
>>>>> 12.3(11)T:
>>>>>
>>>>> Router(config)#ip nat translation max-entries ?
>>>>> <1-2147483647> Number of entries
>>>>> all-host Specify maximum number of NAT entries for each
>>>>> host
>>>>> all-vrf Specify maximum number of NAT entries for each
>>>>> vrf
>>>>> host Specify per-host NAT entry limit
>>>>> list Specify access list based NAT entry limit
>>>>> vrf Specify per-VRF NAT entry limit
>>>>>
>>>>> Router(config)#ip nat translation max-entries all-host ?
>>>>> <1-2147483647> Number of entries
>>>>>
>>>>> Router(config)#ip nat translation max-entries all-host 20
>>>>>
>>>>> I'm not sure why the doc's didn't get updated to reflect
>>>>> this. I will check on that.
>>>>>
>>>>> I just filed yesterday:
>>>>>
>>>>> CSCsa42809
>>>>> Internally found enhancement defect: Assigned (A)
>>>>> Ability to limit per user NAT entries (CSCec16330) should be VRF
>>>>> aware
>>>>>
>>>>> Does CSCec16330 do what you are asking for with the all-host
>>>>> option?
>>>>>
>>>>> Rodney
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Nov 15, 2004 at 08:25:47PM -0600, Brian Feeny wrote:
>>>>>> I have a question regarding the NAT rate limiting in 12.3:
>>>>>>
>>>>>> http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/
>>>>>> products_feature_guide09186a00801d09f0.html#1027258
>>>>>>
>>>>>> I understand you can globally limit the number of NAT
>>>>>> translations:
>>>>>>
>>>>>> ip nat translation max-entries 300
>>>>>>
>>>>>> or you can limit a single host
>>>>>>
>>>>>> ip nat translation max-entries host 127.0.0.1 300
>>>>>>
>>>>>> can you use the ACL functionality to set a maximum amount of
>>>>>> entries
>>>>>> on
>>>>>> a per host level? For example:
>>>>>>
>>>>>> ip nat translation max-entries list perHost 100
>>>>>> ip access-list extended perHost
>>>>>> permit ip 192.168.1.0 0.0.0.255 any
>>>>>>
>>>>>> would the above make it so that each host in 192.168.1.0 had its
>>>>>> own
>>>>>> max-entries of 100, or would that be shared across all hosts in
>>>>>> the
>>>>>> ACL? I am trying to look for a way so that each host has its own
>>>>>> "max-entries" without having to set a bunch of lines specifically
>>>>>> setting it for each host.
>>>>>>
>>>>>> Brian
>>>>>>
>>>>>> ---------------------------------------------
>>>>>> Brian Feeny, CCIE #8036, CISSP
>>>>>> Network Engineer
>>>>>> ShreveNet Inc.
>>>>>
>>>>>
>>>>>
>>>>>> _______________________________________________
>>>>>> cisco-nsp mailing list cisco-nsp at puck.nether.net
>>>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>>>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>>>>
>>>> ---------------------------------------------
>>>> Brian Feeny, CCIE #8036, CISSP
>>>> Network Engineer
>>>> ShreveNet Inc.
>>>>
>>>
>>>
>>> _______________________________________________
>>> cisco-nsp mailing list cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>
>> ----------------------------------------------------------------------
>> --
>> ------
>> Brian Feeny, CCIE #8036, CISSP e: signal at shreve.net
>> Network Engineer p: 318.213.4709
>> ShreveNet Inc. f: 318.221.6612
>>
>
>
>
------------------------------------------------------------------------
------
Brian Feeny, CCIE #8036, CISSP e: signal at shreve.net
Network Engineer p: 318.213.4709
ShreveNet Inc. f: 318.221.6612
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : https://puck.nether.net/pipermail/cisco-nsp/attachments/20041116/2e8f2b46/PGP.bin
More information about the cisco-nsp
mailing list