Member Avatar for poppaman2

I am posting this thread in the one of Network groups as well....

I have a triple homed system (a Dell GX270 w/512MB RAM running Windows 2000 Pro SP4 fully patched): the built-in (onboard) NIC is connected to our production network, the second NIC (a 3C900B combo RJ45/BNC card) is connected to one device via BNC cable (this device is controlled via direct IP communication to the MAC address or the device's network card) and the third NIC (a 3C900B TPO card) is connected to a second device via Intel 5 port hub, and receives its' IP address via bootp (server resident on the PC).

The problem is this: The bootp server is supposed to receive an IP address request from the 2nd device upon device bootup, which it does without issue provided the production network is disconnected OR the NIC is disabled. When the production network is enabled, the resident bootp server sees requests from other similar devices on the network. The bootpserver, having been configured to respond only to requests from the 2nd device's MAC address, rejects all of these foreign requests, but in doing so cannot process the one request which it SHOULD be responding to. Today, the bootp requests were coming in at such a rate that the CPU utilization approached 100%.

The bootp server is from Agilent and should be associated only with the third NIC. Is there a way to isolate the bootp server? Is there a way to prohibit what looks to be LAN bridging? The Routing and Remote Access service is disabled.

Any and all assistance tou might be able to give me would be appreciated.

  • 2 Contributors
  • 1 Reply
  • 134 Views
  • 6 Hours Discussion Span
  • Latest Post Latest Post by DMR

Dani AI

Generated

A concise expert add-on to (and noting 's cross-post reminder): the symptom described is typically caused by one of two things — the BOOTP daemon is listening on every IP interface and therefore sees broadcast BOOTP requests from the production LAN, or there is an unintended path (physical or software) tying the production segment into the BOOTP segment. The troubleshooting priority should be: prove which of those is happening, then either force the BOOTP service onto a single adapter or stop BOOTP packets from arriving on the production interface.

Useful quick checks (run as Administrator):

ipconfig /all
route print
netstat -ano | find ":67"

If netstat shows a listener on UDP port 67 bound to 0.0.0.0 (or to the production adapter IP), the BOOTP server is reachable from every interface. Use a packet capture (Wireshark/WinPcap) on each adapter to confirm which NIC is actually receiving the flood of BOOTP/DHCP Discover traffic.

Remedies, in order of least-to-most disruptive:

  • Configure the Agilent BOOTP service to bind to the dedicated adapter/IP only (many BOOTP/DHCP servers expose a "listen on" or "adapter binding" option).
  • If the server cannot bind, use a per-adapter packet filter/firewall on the host to block inbound UDP 67/68 on the production NIC (this keeps BOOTP traffic from being handed to the service).
  • Physically isolate the BOOTP segment: remove any accidental uplink on the hub, place the device and PC on a dedicated switch with no connection to the production LAN, or run the BOOTP server on a dedicated machine/VM that only has the single NIC attached.
  • Verify no Windows-level bridge/ICS/RRAS is active (check Network Connections for a "Network Bridge" and confirm RRAS/ICS are off).

These steps will show whether the issue is a service binding or an unintended network path and provide practical removal methods without rearchitecting the production network.

Member Avatar for DMR

Hi poppaman2,

As stated in our forum rules, we ask that members not cross-post/double-post in the forums. Given that, we'll stick with your original thread, which you posted in the correct (Networking) forum.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.