CCIE Pursuit Blog

August 13, 2008

Internetwork Expert Volume II: Lab 12 – Section 8

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:

frame-relay fragment

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).

Advertisements

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: