[afnog] QoS setting verification

Antonio Godinho antonio at uem.mz
Fri Jul 21 11:10:39 EAT 2006


Actually the internal  network where PC1 and PC2 and PC3 are there is a 
switch. The router has an access list on the ethernet that will only allow 
certain type of traffic thus cutting off any other disallowed traffic. So 
you may find that PC1 is bombarding the router with traffic since the router 
is the default gateway and the router is trashing all this traffic because 
it is illegal traffic, at this point the voice calls going across the serial 
link also drop although there is no traffic going across the serial link at 
all. Does this action of blocking the incoming traffic at the ethernet port 
affect the performance of the VoIP? because this is what I have concluded 
from my experiments.

Cheers,

AG

On Fri, 21 Jul 2006 08:42:22 +0100, Brian Candler wrote
> On Fri, Jul 21, 2006 at 09:02:28AM +0200, Antonio Godinho wrote:
> > On the subject of QoS, I have setup a serial link between two sites of 
128K 
> > and using 1760 routers. I setup autoQoS for both sides and it seems to 
work 
> > ok, the only problem I have noticed to which I have not found any 
solution 
> > is that when in one of the sites the ethernet interface of the router is 
> > bombarded with traffic, the voice channels drop the calls even though 
there 
> > is no traffic going through the serial link. Any ideas anyone?
> 
> Under what circumstances does the router's ethernet port get 
> bombarded with traffic? Do you mean something like this?
> 
>               hub
>               |||'----------router========>
>          +----'|'----+
>          |     |     |
>         PC1   PC2   PC3
> 
> Clearly, here, if PC1 and PC2 are using up all the available ethernet
> bandwidth, then PC3 will have to fight for bandwidth on the ethernet 
> segment to get to the router (and the router will have to fight for 
> bandwidth when sending data back to PC3). No QoS settings on the 
> router will help here. When the router has multiple packets waiting 
> to go over the ethernet then QoS lets it decide which is the most 
> important packet to send first; but the ethernet port still has to 
> wait until the port is clear before sending.
> 
> Things are much better if the hub is replaced by a switch, because 
> PC1 and PC2 can exchange frames at the same time as PC3 sends frames 
> to the router. However it's still possible for the ethernet port of 
> the router to be 'bombarded with traffic' as you describe it:
> 
> (1) if you have a broadcast storm
> 
> (2) if traffic has to hit the router for legitimate reasons, e.g. 
> because it has to pass through the router but not go down the serial 
> link. Let's imagine your network is divided into two ethernet 
> subnets, where PC4 is on the second subnet, and your router is 
> forwarding traffic between the two subnets as well as to the serial line:
> 
>             switch      *
>               |||'----------router=========>
>          +----'|'----+         |
>          |     |     |         |
>         PC1   PC2   PC3       PC4
> 
> Here, if PC1 is sending at top speed to PC4, the link between the 
> switch and the router (marked *) could be filled; so if PC3 then 
> wants to send traffic via the router to the serial line, it will 
> find that link (*) is congested.
> 
> If this is the case, then you'll need to use a switch with QoS 
> features too
> (and note that it will be doing layer2 forwarding but probably needs 
> to look at layer3 info to decide which priority to choose)
> 
> If you have a multi-switch or multi-router network then this becomes
> difficult to scale, as it gets difficult to deploy all the right ACLs
> everywhere. At this point you should be thinking of ingress marking. 
> That is, each switch or router in the core of your network just 
> looks at the IP TOS bits and/or ethernet 802.1p bits to decide on 
> priority. At the edges where customers or users connect, you use 
> ACLs to categorise the traffic and replace the existing TOS bits in 
> each frame with ones of your choice.
> 
> Regards,
> 
> Brian.


--
Antonio Godinho
B.Sc., MCP+I, MCSE, CCNA, CCNP
CIUEM
Maputo
Mozambique




More information about the afnog mailing list