[c-nsp] Question about NAT Rate Limiting
Rodney Dunn
rodunn at cisco.com
Wed Nov 17 08:43:32 EST 2004
On Tue, Nov 16, 2004 at 08:42:35PM -0600, Church, Chuck wrote:
> 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...
>
Yep. That's exactly why I filed it.
That's a good idea about making it part of the "auto-secure"
feature. I will follow up with them.
That's the part that makes it difficult. There are lots
of times we would like to change defaults to help customers
that don't know any better have their boxes be more robust.
But every time you do that there are just as many customers
fussing because a default changed. And then deciding what
to make the default is even more challenging.
I guess the mindset should have been years ago for features
like NAT to make it a required part of the configuration
to specify how many translations per host would be allowed
and until that was configured NAT wouldn't work at all.
But then people would just say "allow all" and you have the
same problem again.
My point is changing defaults is not as easy as it appears
on the surface.
At least with "auto-secure" a user is knowingly making
a change and they should read about what that change
does.
I'll let you know what I find out.
Rodney
>
> 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
>
>
> _______________________________________________
> 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/
More information about the cisco-nsp
mailing list