Frame Relay Switching and Policing Lab


OVERVIEW

A large part of Frame Relay documentation is focused on the configuration of end devices more than the FR cloud, which can make practicing Frame Relay quality of service very confusing and frustrating without an organized approach, this begins by setting a FR lab for testing and deployment; this is the purpose of the current post .

R2 and R1, customer devices, connected to FRS the frame Relay switch through back-to-back serial cables, a traffic generator is connected to R2 will generate traffic, through the FR cloud at different rates, destined to the receiver station connected to R1 (figure1).

To understand the role and the impact of QoS concepts like shaping, policing, congestion management and related parameters, we will focus on each one of them separately.

Note: The mentioned topology can be deployed on dynamips and GNS3 with the exception that clock rate has no effect, and clocking is fixed to 2mbps for serial interface, so to simulate connection mismatch you can use multiple serial connections (n*2mbps) as spokes for example and aggregate them to one serial connection (2mbps).

Figure1: FR Lab topology

The lab is organized as follow:

1) Frame Relay connectivity

    1-a) FR End-device

    1-b) FR switch

2) Shaping queue and congestion on FR end device

    2-a) Traffic rate:

    2-b) Shaping queue size:

    2-c) Shaping parameters:

3) Shaping queue and congestion on FR Switch

4) FR Congestion management, FECN/BECN

5) FR Congestion management, Discard Eligible bit

CONCLUSION

 

1) Frame Relay Connectivity

1-a) FR End-devices

Both R1 and R2 are connected to the Frame Relay cloud using point-to-point sub-interfaces, where local dlci’s are assigned and inverse-arp doesn’t mind because there is only one PVC in the other side thereby it is disabled, as depicted in the mindmap (figure 2).

Figure2:Inverse-ARP configuration

R1 (receiver):

interface Serial0/0
no ip address
encapsulation frame-relay

load-interval 30

no fair-queue

frame-relay traffic-shaping

no frame-relay inverse-arp

frame-relay lmi-type ansi

!

interface Serial0/0.201 point-to-point

ip address 172.16.0.201 255.255.0.0

frame-relay interface-dlci 201

load-interval 30

R2 (sender):

interface Serial0/0
no ip address
encapsulation frame-relay

load-interval 30

no fair-queue

frame-relay traffic-shaping

no frame-relay inverse-arp

frame-relay lmi-type ansi

!

interface Serial0/0.102 point-to-point

ip address 172.16.0.102 255.255.0.0

frame-relay interface-dlci 102

load-interval 30

 

1-b) FR switch

As follow the commands used to establish connectivity in the FR switch

FRS(config)#frame-relay switching Enable frame relay switching globally on a router.
FRS(config)#connect <name> <interface> <dlci> <interface> <dlci> – Set connections between FR PVCs (similar to “frame-relay route” command).- With FR switching, FR traffic shaping is not applied to routed PVCs (using “frame-relay route” command).
FRS(config-if)#frame-relay interface-dlci <dlci> switched Needed to directly associate FR map to a specific switched PVC
clockrate <bps> Because it is a lab environment and routers are connected through back-to-back serial cables, connected interfaces on FR switch are required be set as DCE to supply clocking on the line to customer DTE devices

Here is the configuration of the FR switch

FRS:

interface Serial1/0encapsulation frame-relayclockrate 64000

frame-relay traffic-shaping

frame-relay interface-dlci 201 switched

frame-relay lmi-type ansi

frame-relay intf-type dce

!

interface Serial1/1

encapsulation frame-relay

clockrate 128000

frame-relay interface-dlci 102 switched

frame-relay lmi-type ansi

frame-relay intf-type dce

!

frame-relay switching

connect 102_201 Serial1/1 102 Serial1/0 201

 

1) Shaping queue and congestion on FR end device

Before moving on here a short explanation of the main commands used with FR traffic shaping and policing:

PVC-basis 

