Tuesday, March 24, 2009

CCIE ALU - FRTS and how to compute ts

Foreward: A CCIE ALU is an Autonomous Learning Unit, you can read this post to learn more about them.

 


 

 

Question:

Users have been reporting an increase in the number of dropped packets on the frame relay link between R1 and R2.  Your frame relay provider has sent you a notice that they are seeing significantly more traffic attempting to go through the frame relay link then permitted.  You have purchased 128kbit/sec of guaranteed bandwidth from the provider, but there is currently no restriction on the amount of traffic permitted out the frame relay link.  Limit the amount of traffic traversing the frame relay link to the permitted amount.  You will soon be allowing voice traffic across that link, so you must minimize delay and jitter.

 

 

 

Highlight below for the solution:

 

Solution:

map-class frame-relay FRTS

 frame-relay cir 128000

 frame-relay bc 1280

 frame-relay be 0

!

interface Serial0/0

 frame-relay traffic-shaping

 frame-relay class FRTS

 

Confirmation:

R2#show frame pvc 201

 

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

 

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

 

  input pkts 5             output pkts 5            in bytes 520      

  out bytes 520            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 0         out bcast bytes 0        

  5 minute input rate 0 bits/sec, 0 packets/sec

  5 minute output rate 0 bits/sec, 0 packets/sec

  pvc create time 1w6d, last time pvc status changed 00:00:01

  cir 128000    bc 1280      be 0         byte limit 160    interval 10 

  mincir 64000     byte increment 160   Adaptive Shaping none

  pkts 0         bytes 0         pkts delayed 0         bytes delayed 0       

  shaping inactive   

  traffic shaping drops 0

  Queueing strategy: fifo

  Output queue 0/40, 0 drop, 0 dequeued

 

 

Explanation:

Frame relay traffic shaping is the method of controlling the rate at which packets are allowed to exit an interface.  Since frame relay is a multi-access medium, FRTS specifically allows us to specify separate queues for each DLCI, therefore if you need to allow a certain amount of bandwidth between one set of routers, and a separate amount of bandwidth between another set of routers, FRTS is a great option.

 

By default there is no limit to the amount of traffic exiting an interface, therefore in this case we will be attempting to send traffic up to the full interface speed out the frame relay interface.  Since our service provider is limiting us to 128kbit/sec, it is fruitless to send more than that.

 

The most important part of this question is to understand how CIR, Bc, Be, and Tc relate mathematically.    In this case, since we are asked to minimize delay and jitter we need to set our Tc as low as possible, which is 10ms.

 

You cannot set the Tc for FRTS explicitly, therefore we must calculate it.  To obtain the Tc we want, we need to first figure out how many segments should be sent in a single second.  To do this we take 1000 ms and divide it by the desired TC:

 

1000 / 10 = 100

 

Now we take our CIR and divide it by the number of segments we will send in a given second to figure out how many bits we should send each time segment, that number will be our Bc:

 

128000 / 100 = 1280

 

FRTS will now send 1280 bits every 10ms, resulting in 128,000 bits being sent per second.

 

It is interesting to note that a router cannot actually send data at less than the interface speed.  Therefore, if our frame relay connection above is a 1.536Mbit/sec T1, FRTS will send 1280 bits in  only 0.84ms, then sit idle for 9.16ms, then repeat that process 99 more times per second, resulting in the equivalent of 128Kbit/sec.

 

If you remember the above two step process, you will always be able to calculate the Bc needed to achieve a certain Tc.

  1. Figure out how many segments should be sent in a single second    (1000ms / 10ms = 100 segments)
  2. Divide our CIR by the number of segments to send in a single second to calculate Bc (128000bps / 100 segments = 1280 bits/segment)

 

 

DocCD items to reference:

Configuration Guide (Configuring Frame Relay Traffic Shaping)

map-class frame relay

frame relay traffic-shaping

frame relay class

show frame-relay pvc

Tuesday, March 10, 2009

CCIE ALU - CBWFQ and qos-group tagging to match traffic

Foreward: An ALU is an Autonomous Learning Unit to help with CCIE lab preparation , you can read this post to learn more about them.

 


 

Question:

 

All traffic coming in Serial0/1 of R2 needs to be guaranteed 512Kbit/sec of bandwidth when exiting the frame relay interface of R2.  All traffic entering FastEthernet0/0 of R2 should be dropped if it tries to exit the frame relay interface of R2, unless it is HTTPS traffic.  No change in configuration should be required if any IP addresses change in the future.  Also, no part of the packet header should be modified in any way by this configuration.

 

 

 

 

Highlight below for the solution:

 

Solution:

R2:

class-map match-all MATCH_HTTPS

 match protocol secure-http

class-map match-all MATCH_QOS1

 match qos-group 1

class-map match-all MATCH_QOS2

 match qos-group 2

!

policy-map IN_S0-1

 class class-default

  set qos-group 1

policy-map OUT_S0-0

 class MATCH_QOS1

  bandwidth 512

 class MATCH_QOS2

   drop

policy-map IN_FA0-0

 class MATCH_HTTPS

 class class-default

  set qos-group 2

!

interface FastEthernet0/0

 service-policy input IN_FA0-0

interface Serial0/1

 service-policy input IN_S0-1

interface Serial0/0

 service-policy output OUT_S0-0

 

 

Confirmation:

R2#show policy-map interface

 FastEthernet0/0

 

  Service-policy input: IN_FA0-0

 

    Class-map: MATCH_HTTPS (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0 bps

      Match: protocol secure-http

 

    Class-map: class-default (match-any)

      45 packets, 670 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: any

      QoS Set

        qos-group 2

          Packets marked 45

 Serial0/0

 

  Service-policy output: OUT_S0-0

 

    Class-map: MATCH_QOS1 (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: qos-group 1

      Queueing

        Output Queue: Conversation 265

        Bandwidth 512 (kbps)Max Threshold 64 (packets)

        (pkts matched/bytes matched) 0/0

        (depth/total drops/no-buffer drops) 0/0/0

 

    Class-map: MATCH_QOS2 (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: qos-group 2

      drop

 

    Class-map: class-default (match-any)

      33 packets, 462 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: any

 Serial0/1

 

  Service-policy input: IN_S0-1

 

    Class-map: class-default (match-any)

      15 packets, 150 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: any

      QoS Set

        qos-group 1

          Packets marked 15

 

 

Explanation:

Qos-group is a flag that can be set and matched on packets, and is local to the router; that is, it is not an industry standard flag, or a flag that is part of the IP or Ethernet headers.  The qos-group is very useful because it allows you to apply QOS policy without modifying a packet.  For example, in the above question we could have set a DSCP or IP Precedence value, then matched based on that.  However, that would modify the packet and change those values; which might have been set by other devices in the network.

 

In this example we are setting QOS Group 1 on any packets entering the PPP serial link from R3 using the policy-map IN_S0-1.  We are also setting QOS Group 2 on any non-HTTPS packet entering FastEthernet0/0 using policy-map IN_FA0-0.  We are then reserving bandwidth for QOS Group 1, and dropping QOS Group 2 in policy-map OUT_S0-0.

 

An important point to remember is that policy-maps are "first hit exit" policies.  Meaning traffic is compared to each class within the policy-map, and as soon as it finds one that matches, the actions in that class are executed and the policy-map is exited.  In the example of IN_FA0-0 we can see that we are matching HTTPS traffic, and applying no action to it.  All other traffic hits the class class-default and has a QOS-GROUP 2 set on it.  An alternative to this configuration would be to set QOS-GROUP 2 on all traffic entering FastEthernet0/0, then in policy-map OUT_S0-0 you could match HTTPS and do nothing to it, thereby bypassing the drop associated with QOS GROUP 2.  Both options are valid and would be awarded full credit in the CCIE lab.

 

DocCD items to reference:

Configuration Guide (Class-Based Weighted Fair Queueing Configuration Task List)

class-map

policy-map

match protocol

drop (in a class-map)

set qos-group

service-policy in

service-policy out

show policy-map interface

Thursday, March 5, 2009

CCIE ALU - CBWFQ Part 4, CBWFQ as a Security Feature

Foreward: An ALU is an Autonomous Learning Unit, you can read this post to learn more about them.

 

 

 

Question:

 

Users in subnet 1.1.124.0/24 have been using Kazaa and edonkey to download illegal music files.  Company policy prohibits downloading illegal music, and your CIO would like you to stop Kazaa and Edonkey traffic.  User's default gateway is 1.1.124.2.

 

 

 

Highlight below for the solution:

 

Solution:

R2:

class-map match-any DROP_TRAFFIC

 match protocol kazaa2

 match protocol edonkey

!

policy-map QOS2

 class DROP_TRAFFIC

   drop

!

interface FastEthernet0/0

 service-policy input QOS2

 

Confirmation:

R2(config)#do sh policy-map interface FastEthernet0/0

 FastEthernet0/0

 

  Service-policy input: QOS2

 

    Class-map: DROP_TRAFFIC (match-any)

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: protocol kazaa2

        0 packets, 0 bytes

        5 minute rate 0 bps

      Match: protocol edonkey

        0 packets, 0 bytes

        5 minute rate 0 bps

      drop

 

    Class-map: class-default (match-any)

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: any

 

 

Explanation:

One great feature of Class Based Weighted Fair Queueing (CBWFQ) is the option to assign the action "drop" within a policy-map, turning CBWFQ into a security tool.  Combined with NBAR to perform deep inspection on packets, you can selectively drop traffic based on application.

 

Keeping in mind that CBWFQ can be used to drop traffic is a great way to address questions that prevent you from using all of the traditional security tools such as access-lists, it also allows you to drop very specific traffic such as Kazaa and Edonkey.

 

Additionally, this question shows the "match-any" keyword on a class-map.  By default, a class-map with multiple match statements is a "match-all" class-map.  That means if you had a class match that matched an access-list and a DSCP value, both items would need to be true for that class-map to apply.  However, in this case we are matching two applications, so a "match-all" class-map would never match, since traffic cannot be BOTH applications.  By using the "match-any" keyword, we can use fewer class-maps to match the traffic.

 

In this question we apply the policy-map in the inbound direction on FA0/0, however we could have also applied it outbound on Serial0/1 of R2.  It is best to block traffic as close to the source as possible, so I blocked it inbound at FastEthernet0/0.

 

 

DocCD items to reference:

Configuration Guide (Class-Based Weighted Fair Queueing Configuration Task List)

class-map

policy-map

match protocol

drop (in a class-map)

service-policy in

show policy-map interface