[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