[afnog] QoS setting verification

[Kayihura M. Eddy]

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.