Internet QoS Workshop

Internet QoS Workshop
Charles Mujie
PME - ISP Business Unit
cmujie@cisco.com
Cisco Systems Confidential
V2.00
Greetings and welcome to Cisco training on Internet QoS.
Workshop Agenda
What is Internet QoS?
Internet QoS Building Blocks
Configuration Guidelines
Case Study
Demo
V2.00
Cisco QoS Initiative

QoS
11.1CC
11.2
CAR
Queuing
WFQ
Traffic Shaping
NetFlow Services
RED
BGP Policy Propagation
RSVP
NetFlow Switching
FIFO, Priority, Custom, WFQ
WRED
V2.00
There are main two QoS initiavtives happening in Cisco. One is on the
11.1CC train and the other on 11.2 train. Depending on the feature or
features you are looking for you select the appropriate train.

11.1CC
Targeted to SP who wants to provide differentiated levels
of services to their customers
Speed
Performance
11.2
Targeted to Enterprise customers
This workshop will focus on features in

11.1CC only
V2.00
Initially 11.1CC will be targeted for SP only. The features in 11.1CC will
eventually be integrated to 12.0 at which time Enterprise customer will have
access to it.
Anyone wanting to use 11.1CC MUST be trained for CEF and QoS features.

11.1
11.2
WFQ
11.1CA
11.1CB (ISP8)
11.1CC (FIB)
11.1CD (ISP8+L3)
11.1CE (FIB+L3)
11.3
RED
WRED
RSVP
NetFlow Switching
12.0
CYH298
12.0T
IP ATM CoS (Ph II)
11.1CC
CEF
11.1R
CAR/DCAR
IP ATM CoS (Ph I)
DWFQ
DWRED
NetFlow Services
V2.00
11.1CC will merge with 11.3 in 12.0. Extensive integration work is underway.
What is Internet QoS?

IP - Best effort
Internet QoS is a set of features that
allows a user to build an IP network
capable of providing
Timely delivery of packets
Bandwidth guarantees
Improve loss characteristics
V2.00
Layer 3 vs Layer 2 QoS

Layer 3 == IP
Different approaches in providing QoS
Frame Relay - Committed Information Rate (CIR)
ATM - Peak Cell Rate (PCR)
Sustainable Cell Rate (SCR)
Maximum Burst Size (MBS)
In delivering Layer 3 QoS a set of

features has been developed
CAR, WFQ & WRED
V2.00
Layer 3 vs Layer 2 QoS

In some cases layer 2 and layer 3 QoS
has to work together to deliver the
appropriate level of QoS to the
application or user
This is especially true in the case where
Frame Relay or ATM is used in the
network
V2.00
A Point to Note
The focus of this workshop is

on IP QoS and NOT on Frame
Relay or ATM QoS
V2.00
Please note that the emphasis on this workshop is Internet QoS and NOT
Frame Relay or ATM QoS.
We wont be discussing interworking between IP QoS and Frame Relay or
ATM QoS as these features are either on a separate IOS train or under
development.
The features that we will cover in this workshop are those of 11.1CC.

Internet scale performance
Packet classification
Access bandwidth management
Congestion management
Queue management
Granular measurements
V2.00
10
10

Queue management
V2.00
11
11
Network Architecture
POP
POP
Backbone
POP
POP
Scaleable Solutions Require
Cooperative Edge and
Backbone Functions
Edge Functions
Admission control
Bandwidth management
Queuing
Services and traffic metering
Security filtering
Customer access aggregation
Backbone Functions
High-speed switching and transport
Queue management
Traffic management
QoS interworking
V2.00
12
12
Distributed Switching & Services

The key to delivering scaleable and high
performance Internet QoS is the distributed
processing capabilities on the 12000 (GSR)
and 7500 family of routers
With the 12000 and 7500 packet forwarding
(switching) and other services are off-loaded
from the central processor to the linecard
(12000) and VIP (7500)
Utilizes the Packet Engine and SRAM on the
linecard or VIP
V2.00
13
13

With VIP2-40 and distributed processing
we are able to deliver up line rate on a
DS3 interface
The next generation VIP (VIP2-50) with
distributed processing we can scale up
to OC-3/STM-1 (155Mbps) rates
V2.00
14
14

Distributed Services
Distributed Switching
CAR
Cisco Express
Forwarding (CEF)
Rate Limiting
WFQ
WRED
NetFlow Services
BGP Policy
Propagation
V2.00
15
15
Cisco Express Forwarding (CEF)

Forwarding
Information
1) First
Packet
Si
2) Cache
Entry
3) Subsequent
Packets
Cache-Based Forwarding
Distributed Forwarding
First packet to destination processed by route processor

Forwarding cache entry made to switching engine
Subsequent packets to same destination switched
without route processor
Topology changes flush cache entries; refresh of cache
is traffic-driven
Optimized for longer flows and moderate number of
destinations
Forwarding information automatically distributed to

switching engines
Route processor is no longer in data path
Updates to forwarding information are topology, not
traffic driven
Optimized for shorter flows and large number of
destinations
Cisco Express Forwarding (CEF) technology for IP is a scaleable,

distributed, layer 3 switching solution designed to meet the future
performance requirements of the Internet and Enterprise networks. CEF is
also a key component of Cisco's Tag Switching architecture.
CEF replaces Route Caching. CEF creates a Forwarding Information Base
(FIB) for the destination switching decision which mirrors the entire contents
of the IP routing table. i.e. there is a one-to-one correspondence between
FIB table entries and routing table prefixes; therefore no need to maintain a
route-cache.
CEF feature:
Load balancing: Per destination (the default) and per packet over
equal/unequal cost links for as many paths as known in the routing
topology
Traffic statistics: Byte and packet counts at a granularity of per-prefix,
per-neighbor etc.
Media independence: CEF currently supports Packet over Sonet,
ATM/AAL5, Frame Relay, Ethernet, FDDI, HDLC and mPPP.
Tunnelling: Generic Route Encapsulation (GRE).
Subinterface support: allowing for the flexibility of per subinterface
configurations e.g. MTU.
16
CEF
Fast/Optimum/Flow
CEF
Cisco 7500
Cisco 7500
RSP
Routing
Table
RSP
Forwarding
Cache
Routing
Table
CyBus
VIP
VIP
VIP
FIB
Table
CyBus
VIP
VIP
VIP
Distributed
FIB
Distributed
Forwarding
Cache
First Packet
Subsequent Packets
Process Switched
Fast Switched
All Packets Forwarded by VIPs
V2.00
17
17
CEF
CEF works between
Port-to-port on the same VIP
VIP to VIP
VIP to xIP
xIP to VIP
xIP to xIP
For xIP to VIP and xIP to xIP packet

forwarding decision is made on the RSP
V2.00
18
A point to note, CEF only runs distributed if your 7500 configuration has
VIP2-40 or better
Packets switched from port-to-port on the same VIP does not leave the VIP.
18
CEF
CEF runs on existing RSP but to take
advantage of distributed switching and
higher performance you will need a
VIP2-40 or better
Available on 7200, 7500 and 12000
(GSR) platform
Other platforms will be added in the
future
V2.00
19
For an independent test result on CEF read The Tolly Group report #7295
October 1997.
19
Versatile Interface Processor (VIP)

Packet
Engine
RSP
Si
C
y
B
u
s
RSP
Si
P
C
I
Si
P
C
I
Port
Adapter
Port
Adapter
SRAM
VIP
V2.00
20
Distributed services runs on the VIP.

Each VIP has its own processor, called the Packet Engine, which runs the
IOS code and SRAM for packet memory.
20

Queue management
V2.00
21
Next we will talk about Packet Classification and Access Bandwidth

Management. These two functions are delivered through a feature called
Committed Access Rate (CAR).
21
Committed Access Rate (CAR)

Committed Access Rate (CAR)
Previously known as Weighted Rate Limiting
(WRL)
Two functions
Packet Classification - IP precedence setting
Access Bandwidth Management through rate
limiting
V2.00
22
22
CAR - Overview
Traffic
Matching
Specification
Traffic
Measurement
Instrumentation
Next
Policy
Action
Policy
V2.00
23
In the next few slides we will discuss the above items in detail starting with
Traffic Matching Specification.
23
CAR - Traffic Matching Specification

Identify packets of interest for
precedence setting or rate limiting or
both
Matching specification
1) All traffic
2) IP Precedence
3) MAC Address
4) IP Access List - Standard & Extended (slow)
V2.00
24
Accounting information for all of the above are available. For MAC
accounting in 11.1CC we provide accounting information for up to 512
peers.
Please note that doing IP access-list is slow as it uses the same code that
the current IP access-list is using. The same rules apply as if you are doing
a regular access-list.
24
CAR - Traffic Measurement

Uses the token bucket scheme as a
measuring mechanism
Tokens are added to the bucket at the
committed rate and the number of
tokens in the bucket is limited by the
normal burst size
Depth of the bucket determines the
burst size
V2.00
25
The differences between token bucket and leaky bucket schemes will be
discussed later.
25
Packets arriving with sufficient tokens

in the bucket are said to conform
Packets arriving with insufficient tokens
in the bucket are said to exceed
V2.00
26
Packets arriving are said to conform if sufficient tokens are available and the
corresponding number of tokens are removed from the bucket.
Packets arriving at the bucket are said to exceed if insufficient tokens are
available.
26

Packets arriving exceeding the normal
burst but fall within the excess burst
limit is handled via a RED-like managed
drop policy
This is to reduce TCP Slow-Start
oscillation
(when the exceed-action is to drop packets)
V2.00
27
27

Token bucket configurable parameters
Committed rate (bits/sec)
Configurable in increments of 8Kbits
Normal burst size (bytes)

To handle temporary burst over the committed rate limit
without paying a penalty
Extended burst size (bytes)

Burst in excess of the normal burst size
V2.00
28
There is a burst counter that counts the packets in excess of the committed
rate. Any packet that is in excess of the committed rate will cause the burst
counter to increment. Likewise, when the traffic is below the committed rate
the burst counter will reset back to zero.
When a packet arrives the burst counter is evaluated:
< burst-normal: conform-action
< burst-max: possibility of exceed-action proportional to burst value
> burst-max: exceed-action
In any given period a committed rates worth of traffic will always conform.
To calculate the probability
P(exceed) = (burst_counter - normal_burst) / (max_burst normal_burst)
28
Token Bucket
Tokens
B - Burst size
p - Token arrival rate
Overflow
Tokens
Packets
arriving
Conform
Exceed
V2.00
29
The token bucket accumulates token at the Committed Rate up to the

