CCIE Pursuit Blog

May 28, 2009

Core Knowledge Question of the Day: 28 May 2009

Which markings are trusted by default on the interface when you configure the following on a Cisco 3560 switch:

SW1(config)#int f0/1
SW1(config-if)#mls qos trust

Highlight for answer: If no keyword is specified when the command is entered, then DSCP markings are trusted by default when the ‘mls qos trust’ interface-level command is configured.

May 27, 2009

Core Knowledge Question of the Day: 27 May 2009

R3#sh frame map
Serial0/0 (up): ip 155.3.0.3 dlci 503(0x1F7,0x7C70), static,
broadcast,
CISCO, status defined, active
TCP/IP Header Compression (inherited), connections: 218959117
RTP Header Compression (inherited), connections: 218959117

R5#sh frame map
Serial1/0 (up): ip 155.1.0.5 dlci 305(0x131,0x4C10), static,
broadcast,
CISCO, status defined, active
TCP/IP Header Compression (enabled), connections: 256
RTP Header Compression (enabled), connections: 256

Given the above output, what is the fundamental difference between the TCP and RTP header compression configurations on R3 and R5?

Highlight for answer: On R3, TCP and RTP header compression have been enabled on the interface level as indicated by the ‘inherited’ description in the ‘show frame-relay map’ output.  On R5 it has been enabled via the frame-relay map map statement(with the keyword ‘compress’).

August 20, 2008

Lab Tip: Finding Default WRED Values

Here’s a quick and dirty method to find default WRED values so that if a task asks you to reference the defaults (i.e. “Make the maximum threshold twice the default”) you will be able to quickly find the default values without searching the Cisco documentation.

First turn WRED on for an interface:

r1(config)#int fa0/1
r1(config-if)#random-detect

Now you can issue the “show queueing interface f0/1” command:

r1#show queueing interface f0/1
Interface FastEthernet0/1 queueing strategy: random early detection (WRED)
    Random-detect not active on the dialer
    Exp-weight-constant: 9 (1/512)
    Mean queue depth: 0

  class          Random drop      Tail drop    Minimum Maximum  Mark
                  pkts/bytes       pkts/bytes    thresh  thresh  prob
      0      0/0              0/0           20      40  1/10
      1      0/0              0/0           22      40  1/10
      2      0/0              0/0           24      40  1/10
      3      0/0              0/0           26      40  1/10
      4      0/0              0/0           28      40  1/10
      5      0/0              0/0           31      40  1/10
      6      0/0              0/0           33      40  1/10
      7      0/0              0/0           35      40  1/10
   rsvp      0/0              0/0           37      40  1/10

This shows the default WRED settings for each IP precedence class.  The default values for IP precedence 3 are:

r1(config-if)#random-detect precedence 3 26 40 10

Where 3 = IP Precedence; 26 = Minimum Threshold; 40 = maximum threshold; and 10 = mark probability denominator

This is good to know because you may be asked to change one of these variables.  To change one of these variables you still need to enter in values for the other variables so you need to know the default values if you are not tasked with changing them.  You could look up the defaults in the DOC, but this is faster.

What if you want the DSCP defaults instead?  One more line will yield those for you:

r1(config)#int fa0/1
r1(config-if)#random-detect dscp-based

r1(config-if)#do sh queueing int f0/1
Interface FastEthernet0/1 queueing strategy: random early detection (WRED)
    Random-detect not active on the dialer
    Exp-weight-constant: 9 (1/512)
    Mean queue depth: 0

   dscp          Random drop      Tail drop    Minimum Maximum  Mark
                  pkts/bytes       pkts/bytes    thresh  thresh  prob
   af11      0/0              0/0           33      40  1/10
   af12      0/0              0/0           28      40  1/10
   af13      0/0              0/0           24      40  1/10
   af21      0/0              0/0           33      40  1/10
   af22      0/0              0/0           28      40  1/10
   af23      0/0              0/0           24      40  1/10
   af31      0/0              0/0           33      40  1/10
   af32      0/0              0/0           28      40  1/10
   af33      0/0              0/0           24      40  1/10
   af41      0/0              0/0           33      40  1/10
   af42      0/0              0/0           28      40  1/10
   af43      0/0              0/0           24      40  1/10
    cs1      0/0              0/0           22      40  1/10
    cs2      0/0              0/0           24      40  1/10
    cs3      0/0              0/0           26      40  1/10
    cs4      0/0              0/0           28      40  1/10
    cs5      0/0              0/0           31      40  1/10
    cs6      0/0              0/0           33      40  1/10
    cs7      0/0              0/0           35      40  1/10
     ef      0/0              0/0           37      40  1/10
   rsvp      0/0              0/0           37      40  1/10
