cisco 871 with fifo interface(without fair queue)

[diegino]

hello everybody,
I'm having a problem with how my cisco is managing the congestions. It is configured with fifo and it has a traffic-shape but it is discarding packets of some flows and it doesn't discard a single packet of one specific flow that is consuming less bandwith. So, my question is:Using fifo,Does the router treats all packet in the same way?

 

[unclerico]

FIFO is first in first out so traffic is forwarded out as it is received. Fair Queue would give higher priority to the less aggressive flows.

I hate all Uppercase... I don't want my groups to seem angry at me all the time! =)
- ColdFlame (vbscript forum)

 

[diegino]

Well, i understand the theory like you do but it isn't the way it's working on my network. I've a cross traffic of video generated with vlc and another traffic(with the same packet size of video but sent to another port) is controlled by me. This last traffic is captured in another machine and i verify that no packets are lost. However,in the cisco interface (that has a traffic-shape on it) there is thousands of packet drops, so must corresponds only to video traffic.
I repeat this many times and is always the same result.Would you have any idea why is happening?
thanks for reply!

 

[Quadratic]

Can you post the interface config, and anything else relevant to the traffic shapping setup? If it's only shaping one traffic type, for example, then that could explain the drops. FIFO as a queuing solution doesn't care about one flow over the other, so it's something else.

Also, video traffic is bursty by nature. It's possible that periods of congestion are occurring during a burst of video traffic, thus that is what ends up getting dropped moreso than other traffic flows.

Any real-time traffic needs to be prioritized. Especially since you're saying it's congested, you shouldn't be using FIFO over a converged video/data link. Consider CBWFQ or even LLQ to prioritize video and give it some bandwidth guarantees.

CCNP, CCDP

 

[diegino]

Ok,thanks for the reply. I'm uploading the router configuration.

In the other hand, I tell you that I'm trying to test how video traffic is affected when the link is congested.

So, I send real video traffic that is almost saturating the link and then I also send a capture of video that i refer as "my traffic"( isn't real video traffic but it is a simulation of video,with the same packet size and time between packets,therefore bitrate).

In the other side of the wan interface i have a computer that is receiving "my traffic", so with sequence numbers and time stamps i can tell what delay,jitter and loss is affecting "my traffic".

What I'm trying to say is that I don't want to prioritized any of the traffic in my link, I'm looking for the exact opposite:that any traffic(the real video and "my traffic") is treated as equal and buffered in the same way so i can see the results on "my traffic".And I'm seeing that there are thousands of drops on the interface but none on "my traffic".
Do i explain better what is my situation? Any ideas?

 

[Quadratic]

I think the config file will clear a lot of this up. If the main video traffic is getting drops while the secondary traffic isn't (assuming that has been proven), then I'm thinking the traffic shaper you speak of may be shaping the video traffic down to, say, 10% of link bandwidth, while the secondary traffic is unassociated with the shaping policy and gets the full bandwidth of the interface.

If the queuing strategy in place is FIFO, and the only other QoS mechanism in play is a shaping policy, then any per-flow discrimination taking place between otherwise-identical frames has got to be due to that policy.

CCNP, CCDP

 

[Quadratic]

Sorry, just noticed you uploaded the file.

From it, that shaper won't discriminate between flows. If it is true that drops are only occuring on video traffic and not test traffic, then either something's wrong with the test or there's something else in the line of path causing the drops.

Is the secondary traffic TCP-based? You mention sequencing and timestamps, so are you absolutely certain that none of it is dropped and resent? Also, what specifically shows up in "show interface fa4"?

CCNP, CCDP

 

[diegino]

My test traffic isn't tcp-based. It is udp traffic with the sequence number and timestamps in the payload of each packet.
So, with that information I know if there is a drop of my traffic or there isn't, and I can tell you there are no drops and no resents can occur because it is udp traffic.
I'm posting a print screen of my "show int fasteth4" if it helps.
Another weird thing that print screen is that I never see any packet in the output queue(I mean is always 0/4000), why do you think this is happening?
Well,thanks again for helping me out