[c-nsp] Question about NAT Rate Limiting
Mike Byrne
cisco-nsp at spam.turbolink.net
Tue Nov 16 12:35:06 EST 2004
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
More information about the cisco-nsp
mailing list