Frame Relay Traffic Shaping and MSS/MTU

[mlitka]

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.

[Edison Ortiz]

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.

[mlitka]

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

[Edison Ortiz]

I want to see it with FRTS applied to the interface.

[mlitka]

Where would I see the byte size? Can I show you the policy or do you need to see the output of that caommand.

[Edison Ortiz]

Yes, show me the map-class for the FRTS. I can determine if the packets will be fragmented.

[mlitka]

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

[Edison Ortiz]

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.

[mlitka]

So anything with the DF bit set would get dropped in this circumstance?

[Edison Ortiz · Accepted solution]

Yes.

[mlitka]

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.

[Edison Ortiz]

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