burst level. When that happens the token overflows.
As a packet arrives if there is a matching token the packet is said to conform
otherwise exceed.
Token comes in bytes.
The token size must match the packet size for a conform.
Committed Rate = increments of 8Kbits/milisec.
29
Extended Burst
Packet Discard %
100
Bucket
Depth
Normal Extended
Burst
Burst
V2.00
30
30
CAR - Action Policies

Configurable actions
Transmit
Drop
Continue (go to the next rate-limit in the list)
Set precedence and transmit (rewrite the IP
precedence bits and transmit)
Set precedence and continue (rewrite the IP

precedence bits and go to the next rate-limit in the list)
Rate-limit statement can be cascaded

If a match is not found the default is to transmit
V2.00
31
In 11.1CC the rate-limit list is not bounded.

Each rate-limit statement is checked sequentially for a match. When a
match is found the token bucket, if there is one, is evaluated.
If the action is a continue action it will go to the next rate-limit on the list to
find a subsequent match. If a match is found and a token bucket exists it is
evaluated again.
If an end of rate-limit list is encounter without finding a match or continue
action the default behaviour would be to transmit.
31
CAR - Policy Examples

Recolour
Drop
Multimedia
Drop
Recolour
Mission-Critical
Per Application CAR

32
32
Token vs Leaky Bucket

Token bucket
Passes bursts
No buffering
Does not smoothes or shapes traffic
Leaky bucket
Smoothes or shapes traffic, this is achieved by buffering
the traffic
Generic traffic shaping feature uses this scheme
Used in ATM networks for traffic shaping and policing
Known also as Generic Cell Rate Algorithm (GCRA) in ATM
V2.00
33
Definition of Traffic shaping: Traffic shaping is forcing your traffic to conform

to a certain specified behavior. Usually the specified behavior is a worst
case or a worst case plus average case (i.e., at worst, this application will
generate 100 Mbits/s of data for a maximum burst of 2 seconds and its
average over any 10 second interval will be no more than 50 Mbit/s). By
knowing precisely how the traffic is going to behave, it is possible to allocate
resources inside the network such that guarantees about availability of
bandwidth and maximum delays can be given.
For those who wants more information read Gigabit Networking by Craig
Partridge, Ch11 - Traffic Shaping, page 253 - 263.
33
Leaky Bucket
Packets
arriving
Overflow
Packets
B - Burst size
p - Leak rate
B
p
Packets are leaked

at a rate specified
by p
V2.00
34
The leaky bucket algorithm uses a buffer of finite size that incoming traffic is
placed into. Traffic is allowed to drain out of the bucket and sent on the
network at a rate, p. Excess data that cannot fit into the buffer is discarded.
The leaky bucket algorithm has the effect of shaping bursty traffic into a flow
of equally spaced packets, each being emitted 1/p units of time after the
previous packet. The size of the buffer limits the packet delay.
Any packets that arrive when the bucket is full is dropped.
34
Traffic Rate
Traffic Shaping
Time
Traffic
Traffic
Traffic Shaping
Traffic Rate
Time
V2.00
35
The diagram above shows the effects of traffic shaping.
35
CAR - Packet Classification
A function of CAR
Also known as colouring or labeling of
packets
Partition network traffic into multiple
priority levels or Class of Service (CoS)
V2.00
36
36

Uses the 3 bits precedence field in the
IP header
Up to 6 CoS can be defined
05
The other two are reserved (per RFC791)
Classification is done using several

methods
rate-limit or IP access list (Standard & Extended)
V2.00
37
8 bits in IP header for ToS - precedence, delay, reliability, throughput

3 bit for precedence
(RFC 791)
Network Control (7)

Internetwork Control (6)
CRITIC/ECP (5)
Flash Override (4)
Flash (3)
Immediate (2)
Priority (1)
Routine (0)
Precedence 6 and 7 are reserved for routing protocol and cannot be used
37

Packets can be classified based on
1) IP Address (source/destination)
2) Application port
3) IP Protocol
4) Interface
5) Other IP header information
Classification can also be over-ridden or

re-classified
V2.00
38
Note that precedence bits can be override.
38
CAR
L3 CAR
L3 CAR
Ingress Router
Egress Router
Token bucketlike Frame Relay
Multiple thresholds
Actions:
Change class (precedence)
Drop packet (RED-like)
Token bucket
Multiple thresholds
Actions:
Drop packet
V2.00
39
39
CAR
CAR implementation in 11.1CC is

available in either RSP or distributed
To run Distributed CAR (DCAR) you will
need a VIP2-40 or better
V2.00
40
40
Configuring CAR
Configuring CAR
[no] rate-limit {input|output}
[access-group [rate-limit] <acl-index>]
<bps> <normal-burst> <extended-burst>
conform-action {drop|transmit|continue|
set-prec-transmit <new-prec>|
set-prec-continue <new-prec>}
exceed-action
{drop|transmit|continue|
set-prec-transmit <new-prec>|
set-prec-continue <new-prec>}
V2.00
41
<bps> - Bits/secs
<normal-burst> - bytes
<extended-burst> - bytes
The upper bound for bps is 155000000, normal-burst is 2000000 and
extended-burst is 8000000
41
Configuring CAR
CAR access-list
[no] access-list rate-limit <1-99> <precedence>
[no] access-list rate-limit <100-199> <mac_address>
CAR show command

show interface [interface] rate-limit
V2.00
42
42
CAR Configuration Example

hssi0/0/0
R1
R2
R2#write term
.
!
interface Hssi0/0/0
description 45Mbps to R1
rate-limit input 20000000 24000 24000
conform-action transmit exceed-action drop
ip address 200.200.14.250 255.255.255.252
!
V2.00
43
In the above configuration a customer has a T3 link to an ISP and the ISP
wants to rate-limit the customer to only allow them 20Mbps of the 45Mbps.
Probably because the customer is only willing to pay 20Mbps worth of traffic.
We have also configured to allow them to burst up to 24000 bytes and
anything beyond that we drop.
43
CAR Show Command

R2#sh
sh int hssi 0/0/0 rate-limit
Hssi0/0/0 45Mbps to R1
Input
matches: all traffic
params: 20000000 bps, 24000 limit, 24000 extended limit
conformed 8 packets, 428 bytes; action: transmit
exceeded 0 packets, 0 bytes; action: drop
last packet: 8680ms ago, current burst: 0 bytes
last cleared 00:03:59 ago, conformed 0 bps, exceeded 0 bps
V2.00
44
This is the output when do a show interface [interface] rate-limit.
44
CAR - More Examples

R1#write term
hssi0/0/0
R1
R2
.
!
interface Hssi0/0/0
rate-limit input access-group 101 20000000 24000 32000
conform-action set-prec-transmit 5 exceed-action set-prec-transmit 0
conform-action set-prec-transmit 5 exceed-action drop
rate-limit input 8000000 16000 24000
conform-action set-prec-transmit 5 exceed-action drop
ip address 200.200.14.250 255.255.255.252
!
access-list 101 permit tcp any any eq www
access-list 102 permit tcp any any eq ftp
!
V2.00
45
The above example show a rate-limit by application.

We rate-limit Web traffic to 20Mbps and if that conforms set the precedence
to 5, otherwise we set if to 0 (best effort).
Ftp is rate-limit to 10Mbps again if it conforms we set the precedence to 5
and if it exceeds we drop it.
The last line in the rate-limit statement is a catch all. For the catch all we
rate-limit to 8Mbps, if it conforms set the precedence to 5 otherwise drop.
45
CAR
- More Examples
R1#sh
sh int hssi 0/0/0 rate-limit
Hssi0/0/0 45Mbps to R2
Input
matches: access-group 101
conformed 3 packets, 189 bytes; action: set-prec-transmit
exceeded 0 packets, 0 bytes; action: set-prec-transmit
V2.00
46
Output of show interface [interface] rate-limit.
46
CAR - More Examples

R2#write term
fddi2/1/0
R1
.
R2
FDDI
!
interface Fddi2/1/0
rate-limit input access-group rate-limit 100 800000000 80000 160000
conform-action set-prec-continue 1 exceed-action set-prec-continue 0
rate-limit input 50000000 50000 100000
rate-limit output 80000000 80000 16000
conform-action transmit exceed-action drop
ip address 200.200.6.1 255.255.255.0
!
access-list rate-limit 100 00e0.34b0.7777
!
access-list 101 permit tcp any any eq www
!
V2.00
47
The above configuration show an example using rate-limit to control traffic in

an Internet Exchange Point (IXP).
Lets say we have a connection to another ISP via FDDI (back-to-back FDDI)
and we want to rate-limit the other ISP to 80Mbps out of the 100Mbps FDDI
bandwidth. If they conform we set the IP precedence to 1and if they exceed
we set the IP precedence to 0. Notice that in both cases we continue to find
a next rate-limit match.
The next rate-limit statement limits web traffic to 80Mbps with a normal burst
of 56kbytes and extended burst of 72kbytes. If it conforms set the IP
precedence to 5 and transmit otherwise we set the IP precedence to 0 and
transmit.
The next rate-limit statement is a catch all where we are only allowing
50Mbps for all other traffic (other than web traffic). Again if it conforms we
set the IP precedence to 5 and transmit otherwise we set the IP precedence
to 0 and transmit.
The last rate-limit statement is an output rate-limit. What we are doing here
is rate-limit what we send to the other ISP to 80Mbps. Nothing more.
47
CAR
- More Examples
R1#sh
sh int fddi2/1/0 rate-limit
Fddi2/1/0
Input
matches: access-group rate-limit 100
conformed 0 packets, 0 bytes; action: set-prec-continue
exceeded 0 packets, 0 bytes; action: set-prec-continue
last cleared 01:00:22 ago,
conformed 0 bps, exceeded 0 bps
V2.00
48
Output of show interface [interface] rate-limit. This is on the input. Next