default       0/0              0/0           20      40  1/10

Remember to remove WRED (or DSCP) if you’re not using it on that interface:

r1(config)#int fa0/1
r1(config-if)#no random-detect

r1(config-if)#do sh queueing int f0/1
Interface FastEthernet0/1 queueing strategy: none

If you’re given an IP Precedence name like “flash-override” instead of the IP Precedence value (4 in this case) then use this tip:

Lab Tip: Remembering IP Precedence Values

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

Internetwork Expert Volume II: Lab 5 – Section 7

QoS – 8 Points

7.1 Frame Relay Traffic Shaping

We need to configure FRTS on r1.

AIR = 512Kbps
CIR = 384Kbps
MINCIR = 256Kbps
Be = Up to port speed
Tc = 100ms

We also know that we need to use adaptive shaping.

Bc = CIR * (Tc/1000)
Be = (AR – CIR) * (Tc/1000)

Adaptive Frame Relay Traffic Shaping for Interface Congestion

Frame-Relay Traffic Shaping

We can knock out the easy ones first:

map-class frame-relay FRTS
 frame-relay cir 384000
 frame-relay mincir 256000
 frame-relay adaptive-shaping becn

Now we just need to configure Bc and Be.

Bc = CIR * (Tc/100)
Bc = 384000 * (100/1000)
Bc = 384000 * .1
Bc = 38400

Be = (AR – CIR) * (Tc/1000)
Be = (512000 – 384000) * (100/1000)
Be = (128000) * (.1)
Be = 12800

So our final map-class is:

map-class frame-relay FRTS
 frame-relay cir 384000
 frame-relay bc 38400
 frame-relay be 12800
 frame-relay mincir 256000
 frame-relay adaptive-shaping becn

