Thursday, July 23, 2009

MPLS - BGP L3 VPN




With CCIE version 4 coming round the corner in October i thought i would turn my attention to some of the new topics on the syllabus. Here i look at MPLS VPNS and in the post i configure an MPLS L3 VPN.

There are 3 customers: A, B and C. These are connected across the shared MPLS infrastructure. The goal is to allow each customer to see their partner sites routes, and their routes only, across the MPLS cloud.

In this post i do not plan to look at the detailed workings of MPLS VPNS but rather just detail the steps necessary to build and configure.

In the MPLS cloud, BGP peering to the customer sites is implemented. The IGP routing protocol in the PE network is OSPF. The config i used to achieve this is layed out below.

First step is to define the customer VRFS and i apply the following config on each of the PE routers.

ip vrf CUSTA
rd 1:1
route-target export 1:1
route-target import 1:1
!
ip vrf CUSTB
rd 2:2
route-target export 2:2
route-target import 2:2
!
ip vrf CUSTC
rd 3:3
route-target export 3:3
route-target import 3:3


Second step is to apply the vrf config to the customer facing interfaces on the PE routers. At each step i verify my config with the show ip vrf command.


PE1(config-if)#DO SIIB
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 13.0.0.1 YES NVRAM up up
Serial2/0 10.0.0.2 YES manual up up
Serial2/1 10.0.0.6 YES NVRAM up up
Serial2/2 10.0.0.10 YES NVRAM up up


PE1(CONFIG)#int s2/0
PE1(config-if)#ip vrf forwarding CUSTA
% Interface Serial2/0 IP address 10.0.0.2 removed due to enabling VRF CUSTA
PE1(config-if)#ip address 10.0.0.2 255.255.255.252
PE1(config)#int s2/1
PE1(config-if)#ip vrf forwarding CUSTB
% Interface Serial2/1 IP address 10.0.0.6 removed due to enabling VRF CUSTB
PE1(config-if)#ip address 10.0.0.6 255.255.255.252
PE1(config-if)#int s2/2
PE1(config-if)#ip vrf forwarding CUSTC
% Interface Serial2/2 IP address 10.0.0.10 removed due to enabling VRF CUSTC
PE1(config-if)#ip address 10.0.0.10 255.255.255.252


PE1#s ip vrf
Name Default RD Interfaces
CUSTA 1:1 Se2/0
CUSTB 2:2 Se2/1
CUSTC 3:3 Se2/2


PE2#siib
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 13.0.0.2 YES NVRAM up up
Serial2/0 12.0.0.2 YES NVRAM up up
Serial2/1 12.0.0.6 YES NVRAM up up


PE2(config)#int s2/0
PE2(config-if)#ip vrf for
PE2(config-if)#ip vrf forwarding CUSTA
% Interface Serial2/0 IP address 12.0.0.2 removed due to enabling VRF CUSTA
PE2(config-if)#ip address 12.0.0.2 255.255.255.252
PE2(config-if)#int s2/1
PE2(config-if)#ip vrf forwarding CUSTC
% Interface Serial2/1 IP address 12.0.0.6 removed due to enabling VRF CUSTC
PE2(config-if)#ip address 12.0.0.6 255.255.255.252

PE2(config-if)#do s ip vrf
Name Default RD Interfaces
CUSTA 1:1 Se2/0
CUSTB 2:2
CUSTC 3:3 Se2/1


PE3#siib
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 13.0.0.3 YES manual up up
Serial2/0 11.0.0.2 YES NVRAM up up
Serial2/1 11.0.0.6 YES NVRAM up up

PE3(config-vrf)#int s2/0
PE3(config-if)#ip vrf forwarding CUSTB
% Interface Serial2/0 IP address 11.0.0.2 removed due to enabling VRF CUSTB
PE3(config-if)#ip address 11.0.0.2 255.255.255.252
PE3(config-if)#int s2/1
PE3(config-if)#ip vrf forwarding CUSTC
% Interface Serial2/1 IP address 11.0.0.6 removed due to enabling VRF CUSTC
PE3(config-if)#ip address 11.0.0.6 255.255.255.252

