From: Church, Chuck (cchurch@netcogov.com)
Date: Mon Oct 03 2005 - 22:58:29 GMT-3
Yeah, I've seen a similar issue in the past. 50 bytes is way to small
for almost all traffic types. You want to fragment to keep your
serialization delay low, but at 50 bytes, you're going to be fragmenting
all the traffic you're trying to prioritize. Use netflow to figure out
the average size of time-constrained traffic, and make the size a little
bigger than that. I've used a fragment size of 200 bytes on a 56 kbit
line with Cisco VoIP (FXS port to FXS port) and it sounded pretty good.
Chuck Church
Lead Design Engineer
CCIE #8776, MCNE, MCSE
Netco Government Services - Design & Implementation Team
1210 N. Parker Rd.
Greenville, SC 29609
Home office: 864-335-9473
Cell: 864-266-3978
cchurch@netcogov.com
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
dusth@comcast.net
Sent: Monday, October 03, 2005 6:04 PM
To: ccielab@groupstudy.com
Subject: frame-relay traffic shaping over ospf
My ospf neighbor is down everytime I apply this shapping on the
interface. Is that fragment packet is too small for ospf? When I change
the fragment to 640, ospf comes up just fine.
nterface Serial0/0
ip address 158.1.123.1 255.255.255.0
encapsulation frame-relay
ip ospf priority 0
frame-relay class frts
frame-relay traffic-shaping
frame-relay map ip 158.1.123.2 102 broadcast
no frame-relay inverse-arp
frame-relay lmi-type cisco
end
map-class frame-relay frts
frame-relay fragment 50
no frame-relay adaptive-shaping
frame-relay cir 64000
frame-relay bc 1000
frame-relay be 0
frame-relay fair-queue
Please advice.
Dustin
This archive was generated by hypermail 2.1.4 : Sun Nov 06 2005 - 22:00:49 GMT-3