r1(config#int s0/0
r1(config-if)#frame traffic
r1(config-if)#frame interface-dlci 113
r1(config-fr-dlci)#class FRTS

r1(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
103           56000     875    7000      0         125       875       –
104           56000     875    7000      0         125       875       –
105           56000     875    7000      0         125       875       –
113           384000    6400   38400     12800     100       4800      BECN 
102           56000     875    7000      0         125       875       –

IE simply applies the map-class to the interface.  I don’t agree with their solution as all PVCs are affected and not just the PVC to r1.  Of course, only DLCI 113 is actually being used so…..ask your friendly proctor for clarification.  🙂

7.2 RTP Header Compression

Configure the Frame connection between r3 and r4 to support RTP header compression. 

ip rtp header-compression

r3’s s0/0 is a multipoint, physical Frame-Relay interface and we need to configure this only on the DLCI to r4.  I had to peek the answer on this one.

frame-relay map ip rtp header-compression

r3(config-if)# frame-relay map ip 162.1.0.4 304 rtp header-compression ?
  active            Always compress RTP headers
  connections       Maximum number of compressed RTP connections
  passive           Compress for destinations sending compressed RTP headers
  periodic-refresh  Send periodic refresh packets
  <cr>

Ummmm….did this blow away my broadcast capability

Before:
r3(config-if)#do sh run int s0/0:0 | i 162.1.0.4
 frame-relay map ip 162.1.0.4 304 broadcast

After:
r3(config-if)#do sh run int s0/0:0 | i 162.1.0.4
 frame-relay map ip 162.1.0.4 304 rtp header-compression passive connections 15

r3(config)#do sh frame map | sec 162.1.0.4
Serial0/0:0 (up): ip 162.1.0.4 dlci 304(0x130,0x4C00), static,
              CISCO, status defined, active
              RTP Header Compression (enabled), passive (enabled), connections: 15

Make sure that you leave your broadcast keyword in your map:

frame-relay map ip 162.1.0.4 304 broadcastrtp header-compression passive connections 15

Your connections need to match on both sides:

r4(config-if)#do sh run int s0/0 | i header
 frame-relay map ip 162.1.0.3 403 broadcast rtp header-compression connections 15

r3#sh ip rtp header-compression
RTP/UDP/IP header compression statistics:
 DLCI 304        Link/Destination info: ip 162.1.0.4
  Interface Serial0/0:0 DLCI 304 (compression off, Cisco, RTP, passive)
    Rcvd:    0 total, 0 compressed, 0 errors, 0 status msgs
             0 dropped, 0 buffer copies, 0 buffer failures
    Sent:    0 total, 0 compressed, 0 status msgs, 0 not predicted
             0 bytes saved, 0 bytes sent
    Connect: 15 rx slots, 15 tx slots,
             0 misses, 0 collisions, 0 negative cache hits, 15 free contexts

7.3 Bandwidth Limiting

“…Microsoft SQL traffic is limited to an average rate of 256Kbps on r2’s connection to the Frame Realy cloud.”
“Up to 2048 SQL packets in excess of 256Kbps should be queued up by r2 before packet loss occurs.”

Sounds like queueing to me.

“Do not use an access-list to accomplish this.”

That means we’ll be using a class-map with NBAR to match the traffic.

r2(config-cmap)#match protocol ?
—output truncated—
  sqlnet            SQL*NET for Oracle
  sqlserver         MS SQL Server

—output truncated—

We need to match on MICROSOFT SQL:

class-map match-all TASK_73
 match protocol sqlserver

r2(config-if)#policy-map TASK_73
r2(config-pmap)#class TASK_73
r2(config-pmap-c)#shape average 256000
r2(config-pmap-c)#shape ?
  adaptive        Enable Traffic Shaping adaptation to BECN
  average         configure token bucket: CIR (bps) [Bc (bits) [Be (bits)]],
                  send out Bc only per interval
  fecn-adapt      Enable Traffic Shaping reflection of FECN as BECN
  fr-voice-adapt  Enable rate adjustment depending on voice presence
  max-buffers     Set Maximum Buffer Limit
  peak            configure token bucket: CIR (bps) [Bc (bits) [Be (bits)]],
                  send out Bc+Be per interval

shape max-buffers

r2(config-pmap-c)#shape max-buffers 2048

r2(config-pmap-c)#int s0/0/0.1
r2(config-subif)#service-policy output TASK_73

r2(config-subif)#do sh policy-map int s0/0/0.1

 Serial0/0/0.1

  Service-policy output: TASK_73

    Class-map: TASK_73 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol sqlserver
      Traffic Shaping
           Target/Average   Byte   Sustain   Excess    Interval  Increment
             Rate           Limit  bits/int  bits/int  (ms)      (bytes)
           256000/256000    1984   7936      7936      31        992

        Adapt  Queue     Packets   Bytes     Packets   Bytes     Shaping
        Active Depth                         Delayed   Delayed   Active
        –      0         0         0         0         0         no

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

 

April 5, 2008

Internetwork Expert Volume II: Lab 8 – Section 7

QoS – 8 Points

7.1  Queueing

Configure r1’s traffic shaping queue to hold 10 times the default amount of packets.

r1#sh traffic queue
Traffic queued in shaping queue on Serial0/0 dlci 105
  Queueing strategy: fcfs

r1#sh queueing int s0/0
Interface Serial0/0 queueing strategy: none

So what is the default number of packets?

Here’s the answer:

r1#sh frame pvc 104

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

DLCI = 104, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0

  input pkts 1371          output pkts 1726         in bytes 79864
  out bytes 93708          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 1145      out bcast bytes 59946
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 05:18:08, last time pvc status changed 05:17:48
  cir 128000    bc 16000     be 0         byte limit 2000   interval 125
  mincir 64000     byte increment 2000  Adaptive Shaping none
  pkts 1726      bytes 93708     pkts delayed 0         bytes delayed 0
  shaping inactive
  traffic shaping drops 0
  Queueing strategy: fifo
  Output queue 0/40, 0 drop, 0 dequeued 

Or the easier to read version:

r1#sh frame pvc 104 | i que
  Output queue 0/40, 0 drop, 0 dequeued

Now I need to find a way to change that from 40 to 400:

r1(config)#map-class frame-relay FRTS
r1(config-map-class)#frame ?
  adaptive-shaping   Adaptive traffic rate adjustment, Default = none
  bc                 Committed burst size (Bc), Default = 7000 bits
  be                 Excess burst size (Be), Default = 0 bits
  cir                Committed Information Rate (CIR), Default = 56000 bps
  congestion         Congestion management parameters
  custom-queue-list  VC custom queueing
  end-to-end         Configure frame-relay end-to-end VC parameters
  fair-queue         VC fair queueing
  fecn-adapt         Enable Traffic Shaping reflection of FECN as BECN
  fragment           fragmentation – Requires Frame Relay traffic-shaping to be
                     configured at the interface level
  holdq              Hold queue size for VC
  idle-timer         Idle timeout for a SVC, Default = 120 sec
  interface-queue    PVC interface queue parameters 
  ip                 Assign a priority queue for RTP streams
  mincir             Minimum acceptable CIR, Default = CIR/2 bps
  priority-group     VC priority queueing
  tc                 Policing Measurement Interval (Tc)
  traffic-rate       VC traffic rate
  voice              voice options

holdq looks promising:

frame-relay holdq

To configure the maximum size of a traffic-shaping queue on a switched permanent virtual circuit (PVC), use the frame-relay holdq command in map-class configuration mode.

Defaults
40 packets

That’s the stuff!

r1(config-map-class)#frame holdq 400

r1#sh frame pvc 104 | i que
  Output queue 0/400, 0 drop, 0 dequeued

The IE solution guide shows the configuration on r4 but it should be configured on r1:

Task 7.1

7.2 Congestion Management

Configure traffic with a UDP destination port of 7070 between r1 and r3 over the serial link with:

1) Priority over all other traffic on the link
2) A maximum of 128Kbps outbound on r1 and r3
3) A burst value of 64Kbps

