I have set cisco 3550 to act as DHCP server on one my LAN. All the EMAC PC's could able to fetch the address automatically from 3550, but windows machines couldn't fetch, i hav set static ip address configuration in 3550 for both EMAC & win2000. configuration are below
ip dhcp excluded-address 10.205.1.1 10.205.1.10
ip dhcp pool windows
host 10.205.1.1 255.255.255.0
ip dhcp pool emac
host 10.205.1.2 255.255.255.0
ip dhcp pool lan
network 10.205.1.0 255.255.255.0
ip dhcp snooping
ip dhcp-server 10.205.1.250
interface vlan 205
ip address 10.205.1.250 255.255.255.0
ip default-gateway 10.205.1.252
Note: on the LAN i hav made openBSD3.9 to act as dhcp server for few set of pc's which will have a differnet subnet. when i shutdown the openbsd, windowz get the ip address perfectly, but openBSD is ON it doesn't. my question why specifically windows is getting affected & why not mac is not getting affected when openBSD is also acting as dhcp server?
From your description am I correct to understand that the openBSD is connected on the VLAN 205?
Perhaps you can clarify what is configured in the openBSD for DHCP. I do not understand your statement that openBSD provides different ip address series. Perhaps you can clarify.
From my understanding so far I believe that the 3550 and the openBSD are both operating in the same VLAN (and therefore in the same subnet). If that is not correct please correct me.
I believe that part of the explanation is that you have two devices configured as DHCP servers in the same VLAN. In that case when the PC starts up and sends its DHCP request, both servers receive the request, and both servers send a response. It is up to the end station to choose which response to accept. It sounds like the openBSD is responding first and the Windows PCs are attempting to learn addresses from the openBSD server.
Knowing how to resolve this would require additional information about your environment and about the relationship between the DHCP configuration of the 3550 and of openBSD.
lemme clearly explain, 3550 is acting as a dhcp server subent, 10.205.1.0/24, over all 100 pc's are on the network, openBSD subnet 192.168.255.0/24, a novel server is located juz bcoz subnet 10.205.1.0/24 need to access that server & also the subnet 192.168.255.0/24 will also need to access the novel server. so the novel server port is on vlan 205 & also the openBSD too the same(juz bcoz it needs to access the novel server) once it becomes a diff. vlan 192.168.255.0/24 users cannot access novel server as it is using IPX. i hope my question is clear for you to make understand.
as u say that YES openBSD responding fast/first to the clients request that 3550. so how do i over come?
i have planned to put the secondary ip address on vlan 205 with the subnet 192.168.255.0/24, so that i will create 2 DHCP pools. so will it work?
The additional information that you provide is very helpful in understanding the problem. The essence of the problem is indeed that there are 2 DHCP servers in the same VLAN. You may be treating them as 2 subnets, but they are all in the same VLAN and therefore all in the same broadcast domain. This means that when the client sends a DHCP request that both servers will recieve it. And both servers are responding.
Perhaps if we knew more about the 10.205.1/24 and the 192.168.255/24 subnets we might find some solution. (I am not clear why you need 2 subnets) But at this point the only way that I know to really fix the DHCP problem if you need 2 different subnets is to have separate VLANs and each VLAN as a separate subnet. This does create issues if there is a server that both need to access and if the server is running only IPX networking. I believe that the solution for that is really to get a device into the network that can route IPX.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...