Cisco – TX-ring-limit Values

ciscoqosrouterswitch

So, I am getting deep into my CCIE study and I just read about the TX-ring-limit interface command. I have used QoS a bit to oversubscribe software buffers to prevent frame loss on switches and whatnot, can you use the "TX-ring-limit" in a similar manner to decrease the likelihood of frame loss during bursty traffic on a LAN?

Additionally I understand the following:
1) TX-ring-limit should be set to either a value of 1 or 2 for a low speed interface such as a T1 serial
2) Higher values can be configured on higher speed interfaces
3) Setting a high value can introduce jitter on a link because the software queue of a IOS device will send the packets to the hardware queue where they are simply FIFO

Has anyone experimented with setting this to a higher value on ethernet LAN interfaces to allow the hardware queue to "hold on to frames" during a bursty traffic period, rather than drop them?

Best Answer

The TX-Ring is the hardware interface queue and is FIFO. QOS does NOT begin to operate in a router until the TX-Ring is full. The tradeoff is a small TX-Ring causes QoS to cut in quicker (good when you want to use LLQ for VoIP) at the cost of CPU, a large TX-Ring uses less cpu (don't need to service the queue as much) but will increase jitter (remember that the queue is Fifo) for voip applications. This is an important VoIP tuning knob on the older cisco routers for the above reasons.

It does not impact drops because TX-Ring only exists in routers and when the tx ring is full traffic is queued in router memory.

Related Solutions

Cisco – Output Drops on Serial interface: Better queueing or Output queue size

You're right, you wouldn't really see the burstiness easily on SNMP. 1GE can send 1.48Mpps, so it takes very very little time to congest the the 45Mbps, which can handle less than 75kpps.

If your ingress is 1GE and egress is 45Mbps, then obviously the congestion point of 45Mbps will need to drop packets. This is normal and expected. If you increase buffers you'll introduce more delay.
1GE takes 0.45ms to send 40 1500B IP frames, which is right now the amount of burst you can handle. However dequeueing them on the 45Mbps already takes 10ms.

If you don't have any acute problem, I would probably not do anything about it. But if some traffic is more eligible for dropping than other, then you should replace FIFO with class-based queueing. Say maybe you want to prioritize so that more ftp is dropped and less voip.
Then it'll also make more sense to add more buffering on the ftp traffic, as it's not really sensitive to delay.

If you want to try your luck with deeper buffers, something like this should suffice:

policy-map WAN-OUT
 class class-default
    fair-queue
    queue-limit 200 packets
!
interface Serial1/0
  service-policy output WAN-OUT

This would cause 50ms buffers on the Serial1 and would allow you to handle up-to 2.25ms burst from single Gige interface.

Switch – Spanning Tree Default Priority Values

In the spanning tree algorithm the process of determining the root bridge is based on the bridge priority (BID).

When there were no VLANs (meaning that switches had to deal with only one broadcast domain) the BID was equal to:

Bridge priority - MAC Address
   <2 bytes>       <6 bytes>

As Network administrators we can modify the bridge priority value.

When VLANs were introduced the needing of differentiating the STP protocol raised (Per VLAN Spanning Tree - PVST).

To accomplish this the bridge priority value was modified as follows:

Bridge priority - Exstended system ID (VLAN ID)
     4 bit      -           12 bit

We are still able to modify the bridge priority but this means to operate to the 4th most significative bit over 16 bits.

To put it simple:

Legend : C= changeable ; U= unchangeable

CCCCUUUUUUUUUUUU 16 bits

0001UUUUUUUUUUUU 1*2^12 = 4096

0111UUUUUUUUUUUU Default: 32768

0111000000000001 Default for VLAN 1: 32769

Best Answer

Related Solutions

Cisco – Output Drops on Serial interface: Better queueing or Output queue size

Switch – Spanning Tree Default Priority Values

Related Topic