I'm looking to restrict a particular service/IP's (matched by ACL) to a specified chunk of bandwidth.
I've found before that police will do this, but only partially. I think I found that police will hold an ACL matched service to it's max bandwidth, but then it will either drop the packets that are over the limit or dish them off to the fair-queue.
I'd like to restrict the ACL matched service to it's specified max bandwidth, and for anytyhing over that it will keep it in its own queue till the bandwidth free's up on it's policy and then pass the packets.
I think the closest thing to what you want is to use traffic shaping rather than policing. Have a look at this document which explains the difference between the two. Please come back if you have further questions.
The options for exceed-action and violate-action do not keep the packets in their respected queue. It reassigns a precidence, QoS group, or dscp value. Even if I set it to the lowest presidense or least important dscp value, it still gets dished into the first in/first out queue and it utilizes the bandwidth just the same.
Traffic-shapping only applies to the interface, which would be the entire set of bandwidth I have. I don't want to mess with the QoS I already have setup for our time sensitive info, I just don't want this traffic that's matched by ACL to cut into the time sensitive traffic in anyway. The ACL matched info needs to remain in it's own queue no matter what.
I'm thinking I may need another interface connected to it's own private data link, then use policy-based routing and just seperate it based on service/source/destination.
What you're describing might be accomplished with CBWFQ.
You can define a class to have a minimum amount of bandwidth when there's congestion from other traffic, but the class will use excess available bandwidth. If the minimum provides less bandwidth than the class is attempting to use, it will queue within that class.
match protocol ftp
bandwidth percentage 50 (can also use absolute values)
If ftp wants 25% of the T1, it shouldn't queue. If ftp want 50% of the T1, it also shouldn't queue.
If ftp wants 75% of the T1, and the additional 25% is available, it shouldn't queue. If there is no excess available, the extra 25% ftp should queue. If there is some excess available, is will obtain some, and will queue what it couldn't obtain.
You can also define the queue allocation for the ftp class and whether WRED should be used for drop management.
what about this crazy idea.. if it's possible. Creating a third subinterface (already have two) and configuring it with the traffic-shape? it'd still hit the default route for outbound..
here's my config, do you thinka third interface would work for this? say, some 192.168 address and just use ACL's to match the source and route it to the 192.168 interface... Possible? (in the config below, our data network is the 10. and the voice is th 172 - the replications data is coming from a 10.10.1.x address)
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...