slide/page will be the output.
48
CAR - More Examples
Output
conformed 0 packets, 0 bytes; action: transmit
V2.00
49
49
Implementation Note
Cisco recommends that you set the IP
precedence for all traffic entering your
network
This is done to ensure that only
customers who pay for preferential
treatment gets preferential treatment
V2.00
50
This is done to ensure that customers who did not pay for premium service
for example buts sets their packet to premium doesnt get premium
treatment.
Remember there is nothing stopping a customer from setting all their traffic
to IP precedence 5 for example before sending it you. If you so happen to
use IP precedence 5 as premium service than this customer who is only
paying you standard service will get premium treatment.
It is also recommended to have this at the end of every rate-limit list.
50
Implementation Note
Set or reset IP precedence to 0

!
interface Serial 0/0/0
rate-limit input 155000000 155000 155000
!
V2.00
51
Here we are assuming that IP precedence 0 is best-effort.
51

Conveys IP precedence to be used in
forwarding to specified destination
prefix via BGP community tag
Allows ingress routers to prioritize
incoming traffic
Also allows IP precedence setting based
on AS-path attribute or access list
Inter-ISP Service Level Agreements
(SLAs)
V2.00
52
52
For this feature to work you will need to

run
BGP
CEF
V2.00
53
53

Prefix
FIB Table
Next-hop Precedence
210.210.1.0/24 h0/0/0
210.210.2.0/24 h0/0/0
5
0
Traffic
Source
Data
R1
IP Header
Service
Provider
AS
iBGP Peers
210.210.1.0/24
R2
Premium
Customer
Prefix 210.210.1.0/24;
Community 210:5
IP Precedence: 5
Dest Addr: 210.210.1.1
Src Addr: x.x.x.x
V2.00
54
54
Configuring BGP Policy

Propagation
Configuring BGP Policy Propagation

[no] bgp-policy ip-prec-map
V2.00
55
55
BGP Policy Propagation - Sample Config

R2#write term
!
router bgp 210
neighbor 210.210.14.1 remote-as 210
neighbor 210.210.14.1 route-map comm-relay-prec out
neighbor 210.210.14.1 send-community
!
ip bgp-community new-format
!
access-list 1 permit 210.210.1.0 0.0.0.255
!
route-map comm-relay-prec permit 10
match ip address 1
set community 210:5
!
route-map comm-relay-prec permit 20
set community 210:0
!
V2.00
56
56

R1#write term
!
router bgp 210
table-map precedence-map
neighbor 200.200.14.4 update-source Loopback0
!
!
ip community-list 1 permit 210:5
!
route-map precedence-map permit 10
match community 1
set ip precedence 5
!
set ip precedence 0
!
V2.00
57
57
!
int hssi0/0/0
ip address 210.210.2.1 255.255.255.252
bgp-policy ip-prec-map
!
V2.00
58
58
BGP Policy Propagation - Inter-AS
AS200
R1
R2
AS210
Prefix
Community
210.210.1.0/24
210.210.2.0/24
200:5
200:4
210.210.3.0/24
200:0
V2.00
59
R1 configuration
!
router bgp 200
table-map AS210-precedence-map
neighbour R2 remote-as 210
!
!
!
route-map AS210-precedence-map permit 10
match community 1
set ip precedence 5
match community 2
set ip precedence 4
match community 3
set ip precedence 3
match community 4
set ip precedence 2
match community 5
set ip precedence 1
set ip precedence 0
!
59
BGP Policy Propagation - AS-path

AS200
R1
R2
AS210
!
router bgp 210
table-map as-path-precedence-map
neighbor R1 remote-as 200
!
ip as-path access-list 101 permit $200^
!
route-map as-path-precedence-map
match ip as-path 101
set precedence 3
!
interface hssi/0/0/0
bgp-policy ip-prec-map
!
V2.00
60
60

Queue management
V2.00
61
61
The Problem of Congestion

Uncontrolled, congestion will seriously degrade
system performance
The system buffers fill up
Packets are dropped, resulting in retransmissions
This causes more packet loss and increased latency
The problem builds on itself until the system collapses
Controlled Congestion
Throughput
Uncontrolled Congestion
Congestion
V2.00
62
62
Affects of Tail Drop
Queue Utilization
100%
Time
Tail Drop
V2.00
63
63
Random Early Detect/Drop (RED)

A congestion avoidance algorithm
Designed to work with a transport protocol
like TCP
Not bias against bursty traffic
Avoids global synchronisation of many
connections
Global synchronisation is many connections
going through TCP Slow-Start mode at the same
time
V2.00
64
An algorithm that cooperates with TCP to provide congestion avoidance.

Puts a big buffer in front of a congested link and signals the application at
either end of the congested link to back off in the event of a congestion.
If they are using a well behaved TCP implementation they will back off.
Trade off packets get buffered, introduces latency.
The amount of buffer required is x2 the round trip delay.
RED does not give you more bandwidth. What it does is allows you to better
utilize your available bandwidth.
The obvious solution to fix the congestion problem is to increase the
bandwidth of the link, but sometimes due to cost or availability this is not
possible. Therefore you use RED to manage the congestion.
64
Global Synchronization
100%
Queue Utilization
Time
Tail drop
3 traffic flows start
at different times
V2.00
65
65
RED
RED reduces overall network packet loss,
maximizing goodput and minimizing
latency
RED accomplishes this by fine-tuning the
TCP Slow-Start congestion window
mechanism to avoid oscillation and
minimize retransmission
Result is optimized throughput, with minimal
packet loss
V2.00
66
66
TCP & RED

TCP is a sliding window protocol that uses
self-clocking to adjust its use of the
network to match available bandwidth
Packet loss is a requirement for this to
work
Key decisions: what packets to drop, when to drop them
A drop is an explicit signal to TCP to slow

down transmission
V2.00
67
67
TCP & RED
In a well behaved TCP implementation,

the sender upon detecting a packet loss
will shrink its window size (i.e., slow
down its rate of transmission), and go
into Slow-Start mode
V2.00
68
68
RED
1
Packet
Discard
Probability
Adjustable
Minimum
Threshold
Maximum
Threshold
Average
Queue
Size
V2.00
69
69
RED
Queue
Packets
arriving
Queue
Pointer
Without RED when the queue fills up all packets

that arrive are dropped
This is also referred to as tail drops
With RED as oppose to doing a tail drop the router

monitors the average queue size and using
randomization choose connections to notify that a
congestion is impending
V2.00
70
In 11.1CC implementation of RED the packet dropping portion is not

random. Today we drop every 100th packet that exceeds the predefined
minimum threshold.
70
RED Algorithm
for each packet arrival
calculate the average queue size (avg
avg)
if min_threshold > avg
queue arriving packet
else if min_threshold <= avg < max_threshold
calculate packet-drop probability (p
p)
with packet-drop probability p
drop the arriving packet
or
queue the arriving packet
else if max_threshold <= avg
drop arriving packet
V2.00
71
The above algorithm was taken from Random Early Detection Gateways for
Congestion Avoidance by Sally Floyd and Van Jacobson.
RED has two algorithms. One for computing Average Queue Size and the
other for calculating packet-marking probability Both will be explained in the
following two slides.
The max-threshold and min-threshold parameters are user configurable
parameters.
71
RED - Average Queue Size
Used to determine the degree of

burstiness that will be allowed in the
queue
Calculating average queue size
avg = (1 - 1/weight) * avg + 1/weight * current_queue_size
V2.00
72
The weight parameter is a user configurable parameter.
72
RED - Packet-drop Probability

Determines how frequent packets are
dropped given the current level of
congestion
The objective is to drop packets at a fairly
evenly-spaced intervals
This is to avoid biases and global
synchronisation
Packets are dropped sufficiently frequently

to control the average queue size
V2.00
73
73
RED - Packet-drop Probability

Calculating packet-drop probability
probability = mark_probability (avg - min_threshold) /
(max_threshold - min_threshold)
The probability that a packet is dropped

from a connection is proportional to the
amount of packets sent by the connection
V2.00
74
The packet-drop probability is a function of the average queue size

discussed earlier.
The mark_probability, min_threshold and max_threshold parameters are
user configurable.
74
Weighted RED (WRED)

WRED combines IP precedence with RED
to implement multiple service classes with
defined drop rates
Precedence applied at the edge or prior to entering network
Administered in the core
In a congestion situation, higher priority traffic

is given precedence without exacerbating the
congestion problem
Lower priority traffic is throttled more aggressively
RED is applied to all levels of traffic to

manage congestion
Result: overall network traffic optimized,
giving precedence to high-priority traffic
V2.00
75
75
WRED Service Profile Example

1
Packet
Discard
Probability
Standard
Service
Profile
Adjustable
Standard
Minimum
Threshold
Premium
Minimum
Threshold
Two Service
Levels are Shown;
Up to Six
Can Be Defined
Premium
Service
Profile
Maximum
Threshold
Average
Queue
Size
V2.00
76
76
Where/When should I use WRED?

Congested long-haul links (e.g. transoceanic links)
Not recommended for campus networks
Where the bulk of your traffic is TCP as
oppose to UDP
Remember only TCP will react to a packet drop
UDP will not
V2.00
77
77
DWRED
WRED implementation in 11.1CC runs
distributed only on the VIP
DWRED (Distributed WRED)
It utilizes the processor and SRAM
memory on the VIP
This feature requires VIP2-40 or better
V2.00
78
78
Configuring DWRED
Enabling DWRED
[no] random-detect enable
Configuring weight factor for moving

average queue size calculation
random-detect queue-weight <weight>
V2.00
79
In most cases to turn on DWRED all you need to do is type the randomdetect enable interface command. The IOS will figure the rest out.
79
Configuring DWRED
Configuring DWRED max threshold
random-detect max-threshold <packets>
Configuring DWRED to not drop any

packets below <size> to avoid dropping
of TCP ACKs
random-detect min-mark-packet-size <size>
V2.00
80
80
Configuring DWRED
Configuring WRED parameters for a
specific CoS
random-detect precedence <n> <min-threshold>
<mark-probability>
Show command
show interface [interface] random-detect
V2.00
81
Note that the min-threshold parameter is a percentage of max-threshold.