Interface-basis 

 
interface Serial <X/X>frame-relay [traffic-shaping | policing] Enable traffic shaping or policing on the physical interface
frame-relay interface-dlci <dlci> switchedclass <mapclassname> interface Serial <X/X>frame-relay class <mapclassname> Assign the map-class directly to the PVC
map-class frame-relay <mapclassname> Define the map-class
frame-relay cir <bps>frame-relay bc <bits>frame-relay be <bits> Define shaping parameters
frame-relay holdq <max_size> Hold-queue <max_size> [out|in] Set the size of the shaping queue, 40 by default. The router start filling it when the interface is experiencing congestion, the bigger, the more delay; the lower, the more congestion and deleted packets.
frame-relay congestion threshold ecn <%> frame-relay congestion-managementthreshold ecn [bc|be] <%> Set the congestion management threshold in the shaping queue, if reached the router will mark returning traffic to the sender with BECN and if no returning traffic, the router send FECN packets to the receiver that in turns will generate Q.922 packets towards the sender that will be marked with FECN.
frame-relay congestion threshold de <%> frame-relay congestion-managementthreshold de <%> Set the congestion management threshold in the shaping queue, if reached the router will start deleting packets marked with “DE”

With frame relay shaping enabled and map class assigned to a PVC, shaping queue congestion, packet dropping and delay depend on many factors like the traffic rate , shaping queue size (holdq) and shaping parameters

1-a) Traffic rate:

To observe the effect of traffic rate on shaping queue congestion on R2, we will fix the shaping parameters on R2 (sender) to the maximum of the interface clock rate 128 kbps with no excess burst to allow the shaping queue to function at its full capacity.

Parameters 

FR End-device, sender 

Shaping (outbound) 

CIR 

128kbps 

Bc=CIR*Tc

16000 

Tc 

125ms 

Be 

  • Traffic is generated at the rate of 64kbps —> the shaping queue is not congested:
R2#sh int s0/0 | i output rate

30 second output rate 64000 bits/sec, 5 packets/sec
R2#sh frame pvc 102

 

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

 

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.102

 

input pkts 1178 output pkts 1368 in bytes 5164

out bytes 2048886 dropped pkts 0 in FECN pkts 0

in BECN pkts 1177 out FECN pkts 0 out BECN pkts 0

in DE pkts 0 out DE pkts 0

out bcast pkts 5 out bcast bytes 1660

5 minute input rate 0 bits/sec, 5 packets/sec

5 minute output rate 57000 bits/sec, 5 packets/sec

pvc create time 00:57:16, last time pvc status changed 00:55:46


cir 128000
bc 16000
be 0 byte limit 2000 interval 125

mincir 64000 byte increment 2000 Adaptive Shaping none

pkts 1368 bytes 2048886 pkts delayed 0 bytes delayed 0


shaping inactive

traffic shaping drops 0

Queueing strategy: fifo


Output queue 0/40, 0 drop, 0 dequeued

R2#

  • Traffic is generated at the rate of 128kbps —> shaping queue is congested and packets are queued, the queue can still support the traffic rate
R2#sh int s0/0 | i output rate

30 second output rate 124000 bits/sec, 10 packets/sec
R2#sh frame pvc 102

 

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

 

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.102

 

input pkts 398 output pkts 814 in bytes 1846

out bytes 1219010 dropped pkts 0 in FECN pkts 0

in BECN pkts 398 out FECN pkts 0 out BECN pkts 0

in DE pkts 0 out DE pkts 0

out bcast pkts 1 out bcast bytes 332

5 minute input rate 0 bits/sec, 5 packets/sec

5 minute output rate 40000 bits/sec, 10 packets/sec

pvc create time 01:11:26, last time pvc status changed 01:09:57


cir 128000
bc 16000
be 0 byte limit 2000 interval 125

mincir 64000 byte increment 2000 Adaptive Shaping none

pkts 798 bytes 1194978 pkts delayed 798 bytes delayed 1194978


shaping active

traffic shaping drops 0

Queueing strategy: fifo


Output queue 20/40, 0 drop, 798 dequeued

