home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / sun / admin / 6071 < prev    next >
Encoding:
Internet Message Format  |  1992-09-02  |  2.1 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!think.com!barmar
  2. From: barmar@think.com (Barry Margolin)
  3. Newsgroups: comp.sys.sun.admin
  4. Subject: Re: message from Unknown router
  5. Date: 2 Sep 1992 19:21:11 GMT
  6. Organization: Thinking Machines Corporation, Cambridge MA, USA
  7. Lines: 34
  8. Message-ID: <183477INN9cp@early-bird.think.com>
  9. References: <1992Sep2.144249.11124@samba.oit.unc.edu>
  10. NNTP-Posting-Host: telecaster.think.com
  11.  
  12. In article <1992Sep2.144249.11124@samba.oit.unc.edu> Shawn.Hayes@bbs.oit.unc.edu (Shawn Hayes) writes:
  13. >Hi.  A freind of mine has a few Sparcstations that he is managing and 
  14. >he is having a few proplems with a message showing up every few minutes
  15. >from an unknown router.  His machines are hooked up to thicknet backbone
  16. >which is tied into a corporate network.  The unknown router is not one
  17. >of his machines.  Has anyone run into a similar problem and what changes
  18. >are likely to fix the problem. 
  19.  
  20. That message is printed by in.routed when it receives a routing table from
  21. a router that's not on the local subnet and not listed in /etc/gateways.
  22.  
  23. We saw this when we were running two logical subnets on one physical net,
  24. using a cisco router's "secondary address" feature.  In order to get the
  25. router to send RIP broadcasts that hosts on both subnets would receive, we
  26. had to configure it to use the 255.255.255.255 broadcast address rather
  27. than net.net.subnet.255.  This caused machines on each logical subnet to
  28. see the broadcast from the router's address on the other subnet.
  29.  
  30. This could also happen if your routers are configured to forward
  31. broadcasts.  This is often not correct, so you may have a router
  32. configuration problem.
  33.  
  34. If they determine that the routers are correctly configured, then you can
  35. silence in.routed by putting an entry for the unknown router in
  36. /etc/gateways on each machine that complains.  The entry will be ignored
  37. when making routing decisions, because a machine can only route through a
  38. machine on the same subnet anyway, but it will be a "known" router and thus
  39. not generate warnings.
  40.  
  41. -- 
  42. Barry Margolin
  43. System Manager, Thinking Machines Corp.
  44.  
  45. barmar@think.com          {uunet,harvard}!think!barmar
  46.