CCIE Cert Guide — QoS Notes Part I

QOS:

• IP header has 1-byte fields called the TOS. It’s HIGH ORDER 3 bits are defined as IPP field.
• Diffserv renamed TOS byte to DS field and IPP was replaced with a 6 bit field called DSCP. The low order 2 bits of the DS filed were used for ECN.
• C&M tools makr DSCP and IPP because the IP packet remains intact as it is forwarded throughout the IP network.
• PHB: PER HOP BEHAVIOR
  • Class Selector PHB and DSCP Values
    • Class Selector (CS) PHBs provide backward compatibility with IPP.
    • Default is CS0 (most IOS will only allow default and not CS0)
    • CS PHB states that packets with larger DSCPs should be given better queuing preference.
  • Assured Forwarding PHB and DSCP Values
    • four classes for queuing purposes ALONG with 3 LEVELS of DROP probability in each queue.
    • AF PHB defines 12 DSCP values and their meanings. AFxy (where x is one of four queues and y implies one of three drop priorities.
    • First 3 bits imply queuing class and next 2 bits (3 and 4) imply drop preference.
    • To convert the AF name to decimal equivalent: AFxy foruma is: 8x + 2y = decimal value.
  • Expedited Forwarding PHB and DSCP Values
    • PHB actions:
      • queue EF packets so that they get scheduled quickly (low latency)
      • police the EF packets so that they do not consume all bandwidth.
      • EF value is 46, binary 101110
• Non-IP Header Marking Fields
  • Ethernet LAN CoS:
    • included 802.1q or ISL trunking header
    • 802.1q defines as 3 most significant bits of the 2-byte Tag Control field. Called “user priority” bits
    • ISL defines the 3 LEAST significant bits from 1 byte USER field, calling it CoS.
  • WAN marking Fields
    • Frames set to 1 are considered to be better candidates to be dropped than without set to 1.
    • Frame Relay: DE bit,
    • ATM: Cell Loss Priority (CLP) bit.
    • MPLS defines 3-bit fields called MPLS EXP.
  • Rules for non-IP markable fields:
    • Classification: ON INGRESS ONLY (COIN) and only if that interface supports that particular header field
    • Marking: MOEG – On EGRESS ONLY.
• M-QoS CLI
  • “Class Based” tools include: CB Marking, CB WFQ, CB Policing, CB shaping, CB Header Compression.
  • MQC separates the classification function of a QoS tool (class-map) from the action (PHB) that the QoS wants to perform (policy-map). 3 major commands:
    • CLASSIFICATION: class-map
      • uses “match command”.
      • match any matches any packet – any and all packets!
      • if packets don’t match either class 1 or class 2, those packets would not be marked and will retain their DSCP values.
      • upto four (cos and IPP) and eight (dscp) values can be listed on a “match cos”, “match precedence” or “match dscp” command.
      • if a class has multiple match, default is “MATCH-ALL (AND)”, but match-any can be (OR) can be defined on command.
      • to do an OR on the same command for qos values, e.g: “match dscp 0 1” == match dscp 0 OR match dscp 1.
    • MARKING: policy-map à multiple classes can be referenced under a single policy map.
    • service policy
• Marking
  • CB Marking requires CEF enabled.
  • CB marking is enabled for packets entering or exiting an interface
  • policy map is processed sequentially.
  • packets that do not explicitly match defined class are considered to match special class “class-default”.
  • for any class inside policy-map for which there is no set command, packets are not marked in that class.
  • some “sets”: set atm-clp, set fr-de, set qos-group gid, set ip dscp <dscp-value>
  • show policy-map <policy-map-name> {lists config info}
  • show policy-map <interface-spec> input | output [class] {lists statistics of policy-map}
  • load-interval interface subcommand: useful for QoS statistics. It defines the time interval over which IOS measures packet and bit rates on an interface. With lower load interval, stats change more quickly; default is 5 minutes, it can be lowered to 30 seconds.
  • if packets are matched by an earlier class statement in policy map, they won’t match the later ones.
  • on “native” vlan interfaces, policy-maps that refers to CoS cannot be enabled.
  • the “show ip nbar” command only displays statistics if the “ip nbar protocol-discovery” command is applied to an interface.
  • you can download new PDLMs from Cisco, copy it into flash memory and add the “ip nbar pdlm <name>” command.
  • packets should generally be marked as close to INGRESS point of packet as possible.
  • “Mark as close to ingress edge of the network as possible, but not so close the to the edge that the marking made is made by an untrusted device.”
  • Marking Using Policers:
    • Determines if configured traffic contract is exceeded! Has two components: traffic rate (bits per second) and burst size (# of bites)
    • if traffic within the contract, all packets are considered to have conformed to the contract, if exceeded, they have “exceeded” the contract.
    • marking down requires re-marking of QoS fields, typically IPP or DSCP values. E.g: policer marks AF11 to AF13 without discarding.
• QoS Pre-classification:
  • encapsulated traffic like IPSec, tunnel mode, GRE tunnels.. ToS byte of the original packet is automatically copied to the tunnel header BUT features like NBAR are broken.
  • QoS pre-classification works by keeping the original, unencrypted traffic in memory until the egress QoS action are taken.
  • You can enable in “tunnel interface configuration mod”(GRE and IPIP), “virtual-template configuration mode”(L2F and L2TP) or “crypto map config mode”(IPSec) by using “qos pre-classify”.
• Policy routing for Marking
  • allows capability to route packet based on information in packet beside the destination IP address. Uses “route-maps” to classify packets.
  • Policy routing can also mark the IPP field, or the entire ToS byte using the set command in a route-map.
  • Packets are examined as they enter an interface
  • traditional policy routing function of using set command to define the route may also be configured but nor required.
  • should only be used when CB marking is not available or when router has to use both policy routing and mark packets entering the SAME interface.

CCIE Cert Guide Notes — QoS Part IV

Traffic Shaping Concepts

• Solves 2 general types of problems:
  • if a SP discards any traffic on a VC when traffic rate exceeds CIR, it makes sense for router not to send traffic faster than CIR
  • egress blocking problem solved. happens when router sends data into a FR or ATM service, and the Egress FR or ATM switch has to queue the data before it can be sent out to the router on the other end of the VC.
• Tc: Shaper sets a static time interval Tc. It calculates the number of bits that can be sent in the Tc interval such that over time, the number of bps sent matches the shaping rate. (Tc = Bc/CIR) or Shapers apply this formula: (Tc=Bc/shaping rate)
• Bc: Number of bits that can be sent each Tc is called Bc (committed burst size). Measured in bits. Defined in the contract. (Bc = rate * Tc)
• With a Tc of 125 ms, there will be 8 Tc Intervals per second (125msx8=1second). If 8k (Bc) bits are sent each Tc, the resulting rate would be 64000 bps.
• CIR: Committed Information rate, in bps, which defines the rate of a VC according to the business contract.
• Shaped Rate: the rate in bps to which a particular configuration wants to shape the traffic. It may or may not be set to the CIR
• Be: excess burst size in bits. Number of bits beyond Bc that can be sent after a period of inactivity.
• When using a Be, the shaper can allow in addition to the Bc bits per Tc, Be extra bits to be sent.
• Traffic Shaping adaption on FR networks:
  • when no congestions, shaper uses the shaping rate
  • when congestion, lowers the shaping rate to “mincir” (minimum information rate). Defaults to 50% of shaping rate.
    • to lower rates shapers must notice congestion via BECN bit set or receipt of a Cisco-proprietary “ForeSight” congestion maessage.
    • each time a BECN or ForeSight is received, shaper slows down by 25% of Max Rate. It simply decreases Bc and Be by 25% keeping the Tc value the same. Until it bottoms out to “mincir”.
    • Rate grows again after 16 consecutive Tc values without BECN, shaping rate increases by 1/16.
• CB Shaping Configuration
  • “shape [average | peak] mean-rate [[burst-size] [excess-burst-size]]”
  • CB shaping can be implemented for output packets only, can be associated with either a physical interface or a subinterface.
  • “service-policy output” command is configured with referenced policy map including the shape command.
  • Sustain bits/int (Bc) and Excess bits/int (Be) in “show policy-map interface <int>” output. Increment (bytes) is equal to Bc (8000bits) but listed in bytes
  • CB shaping default var settings:
    • Bc: 8000 bits if rate <= 320kbps, Bc=shaping rate*Tc if > 320 kbps
    • Be: Be=Bc= 8000 bits if rate <= 320kbps, Be=Bc if > 320 kbps
    • Tc: Tc = Bc/shaping rate if rate <=320 kbps, Tc=25ms if > 320kbps
  • E.g: Shape rate: 96kbps, Tc=10ms, Bc=960bits.
  • How to use LLQ against packets shaped by CB Shaping? by calling an LLQ policy map with “service-policy queue-voip” command [Service the Quality Policy Map INSIDE THE SHAPE POLICY MAP]. Note the output keyword is not used since output direction is implied.
  • Shaping by Bandwidth Percent
    • subinterfaces do not inherit the bandwidth setting of the physical interface, so if not set via bandwidth command, it defaults to 1544.
    • Bc and Be are configured as a number of milliseconds;
    • Tc is set to the configured Bc value (in milliseconds)
  • Shaping to Peak Rate
    • shaping_rate = configured_rate(1 + Be/Bc)
    • shape peak mean-rate
    • e.g. shaping_rate = 64(1 + 8000/8000) = 128
  • Adaptive Shaping
    • shape adaptive min-rate
• Frame Relay Traffic Shaping Configuration
  • Does not allow fancy queuing tools to be enabled on the physical interface concurrent with FRTS
  • FRTS always shapes traffic on each VC separately.
  • FRTS can dynamically learn the CIR, Bc, and Be values configured on FR switch by using Enhanced Local Management Interface (ELMI)
  • FRTS organizes a set of shaping parameters (rate, Bc and so on) into a named Frame Relay map class, using the “map-class frame-relay” command, the “frame-relay class” command and the “class” command.
  • on the MAIN interface, issue: “frame-relay traffic-shaping”
    • First, FRTS uses the map class referenced by the “class” command under “frame-relay interface-dlci” command. e.g under subinterface, issue: frame-relay interface-dlci 203 à class C3
    • Second, if no “class” is there, FRTS assigns the map class based on the subinterfaces “frame-relay class” command. e.g. “frame-relay class C2” àframe-relay interface-dlci 103
    • Third, if that’s not found, FRTS looks for setting on the physical interface, so on the main interface if “frame-relay class C2” is issued, it will use that.
    • if FRTS still doesn’t find anything, it uses the default setting. Default settings when no class: CIR=56kbps, Bc=7000bits, Tc=125ms
  • FRTS configuration using the “traffic-rate” command
    • FRST uses two main styles of configuration for shaping parameters.
    • frame-relay traffic-rate average [or peak] configures avg or peak rate.
    • Cisco IOS calculates the Bc, Be with an assumed Tc of 125ms
    • simpler to configure but no tuning available.
    • frame-relay traffic-shaping enabled FRTS for all VCs on physical interface.
    • on subint: “frame-relay class shape-all-64”
    • Now creating the map-class
      • map-class frame-relay shape-all-64
        • frame-relay traffic-rate 64000 64000
      • show frame-relay pvc 101
      • show traffic-shape
      • show traffic-shape queue
    • Configuring Peak rate:
      • Be = Tc * (PIR – CIR)
      • so if frame-relay traffic-rate 64000 96000 command was enabled, it would be 0.125(96000 – 64000) = 4000
  • Setting FRTS Parameters Explicitly
    • instead of frame-relay traffic-rate command, you can use: frame-relay cir, frame-relay Bc, and frame-relay Be directly to set FRTS.
    • Benefit: allows tuning to use small Tc
    • e.g
      • map-class frame-relay shape-all-64-long
        • frame-relay cir 64000
        • frame-relay bc 8000
        • (show traffic-shape) shows Tc=125ms
      • now change it so that Bc is set to 1/100^th of the shaping rate (10ms)
        • frame-relay cir 64000
        • frame-relay bc 640
        • (show traffic-shape) shows Tc=10ms
  • FRTS using LLQ
    • to enable LLQ, just add the command “service-policy output queue-voip” [queue-voip is a policy map] in the map-class configuration for the LLQ class map.
    • use the “show frame-relay pvc 101” command and not “show policy-map interface” command.
  • FRTS Adaptive shaping
    • add “frame-relay adaptive-shaping becn” command to the appropriate map class.
    • to set minimum other than default 50%, use “frame-relay mincir rate” command in map class.
  • FRTS with MQC
    • create a default class in FRTS service policy under which FRTS commands are applied
    • need to cover…
• CB POLICING
  • enabled for packets entering or exiting an interface or subinterface.
  • Policing actions:
    • drop
    • set-dscp-transmit
    • set-prec-transmit
    • set-qos-transmit: sets qos group id (1-99) and sends the packet
    • set-clp-transmit: atm clp bit
    • set-fr-de
    • transmit
  • policing categories
    • conforming
    • exceeding
    • violating
  • Policing Logics
    • Single Rate (two-color policing)
      • only two categories, “conform” and “exceed”
      • usually conform transmit and exceed drops or marks the packed down.
      • uses “single-bucket two color”
      • each token is 1 byte, so 12,000 tokens is 96,000 bits. So policing at 96kbps add 12,000 tokens to the bucket.
      • Formula [(current-packet-arrival-time – previous-packet-arrival-time) * police_rate ]/ 8
      • Number of bytes in the packet (Xp), and number of tokens in the bucket (Xb). if Xp <= Xb – it conforms and Xp tokens are drained from bucket
      • if Xp > Xb – it exceeds and no tokens are drained from bucket
    • Single-Rate, Three color Policer
      • when you want the policer to police at a particular rate but also support Be, then you need to use two token buckets.
      • conform, exceed, violate all used.
      • two buckets, Bc bucket and Be bucket
      • the spilled token from Bc bucket go to Be bucket
    • Two-rate, Three-color policer
      • uses two separate policing rate
      • lower rate is CIR and the higher rate is called PIR (packet information rate)
      • packet under CIR conform, over CIR but below PIR exceed and above PIR are violate
    • CB Policing Configuration
      • “police” command configured CB policing inside POLICY MAP
      • Policing rate in bps, Bc in bytes and Be in bytes.
      • police bps burst-normal burst-max conform-action action exceed-action action [violate-action action]
      • e.g for traffic rate, 96 Kbps, Bc of 1 second, and Be of 0.5 second
        • police cir 96000 bc 12000 be 6000 conform-action transmit exceed-action set-dscp-transmit 0 violate-action drop
        • to configure 3 color policer, you need to configure a violate action or explicitly set Be to something larger than 0.
      • policing subset of traffic:
        • police web traffic at 80kbps at ingress, xmit conforming and exceeding traffic and discard violating
        • police all other traffic at 16kbps at ingress. Mark down exceeding and violating to dscp 0
        • set bc and be to 1 second and 0.5 second worth
        • match protocol http
        • police cir 80000 bc 10000 be 5000 conform-action transmit exceed-action transmit violate-action drop
        • police cir 16000 bc 2000 be 1000 conform-action transmit exceed-action set-dscp-transmit 0 violate-action set-dscp-transmit 0
        • service-policy input police-web
    • default Bc and Be
      • if not set in police command, sent in ¼ second.
      • Bc = (CIR*0.25second)/8bits/bye = CIR/32
      • if formulaa yields a number less than 1500, CB policing uses a Bc of 1500
      • default Be depends on type of policing
        • single rate two color, Be=0 (no violate-action configured)
        • single rate three color, Bc=CIR/32; Be=Bc (violate-action configured)
        • dual rate; Bc=CIR/32; Be=PIR/32 (pir configured)
    • dual rate: police cir 96000 pir 128000
    • Multi-Action Policing
      • uses different format, separates the commands
      • e.g
      • police 128000 256000
        • conform-action transmit
        • exceed-action transmit
        • violate-action set-dscp-transmit 0
        • violate-action set-frde-transmit
  • CAR vs CB Policing
    • uses the “rate-limit” command not part of MQC, under an interface or subinterface
    • has feature “cascaded or nested rate-limit” command.
    • CAR supports Be but does not have violate-action
    • “rate-limit input 96000 12000 18000 conform-action set-prec-transmit 0 exceed-action drop”
    • rate-limt ACL can match MPLS experimental bits, IP Prec or MAC address.
    • for others, IP ACL must be used.

CCIE Cert Guide Notes — QoS Part III

• LAN Switch Congestion Management and avoidance
  • 3550 and 3560 Switch Ingress Queuing
    • 3550 uses a single FIFO ingress queue as a place to hold frames, 3560 uses two ingress queues, one of which can be configured to be PQ.
    • 3560 uses Shared Round Robin (SRR) to control rates at which packets are sent. SRR shares the bandwidth among the queues according to the weights you configure.
    • Configuring ingress queuing:
      • allocate the ration by which to divide the ingress buffers to the two queues using: mls qos srr-queue input buffers %1 %2
      • mls qos srr-queue input bandwidth w1 w2: sets frequency at which the scheduler takes packets from the two queue.
      • to enable PQ, use: mls qos srr-queue input priority-queue queue-id bandwidth weight command. Weight parameter defines the %age of the link’s bandwidth that can be consumed by the PQ when there is competing traffic in the non-PQ.
      • ingress queues in 3560 use a method called Weighted Tail Drop (WTD) to set discard thresholds for each queue.
  • 3550 Egress Queuing
    • 3550 supports 4 queues per interface with classification based on CoS.
    • Scheduling is based on WRR with an optional expedited PQ.
    • makes most internal decisions based on internal DSCP setting.
      • the Frame’s internal DSCP is compared to a global DSCP-to-CoS map to determine a CoS value
      • the per-interface CoS-to-queue map determines the queue for a frame based on the assigned CoS.
    • wrr-queue bandwidth 10 20 30 40 and wrr-queue bandwidth 1 2 3 4 configure the SAME proportions.
    • 3550, egress queue FOUR (ONLY) on an interface as a PQ. priority-queue out is configured under the interface. WRR still applied on 1-3.
    • DSCP-toCoS map (upto 8 DSCPs can be mapped in a single command). e.g mls qos map dscp-cos 60 61 62 63 to 1
    • wrr-queue cos-map 3 6 7 (assigns cos 6 and 7 to queue 3).
    • sh mls qos int gi0/1 queue
  • 3560 Egress Queuing
    • improves by creating a mechanism to stop starvation due to PQ. Secondly, it adds shaping feature that slows down egress traffic.
    • same # of queues but only queue 1 can be PQ not queue 4.
    • 3560 has two options for scheduler: Shared Round Robin and Shaped Round Robin. Shared option also rate-limits (shapes) the queues so that they do not exceed the configured percentage of the link’s bandwidth.
    • Configuration:
      • srr-queue bandwidth share w1 w2 w3 w4
      • srr-queue bandwidth shape w1 w2 w3 w4
    • operation differs when queues are not full.
    • the shaped scheduler never allows any queue, PQ or non-PQ to exceed its configured percentage of link bandwidth, even if that means link sits idle.
• 3550 Congestion Avoidance
  • Gig interfaces support, WRED or taildrop
  • FastE ports use switch specific method (not covered)
  • 3550 WRED has same strategy as WRED on routers but with many differences.
  • each egress queue has two WRED thresholds, which are $ages of the queue length.
  • thresholds can be set differently for each egress queue on each interface.
  • existence of single wrr-queue random-detect command under an interface both enables WRED on the interface for all queues and disabled default tail drop for each queue. If only one interface egress queue has wrr-queue random detect command, other three egress queues use WRED as well, however WRED defaults to use thresholds of 100%. To enable WRED-like behavior, each queue needs to have nondefault thresholds configured.
• 3560 Congestion Avoidance
  • uses WTD (weighted Tail drop).
  • 3 thresholds per queue into which traffic can be divided based on CoS value.
  • WTD is configurable separately for all 6 queues in the 3560 (two ingress and four egress).
    
    

CCIE Cert Guidge — QoS notes Part II

Congestion Management and Avoidance

· Software vs Hardware Queues:

o Hardware queues are called, Transmit queue (TX queue) or Transmit ring (TX ring) – depending on the model.

o IOS automatically shrinks the length of the hardware queue to smaller length than the default when a queuing tool is present.

o ONLY function of a hardware queue that can be manipulated is the LENGTH OF THE QUEUE.

o “show controllers serial 0/0”

o tx-ring-limit 1 (set tx ring limit to 1).

· Queuing Tools: CBWFQ and LLQ

o PQ and CQ legacy queuing methods are no longer covered.

o WFQ is covered in context of CBWFQ, not alone

o CBWFQ reserves bandwidth for each queue and provided ability to use WFQ for packets in the class-default queue.

o LLQ adds to CBWFQ the concept of priority queue but unlike PQ, prevents high priority queue from starving other queues.

o configuration for LLQ and CBWFQ is exactly the same EXCEPT whether bandwidth command (CBWFQ) or the priority command (LLQ) is used to configure.

o each class defines a single queue, that’s why sometimes class and queues are used interchangeably.

o both support 64 queues/classes.

o Both have special class, “class-default queue”.

o CBWFQ configuration:

§ guarantees a minimum percentage of a link’s bandwidth to each class/queue. If some queues are empty and do not need their bandwidth for a short period, the bandwidth is proportionally allocated across the other classes.

§ it drops based on “Tail drop” or WRED and can be configured per queue.

§ Commands:

· bandwidth {in kbps or percent}

· bandwidth {remaining percent}

· queue-limit {sets the max length of cbwfq}

· fair-queue [queue-limit]: enabled WFQ on class-default only.

· max-reserved-bandwidth: defines % of link that can be reserved for CBWFQ besides class-default (default: 75%)

· load-interval 30 (how often it’s updated, 30 seconds)

§ Input is not allowed on routers for policy maps that perform queuing.

§ IOS checks CBWFQ policy map to ensure it does not allocate too much bandwidth.

§ IOS performs the check when the “service policy output” command is added.

§ defines bandwidth based on: bandwidth command and max-reserved-bandwidth commands.

§ IOS allows a policy map to allocate bandwidth based on the product of int-btw and max-res. E.g: with default max-res of 75 on an interface with int-bw of 256 (256kbps), the policy map could allocate 192kbps.

§ To avoid problems: bandwidth command must not total more than max-res X int-bw.

§ “bandwidth percent” sets class’s reserved bandwidth as a % of int-bw. Bandwidths <= max-res%. IOS checks all the bandwidth percent commands in a single policy map to ensure that the total does not exceed the max-res setting for that interface. In other words, with default setting for max-res, all the bandwidth percent commands in a single policy cannot exceed more than 75.

§ “bandwidth remaining percent”: remaining bandwidth is the reservable bandwidth. E.g. remaining bandwidth would be 75% x 128 kbps or 96kbps. The command “bandwidth remaining percent 50” would allocate 48kbps for a class.

o LLQ Configuration

§ for delay (latency) sensitive traffic, LLQ is the tool of choice.

§ like CBWFQ but adds the capability for some queues to be configured as LLQ (specific queues as strict priority queues).

§ Sometimes a single LLQ is called “the LLQ” or “the PQ”. But LLQ polices the PQ based on the configured bandwidth.

§ Bandwidth given to the LLQ PQ is both guaranteed minimum and policed maximum.

§ use the “priority {bandwidth kbps | percent percentage} [burst]” command instead of bandwidth command.

§ class subcommand: enables LLQ, reserves bandwidth and enables policing function.

§ Burst size by default is 20% of configured bandwidth.

§ IOS allows both the explicit and percentage version of the priority command inside the same policy map.

§ the actual bandwidth from both LLQ classes (with priority commands) and non-LLQ classes (with bandwidth commands) not allowed to exceed max-res x int-bw.

§ class percent is percentage of Link Bandwdith.

§ LLQ > 1 PQ:

· LLQ places packets from multiple LLQs into a single internal LLQ.

· why use multiple priority queues? for POLICING. By policing traffic in one class at one speed, and traffic in another class at another speed, you get more granularity for the policing function of LLQ.

o IOS will not allow “priority” command in “class-default”.

o When class class-default does not have a “bandwidth” command, IOS internally allocates any unassigned bandwidth among all classes. As a result, class class-default might not get much bandwidth unless the class is configured a minimum amount of bandwidth using the bandwidth command.

· WRED

o WRED uses the measured “average queue depth” when deciding if a queue has filled enough to begin discarding packets.

o WRED then compares the avg depth to min and max queue threshold, performing different discard actions depending on the outcome.

o if avg depth > max threshold (drop all like tail drop)

o if avg depth < max threshold and > than min threshold, random drop is done.

o “full drop” to distinguish from “tail drop” (all new packets are discarded).

o Mark probability Denominator (MPD), from which the discard percentage used at the max threshold is derived, using 1/MPD.

o WRED method of weighing:

§ uses different traffic profile for packets with different IPP and DSCP values

§ traffic profile based on: min threshold, max threshold and MPD.

§ MPD of 20 is 1/20 = 5% drop. higher MPD means lower discard percentage.

§ DSCP values ending with 1 get better treatment than values of 2 and 3.

o WRED Configuration

§ WRED can only be configured on the following locations:

· physical interface (with FIFO queuing)

· non-LLQ class inside CBWFQ policy map

· for an ATM VC

§ for physical interface, IOS disables all other queuing mechanisms and creates a single FIFO queue.

§ for CBWFQ, WRED is configured in a class inside a policy map.

§ “random-detect” command enables WRED IPP based. To enable dscp based, use “random-detect dscp-based”

§ to change values use either “random-detect precedence” or “random-detect dscp”

§ exponential-weighting-constant – to affect calculation of rolling average queue depth.

· MDRR (Modified Deficit Round Robin)

o only by Cisco 12000 series routers.

o replaces CBWFQ and LLQ

o allows classifying traffic into seven round-rabin queues (0-6), with one additional priority queue.

o when no packets in the PQ, MDRR services its queues in a round-robin approach, once per cycle.

o with packets in PQ, has 2 algos, Strict Priority mode and Alternate Priority Mode

o Strict Pri Mode: serves PQ whenever traffic is present in that queue. (may lead to starvation)

o Altername Mode: serves PQ in b/w serving each of the other queue. (every other cycle, PQ is serviced)

o Can cause jitter and latency for traffic in PQ.

o MDRR removes packets from a queue until the Quantum Value (QV) for that queue has been removed. QV quantifies a number of bytes and is used much like the byte count is used by the CQ scheduler.

o MDRR deals with the CQ scheduler’s problem by treating any “extra” bytes sent during a cycle as a “deficit”.

o Formula: (QV for Queue X)/(Sum of All QVs)

CCIE Certification Guide (by Odom) Notes: BGP

BGP

• BGP uses path attributes instead of metric.
• BGP port 179 – TCP connection.
• Keepalive – 60 and Hold time – 180, “bgp timers keepalive holdtime” or “neighbor timers” (they do not need to match for neighbor relationship)
• Router ID: “bgp router-id” à highest IP of loopback à highest IP of another interface
• Auto-summary is off by default and MD5 is uses only with “neighbor password” command
• iBGP peers often use loopback interface IP addresses for BGP peering to achieve higher availability. Peering loopbacks makes most sense
• For IGP, if using loopback, do: neighbor 2.2.2.2 update-source loopback1
• for eBGP, if IP redundancy exists b/w two eBGP peers, the eBGP neighbor commands should use loopback IP address to take advantage of that redundancy, so that even if the link fails, the TCP connection remains established. If you use eBGP peers loopback, you should use, “neighbor ebgp-multihop” command (set ttl to 2)
• the initiator of the connection uses a dynamic port number, the receiver (server) uses port 179
• Tools BGP can use to inject routes:
  • maximum number injected by the NETWORK command in one BGP process is 200.
  • redistribution into BGP does not require any consideration of setting metrics.
  • BGP auto-summary router subcommand causes BGP to summarize only those routes injected due to redistribution on that router. logic differs b/w redistribute and network command. REDISTRIBUTE: do not inject subnets in routing table, inject the classful network.
  • network – for network commands that list a classful network number and no mask parameter, inject the classful network if at least one subnet of that classful network exists in the IP routing table.
  • AGGREGATE-ADDRESS: components (AS SEQ and AS SET). AS SEQ becomes null when ASSEQ of component subnet differs in any way, with as-set the router creates AS_SET segment for the aggregate route if this is the case. “summary-only” suppresses component subnets. “suppress-maps” advertises a subset.
  • aggregate-address 23.0.0.0 255.0.0.0 summary-only as-set
  • adding default routes to BGP: 3 ways: 1) using “network 0.0.0.0” command (route to 0.0.0.0 must exist in the routing table), 2) using redistribute, 3) using “neighbor neighbor-id default-information [route-map]” subcommand – doesn’t need to check the route table, it just advertises the default to the specified neighbor.
