Access-list question

itdaddyitdaddy Member Posts: 2,089 ■■■■□□□□□□
access-list 101 permit ip host 192.168.1.94 host 192.168.2.7 
!
interface FastEthernet0/0
 rate-limit input access-group 101 1536000 24000 24000 
conform-action transmit exceed-action drop


Okay I have a server on the inside of a gateway router that connects to our other WAN gateways. I want to limit traffic destinted to 192.168.2.7 and sourced from 192.168.1.94.

But I do not want to shut off all traffic down to this speed. And I do not want others accessing the 192.168.1.94 from accross the WAN to be limited to the speed I am setting which is 1.5 MBPS right?


I only want to limit the speed of NFS traffic sourced from 192.168.1.94 to a destination address that is accross the WAN at 192.168.2.7 and I am using ip which would be all trarffic to make it somewhat simpilar but you guys get this?

It is simple right using this. I just need to be able to throttle the traffic to this destination ip (192.168.2.7) from the source ip (192.168.1.94) and throttle how much it is feeding the 2.7 server.

The NFS traffic is sucking the bandwitdth dry here? so what you guys think any tips for me?
I just do not wan to lay down a command and find out that I am throttle the entire LAN into the WAN. I only want to throttle the 192.168.1.94 from flowing to the 192.168.2.7 cache server. The NFS traffic just hammers the WAN pipe to nothing left for anyone to use who is accross the WAN...thanks guys.icon_cheers.gif

Comments

  • cisco_troopercisco_trooper Member Posts: 1,441 ■■■■□□□□□□
    What model router? and what type of interface is that? Is that an actual WAN interface? I don't want to make any assumptions because WAN ethernet interfaces and LAN ethernet interfaces can have very different features.
  • itdaddyitdaddy Member Posts: 2,089 ■■■■□□□□□□
    FourthAveGateway1#sh ver
    Cisco IOS Software, 2800 Software (C2800NM-IPBASE-M), Version 12.3(14)T7, RELEASE SOFTWARE (fc2)
    Technical Support: Support and Documentation - Cisco Systems
    Copyright (c) 1986-2006 by Cisco Systems, Inc.
    Compiled Wed 22-Mar-06 18:40 by pwade

    I want it to be the WAN interface but ingress to it from the Source LAN ip 192.168.1.94 that is what a CCIE told me...but I do not want to limit everything else..thanks man

    I saw some cool QOs techniques but I am not even close to learning that yet.
    but man i cannot wait to understand policy better ;)
  • cisco_troopercisco_trooper Member Posts: 1,441 ■■■■□□□□□□
    Looks like it is in fact an actual WAN interface. Very good.

    I believe what you have there will work IF I understand everything you are saying correctly. But, I would recommend another solution using a policy map applied to the egress WAN interface. Provide a bandwidth guarantee to your other traffic and let this NFS traffic have the scraps. You will protect your other traffic this way, and the NFS traffic will be able to move faster if the WAN is under low utilization rather than being set at a hard cap of 1.5mbps.
  • itdaddyitdaddy Member Posts: 2,089 ■■■■□□□□□□
    so I should set the policy to give a percentage ? and if no traffic use all of it? kind of thing.
    do you have any references for me to look at? and test.
  • Forsaken_GAForsaken_GA Member Posts: 4,024
    itdaddy wrote: »
    so I should set the policy to give a percentage ? and if no traffic use all of it? kind of thing.
    do you have any references for me to look at? and test.

    Is the WAN link actually 100 megs up to the provider? It's a FastEthernet interface, so if the link up to the provider is limited to something like 20 megs, then a policy map isn't going to work - the QoS bandwidth reservations don't kick in until there's saturation on the link. If you try and setup a CBWFQ policy on a 100 meg interface that's being rate limited on the far end to something less, you're going to find your policy has no effect.

    If you want references, pickup the Odom QoS book. This is not something you want to go messing around with unless you understand what you're doing. Badly implementing QoS policies is one of the quickest ways to invoke the Law of Unintended Consequences.
  • cisco_troopercisco_trooper Member Posts: 1,441 ■■■■□□□□□□
    That is a very good point. My next question was going to be how much bandwidth but I was going to spit out a policy map ignoring the hardware. Lesson learned. Thanks Forsaken.
  • Forsaken_GAForsaken_GA Member Posts: 4,024
    What model router? and what type of interface is that? Is that an actual WAN interface? I don't want to make any assumptions because WAN ethernet interfaces and LAN ethernet interfaces can have very different features.

    I don't think that's a WAN interface. From his config, and from his wording, it looks like the .94 address is ingressing to that interface and the 2.7 is out on the other side of the WAN, so if I'm understanding it right, the interface he's dealing with is LAN facing.

    If so, his rate-limit command should work without effecting any other traffic. That's the solution I'd take, because it has the least effect on the rest of the network and accomplishes his goal. Fiddling with policy on whatever interface actually is the WAN facing egress interface has potential to break a whole lot more stuff
  • cisco_troopercisco_trooper Member Posts: 1,441 ■■■■□□□□□□
    Right. What I meant by WAN interface was more in reference to the type of hardware and I should have been more specific. The only thing I was really after in asking that question was being able to determine the QoS tools supported by the interface. I agree this interface in facing the LAN and the rate-limit should work. I was hoping to come up with something a little more robust so that the traffic wasn't limited even if there is nothing else going across the WAN. I'd hate to see this screw up a backup script that runs while no one is in the office, or something like that.
  • itdaddyitdaddy Member Posts: 2,089 ■■■■□□□□□□
    Forsaken GA you are on the money yes it is on the LAN side ingress into the gateway that leads to the wan
    just wanted ot make sure it wont poor bad JU JU! on me ;)
  • Forsaken_GAForsaken_GA Member Posts: 4,024
    itdaddy wrote: »
    Forsaken GA you are on the money yes it is on the LAN side ingress into the gateway that leads to the wan
    just wanted ot make sure it wont poor bad JU JU! on me ;)

    Well, worst case scenario is that you rate limit the entire LAN and have to pull the config. If you've got NetFlow setup, just keep an eye on it and see if the traffic drops to that one pair as intended, or if it drops across the board, you'd know within 5 to 10 minutes pretty quickly if it worked or not.
  • itdaddyitdaddy Member Posts: 2,089 ■■■■□□□□□□
    Guys it is working wowoowwowowow I have a band graph and I can see it is squashing the graphing but taking alittle longer yeah!!!!!!!!!!!! not blocking any traffice just slow the traffic to the destination 2.7 yeah!!!!!!!!!!!!! awesome thank you so much and so do 30 employees hahaaa ;) you guys rockicon_study.gif
  • LizanoLizano Member Posts: 230 ■■■□□□□□□□
    Glad to see it worked, I was late to the thread but if you your interested I have an excel sheet that automatically does the max burst rate values based on the max bandwidth that you want to allow. I got it off of Cisco Learning Network.
  • itdaddyitdaddy Member Posts: 2,089 ■■■■□□□□□□
    I had to adjust the burst rate to extended due to the NFS file transferring caching too much. Once I changed the config to this burst rate min and max it was sweet; only using 1.5MBPS for sure for NFS traffic from the 192.168.1.94 to the 192.168.2.7...totally working. Now the employees at 8th street won't be yelling at me network slow every 30 minutes haaha now I fix that bad boy!Now that to me is network engineering. Total control over the bits and bytes! yeah baby!!!!!!!!!icon_cheers.gif

    rate-limit input access-group 101 1536000 288000 576000 conform-action transmit exceed-action drop
Sign In or Register to comment.