[comp.protocols.tcp-ip] How to limit broadcasts between expensively connected networks?

mickey@altos86.Altos.COM (Michael Thompson) (07/11/90)

I have two local area networks connected via a slip connection over X.25.
(I know it's a hack, but I do get reasonable throughput)

		     gateway-A			   gateway-B
      144.1       ---------------   X.25(slip)	----------------  192.68.19
      (ethernet)  | 200.2.10.1  |<<----------->>| 200.2.10.2   |  (ethernet)
    <<---------->>| 144.1.10.98 |		| 192.68.19.42 |<<--------->>
		  ---------------	        ----------------
		  gateway to 200.2.10           gateway to 200.2.10
		  gateway to 192.68.19	        gateway to 144.1

When the gateways are configured as above, I can ping any machine on the
192.68.19 network from anywhere on the the 144.1 network (and vice versa).
However, I notice a lot of traffic across the X.25 line that I am guessing are
broadcasts (maybe from rwhod and/or timed??).  These broadcasts seem to
originate from machines other than the gateways since if I don't make
them appear as gateways between 144.1 and 192.68.19 the traffic is eliminated.

My question is: is there any way to (at the gateways) limit broadcast traffic
over expensive connections?


				Thanks,

				-Michael
				mickey@altos.Altos.COM

almquist@JESSICA.STANFORD.EDU ("Philip Almquist") (07/12/90)

Michael,
> My question is: is there any way to (at the gateways) limit broadcast traffic
> over expensive connections?

	In general, broadcasts on one of your nets will not be forwarded
across the SLIP line to the other net.  The only exception that I know
of is that cisco routers can be configured (using "helper-address" or
whatever they call it now).

	If you are using a routing protocol, it can (depending upon the
protocol and the rest of your topology) generate a fair amount of
traffic across the SLIP link.  By clever configuration or by using
static routing you can minimize eliminate this traffic.

	If I were you, I would try to diagnose the problem more fully.
I don't know what kind of routers you are using, but most include the
facility to trace packets going through them.  Although that is hardly
recommended for regular use (since it slows the routers to a crawl),
such a facility is very useful for diagnosing the sort of problem you
are seeing.
							Philip

raj@hpindwa.HP.COM (Rick Jones) (07/12/90)

I have two local area networks connected via a slip connection over X.25.
(I know it's a hack, but I do get reasonable throughput)

		     gateway-A			   gateway-B
      144.1       ---------------   X.25(slip)	----------------  192.68.19
      (ethernet)  | 200.2.10.1  |<<----------->>| 200.2.10.2   |  (ethernet)
    <<---------->>| 144.1.10.98 |		| 192.68.19.42 |<<--------->>
		  ---------------	        ----------------
		  gateway to 200.2.10           gateway to 200.2.10
		  gateway to 192.68.19	        gateway to 144.1

$Begin Response$

	Well, correct me if I am wrong (I'm sure someone will ;-), but
the ONLY *IP* broadcasts that should be going across the gateways
should be directed IP broadcasts. a 144.1.255.255 bcast should not be
forwarded from 144.1 to 192.68.19...

Are your gateways configured to be brouters? That would be the likely
way I can think of where broadcasts - ARPs and other non-IP - might be
passed from gateway to gateway? Rwho, and timed, being IP based,
should not be propagating across the gateways/routers. If they are
indeed brouters, you might try digging deep into the back of the
manuals to find-out how to set-up filtering for the 'bridged' packets
of the brouter.

___   _  ___
|__) /_\  |    Richard Anders Jones   | MPE/XL Networking Engineer
| \_/   \_/    Hewlett-Packard  Co.   | Honest! It is TCP/IP! ;-)
------------------------------------------------------------------------
Being an employee of a Standards Company, all Standard Disclaimers Apply

jbvb@VAX.FTP.COM (James B. Van Bokkelen) (07/14/90)

If the routers in use are actually 4bsd Unix systems, all the ones
I've ever seen forward both RIP and RWHO packets out all their
interfaces (SLIP included) by default.  I don't recall anything in
the manual pages which indicate that either broadcast can be
restricted to a subset of the attached interfaces, but my memory
isn't quite perfect, and I havn't read the source...

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901