642-642 QOS VIDEO TRAINING: Traffic Shaping

642-642 QOS VIDEO TRAINING: Traffic Shaping

Moving towards MCQ Style of Traffic Shaping

  • Shaping – Queues excess traffic and sends at a desired rate. Only really an interim feature.. not really a fix.. Same concept as a ‘map-class’. Implemented using Class Maps.
  • MQC Shaping is a new implementation of legacy Generic Traffic Shaping – GTS
  • Shaping queues excess traffic rather than dropping
  • Shaping has no remarking capabilities
  • MQC Shaping allow per class shaping rather than per interface (legacy)

Traffic Shaping Terminology

  • Packet Switched Networks (ATM, X25, FR etc..) not in tune with the CIR using CSU/DSU.
  • Speed that circuit can physically send… Local access rate..
  • CIR is lower than LAR – logically speed that ISP actually provides.

Tc – Time committed/Committed time – ISP will divide up every second into intervals. Default time interval = 32 (How much data you are able to send) Router can not send data than the sent clock rate.

Bc – Committed Burst/Burst Committed – What the CIR is translated to…CIR = Tc x Bc or CIR/Number of time intervals…

Be – Excess Burst/Burst Excess – Amount you can exceed of the CIR.. When the Bc is not met, the router will bank bandwidth for the Excess Burst. (There is a limit)

De – Discard Eligible – Area between the Bc and Be. When the exceed the CIR, the packet is marked with a De 1 bit. Marked for death and liable to be dropped.

What traffic do we want marked as De…..? ISP marks randomly, however you have the ability to do this yourself. (Odd…!) Premarked so the ISP do not need to mark again.

Traffic Shaping Methodology

  • Traffic Shape Average = Bc
  • Traffic Shape Peak = Be

Peak traffic is living dangerously and you are in debt! Recoverable traffic should only really peak… such as TCP based applications.

Exceeding the peak = violate traffic.

Traffic Shaping = conceptually heavy… configuration is not!

Traffic Shaping Topology

Capture

Cfg

Under policy-map for class ‘SHAPE_500:

shape peak 500000

Built into Cisco router is an algorithm that will work out the Bc and Be values. Recommended not to configure it.

Under policy-map for class ‘VOICE’:

shape average 500000

Create priority for queuing…

Nesting

policy-map PRIORITY

class DATA (WWW/HTTPS/FTP)

bandwidth 50

class VOICE

priority 300

class class-default

fair-queue

—–

class-map ALL_TRAFFIC

match class DATA

match class VOICE

match class class-default

policy-map SHAPE_500

class ALL_TRAFFIC

shape average 500000

service-policy PRIORITY

Frame Relay Specifics

  • BECN – Backwards Explicit Congestion Notification. (Before the ISP starts to drop, they can tell you to slow down in advance using a BECN)
  • FECN – Forward Explicit Congestion Notification – When packet is not marked or not TCP but UDP. Request for a BECN to be sent back to the source router)

Tells the router to slowdown!

Every TCP ACK that is received contains 1 bit for the BECN. (0 to a 1) By default BECNs will not be understood. You need to enable it)

Q.922 Test Frame is sent with a FECN.

To enable BECN on Router:

shape adaptive – You will respond to BECNs..

MIN CIR needs to be set for when a BECN is received. By default 1 BECN takes you down half each time!!

FECN/BECN Explained further….

FECN/BECN (forward explicit congestion notification/backward explicit congestion notification)

In a frame relay network, FECN (forward explicit congestion notification) is a header bit transmitted by the source (sending) terminal requesting that the destination (receiving) terminal slow down its requests for data.
BECN (backward explicit congestion notification) is a header bit transmitted by the destination terminal requesting that the source terminal send data more slowly. FECN and BECN are intended to minimize the possibility that packets will be discarded (and thus have to be resent) when more packets arrive than can be handled.

If the source terminal in a communications circuit generates frequent FECN bits, it indicates that the available network bandwidth (at that time) is not as great as can be supported by the destination terminal. Likewise, if the destination generates frequent BECN bits, it means the available network bandwidth (at that time) is not as great as can be supported by the source. In either case, the root cause is lack of available bandwidth at the times during which FECN or BECN bits are generated. This can occur because of outdated or inadequate network infrastructure, heavy network traffic, high levels of line noise, or portions of the system going down. Identifying and resolving these issues can improve overall network performance, especially when the system is called upon to carry a large volume of traffic.

*Headache* – Will  read over Traffic Shaping in more detail from the Cisco Press QoS book.

Advertisements