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

April 29, 2008

Question Of The Day: 29 April, 2008

Topic: OSPF

You have the following configuration on r1.

interface Loopback0
 ip address 1.1.1.1 255.0.0.0
!
router ospf 100
 router-id 1.1.1.1
 log-adjacency-changes
 network 1.1.1.1 0.0.0.0 area 0
 network 10.1.12.1 0.0.0.0 area 0

r2 is seeng the loopback address with a /32 mask:

r2#sh ip route ospf
     1.0.0.0/32is subnetted, 1 subnets
O       1.1.1.1 [110/2] via 10.1.12.1, 00:00:13, FastEthernet0/0

Using only a single command, make it so that r2 sees r1’s Loopback 0 with its configured network mask.

Click Here For The Answer


Yesterday’s Question

Question Of The Day: 28 April, 2008 

Topic: Frame Relay Traffic Shaping

Here is the current configuration for r1’s Frame Relay connection:

interface Serial1/0
 no ip address
 encapsulation frame-relay
!
interface Serial1/0.12 point-to-point
 ip address 10.1.12.1 255.255.255.0
 frame-relay interface-dlci 102

Configure r1 to match this output:

r1#show traffic-shape

Interface   Se1/0.12
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
102           512000    9600   51200     25600     100       6400      BECN

Answer:

map-class frame-relay FRTS
 frame-relay cir 512000
 frame-relay bc 51200
 frame-relay be 25600
 frame-relay adaptive-shaping becn
!
interface Serial1/0
 no ip address
 encapsulation frame-relay
 frame-relay traffic-shaping

!
interface Serial1/0.12 point-to-point *
 ip address 10.1.12.1 255.255.255.0
 frame-relay interface-dlci 102
  class FRTS

* There are actually three ways to apply this map-class to achieve the output in the question:

1)  Apply it to DLCI 102 only (method shown above).  Configure frame-relay traffic-shaping on the physical interface.  The subinterface will inherit that setting.  Next, configure the FRTS class under the frame-relay interface-dlci command.

interface Serial1/0
 frame-relay traffic-shaping
interface Serial1/0.12 point-to-point
 frame-relay interface-dlci 102
  class FRTS

2)  Configure frame-relay traffic-shaping on the physical interface.  The subinterface will inherit that setting.  Next, configure the FRTS class on the subinterface with the frame-relay class command.  This will apply the FRTS map-class to all DLCIs assocatiated with the s1/0.12 subinterface.  Since we’re using a point-to-point subinterface (only one DLCI allowed) we achieve the same results as method 1.  Keep in mind that if this is a multipoint subinterface this method would apply the map-class to all DLCIs associated with that subinterface.

interface Serial1/0
 frame-relay traffic-shaping
interface Serial1/0.12 point-to-point
 frame-relay class FRTS

3)  Configure frame-relay traffic-shaping on the physical interface.  The subinterface will inherit that setting.  Next, configure the FRTS class on the physical interface with the frame-relay class command.  All subinterfaces will inherit this map-class.  In our example we only have a single subinterface configured so this will achieve the same result as methods 1 and 2. 

interface Serial1/0
 frame-relay traffic-shaping
 frame-relay class FRTS

The biggest ‘gotcha’ with FRTS on subinterfaces is that you need to turn frame-relay traffic-shaping on for the physical interface.  If we add another subinterface to serial1/0 then we’ll end up with that subinterface inheriting a default frame-relay map-class (methods 1 and 2) or the FRTS map-class (method 3).

Methods 1 and 2:
r1(config-subif)#do sh traffic

Interface   Se1/0.12
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
102           512000    9600   51200     25600     100       6400      BECN

Interface   Se1/0.13
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
103           56000     875    7000      0         125       875       –  

Method 3:
r1(config-if)#do sh traffic

Interface   Se1/0.12
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
102           512000    9600   51200     25600     100       6400      BECN

Interface   Se1/0.13
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
103           512000    9600   51200     25600     100       6400      BECN

So how did we reverse-engineer the values for our map-class?  Let’s look at the original output:

r1#show traffic-shape

Interface   Se1/0.12
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
102           512000    9600   51200     25600     100       6400      BECN

VC= Virtual Circuit (DLCI) = 102
Access-List = access-group assigned to the interface = none
Target Rate= CIR = 512Mbps
Byte Limit= Bc + Be in bytes = 9600 (multiply by 8[bit] to get 76800 which jives with our Bc (51200) + Be (25600))
Sustain bits/int= Bc = 51200
Excess bits/int = Be = 25600
Interval (ms) = Tc in milliseconds = 100 ms
Increment (bytes)= No idea  🙂  It looks like it may be the Bc in bytes.
Adapt Active= Adaptive Shaping mechanism (if any) =  BECN (reduce to MINCIR value if a BECN is detected)