The mark-probability parameter is by default 100.
To calculate the mark-probability for a particular precedence level;
p = 1/ mark-probability
81
WRED CLI
R3#conf term
R3(config)#int hssi 0/0/0
R3(config-if)#random-detect
random-detect ?
enable
Enable DWRED on this output interface
max-threshold
Maximum threshold
min-mark-packet-size Minimum packet size subject to marking
precedence
Parameters for each precedence value
queue-weight
Packet weight for queue depth average
V2.00
82
82
WRED Configuration Example

hssi0/0/0
R1
R3
R3#conf term
R3(config-if)#random-detect
random-detect enable
R3(config-if)#^Z
V2.00
83
83
WRED Configuration Example

R3#write terminal
!
interface Hssi0/0/0
ip address 200.200.14.250 255.255.255.252
random-detect max-threshold 256
random-detect min-mark-packet-size 50
random-detect queue-weight 1024
random-detect precedence 0 12 100
!
V2.00
84
84
WRED Show Command

R3#sh
sh int hssi0/0/0
Hssi0/0/0 is up, line protocol is up
Hardware is cyBus HSSI
Description: 45Mbps to R1
Internet address is 200.200.14.250/30
MTU 4470 bytes, BW 45045 Kbit, DLY 200 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
Last input 00:00:02, output 00:00:03, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Packet Drop strategy: VIP-based weighted RED
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
1976 packets input, 131263 bytes, 0 no buffer
Received 1577 broadcasts, 0 runts, 0 giants
0 parity
4 input errors, 4 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
1939 packets output, 130910 bytes, 0 underruns
0 output errors, 0 applique, 3 interface resets
0 output buffers copied, 0 interrupts, 0 failures
1 carrier transitions
V2.00
85
85
WRED Show Command

R3#sh
sh int hssi 0/0/0 random-detect
Hssi0/0/0 queue size 0
packets output 3, drops 0
WRED: queue average 0, max threshold 256
weight 1/1024, minimum mark packet size 50
Precedence 0: 32 min threshold, 1/100 mark weight
3 packets output, drops: 0 random, 0 threshold
(no traffic)
(no traffic)
(no traffic)
(no traffic)
(no traffic)
(no traffic)
(no traffic)
V2.00
86
86
WRED Show Command

Threshold Drop
Packet
Discard
Probability
Random Drop
Minimum
Threshold
Maximum
Threshold
Average
Queue
Size
V2.00
87
If you are seeing a lot of threshold drop you are no longer doing RED. What
you need to do is adjust your min-threshold to a point where you are no
longer seeing a lot of threshold drop.
87

Queue management
V2.00
88
88
Weighted Fair Queuing (WFQ)

Cisco 7500
RSP
What is WFQ?
Packet scheduling
algorithm on the transmit
path
Approximates the
Generalised Processor
Sharing (GPS) algorithm
(V)IP
(V)IP
VIP
V2.00
89
Packet scheduling algorithm determines the order in which buffered packets are
sent out to a transmission link.
An example of a packet scheduling algorithm is FIFO.
Before we go on to talk about WFQ let us briefly examine what Fair Queueing (FQ)
is. FQ was first introduced by J. Nagle [RFC970] in 1985 and later enhanced by A.
Demers, S. Keshav and S. Shenker [Analysis and Simulation of a Fair Queuing
Algorithm; ACM SIGCOMM 1989], Zhang [Virtual Clock; A New Traffic Control
Algorithm for Packet Switching Networks; ACM SIGCOMM 1990], and McKenney
[Stochastic Fairness Queuing; Internetworking Research and Experience].
The goal of FQ as introduced by Nagle was to protect the network from hosts that
are badly-behaved in the presence of both well-behaved and badly-behaved hosts.
This is to insure that well behaved hosts gets better service than badly-behaved
hosts.
With FQ each source host gets an equal fraction of the bandwidth. This is done by
having multiple queues on the outgoing interface (as oppose to a single queue
where all traffic gets queued on a single queue) one for each source host. The
backlog queues are serviced in a round robin fashion.
Because each source hosts has a queue of its own well-behaved hosts will be
protected from badly-behaved hosts. Badly-behaved hosts can send as many
packets as they want, but this will not increase their share of the bandwidth. All that
does is it fills up its own queue and when that happens their packets are dropped.
The problem with Nagles approached was a queue is required for every source
hosts on the network.
Demers, Keshav and Shenker did further studies on Nagles work and found that
the same effect can be archived by separating the traffic into flows and
guaranteeing that each flow gets an equal share of the bandwidth.
The W in WFQ was introduced by L. Zhang at about the same time as the work
done by Demers, Keshav and Shenker. The original algorithm introduced by Zhang
was called Virtual Clock (VC), later named Weighted Fair Queuing (WFQ). The
goal of FQ and VC was somewhat different, but they both have a common goal
which is to share resources fairly between a variable number of sources.
The objective of WFQ is to provide a packet based approximation of the the
Generalised Processor Sharing (GPS) model. That is providing queue service that
supports bandwidth allocation and delay bounds while providing fairness and
protection for connections and retains packet switching efficiency.
The GPS model also yields a delay bounds both for queueing delay at a single
router based on allocated buffer length for the associated traffic class and for endto-end queueing delay when the traffic source is constrained by a traffic contract
such as token bucket or leaky bucket mechanism.
89
Packet Scheduling
An algorithm that
determines the order
in which packets are
sent out to the
transmission link
Examples of packet
scheduling schemes
Cisco 7500
RSP
(V)IP
(V)IP
VIP
VIP
FIFO
Round Robin
Priority
forwarding
engine
V2.00
90
Output
Normal queuing; one queue per output interface
forwarding
engine
Output
Fair queuing; one queue per flow
90
Generalised Processor Sharing

(GPS)
Cisco 7500
RSP
Assign a weight for

each queue
Backlog queues are
severed in
proportion to their
weight
(V)IP
(V)IP
VIP
1 2 3
V2.00
91
The ideal algorithm is to serve each queue in proportion to its weight for
example for every 6 bits take 3 bits from the blue queue, 2 bits from the red
queue and 1 bit from the amber queue. Unfortunately though we deal in the
packet world. So the above is not practical.
What WFQ does is it approximates the GPS algorithm.
91
Why use WFQ?
Provides relative bandwidth guarantees

Fair Queuing (FQ) provides fair share
allocation of bandwidth
Weighted Fair Queuing (WFQ) allows for
unequal allocation of bandwidth
V2.00
92
92
Why use WFQ?

Provides absolute bandwidth/delay
guarantees
Good for real-time applications (e.g.
audio/video) and bandwidth provisioning
But requires cooperation of admission control
algorithm and use of traffic descriptor to
determine the traffic characteristics of the
application
Example:- average rate and burstiness of the traffic
V2.00
93
The absolute delay here talks about the delay on the transmit side.
The admission control algorithm and traffic descriptor has been discussed
earlier on; CAR.
To provide absolute delay you will have to be able to bound the queue size
and guarantee a service rate on the queue. This can only be done if you
have a traffic descriptor for the traffic you are dealing with.
guarantee delay == maximum delay.
93
DWFQ
WFQ implementation in 11.1CC runs
distributed only on the VIP
DWFQ (Distributed WFQ)
It utilizes the processor and SRAM
memory on the VIP
This feature requires VIP2-40 or better
V2.00
94
94
DWFQ
In 11.1CC WFQ supports

Flow-based WFQ (default)
Class-based WFQ
V2.00
95
95
Flow-based WFQ
A flow ID is computed for each packet
The flow ID is a hash computed on source and
destination IP address, source and destination
TCP/UDP port and ToS field
Based on the flow ID the packet is then

classified to the appropriate queue
In 11.1CC there are a total of 512 queues for
each interface
V2.00
96
Packets with the same IP source and destination address, TCP or UDP
source and destination port and Type-of-service (ToS) field belongs to the
same flow.
In 11.1CC each interface has a total of 512 queues; fix.
96
Flow-Based WFQ
Packets
arriving
Compute hash
Flow Queues
.
0
510
511
V2.00
97
97
Class-based WFQ
Packets can be classified into one of the
following
1) IP Precedence
2) TCP/UDP Port
3) IP Protocol
4) Source Interface
V2.00
98
98
Class-based WFQ
For IP precedence the classes follows
directly from the precedence value
For other class-based methods the
classes are defined by mapping a
parameter to a class
This is a user configurable parameter
Class range is from 031
V2.00
99
99
Class-based WFQ
Packets
arriving
Class-based
(IP Precedence)
.
0
V2.00
100
100
Class-based WFQ
Packets
arriving
Class-based
(IP Protocol)
.
TCP(6) UDP(17)
IPinIP(4) GRE(47)
.
0
30
31
V2.00
101
101
Weight Fair Queuing

Ones the packets are classified (to
either flow or class-based) a timestamp
is computed for each packet
The timestamp is computed based on
flow/class weights
This timestamp is used for packet
scheduling decision
V2.00
102
102
Weighted Fair Queuing

Packets
arriving
Flow or class-based queues

with timestamp entries
Output Queue
V2.00
103
103
Configuring WFQ
Enabling flow-based WFQ

[no] fair-queue enable
Enabling class-based WFQ

[no] fair-queue class-based
V2.00
104
As of writing (Nov 97) only precedence-based class-based WFQ is

supported. All the other options are currently not available and may change
in future release.
104
Configuring WFQ
Setting queue depth
fair-queue max-queue-depth <global-limit>
<local-limit>
Where
<global-limit> is the per interface buffer limit (in

number of packets)
<local-limit> is the per flow or per class limit (in

number of packets)
V2.00
105
105
Configuring WFQ
Changing the weights for each precedencebased class

fair-queue prec-weight <precedence> <weight>
Show command
show interface [interface] fair-queue
V2.00
106
106
DWFQ CLI
R1#conf term
R1(config-if)#fair-queue
fair-queue ?
<1-4096>
Congestive Discard Threshold
class-based
Enable class-based DWFQ on this output
interface
max-queue-depth Set maximum global and local queue depth
prec-weight
Set weight for each precedence-based class
<cr>
V2.00
107
The Congestive Discard Threshold parameter above is not used in the VIP
implementation of WFQ.
107
DWFQ Configuration Example

