QOS, Frame - LLQ sucks 2

[JayNEC]

I've implemented QOS over frame-relay (for VOIP) with the standard proceedure several times now. It sucks every time.
LLQ, with LFI, priority queue for VOIP etc everything Cisco recommends for VOIP of Frame-relay. When there's not a really heavy load it's fine of course. When I put a HEAVY load on it, say with UDP Speed Test:

http://www.mycgiserver.com/~skybuck/)

it craps out. With the QOS there, it shouldn't.

With my PPP T1's I can run the UDP speed test and spew tons of UDP as fast as I want over the pipe and I don't lose calls or dialtone. I've frequently used custom queuing with T1's instead of LLQ.

So, is it the frame providers that are dropping the ball, or the router not prioritizing correctly?

 

[JayNEC]

Am I to believe that everyone that is implementing QOS over frame relay is perfectly when the network is under load?

 

[KiscoKid]

You can quickly verify end to end if the QoS is working and indeed compare if the priority packets queued at source equals the priority packets seen at destination using the 'show policy interface' command.

When you run continuous congestion over Frame Relay, your provider will indiscrtiminantly drop packets. Frame Relay switches don't understand layer 3 QoS and likely never will. If congestion is occuring and you are bursting over CIR, they will just keep dropping packets randomly until your traffic burst conforms to their preconfigured parameters.

One suggestion I would make is to mark all traffic, except voice, as discardable (or Discard Eligibile using FR language). Frame Relay switches will somestimes drop Discard Eligible traffic before they drop the voice traffic. I say sometimes because not all providers configure ther switches this way unfortunately.

I think this will probably work for you as the UDP packets greatly outnumber the voice packets.

The following Cisco URL explains how to configure Discard Eligibility.

http://www.cisco.com/en/US/products...ion_guide_chapter09186a00800ca5a1.html#wp4857

 

[jneiberger]

In addition to LLQ, you need to configure Frame Relay Traffic Shaping to ensure that you never burst above your CIR. That, in effect, drops your total available link speed down to your CIR, but that's the way the ball bounces. That's precisely why we moved away from frame relay to an MPLS-based VPN before we decided to run VoIP over it. The limitations of pure frame relay were unacceptable in our environment.

 

[JayNEC]

Thanks KiscoKid, I was actually recently beginning to do some research on marking packets DE.

Also was looking into the possibility that we were bursting above CIR...
However if the PVC and bandwidth settings are set to the CIR will the interface still attempt to burst above that?

 

[jneiberger]

If you're not doing frame relay traffic shaping then your router will send frames out as fast as it can. What precisely do you mean by "if the PVC and bandwidth settings are set to the CIR" ?

 

[lgarner]

Bandwidth statements on the router are informational and are only actually used for route calculation. They don't affect the amount of data the router tries to push through.

 

[JayNEC]

This is what I mean, my bandwith is set to 384k, and my CIR is set to 384. So, as I understand it now - my actual port speed may be higher and the interface will attempt to burst up to the port speed, correct? And that port speed could be actually a 1.5mb T1!

How does one tell if the frame is bursting or has bursted above CIR. Actually, the fact that I'm having packet loss when the network is busy tells me that I guess.
---------------------------------------------------------

interface Serial0/0/0.76 point-to-point
bandwidth 384000
ip address 172.16.60.2 255.255.255.0
frame-relay interface-dlci 76
class broadway
------------------------------------------
map-class frame-relay broadway
frame-relay fragment 480
frame-relay cir 384000
frame-relay bc 3840
frame-relay be 0
service-policy output broadway

 

[JayNEC]

So, now I wonder could I use the clockrate command to set the port speed... Although the other end of the PVC which is 2 T1's would still be capable of attempting to send 3mbs of data...

 

[jneiberger]

No, don't mess with the clockrate. You have frame relay traffic shaping configured, so your router shouldn't burst above your CIR.

Since you brought it up, what is the actual port speed of this link?

 

[JayNEC]

I'm not sure at this time, but I suspect that it's a full 1544. We don't have fractional T1 in this State.

 

[jneiberger]

What IOS are you using? I've seen some nasty bugs related to LFI in the past. You might try turning off LFI to see if anything changes.

 

[JayNEC]

I don't have access to the router itself, but show run says 12.4

 

[jneiberger]

If you don't have fractional T1 in your State then your link is being clocked at a full T1 rate, which means that you definitely do not need LFI. LFI is designed to alleviate serialization delay at sub-rate speeds, i.e. less than T1. It's not necessary once you get to full T1 clock rates.

 

[JayNEC]

But, the CIR is only 384k! So, you're saying that we've got a full T1 to the cloud, but the cloud will only send traffic onward at the CIR?

 

[jneiberger]

You don't really have a full T1 to the cloud because you're probably being rate-limited to a lower value if you're only paying for 384K. LFI isn't necessary because the bits are placed onto the wire at T1 speed. It's weird to think of it this way, but you have to separate the idea of your CIR from the concept of bits being placed onto the wire. Your wire speed is 1.544 Mbps, but your provider isn't guaranteeing anything above your CIR.

Depending on your arrangement with your provider, they may even be rate-limiting you to 384K. If they're nice and have plenty of capacity, they may let you burst over that but I wouldn't ever count on it.

 

[JayNEC]

So, what's my answer? My CIR is set to 384k, my "be" is set to 0, and traffic shaping is on.

It still remains that when I put a load on the WAN the voice starts to choke, and I've seen this with differnt providers.

 

[jneiberger]

What does your LLQ config look like?

 

[JayNEC]

This is on the edge router:

class-map match-all voice-sig
match ip dscp 54
class-map match-all voice
match ip dscp ef
!
!
policy-map broadway
class voice
priority 248
class voice-sig
bandwidth 8
class class-default
fair-queue

interface Serial0/0/0
no ip address
encapsulation frame-relay IETF
frame-relay traffic-shaping
frame-relay lmi-type ansi
!
interface Serial0/0/0.76 point-to-point
bandwidth 512000
ip address 172.16.60.2 255.255.255.0
frame-relay interface-dlci 76
class broadway

map-class frame-relay broadway
frame-relay fragment 480
frame-relay cir 512000
frame-relay bc 5120
frame-relay be 0
service-policy output broadway

 

[JayNEC]

This is a core (3845 router)

policy-map hancock
class voice
priority 248
class voice-sig
bandwidth 8
class class-default
fair-queue

interface Hssi1/0
description *** 3072M ***
no ip address
encapsulation frame-relay IETF
hssi internal-clock
serial restart-delay 0
clockrate 3240000
frame-relay traffic-shaping
frame-relay lmi-type ansi
max-reserved-bandwidth 90
!
interface Hssi1/0.76 point-to-point
description *** from Hancock Pl ***
bandwidth 512000
ip address 172.16.60.1 255.255.255.0
frame-relay interface-dlci 76
class hancock
!
map-class frame-relay hancock
frame-relay fragment 480
frame-relay cir 512000
frame-relay bc 5120
frame-relay be 0
service-policy output hancock