I was asked today how to calculate the Bc values. The known formulas always add confusion. So the aim of this article is not to add more confusion, but offer an easy alternate way to calculate the Bc values used with shaping.
First lets review some basic shaping definitions.
CIR (Committed Information Rate)
- Dictates the output rate one aims to average per second on the circuit/interface.
- Book formula : CIR = Bc / (Tc/1000)
- It is the time in milliseconds into which a second is divided for transmission intervals.
- The Tc can’t be adjusted directly, but it can be changed by setting the Bc to a specific value..
- The maximum value of Tc is 125ms (8 intervals per second) and the minimum value is 10ms (100 intervals per second).
- Actually 8ms (125 intervals per second) on distributed platforms. On distributed platforms, the Tc must be defined in 4-ms increments. The nearest multiple of 4 ms within the 10-ms target is 8 ms.
- Book formula : Tc = (Bc / CIR) x 1000
Bc (Committed Burst Rate)
- Bc is the number of committed bits allowed to be sent per interval (Tc) to conform with the target-rate (CIR) per second.
- If Bc worth of bits are sent every interval in a second, the output rate is the CIR.
- Book formula : Bc = CIR x (Tc/1000)
Continue reading “Working out Bc values quickly”
Often knowing the necessary show commands is not enough, you need to understand the output.
Here is a good example and breakdown of each of the fields with the command:
VC = 'DLCI's'
Access List = 'Used to shape traffic of common type for separation'
Target Rate = 'CIR in bits'
Byte-Limit = 'Bc+Be ie the size the token bucket, express in BYTES'
Sustain bits/int = 'Bc value per Tc, (int is short for interval or Tc)'
Excess bits/int = 'Be value'
Interval (ms) = 'Tc value'
Increment (bytes) = 'How many bytes of token replenished each Tc, ie Bc value in bytes'
Adapt Active = 'Shows Adaptive shaping has been enabled. If a BECN is received, the flow is throttled back'
What else can be set about the configuration here?
The interface have 3 DLCI’s defined.
DLCI’s 413 and 405 have a CIR of 56k. This was not configured. This is default behaviour. When ‘frame-relay traffic-shaping’ is enabled each DLCI on that interface will be allocated a 56k CIR unless changed. Here it is clear that DLCI 403 has a map-class policy applied.
Oh and Merry Christmas guys :D
Serialization/Access-Rate is the physical clocking speed of the interface (ie 64-kbps/128-kbps etc), which determines the amount of data that can be encapsulated on to the wire.
Serialization Delay or Serialization Rate is a constant based on the access rate of the interface. It is the time needed to place data on the physical wire.
These values are set in hardware and cannot be changed.
A data frame can be sent onto the physical wire ONLY at the serialization rate of the interface. Thus serialization delay is the size of the frame in bits divided by the clocking speed of the interface.
Serialization Delay = Frame Size/Link Speed
For example, a 1500-byte frame (12000-bits/64000-bits) will take 187.5ms to serialize (put on the wire) on a 64-kbps circuit.
|| Frame Size (Bytes)
For low-speed WAN connections (those with a clocking speed of 768kbps or below), it might be necessary to provide a mechanism for Link Fragmentation and Interleaving (LFI) when running delay sensitive application like voice.
Continue reading “Serialization Delay?”
I saw someone removing a Policy-Map and the associated Class-Maps, just to rename the class-map to the correct naming standard. And although the intention was great conforming to network standards, there is an easier way.
Within the class-map and the Policy-Map there is a rename option. What is really cool, Mr IOS will update the mappings that are in use or referenced by that name auto-magically.
Take the following Class-Map and Policy-Map I ‘errornously’ created:
Continue reading “Renaming Class-maps and Policy-maps”
One of the most feared technologies by CCIE candidates is QOS (Quality of Service). This is understandably because most first world countries seldom have problems with bandwidth or getting more if needed. So the necessity for juggling traffic around, by means of QOS strategies is almost non existent. On the other hand, engineers in developing countries tend to be familiar with various QOS technologies, because of frequent bandwidth shortages as a result of the high bandwidth costs.
In my previous article I covered the difference in structures between the original TOS-Byte Field and the Diff-Serv Field which supersedes it.
Here is a concise table listing the all the values for both BYTE fields:
TOS-BYTE = (3bits IP PREC + 5bits legacy)
|IP Precedence Description
IP PREC Binary
|IP PREC Decimal Value
Continue reading “QOS Priority Levels”
In the previous article I showed how useful Netflow can be, but that is only the beginning. The “verbose” output provides even more useful information, specifically the TOS-Byte. That field is necessary when you want to verify if QOS marking is correctly applied to traffic classes.
But first you have to understand a little about QOS (Quality of Service) and the TOS-byte/DS-Field in the IP header.
The IP header is defined in RFC 791, includes a 1-byte ﬁeld called the Type of Service (ToS) byte. The ToS byte was intended to be used as a ﬁeld to mark a packet for treatment with QoS tools. The ToS byte itself was initially further subdivided, with the high-order 3 bits defined as the IP Precedence (IPP) ﬁeld. Bits 3 through 6 were not used very often, and bit 7 was never defined, so over time the entire ToS byte’s purpose was to hold the 3-bit IPP ﬁeld. 3 bits (23 = 8 ) allowed 8 possible markings.
Continue reading “Using Netflow’s verbose output with QOS”
- Class class-default need “fair-queue” if “bandwidth” was not specified.
- When using “ip rsvp bandwidth” on a sub-interfaces, it is also required to be configured on the main interface.
- When using multiple sub-interfaces with “ip rsvp bandwidth”, the main interface should be configured to be the sum all sub-interfaces.
- RSVP requires fair-queue to be enabled. With FRTS, WFQ is disabled by default, re-enable with “frame-relay fair-queue” in the map-class.
- When doing MQC configurations using the bandwidth percent command, do not forget to change the “max-reserve-bandwidth %”.
- Custom queueing defaults – Byte-count = 1500 bytes & Queue-limit = 20.
- Know the NBAR mime categories: “image/*” or “audio/*” or “application/*” or “text/*”
- Voice EF class = 46 decimal and 101110 in dscp-binary.
- FRTS formulas:
Bc = CIR * Tc
Be = (CAR – CIR) * Tc
Bc = CIR / 8 * Tc (Default Tc = 1.5 seconds)
Be = 2 * Bc
Although NBAR is an extremely powerful tool that CISCO IOS has to offer, many guys still dont know how use the match statements correctly.
You can use NBAR to block almost any part website or the content there of. It is most useful to block those bandwidth hungry websites that contains pictures, videos, music or even flash.
The match protocol HTTP function is what you will need to use.
Firstly to match just the HOSTNAME of the website:
match protocol http host *facebook.com*
! This would match any hostname containing the string
! 'facebook.com' like http://www.facebook.com
! or http://login.facebook.com
match protocol http host *google*
! This would match any hostname containing the word google
! like http://mail.google.com or http://www.google.co.za
! or http://images.google.com
match protocol http host google*
! This would match http://google.co.za but
! not http://mail.google.com
Secondly to match certain URL strings:
Continue reading “Using NBAR to match web traffic”