R2#

  • Traffic is generated at the rate of 180kbps higher that the interface clock rate —> the shaping queue become congested and can no more support the traffic rate, therefore begin dropping packets:
R2#sh frame pvc 102
 PVC Statistics for interface Serial0/0 (Frame Relay DTE)

 

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.102

 

input pkts 2940 output pkts 7786 in bytes 12080

out bytes 11673976 dropped pkts 1920 in FECN pkts 0

in BECN pkts 2939 out FECN pkts 0 out BECN pkts 0

in DE pkts 0 out DE pkts 0

out bcast pkts 9 out bcast bytes 2988

5 minute input rate 0 bits/sec, 5 packets/sec


5 minute output rate 180000 bits/sec, 15 packets/sec

pvc create time 01:19:34, last time pvc status changed 01:18:04


cir 128000
bc 16000
be 0 byte limit 2000 interval 125

mincir 64000 byte increment 2000 Adaptive Shaping none

pkts 5823 bytes 8725550 pkts delayed 5820 bytes delayed 8721044


shaping active

traffic shaping drops 0

Queueing strategy: fifo


Output queue 40/40, 1927 drop, 5820 dequeued

R2#

 

1-b) Shaping queue size:

Now let’s try to increase the shaping queue size (holdq) up to 100 —> this can resolve the problem of dropping but packet will take more and more time to be dequeued and the delay will blow up and this is inacceptable for delay sensitive traffic.

R2:

R2#sh frame pvc 102
 PVC Statistics for interface Serial0/0 (Frame Relay DTE)

 

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.102

 

input pkts 5200 output pkts 14247 in bytes 21319

out bytes 21362590 dropped pkts 3801 in FECN pkts 0

in BECN pkts 5199 out FECN pkts 0 out BECN pkts 0

in DE pkts 0 out DE pkts 0

out bcast pkts 16 out bcast bytes 5312

5 minute input rate 0 bits/sec, 5 packets/sec

5 minute output rate 184000 bits/sec, 15 packets/sec

pvc create time 01:26:38, last time pvc status changed 01:25:08


cir 128000
bc 16000
be 0 byte limit 2000 interval 125

mincir 64000 byte increment 2000 Adaptive Shaping none

pkts 10345 bytes 15501786 pkts delayed 10342 bytes delayed 15497280


shaping active

traffic shaping drops 0

Queueing strategy: fifo


Output queue 55/100, 0 drop, 123 dequeued

R2#

 

1-c) Shaping parameters:

To observe the effect of FR shaping parameters on shaping queue congestion, we will fix the generated traffic rate to 64 kbps and the shaping queue size on R2 to the default value of 40.

  • These are the shaping parameters applied to PVC 102 on R2:
Parameters 

FR End-device, sender 

Shaping (outbound) 

CIR 

128kbps

Bc=CIR*Tc

8000

Tc 

125ms 

Be 

With traffic rate of 64 kbps and CIR set to the clock rate capacity, there is no congestion:

R2:

R2(config-map-class)#do sh int s0/0 | i output rate

30 second output rate 64000 bits/sec, 5 packets/sec
R2(config-map-class)#do sh frame pvc 102

 

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

 

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.102

 

input pkts 2 output pkts 216 in bytes 509

out bytes 321984 dropped pkts 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 15000 bits/sec, 5 packets/sec

pvc create time 03:16:46, last time pvc status changed 03:15:16


cir 128000
bc 16000
be 0 byte limit 2000 interval 125

mincir 64000 byte increment 2000 Adaptive Shaping none

pkts 216 bytes 321984 pkts delayed 0 bytes delayed 0


shaping inactive

traffic shaping drops 0

Queueing strategy: fifo


Output queue 0/40, 0 drop, 0 dequeued

R2(config-map-class)#

  • Now with a CIR equal to the traffic rate 64kbps, the shaping queue is experiencing congestion but still no dropping:
Parameters 

FR End-device, sender 

Shaping (outbound) 

CIR 

64kbps 

Bc=CIR*Tc 

8000 

Tc 

125ms 

