[DHCP] Cisco Relay helper adres probleem

[Firefox]

Hoi luitjes,

Ik zit met een vaag probleem: We hebben een Windows 2003 netwerk met een DHCP server op het hoofdkantoor en verschillende locaties door het land. PC's en Laptops zijn allemaal Windows XP SP1
De routers zijn zodanig geconfigureerd dat ze dhcp requests worden geforward naar het helperadres (== dhcp server).
Dit gaat goed. Alle machines in de locaties krijgen de gewenste adressen toebedeeld. Ergo, DHCP relay werkt.

Maar dan heb je een paar mobiele jongens die maandag op locatie 1 zitten, en dinsdag op locatie 2.
En daar gaat het fout. Zet de PC aan op locatie 2 en de PC blijft roepen dat ie op het IP adres van locatie 1 wil blijven werken. dus...
ipconfig /release; ipconfig /renew
Wederom het IP adres van locatie 1.
poging 2:
ipconfig /release; *gooi lease weg op de server*; ipconfig /renew
Wederom het IP adres van locatie 1.
Het enige wat lijkt te werken is:
ipconfig /release; *reboot PC*

Ik heb redelijk wat gezien aan DHCP Relay agent troubleshooting, maar helaas allemaal gerelateerd aan VPN servers. Weet iemand hoe ik deze rotgrap kan tackelen? want elke keer omslachtig releasen en rebooten vinden de mensen in het veld niet lief....

[Brahiewahiewa]

Hoe heb je de scopes op je DHCP server gedefinieerd?

[JackBol]

Dat heeft met een functie van het DHCP protocol te maken. Deze zal altijd aan de DHCP server vragen of zijn oude adres vrij is. Als dit zo is, zal het dit adres re-requesten. Omdat voor de DHCP server alle requests van de zelfde relay komen, weet deze niet dat de client nu in een andere scope zit.
Wat je kan doen is de leasetime korter zetten. (een uur ofzo) Maar ik denk niet dat dit helpt.
Je zou even moeten zoeken hoe je de dhcp client zover krijgt dat die niet meer zijn oude adres terug wil.

[Brahiewahiewa]

Dirk-Jan schreef op woensdag 20 april 2005 @ 17:56:
Dat heeft met een functie van het DHCP protocol te maken. Deze zal altijd aan de DHCP server vragen of zijn oude adres vrij is. Als dit zo is, zal het dit adres re-requesten. Omdat voor de DHCP server alle requests van de zelfde relay komen, weet deze niet dat de client nu in een andere scope zit.
Wat je kan doen is de leasetime korter zetten. (een uur ofzo) Maar ik denk niet dat dit helpt.
Je zou even moeten zoeken hoe je de dhcp client zover krijgt dat die niet meer zijn oude adres terug wil.

Jij moet je nog maar eens gaan verdiepen in de werking van de DHCP helper

[JackBol]

Brahiewahiewa schreef op woensdag 20 april 2005 @ 18:42:
[...]

Jij moet je nog maar eens gaan verdiepen in de werking van de DHCP helper

als jij het beter weet, dan geef het antwoord maar...

[Arfman]

Brahiewahiewa schreef op woensdag 20 april 2005 @ 18:42:
[...]

Jij moet je nog maar eens gaan verdiepen in de werking van de DHCP helper

Ten eerste zie ik niet wat dit met helpers te maken heeft, en ten tweede: als je het zelf zo goed weet, post het dan hier.

TS: ik heb bijna dezelfde setup, alleen dan met Novell DNS/DHCP draaiend. Werkt zoals het moet werken. Het moet dus iets in jouw netwerk/instellingen zijn, lijkt me.

[Prx]

De router die ingesteld staat op de lokatie als DHCP helper geeft in een TCP pakket naar de hoofdserver bij jullie mee vanaf welk netwerk dat de dhcp request kwam. Hij geeft dus zijn eigen e0 adres mee.

De DHCP server controleert dan of hij een scope heeft in die range, zoja dan zal hij een adres verstrekken welke in die range ligt.

Zal gelijk het antwoord zijn op

Dirk-Jan schreef op woensdag 20 april 2005 @ 20:59:
[...]


als jij het beter weet, dan geef het antwoord maar...

