Frame relay traffic shaping and QoS appears to be incompatible with frame relay end-to-end keepalives. Need traffic shaping to provide production traffic with guaranteed bandwidth in the presence of other traffic. Need end-to-end keepalives (EEK) to reliably detect loss of frame connectivity at the link level (for policy routing).
The configuration which follows works fine as long as there is not too much production traffic. No problems (except for surfers) when background traffic exceeds available bandwidth. But major problems when production traffic exceeds allocated bandwidth. This forces the PVC down due to loss of end-to-end keepalives. It appears that end-to-end keepalives have lower priority than reserved bandwidth, unlike routing keepalives, which have their own high priority queue.
Side note: the background traffic is policed because if left to contend for available bandwidth, the frame relay traffic shaping kicks in before the background traffic is rate limited, boosting the queuing delays for production traffic to unacceptable (approx five seconds one way) levels. As configured, production traffic delay still suffers a major, but not fatal, hit, rising from 60 ms at no load to around 150 ms. Using "priority" rather than "bandwidth" does not improve the delay hit, implying it is queuing occuring after the QoS queuing has already been applied.
Another hint: With both production and background traffic sources running at overload, production traffic is not being limited to the allocation, behaving more like priority queuing rather than QoS queuing.
Serial0/0 is a full T1 at this end, a 256K fractional T1 at the destination end.
Anyone have any ideas what is going on or how to fix it? Ideal would be getting QoS to work the way it does on a leased line, but just getting frame EEK to queue at a higher priority would be acceptable.
Configuration excerpts:
Cisco Internetwork Operating System Software IOS (tm) C1700 Software (C1700-SY7-M), Version 12.3(10b), RELEASE SOFTWARE (fc3) cisco 1760 (MPC860P) processor (revision 0x500) with 56320K/9216K bytes of memory. Processor board ID FOC08091V2T (923892838), with hardware revision 0000 MPC860P processor: part number 5, mask 2
! class-map match-all APPL-priority match access-group name PRIORITY-TRAFFIC ! policy-map FRAME256policy class APPL-priority bandwidth 100 class class-default fair-queue police cir 120000 conform-action transmit exceed-action drop violate-action drop ! interface Serial0/0 description DLCI 100 no ip address encapsulation frame-relay IETF logging event dlci-status-change serial restart-delay 0 no fair-queue frame-relay traffic-shaping ! interface Serial0/0.150 point-to-point description TestLink bandwidth 240 ip address 206.208.93.37 255.255.255.252 delay 1000 frame-relay class FrameShape256 frame-relay interface-dlci 150 ! ip access-list extended PRIORITY-TRAFFIC permit icmp host 192.168.100.131 any ! map-class frame-relay FrameShape256 frame-relay end-to-end keepalive mode bidirectional frame-relay cir 256000 frame-relay mincir 256000 frame-relay traffic-rate 240000 240000 service-policy output FRAME256policy !
Thanks in advance...