Flow-based WFQ
R1#conf term
fair-queue enable
Class-based WFQ
R1#conf term
fair-queue class-based
V2.00
108
108
DWFQ Configuration Example

R1#write term
!
interface Hssi0/0/0
ip address 200.200.14.250 255.255.255.252
fair-queue enable
fair-queue max-queue-depth 401 200
fair-queue prec-weight 0 8
!
V2.00
109
109
DWFQ Show Command

R1#sh
sh int hssi 0/0/0
Hssi0/0/0 is up, line protocol is up
Hardware is cyBus HSSI
Description: 45Mbps to R2
Internet address is 200.200.14.250/30
MTU 4470 bytes, BW 45045 Kbit, DLY 200 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
Last input 00:00:09, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Queueing strategy: VIP-based fair queuing
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
2011 packets input, 133587 bytes, 0 no buffer
Received 1604 broadcasts, 0 runts, 0 giants
0 parity
4 input errors, 4 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
1971 packets output, 133082 bytes, 0 underruns
0 output errors, 0 applique, 3 interface resets
0 output buffers copied, 0 interrupts, 0 failures
1 carrier transitions
V2.00
110
110
DWFQ Show Command

R1#sh
sh int hssi 0/0/0 fair-queue
Hssi0/0/0 queue size 0
packets output 35, drops 0
WFQ: global queue limit 401, local queue limit 200
Precedence 0: weight 8
V2.00
111
111

Queue management
V2.00
112
112
Granular Measurements
NetFlow
Billing and accounting
Planning
Traffic monitoring
MIB support
IP Precedence
MAC Accounting
CAR
WRED
V2.00
113
113
NetFlow
First
Packet
Subsequent
Packets
Route
Table
Access
List
Switching
Task
Security
Task
NetFlow
Cache
NetFlow
Switching
Task
NetFlow
Statistics
Acctg
Data
Acctg
Task
NetFlow Data
Export
Only first packet is processed by multiple tasks

NetFlow is definedwith specific service requirements
Single switching task applies network services and collects
traffic statistics
V2.00
114
NetFlow switching operates by creating a flow cache that contains the

information needed to switch and perform access list check for all active
flows. The NetFlow cache is built by processing the first packet of a flow
through the standard switching path (fast or optimum). As a result, each flow
is associated with an incoming and outgoing interface port number and with
a specific security access permission and encryption policy. The cache also
includes entries for traffic statistics that are updated in tandem with the
switching of subsequent packets. After the NetFlow cache is created,
packets identified as belonging to an existing flow can be switched based on
the cached information and security access list checks bypassed. Flow
information is maintained within the NetFlow cache for all active flows.
NetFlow switching is based on identifying packet flows and performing
switching and access list processing within a router. It does not involve any
connection-setup protocol either between routers or to any other networking
device or end station and does not require any change externallyeither to
the traffic or packets themselves or to any other networking device.
Note NetFlow does consume additional memory and CPU resources
compared to other switching modes; therefore, it is important to understand
the resources required on your router before enabling NetFlow.
114
NetFlowA Point to Note

With 11.1CC NetFlow is no longer a
switching mode as in 11.1CA & 11.2
In 11.1CC NetFlow is a service which
provides call record accounting
information for a IP network independent
of the switching mode used
The switching mode in 11.1CC is CEF
Distributed NetFlow and flow export
CEF and NetFlow integration
V2.00
115
115
Configuring NetFlow
Enabling NetFlow on an interface
[no] ip route-cache flow
Exporting flowsVersion 1
[no] ip flow-export <ip-address> <UDP-port>
Exporting flowsVersion 5
[no] ip flow-export <ip-address> <UDP-port>
version 5 {origin-AS|peer-AS}
Show command
show ip cache flow
V2.00
116
Flow export by default if you do not specify origin-AS or peer-AS does not
export the AS information.
Origin-AS is where the prefix originated and peer-AS is where you learned
the prefix from.
If you see an AS #0 in you cache entry or data export AS #0 is:
1. Local traffic
2. Traffic destined for the router
3. Flows which are unroutable (flow where there was not an entry in
the route cache for the source or destination)
4. If source AS = 0 and source prefix mask = 0 then it indicates the
absent of route entries
Normally the default size of the NetFlow cache will meet your needs.
However, you can increase or decrease the number of entries maintained in
the cache to meet the needs of your NetFlow traffic rates. The default is 64K
flow cache entries. Each cache entry is approximately 64 bytes of storage.
Assuming a cache with the default number of entries, approximately 4MB of
DRAM would be required. Each time a new flow is taken from the free flow
queue, the number of free flows is checked. If there are only a few free flows
remaining, NetFlow attempts to age 30 flows using an accelerated time-out.
If there is only one free flow remaining, NetFlow automatically ages 30 flows
regardless of their age. The intent is to ensure free flow entries are always
available.
Before attempting to changing the number of entries read the release notes.
116
NetFlow Metering Infrastructure
Network Planning
Accounting/Billing
Flow Profiling
Flow Switching
Flow
and Data Export Flow Collection Consolidation
Network Monitoring
Flow Consumers
117
117
NetFlow Data Record (V5)

Usage
Packet Count
Byte Count
Source IP Address
Destination IP Address
Time
of Day
Start Timestamp
End Timestamp
Source TCP/UDP Port

Destination TCP/UDP Port
Input Interface Port

Output Interface Port
Next Hop Address

Source AS Number
Destination AS Number
Port
Utilization
QoS
Type of Service
TCP Flags
Protocol
Application
Routing
and
Peering
V2.00
118
118
NetFlow FlowCollector
Receive flow export data from router(s) on
predefined UDP port(s)
Supports both version 1 and 5 NetFlow
records
Filtering (permit/deny) on the fly
Summarize/aggregate as needed
Periodically flush summarized data to disk
Filesystem management
V2.00
119
On the router you specify an IP address and a UDP port number to export
the flow data to. The UDP port number can be one UDP port number where
all routers export their flow data to or it can be a UDP port number for a
router and anything in between that.
119
FlowCollector Architecture
NetFlow Exports
Workstation
Filter
User
Interface
FlowCollector
Summarize
Storage
Config
Files
Flow Consumer
Applications
V2.00
120
120
Summarization/Aggregation
Objective to reduce the data to be stored and
prepare it for the end application
HostMatrix (conversion-pairs)
DetailHostMatrix (HostMatrix + application infomation +
start/end timestamps)
CallRecord (NetFlow usage record)
Template for usage-based (CoS, time-of-day, etc.) billing
Gives host IP addresses + ports + protocols +
ToS and total time spent in the router on switching +
start/end stamps
DetailInterface, traffic per interface-pair as well as

nexthop, useful in planning resources, trending etc.
SourceNode, DestNode, SourcePort, Protocol etc.
V2.00
121
121
FlowCollector v1.0
FCS - Oct 97
Platform supported
Solaris 2.5
HP-UX - 10.2
V2.00
122
122
FlowCollector - Sample Config
Filter allow-web-server
Permit Srcport
80
Filter deny-icmp-traffic
Deny Prot
1
Permit Dstaddr 0.0.0.0 255.255.255.255
V2.00
123
See Appendix F for a complete list of FlowCollector Attritubes and their

meaning.
123
FlowCollector - Sample Config

Thread DAM
Aggregation DetailASMatrix
Period 30
Port 9992
State Active
DataSetPath /usr1/netflow/data/r1
DiskSpaceLimit 1000
FileRetain 32
Thread CALLREC
Aggregation CallRecord
Period 30
Port 9991
State Active
DataSetPath /usr1/netflow/data/r2
DiskSpaceLimit 1000
FileRetain 0
V2.00
124
124
NetFlow FlowAnalyzer
GUI front end to FlowCollector
Web based
Java applet running in a html file
Formats and display data

Data analysis
Charts
Spreadsheet data export capability
V2.00
125
125
FlowAnalyzer
Server
Unix platform (SUN & HP-UX)
Client
Unix
PCs
MACs
V2.00
126
126
FlowAnalyzer Architecture
UNIX Workstation
FlowAnalyzer Server
Aggregation
Processing
FlowCollector
FlowAnalyzer Display
FlowCollector
FlowCollector
V2.00
127
127
FlowAnalyzer Server Components

FlowAnalyzer Display
Communications (Java)
Aggregation
Processing
V2.00
128
128
FlowAnalyzer Client Components

Java AWT 1.02
Netchart:
Graphs
How it works
Microline:
Trees,
Tabs, &
Spreadsheet
Communications
FlowAnalyzer Server
V2.00
129
129
FlowAnalyzer v1.0 Features

Displays results of all aggregation
schemes except raw
Set time ranges for viewing data
Table and graph displays
Sorting capability
Save data in Excel spreadsheet format
Online help
V2.00
130
130
Platforms Supported
Client
Server
Solaris 2.5.1
Solaris 2.5.1
Netscape 3.0 and 3.0

Gold
Windows 9.5 & MAC
HP-UX 10.2
Java 1.0.2
Netscape 3.0, 3.0 Gold

and MSIE
V2.00
131
131
FlowAnalyzer v1.0
FCS - Oct 97
Bundled with FlowCollector v1.0
Demo copy for FlowCollector and
FlowAnalyzer available
http://www.cisco.com/kobayashi/sw-center/netmgmt/nfplanner.shtml
V2.00
132
132
Netsys Technologies and NetFlow

Proactive Planning/Design
Reactive Analysis and Diagnosis
Netsys
Workstation
FlowCollector
Token
Ring
Views and Reports

Link, LAN, router utilizations
Application mix
Communicating pairs
What-If Analyses
FDDI
Dual
Ring
Bandwidth/provisioning
Topology
Configuration tuning
V2.00
133
133
MIB Support
CAR MIBS
WRED MIBS
IP Accounting &
WFQ MIBS
Statistics MIBS
CAR
Configuration
Table
WRED Global
MAC Accounting
Configuration Table Table
CAR Statistics
Table
WRED Precedence IP Precedence

