[afnog] QoS setting verification

[Antonio Godinho]

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?

Cheers,

AG

On Thu, 20 Jul 2006 20:59:01 +0200, Kayihura M. Eddy wrote
> Thanks Brian for your input.
> Yes the HSSI is the bottleneck and we have also some QoS setting on the
> Remote router.
> I thought there could be some tools to test that but as you said I could
> just do a test by filling the pipe and see if the special IP have priority.
> 
> Regards,
> 
> Eddy K.
> 
> -----Original Message-----
> From: Brian Candler [mailto:B.Candler at pobox.com] 
> Sent: Thursday, July 20, 2006 4:08 PM
> To: Kayihura M. Eddy
> Cc: afnog at afnog.org
> Subject: Re: [afnog] QoS setting verification
> 
> On Wed, Jul 19, 2006 at 03:51:39PM +0200, Kayihura M. Eddy wrote:
> >    interface Hssi2/0
> ...
> >     service-policy output VoIP_policy
> 
> So, presumably, the link coming out of Hssi2/0 is the bottleneck in your
> network. If it isn't, then applying traffic prioritisation here 
> won't be useful.
> 
> Also, you must be aware that this will only affect traffic in 
the "outbound"
> direction:
> 
>                          congested
>            local           link            remote
>   ---------- R ============================== R -----------
>                hssi2/0
>            ------>
>          policy works
>          for this traffic
> 
> If your link is filling in the inbound direction, then you'd need 
> someone to make a corresponding change on the remote router.
> 
> As for testing this: I would tend to go for the simple and direct approach.
> 
> (1) Fill up the link in the outbound direction. For example, FTP 
> outbound a very large file from a machine on your local LAN to some 
> remote machine
> (preferably not too far from remote router R, so that other links 
> are not bottlenecks). If necessary, run several FTP sessions concurrently.
> 
> (2) Now start up another session which matches your priority policy -
>  in this case just set up an FTP client on one of the special IP 
> addresses, and send outbound data from that.
> 
> Since you're doing simple prioritisation, you should find that the
> privileged traffic fills up the pipe, and starves out the non-privileged
> traffic. It won't starve it out to zero, because there will always 
> be gaps it can fit into, but it should be drastically reduced.
> 
> If all the test devices are plugged into a managed switch, then 
> graphing the bandwidth in and out of all the switch ports is a good 
> way to visualise this.
> 
> >    access-list 131 permit ip A.B.C.D 0.0.0.31 any
> > 
> >    access-list 131 permit ip any host A.B.C.E
> > 
> >    access-list 131 permit ip any host A.B.C.F
> > 
> >    access-list 131 permit ip any host A.B.C.M
> 
> Note that this matches traffic from the A.B.C.D subnet to anywhere, and
> traffic from anywhere to addresses A.B.C.E/F/M. That is, it only 
> makes sense if addresses A.B.C.E/F/M are on the far side of the 
> remote router R.
> 
> Regards,
> 
> Brian.
> 
> _______________________________________________
> afnog mailing list


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