home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / dcom / sys / cisco / 1202 < prev    next >
Encoding:
Text File  |  1992-08-31  |  2.4 KB  |  60 lines
  1. Newsgroups: comp.dcom.sys.cisco
  2. Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!agate!boulder!recnews
  3. From: hyder@niwot.scd.ucar.EDU
  4. Subject: Re: bug in 9.0(1) ? 
  5. In-Reply-To: Your message of Mon, 31 Aug 92 11:11:27 +0700
  6. Message-ID: <9208311703.AA02736@mrbean.scd.ucar.edu>
  7. Sender: news@colorado.edu
  8. Date: 31 Aug 92 11:03:01 -0600
  9. Lines: 49
  10.  
  11. >> Recently we discovered strange behaviour in 9.0(1).
  12. >> We route tcp/ip decnet and appletalk and bridge LAT in a 
  13. >> newly installed MGR. 
  14. >> ARP requests done on lan-s connected to this router are
  15. >> FORWARDED to all interfaces! Even worse, since they are
  16. >> forwarded to a AGS with 8.3(3), the AGS has no way of
  17. >> protecting himself, but instead the AGS will put the ARP-s
  18. >> to all of hi's interfaces. In one case he substituded the
  19. >> original ip-address with the AGS ip-address.
  20. >> ...
  21.  
  22. We have also seen some very troubling ARP related problems in
  23. 9.0(1).  At this time we are using an ftp'd copy of 9.0(1.10)
  24. that seems to solve the problems.  My advice would be if you use
  25. bridging don't use 9.0(1).
  26.  
  27. Most of the nasty behavior seems to be related to the unexpected 
  28. behavior on the Cisco routers related to the handling of ARP >reply<
  29. packets.  For the record the queries are broadcast and are filtered
  30. >HOWEVER< replies are bridged, in our case to darn near everywhere on
  31. the net. [Please see question below.]
  32.  
  33. What seemed to happen under 9.0(1) was that the bridged ARP reply
  34. packets caused routers to install incorrect arp cache entries for
  35. related routes.  For example an ARP reply for a host that was known
  36. to be beyond another router caused an update of ALL arp cache entries
  37. for that net PLUS it updated the cache entry for the router.  (Turns
  38. off the router rather nicely.)  Rogue hosts, with the wrong IP address
  39. for the cable segment in question, absolutely triggered this arp cache
  40. corruption.
  41.  
  42. My questions for everyone out there are:
  43.  
  44.    Why should these response packets be bridged to everyhwere?
  45.  
  46.     Yes, they truly are not IP packets by definition and are
  47.     bridge-able.  However, from what I can see on the tcpdumps
  48.     the destination host's location is well known, so it seems to
  49.     me that bridging these off of the origin segment is almost
  50.     never correct.  Is this a feature or is it done for some reason?
  51.  
  52.    Is the solution to this to install a filter that stops all bridged
  53.    arp packets?  Does this stop anything else I'm likely to need?
  54.    (Like my AppleTalk)
  55.  
  56. As always thanks in advance.
  57.     Paul Hyder
  58.     NCAR
  59.     Boulder,CO
  60.