Configuration Table Accounting Table
None
NetFlow
MIBS
None
WRED Queue
Length Table
WRED Statistics
Table
WRED Backing
Store Statistics
Table
V2.00
134
134
CAR MIBS
CAR Configuration Table
CAR Statistics Table
Rate Limit Direction
Packets Switched*
Rate Limit Type

Access List Index
Bytes Switched
Committed Rate
Bytes Filtered
Burst Limit
Current Burst
Packets Filtered
Excess Burst Limit

Conform Action
Exceed Action
* For rate limit
V2.00
135
135
WRED MIBS
WRED Global
Configuration Table
No Discard Size
WRED Precedence
Configuration Table
WRED Queue
Length Table
Average Queue
Length
Precedence
Average Queue Length Queue Minimum

Decay Constant
Depth Threshold
Queue Depth
WRED Backing
WRED Statistics
Store Status
Table
Table
Packet
Switched
Backing Store
Queue Depth
Byte Switched
Queue Maximum
Depth Threshold
Packets Filtered
from Minimum
Depth Threshold
Drop Probability
Packets Filtered
from Maximum
Depth Threshold
Packets Filtered
due to Backing
Store Exhaust
V2.00
136
136
MAC/Precedence Accounting MIB
MAC Accounting MIB
IP Precedence
Accounting MIB
Packet Direction (input or

output)
MAC Address
IP Precedence
Packets Switched
Packets Switched
Bytes Switched
Bytes Switched
Packets Direction
V2.00
137
137
Putting It All Together
L3 CAR
WRED/WFQ
L3 CAR
Packet
Classifier
Premium
Apply Ingress
Rate Thresholds
Determine
Packet Class
Medium
Standard
Administer
Packet Class
Apply Egress
Rate Thresholds
Traffic Metering
138
138
Configuration Guidelines
Feature
Availability
Platform
Performance
Operation
CAR Packet
Classification
11.1CC
7500 on RSP or
distributed, 7200
T3/E3 per VIP
CAR Rate
Limiting
11.1CC
7500 on RSP or
distributed, 7200
T3/E3 per VIP
BGP Policy
Propagation
11.1CC
7500 on RSP or T3/E3 per VIP

distributed, 7200
Input
side
RED/WRED
11.1CC
7500 distributed
only
T3/E3 per VIP
Output
side
WFQ
11.1CC
7500 distributed
only
T3/E3 per VIP
Output
side
7500 on RSP or
distributed, 7200
N/A
Input
side
7500 on RSP or
distributed, 7200
N/A
N/A
11.1(12)CA,
NetFlow
[or greater]
11.1CC
CEF
11.1CC
N/A
Input or
Output side
Requirements
requires VIP2-40 or better
to run distributed, requires
CEF, requires BGP for
precedence propagation
CEF
CEF and BGP
CEF
CEF
router NetFlow license,
optional FlowCollector &
FlowAnalyzer
with 32M DRAM to run
distributed
V2.00
139
139
The End
Q&A
V2.00
140
140
Resources
PM for NetFlow & Internet QoS
David Powell (dpowell@cisco.com)
Internet QoS web page

http://corewww.cisco.com/core/html/
qosindex.html
Mailing-list
cs-ipservices@cisco.com
V2.00
141
Please note that the above URL can only be accessed from within Ciscos
internal network.
141
Case Study
V2.00
142
142
Case Study
Application based rate-limiting
Premium bandwidth delivery
Subrate IP service
IX traffic control
Web hosting service
V2.00
143
143
Application Based Rate-Limiting

WWW
50%
Telnet
FTP
Rate limit a particular type of traffic (e.g., Web) to

a portion of the bandwidth
This is done so that the application does not take
up the entire pipe
Can be applied either on the outgoing or incoming
path or both
V2.00
144
144
Premium Bandwidth Delivery

Premium
Customers
ISP1
Broadband Pipe
Standard
Customers
Customer
Premium bandwidth allocation

enforced by WRED or WFQ
Premium charging via NetFlow
ISP2
Bi-directional premium traffic via

BGP policy propagation
Standard traffic bursts to fill capacity
V2.00
145
145
IP Subrate Service
Fractional bandwidth pipes via rate limiting by port

Upgrade to higher speed without physical reconfig
Discard or recolour excess traffic
NetFlow metering for reporting and charging
Business customer or ISP application
V2.00
146
146
Exchange Point Traffic Control

Downstream ISP &
peering bandwidth
control
Peer A
Peer C
Rate limit by MAC

address
Discard excess traffic
MAC accounting
Peer B
V2.00
147
147
ISP Web Hosting

Premium Traffic
Standard Traffic
Medium Traffic
Multiple classes of hosting customers

Rate limit or allocate bandwidth to
each server
ISP Network
Classify traffic from/to each server

Measure and bill with NetFlow and
CAR MIB
V2.00
148
148
Internet QoS Demo
V2.00
149
149
Demo
Demo objectives
Topology
Configuration
V2.00
150
The router configuration for this demo can be found in appendix E.
150
Demo Objective
The objective of this demo is to

demonstrate how Internet QoS
works and how the different IOS
Internet QoS feature tie together
V2.00
151
151
CAR Demo
30,000pps
f0/0/0
f1/0/0
30,000pps
rate-limit 20,000pps
V2.00
152
This quick demo illustrates how rate-limiting works.

For config see R1 config in Appendix E.
152
Topology
Traffic
Generator
Traffic
Generator
FE
R4
FDDI
R1
Traffic
Generator
Traffic
Generator
HSSI
HSSI
Traffic
Generator
FE
Traffic
Generator
FE
R2
HSSI
R3
FE
FE
FE
Traffic
Generator
Traffic
Generator
V2.00
153
153
Topology
Traffic
Generator
Traffic
Generator
AS200 (200.200.240.0/20)
FE
R4
FDDI
R1
Traffic
Generator
Traffic
Generator
HSSI
HSSI
Traffic
Generator
FE
Traffic
Generator
FE
R2
HSSI
R3
FE
FE
Traffic
Generator
AS210 (210.210.240.0/20)
FE
Traffic
Generator
V2.00
154
154
Demo 1
3
Traffic
Generator
Traffic
Generator
Premium
FE
Standard
R4
Direction of Traffic
4
FDDI
R1
FE
Traffic
Generator
Traffic
Generator
HSSI
HSSI
Traffic
Generator
DWFQ
FE
R2
CAR
6
HSSI
7
Traffic
Generator
R3
FE
CAR
FE
FE
Traffic
Generator
Traffic
Generator
V2.00
155
155
Demo 2
3
Traffic
Generator
Traffic
Generator
Premium
FE
Standard
R4
Direction of Traffic
4
FDDI
R1
DWRED
5
Traffic
Generator
FE
Traffic
Generator
Traffic
Generator
HSSI
HSSI
Traffic
Generator
FE
R2
CAR
6
R3
HSSI
FE
CAR
FE
Traffic
Generator
DWFQ
FE
Traffic
Generator
V2.00
156
156
APPENDIX
APPENDIX........................................................................................................................................................157
APPENDIX A - CEF COMMAND SYNTAX ..................................................................................................158
INTRODUCTION ...............................................................................................................................................158
PLATFORM REQUIREMENTS ..............................................................................................................................158
CEF CONFIGURATION/SHOW/DEBUG COMMANDS ..............................................................................................158
APPENDIX B - BGP POLICY PROPAGATION............................................................................................162
APPENDIX C - LAB HARDWARE CONFIGURATION...............................................................................164
APPENDIX D - LAB IP ADDRESS LAYOUT ................................................................................................165
APPENDIX E - LAB ROUTER CONFIG .......................................................................................................167
ROUTER - R1...................................................................................................................................................167
ROUTER - R2...................................................................................................................................................170
ROUTER - R3...................................................................................................................................................173
ROUTER - R4...................................................................................................................................................176
APPENDIX F - FLOWCOLLECTOR ATTRIBUTES LIST..........................................................................178
157
APPENDIX A - CEF Command Syntax

Introduction
Cisco Express Forwarding (CEF) is a new form of scaleable switching intended to
tackle the problems associated with demand caching. With CEF switching, the
information which is conventionally stored in a route cache is now split up over several
data structures. The CEF code is able to maintain these data structures in the RSP,
and also in slave processors such as the VIP2. The data structures include:
A CEF table, containing all IP prefixes from the main routing table.
An adjacency table, containing layer 2 rewrite strings.
Shadow copies of hardware and software interface information, as needed for
maintaining the CEF, and also for switching packets.
With the CEF code, IP packets can be switched at interrupt level, just like fast,
optimum, and flow switching. This packet switching can be performed strictly on the
RSP, or it can also occur in a distributed mode (like DFS), where both the RSP and VIP
processors can concurrently switch IP packets. When CEF is configured in a
distributed mode, each VIP has a separate copy of the above mentioned data
structures.
Platform Requirements
Currently CEF is supported in 7500 and 7200. VIP2 is needed for distributed CEF. For
full Internet routing table, VIP2's should have 32M memory.
CEF configuration/show/debug commands
The following is a brief description of the commands that are added with CEF switching.
I. Configuration Commands:
Global:
[no] ip cef switching
Enable CEF on the RSP
[no] ip cef distributed switching
Enable distributed CEF
158
[no] ip cef accounting [per-prefix] | [per-adjacency]

Enable per-prefix/per-adjacency accounting on both VIP and RSP
Interface:
no ip route-cache distributed
To disable fib switching on interface. Can be used only when express-cef
is already configured on the router.
ip load-sharing [per-packet] | [per-destination]
no ip load-sharing per-packet
To specify the type of load-sharing on an interface.
II. Show Commands:
show ip cef [unresolved] | [summary]
unresolved : Display all prefixes which are unresolved at the moment
summary : Display summary info on the CEF table: size of table (int
bytes), number of nodes, leaves, number of routes, unresolved routes,
etc.
Available both in RSP and on VIPs.
show ip cef [[<prefix>] [<mask>] [<longer-prefix>]] [internal]
detail : Provide detailed information on a destination prefix : Detailed
information for a prefix includes the nexthop, nexthop interface, number of
dependencies, the nature of the cached adjacency, packet and bytes
transferred to this prefix and the gateway via which this destination can be
reached.
internal : Displays data stored in the loadinfo structure used for loadsharing.
If no prefix is specified all the fib entries are displayed.
If the keyword 'longer-prefix' is specified after the mask of a prefix then all
the longer (more specific) prefixes of this prefix is displayed. Available on
both RSP and VIPs.
show ip cef adjacency <next-hop interface> <next-hop ipaddress> [detail] |
[internal]
159
Display info on prefixes resolving (directly or recursively) resolving