PE3(config-if)#DO S IP VRF
Name Default RD Interfaces
CUSTA 1:1
CUSTB 2:2 Se2/0
CUSTC 3:3 Se2/1


The 3rd step is to configure the PE to CE BGP adjacencies. N.B. The CE to PE adjacencies are standard BGP config and i do not detail here. To keep the output down i have detailed the config required on PE1 only, as the config on the other PE routers is very similar.

router bgp 1000
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 10.0.0.1 remote-as 1
neighbor 10.0.0.5 remote-as 2
neighbor 10.0.0.9 remote-as 3

address-family ipv4 vrf CUSTC
neighbor 10.0.0.9 remote-as 3
neighbor 10.0.0.9 activate

address-family ipv4 vrf CUSTB
neighbor 10.0.0.5 remote-as 2
neighbor 10.0.0.5 activate

address-family ipv4 vrf CUSTA
neighbor 10.0.0.1 remote-as 1
neighbor 10.0.0.1 activate


The 4th step is to configure the PE to PE adjacencies. Again i have detailed PE1 config only here

PE1
router bgp 1000
neighbor 13.0.0.2 remote-as 1000
neighbor 13.0.0.3 remote-as 1000
!
address-family vpnv4
neighbor 13.0.0.2 activate
neighbor 13.0.0.2 send-community extended
neighbor 13.0.0.3 activate
neighbor 13.0.0.3 send-community extended
exit-address-family


The 5th step is to enable mpls in the provide network.
On PE1, PE2 and PE3

conf t
mpls ip
int fa0/0
mpls ip



For verification

PE1#s ip bgp vpnv4 all sum | beg Neigh
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.0.1 4 1 46 49 24 0 0 00:17:01 2
10.0.0.5 4 2 6 6 24 0 0 00:01:33 2
10.0.0.9 4 3 5 4 19 0 0 00:00:43 2
101.101.101.101 4 1000 30 32 24 0 0 00:17:31 2
102.102.102.102 4 1000 31 34 24 0 0 00:17:19 2

PE1#s ip bgp vpnv4 *
BGP table version is 30, local router ID is 100.100.100.100
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf CUSTA)
*> 1.1.1.0/24 10.0.0.1 0 0 1 ?
r> 10.0.0.0/30 10.0.0.1 0 0 1 ?
*>i12.0.0.0/30 101.101.101.101 0 100 0 7 ?
*>i102.102.102.0/24 101.101.101.101 0 100 0 7 ?
Route Distinguisher: 2:2 (default for vrf CUSTB)
*> 2.2.2.0/24 10.0.0.5 0 0 2 ?
*>i4.4.4.0/24 102.102.102.102 0 100 0 4 ?
r> 10.0.0.4/30 10.0.0.5 0 0 2 ?
*>i11.0.0.0/30 102.102.102.102 0 100 0 4 ?
Route Distinguisher: 3:3 (default for vrf CUSTC)
*> 3.3.3.0/24 10.0.0.9 0 0 3 ?
*>i5.5.5.0/24 102.102.102.102 0 100 0 5 ?
*>i6.6.6.0/24 101.101.101.101 0 100 0 6 ?
r> 10.0.0.8/30 10.0.0.9 0 0 3 ?
*>i11.0.0.4/30 102.102.102.102 0 100 0 5 ?
*>i12.0.0.4/30 101.101.101.101 0 100 0 6 ?



Finally i examine the routing tables on peer customer sites to check routes have been shared. Here i dump the Customer A routing tables

CUSTA1>s ip route

1.0.0.0/24 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, Loopback0
7.0.0.0/24 is subnetted, 1 subnets
B 7.7.7.0 [20/0] via 10.0.0.2, 00:30:23
10.0.0.0/30 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, Serial2/0
12.0.0.0/30 is subnetted, 1 subnets
B 12.0.0.0 [20/0] via 10.0.0.2, 00:37:16

