Quantcast
Channel: IEOC - INE's Online Community
Viewing all articles
Browse latest Browse all 10744

Legacy FRTS

$
0
0

For some reason when I get a question about shaping frame relay I always configure using MQC and not Legacy FRTS. I did it again on Lab 7 task 8.2.  

 

8.2 Shaping

• The next portion of the QoS policy dictates that all traffic sent across the

Frame Relay cloud should be shaped as not to cause congestion for the

VoIP traffic.

• The Frame Relay interfaces of R3, R4, and R5 are all clocked at T1 speed

by the Frame Relay service provider. However since R5 only has a single

connection to the Frame Relay cloud, each VC on R5 has been equally

provisioned a CIR of 768Kbps by the telco.

• Configure all endpoints of the Frame Relay network to adhere to the

provisioned CIR.

• The shaping intervals of R4 and R5 should be such as to minimize delay

for the packet in shaper queue.

• As an additional measure to decrease the delay of your VoIP traffic

configure R4 and R5 so that packets with a payload greater than 960

bytes are fragmented.

 

INE's solution uses FRTS which is a lot simpler than MQC but I wanted to check my work.  My config looks correct to me but does anyone see any issues?  My one concern is applying the framentation on the main interface.  Here is my config of just R5.  R4 and R3 are similar just CIR and Bc different.

 

policy-map SHAPE_POLICY

 class class-default

    shape peak 768000 3072 0

 

map-class frame-relay SHAPE_MAP_CLASS

 service-policy output SHAPE_POLICY

 

interface Serial0/0/0:0

 frame-relay fragment 960 end-to-end

 

interface Serial0/0/0:0.35 point-to-point

 frame-relay class SHAPE_MAP_CLASS

 

interface Serial0/0/0:0.54 point-to-point

 frame-relay class SHAPE_MAP_CLASS


Viewing all articles
Browse latest Browse all 10744

Trending Articles