through regular adjacency specified by <next-hop intfc> and <next-hop
ipaddress>
show ip cef adjacency glean | discard | drop | punt | null [detail] | [internal]
Display info on prefixes resolving through the special adjacencies - glean,
discard, drop, punt, null
show cef interface <interface> [detail] | [stat]
Displays express-forwarding related interface information, whether this
interface can express-forward the packet or not and why, the type of loadsharing configured, the transmit queue pointer etc.
The 'stat' keyword is available only the VIPs. Provides a in/out pkt/byte
count per interface on VIP.
Available on both RSP and VIPs
show cef [drop] | [not-cef-switched]
drop : Classifies packets dropped at each VIP. Packets are dropped at
the VIPs because of encapsulation failure, no route, no adjacency.
not-cef-switched : Classifies packets sent to next slower switching
because cef was unsupported, packets were locally destined for the box,
packet has IP OPTIONS, etc
Available on RSP only.
show cef linecard [<number>] [detail]
Shows CEF information pertaining to VIPs. Displays the number of
prefix/adjacencies queued up by route-processor for updates, messages
sent by RSP, total packets and bytes transferred by VIP.
Available on RSP only.
show adjacency [detail] | [internal]
Shows the adjacency specific information , protocol from which it was
learnt, timers, and other internal data structures.
160
III. Clear Commands:

clear cef linecard [<slot-number>] [adjacency] | [interface | prefix]
Available on RSP only. Reload either the adjacency, distributed interface,
or CEF database information. If a slot number is specified, only perform
the reload for that particular VIP slot, otherwise all VIP slots receive the
reload operation.
clear ip cef [<prefix> [<mask>]] | [*] statistics
Clear the packet/byte count for the specific prefix. If * is specified then
clear all prefix statistics.
clear adjacency
Clean up the adjacency database.
IV. Debug Commands:
debug ip cef [table] | [events] | [interface-ipc] | [prefix-ipc] | [drops]
161
APPENDIX B - BGP Policy Propagation

Currently we have mechanism to set Precedence based on the inbound interface and
source IP address. With this new feature, we can set Precedence on the packet based
on the destination IP address. This uses the BGP attributes (AS-path or Community) to
convey Precedence value indirectly for different prefixes via BGP updates. This
approach is scaleable as the Precedence for destinations are learnt via routing
protocol.
For example each Precedence value is assigned BGP community value and prefixes
are tagged with appropriate Community value. BGP will perform bestpath selection and
install the best path in the IP routing table. The 'table-map' BGP router configuration
command can be used to map the Community value to IP Precedence when installing
the prefix in the IP routing table. The Precedence value is populated in the FIB table
along with the prefix. When packets are switched by FIB, Precedence for the
destinations are picked from FIB entry and set in the packets.
To support the above functionality, route-map is enhanced to support Precedence
setting.
For example the following will set Precedence 5 for prefixes with community 1000:5,
and Precedence 4 for prefixes with community 1000:4.
!
! to support new Community format
!
!
!
router bgp 1000
neighbor x.x.x.x ...
.
.
.
!
!
!
match community-list 1
set ip precedence 5
!
162

match community-list 2
set ip precedence 4
!
In the following example, as-path access-list is used in the route-map to set
precedence. This will set precedence of packets going thru AS 109, AS 120 to have
precedence 5 and for packets destined to AS 130 to have precedence 4.
!
!
router bgp 100
neighbor x.x.x.x ...
!
!
ip as-path access-list 101 permit _109_
ip as-path access-list 101 permit _120_
ip as-path access-list 102 permit _130$
!
!
match as-path 101
set ip precedence 5
!
match as-path 102
set ip precedence 4
!
route-map precedence permit 30
!
Verification
use the 'show ip bgp x.x.x.x' to verify if correct community is set on the prefixes
use the 'show ip bgp community-list <num>' to verify if the correct prefixes are
selected.
use the 'show ip route x.x.x.x' to verify if the correct Precedence values are set on
the prefixes.
use the 'show ip cef x.x.x.x' to verify if FIB has the correct Precedence value for the
prefix.
163
Appendix C - Lab Hardware Configuration

R1
7505
Slot
Card
4 RSP4 (64MB)
3 VIP2-40
2 VIP2-40
1 VIP2-40
0 VIP2-40
R2
7505
Slot
Card
4 RSP4 (64MB)
3 VIP2-40
2 VIP2-40
1 VIP2-40
0 VIP2-40
R3
7505
Slot
Card
4 RSP4 (64MB)
3 VIP2-40
2 VIP2-40
1 VIP2-40
0 VIP2-40
R4
7206
Slot
Card
0 NPE-200/7200-I/O (64MB)
1 PA-F-MM
2 PA-FE-TX
3 PA-FE-TX
4 PA-4E
5 Empty
6 Empty
Slot 0
PA-H
PA-F-MM
PA-FE-TX
PA-FE-TX
Slot 0
PA-FE-TX
PA-FE-TX
PA-H
PA-H
Slot 0
PA-FE-TX
PA-FE-TX
PA-H
PA-H
Slot 1
PA-H
PA-FE-TX
Empty
Empty
Slot 1
Empty
Empty
Empty
Empty
Slot 1
Empty
Empty
Empty
Empty
164
Appendix D - Lab IP Address Layout

AS200
R1 - 7505/RSP4
Interface
Loopback 0
FastEthernet 0/0/0
FastEthernet 1/1/0
Fddi 2/0/0
FastEthernet 2/1/0
Hssi 3/0/0
Hssi 3/1/0
R4 - 7206/200
Interface
Loopback 0
Fddi 1/0
FastEthernet 2/0
FastEthernet 3/0
AS210
R2 - 7505/RSP4
Interface
Loopback 0
Hssi 0/0/0
Hssi 1/0/0
FastEthernet 2/0/0
FastEthernet 3/0/0
(200.200.0.0/20)
Subnet
200.200.14.1/32
200.200.1.0/24
200.200.2.0/24
200.200.5.0/24
200.200.6.0/24
200.200.14.252/30
200.200.14.248/30
IP Address
200.200.14.1
200.200.1.1
200.200.2.1
200.200.5.1
200.200.6.1
200.200.14.253
200.200.14.249
Subnet Mask
255.255.255.255
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.252
255.255.255.252
Subnet
200.200.14.2/32
200.200.5.0/24
200.200.3.0/24
200.200.4.0/24
IP Address
200.200.14.2
200.200.5.2
200.200.3.1
200.200.4.1
Subnet Mask
255.255.255.255
255.255.255.0
255.255.255.0
255.255.255.0
IP Address
210.210.14.1
200.200.14.254
210.210.14.253
210.210.1.1
210.210.2.1
Subnet Mask
255.255.255.255
255.255.255.252
255.255.255.252
255.255.255.0
255.255.255.0
Remarks
to Smartbit #1
to Smartbit #2
to R4
to 10/100 Ether Switch
to R2
to R3
Remarks
to R2
to Smartbit #3
to Smartbit #4
(210.210.0.0/20)
Subnet
210.210.14.1/32
200.200.14.252/30
210.210.14.252/30
210.210.1.0/24
210.210.2.0/24
Remarks
to R1
to R3
to Smartbit #5
to Smartbit #6
165
R3 - 7505/RSP4
Interface
Loopback 0
Hssi 0/0/0
Hssi 1/0/0
FastEthernet 2/0/0
FastEthernet 3/0/0
Subnet
210.210.14.2/32
200.200.14.248/30
210.210.14.252/30
210.210.3.0/24
210.210.4.0/24
IP Address
210.210.14.2
200.200.14.250
210.210.14.254
210.210.3.1
210.210.4.1
Subnet Mask
255.255.255.255
255.255.255.252
255.255.255.252
255.255.255.0
255.255.255.0
Remarks
to R1
to R2
to Smartbit #7
to Smartbit #8
166
Appendix E - Lab Router Config

Router - R1
R1#write term
Building configuration...
Current configuration:
!
version 11.1
no service udp-small-servers
no service tcp-small-servers
!
hostname R1
!
boot system flash slot0:rsp-pv-mz.dcar
!
ip subnet-zero
no ip domain-lookup
ip spd enable
ip cef distributed switch
!
interface Loopback0
ip address 200.200.14.1 255.255.255.255
transmit-buffers backing-store
!
interface FastEthernet0/0/0
description Smartbit #1
mac-address 0000.c000.0001
ip address 200.200.1.1 255.255.255.0
no ip route-cache optimum
ip route-cache distributed
no keepalive
full-duplex
no cdp enable
!
ip address 200.200.2.1 255.255.255.0
rate-limit input 21120000 64000 80000 conform-action transmit
exceed-action drop
no keepalive
full-duplex
!
interface Fddi2/0/0
ip address 200.200.5.1 255.255.255.0
no keepalive
167
!
ip address 200.200.6.1 255.255.255.0
!
interface Hssi3/0/0
ip address 200.200.14.253 255.255.255.252
hssi internal-clock
!
interface Hssi3/1/0
ip address 200.200.14.249 255.255.255.252
hssi internal-clock
!
router ospf 200
passive-interface FastEthernet0/0/0
passive-interface Hssi3/0/0
network 0.0.0.0 255.255.255.255 area 0
!
router bgp 200
no synchronization
network 200.200.0.0 mask 255.255.240.0
network 200.200.1.0
network 200.200.2.0
neighbor external-210 peer-group
neighbor external-210 remote-as 210
neighbor external-210 soft-reconfiguration inbound
neighbor external-210 remove-private-AS
neighbor external-210 version 4
neighbor internal peer-group
neighbor internal remote-as 200
neighbor internal update-source Loopback0
neighbor internal send-community
neighbor internal version 4
neighbor 200.200.14.2 peer-group internal
neighbor 200.200.14.250 peer-group external-210
neighbor 200.200.14.254 peer-group external-210
maximum-paths 2
no auto-summary
!
ip classless
ip route 200.200.0.0 255.255.240.0 Null0 254
logging buffered
arp 200.200.2.10 0000.0000.0002 ARPA
arp 200.200.1.10 0000.0000.0001 ARPA
no cdp run
168
!
!
line con 0
line aux 0
line vty 0 4
login
!
end
R1#
169
Router - R2
R2#write term
!
version 11.1
!
hostname R2
!
boot system flash slot0:rsp-pv-mz.11.1CC
!
ip subnet-zero
no ip domain-lookup
ip spd enable
!
interface Loopback0
ip address 210.210.14.1 255.255.255.255
!
interface Hssi0/0/0
ip address 200.200.14.254 255.255.255.252
hssi internal-clock
random-detect max-threshold 380
random-detect min-mark-packet-size 50
random-detect queue-weight 1024
!
interface Hssi1/0/0
ip address 210.210.14.253 255.255.255.252
ip accounting precedence input
no keepalive
hssi internal-clock
!
170
rate-limit input 155000000 80000 80000 conform-action set-prectransmit 5 exceed-action set-prec-transmit 5