CUSTA2#sir
1.0.0.0/24 is subnetted, 1 subnets
B 1.1.1.0 [20/0] via 12.0.0.2, 00:37:54
7.0.0.0/24 is subnetted, 1 subnets
C 7.7.7.0 is directly connected, Loopback0
10.0.0.0/30 is subnetted, 1 subnets
B 10.0.0.0 [20/0] via 12.0.0.2, 00:37:54
12.0.0.0/30 is subnetted, 1 subnets
C 12.0.0.0 is directly connected, Serial2/0


I ping across the cloud

For Customer C
CUSTC3>ping 3.3.3.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 544/1161/1684 ms
CUSTC3>ping 6.6.6.6

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 624/1000/1700 ms

For Customer B
CUSTB2>p 2.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 692/1121/1388 ms

CUSTA1#ping 7.7.7.7

For customer A
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:
!!!!!
Success rate is 60 percent (5/5), round-trip min/avg/max = 792/1004/1228 ms

Thursday, July 16, 2009

QOS - MQC shape average vs shape peak

The operation of shape peak is exactly the same as shape average:it calculates the default bc in the same manner, except, that each interval it gets to fill up the Be bucket as well. With the shape average command the excess burst is only sent if the bc bucket is full i.e. after periods of inactivity.

If a network has additional bandwidth available (over the provisioned CIR) and the application can tolerate occasional packet loss, the extra bandwidth can be exploited through the use of peak rate shaping. There may be occasional packet drops when network congestion occurs.

If the traffic being sent to the network must strictly conform to the configured network provisioned CIR, then use average traffic shaping.

If you had: shape peak 8000

We get a default tc of 1/8th of a second which gives us a bc of 1000 and a be of the same value. So the sending rate equals bc + be per tc or 16000. The rate equation is as follows

peak rate = CIR * (1 + Be/Bc)
peak rate = 8000 * (1 + 10/10) = 16000


In summary

shape average 8000 equates to a tcp traffic flow of 8000 bps.
shape peak 8000 equates to tcp traffic flow of 16000 bps.

R1
policy-map RICH
class class-default
shape average 8000 1000 1000

int fa0/0
policy-map output RICH


show policy-map int fa0/0
Service-policy output: RICH

Class-map: class-default (match-any)
86 packets, 7295 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
8000/8000 250 1000 1000 125 125

Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 86 7295 0 0 no

R1
policy-map RICH
class class-default
shape peak 8000 1000 1000

int fa0/0
policy-map output RICH



show policy-map int fa0/0
Service-policy output: RICH

Class-map: class-default (match-any)
159 packets, 13622 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
16000/8000 250 1000 1000 125 250

Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 4 298 0 0 no

Monday, July 13, 2009

QOS - MQC Policer


The lab requirement here is to meter incoming HTTP traffic. When the traffic rate is less than 256kbps packets should be marked with precedence 4, and when the traffic exceeds 256kbps the traffic should be marked with precedence 0. The normal burst duration is 100 ms amd and an excess burst of 100ms should be allowed. Traffic exceeding these parameters should be dropped.

With the policing config the traffic rate is configured as bps wherease the burst size is configured in bytes. For a burst duration of 100ms then the burst size is calculated as follows: 256000 / 10 / 8 = 3200

I apply the configuration on R1 as follows

R1
class-map HTTP
match protocol http

policy-map POLICE
class HTTP
police 256000 bc 3200 be 3200 conform-action set-prec-transmit 4 exceed-action set-prec-transmit 0 violate-action drop

int fa0/0
service-policy input POLICE



Verification


Router_1#show policy-map int fa0/0
FastEthernet0/0

Service-policy input: POLICE