Well we’re definitely talking LLQ here.  Let’s start by classifying the traffic:

r1(config)#ip access-list extended TASK72
r1(config-ext-nacl)#permit udp any any eq 7070

Now let’s put that in a class-map:

r1(config)#class-map TASK72
r1(config-cmap)#match access-group name TASK72

Now let’s configure our policy-map:

r1(config)#policy-map TASK72
r1(config-pmap)#class TASK72
r1(config-pmap-c)#priority 128000 64000

Finally, let’s apply this outbound on the serial link:

r1(config-if)#service-policy out TASK72
I/f Serial0/1 class TASK72 requested bandwidth 128000 (kbps), available only 1152 (kbps)

DOH!!!!  RTFM!

r1(config-pmap-c)#priority ?
  <8-2000000>  Kilo Bits per second
  percent      % of total bandwidth
r1(config-pmap-c)#  priority 128 ?
  <32-2000000>  Burst in bytes
  <cr>
r1(config-pmap-c)#  priority 128 8000 <-64000/8

r1(config-if)#service-policy out TASK72
Must remove fair-queue configuration first.

ARGH!!!!

r1(config-if)#do sh run int s0/1
interface Serial0/1
 ip address 174.1.13.1 255.255.255.0
 ip pim sparse-dense-mode
 fair-queue 64 256 256  <-WTF????

r1(config-if)#int s0/1
r1(config-if)#no fair
r1(config-if)#service-policy out TASK72

FINALLY!!!

r1#sh policy-map int s0/1 out
 Serial0/1

  Service-policy output: TASK72

    Class-map: TASK72 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group name TASK72
      Queueing
        Strict Priority
        Output Queue: Conversation 264
        Bandwidth 128 (kbps) Burst 8000 (Bytes)
        (pkts matched/bytes matched) 0/0
        (total drops/bytes drops) 0/0

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

The cool thing is that you can drop this same configuration on r3:

r1#sh run | sec TASK72
class-map match-all TASK72
 match access-group name TASK72
policy-map TASK72
 class TASK72
  priority 128 8000
 service-policy output TASK72
ip access-list extended TASK72
 permit udp any any eq 7070

This discussion brings up a good point about the question asking for the burst in bps rather than just ‘bits’:

7.2 Cong. Mgmt

I think this question is flawed…..

The question is worded such that it wants 6400bps (bits PER SEC) of a burst.
The token bucket burst is entered as total bytes (i.e. within an interval of Tc, you can burst x bytes of data).
Since the rate needs to be 128kbps, you can’t send bursts at another rate as the CIR along with the burst bytes gives you a fixed Tc.

Yes I agree. I guess it’s 200ms in this case as default value calculated that way in the command reference.

So if question had asked 64000bits then 8000bytes is correct.

But question has asked 64000bps. therefore:
Be=64000bps*0,200sec = 12800bits = 1600 bytes.

so config should be:
priority 128 1600

7.3 Congestion Avoidance

Use WRED on traffic s0/0 on r4 [I initially read this question as requiring only traffic from VLAN 4 to be matched]:

1) Do not drop ‘critical’ traffic until there are 60 packets in queue
2) Drop 5 of every 25 packets of ‘critical’ traffic when there are 60 – 90 packets in queue
3) Drop all ‘critical’ packets once the queue exceeds 90

“critical” traffic is traffic with an IP precedence value of 5:

critical        Set packets with critical precedence (5)

So we need to set the queueing for traffic that matches ip precence 5

random-detect precedence

min-threshold
 Minimum threshold in number of packets. The value range of this argument is from 1 to 4096. When the average queue length reaches the minimum threshold, WRED randomly drops some packets with the specified IP Precedence.
 
max-threshold
 Maximum threshold in number of packets. The value range of this argument is from the value of the min-threshold argument to 4096. When the average queue length exceeds the maximum threshold, WRED drops all packets with the specified IP Precedence.
 
mark-prob-denominator
 Denominator for the fraction of packets dropped when the average queue depth is at the minimum threshold. For example, if the denominator is 512, 1 out of every 512 packets is dropped when the average queue is at the minimum threshold. The value range is from 1 to 65536. The default is 10; 1 out of every 10 packets is dropped at the minimum threshold.

The 5 out of 25 packets is the same as 1 out of 5 so:

policy-map TASK73
 class class-default
  fair-queue
  random-detect
  random-detect precedence 5   60    90    5

Finally, we apply this to our existing map-class:

r4(config)#map-class frame FRTS
r4(config-map-class)#service-policy out TASK73

r4#sh frame pvc 401 | b policy
  service policy TASK73
 Serial0/0: DLCI 401 –

  Service-policy output: TASK73

    Class-map: class-default (match-any)
      10 packets, 581 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
      Queueing
        Flow Based Fair Queueing
        Maximum Number of Hashed Queues 16
        (total queued/total drops/no-buffer drops) 0/0/0
         exponential weight: 9

  class    Transmitted      Random drop      Tail drop    Minimum Maximum  Mark
           pkts/bytes       pkts/bytes       pkts/bytes    thresh  thresh  prob
      0       0/0               0/0              0/0           20      40  1/10
      1       0/0               0/0              0/0           22      40  1/10
      2       0/0               0/0              0/0           24      40  1/10
      3       0/0               0/0              0/0           26      40  1/10
      4       0/0               0/0              0/0           28      40  1/10
      5       0/0               0/0              0/0           60      90  1/5
      6      10/581             0/0              0/0           32      40  1/10
      7       0/0               0/0              0/0           34      40  1/10
   rsvp       0/0               0/0              0/0           36      40  1/10

  Output queue size 0/max total 600/drops 0

 

 

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.

February 3, 2008

How To Look Like A Jackass

Filed under: Cisco,IOS,QoS,Work — cciepursuit @ 7:42 pm
Tags: ,

I was asked by a member of our NOC to take a look at the QoS configuration on a router to see if there were any issues.  I logged in and took a look: 

r1#show policy-map
  Policy Map FAKE
    Class FAKE1
      Strict Priority
      Bandwidth 512 (kbps) Burst 12800 (Bytes)
    Class FAKE2
      Bandwidth 128 (kbps) Max Threshold 64 (packets)
    Class FAKE3
      Bandwidth 128 (kbps) Max Threshold 64 (packets)
    Class class-default

r1#sh policy-map s0/0

r1#

The policy map exists on the router but is not assigned to the interface.  I told the NOC:

“There’s the problem.  Tell the site engineer that he did not apply the service-policy to the interface.”

A few minutes later I got a call from the engineer who supports that site:

“Why did you tell the NOC that I didn’t have QoS running on router r1?”
“Because I saw that the policy is there, but it is not applied to interface.”
“Yes it is.”
“No it isn’t.”
“Yes.  It.  Is.”

At that point I logged into the router and rechecked.  To my surprise, the policy was there:

r1#sh policy-map int s0/0

 Serial0/0

  Service-policy output: FAKE

    Class-map: FAKE1 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol edonkey
      Queueing
        Strict Priority
        Output Queue: Conversation 264
        Bandwidth 512 (kbps) Burst 12800 (Bytes)
        (pkts matched/bytes matched) 0/0
        (total drops/bytes drops) 0/0

    Class-map: FAKE2 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol dns
      Queueing
        Output Queue: Conversation 265
        Bandwidth 128 (kbps)Max Threshold 64 (packets)
        (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0

—OUTPUT TRUNCATED—

My first thought was that he had changed the configuration, but there were no configuration changes made.  An IOS bug?

In cases like this I have learned that the most likely suspect is myself.  This proved to be no exception.  Those of you with a good eye have already spotted my mistake:

r1#sh policy-map ?
  WORD           policy-map name
  control-plane  Show Control Plane policy
  interface      Show Qos Policy Interface
  session        Show session Qos Policy
  |              Output modifiers
  <cr>

‘show policy-map s0/0’ and ‘show policy-map int s0/0′ are not the same command.  🙂

‘show policy-map s0/0 looks for a policy-map named ‘s0/0’, while ‘show policy-map int s0/0’ shows the (inbound and outbound) policies assigned to interface s0/0.

DOH!!!!

As soon as I explained my mistake the flood of jokes at my expense began:

“Do they have QoS on the CCIE lab?  Good luck with that.”
“Why don’t you just take $1500 and light it on fire?  It’ll save you time and travel.”
“Did you hear?  Cisco has an undocumented command.  It’s called “show policy-map interface”!”
“Help!  All of my routers have lost their QoS configuration!”

And so on….all fucking day long.  🙂

It’s all in good fun.  Just be aware that if you announce that you are pursuing the CCIE, every mistake you make is going to be analyzed because you are supposed to be a guru.  🙂
 

January 13, 2008

Internetwork Expert Volume II: Lab 4 – Section 7

 QoS – 7 Points

7.1 Congestion Avoidance

“…configure r1 to start dropping packets with an IP precedence of routine on this link when there are at least 15 packets in the queue.”

Sounds like WRED to me.

Configuring Weighted Random Early Detection

“routine” traffic is IP Prec 0:

r1(config-cmap)#match ip prec ?
  <0-7>           Enter up to 4 precedence values separated by white-spaces
  critical        Match packets with critical precedence (5)
  flash           Match packets with flash precedence (3)
  flash-override  Match packets with flash override precedence (4)
  immediate       Match packets with immediate precedence (2)
  internet        Match packets with internetwork control precedence (6)
  network         Match packets with network control precedence (7)
  priority        Match packets with priority precedence (1)
  routine         Match packets with routine precedence (0)

r1(config)#int fa0/0
r1(config-if)#random-detect ?
  dscp-based  Enable dscp based WRED on an inteface
  prec-based  Enable prec based WRED on an interface

r1(config-if)#random-detect prec-based

Now we have a few more options:

r1(config-if)#random-detect ?
  dscp                            parameters for each dscp value
  dscp-based                      Enable dscp based WRED on an inteface
  exponential-weighting-constant  weight for mean queue depth calculation
  flow                            enable flow based WRED
  prec-based                      Enable prec based WRED on an interface
  precedence                      parameters for each precedence value

r1(config-if)#random-detect precedence 0 15 ?
  <1-4096>  maximum threshold (number of packets)

Shit.  What is the standard queue size?  It’s easy enough to find:

r1(config-if)#do sh queueing int fa0/0
Interface FastEthernet0/0 queueing strategy: random early detection (WRED)
    Random-detect not active on the dialer
    Exp-weight-constant: 9 (1/512)
    Mean queue depth: 0

  class          Random drop      Tail drop    Minimum Maximum  Mark
                  pkts/bytes       pkts/bytes    thresh  thresh  prob
      0      0/0              0/0           20      40  1/10
      1      0/0              0/0           22      40  1/10
      2      0/0              0/0           24      40  1/10
      3      0/0              0/0           26      40  1/10
      4      0/0              0/0           28      40  1/10
      5      0/0              0/0           31      40  1/10
      6      0/0              0/0           33      40  1/10
      7      0/0              0/0           35      40  1/10
   rsvp      0/0              0/0           37      40  1/10

r1(config-if)#random-detect prec 0 15 40 ?
  <1-65535>  mark probability denominator
  <cr>

Let’s leave that at the default of 10.

r1#sh queueing int fa0/0
Interface FastEthernet0/0 queueing strategy: random early detection (WRED)
    Random-detect not active on the dialer
    Exp-weight-constant: 9 (1/512)
    Mean queue depth: 0

  class          Random drop      Tail drop    Minimum Maximum  Mark
                  pkts/bytes       pkts/bytes    thresh  thresh  prob
      0      0/0              0/0           15      40  1/10
      1      0/0              0/0           22      40  1/10
      2      0/0              0/0           24      40  1/10
      3      0/0              0/0           26      40  1/10
      4      0/0              0/0           28      40  1/10
      5      0/0              0/0           31      40  1/10
      6      0/0              0/0           33      40  1/10
      7      0/0              0/0           35      40  1/10
   rsvp      0/0              0/0           37      40  1/10

7.2 Congestion Avoidance

“…configure r5 so that all SMTP packets are guaranteed at least 1.5Mbps of the output queue on int fa0/1.”
“Do not use an access-list to accomplish this.”

The only twist on this task is whether to use LLQ or bandwidth.  “at least” screams ‘bandwidth’ to me.

r5(config-pmap-c)#bandwidth ?
  <8-2000000>  Kilo Bits per second <- Be careful
r5(config-pmap-c)#bandwidth 1500

class-map match-all SMTP
  match protocol smtp
!
policy-map SMTP
  class SMTP
   bandwidth 1500
!
interface FastEthernet0/1
 service-policy output SMTP

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

  Service-policy output: SMTP

    Class-map: SMTP (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol smtp
      Queueing
        Output Queue: Conversation 265
        Bandwidth 1500 (kbps) Max Threshold 64 (packets)
        (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0

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

7.3 Rate Limiting

“…configure r5 so that packets over 1250 bytes are limited to 2.5Mbps outbound on interface fa0/1.”

This is definitely policing.

r5(config-cmap)#match packet length ?
  max  Maximum length of packet
  min  Minimum length of packet

1250 or 1251….I chose 1251 (“over 1250”), but I would ask the proctor for clarification.

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

Ooops!!!  I didn’t notice the interface.  I already have an outbound policy on fa0/1:

interface FastEthernet0/1
 service-policy output SMTP

No problem.  I can just add this class to the existing policy-map (I should have read more carefully) rather than creating a new one.

class-map match-all POLICE_1250
  match packet length min 1251
!
policy-map SMTP
  class SMTP
   bandwidth 1500
  class POLICE_1250
   police 2500000

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

  Service-policy output: SMTP

    Class-map: SMTP (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol smtp
      Queueing
        Output Queue: Conversation 265
        Bandwidth 1500 (kbps) Max Threshold 64 (packets)
        (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0

    Class-map: POLICE_1250 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: packet length min 1251
      police:
          cir 2500000 bps,
bc 78125 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)
      427 packets, 42622 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

December 10, 2007

Quick QoS Tip

If you use the same name for all of your (MQC) QoS elements (class-map, policy-map, service-policy, etc), then you can easily see all of these elements with the section filter:

r3(config-cmap)#do sh run | sec FROM_FTP
class-map match-all FROM_FTP_SERVER
 match access-group name FROM_FTP_SERVER
policy-map FROM_FTP_SERVER
 class FROM_FTP_SERVER
  bandwidth 256
 service-policy output FROM_FTP_SERVER
ip access-list extended FROM_FTP_SERVER
 permit tcp host 132.1.33.33 132.1.6.0 0.0.0.255 eq ftp

Next Page »

Blog at WordPress.com.