Tuesday, February 24, 2009

ALU - CBWFQ Part 3, Time Specific QOS

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

 

 

 

Question:

 

Users in the 1.1.124.0/24 subnet are accessing a stock trading web site on web server with the IP address 1.1.3.25.  Users are reporting that every afternoon between 3:00 PM and 5:00 PM, in the final minutes of trading, the responsiveness of the web server becomes very poor.  You have traced the issue down to an automated FTP transfer that occurs during this time.  Guarantee 1Mbit/sec of bandwidth for web traffic to and from the web server across the serial link between R2 and R3.  Access-lists should be as specific as possible.  This QOS should only be applied during the two hours listed above, and only on weekdays.

 

Note: This question is an extension of the previous question, ALU - CBWFQ Part 2.

 

 

Highlight below for the solution:

 

Solution:

R3:

access-list 102 remark Traffic from server to clients

access-list 102 permit tcp host 1.1.3.25 eq www 1.1.124.0 0.0.0.255 time-range TRADING_HOURS

!

class-map match-all HTTP_STOCK

 match access-group 102

!   

policy-map QOS1

 class HTTP_STOCK

  bandwidth 1000

!

interface Serial1/3

  service-policy output QOS1

 

R2:

access-list 102 remark Traffic from clients to server

access-list 102 permit tcp 1.1.124.0 0.0.0.255 host 1.1.3.25 eq www time-range TRADING_HOURS

!

class-map match-all HTTP_STOCK

 match access-group 102

!   

policy-map QOS1

 class HTTP_STOCK

  bandwidth 1000

!

interface Serial0/1

  service-policy output QOS1

 

Confirmation:

R2(config)#do show policy-map int

 Serial0/1

 

  Service-policy output: QOS1

 

    Class-map: HTTP_STOCK (match-all)

      0 packets, 0 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: access-group 102

      Queueing

        Output Queue: Conversation 265

        Bandwidth 1000 (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)

      295 packets, 18144 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: any

 

R2(config)#do sh access-list 102

Extended IP access list 102

    10 permit tcp 1.1.124.0 0.0.0.255 host 1.1.3.25 eq www time-range TRADING_HOURS

 

 

 

Rack1R2#clock set 13:30:00 feb 20 2009

Rack1R2#sh access-list 102

Extended IP access list 102

    10 permit tcp 1.1.124.0 0.0.0.255 host 1.1.3.25 eq www time-range TRADING_HOURS (inactive)

Rack1R2#sh time-range

time-range entry: TRADING_HOURS (inactive)

   periodic weekdays 15:00 to 16:59

   used in: IP ACL entry

Rack1R2#clock set 15:30:00 feb 20 2009

Rack1R2#

Rack1R2#sh access-list 102

Extended IP access list 102

    10 permit tcp 1.1.124.0 0.0.0.255 host 1.1.3.25 eq www time-range TRADING_HOURS (active)

Rack1R2#sh time-range

time-range entry: TRADING_HOURS (active)

   periodic weekdays 15:00 to 16:59

   used in: IP ACL entry

 

 Explanation:

This question combines knowledge of CBWFQ and basic knowledge of what ports traffic uses as source and destination ports.  For a detailed explanation of how a CBWFQ policy is put together, see my previous post ALU - CBWFQ Part 1.

 

When a client establishes a TCP connection to a server it selects a random "high port" to use as its source port, and it puts the well-known port for the application it is trying to reach as its destination port.  In this case, a client accessing the web server will have a source IP address of 1.1.124.0/24, a random source port, a destination IP address of 1.1.3.25, and a destination port of 80.  Conversely, the web server will generate the mirrored traffic; a source IP of 1.1.3.25, a source port of 80, a destination IP of 1.1.124.0/24, and a random destination port to match the client's random source port.

 

Note, with regards to the part of the question that requires specific access-lists, it would be worth asking the Proctor if the above access-lists are sufficiently specific, or if you need to scope it even further because the client will use a random high port as a source port.  It is not likely that the CCIE lab is testing that, it would be looking to make sure you know a server's source port is the well-known port, and the client's destination port is the well-known port.  Also, since different operating systems use a different set of "high ports," there is not a definitive answer to what a high port should be.  Reference: Wikipedia: "Ephemeral port"

 

This question is an extension of the question ALU - CBWFQ Part 2 because it adds the requirement that the QOS should only be active during a certain time range.  Since the time in a time-range command continues until the 59th second of the stated time, it is most precise to configure the time range as "periodic weekdays 15:00 to 16:59" which is 3:00:00 PM through 4:59:59 PM.  In general, the CCIE lab is not concerned with that degree of specificity.  In all likelihood, the Proctor or grading script will set two times like the above confirmation section does, and neither will be within seconds of the time-range activating.  If your lab has a question that mentions specific times, it is best to ask the proctor for clarification.

 

DocCD items to reference:

Configuration Guide (Access Control Lists: Overview and Guidelines)

class-map

policy-map

match access-group

bandwidth

service-policy out

time-range

show policy-map interface

No comments:

Post a Comment