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
Serial0/0 is a full T1 at this end, a 256K fractional T1 at the
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.
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
police cir 120000
description DLCI 100
no ip address
encapsulation frame-relay IETF
logging event dlci-status-change
serial restart-delay 0
interface Serial0/0.150 point-to-point
ip address 188.8.131.52 255.255.255.252
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...
Vincent C Jones, Consultant Expert advice and a helping hand
Networking Unlimited, Inc. for those who want to manage and
Tenafly, NJ Phone: 201 568-7810 control their networking destiny