cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
780
Views
0
Helpful
17
Replies

frame relay traffic shaping - FRTS - unconfigured PVC

cmccready
Level 1
Level 1

I have a frame circuit and am implementing FRTS. I have sub-interfaces configured and classes mapped. My question is ... I ordered a new PVC and had not yet configured a sub-interface with DLCI and class map. When issuing the 'show traffic' command it shows the PVC appears to have been "adopted" by the main interface and then had the default 56k policy applied. This automatic activity seems to have imposed the default 56k limitation on all sub-interfaces, even though they have higher values configured. If I then configure a sub-interface for this pvc, the limitations seem to go away. Is this normal behavior? Do I need to configure sub-interfaces before the orders are placed?

17 Replies 17

What you are seeing is the normal behavior of IOS when FRTS is enabled on the main interface. Any sub-int or PVC that doesn't have an explicit FRTS class applied would be applied the default policy of 56k.

You might want to configure a default policy like the one below (for a t1 interface) and apply it on the main interface and that way the CIR isn't restricted to 56k. This would make sure any sub-int or PVC that doesn't use a class wouldn't start crawling at 56k speed when the actual bandwidth may be much higher.

int s0

frame-relay traffic-shaping

frame-relay class cisco

map-class frame-relay cisco

frame-relay cir 1536000

frame-relay bc 48000

HTH

Sundar

thanks for the reply. If I apply a class to the main interface does it impact the sub-interfaces? If I were to use a cir of 1024000 on the main interface instead of the 1536000 you listed, would it prohibit sub-interfaces with different map-classes from utilizing a cir of 1536000 ?

It should not be a problem. You can set the CIR to 1024k on main int and 1544 on sub-int. The class that is used on the main int would only be applied to PVCs that doesn't have it's own FRTS class.

HTH

Sundar

Thanks, again, for the reply. But I'm confused.

In my network I had configured a map-class with a 4096000 cir and applied it to a sub-interface of a T3. There is a second PVC provisioned by our provider but I had not yet created a sub-interface nor applied a map-class. As a result the 'show traffic-shape' command assigns the default 56000 to the main interface and the 4096000 on the sub-interface. That behavior now makes sense to me. However my network monitor shows that the sub-interface was unable to pass traffic above 32000. This behavior is unexpected since it's map-class specified 4096000. Can you help me to understand this?

I'm still trying to figure this out. If anybody has an explanation of why the pvc would throttle to 32k when the map-class specifies 4Mb I would love to know. Thanks.

Are you saying you are only able to send 32k data across the PVC when your shaping is set to 4096k. Can you attach the config after removing any sensitive info. Moreover, post the output of 'show frame-relay pvc (dlci_#)'.

here is the show traffic

Interface Se4/0

Access Target Byte Sustain Excess Interval Increment Adapt

VC List Rate Limit bits/int bits/int (ms) (bytes) Active

35 56000 875 7000 0 125 875 -

Interface Se4/0.86

Access Target Byte Sustain Excess Interval Increment Adapt

VC List Rate Limit bits/int bits/int (ms) (bytes) Active

25 4096000 72000 512000 512000 16 8192 BECN

here is the show frame pvc for the configured pvc

ADC-7206-2#show frame-relay pvc 25

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

DLCI = 25, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial4/0.86

input pkts 534234 output pkts 248585 in bytes 52547080

out bytes 51885039 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 100135 out bcast bytes 8437467

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

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

Shaping adapts to BECN

pvc create time 1w0d, last time pvc status changed 1w0d

service policy VOICE-POLICY

Serial4/0.86: DLCI 25 -

Service-policy output: VOICE-POLICY

Class-map: voice-traffic (match-all)

0 packets, 0 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: access-group 102

Queueing

Strict Priority

Output Queue: Conversation 72

Bandwidth 128 (kbps) Burst 3200 (Bytes)

(pkts matched/bytes matched) 0/0

