01-29-2007 12:04 PM - edited 03-03-2019 03:32 PM
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?
01-29-2007 01:43 PM
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
01-29-2007 02:01 PM
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 ?
01-29-2007 03:27 PM
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
01-29-2007 04:05 PM
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?
01-30-2007 12:07 PM
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.
01-30-2007 03:46 PM
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_#)'.
01-30-2007 04:48 PM
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
01-30-2007 04:51 PM
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
01-30-2007 04:52 PM
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
01-30-2007 04:59 PM
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
01-30-2007 05:21 PM
01-30-2007 05:33 PM
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?
01-30-2007 05:42 PM
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.
01-30-2007 05:47 PM
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.....
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide