Section 8 – QoS – 6 Points
8.1 Frame Relay Traffic Shaping
Oooh. A VoIP issue with an interface running at less than 768K. Time for some packet interleaving. 🙂
The task tells us that r2 and r4 have been provisioned at 512K and that we should “ensure that neither of these devices send traffic beyond this rate on this circuit.”
We also have this requirement:
“Additional VCs on r4 (DLCIs 401 and 405) should equally share the remaining bandwidth of its T1 interface to the Frame Relay cloud.”
Okay. That bit confused me. Basically we need to split the the remaining bandwidth (1544 – 512)/2. In the end we’re assigning a CIR of 512 to each of the three circuits on int s0/0 of r4.
It’s the last requirement that gives us the most “actionable information”:
“In order to allow VoIP traffic to be interleaved between larger data converstions ensure that the maximum time that it takes to transmit a packet across the Frame Relay network is 10ms.”
All of that just basically means that we need to use a Tc of 10ms.
We aren’t asked to allow a burst, so we can set Be to 0. Bc can be determined by the following formula:
Bc = CIR * (Tc/1000)
Bc = 512000 * (10/1000)
Bc = 512000 * .01
Bc = 5120
So our map-class should be:
map-class frame-relay FRTS
frame-relay cir 512000
frame-relay bc 5120
frame-relay be 0
Now we need to enable interleaving:
Rack16R2(config-map-class)#frame ?
fragment fragmentation – Requires Frame Relay traffic-shaping to be configured at the interface level
Rack16R2(config-map-class)#frame frag ?
<16-1600> Define fragment size, Bytes
<cr>
Okay. So how do we come up with this value? There’s a chart of suggested values in the frame-relay fragement documentation. As long as the speed is under 768K We just need to convert the Bc of the lowest speed link in the path (in our case both sides are 512K) to bytes (divide by 8):
5120/8 = 640 bytes
So now we have:
map-class frame-relay FRTS
frame-relay cir 512000
frame-relay bc 5120
frame-relay be 0
frame-relay fragment 640
frame-relay fair-queue <- IOS added this
Now apply the map-class to the DLCI:
Rack16R2(config)#int s0/0
Rack16R2(config-if)#frame interface-d 204
Rack16R2(config-fr-dlci)#class FRTS
I generally only apply traffic shaping to the specific DLCI, IE likes to apply it to the all DLCIs on the interface. Ask your proctor. 🙂
Rack16R2(config-if)#do sh traffic
Interface Se0/0
Access Target Byte Sustain Excess Interval Increment Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes) Active
201 56000 875 7000 0 125 875 –
203 56000 875 7000 0 125 875 –
205 56000 875 7000 0 125 875 –
213 56000 875 7000 0 125 875 –
204 512000 640 5120 0 10 640 –
Rack16R2#sh frame pvc 204
PVC Statistics for interface Serial0/0 (Frame Relay DTE)
DLCI = 204, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0
input pkts 1026 output pkts 1092 in bytes 148630
out bytes 148115 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 254 out bcast bytes 90472
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 04:09:41, last time pvc status changed 04:08:32
fragment type end-to-end fragment size 640
cir 512000 bc 5120 be 0 limit 640 interval 10
mincir 256000 byte increment 640 BECN response no IF_CONG no
frags 74 bytes 9639 frags delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
Queueing strategy: weighted fair
Current fair queue configuration:
Discard Dynamic Reserved
threshold queue count queue count
64 16 0
Output queue size 0/max total 600/drops 0
One “gotcha” on r4 is that we already have a class applied to DLCI 504:
interface Serial0/0.54 point-to-point
ip address 129.16.54.4 255.255.255.0
ip ospf demand-circuit
frame-relay interface-dlci 405
class FREEK
We just need to add the additional FRTS configuration to that already existing map-class. You could create only one additional map-class for both of the remaining DLCIs, but the next task will require two separate map-classes as you will tweak DLCI 402 only.
Rack16R4#sh traffic
Interface Se0/0
Access Target Byte Sustain Excess Interval Increment Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes) Active
403 56000 875 7000 0 125 875 –
413 56000 875 7000 0 125 875 –
Interface Se0/0.54
Access Target Byte Sustain Excess Interval Increment Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes) Active
405 512000 640 5120 0 10 640 –
Interface Se0/0.124
Access Target Byte Sustain Excess Interval Increment Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes) Active
401 512000 640 5120 0 10 640 –
402 512000 640 5120 0 10 640 –
8.2 Priority Queueing
“…configure your network so that all VoIP traffic (UDP 16384 – 32767) coming from VLAN 46 going out the Frame Relay circuit to R2 gets priority over data traffic.”
“VoIP should be allocated a maximum of 192Kbps during periods of congestion on this link.”
It’s nice that IE included the VoIP protocol ports, but you should probably memorized that before the lab. It’s pretty obvious that we’ll be configuring LLQ and mixing it with the existing FRTS configuration.
ip access-list extended TASK_8_2
permit udp 129.16.46.0 0.0.0.255 any range 16384 32767
Rack16R4(config)#class-map TASK_8_2
Rack16R4(config-cmap)#match access-group name TASK_8_2
Rack16R4(config-ext-nacl)#policy-map TASK_8_2
Rack16R4(config-pmap)#class TASK_8_2
Rack16R4(config-pmap-c)#prio ?
<8-2000000> Kilo Bits per second <- KILO!!!
percent % of total bandwidth
Rack16R4(config-pmap-c)#prio 192
Rack16R4(config-pmap-c)#map-class frame-relay DLCI_402
Rack16R4(config-map-class)#service-policy out TASK_8_2
Configure the same thing on r2 (remember to alter the direction of your access-list).
Leave a Reply