Be 

R2:

R2(config-map-class)#do sh int s0/0 | i output rate

30 second output rate 64000 bits/sec, 5 packets/sec
R2(config-map-class)#do sh frame pvc 102

 

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

 

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.102

 

input pkts 2 output pkts 367 in bytes 658

out bytes 550064 dropped pkts 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 1 out bcast bytes 332

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 21000 bits/sec, 5 packets/sec

pvc create time 03:26:19, last time pvc status changed 03:24:50


cir 64000
bc 8000
be 0 byte limit 1000 interval 125

mincir 32000 byte increment 1000 Adaptive Shaping none

pkts 358 bytes 536546 pkts delayed 358 bytes delayed 536546


shaping active

traffic shaping drops 0

Queueing strategy: fifo


Output queue 13/40, 0 drop, 358 dequeued

R2(config-map-class)#

  • Now with a shaping rate capacity less that the traffic rate the shaping is queue is congested to the maximum and start dropping packets that can’t handle:
Parameters 

FR End-device, sender

Shaping (outbound) 

CIR 

32kbps 

Bc=CIR*Tc 

4000 

Tc 

125ms 

Be 

R2:

R2(config-map-class)#do sh frame pvc 102
 PVC Statistics for interface Serial0/0 (Frame Relay DTE)

 

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.102

 

input pkts 26 output pkts 3893 in bytes 6340

out bytes 5818010 dropped pkts 203 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 12 out bcast bytes 3984

5 minute input rate 0 bits/sec, 0 packets/sec


5 minute output rate 65000 bits/sec, 5 packets/sec

pvc create time 03:37:08, last time pvc status changed 03:35:39


cir 32000
bc 4000 be 0 byte limit 500 interval 125

mincir 16000 byte increment 500 Adaptive Shaping none

pkts 3652 bytes 5457198 pkts delayed 3652 bytes delayed 5457198


shaping active

traffic shaping drops 0

Queueing strategy: fifo


Output queue 40/40, 205 drop, 3652 dequeued

R2(config-map-class)#

 

2) Shaping queue and congestion on FR Switch

Exactly the same concepts and observation as in an FR end-device, with the exception that the FR switch can manage the congestion, which will be treated in the next point.

3) FR Congestion management, FECN/BECN

The congestion management ecn threshold of 10% means that if the queue is filled up to 10 % the FR switch mark any returning traffic to the sender with BECN (Backward Explicit Congestion Notification) to notify the sender that its shaping rate is too high and it should be throttled back, each time the sender receive a BECN it decrease the CIR by 25%, but will never go below mincir (figure3 – first case).

If there is no traffic back to the sender from the receiver, the FR switch mark sender traffic with FECN (Forward Explicit Congestion Notification) to trigger the receiver to send back special q.922 packet toward the sender with BECN bit set (figure3 – second case).

Figure 3: FR FECN/BECN concept

Here is the summary of shaping parameters set in the network to test ECN:

Parameters 

FR End-device, sender 

FR switch 

FR End-device, receiver 

Shaping (outbound) 

Policing (inbound) 

Shaping (outbound) 

Shaping (inbound) 

CIR 

128kbps

(mincir=48kbps)

– 

64kbps

Congestion management

– 

ENC 

10%

Bc=CIR*Tc

16000 

– 

8000

– 

Tc 

125ms 

– 

125ms

– 

Be 

– 

0

– 

R2(sender):

interface Serial0/0.102 point-to-pointclass ADAPT_R2!

map-class frame-relay ADAPT_R2

frame-relay adaptive-shaping becn

frame-relay cir 128000

frame-relay mincir 48000

FRS:

map-class frame-relay SHAPE_R1frame-relay cir 64000frame-relay bc 8000

frame-relay be 0

frame-relay holdq 40

frame-relay congestion threshold ecn 10

!

interface Serial1/0

frame-relay interface-dlci 201 switched

class SHAPE_R1 

R1(receiver):

interface Serial0/0.201 point-to-pointframe-relay interface-dlci 201class FECN_REACT