From this information we should be able to build our Frame Relay map-class:

map-class frame-relay FRTS
 frame-relay cir 512000 <- Target Rate
 frame-relay bc 51200 <- Sustain bits/int
 frame-relay be 25600 <- Excess bits/int 
 frame-relay adaptive-shaping becn <- Adapt Active

One thing to note is that you cannot determine the MINCIR value from the output provided.  Since we’re using adaptive shaping, there must be a MINCIR value established.  This is the tranmit rate that the interface will use if it detects a BECN.  By default this value is set to half of the CIR.  In our case the CIR is 512000 so our MINCIR is 256000:

r1(config-map-class)#do sh frame pvc 102 | b Shaping
  Shaping adapts to BECN
  pvc create time 00:28:39, last time pvc status changed 00:27:25
  cir 512000    bc 51200     be 25600     byte limit 9600   interval 100
  mincir 256000    byte increment 6400  Adaptive Shaping BECN
  pkts 370       bytes 30031     pkts delayed 0         bytes delayed 0       
  shaping inactive   
  traffic shaping drops 0
  Queueing strategy: fifo
  Output queue 0/40, 0 drop, 0 dequeued

I didn’t give that information in this question because the output explicitly shows you the Be and Bc values.  🙂  Technically I did not give you sufficient information to complete this task as the MINCIR value could have been set to a non-default value (384000) and you would not have known about it from the output provided.

The second point it that the Interval is derived from the formula (using a little bit of basic algebra):

Bc = CIR * (Tc/1000)
Bc/CIR = Tc/1000
(Bc/CIR)*1000 = Tc
Tc = (Bc/CIR)*1000
Tc = (51200/512000) * 1000
Tc = .1 * 1000
Tc = 100

My point is that you do not need to explicitly set the Tc with the ‘frame-relay tc’ command.  In fact, if you do try to set it after setting Bc and CIR, it will not change your Tc:

Let’s try to change the Tc:
r1(config)#map-class frame-relay FRTS
r1(config-map-class)#frame-relay tc 50r1(config-map-class)#do sh traffic

 

Interface   Se1/0.12
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
102           512000    9600   51200     25600     100       6400      BECN

As you can see, the Interval does not change.  If we want to set it to 50 ms, then we need to alter the Bc value.  In this case we would just cut it in half:

r1(config)#map-class frame-relay FRTS
r1(config-map-class)#frame-relay bc 25600 
r1(config-map-class)#do sh traffic

Interface   Se1/0.12
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
102           512000    6400   25600     25600     50        3200      BECN

 

April 28, 2008

Question Of The Day: 28 April, 2008

Topic: Frame Relay Traffic Shaping

Here is the current configuration for r1’s Frame Relay connection:

interface Serial1/0
 no ip address
 encapsulation frame-relay
!
interface Serial1/0.12 point-to-point
 ip address 10.1.12.1 255.255.255.0
 frame-relay interface-dlci 102

Configure r1 to match this output:

r1#show traffic-shape

Interface   Se1/0.12
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
102           512000    9600   51200     25600     100       6400      BECN

Click Here For The Answer


Yesterday’s Question

Question Of The Day: 25 April, 2008 

Topic: EIGRP

r1 and r2 are directly connected via their respective fa0/0 interfaces:

r1:
interface FastEthernet0/0
  ip address 10.1.12.1
  ip hold-time eigrp 100 30
  ip hello-interval eigrp 100 5
!
router eigrp 100
  no auto-summary
  network 10.1.12.1 0.0.0.0

r2:
interface FastEthernet0/0
  ip address 10.1.12.2
  ip hold-time eigrp 100 60
  ip hello-interval eigrp 100 10
!
router eigrp 100
  no auto-summary
  network 10.1.12.2 0.0.0.0

Will r1 and r2 for an EIGRP neighbor relationship over the Ethernet link between them?

Answer: Yes

I have to admit that this one seems counter-intuitive to me.  If you create a mismatch of the EIGRP hello and hold-times (provided that you do not configure a hold-time that is less than the hello interval) on each side of a link, the EIGRP neighbor relationship will not be affected.

r1#show ip eigrp interfaces detail | i Inter|Fa0/0|Hello
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Fa0/0              1        0/0       249       0/10         856           0
  Hello interval is 5 sec

r2#show ip eigrp interfaces detail | i Inter|Fa0/0|Hello
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Fa0/0              1        0/0       295       0/10        1216           0
  Hello interval is 10 sec

I did a ‘debug ip packet detail’ on r1.  You can see that the EIGRP hellos are going out every (approximately) every 5 seconds:

r1#sh log | i s=10.1.12.1
*Mar  1 00:32:29.383: IP: s=10.1.12.1 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:32:33.999: IP: s=10.1.12.1 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:32:38.895: IP: s=10.1.12.1 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:32:43.323: IP: s=10.1.12.1 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:32:48.075: IP: s=10.1.12.1 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:32:52.743: IP: s=10.1.12.1 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:32:57.287: IP: s=10.1.12.1 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:33:01.815: IP: s=10.1.12.1 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:33:06.619: IP: s=10.1.12.1 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88

Same thing on r2.  The EIGRP hellos are going out (approximately) every 10 seconds:

r2#sh log | i s=10.1.12.2
*Mar  1 00:37:30.755: IP: s=10.1.12.2 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:37:39.931: IP: s=10.1.12.2 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:37:49.467: IP: s=10.1.12.2 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:37:58.447: IP: s=10.1.12.2 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:38:07.831: IP: s=10.1.12.2 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:38:16.371: IP: s=10.1.12.2 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:38:25.899: IP: s=10.1.12.2 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:38:34.755: IP: s=10.1.12.2 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88
*Mar  1 00:38:43.463: IP: s=10.1.12.2 (local), d=224.0.0.10 (FastEthernet0/0), len 60, sending broad/multicast, proto=88

The EIGRP neighbors are up and stable, and routes are be advertised:

r1#show ip eigrp neighbors detail fa0/0
IP-EIGRP neighbors for process 100
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   10.1.12.2               Fa0/0             59 00:41:49  249  1494  0  6
   Version 12.3/1.2, Retrans: 1, Retries: 0, Prefixes: 2

r1#sh ip route eigrp
     100.0.0.0/24 is subnetted, 1 subnets
D       100.1.4.0 [90/158720] via 10.1.12.2, 00:43:13, FastEthernet0/0
     10.0.0.0/24 is subnetted, 4 subnets
D       10.1.24.0 [90/30720] via 10.1.12.2, 00:43:14, FastEthernet0/0

r2#show ip eigrp neighbors detail fa0/0
IP-EIGRP neighbors for process 100
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   10.1.12.1               Fa0/0             26 00:45:17  249  1494  0  5
   Version 12.3/1.2, Retrans: 1, Retries: 0, Prefixes: 1

r2#show ip route eigrp
     1.0.0.0/32 is subnetted, 1 subnets
D       1.1.1.1 [90/156160] via 10.1.12.1, 00:00:16, FastEthernet0/0

So the answer is yes.  🙂

 

April 10, 2008

Question Of The Day: 10 April, 2008

Topic: Frame Relay Traffic Shaping

The network engineer in charge of r1 recently configured Frame Relay Traffic Shaping.  The remote sites have complained that they are still getting too much traffic ingress on their Frame Relay connections to r1.  You agree to look at his configuration:

map-class frame-relay FRTS
 frame-relay cir 256000
 frame-relay be 12880
 frame-relay mincir 128000
 frame-relay adaptive-shaping becn
!
interface Serial1/0
 ip address 10.1.1.1 255.255.255.0
 encapsulation frame-relay
 frame-relay class FRTS
 frame-relay map ip 10.1.1.2 102 broadcast
 frame-relay map ip 10.1.1.3 103 broadcast
 no frame-relay inverse-arp

r1#sh frame map
Serial1/0 (up): ip 10.1.1.2 dlci 102(0x66,0x1860), static,
              broadcast,
              CISCO, status defined, active
Serial1/0 (up): ip 10.1.1.3 dlci 103(0x67,0x1870), static,
              broadcast,
              CISCO, status defined, active

What is the problem with this configuration?


Yesterday’s Question

Question Of The Day: 09 April, 2008 

 Topic: IP Prefix Lists

Write a single line IP prefix list called “MY_SUBNETS” that will only allow the following subnets:

10.1.1.118/26
10.1.1.118/27
10.1.1.118/28
10.1.1.118/29
10.1.1.118/30

Answer: ip prefix-list MY_SUBNETS 10.1.1.118/26 le 30

When matching on multiple, contiguous IP subnets, your ip prefix-list should be in the form: ip prefix-list NAME permit x.x.x.x/[min mask] le [max mask]

ip prefix-list

 

April 4, 2008

Internetwork Expert Volume II: Lab 3 – Section 8

QoS – 6 Points

8.1 FRTS

Configure FRTS with these parameters:

Data should be sent at a sustained rate of 256Kbps per DLCI.  <-CIR
In the event of congestion noticification fallback to no lower than 192Kbps  <-MINCIR with adaptive-shaping becn
Any FECNs received should be reflected back as a BECN. <-???

Not too hard to figure out the third one :-0

