[c-nsp] Question about NAT Rate Limiting
Church, Chuck
cchurch at netcogov.com
Tue Nov 16 21:42:35 EST 2004
And not just for P2P 'problem users' either. This can probably save many a router from running out of RAM when the next big MS worm gets on an internal PC. Maybe this 'all-host' option might eventually be a default, or at least part of the 'auto-secure' thing in 12.3...
Chuck Church
Lead Design Engineer
CCIE #8776, MCNE, MCSE
Netco Government Services - Design & Implementation Team
1210 N. Parker Rd.
Greenville, SC 29609
Home office: 864-335-9473
Cell: 703-819-3495
cchurch at netcogov.com
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D
-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Brian Feeny
Sent: Tuesday, November 16, 2004 6:42 PM
To: Mike Byrne
Cc: cisco-nsp
Subject: Re: [c-nsp] Question about NAT Rate Limiting
yes static ip would work, but then the next problem user happens, etc.
So its only a temporary fix.
The "all-hosts" option is going to work real nice once thats in release.
Brian
On Nov 16, 2004, at 11:35 AM, Mike Byrne wrote:
>
> On Tue, 16 Nov 2004, Brian Feeny wrote:
>
>> Rodney,
>>
>> Ok thanks, I will wait for the "all-hosts" option and use that.
>>
>> Brian
>
> If you could always identify the 'problem user' by static IP, would the
> following solution work? Say problem user is 192.168.1.100:
>
> access-list 100 deny ip host 192.168.1.100 any
> access-list 100 permit ip 192.168.1.0 0.0.0.255 any
>
> access-list 101 permit ip 192.168.1.100 any
>
> access-lsit 102 permit ip 192.168.1.0 0.0.0.255 any
>
> ip nat translation max-entries list 100 16384 ! some high number to
> prevent the router from exhausting RAM
> ip nat translation max-entries list 101 256 ! much lower limit for
> problem customer
>
> ip nat inside source list 102 interface FastEthernet0/1 overload
>
> - Mike
>
>> 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
>
> _______________________________________________
> 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
More information about the cisco-nsp
mailing list