Class-map: HTTP (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol http
police:
cir 256000 bps, bc 3200 bytes, be 3200 bytes
conformed 0 packets, 0 bytes; actions:
set-prec-transmit 4
exceeded 0 packets, 0 bytes; actions:
set-prec-transmit 0
violated 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps, violate 0 bps

Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any


A further addendum to this post is the ability to police individual traffic flows inside an pre-existing policer!

For example, R1 is on a LAN segment connected to R6 and R4. A further requirement might be that traffic flows from these routers should only be able to consume half of the available bandwidth i.e. 128kbps each. This can be achieved by nesting policers as follows.

ip access-list extended R4
permit ip host 155.1.146.4 any
ip access-list extended R6
permit ip host 155.1.146.6 any

class-map R4
match access-group name R4
class-map R6
match access-group name R6

policy-map POLICE2
class R4
POLICE 128000 1600 1600 conform-action set-prec-transmit 4 exceed-action set-prec-transmit 0 violate-action drop
class R6
POLICE 128000 1600 1600 conform-action set-prec-transmit 4 exceed-action set-prec-transmit 0 violate-action drop

policy-map POLICE
class HTTP
police 256000 bc 3200 be 3200 conform-action transmit exceed-action set-prec-transmit 0 violate-action drop
service-policy POLICE2





Verification

Router_1#s policy-map int fa0/0
FastEthernet0/0

Service-policy input: POLICE

Class-map: HTTP (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol http
police:
cir 256000 bps, bc 3200 bytes, be 3200 bytes
conformed 0 packets, 0 bytes; actions:
set-prec-transmit 4
transmit
exceeded 0 packets, 0 bytes; actions:
set-prec-transmit 0
violated 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps, violate 0 bps

Service-policy : POLICE2

Class-map: R4 (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group name R4
police:
cir 128000 bps, bc 1600 bytes, be 1600 bytes
conformed 0 packets, 0 bytes; actions:
set-prec-transmit 4
exceeded 0 packets, 0 bytes; actions:
set-prec-transmit 0
violated 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps, violate 0 bps

Class-map: R6 (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group name R6
police:
cir 128000 bps, bc 1600 bytes, be 1600 bytes
conformed 0 packets, 0 bytes; actions:
set-prec-transmit 4
exceeded 0 packets, 0 bytes; actions:
set-prec-transmit 0
violated 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps, violate 0 bps

Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any

Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any

Friday, July 10, 2009

QOS - FRTS PVC Priority Queue

Within frame relay it is possible to prioritise one vcs traffic over and above another.
A priority queue for PVCS!!


map-class frame-relay DLCI_503
frame-relay interface-queue priority high
map-class frame-relay DLCI_502
frame-relay interface-queue priority medium
map-class frame-relay DEFAULT
frame-relay interface-queue priority low

int s2/0
frame-relay interface-queue priority
frame-relay class DEFAULT
frame-relay interface-dlci 503
class DLCI_503
frame-relay interface-dlci 502
class DLCI_502

Thursday, July 9, 2009

QOS - FRTS custom queue

Here i define a Frame Relay custom queue on dlci 502 on R5.

www traffic is defined to use 50% of the bandwidth, telnet traffic 30% and everything else is defined to use the default queue with a 20% share of the bandwitdh.

Additionally the queue size is set to 40 packets for the queues in use i.e. 1-3.

queue-list 2 protocol ip 1 tcp www
queue-list 2 protocol ip 2 tcp telnet
queue-list 2 default 3
queue-list 2 queue 1 byte-count 500 limit 40
queue-list 2 queue 2 byte-count 300 limit 40
queue-list 2 queue 3 byte-count 200 limit 40


map-class frame-relay DLCI_502
frame-relay cir 128000
frame-relay bc 1280
frame-relay be 0
frame-relay custom-queue-list 2


For verification i use the show traffic-shape queue command and the show frame pvc 502 command.

Router_5#show traffic-shape queue
Traffic queued in shaping queue on Serial2/0 dlci 501
Queueing strategy: fcfs
Traffic queued in shaping queue on Serial2/0 dlci 504
Queueing strategy: fcfs
Traffic queued in shaping queue on Serial2/0 dlci 503
Queueing strategy: fcfs
Traffic queued in shaping queue on Serial2/0 dlci 502
Queueing strategy: custom-queue list 2


Router_5#show frame pvc 502

PVC Statistics for interface Serial2/0 (Frame Relay DTE)

DLCI = 502, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial2/0

input pkts 48 output pkts 67 in bytes 1548
out bytes 2227 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 0 out bcast bytes 0
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:19:07, last time pvc status changed 00:17:28
cir 128000 bc 1280 be 0 byte limit 160 interval 10
mincir 64000 byte increment 160 Adaptive Shaping none
pkts 79 bytes 2371 pkts delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
Queueing strategy: custom-list 2

List Queue Args
2 3 default

List Queue Args
2 1 protocol ip tcp port www
2 2 protocol ip tcp port telnet
2 1 byte-count 500 limit 40
2 2 byte-count 300 limit 40
2 3 byte-count 200 limit 40
Output queues: (queue #: size/max/drops/dequeued)
0: 0/20/0/0 1: 0/40/0/0 2: 0/40/0/0 3: 0/40/0/0 4: 0/20/0/0
5: 0/20/0/0 6: 0/20/0/0 7: 0/20/0/0 8: 0/20/0/0 9: 0/20/0/0
10: 0/20/0/0 11: 0/20/0/0 12: 0/20/0/0 13: 0/20/0/0 14: 0/20/0/0
15: 0/20/0/0 16: 0/20/0/0

Wednesday, July 8, 2009

QOS - FRTS priority queue

Priority queueing can also be applied on a per VC basis. Configuration of the priority queues and flows is done in the standard manner.

access-list 150 permit tcp any any eq www
access-list 151 permit udp any any eq tftp
access-list 152 permit tcp any any eq cmd

priority-list 1 protocol ip high list 151
priority-list 1 protocol ip medium list 150
priority-list 1 protocol ip normal list 152
priority-list 1 default low


To apply the priority queueing this is NOT done under the interface. Without thinking i tried this and received the following error.

Router_5(config)#int s2/0
Router_5(config-if)#priority-group 1
Cannot change interface queuing when Frame-Relay traffic-shapi
ng is configured

For per VC priority queueing the priority queue must be applied to the map class used by the VC.

map-class DLCI_503
frame-relay priority-group 1


This can then be verified using the show traffic-shape queue command and the show frame pvc 503 commands.



Router_5#show traffic-shape queue
Traffic queued in shaping queue on Serial2/0 dlci 501
Queueing strategy: fcfs
Traffic queued in shaping queue on Serial2/0 dlci 504
Queueing strategy: fcfs
Traffic queued in shaping queue on Serial2/0 dlci 503
Queueing strategy: priority-group 1

Traffic queued in shaping queue on Serial2/0 dlci 502
Queueing strategy: fcfs



Router_5#show frame-relay pvc 503

PVC Statistics for interface Serial2/0 (Frame Relay DTE)

DLCI = 503, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial2/

input pkts 71 output pkts 68 in bytes 6372
out bytes 6608 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 0 out bcast bytes 0
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:30:32, last time pvc status changed 00:28:53
cir 256000 bc 2560 be 0 byte limit 320 interval 10
mincir 128000 byte increment 320 Adaptive Shaping none
pkts 43 bytes 3952 pkts delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
Queueing strategy: priority-list 1

List Queue Args
1 low default

List Queue Args
1 high protocol ip list 151
1 medium protocol ip list 150
1 normal protocol ip list 152
Output queue: high 0/20/0, medium 0/40/0, normal 0/60/0, low 0/80/0

Tuesday, July 7, 2009

QOS - FRTS fair queue

By default the queue will be FIFO or fcfs (first come first served). This can be seen by executing the show traffic-shape queue command.

Router_3#show traffic-shape queue
Traffic queued in shaping queue on Serial2/0 dlci 305
Queueing strategy: fcfs


Effectively this queueing mechanism is a 'per interface' queue. Per-VC WFQ can be enabled using the frame-relay fair-queue command.

map-class frame-relay DLCI_305
frame-relay cir 384000
frame-relay bc 3840
frame-relay be 0
frame-relay mincir 256000
frame-relay adaptive-shaping becn
frame-relay adaptive-shaping interface-congestion
frame-relay fair-queue 16 32 0 512

The change can be verified using the show traffic-shape queue command

Router_3#show traffic-shape queue
Traffic queued in shaping queue on Serial2/0 dlci 305
Queueing strategy: weighted fair
Queueing Stats: 0/512/16/0 (size/max total/threshold/drops)
Conversations 0/0/32 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 256 kilobits/sec

QOS - FRTS adaptive shaping

R3 ------- R5

The lab requirement is to allow router 3 to 'oversubcribe' the link TO router 5 at 384k. The provider actually guarantees 256k.
In this situation the cir is set to the 'oversubcribed' rate and the mincir is set to the providers guaranteed rate.

Router 3
map-class frame-relay DLCI_305
frame-relay cir 384000
frame-relay mincir 256000
frame-relay bc 3840
frame-relay be 0
frame-relay adaptive-shaping becn
frame-relay adaptive-shaping interface-congestion


frame-relay adaptive-shaping becn allows the router to adjust its sending rate down to minCIR when BECNs are received from the provider cloud.

frame-relay fecn-adapt when set on the receiving router enables it to generate BECNs when a FECN is received from the provider cloud.

Router 5
map-class frame-relay DLCI_503
frame-relay fecn-adapt


Also in this scenario, the feature frame-relay adaptive-shaping interface-congestion enables the sending router to slow down transmission when the interface queue reaches its threshold.

QOS - FRTS

FRTS or Frame Relay Traffic shaping was intended as a replacement to GTS. It allows a more granular approach to QOS with shaping per VC.

Once traffic shaping is enabled on a physical interafce a CIR of 56kbps and a tc of 125ms applies. Configuration parameters are defined using the map-class frame-relay command and are then applied to the interface using frame-relay interface-dlci xxx.

In this example R3 and R5 and connected via a frame-relay circuit. The CIR is 256k, with bursts up to 384k permitted. R5 must not overwhelm R3 i.e. it must conform to the CIR of R3.

Router 3

map-class frame-relay DLCI_305
frame-relay cir 256000
frame-relay bc 2560
frame-relay be 1280

interface Serial2/0
frame-relay traffic-shaping
frame-relay interface-dlci 305
class DLCI_305


Router 5

map-class frame-relay DLCI_503
frame-relay cir 256000
frame-relay bc 2560
frame-relay be 0

interface Serial2/0
frame-relay traffic-shaping
frame-relay interface-dlci 503
class DLCI_503


Once applied the configuration can be verified with the show traffic-shape command


Router_3#show traffic-shape

Interface Se2/0
Access Target Byte Sustain Excess Interval Increment Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes) Active
305 256000 480 2560 1280 10 320 -



FRTS employs a three tiered approach to queueing. The per vc queues, then the main interface queue, followed by the physical interface transmit ring. These can all be adjusted as follows

per vc FIFO: frame-relay holdq
interface FIFO: hold-queue
transmit-ring: tx-ring-limit

Monday, July 6, 2009

QOS - CAR

CAR or Committed Access Rate

The lab topology and requirement in the post is the same as with the QOS - GTS post.
This time it is achieved using CAR.

TOPOLOGY: R2 ------ R3 ------ R1 ------ R4

The LAB requirement is to use CAR to limit the traffic flow to R4.
Packets destined to R4 loopback (150.1.4.4) is allowed 16k and packets destined to R4 fa0/0 (155.1.148.4) is allowed only 8K.



Router_1
int fa0/0
rate-limit access-group 100 8000 1000 2000 conform-action continue exceed-action drop
rate-limit access-group 101 16000 1000 2000 conform-action continue exceed-action drop


I execute pings from R3 and R2

Router_3#ping 155.1.148.4 size 4000 repeat 1000 timeout 1
Router_2#ping 155.1.148.4 size 4000 repeat 1000 timeout 1


I now verify the rate limiting on R1

Router 1
show int fa0/0 rate-limit

FastEthernet0/0
Output
matches: access-group 100
params: 8000 bps, 1500 limit, 2000 extended limit
conformed 59 packets, 65866 bytes; action: transmit
exceeded 136 packets, 199464 bytes; action: drop
last packet: 20ms ago, current burst: 1810 bytes
last cleared 00:01:04 ago, conformed 8000 bps, exceeded 24000 bps
matches: access-group 101
params: 16000 bps, 1500 limit, 2000 extended limit
conformed 95 packets, 130030 bytes; action: transmit
exceeded 100 packets, 135300 bytes; action: drop
last packet: 36ms ago, current burst: 1676 bytes
last cleared 00:01:04 ago, conformed 16000 bps, exceeded 16000 bps

QOS - GTS

TOPOLOGY: R2 ------ R3 ------ R1 ------ R4

GTS or generic traffic shaping. This predates MQC.
The LAB requirement here is to use GTS to limit the traffic flow to R4. Packets destined to R4 loopback (150.1.4.4) is allowed 16k and packets destined to R4 fa0/0 (155.1.148.4) is allowed only 8K.

I create two acls matching the required traffic flows on R1

access-list 100 permit ip any 155.1.148.0 0.0.0.255
access-list 101 permit ip any 150.1.4.0 0.0.0.255



I apply 2 traffic-shape commands to the fa0/0 interface on R1.

interface FastEthernet0/0
ip address 155.1.148.1 255.255.255.0
duplex half
traffic-shape group 100 8000 1000 2000 10
traffic-shape group 101 16000 1000 2000 10


I execute 2 pings: One from R3 to fa0/0 on R4, and one from R2 to lo0 on R4.

Router_3#ping 155.1.148.4 size 2000 repeat 1000 timeout 1
Router_2#ping 150.1.4.4 size 2000 repeat 1000 timeout 1


I then examine the traffic shaping with the following three commands on R1.

show traffic-shape
show traffic-shape statistics
show traffic-shape queue fa0/0



Router_1#show traffic-shape

Interface Fa0/0
Access Target Byte Sustain Excess Interval Increment Adapt
VC List Rate Limit bits/int bits/int (ms) (bytes) Active
- 100 8000 375 1000 2000 125 125 -
- 101 16000 375 1000 2000 62 125 -


Router_1#show traffic-shape queue fa0/0
Traffic queued in shaping queue on FastEthernet0/0
Traffic shape group: 100
Queueing strategy: weighted fair
Queueing Stats: 10/10/64/46 (size/max total/threshold/drops)
Conversations 1/1/16 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 8 kilobits/sec

(depth/weight/total drops/no-buffer drops/interleaves) 10/4048/46/0/0
Conversation 1, linktype: ip, length: 1514
source: 155.1.13.3, destination: 155.1.148.4, id: 0x002B, ttl: 254, prot: 1


Traffic shape group: 101
Queueing strategy: weighted fair
Queueing Stats: 9/10/64/61 (size/max total/threshold/drops)
Conversations 1/1/16 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 16 kilobits/sec

(depth/weight/total drops/no-buffer drops/interleaves) 9/4048/61/0/0
Conversation 5, linktype: ip, length: 1514
source: 155.1.23.2, destination: 150.1.4.4, id: 0x004E, ttl: 253, prot: 1


Lastly the show traffic-shape statistics command indicates the ping to R4 loopback is transmitting twice the amount of data in comparison to the ping to R4 fa0/0 interface.

Router_1#show traffic-shape stat
Acc. Queue Packets Bytes Packets Bytes Shaping
I/F List Depth Delayed Delayed Active
Fa0/0 100 10 98 130592 92 128508 yes
Fa0/0 101 10 277 329510 254 309188 yes



GTS can also be applied to the interface as a whole with the traffic-shape rate command. For example.

int fa0/0
traffic-shape rate 128000 8000 8000 100