r1(config-map-class)#frame ?
  fecn-adapt         Enable Traffic Shaping reflection of FECN as BECN

frame-relay cir

frame-relay mincir

frame-relay adaptive-shaping

becn
 Enables rate adjustment in response to backward explicit congestion notification (BECN).

r1(config-map-class)#do sh run | sec FRTS
map-class frame-relay FRTS
 frame-relay cir 256000
 frame-relay mincir 192000
 frame-relay adaptive-shaping becn
 frame-relay fecn-adapt

Since we want to apply this to ALL DLCIs we just need two commands under the FR int:

r1(config-map-class)#int s0/0/0
r1(config-if)#frame traffic-shaping  <-don’t forget this!!!
r1(config-if)#frame class FRTS

r1(config-if)#do sh traffic

Interface   Se0/0/0
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
103           256000    4000   256000    0         125       4000      BECN
104           256000    4000   256000    0         125       4000      BECN
105           256000    4000   256000    0         125       4000      BECN
106           256000    4000   256000    0         125       4000      BECN
107           256000    4000   256000    0         125       4000      BECN
108           256000    4000   256000    0         125       4000      BECN
109           256000    4000   256000    0         125       4000      BECN
—output truncated—

8.2 Rate Limiting

Limit HTTP responses out r4’s fa0/1 to 256Kbps between the hours of 8am to 5pm Monday through Friday.

We need to build a time-range first:

time-range
http://www.cisco.com/en/US/docs/ios/12_3t/fun/command/reference/cfrgt_12.html#wp1058115

r4(config)#time-range TASK82
r4(config-time-range)#periodic weekdays 08:00 to 17:00

NOTE: Clarify with the proctor about the start and end time (17:00 versus 16:59)

Now let’s match HTTP in an (extended named) access-list:

ip access-list extended TASK82
 permit tcp any eq www any time-range TASK82

Let’s pop that sucker into a class-map:

class-map match-all TASK82
 match access-group name TASK82

Then match that class in a policy-map and apply our policing:

policy-map TASK82
 class TASK82
    police 256000

Finally let’s put this on the interface:

r4(config)#int fa0/1
r4(config-if)#service-policy out TASK82

The reason that I use consistent naming throughout the process is so that I can quickly look at my configuation:

r4(config-if)#do sh run | sec TASK82
class-map match-all TASK82
 match access-group name TASK82
policy-map TASK82
 class TASK82
    police 256000
 service-policy output TASK82
ip access-list extended TASK82
 permit tcp any eq www any time-range TASK82
time-range TASK82
 periodic weekdays 8:00 to 17:00

IE uses:

policy-map TASK82
 class TASK82
    police cir 256000

Not sure why?

Task 8.2 quick question

With ‘police 256000’:

r4#sh policy-map int fa0/1
 FastEthernet0/1

  Service-policy output: TASK82

    Class-map: TASK82 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group name TASK82
      police:
          cir 256000 bps, bc 8000 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop
        conformed 0 bps, exceed 0 bps

    Class-map: class-default (match-any)
      84 packets, 7949 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

With ‘police cir 256000’:

r4#sh policy-map int fa0/1
 FastEthernet0/1

  Service-policy output: TASK82

    Class-map: TASK82 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group name TASK82
      police:
          cir 256000 bps, bc 8000 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop
        conformed 0 bps, exceed 0 bps

    Class-map: class-default (match-any)
      101 packets, 9793 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

Any differences?

police

r4(config-pmap-c)#police ?
  <8000-2000000000>  Bits per second
  cir                Committed information rate
  rate               Specify police rate

8.3 Signalling

“…administrators have configured the client applications on these vlans to requrest bandwidth reservations…”

RSVP….Integrated Services

The good news is that RSVP is ridiculously easy to configure:

ip rsvp bandwidth

r4(config)#int s0/0/0
r4(config-if)#ip rsvp band 128 64

r4#sh ip rsvp int s0/0/0
interface    allocated  i/f max  flow max sub max
Se0/0/0      0          128K     64K      0

There is one ‘gotcha’ though: You need to enabled WFQ for RSVP.  When you turn on FRTS, WFQ is disabled.  You need to explicitly set it.

January 24, 2008

Internetwork Expert Blog: Three Flavors Of Traffic Shaping

The Internetwork Expert Blog has three posts covering different ways to configure traffic-shaping.  This is a topic that you must master for the lab.  You’ll need to be familiar with each of the different versions in case they eliminate one or more methods in the task.

Frame-Relay Traffic Shaping with GTS (Generic Traffic Shaping)

Legacy Frame-Relay Traffic Shaping

MQC-based Frame-Relay Traffic-Shaping

Blog at WordPress.com.