[ Voor 24% gewijzigd door Prx op 21-04-2005 00:08 ]

[Brahiewahiewa]

Precies. Uit RFC1542

If the relay agent does decide to relay the request, it MUST examine the 'giaddr' ("gateway" IP address) field. If this field is zero, the relay agent MUST fill this field with the IP address of the interface on which the request was received.

[Question Mark]

Vraag is even of de laptops op hibernation gezet worden, of echt herstart worden tijdens het verhuizen van de lokatie. In het eerste geval wordt er nl. helemaal geen contact gezocht met de DHCP-server, maar blijft de laptop werken met het (verkeerde) ip-adres wat hij reeds heeft.

Anders zou je moeten gaan sniffen met op het subnet op het moment dat er een verhuisde laptop ingeschakeld wordt.

[Brahiewahiewa]

Question Mark zoog uit zijn duim op donderdag 21 april 2005 @ 15:22:
Vraag is even of de laptops op hibernation gezet worden, of echt herstart worden tijdens het verhuizen van de lokatie. In het eerste geval wordt er nl. helemaal geen contact gezocht met de DHCP-server, maar blijft de laptop werken met het (verkeerde) ip-adres wat hij reeds heeft.

Als ik KB327875 moet geloven, doet een client in ieder geval bij resume from standby z'n IP-adres vernieuwen.
Merk op dat KB327875 precies het probleem van de TS omschrijft, maar dan met een NT4 server.

Anders zou je moeten gaan sniffen met op het subnet op het moment dat er een verhuisde laptop ingeschakeld wordt.

Als je toch gaat sniffen, kun je dat het beste op beide subnets tegelijkertijd doen, en de verschillen zoeken.

[TrailBlazer]

dit probleem is hier al een keer langsgekomen afaik ik zal eens zoeken. overigens het heeft niks met helpers of hybernate te maken.
DHCP laat de lease niet los

[ Voor 19% gewijzigd door TrailBlazer op 22-04-2005 06:59 ]

[Question Mark]

Brahiewahiewa schreef op donderdag 21 april 2005 @ 22:13:
[...]
Als ik KB327875 moet geloven, doet een client in ieder geval bij resume from standby z'n IP-adres vernieuwen.
[...]

Klopt... Echter, laptop doet volgens mij geen nieuwe DHCP-discovery (hij weet immers al het ip-adres van de DHCP-server), hij probeert een renewel. De laptop kan echter op dat moment niet weten dat deze geplaatst is in een ander subnet en gaat naar de voor hem op dat moment bekende gateway (wat nog steeds de 'oude' is). Gevolg is dat er geen contact is met de DHCP-server, dus renewal lukt niet. Standaard gedrag van een windows machine is volgens mij dan dat er doorgewerkt wordt met het huidige ip-adres. En zie hier het probleem van de topic starter.

Ik kan in het door jouw aangehaale KB-artikel niet achterhalen of er ook daadwerkelijk een nieuwe DHCP-discovery plaatsvind, vandaar mijn opmerking om te gaan sniffen...

TrailBlazer schreef op vrijdag 22 april 2005 @ 06:55:
dit probleem is hier al een keer langsgekomen afaik ik zal eens zoeken. overigens het heeft niks met helpers of hybernate te maken.
DHCP laat de lease niet los

In dit topic is het overigens opgelost door DHCP-optie 2 te activeren. Deze optie zorgt ervoor dat laptops automatisch een DHCP-release doen tijdens het afsluiten. Dit lost het nog niet op voor hybernation overigens...

[ Voor 21% gewijzigd door Question Mark op 22-04-2005 09:13 ]

[TrailBlazer]

klopt echter in dat topic lijkt de DHCP server zich niet aan de RFC te houden. Je kan eens gaan sniffen op de DHCP server, welke er nou exact binnenkomen

[Maarten @klet.st]

Brahiewahiewa schreef op donderdag 21 april 2005 @ 00:44:
Precies. Uit RFC1542
[...]

En nog een stukje verder:

code:

   If the relay agent does decide to relay the request, it MUST examine
   the 'giaddr' ("gateway" IP address) field.  If this field is zero,
   the relay agent MUST fill this field with the IP address of the
   interface on which the request was received.  If the interface has
   more than one IP address logically associated with it, the relay
   agent SHOULD choose one IP address associated with that interface and
   use it consistently for all BOOTP messages it relays.  If the
   'giaddr' field contains some non-zero value, the 'giaddr' field MUST
   NOT be modified.  The relay agent MUST NOT, under any circumstances,
   fill the 'giaddr' field with a broadcast address as is suggested in
   [1] (Section 8, sixth paragraph).

Hieruit maak ik op dat als het veld LEEG is de helper het veld moet vullen
en als hiet veld NIET LEEG is, de helper er af MOET blijven. Ik heb de RFC
verder niet gelezen
Uit het verhaal van TS valt op te maken dat er dus om een renewal gevraagd
wordt, waarbij het veld niet leeg is. De helper stuurt dit braaf door..

Zo op het eerste oog dus RFC compliant gedrag.

[TrailBlazer]

leuk probleem dit ik heb namelijk sterk het idee dat er ergens iets is wat zich niet aan een rfc houdt en ik denk iet dat het de cisco is

[Predator]

TrailBlazer schreef op zaterdag 23 april 2005 @ 19:13:
leuk probleem dit ik heb namelijk sterk het idee dat er ergens iets is wat zich niet aan een rfc houdt en ik denk iet dat het de cisco is

Mwah, dat denk ik toch echt niet. Het gaat hier om basis fonctionaliteit en niet over enkel exotische feature die de fabrikant toevoegd of anders implementeerd. Er kan natuurlijk wel altijd 1 of andere bug aanwezig zijn.

Ik heb nog maar weinig problemen gezien bij migraties van IP ranges waarbij routers DHCP relay waren. Net als bij roaming portables.

Ik zou nog niet zo snel de DHCP relay agent veroordelen. Ik zou toch eerder bij de client of server gaan kijken.

Maar zoals reeds gezegd, sniffen met een portable achter een DHCP relay enabled router en tegelijk ook op de server. Je kan gewoon de network monitor van windows installeren op je server. Dan kan je gemakkelijk even inloggen via mstsc en die starten. Daarna sniffer log saven en vergelijken.

PS: just to make sure, je ip helpder-address verwijst toch direct naar je DHCP server IP adres ?

[Question Mark]

Maarten.O schreef op zaterdag 23 april 2005 @ 10:26:
[...]
En nog een stukje verder:

Hieruit maak ik op dat als het veld LEEG is de helper het veld moet vullen
en als hiet veld NIET LEEG is, de helper er af MOET blijven. Ik heb de RFC
verder niet gelezen
Uit het verhaal van TS valt op te maken dat er dus om een renewal gevraagd
wordt, waarbij het veld niet leeg is. De helper stuurt dit braaf door..

Zo op het eerste oog dus RFC compliant gedrag.

Renewal is een point-to-point verbinding naar de DHCP-server, het ip-adres is immers al bekend bij de client. De relay agent doet alleen iets in het geval van een DHCP-discovery (= broadcast)...

[TrailBlazer]

Als de client in een ander subnet staat is de gw verandert en kan de client geen renew vragen. Volgens mij is een renwe ook een broadcast

[Brahiewahiewa]

Question Mark schreef op zondag 24 april 2005 @ 20:16:
[...]Renewal is een point-to-point verbinding naar de DHCP-server, het ip-adres is immers al bekend bij de client. De relay agent doet alleen iets in het geval van een DHCP-discovery (= broadcast)...

't Zou toch prettig zijn als jij je fantasie wat minder de vrije loop liet gaan. Uit RFC1541

3.2 Client-server interaction - reusing a previously allocated network address

If a client remembers and wishes to reuse a previously allocated
network address (allocated either by DHCP or some means outside the
protocol), a client may choose to omit some of the steps described in
the previous section. The timeline diagram in figure 4 shows the
timing relationships in a typical client-server interaction for a
client reusing a previously allocated network address.

1. The client broadcasts a DHCPREQUEST message on its local subnet...

[elevator]

Firefox schreef op woensdag 20 april 2005 @ 16:54:
Ik heb redelijk wat gezien aan DHCP Relay agent troubleshooting, maar helaas allemaal gerelateerd aan VPN servers. Weet iemand hoe ik deze rotgrap kan tackelen? want elke keer omslachtig releasen en rebooten vinden de mensen in het veld niet lief....