!

map-class frame-relay FECN_REACT

frame-relay fecn-adapt

frame-relay cir 64000

frame-relay bc 8000

frame-relay be 0 

In our example, the ECN (Explicit Congestion Notification) is set to 10%, consequently if the FR switch PVC 102 shaping queue is filled up to 10% (4 out of 40) traffic is marked with FECN/BECN.

  • With a traffic rate of 48 kbps, the FR switch output interface queue size doesn’t reach the ECN threshold so the congestion mechanism is not triggered:

FRS:

FRS_QOS(config-if)#do sh frame pvc 201
 PVC Statistics for interface Serial1/0 (Frame Relay DCE)

 

DLCI = 201, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial1/0

 

input pkts 98 output pkts 488 in bytes 6802

out bytes 593758 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

30 second input rate 0 bits/sec, 1 packets/sec

30 second output rate 48000 bits/sec, 5 packets/sec

switched pkts 98

Detailed packet drop counters:

no out intf 0 out intf down 0 no out PVC 0

in PVC down 0 out PVC down 0 pkt too big 0

shaping Q full 0 pkt above DE 0 policing drop 0

pvc create time 00:19:46, last time pvc status changed 00:18:27


Congestion ECN threshold 4, not congested

cir 64000 bc 8000 be 0 byte limit 1000 interval 125

mincir 32000 byte increment 1000 Adaptive Shaping none

pkts 493 bytes 599830 pkts delayed 51 bytes delayed 3264


shaping inactive

traffic shaping drops 0

Queueing strategy: fifo


Output queue 0/40, 0 drop, 53 dequeued

FRS_QOS(config-if)#

  • With a traffic rate of 64 kbps, the FRS output queue already experiencing congestion and reach the ECN threshold triggering the congestion management mechanism:

FRS:

FRS_QOS(config-if)#do sh frame pvc 201
 PVC Statistics for interface Serial1/0 (Frame Relay DCE)

 

DLCI = 201, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial1/0

 

input pkts 43 output pkts 144 in bytes 1675

out bytes 186358 dropped pkts 0 in pkts dropped 0

out pkts dropped 0 out bytes dropped 0

in FECN pkts 0 in BECN pkts 22
out FECN pkts 22

out BECN pkts 0 in DE pkts 0 out DE pkts 0

out bcast pkts 0 out bcast bytes 0

30 second input rate 2000 bits/sec, 1 packets/sec

30 second output rate 64000 bits/sec, 5 packets/sec

switched pkts 43

Detailed packet drop counters:

no out intf 0 out intf down 0 no out PVC 0

in PVC down 0 out PVC down 0 pkt too big 0

shaping Q full 0 pkt above DE 0 policing drop 0

pvc create time 00:26:22, last time pvc status changed 00:25:04


Congestion ECN threshold 4, congested

cir 64000 bc 8000 be 0 byte limit 1000 interval 125

mincir 32000 byte increment 1000 Adaptive Shaping none

pkts 152 bytes 198374 pkts delayed 130 bytes delayed 166768


shaping active

traffic shaping drops 0

Queueing strategy: fifo


Output queue 5/40, 0 drop, 137 dequeued

FRS_QOS#

The FRS output interface shaping queue has reached ECN threshold and marked 22 packets with FECN bit toward the receiver and consequently has received from it 22 packets marked with BECN toward the sender.

R1 (receiver):

R1#sh frame pvc 201
 PVC Statistics for interface Serial0/0 (Frame Relay DTE)

 

DLCI = 201, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.201

 

input pkts 4061 output pkts 1076 in bytes 4702782

out bytes 76079 dropped pkts 0 in pkts dropped 0

out pkts dropped 0 out bytes dropped 0


in FECN pkts 78 in BECN pkts 0 out FECN pkts 0


out BECN pkts 78 in DE pkts 0 out DE pkts 0

out bcast pkts 26 out bcast bytes 8545

5 minute input rate 59000 bits/sec, 5 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