ip address 210.210.1.1 255.255.255.0
no keepalive
full-duplex
!
ip address 210.210.2.1 255.255.255.0
no keepalive
full-duplex
!
router ospf 210
network 0.0.0.0 255.255.255.255 area 0
!
router bgp 210
no synchronization
network 210.210.0.0 mask 255.255.240.0
network 210.210.1.0
network 210.210.2.0
neighbor 200.200.14.253 soft-reconfiguration inbound
neighbor 200.200.14.253 remove-private-AS
neighbor 200.200.14.253 version 4
neighbor 200.200.14.253 route-map set-MED out
no auto-summary
!
ip classless
ip route 210.210.0.0 255.255.240.0 Null0 254
logging buffered
arp 210.210.2.10 0000.0000.0006 ARPA
arp 210.210.1.10 0000.0000.0005 ARPA
no cdp run
171
route-map set-MED permit 10

match ip address 1
set metric 0
!
set metric 10
!
match community 1
set ip precedence critical
!
match community 2
set ip precedence flash-override
!
match community 3
set ip precedence flash
!
match community 4
set ip precedence immediate
!
match community 5
set ip precedence priority
!
set ip precedence routine
!
!
!
line con 0
line aux 0
line vty 0 4
login
!
end
R2#
172
Router - R3
R3#write term
!
version 11.1
!
hostname R3
!
boot system flash slot0:rsp-pv-mz.dcar
!
ip subnet-zero
no ip domain-lookup
ip spd enable
ip cef distributed switch
!
interface Loopback0
ip address 210.210.14.2 255.255.255.255
!
interface Hssi0/0/0
ip address 200.200.14.250 255.255.255.252
shutdown
fair-queue enable
hssi internal-clock
!
interface Hssi1/0/0
ip address 210.210.14.254 255.255.255.252
no keepalive
fair-queue enable
173
fair-queue prec-weight
hssi internal-clock
1
2
3
4
5
6
7
7
6
5
4
24
2
1
!
ip address 210.210.3.1 255.255.255.0
no keepalive
full-duplex
!
ip address 210.210.4.1 255.255.255.0
no keepalive
full-duplex
!
router ospf 210
network 0.0.0.0 255.255.255.255 area 0
!
router bgp 210
no synchronization
network 210.210.0.0 mask 255.255.240.0
network 210.210.3.0
network 210.210.4.0
neighbor 200.200.14.249 soft-reconfiguration inbound
neighbor 200.200.14.249 remove-private-AS
neighbor 200.200.14.249 version 4
neighbor 200.200.14.249 route-map set-MED out
!
ip classless
174
ip route 210.210.0.0 255.255.240.0 Null0 254

ip community-list 1 permit 13762565
logging buffered
arp 210.210.3.10 0000.0000.0007 ARPA
arp 210.210.4.10 0000.0000.0008 ARPA
no cdp run
match ip address 1
set metric 0
!
set metric 10
!
match community 1
set ip precedence critical
!
match community 2
set ip precedence flash-override
!
match community 3
set ip precedence flash
!
match community 4
set ip precedence immediate
!
match community 5
set ip precedence priority
!
set ip precedence routine
!
!
!
line con 0
line aux 0
line vty 0 4
login
!
end
R3#
175
Router - R4
R4#write term
!
version 11.1
service udp-small-servers
service tcp-small-servers
!
hostname R4
!
boot system flash slot0:c7200-p-mz.l3_test
!
ip subnet-zero
no ip domain-lookup
ip spd enable
ip cef switch
!
interface Loopback0
ip address 200.200.14.2 255.255.255.255
!
interface Fddi1/0
ip address 200.200.5.2 255.255.255.0
no keepalive
!
interface FastEthernet2/0
ip address 200.200.3.1 255.255.255.0
no keepalive
full-duplex
!
interface FastEthernet3/0
ip address 200.200.4.1 255.255.255.0
no keepalive
full-duplex
!
interface Ethernet4/0
no ip address
shutdown
!
no ip address
shutdown
!
no ip address
shutdown
!
176
no ip address
shutdown
!
router ospf 210
passive-interface FastEthernet2/0
passive-interface FastEthernet3/0
network 0.0.0.0 255.255.255.255 area 0
!
router bgp 200
no synchronization
network 200.200.0.0 mask 255.255.240.0
network 200.200.3.0
network 200.200.4.0
neighbor internal send-community
no auto-summary
!
ip classless
ip route 200.200.0.0 255.255.240.0 Null0 254
logging buffered
arp 200.200.3.10 0000.0000.0003 ARPA
arp 200.200.4.10 0000.0000.0004 ARPA
no cdp run
!
!
line con 0
line aux 0
line vty 0 4
login
!
end
R4#
177
Appendix F - FlowCollector Attributes List

Below is a list of the FlowCollector Attributes and their definitions.
Attribute
Thread
Variable
Thread-name
Filter
Filter-name
Aggregation
Scheme
Period
Minutes
DataSetPath
Dirctory-path
DiskSpaceLimit
Megabytes
FileRetain
Number
Definition
Unique name of the thread. Can be up to 18
alphanumeric characters.
(Optional.) Unique name of the filter. Can be up
to 18 alphanumeric characters. When more than
one filter is defined, the result is logical AND of
them. You can specify one or more filters, and
filters can be shared among threads. For more
information on filters, refer to the Filter Syntax
section.
A way to summarize data collected by the
FlowCollector application.
Duration of the thread. (That is, how often the
FlowCollector application writes aggregated
data into a file. Data received in each period is
written into a separate file.) For example, setting
period 30 generates two files every hour.
Directory path used for storing the aggregated
data. The output filename is <routername>.hhmm or
<router-name>_YYYY_MM_DD.hhmm, and the
flag to enable this is
LONG_OUTPUTFILE_SUFFIX in the
nf.resources file. For more information on the
output files, refer to the section entitled
Understanding the Output File Form in the
chapter entitled Using the NetFlow collector.
Defines a limit of the total disk usage for the disk
partition where DataSetPath resides, beyond
which this thread will no longer write data to the
disk. This parameter essentially allows you to
reserve disk space for other threads by limiting
the amount of disk space consumed by this
thread, and can help prevent disk space
exhaustion as well. Default for DiskSpaceLimit
is 1000 MB.
Invokes the program to clean up files. The
program removes the oldest files and leaves the
number of files to retain on a per DataSetPath
178
Port
Version
Port-num
per day per router ID per aggregation scheme

basis. To disable this, set FileRetain to 0. For
example, setting FileRetain 10 with a total of 12
files causes the program to delete the two oldest
files.
The UDP port used by the router to report the
traffic.
NetFlow export version expected on the port
configured with this thread. Valid values are V1
or V5.
179

Internet QoS Workshop

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Internet QoS Workshop

Încărcat de

Drepturi de autor:

Formate disponibile

Internet QoS Workshop

Greetings and welcome to Cisco training on Internet QoS.

Cisco Systems Confidential

Cisco QoS Initiative

BGP Policy Propagation

FIFO, Priority, Custom, WFQ

Cisco Systems Confidential

Cisco QoS Initiative

This workshop will focus on features in

Cisco QoS Initiative

Cisco Systems Confidential

What is Internet QoS?

Cisco Systems Confidential

Layer 3 vs Layer 2 QoS

In delivering Layer 3 QoS a set of

Layer 3 vs Layer 2 QoS

Cisco Systems Confidential

The focus of this workshop is

Cisco Systems Confidential

Internet QoS Building Blocks

Internet QoS Building Blocks

Distributed Switching & Services

Distributed Switching & Services

Cisco Systems Confidential

Distributed Switching & Services

Cisco Express Forwarding (CEF)

First packet to destination processed by route processor

Forwarding information automatically distributed to

Cisco Systems Confidential

Cisco Express Forwarding (CEF) technology for IP is a scaleable,

Cisco Systems Confidential

All Packets Forwarded by VIPs

For xIP to VIP and xIP to xIP packet

Versatile Interface Processor (VIP)

Cisco Systems Confidential

Distributed services runs on the VIP.

Internet QoS Building Blocks

Next we will talk about Packet Classification and Access Bandwidth

Committed Access Rate (CAR)

Cisco Systems Confidential

Cisco Systems Confidential

CAR - Traffic Matching Specification

CAR - Traffic Measurement

CAR - Traffic Measurement

Packets arriving with sufficient tokens

Cisco Systems Confidential

CAR - Traffic Measurement

Cisco Systems Confidential

CAR - Traffic Measurement

Normal burst size (bytes)

Extended burst size (bytes)

Cisco Systems Confidential

p - Token arrival rate

The token bucket accumulates token at the Committed Rate up to the

Cisco Systems Confidential

CAR - Action Policies

Set precedence and continue (rewrite the IP

Rate-limit statement can be cascaded

In 11.1CC the rate-limit list is not bounded.

CAR - Policy Examples

Per Application CAR

Token vs Leaky Bucket

Cisco Systems Confidential

Definition of Traffic shaping: Traffic shaping is forcing your traffic to conform