(total drops/bytes drops) 0/0

Class-map: voice-signaling (match-all)

23 packets, 18090 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: access-group 103

Queueing

Output Queue: Conversation 73

Bandwidth 8 (kbps) Max Threshold 64 (packets)

(pkts matched/bytes matched) 23/18090

(depth/total drops/no-buffer drops) 0/0/0

Class-map: class-default (match-any)

140737 packets, 20435200 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: any

Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 64

(total queued/total drops/no-buffer drops) 0/0/0

Output queue size 0/max total 600/drops 0

fragment type end-to-end fragment size 1000

cir 4096000 bc 512000 be 512000 limit 72000 interval 16

mincir 1024000 byte increment 8192 BECN response yes IF_CONG no

frags 148193 bytes 21043086 frags delayed 11164 bytes delayed 7635328

shaping inactive

traffic shaping drops 0

here is the show frame pvc for the unconfigured pvc

ADC-7206-2#show frame-rel pvc 35

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

DLCI = 35, DLCI USAGE = UNUSED, PVC STATUS = ACTIVE, INTERFACE = Serial4/0

input pkts 0 output pkts 0 in bytes 0

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

switched pkts 0

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 6d22h, last time pvc status changed 04:41:49

cir 56000 bc 7000 be 0 byte limit 875 interval 125

mincir 28000 byte increment 875 Adaptive Shaping none

pkts 0 bytes 0 pkts delayed 0 bytes delayed 0

shaping inactive

traffic shaping drops 0

Queueing strategy: fifo

Output queue 0/40, 0 drop, 0 dequeued

here is the stuff from the config that I think is relevant. It is almost straight out of the Cisco documentation with a couple modifications

class-map match-all voice-signaling

match access-group 103

class-map match-all voice-traffic

match access-group 102

!

!

policy-map VOICE-POLICY

class voice-traffic

priority 128

class voice-signaling

bandwidth 8

class class-default

fair-queue

interface Serial4/0

no ip address

encapsulation frame-relay

dsu bandwidth 44210

framing c-bit

cablelength 10

serial restart-delay 0

frame-relay traffic-shaping

!

!

interface Serial4/0.86 point-to-point

bandwidth 512

ip address x.x.x.x 255.255.255.252

no ip redirects

no ip proxy-arp

frame-relay interface-dlci 25

class VoIPovFR

!

!

map-class frame-relay VoIPovFR

frame-relay adaptive-shaping becn

frame-relay cir 4096000

frame-relay bc 512000

frame-relay be 512000

frame-relay mincir 1024000

service-policy output VOICE-POLICY

frame-relay fragment 1000

access-list 102 permit udp any any range 16384 32767

access-list 102 permit udp any any precedence critical

access-list 102 permit udp any any dscp ef

access-list 103 permit tcp any eq 1720 any

access-list 103 permit tcp any any eq 1720

the attached graph shows when I converted traffic to this circuit. notice the blue and red lines flattening at about 32k and then the jump when I moved traffic back to the original circuits

Configuration looks OK for the most part except you can lower the Bc & Be to 128k but that shouldn't cause the problem you are seeing. Did you try to taking off FRTS from the interface and test? If that allows you to burst at much higher speed then try applying FRTS on the interface without the service policy config. Another question, why do you have bandwidth on the sub-interface configured at 512k instead of reflecting the actual bandwidth of the circuit. Just wondering, whether the circuit was provisioned correctly?

We use the bandwidth statements primarily for eigrp calculation. when the spoke offices started complaining, i reduced the bandwidth statement so the traffic would move from the frame circuit back to the atm circuit.

i'll try removing the shaping configs the next maintenance window, which is likely to be this weekend.

ccm-

I think for voice QOS be is 0, bc 1/10 cir and adaptive shaping disabled or your getting

becn's the shaping will adjust unitil the becn's stop? who's your frame provider? most providers police now day's.....

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: