09-28-2007 11:59 AM - last edited on 03-25-2019 03:16 PM by ciscomoderator
Does anyone know if FRTS would change the MSS or MTU of packet or frame? I had a strange issue a few weeks ago and we had turned on some QoS with FRTS and it looked very much like an MTU issue.
Solved! Go to Solution.
10-01-2007 12:50 PM
09-28-2007 03:54 PM
Can we see the output from typing
show frame pvc [dlci #] ?
This output will give us a better understanding on the byte limit per tc, you have currently configured.
10-01-2007 04:47 AM
Here you go. This is without the shaping policy configured.
PVC Statistics for interface Serial0/1/0 (Frame Relay DTE)
DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/1/0.100
input pkts 18704610 output pkts 17889547 in bytes 1000475308
out bytes 913715638 dropped pkts 2821 in pkts dropped 0
out pkts dropped 2821 out bytes dropped 1239045
late-dropped out pkts 2821 late-dropped out bytes 1239045
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 50964 out bcast bytes 20538492
5 minute input rate 5000 bits/sec, 4 packets/sec
5 minute output rate 4000 bits/sec, 4 packets/sec
pvc create time 5w0d, last time pvc status changed 5w0d
10-01-2007 05:05 AM
I want to see it with FRTS applied to the interface.
10-01-2007 05:06 AM
Where would I see the byte size? Can I show you the policy or do you need to see the output of that caommand.
10-01-2007 10:12 AM
Yes, show me the map-class for the FRTS. I can determine if the packets will be fragmented.
10-01-2007 10:39 AM
map-class frame-relay qos_shape_1024
frame-relay cir 972800
frame-relay bc 9728
frame-relay be 0
frame-relay mincir 972800
service-policy output qos_queue
10-01-2007 12:47 PM
Yes, you are fragmenting:
pvc create time 00:05:39, last time pvc status changed 00:04:39
cir 972800 bc 9728 be 0 byte limit 1216 interval 10
mincir 972800 byte increment 1216 Adaptive Shaping none
pkts 0 bytes 0 pkts delayed 0 bytes delayed 0
Your byte limit per Tc is 1216. Default MTU is 1500. Increase the bc to a larger value.
10-01-2007 12:49 PM
So anything with the DF bit set would get dropped in this circumstance?
10-01-2007 12:50 PM
Yes.
10-01-2007 12:53 PM
Thanks, this solves a problem. I got this configuration from the Cisco QoS SRND, which says to shape any medium sized Frame Relay tail to 95% of its bandwidth. How do you mitigate again DF-bit packets being dropped? For instance SMTP and RDP packets all have the df-bit set.
10-01-2007 01:12 PM
And that's fine but you need to make sure you aren't fragmenting the packets per tc if you have applications with DF bit set.
By setting your bc to 9728, your tc value is way too low 10ms.
Try changing your bc to 12646 and your byte limit will be higher than 1500
pvc create time 00:30:21, last time pvc status changed 00:29:21
cir 972800 bc 12646 be 0 byte limit 1580 interval 12
mincir 972800 byte increment 1459 Adaptive Shaping none
pkts 0 bytes 0 pkts delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
Queueing strategy: fifo
Edit:
On the above output, the byte limit is above MTU but the byte increment is lower than MTU.
I recommend bc 14592 instead.
pvc create time 00:33:13, last time pvc status changed 00:32:13
cir 972800 bc 14592 be 0 byte limit 1824 interval 15
mincir 972800 byte increment 1824 Adaptive Shaping none
pkts 0 bytes 0 pkts delayed 0 bytes delayed 0
shaping inactive
traffic shaping drops 0
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: