[c-nsp] Question about NAT Rate Limiting
Rodney Dunn
rodunn at cisco.com
Mon Nov 29 13:11:19 EST 2004
Chuck,
I passed this on to the folks that handle the
auto-secure stuff.
Rodney
On Wed, Nov 17, 2004 at 08:43:32AM -0500, Rodney Dunn wrote:
> 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/
> _______________________________________________
> 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