[c-nsp] QoS on Multilink T1's.

[Lee Starnes]

Hi Joseph,

We has similar issues and had to make a change to the ML interface. Try
adding ppp multilink fradment disable.

-Lee

On Fri, Mar 23, 2012 at 11:38 AM, Joseph Mays <mays at win.net> wrote:

> We have the following service policy on a router that priorities VOIP
> traffic according to the ef tag.
>
> class-map match-all dscp-ef
>  match ip dscp ef
> !
> !
> policy-map queue-on-dscp
> description Prioritizes voice traffic first, signalling next.
>  class dscp-ef
>  priority percent 75
>  class class-default
>  fair-queue
>  random-detect dscp-based
>
> The router primarily contains traffic for T1's routed to several
> destinations.
>
> I can demonstrate that for individual T1's the service policy does as it
> should. Throw normal pings at the remote end, things are low latency and no
> packet loss. Ping flood the remote end with 1500 byte packets and latency
> for normal pings and packet loss go sky high. While still pingflooding,
> pings tagged with DSCP ef still have low latency and no packet loss. This
> is all the way it should be.
>
> However, it generally doesn't work for the multilink client on the box. In
> this case, while ping flooding, packets with and without the EF tag set all
> suffer the same high latency and packet loss during ping flood. Not
> surprisingly, this one client is also having VOIP call quality problems.
> All the clients are using the same service policy. I have been assuming
> that it's something about the fact that this client has two multilink T1's
> bonded together with multilink PPP and other clients just have a single T1.
>
> Is there somethings special that has to done for QoS over multilink PPP?
> Or is there possibly some other thing affecting this one client? There are
> no specific access lists relating to their connection, nor to the ones that
> work. Really, the only thing overt that sets them different from the others
> is that they have bonded T1's, as shown below.
>
> interface Multilink117870
> description Bonded Pair to Edge Outreach
> bandwidth 3072
> ip address 216.24.2.145 255.255.255.252
> no cdp enable
> ppp authorization PermT1
> ppp multilink
> ppp multilink group 117870
> service-policy output queue-on-dscp
>
> interface Serial6/0/1:0
> description Edge Outreach (K1.HCFU.511024..SC)
> bandwidth 1536
> no ip address
> no ip redirects
> no ip proxy-arp
> encapsulation ppp
> ppp authorization PermT1
> ppp multilink
> ppp multilink group 117870
> !
> interface Serial6/0/2:0
> description Edge Outreach (K1.HCFU.511025..SC)
> bandwidth 1536
> no ip address
> no ip redirects
> no ip proxy-arp
> encapsulation ppp
> ppp authorization PermT1
> ppp multilink
> ppp multilink group 117870
>
> Here is an example of a plain single T1 client config, in which case the
> QoS service policy works exactly as it should.
>
> interface Serial6/0/3:0
> description Leonard Brush (K1.HCFU.511093..SC)
> bandwidth 1536
> ip address 216.24.0.53 255.255.255.252
> no ip redirects
> no ip proxy-arp
> encapsulation ppp
> ppp authorization PermT1
> service-policy output queue-on-dscp
>
> ______________________________**_________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/**mailman/listinfo/cisco-nsp<https://puck.nether.net/mailman/listinfo/cisco-nsp>
> archive at http://puck.nether.net/**pipermail/cisco-nsp/<http://puck.nether.net/pipermail/cisco-nsp/>
>