QoS is something that I never had to deal with in a work environment. The only time I ever have to deal with it is on the tests. Makes it something interesting to do. Honestly, though, it really ain't so bad on the routers. Switch QoS is something that is a little different.
Order is important in a policy-map. It applies from the top down. Screw the order up and you can mess up what was intended. A class that matches TCP before a class matching HTTP will never get to the HTTP class.
A lot of tasks for INE and iPexpert (v4) seem to want to try to transfer images from one device to another. Good idea for testing to make sure that HTTP, FTP, ACLs, QoS, etc, is working. Problem is in GNS3, it is hard to do that. I just fire up SLA and run it. May not be the best for some aspects of testing but it works. It won't flood a link but it at least will match HTTP traffic. Commands that I use are
ip sla 1
tcp-connect 155.1.146.1 80
threshold 1000
timeout 1000
frequency 1
ip sla schedule 1 life forever start-time now
To limit the size of the FIFO queues for traffic classes, use the queue-limit command. Starting in 15.2(2)T, the default for this was packets. In other words, a queue-limit 24 would mean that the queue had a size of 24 packets. This command can be used for queue sizes in other queuing methods as seen in a minute.
Turning on WFQ for the class-default class is done through the fair-queue command under that class in the policy map. Once turned on, you can modify the queue sizes with the queue-limit command.
Nested service policies have always gotten me and I don't know why. I can do nested loops in programming. Anyways, say you want to make the overall bandwidth of an interface to be shaped to a specific number and also for the classes to have certain attributes as well. What what you do is create a parent policy that only has class-default as a class, apply the shaping to it, and then use the service-policy command to apply a child policy that has your classes broken out in it. Not really that hard and yet I still screw it up every time. Cisco only allows up to three policy maps to be in a nest. Say you shape with the first one (all traffic), shape even more for the second (TCP traffic), and the third is super specific (HTTP).
As soon as the bandwidth command is given under a class in a policy map, CBWFQ is used. Each bandwidth commands means that that class-map has a FIFO queue attached to it as well. If you configure a bandwidth command under the default class, you turn off fair-queuing. This turns it into a single FIFO queue. If all you have is class-default and you do a bandwidth statement, you have turned the entire interface into a FIFO queue.
If you try to mix bandwidth and bandwidth percent in the same policy-map, it won't work. All units must be the same across all the classes. Didn't do this, but figured that it was was still a good thing to know.
When coming up with a LLQ policy, you need to always remember your Layer 2 overhead. LLQ accounts for that and can screw you up if you forget it.
A task was asking for dropping of packets using random-detect. I figured out how to get it on, but as for actually getting the dropping working, I didn't get that. Solution was to use random-detect precedence, which now makes sense. With random-detect precedence, you tell it what precedence, the minimum and maximum thresholds and the probability. But the question I had was how do you know the precedence to filter on and only get the packets you want? Another portion of this task was to mark all packets of a certain type with IP precedence 2. I took that to mean as they left the interface. They did it as the packets moved in to the ingress interface and then did random-detect on the egress. Sneaky.
CBWFQ has three main drop policies
1) Tail-drop
-- default for user-defined classes
2) Congestive Discard for WFQ
3) Random Early Detection (RED)
To enable random drops on unclassified traffic, the configuration seems to need fair-queue to be enabled in the policy. Do that and then enable random-detect also.
When doing RED with ECN, you may need to enable TCP ECN. Do this with ip tcp ecn. And of course, that command doesn't seem to be available in 7200 Software (C7200-ADVENTERPRISEK9-M), Version 15.2(4)S3. Awesome.
Fun times configuring CIR and Bc values. Bc stands for Burst Committed. CIR is Committed Information Rate. AR is Access Rate (line speed). Tc is Time Committed. Shapers send packets every Tc milliseconds, essentially separating them by Tc time periods. Tc cannot be configured manually on a device but you can use it come up with CIR and Bc. Bc = CIR * (Tc/1000) which means that the Bc is equal to the CIR times the Tc in seconds. The lower the Tc the more the processor will work. There is also Excess Burst (Be) which comes into play. The maximum Be value is equal to the AR minus the CIR all multiplied by the Tc in seconds or maxBe = (AR - CIR) * (Tc/1000).
Single-Rate Three Color Marker (srTCM) is a system that has always boggled my mind. Think I am starting to understand it now. For every 1/CIR milliseconds a token is put into the bucket. The space between those tokens is Ti ms. The size of the bucket is Bc. Excess tokens that are not used are transferred to the excess bucket for size Be. I am thinking that a token is the amount of information that can be send in Tc. So when a packet comes in that is size X, it is checked first against the Bc bucket. If it is less than or equal to the amount of tokens it is marked with the conform action and the Bc bucket is deducted the size of the packet. If it is less than or equal to the Be bucket, then it is marked with the exceed action and the Be bucket is deducted the size of the packet. Finally, it's marked with the violate action if it fails the others.
To account for the sliding window content correctly, it is better to set the policer Bc to the shaper burst size plus the average packet size. This will also give you a little wiggle room.
Two-Rate Three Color Marker (trTCM) uses two different buckets that fill with tokens based on the time intervals configured with Bc and Be. One is for the CIR and the other is for the Peak Information Rate (PIR). There are still three possible outcomes like with srTCM. If the packet is greater than the tokens in the PIR bucket is violates. If the packet is greater than the tokens in the CIR bucket, it exceeds and the PIR bucket is docked the size of the packet. Finally, if the other two are are not met, the packet conforms and the PIR and CIR buckets are docked the size of the packet. Cool. Think I am getting this now.
QoS pre-classify can only be done on tunnel interfaces, virtual templates, and crypto maps. The command is unavailable on any other interface types. It can only be enabled for IP packets as well. This command allows the IOS to apply QoS before the data is encrypted and tunneled. Without this, the interface that has the service-policy applied to it will treat the tunnel as one flow and not respective flows. This command will cause the router to see the header before being put in a tunnel and then use that header for matching class-maps. Class-based traffic shaping doesn't work for DMVPN, so it looks like qos pre-classify is the way to go.
No comments:
Post a Comment