From: Church, Chuck (cchurch@netcogov.com)
Date: Tue Oct 04 2005 - 00:25:25 GMT-3
Depends on if this is a real-world issue, or a lab issue. Fragmenting
this small (even if it makes no sense) shouldn't break higher-level
protocols. Could be a bug, so you could try a newer GD IOS. Debugging
OSPF might tell you what is failing. Blocking OSPF isn't going to make
OSPF work :), so I don't think that'll solve anything. If it's a lab
question, I don't think you have to worry about the lab proctors giving
you a test where an IOS issue will cause something else not to work.
Try making your fragment size slightly larger than an OSPF hello packet.
(not sure how big they are), keep playing with the fragment size to find
out where it starts working. Maybe multicast and fragmentation don't
get along? Just a guess though...
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
________________________________
From: dusth@comcast.net [mailto:dusth@comcast.net]
Sent: Monday, October 03, 2005 10:40 PM
To: Church, Chuck; ccielab@groupstudy.com
Subject: RE: frame-relay traffic shaping over ospf
How do I remedy this situation if I still want to have fragment side to
this small. Should a extended acl to deny ospf or any other frame-relay
command or subcommand to remedy this issue?
Dustin
-------------- Original message --------------
> 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