From: Chuck Church (cchurch@xxxxxxxxxxxx)
Date: Sat Dec 08 2001 - 13:53:12 GMT-3
Michael,
Since it's serial, you've got hellos every 10 seconds. CDP every
minute. That could add up to 1.5mb per day. I'm pretty sure the broadcast
counter includes multicasts. But if it's a least a 56kb circuit, that's a
pretty small percentage of your available bandwidth. Sniffer is good for
identifying traffic and bandwidth hogs. If you don't have Sniffer, you can
put an ACL on the hub and one remote site that has a permit for each
protocol you know of that is going between the sites. Finish it with a
permit all. Sh access-list will then give you a count of matches for each
protocol.
Chuck
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Yonkerbonk
Sent: Friday, December 07, 2001 5:15 PM
To: ccielab@groupstudy.com
Subject: Excessive Broadcasts on Serial links?
I have a client complaining of slow WAN links. He
has 3 hub routers, each with about 5-7 remote links.
They are all running OSPF. The remote sites are not
configured as stub areas even though there is nothing
behind them (I will remedy that).
What I noticed was that the remote router Serial
interfaces all had high 'out bcast bytes', that
averaged out to 1.5 MB a day. Some of those routers
have only been up 5 days and some of them have been up
15 weeks, but somehow they have all managed to average
1.5 MB a day. And the only thing I can think of that
would show up as broadcasts on the Serial interface is
OSPF and CDP.
They only have 2 subnets listed under OSPF with a
total of 50 routes when I do a show ip route. The show
ip ospf database is relatively small too - I only need
to hit spacebar once to see entire database.
Anyone have any ideas if 1.5 MB is high? I think it
is since there are not alot of routes and there
shouldn't be any changes since it's a stub router. The
30 minute updates and CDP shouldn't contribute much
either.
Thanks.
Michael Le, CCIE #6811
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:32:40 GMT-3