Leaky Bucket Rate Limiting

Most M-series router interfaces support transmit and receive rate limiting using a leaky-bucket algorithm that acts to shape the traffic leaving or arriving on a particular interface. Currently, all interface types support this type of rate limiting, with the exception of ATM, Fast Ethernet, and Gigabit Ethernet interfaces. Internet Processor II (IP II) policers employ a token bucket- policing scheme and can be deployed on any interface type.

Configure Leaky Bucket Rate Limiting

This configuration example will demonstrate leaky-bucket configuration and verification techniques using the topology shown in Figure 2.9.

Figure 2.9: Leaky bucket rate limiting

The criteria for this configuration are as follows:

• Limit r3's so-0/2/0 interface to operate at no more than five percent of the OC-3c inter- face's bandwidth. Do not rate limit r5's so-0/1/0 interface.

• Use default encapsulation.

• Ensure that excess data is not delivered and do not allow bursting.

The following commands correctly configure the transmit bucket on r3's so-0/2/0 interface:

[edit interfaces so-0/2/0] lab@r3# set transmit-bucket rate 5 [edit interfaces so-0/2/0] lab@r3# set transmit-bucket threshold 0 [edit interfaces so-0/2/0] lab@r3# set transmit-bucket overflow discard 

This configuration sets the bucket's drain rate to five percent of the ~148Mbps OC-3 pay- load rate (approximately 7.43Mbps), and sets a burst threshold of 0 to disable bursting above the bucket's specified rate. To ensure that excess data is never delivered, the discard action has been configured for data that overflows the bucket. Because M-series router PICs cannot support SONET payload scrambling in conjunction with leaky bucket traffic shaping, the operator must explicitly disable the default SONET payload scrambling behavior in order to commit the rate-limiting configuration:

[edit interfaces so-0/2/0] lab@r3# set sonet-options no-payload-scrambler 

Note 

Although the configuration scenario states that r5's so-0/1/0 interface is not to be rate-limited, you must disable SONET payload scrambling on this interface to make it compatible with r3's setting. Failure to do this will result in a communications failure, with the primary symptom being a device down flag at the logical-interface level.

After configuring the interface's receive bucket with identical parameters, r3's so-0/2/0 interface configuration is shown with token bucket-related entries highlighted:

[edit interfaces so-0/2/0] lab@r3# show receive-bucket {     overflow discard;     rate 5;     threshold 0;  }  transmit-bucket {     overflow discard;     rate 5;     threshold 0; }  sonet-options {     no-payload-scrambler;  }  unit 0 {     family inet {    address 10.0.10.3/24;  }  } 

Verify Leaky Bucket Rate Limiting

You can view leaky bucket-related statistics and configuration settings by using the extensive switch with the show interfaces command. The following example highlights the leaky bucket-related fields. The extensive output shown next has been edited for brevity:

lab@r3> clear interfaces statistics all lab@r3> show interfaces so-0/2/0 extensive Physical interface: so-0/2/0, Enabled, Physical link is Up  . . .  FCS: 16, Payload scrambler: Disabled  Device flags   : Present Running  Interface flags: Point-To-Point SNMP-Traps  Link flags     : Keepalives  Hold-times     : Up 0 ms, Down 0 ms  . . .  Input errors:    Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Giants: 0, Bucket drops: 0,    Policed discards: 0, L3 incompletes: 0, L2 channel errors: 0, L2 mismatch   timeouts: 0,    HS link CRC errors: 0, HS link FIFO overflows: 0  Output errors:    Carrier transitions: 0, Errors: 0, Drops: 0, Aged packets: 0,    HS link FIFO underflows: 0  . . .  HDLC configuration:    Policing bucket: Enabled, Bit rate: 5 , Threshold: 0    Shaping bucket : Enabled, Bit rate: 5 , Threshold: 0    Giant threshold: 4484, Runt threshold: 3  . . . 

The highlighted fields in this display indicate that leaky bucket rate limiting has been correctly configured for this example. To further test the effects of your rate-limiting configuration, you can use r5 to generate flood pings targeted at r3 by issuing a ping rapid count 20000 size 4000 10.0.10.4 command while the traffic level on r3's so-0/2/0 interface is monitored.

Note 

The use of the Routing Engine to generate flood pings is not recommended in a production network because the internal fxp1 link between the RE and PFE is intended for other purposes. The fact that control traffic will take priority over ICMP messages will cause variations in your test results in a production network, especially when routing protocols are converging. Note that the extremely large packet size used in this example was chosen to maximize the amount of traffic produced by the RE. The 4474-byte MTU settings on the SONET interfaces will cause packets of this size to be fragmented by the PFE in both directions.

Figure 2.10 shows the observed traffic load on r3 when the leaky-bucket policer is deactivated, while Figure 2.11 shows the effects of enabling the leaky buckets.

Figure 2.10: Deactivated leaky buckets

Figure 2.11: Leaky buckets activated

Figure 2.10 shows that, in the absence of leaky-bucket policing, the flood pings coming from r5 produce approximately 14Mbps of input traffic on r3's so-0/2/0 interface. Note that the input and output traffic are balanced, which indicates that r3 is able to respond to the ICMP echo packets received from r5.

Figure 2.11 shows the r3's so-0/2/0 interface's input rate has dropped to approximately 214Kbps once the policers are activated on r3. This is because virtually none of the fragmented ICMP packets are allowed to pass through r3's receive bucket unscathed. This point is evidenced by the low output rate of 48bps, which indicates that the r3's RE is not able to reassemble the IP packet fragments such that no echo response traffic can be sent back to r5.

You may wonder why the input rate at r3 is not closer to the expected value of 7.4Mbps. This behavior is the result of the monitor interface command being designed to tabulate only the amount of valid layer 3, or IP, traffic observed. In this case, the 4474-byte MTU of the SONET interfaces means that the discard of a single byte of data will result in the loss of (and failure to count) the remaining 4473 bytes associated with that packet.

Changing the data size to 4000 bytes on r5 allows the echo request packets to pass through r3's receive bucket, causing r3's so-0/2/0 interface to register a receive rate of approximately 5.7Mbps with no observed bucket-induced drops. This value begins to approach the maximum data rate associated with the configured rate limit, which confirms proper rate-limiting to the extent possible, considering the coarse nature of tests conducted with RE-generated traffic streams.

To further confirm that the packet loss is related to the leaky buckets, r3's interface statistics are cleared and the bucket's drop count is displayed both before and after r5 generates exactly 20 flood pings using a 40,000-byte packet size. The results indicate that each attempt to send an ICMP echo packet with a 40,000-byte data field results in six bucket drops on r3:

lab@r3> clear interfaces statistics all lab@r3> show interfaces so-0/2/0 extensive | match Bucket    Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Giants: 0, Bucket drops: 0,    Policing bucket: Enabled, Bit rate: 5 , Threshold: 0    Shaping bucket : Enabled, Bit rate: 5 , Threshold: 0

After r5 generates 20 40,000-byte packets, r3's bucket drops are once again displayed:

lab@r3> show interfaces so-0/2/0 extensive | match Bucket    Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Giants: 0, Bucket drops: 120,    Policing bucket: Enabled, Bit rate: 5 , Threshold: 0    Shaping bucket : Enabled, Bit rate: 5 , Threshold: 0