pvc create time 00:25:34, last time pvc status changed 00:25:34

cir 64000 bc 8000 be 0 byte limit 1000 interval 125


mincir 32000 byte increment 1000 Adaptive Shaping none

pkts 1076 bytes 76079 pkts delayed 0 bytes delayed 0

shaping inactive

traffic shaping drops 0

Queueing strategy: fifo

Output queue 0/40, 0 drop, 0 dequeued

R1#

The receiver receive FECN marked packets and respond with q.922 packets with BECN bit set.

R2 (sender):

R2#sh frame pvc 102
 PVC Statistics for interface Serial0/0 (Frame Relay DTE)

 

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.102

 

input pkts 1109 output pkts 4140 in bytes 76758

out bytes 4808531 dropped pkts 0 in FECN pkts 0


in BECN pkts 109 out FECN pkts 0 out BECN pkts 0

in DE pkts 0 out DE pkts 0

out bcast pkts 29 out bcast bytes 9619

5 minute input rate 0 bits/sec, 1 packets/sec

5 minute output rate 64000 bits/sec, 5 packets/sec


Shaping adapts to BECN

pvc create time 00:26:58, last time pvc status changed 00:25:29

cir 128000 bc 128000 be 0 byte limit 2000 interval 125

mincir 48000 byte increment 750 Adaptive Shaping BECN

pkts 4137 bytes 4804025 pkts delayed 292 bytes delayed 399128


shaping active

traffic shaping drops 0

Queueing strategy: fifo

Output queue 3/40, 0 drop, 292 dequeued

R2#

With adaptive shaping activated, the sender has received BECN marked packets.

 

4) FR Congestion management, Discard Eligible bit

Another concept of the FR congestion management is Frame Relay policing applied inbound (shaping is applied outbound).

Policing doesn’t perform any queuing and prevent network congestion by either marking traffic “DE” bit (Discard Eligible) or discard traffic exceeding FR traffic policing parameters

Inbound interface policing:

  • If (traffic < Bc) then traffic is transmitted to the outbound interface
  • If (Bc< traffic < Be) then traffic is market with “DE” bit and transmitted to the outbound interface
  • If (traffic > Be) then traffic is dropped

outbound interface shaping and congestion management:

  • If (packets in the shaping queue < DE threshold) packets are transmitted
  • If (packets in the shaping queue > DE threshold) packets with “DE” bit marked are dropped

Here is the summary of congestion management parameters for DE testing:

Parameters 

FR End-device, sender 

FR switch 

FR End-device, receiver 

Shaping (outbound) 

Policing (inbound) 

Shaping (outbound) 

Shaping (inbound) 

CIR 

48kbps

64kbps

Congestion management 

– 

DE

70%

Bc=CIR*Tc

6000

8000

– 

Tc 

125ms

125ms

– 

Be 

8000

0

– 

Configuration on FR switch:

map-class frame-relay SHAPE_R1
frame-relay cir 64000
frame-relay bc 8000

frame-relay be 0

frame-relay holdq 40


frame-relay congestion threshold de 70

!

map-class frame-relay POLICE_R1

frame-relay cir 48000

frame-relay bc 6000

frame-relay be 8000

!

interface Serial1/0

frame-relay traffic-shaping

frame-relay interface-dlci 201 switched

class SHAPE_R1

!

interface Serial1/1

frame-relay interface-dlci 102 switched


class POLICE_R1

frame-relay policing

  • Traffic is generated at the rate of 64 kbps

FRS (inbound PVC, policing):

FRS_QOS(config-map-class)#do sh frame pvc 102
 PVC Statistics for interface Serial1/1 (Frame Relay DCE)

 

DLCI = 102, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial1/1

 

input pkts 352 output pkts 12 in bytes 511716

out bytes 1033 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

30 second input rate 60000 bits/sec, 5 packets/sec

30 second output rate 0 bits/sec, 0 packets/sec

switched pkts 352

Detailed packet drop counters:

no out intf 0 out intf down 0 no out PVC 0

in PVC down 0 out PVC down 0 pkt too big 0

