According to the 250 ms bc i explained above which i think it takes as default, the bc in bytes should be
796 (using the formula: bc in bytes * 8 / class BW = bc in ms).
But i get a message saying: "burst bc increased to 1500 bytes".I can only assume it does this because the ingress
interface is an Ethernet interface and the policer runs before FRTS? (again,according to Cisco diagrams).
This stops me from setting the bc value to lower than 1500 by lowering the value in ms, by the way you cannot specify
bc in bytes, only in ms.
Now, what's a logical solution?I have tried lowering the interface MTU ( a serial interface) but nothing.
It wouldn't make any sense to lower the MTU on the ingress Ethernet interface,would it?
! map-class frame-relay 2PE frame-relay cir 256000 frame-relay bc 2560 frame-relay be 0 frame-relay mincir 256000 frame-relay fragment 320 service-policy output ce2pe
! policy-map ce2pe class voice priority percent 33 police cir percent 33 bc 20 ms conform-action transmit exceed-action drop class data bandwidth percent 40 random-detect dscp-based police cir percent 40 conform-action set-dscp-transmit af21 exceed-action set-dscp-transmit af23 class video bandwidth percent 10 police cir percent 10 conform-action set-dscp-transmit af41 exceed-action drop class control bandwidth percent 5 class vocontrol bandwidth percent 5 set ip dscp cs3 class class-default bandwidth percent 5 set ip dscp default
! interface Serial0/0 no ip address encapsulation frame-relay frame-relay traffic-shaping max-reserved-bandwidth 100 ! interface Serial0/0.1 point-to-point ip address 10.0.1.2 255.255.255.0 no cdp enable frame-relay class 2PE frame-relay interface-dlci 100
I know this is an old post but I was researching the topic myself and wanted to share what I found. I think a Bc lower than 1500 would yield unwanted results. Let's say for example 798 was the Bc. Any packet above 798 would be dropped because the policer would always consider it in violation. In your case with FR fragementaiton set to 320 you would never encounter a large packet. Makes me wonder if there is a way around this...