in
IEOC CCIE Forums

IEOC - INE's Online Community

Welcome to INE's Online Community - IEOC - a place for CCIE and CCENT candidates to connect, share, and learn. Our Online Community features CCIE forums and discussions for all tracks including Routing & Switching, Voice, Security, Service Provider, Wireless,, and Storage. Through these online communities you can discuss your questions with thousands of your peers, hundreds of CCIE's and INE's own team of world renowned CCIE instructors and authors, Brian Dennis - Quintuple CCIE #2210, Brian McGahan – Triple CCIE #8593, Petr Lapukhov - Quad CCIE #16379, and Mark Snow - Dual CCIE #14073.
Latest post 03-18-2015 9:12 AM by rllove01. 0 replies.
Page 1 of 1 (1 items)
Sort Posts: Previous Next
  • 03-18-2015 9:12 AM

    CCIE R&S (v4) Volume 1

    I know it's V4 but trying to gleam as much knowledge as I can that will still be valid for v5 before I upgrade my lab etc.  Anyways, I was working on the qos topics and while I get policing/shaping etc I am still struggling with the smaller details. 

    10.25 MQC Hierarchical Policers is one of them. See below for the tasks and configurations. I understand what is happening here mostly.  R4 on it's FE interface facing vlan 146 is shapping all http traffic to 128k while matching HTTP traffic from both R1 and R6 and policing them both to 64k.  Its policing them both down respectively to 64k but not dropping instead re-marking and transmitting. 

    The tasks verification had me shut down the Frame Relay link between R4 and R5 to force traffic across the serial link connecting R4 and R5.  The general idea is that the link between R4 and R5 is set to 128Kbps and the traffic flows will eventually oversubscribe it. 

    Now during testing it stated to send http traffic only from R1 intially.  R1 accounted for most of the allowed traffic on the parent policy but half of that was violated on the nested/child policy.  This was expected though it did surprised me that none of the R1 HTTP packets counted in the exceed category. They went straight from confirm to violate and honestly I can only assume that when it jumped up from confirm levels it did so fast enough to completely avoid a single packet falling into exceed. 

    The main thing I can't figure out is the last verification step.  It had me start  another traffic flow from R6 via http.  Once started I confirmed that we did indeed in the parent policy reach the intended police rate of 128k but that both the child policies or second-level policers meter input rates where close to 64kbps with no violating traffic.  The workbook stated this was because of the Serial interface on R4 connecting to R5 which was running WFQ. I understand WFQ and but I'm confused as to how the outbound interface on R4 affected the inbound policer on the FA interface of R4.  My understanding is that the policer measures and limits traffic inbound on the FA link facing vlan146 and bases it's drops/exceeds solely on that alone.  The input Q of the FA interface is FIFO and isn't using WFQ. The document stated it was due to the outbound serial interface on R4 using WFQ as per the reason each policier conformed and never dropped.  Is there a relation or piece of information that I am missing or overlooking?  

    Could it be due to the fact that the HTTP flow is tcp and if the serial connection is congested that TCP windowing is kicking in slowing the rate of traffic? If so why did we see all the drops in the fist check with just R1 sending HTTP?  Am I to assume that if it was TCP Windowing that maybe the first flow wasn't sending enough to put congestion on the serial link before it started dropping packets at the policier?  Wouldn't the drop packets on the policer trigger TCP Windowing as well at that point? 

     

    Thank you all for your time in reading and responding.

     

    Task

    • Configure R4 to limit the aggregate rate of HTTP traffic entering the connection to VLAN 146 to 128Kbps.
    • Transmit conforming packets, mark exceeding packets with an IP precedence of zero, and drop violating packets.
    • For HTTP traffic flows from R1 and R6, limit the rate to 64Kbps for each flow.
    • For these second-level policers, set the conform action to set the IP precedence to 1 and transmit, the exceed action to set the IP precedence to 0 and transmit, and the violate action to set the IP precedence to 0 and transmit

     

     

    Configuration  Click to collapse
    R4:
    !
    ! All HTTP traffic
    !
    ip access-list extended HTTP
     permit tcp any eq 80 any
    !
    class-map HTTP
     match access-group name HTTP

    !
    ! Traffic from R1 and R6 respectively
    !
    ip access-list extended FROM_R1
     permit ip host 155.1.146.1 any
    !
    ip access-list extended FROM_R6
     permit ip host 155.1.146.6 any
    !
    !
    !
    class-map FROM_R1
     match access-group name FROM_R1
    !
    class-map FROM_R6
     match access-group name FROM_R6

    !
    ! Nested policers (subrate)
    !
    policy-map SUBRATE_POLICER
     class FROM_R1
      police 64000 3200 4800
       conform-action set-prec-transmit 1
       exceed-action set-prec-transmit 0
       violate-action set-prec-transmit 0
     class FROM_R6
      police 64000 3200 4800

       conform-action set-prec-transmit 1
       exceed-action set-prec-transmit 0
       violate-action set-prec-transmit 0

    !
    ! Policer configuration using MQC syntax.
    !
    policy-map POLICE_VLAN146
     class HTTP
       police 128000 3200 4800
        conform-action transmit
        exceed-action set-prec-transmit 0
        violate-action drop
       service-policy SUBRATE_POLICER
    !
    interface FastEthernet 0/1
      service-policy input POLICE_VLAN146

    • Post Points: 5
Page 1 of 1 (1 items)
IEOC CCIE Forums Internetwork Expert CCIE Training
About IEOC | Terms of Use | RSS | Privacy Policy
© 2010 Internetwork Expert, Inc. All Rights Reserved