shaping Q full 0 pkt above DE 0 policing drop 0

pvc create time 05:14:01, last time pvc status changed 05:12:32

policing enabled, 347 pkts marked DE

policing Bc 6000
policing Be 8000 policing Tc 125 (msec)

in Bc pkts 12
in Be pkts 347
in xs pkts 0

in Bc bytes 1036
in Be bytes 521194
in xs bytes 0

FRS_QOS(config-map-class)#

The FR switch outbound PVC queue is experiencing congestion and the queue threshold is reached (> 28 out of 40) so the output interface drops all packets marked with “DE” as show in the following output:

FRS (outbound PVC, shaping):

FRS_QOS(config-map-class)#do sh frame pvc 201

 

PVC Statistics for interface Serial1/0 (Frame Relay DCE)

 

DLCI = 201, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial1/0

 

input pkts 16 output pkts 442 in bytes 1554

out bytes 641412 dropped pkts 5 in pkts dropped 0

out pkts dropped 5 out bytes dropped 7510

late-dropped out pkts 5 late-dropped out bytes 7510

in FECN pkts 0 in BECN pkts 0 out FECN pkts 0

out BECN pkts 0 in DE pkts 0 out DE pkts 431

out bcast pkts 0 out bcast bytes 0

30 second input rate 0 bits/sec, 0 packets/sec

30 second output rate 61000 bits/sec, 5 packets/sec

switched pkts 16

Detailed packet drop counters:

no out intf 0 out intf down 0 no out PVC 0

in PVC down 0 out PVC down 0 pkt too big 0

shaping Q full 5 pkt above DE 0 policing drop 0

pvc create time 05:14:19, last time pvc status changed 05:12:59

Congestion DE threshold 28

cir 64000 bc 8000 be 0 byte limit 1000 interval 125

mincir 32000 byte increment 1000 Adaptive Shaping none

pkts 442 bytes 641412 pkts delayed 442 bytes delayed 641412

shaping active

traffic shaping drops 0

Queueing strategy: fifo

Output queue 28/40, 5 drop, 446 dequeued

FRS_QOS(config-map-class)# 

Note: Policing with “DE” marking can be deployed on the customer FR end-device using class-based QoS.

I resumed all previously mentioned concepts in the following figure4:

Figure 4: Shaping and congestion mechanism

CONCLUSION

  • Use “connect” command on the FR switch to set the connection between switched FR PVCs so you can apply FR shaping and policing.
  • Pay attention to where you apply your shaping or policing policy, applied at PVC level will take precedence over the one applied at the sub-interface level, which in turns take precedence over the one applied at the main interface level. This is crucial when your are deploying multipoint sub-interfaces with several PVC’s on customer devices.
  • The FR switch is able to detect “DE” marked traffic and discard it in case of congestion of the output queue, “DE” traffic can be marked by policing at the FR switch inbound interface (if traffic is higher than Bc and lower than Be), this enable the service provider to reinforce the customer service contract; and by the sender FR customer device as well, by marking low priority traffic to be discarded first when congestion is experienced on the FR switch.
  • Traffic congestion, delay and dropping in the FR switch depend on the traffic rate, the shaping queue size and the shaping parameters.
Advertisements

About ajnouri
Se vi deziras sekure komuniki eksterbloge, jen mia publika (GPG) ŝlosilo: My public key for secure communication: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x41CCDE1511DF0EB8

6 Responses to Frame Relay Switching and Policing Lab

  1. Pingback: MQC - Frame Relay policing and marking « CCIE, the beginning!

  2. Pingback: MQC - Frame Relay policing and marking « CCIE, the beginning!

  3. Tom Kacprzynski says:

    I’m trying to find out more info on the shaping congestion mechanism. Can you share with us any reference regarding Figure 4: Shaping and congestion mechanism?

    Thank you.

  4. psybackquilleup says:

    Thanks a lot for this, cleared a lot of doubts!

  5. Pingback: Frame Relay | GNS3 links and issues

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: