CCIE Pursuit Blog

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

 

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

Internetwork Expert Volume II: Lab 2 – Section 8

Section 8 – QoS – 6 Points

8.1 was a basic QoS question that required you to “guarantee at least 256Kbps during times of congestion across the Frame Relay link [to and from an SMTP server]” 

Having just reviewed the QoS IEATC lessons, I knew that the question was asking for priority using the “bandwidth” command and not LLQ.  Easy enough, write an access-list to match traffic to and from the server on each router and configure QoS using the MQC.

One of the things to remember when using CBWFQ with Frame Relay is that you need to apply it on the interface level:

r3(config-subif)#service-policy out SMTP
CBWFQ : Not supported on subinterfaces

Also, you need to remove fair-queueing on the interface:

r3(config-if)#service-p out SMTP
Must remove fair-queue configuration first. 

I completed this task correctly…or at least I thought that I did. 

My answer:
r3
ip access-list extended TO_SMTP_SERVER
 permit tcp host 132.1.3.100 any eq smtp

r5
ip access-list extended FROM_SMTP_SERVER
 permit tcp host 132.1.3100any eq smtp

IE’s answer:
r3:
ip access-list extended SMTP_FROM_SERVER
 permit tcp host 132.1.3.100 eq smtp any

r5:
ip access-list extended SMTP_FROM_SERVER
 permit tcp anyhost 132.1.3.100 eq smtp

The users are behind r5’s e0/1 and the server is in VLAN3 on r3’s e0/0.  My simple screwup on r5 cost me some easy points.  I forgot to reverse my ACL on r5.  😦

8.2 – Policy routing.  Crap.  Another topic that I am pretty unfamiliar with.  A qucik visit to the DOC shows the following:

Configuring IP Routing Protocol-Independent Features

Enabling Policy Routing

I was able to figure out the solution from those documents.  Well, I almost figured it out.  I made a single mistake that cost me the points for this task and for 8.3 as well.

“Assume that this FTP server does not support PASV FTP connections.”

Active FTP vs. Passive FTP

I’ll have to review passive versus active FTP.  Basically, active FTP uses ports 20 (data port) and 21 (command port) while passive FTP uses port 20.  Even with this understanding I would have lost the points because I assumed that “tcp eq ftp” meant ports 20 and 21.  It turns out that it only means port 21 (command port).  You need to add an additional line (tcp eq ftp-data) to the ACL to filter the data port (20).

My answer:
ip access-list extended FROM_FTP_SERVER
 permit tcp host 132.1.33.33 132.1.6.0 0.0.0.255 eq ftp

IE’s answer:
ip access-list extended FROM_FTP_SERVER
 permit tcp host 132.1.33.33 132.1.6.0 0.0.0.255 eq ftp
 permit tcp host 132.1.33.33 132.1.6.0 0.0.0.255 eq ftp-data

This mistake made me lose points for 8.2 and for 8.3 (an easy QoS task) because they both rely on that ACL.

So I ended up 0 for 6 on the section that I thought that I had the best chance to ace.  😦

Create a free website or blog at WordPress.com.