home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / dcom / sys / cisco / 1271 < prev    next >
Encoding:
Text File  |  1992-09-11  |  2.3 KB  |  47 lines
  1. Newsgroups: comp.dcom.sys.cisco
  2. Path: sparky!uunet!spool.mu.edu!sol.ctr.columbia.edu!destroyer!ncar!csn!news.den.mmc.com!pgl-devsvr.den.mmc.com!jzwiebel
  3. From: jzwiebel@pgl-devsvr.den.mmc.com (John Zwiebel (303)977-1480)
  4. Subject: IP helper address/bridging/FDDI
  5. Message-ID: <1992Sep11.153253.10470@den.mmc.com>
  6. Sender: news@den.mmc.com (News)
  7. Nntp-Posting-Host: pgl-netmgr.den.mmc.com
  8. Organization: PAGE @ Martin-Marietta
  9. Date: Fri, 11 Sep 1992 15:32:53 GMT
  10. Lines: 35
  11.  
  12. I'm working on getting FDDI translation bridging installed on my network.
  13. (I want to thank Eric Decker & Lee Pang of cisco for their help in this.)
  14. Last night I discovered a problem with ip helper-addresses and NIS that I
  15. think I should pass on and ask if anyone else has seen the problem.
  16.  
  17. I switched my routers from running 8.3(3) to 9.1(0.14).  I discovered, after
  18. two days, that NIS clients that lost the bind to their server (generally because
  19. they were being rebooted) could not recontact any server.  I could still ypset
  20. to a server.  I looked at my FDDI ring lanalyzer and discovered that the one
  21. NIS broadcast from the client looking for the server was being bridged onto
  22. the FDDI ring (you have to have an FCIT card and cBus2 for this to happen).  
  23. This one broadcast would generate a 'ministorm' because every host on the ring
  24. would forward a copy of that packet.  Since the IP address was set to broadcast
  25. only on the physical network (xxx.xxx.xxx.255), the hosts routed the packet 
  26. back to where it came from.  There were no ip helper packets forwarded by the 
  27. cisco.
  28.  
  29. By turning on "ip forward-protocol spanning-tree", I was able to get the router
  30. to generate packets directed at the "ip helper-address" or the NIS servers.  
  31. This would _not_ prevent the bridged storm described above, but the clients
  32. can now bind.
  33.  
  34. I tried changing the broadcast address of one of the clients to xxx.xxx.255.255.
  35. This _seems_ to have stopped the storm.  I can still get clients to BIND.  This
  36. is going to require some further testing on my part to be sure of what it 
  37. happening.
  38.  
  39. An important bit of information, All of the Router Ethernet Interfaces are
  40. configured "encap SNAP", "arp SNAP", "no arp ARPA".  All of the clients are
  41. configured to use 802.3 vs DIX (Ethernet2).  
  42.  
  43. Has anyone else seen this problem?  If so please try to provide me with the
  44. circumstances via email.
  45.  
  46. John Zwiebel
  47.