Tag: QOS

Serialization Delay?

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.

Link- Frame Size (Bytes)
Speed 64 128 256 512 1024 1500
64 kbps 8 ms 16 ms 32 ms 64 ms 128 ms 187 ms
128 kbps 4 ms 8 ms 16 ms 32 ms 64 ms 93 ms
256 kbps 2 ms 4 ms 8 ms 16 ms 32 ms 46 ms
512 kbps 1 ms 2 ms 4 ms 8 ms 16 ms 23 ms
768 kbps 0.640 ms 1.28 ms 2.56 ms 5.12 ms 10.4 ms 15 ms

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?” →

Advertisement

Renaming Class-maps and Policy-maps

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.

Class-Maps

Take the following Class-Map and Policy-Map I ‘errornously’ created:

cmpm-1 Continue reading “Renaming Class-maps and Policy-maps” →

Top Talkers

Every quickly wanted to see the current top-talkers on a link?
Who that culprit is, that is using all the bandwidth?

Although you can use normal netflow output to work that out using the packet count or by using some external cache-flow interpreter, it is much easier to just enable netflow top-talkers.

To enable and enter top-talkers configuration mode:
(config)#ip flow-top-talkers

Continue reading “Top Talkers” →

QOS Priority Levels

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

(3 bits)

 IP PREC Decimal Value
ROUTINE 000 0
PRIORITY 001 1
IMMEDIATE 010 2
FLASH 011 3
FLASHOVERRIDE 100 4
CRITICAL 101 5
INTERNETWORK CONTROL 110 6
NETWORK CONTROL 111 7

Continue reading “QOS Priority Levels” →

Using Netflow’s verbose output with QOS

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 field called the Type of Service (ToS) byte. The ToS byte was intended to be used as a field 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) field. 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 field. 3 bits (23 = 8 ) allowed 8 possible markings.

Tos-Byte

Continue reading “Using Netflow’s verbose output with QOS” →

R&S Quick Notes – QOS

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

  • WRED formula:

= (1/MPD)

  • CAR (Police) formula:

Bc = CIR / 8 * Tc           (Default Tc = 1.5 seconds)

Be = 2 * Bc