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