We have completed the upgrade of IEOC! All posts, comments and user profiles have been migrated. For security reasons, we have reset all passwords. To set a new password please Click Here. Further updates soon to follow.

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.



  • 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&nbsp; Click to collapse<br />R4:<br />!<br />! All HTTP traffic<br />!<br />ip access-list extended HTTP<br />&nbsp;permit tcp any eq 80 any<br />!<br />class-map HTTP<br />&nbsp;match access-group name HTTP<br /><br />!<br />! Traffic from R1 and R6 respectively<br />!<br />ip access-list extended FROM_R1<br />&nbsp;permit ip host any<br />!<br />ip access-list extended FROM_R6<br />&nbsp;permit ip host any<br />!<br />!<br />!<br />class-map FROM_R1<br />&nbsp;match access-group name FROM_R1<br />!<br />class-map FROM_R6<br />&nbsp;match access-group name FROM_R6<br /><br />!<br />! Nested policers (subrate)<br />!<br />policy-map SUBRATE_POLICER<br />&nbsp;class FROM_R1<br />&nbsp; police 64000 3200 4800<br />&nbsp;&nbsp; conform-action set-prec-transmit 1<br />&nbsp;&nbsp; exceed-action set-prec-transmit 0<br />&nbsp;&nbsp; violate-action set-prec-transmit 0<br />&nbsp;class FROM_R6<br />&nbsp; police 64000 3200 4800<br /><br />&nbsp;&nbsp; conform-action set-prec-transmit 1<br />&nbsp;&nbsp; exceed-action set-prec-transmit 0<br />&nbsp;&nbsp; violate-action set-prec-transmit 0<br /><br />!<br />! Policer configuration using MQC syntax.<br />!<br />policy-map POLICE_VLAN146<br />&nbsp;class HTTP<br />&nbsp;&nbsp; police 128000 3200 4800<br />&nbsp;&nbsp;&nbsp; conform-action transmit<br />&nbsp;&nbsp;&nbsp; exceed-action set-prec-transmit 0<br />&nbsp;&nbsp;&nbsp; violate-action drop<br />&nbsp;&nbsp; service-policy SUBRATE_POLICER<br />!<br />interface FastEthernet 0/1<br />&nbsp; service-policy input POLICE_VLAN146<br /><br />

Sign In or Register to comment.