• Advertising BGP routes to Neighbors
  • BGP update message has 3 main parts; withdrawn routes, path attributes, prefix and prefix length fields.
  • Choose router with shortest AS path à if aspath is tie, prefer singe eBGP route over one or more iBGP route à if best route not chosen, choose the route with the lowest IGP metric to the NEXT_HOP of the routes. à if the IGP metric ties, choose the iBGP learned route with the lowest BGP RID of advertising router.
  • For a route to be considered, next hop is either 0.0.0.0 (internal routes) or reachable according to the IP routing table.
  • iBGP à neighbor …next-hop-self, for eBGP à neighbor …next-hop-unchangedf
  • Two ways to solve the next-hop problem:
    • make the eBGP neighbor’s IP address reachable by advertising that subnet into IGP
    • Use the next-hop-self option on the neighbor command that points to iBGP peers.
• Building the IP Routing Table
  • in its simplest form, BGP takes the already identified best BGP routes for each prefix and adds those routes to the IP routing table. Restrictions: AD (for eBGP and iBGP) and BGP synchronization (iBGP routes only).
  • eBGP learned routes should never be prefixes from within an AS (i.e. reason for having AD 20).
  • locally injected routes default to 200.
  • Can change the “distance bgp” or distance BGP subcommand.
  • the route that’s added to the IP routing table contains the exact same prefix, prefix length, and next-hop IP address as listed in the BGP table.
  • Backdoor routes: elegant way of not allowing router to use eBGP route and to use an IGP route instead. “network backdoor” command. “network <dest_network> backdoor”.
  • Requirements for adding route:
    • the route must be the best BGP route
    • The route must be the best route (according to the AD) in comparison with other routing sources.
  • BGP synchronization is off by default. To solve the blackhole problem, older solutions recommended turing BGP synch on and redistributing the routes. But now we have two better options: BGP route reflectors and BGP confederations.
    • Using Sync and Redistributing routes:
      • Key: redistribution solves the blackhole problem and sync solves the problem of advertising a black-hole route to another AS. BGP Synch, “Do not consider an iBGP route in the BGP table as “best” unless the exact prefix was learned via an IGP and is currently in the routing table”
      • RIB-failure is seen means that prefix is known via an IGP.
      • sync does not work if OSPF RID and BGP RID do not match.
    • Disabling Sync and using BGP on all routers.
      • N(N-1)/2 connections required. N routers.
    • Confederations
      • avoid loops by using AS_PATH PA.
      • the add AS_PATH segment called AS_CONFED_SEQ.
      • just like AS_SEQ and AS_SET help prevent loops b/w AS, same way these two help as well within confederation AS.
      • before iBGP route is advertised into another sub-AS, the route must make sure the destination sub-AS is not already in the AS_PATH AS_CONFED_SEQ segment.
      • ASN 64512 through 65535 are private ASNs.
      • TTL is 1 by default and can be changed using “neighbor ebgp-multihop” command.
      • confederation eBGP connections act like iBGP connections in every other regards – e.g. NEXT_HOP is not changed by default.
      • TRUE ASN will be configured on the “bgp confederation identifier” BGP subcommand and not “router bgp”.
      • to identify a neighboring AS as another sub-AS, “bgp confed peers subasn”
    • Route Reflectors
      • RR servers: these servers are allowed to learn iBGP routes from their clients and then advertise them to other iBGP peers.
      • only one router acting as RR uses modified rules; the other routers (clients and non-clients) are not even aware of the RR.
        • receives from client: advertises routes to client and non-client
        • receives from non-client: advertises routes to client.
        • receives from eBGP: advertises routes to clients and non-clients.
      • ONE CASE where RR does not reflect routes is when RR receives a route from a non-client, with RR not reflection that roué to other non-clients.
      • tools in RR to prevent loops:
        • CLUSTER_LIST – RRs add their cluster ID into a BGP PA called CLUSTER_LIST before sending an update. when receiving a BGP update, RRs discard received prefixes for which their cluster ID already appears.
        • ORIGINATOR_ID: PA that tells the first iBGP peer to advertise the route into the AS. If a routes sees it’s own id in received route, it does not use or propagate the route.
        • only advertises the BEST routes.