nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

question about DHCP

sizeon

Isnt the answer suppose to be "B"?

dhcp.JPG

Find more posts tagged with

SAVE $250 on Your CISCO Boot Camp — Use Code "EXAM26"

Exclusively for TechExams members for Infosec Boot Camps starting before April 30, 2026

View CISCO Boot Camps

Comments

Roguetadhg

IP address conflicts happen a lot, so i'll say "D". I didn't know both hosts asked for different IP addresses though. I don't see two computers right beside each other taking the same IP address either

Atleast where I work it happens a lot -_- but then again... using a /24 prefix and over 255 active computers... I can see that being a constant problem :P (no secondary addressing that I'm aware of)

http://compnetworking.about.com/od/workingwithipaddresses/f/ip_conflict.htm

http://www.webopedia.com/DidYouKnow/Internet/2007/IP_Address_Conflicts.asp
"...IP conflicts tend to eventually work themselves out in DHCP environments because systems issue repeated requests for valid addresses."

sizeon

The answer is supposedly "C".

fsanyee

The answer is C.
Gratuitous ARP only try to avoid the conflict, but not fix it.

Roguetadhg

i doubt that someone goes into the DHCP at every conflict to manually setup an address to a training computer. But okay :P

Forsaken_GA

There are a couple cases in which a DHCP conflict will occur.

The first is when the subnet has more boxes than IP's. How this is handled differs between the various DHCP daemons. Some will refuse to issue until the leases are up, some will expire the oldest leases. Either way, this is an administration problem, and only gets fixed by human intervention.

The second most common case is when a host is configured with a static IP address that's still within the range of the DHCP pool, so the DHCP server could potentially issue an IP already in use (again, depends on the daemon... some actually check to see if an IP is in use before it offers it up). In that case, administrator intervention is still the only viable solution - either the IP in question gets excluded from the pool, or the host statically defined gets readdressed to something outside the DHCP range, or gets put on DHCP.

My personal preference is to put an exception for the MAC address of hosts that are statically defined into the DHCP servers config so that it gets the same IP address every time. This keeps configuration consistent across the subnet, but it can be a huge gotcha during hardware changeovers.

Roguetadhg

Gotcha. we're talking about not bandaging the problem by either ipconfig /release or a host restart. Instead, getting to the thick of things and fix the cause of the issue.

I like the MAC address idea but that would be a huge administrative cost for a lot of workplaces that are already thinned out?

Forsaken_GA

Roguetadhg wrote: »

Gotcha. we're talking about not bandaging the problem by either ipconfig /release or a host restart. Instead, getting to the thick of things and fix the cause of the issue.

I like the MAC address idea but that would be a huge administrative cost for a lot of workplaces that are already thinned out?

Depends on the work place. If you don't have many servers, then not really. If you have thousands of servers and you convert to it, then yes, there's alot of up front work. If you've been doing it from the word go, then it's not really that much of an administrative hit, you just make it part of the provisioning process.