hi i am trying to implement a simple CBWFQ on cisco 3600 and the bandwidth allocation does not work, the 2 sources i use to generate udp traffic towards one source get eaqual share of the bandwidht, the policy maps fail i guess but i think there is nuthin wrong with it ... im pasting the config. below please let me know if somthin is wrong
class-map match-all u4p5041
match access-group 143
class-map match-all u3p5031
match access-group 133
access-list 143 permit udp host 192.168.4.100 host 192.168.1.100 eq 5041
access-list 143 deny udp any any
access-list 133 permit udp host 192.168.3.100 host 192.168.1.100 eq 5031
access-list 133 deny udp any any
Your QoS looks fine. Traffic sent to port 5041 will get 6m and traffic going to port 5031 will get 1.5m.
Now this is not a limit. If you are running this QoS on a fast ethernet port and the port is not running at 100% then both traffic streams can have all they want.
The only time QoS has a effect is when the interface is queueud. If you have no queue all traffic will be sent as soon as it gets to the interface and all QoS that does not police traffic will be ignored.
When you get line congestion then you should see a differnce.
I have changed the speed of the output fast ethernet tp 10 Mb and the source interfaces are on 100Mb each and i am generating more than 10 Mb of data on each input interface, so a 20Mb of data arrives at the 10mb output interface so queing is there, btw the bandwdht command of 6000 doesnt mean the weight which is assigned to that class its 6 mb served out of that 10Mb interface.. correct me if im wrong
If you set it to 10m and send in 20m of traffic you will get a 80/20 split assuimg there is no other traffic.
Your first stream should get 6m and the second 1.5.
Now if there is no other traffic the remaining 2.5 will be split with the same ratio. You should end up with 8m and 2m for your streams.
If it does not split this way then something else is wrong. I have seen issues in the past were you had to shape the traffic to the interface speed when dealing with ethernet interfaces. I thought that you didn't have to do that anymore. You can test it by building a parent class that matches all traffic and shape it to 10m and then apply you current policy as a child class to this new shaping policy.
i think thats a good idea, but im analysin the traffic delays and losses .. shaping it would never give the correct reads, my scenario is a couple of pc's generating tcp traffic and some generating udp, when i do it udp takes all and tcp get down to 0, this mean the schedular is not working correctly but if i police it ... the traffic is not allowed above a certain specified bandwidth, do u think a problem with the router is causing this coz my config. is quite simple and it works with other things not this one perhaps, do i need some sort of load balancing and im not runnin a routing protocol on this router. and yes the traffic is bottlenecked
What does "show policy-map interface" show? Are packets correctly classified per class? If there is no output for this command, then you have not attached the servic policy to the interface.
What is the total bandwidth of the interface, and are you congesting that interface? Queuing will occur when the interface is congested. At that time the classes should get their minimum bandwidth guarantee. Any excess available bandwidth will be alocated proportional to the size of the class bandwidth.
Hope something from this helps.
the interface is conjested, the packets are classified correclty because the POLICING works, but i need to get the schedular working which is not, please check my attachment its the config file.
the total bandwidth of the interface is 10 mb .. i am congesting it with udp and tcp traffic .. at times all udp at times a mixture of both.... when its all udp they get equal bandwidth .. and incase when tcp is introduced it gets no bandwidht naturally because of it backs up to 0... all the sources generate more that 10 mb of traffic... even if i have to sources the interface gets congested... do i need load balancing,,, or a routing protocol
This sounds more and more like a bug. It should work exactly as you describe and not split it equally. Unless there is some limitation on UDP but I have not seen it in the documentation.
Your test case is clear enough that TAC should be able to reproduce it.
You may want to try what tac is going to tell you to do anyway and load newer code even though I do not see anything in bugtrac.
TAC is cisco's support department.
You need a contract for service on your router. If you do not have a contract I do not know if they will help at all. The only software patches they give for free are the ones related to major security bugs. Maybe you can get one of those. I have never tried to call a router problem in without a contract so maybe they have a pay per call option but I don't know.
I can see nothing wrong with your configuration and I have done similar things many times just not with UDP. The documentation is very clear on how this is to work and it does not appear to be working that way. This is either a bug or a restriction that is documented someplace I have not seen yet.