Je kan een DHCP Option instellen op je DHCP server dat je IP address bij shutdown gereleased wordt -

quote: http://www.microsoft.com/...f0-96d6-4b7414ecfaae.mspx

Release DHCP Lease on Shutdown

This option can be used to control whether DHCP-enabled computers running Windows 2000, Windows XP, or Windows Server 2003 sends a DHCPRelease message to the DHCP server when a shutdown occurs. It is actually implemented and interpreted as a bit-masked value by the DHCP Client service. By default, these clients do not send DHCPRelease messages on proper shutdown.

Misschien dat je op deze manier er om heen kan werken?

[alt-92]

elevator schreef op zondag 24 april 2005 @ 22:07:
Misschien dat je op deze manier er om heen kan werken?

dat helpt wel met een shutdown, maar niet met hibernate, en daar gaat 't nou net mis (tenminste voor zover ik het lees).
En dat is echt een client-issue..

[TrailBlazer]

ik zal zometeen eens testen ik klap nu deze flaptop dicht en laat hem aan (hybernate denk ik) en hang hem meteen aan het bedrijfsnetwerk. O hetzelde moment zal ik etherreal opstarten
OK gedaan
laptop -> DHCP REQUEST voor zijn oude (thuisnetwerk ip) (broadcat
server -> NAK.
laptop -> DHCP DISCOFFER
server -> DHCP OFFER
cleint -> DHCP REQUEST voor het ipadres in de offer
server -> DHCP ACK

kortom sniffn zal het amntworod bieden wie het fout doet

[ Voor 45% gewijzigd door TrailBlazer op 25-04-2005 08:25 ]

[elevator]

BackSlash32 schreef op zondag 24 april 2005 @ 22:32:
dat helpt wel met een shutdown, maar niet met hibernate, en daar gaat 't nou net mis (tenminste voor zover ik het lees).
En dat is echt een client-issue..

Het is dan ook een DHCP client option, en dan ook echt een client 'oplossing'
Gewoon even proberen zou ik zeggen dus

[Firefox]

Sigh.
Aan de hand van dat ene andere draadje op GoT toch nog een keer de DHCP manual doorgeploeterd.

Ik heb nog geen bevestiging ervan dat eea is opgelost - het is nog even afwachten op de resultaten - maar het probleem lijkt hem te zitten in een SuperScope verhaal. Het lijkt er op dat ik de werking van superscopes net verkeerd om heb geinterpreteerd. Ben benieuwd of eea nu wel is opgelost.

[TrailBlazer]

wat is precies het nut van superscopes precies. Ken het principe niet op mijn linux dhcp server maak ik gewoon voor iedere subnet een scope aan. In dat andere draadje is er IMHO ook nooit een oorzaak gevonden maar een buggy oplossing bedacht.

Ik blijf er bij snif en kijk wie wat vraagt/uitdeelt

[Brahiewahiewa]

Uit Using superscopes begrijp ik dat superscopes bedoeld zij ter ondersteuning van "multinets"; meerdere IP-ranges op 1 segment.

A superscope is an administrative feature of DHCP servers running Windows Server 2003 that you can create and manage through the DHCP console. Using a superscope, you can group multiple scopes as a single administrative entity. With this feature, a DHCP server can:

• Support DHCP clients on a single physical network segment (such as a single Ethernet LAN segment) where multiple logical IP networks are used. When more than one logical IP network is used on each physical subnet or network, such configurations are often called multinets.
• Support remote DHCP clients located on the far side of DHCP and BOOTP relay agents (where the network on the far side of the relay agent uses multinets).

In multinet configurations, you can use DHCP superscopes to group and activate individual scope ranges of IP addresses used on your network. In this way, the DHCP server computer can activate and provide leases from more than one scope to clients on a single physical network.

Dat zou het waargenomen gedrag goed kunnen verklaren. Je krijgt gewoon op elk segment voor elk IP-adres uit de superscope een ACK, ongeacht of het IP-adres binnen het segment in kwestie valt.

[ Voor 13% gewijzigd door Brahiewahiewa op 25-04-2005 23:21 ]