[Ubuntu 12] Verliest routes na 2-2,5 uur

[sig69]

Ik heb een Ubuntu 12 server draaien in Hyper-V voor iptv (zie: IPTV op je HTPC). Alles werkt perfect, TvHeadend erop, helemaal mooi. Voor twee uur. Daarna vallen er wat routes weg die nodig zijn voor iptv en werkt het niet meer. De routes worden als volgt toegevoegd overigens:

code:

auto eth1
iface eth1 inet dhcp
 metric 20
 vendor "Aminoaminet110fisys"
 pre-up echo 2 > /proc/sys/net/ipv4/conf/eth1/force_igmp_version
 pre-up echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
 pre-up echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter
 pre-up echo 0 > /proc/sys/net/ipv4/conf/default/rp_filter

 up route add -net 224.0.0.0/4 eth1
 up route add -net 77.243.164.0/24 gw 10.30.128.1 eth1
 up route add -net 82.139.120.0/24 gw 10.30.128.1 eth1
 up route add -net 82.139.121.0/24 gw 10.30.128.1 eth1
 up route del default gw 10.30.128.1

Voorbeeld, na een reboot zijn dit mijn routes:

code:

david@ubuntu:~$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    10     0        0 eth0
10.30.128.0     0.0.0.0         255.255.224.0   U     0      0        0 eth1
77.243.164.0    10.30.128.1     255.255.255.0   UG    0      0        0 eth1
82.139.120.0    10.30.128.1     255.255.255.0   UG    0      0        0 eth1
82.139.121.0    10.30.128.1     255.255.255.0   UG    0      0        0 eth1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
224.0.0.0       0.0.0.0         240.0.0.0       U     0      0        0 eth1

Na ongeveer 2 a 2,5 uur heb ik dit ineens nog over (getest door op de bank af en toe route -n te doen dus ik weet het niet exact):

code:

david@ubuntu:~$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    10     0        0 eth0
0.0.0.0         10.30.128.1     0.0.0.0         UG    20     0        0 eth1
10.30.128.0     0.0.0.0         255.255.224.0   U     0      0        0 eth1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

Ik heb op de Windows 2008 host al uitgezet dat windows de netwerkkaart mag uitzetten om energie te besparen, maar dat heeft niet geholpen. Ik kan in Ubuntu verder niet iets van power management vinden (ben ook Linux n00b). Hebben jullie misschien een idee hoe ik dit op kan lossen?

[Kees]

Heeft je dhcp toevallig een ttl van 2 uur?

[sig69]

Geen idee, hoe zie ik dat? Moet ik dat even na een reboot bekijken dan?

[ Voor 46% gewijzigd door sig69 op 16-05-2014 19:08 ]

[Hero of Time]

Op zich zie je dat soort meldingen ook wel in /var/log/syslog langskomen. Net even gekeken in een VM (heb zelf statisch op m'n systemen hier) en zie bij boot het volgende:

code:

dhclient: bound to <IP adres> -- renewal in 40423 seconds.

Waarbij natuurlijk die 40423 de leasetime is.

Edit:
Oh, briljant, bedenk mij net de oplossing voor je. Lees even de manpage van dhclient.conf hoe het precies ziet, maar je kan namelijk de default gateway optie negeren om toe te laten passen en extra routes appenden aan wat je krijgt.

Default GW uit en routes toevoegen. Succes.

[ Voor 41% gewijzigd door Hero of Time op 16-05-2014 20:46 ]

[sig69]

Ik heb de links bekeken en doorgelezen, maar ik snap echt helemaal niks van wat daar allemaal staat...
Dit staat in mijn syslog na een reboot:

code:

May 17 16:55:24 ubuntu dhclient: bound to 10.30.134.199 -- renewal in 1527 seconds.

[Hero of Time]

Nou, 1527 seconden. Dat is dus 1527 / 60 ~ 25 minuten. Dat lijkt mij nogal stug dat dat je leasetime is. Check je router, daar heb je de mogelijkheid om dat aan te passen. In de mijne, een Asus AC66U, zie ik het volgende:

code:

Lease Time  86400

Dat is 24 uur.

Je zal overigens die renewal entry vaker moeten zien, aangezien het zichzelf vernieuwd. Elke keer als dat gebeurt, wordt er een melding van gemaakt.

[plizz]

Kan je de routes niet permanent maken? Dan blijft routes in de route tabel ook als de dhcp lease tijd voorbij is. Misschien helpt deze artikel jouw probleem.
http://www.ubuntugeek.com...tic-routes-in-ubuntu.html

[sig69]

@Hero of Time: tsja het staat er echt. Meerdere ook zoals je zei je ook. Ik heb geen controle over de router want het is het iptv netwerk.

@plizz: dat heb ik toch ook? Zie mijn eerste post. Dat is juist het hele punt: de routes zouden permanent moeten zijn maar verdwijnen toch.

[Hero of Time]

Dus als je een uptime hebt van 2 uur zijn je routes weg? Niet na een half uur, niet na een uur of anderhalf, maar echt na 2 uur connectiviteit? Dan moet er iets op je systeem mee draaien die dat veroorzaakt. Als het kan, draai eens dhclient in de voorgrond, ipv als daemon. Eventuele uitvoer zou je in de shell moeten zien.

[Brahiewahiewa]

Kun je die routes niet via DHCP meegeven?
Dan is een DHCP-refresh in ieder geval geen probleem meer...

[Berkeley]

http://serverfault.com/qu...ault-gateway-sporadically <- Lijkt dit niet erg veel op jou probleem?

[Hero of Time]

Brahiewahiewa schreef op zondag 18 mei 2014 @ 16:27:
Kun je die routes niet via DHCP meegeven?
Dan is een DHCP-refresh in ieder geval geen probleem meer...

Hij beheert de DHCP server niet. Dat is o.a. het probleem.

[Thc_Nbl]

haal deze uit je script interface:
up route del default gw 10.30.128.1

en stop deze in rc.local
ip route add default gw 10.30.128.1

[Hero of Time]

Hij wil geen default gateway, die komt van de DHCP af is zit in de weg voor z'n IPTV. Waarom zou je 'm dan in rc.local zetten om toe te voegen als je 'm helemaal niet wilt?

* Hero of Time ziet oplossingen voor problemen die er niet zijn en 'oplossingen' die meer problemen veroorzaken.

[sig69]

Hero of Time schreef op zondag 18 mei 2014 @ 11:20:
Dus als je een uptime hebt van 2 uur zijn je routes weg? Niet na een half uur, niet na een uur of anderhalf, maar echt na 2 uur connectiviteit? Dan moet er iets op je systeem mee draaien die dat veroorzaakt. Als het kan, draai eens dhclient in de voorgrond, ipv als daemon. Eventuele uitvoer zou je in de shell moeten zien.

Ongeveer twee uur lijkt op ja. Ik heb zojuist nog een reboot gedaan, ik zal het even in de gaten houden om het te bevestigen.

[dinux]

Werkt IPTV niet met IGMP? Volgens mij wel, vaak is er dan na een x aantal minuten een nieuwe IGMP membership request nodig om de verbinding aan te houden, gebeurd dit niet dan stopt de packet flow. Ik weet zosnel niet of dat ook zou leiden tot het uitvallen van routes, maar ik kan me een verband voorstellen.

[u_nix_we_all]

Ik denk ook dat je het in IGMP moet zoeken. Het lijkt erop dat die een nieuwe default route propageert, kan dat uberhaupt ? nevermind, IGMP != IGRP

[ Voor 12% gewijzigd door u_nix_we_all op 19-05-2014 18:07 ]

[sig69]

Gisteren ben ik er door drukte op het werk niet meer aan toe gekomen helaas, zojuist weer een reboot gedaan en ga de logging een beetje in de gaten proberen te houden.

Edit: ok hij draait nu twee ur en een beetje en mijn routes zijn weg. Dit is mijn /var/log/syslog:

code:

May 20 11:39:14  dhclient: last message repeated 4 times
May 20 11:40:14  dhclient: last message repeated 4 times
May 20 11:41:14  dhclient: last message repeated 3 times
May 20 11:42:14  dhclient: last message repeated 4 times
May 20 11:43:14  dhclient: last message repeated 4 times
May 20 11:44:06  dhclient: last message repeated 3 times
May 20 11:44:06 ubuntu dhclient: DHCPREQUEST of 10.30.134.199 on eth1 to 255.255.255.255 port 67
May 20 11:45:07  dhclient: last message repeated 4 times
May 20 11:46:08  dhclient: last message repeated 4 times
May 20 11:47:15  dhclient: last message repeated 4 times
May 20 11:48:15  dhclient: last message repeated 4 times
May 20 11:49:15  dhclient: last message repeated 4 times
May 20 11:50:15  dhclient: last message repeated 4 times
May 20 11:50:53  dhclient: last message repeated 3 times
May 20 11:50:53 ubuntu dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 3
May 20 11:50:53 ubuntu dhclient: DHCPREQUEST of 10.30.134.199 on eth1 to 255.255.255.255 port 67
May 20 11:50:53 ubuntu dhclient: DHCPOFFER of 10.30.134.199 from 10.30.128.1
May 20 11:50:53 ubuntu dhclient: DHCPACK of 10.30.134.199 from 10.30.128.1
May 20 11:50:53 ubuntu dhclient: bound to 10.30.134.199 -- renewal in 1433 seconds.

Het enige wat mij opvalt is dat hij ineens een DHCPDISCOVER doet, maar weet niet of het er iets mee te maken heeft.

[ Voor 81% gewijzigd door sig69 op 20-05-2014 12:12 ]

[lordgandalf]

DHCPDISCOVER zou niet moeten gebeuren na die tijd imho.
hij zou gelijk een DHCPREQUEST moeten doen aangezien hij een huidig ip wil hergebruiken niet een nieuw ip wil aanvragen.
En daarop zou hij een DHCPACK of DHCPNACK moeten krijgen ack als het goed is en dan houd hij het ip of nack als het verkeerd is en dan stuurd hij een dhcp discover.
Wat me opvalt is deze regels

code:

May 20 11:44:06 ubuntu dhclient: DHCPREQUEST of 10.30.134.199 on eth1 to 255.255.255.255 port 67
May 20 11:45:07  dhclient: last message repeated 4 times

Lijkt erop dat de dhcp server je niet aardig vind want je doet netjes je DHCPREQUEST maar krijgt geen antwoord en doet het nog eens 4x

[ Voor 11% gewijzigd door lordgandalf op 21-05-2014 10:35 ]

[sig69]

Voor de zekerheid heb ik het zojuist vanochtend nog een keer getest en inderdaad, DHCPDISCOVER -> routes weg

[Kees]

Dat was dus ook wat ik eigenlijk met de eerste vraag bedoelde. Het is waarschijnlijk het makkelijkste als je de routes in een exit-hook toevoegt (geen idee wanneer die precies draait, dus mischien moet je eerst checken of de router er nog zijn).

[Brahiewahiewa]

Kees schreef op woensdag 21 mei 2014 @ 13:11:
Dat was dus ook wat ik eigenlijk met de eerste vraag bedoelde. Het is waarschijnlijk het makkelijkste als je de routes in een exit-hook toevoegt (geen idee wanneer die precies draait, dus mischien moet je eerst checken of de router er nog zijn).

Het lijkt mij beter om te achterhalen waarom de DHCP server niet reageert op een DHCPrequest
(of dat-ie dat wel doet, maar het antwoord nooit bij de client aankomt)

[lordgandalf]

met ^ het is niet gezond als een dhcp server geen response geeft of hebben ze de server gelocked op bepaalde macs dat zijn vragen die eerst beantwoord moeten worden.
Kun je een capture maken van het netwerk verkeer op de interface ?

[sig69]

Brahiewahiewa schreef op woensdag 21 mei 2014 @ 13:27:
[...]

Het lijkt mij beter om te achterhalen waarom de DHCP server niet reageert op een DHCPrequest
(of dat-ie dat wel doet, maar het antwoord nooit bij de client aankomt)

Dat zou ik graag doen, maar hoe?

lordgandalf schreef op woensdag 21 mei 2014 @ 14:48:
met ^ het is niet gezond als een dhcp server geen response geeft of hebben ze de server gelocked op bepaalde macs dat zijn vragen die eerst beantwoord moeten worden.
Kun je een capture maken van het netwerk verkeer op de interface ?

Het mac adres van eth1 is hetzelfde als van mijn settopbox (ingesteld in Hyper-V). Zou gewoon moeten werken volgens het IPTV topic. En het werkt ook wel, alleen na twee uur niet meer...
Ik heb even wat gegoogeld, is een capture met tcpdump goed genoeg? En waar wil je een capture van? Als ik m'n routes nog heb of als ze verdwenen zijn?

[ Voor 8% gewijzigd door sig69 op 22-05-2014 11:09 ]

[Kees]

Brahiewahiewa schreef op woensdag 21 mei 2014 @ 13:27:
[...]

Het lijkt mij beter om te achterhalen waarom de DHCP server niet reageert op een DHCPrequest
(of dat-ie dat wel doet, maar het antwoord nooit bij de client aankomt)

Het is de DHCP server van het tv-vlan op het glasvezel netwerk van glashart (i assume). Daar kun je niet veel zelf aan debuggen en mocht je het al aangeven dan zullen ze zeggen dat het geen probleem is want de normale Amino/settopbox kan er prima mee overweg. Ze ondersteunen waarschijnlijk niet officieel deze manier van tv kijken (vooral ook omdat de laatste keer dat ik het controleerde alle tv streams unencrypted over de lijn kwamen en je dus alles kon zien, inc de paytv zenders).

Dus nee, de DHCP server debuggen gaat je niet helpen, aan de ene kant niet omdat deze setup niet supported is, aan de andere kant niet omdat hij de server niet in beheer heeft.

Het is dus meer zinvol om tijd te steken in het omzeilen van deze situatie dan het voorkomen ervan. En in dit geval zou ik gewoon met DHCP exit hooks gaan spelen.

[Brahiewahiewa]

Ik zou toch wel even willen weten of de DHCPserver een antwoord stuurt op het request.
Als dat niet het geval is, is het einde oefening; gaan we workarounds toepassen.

Besides, vziw komt ubuntu met meerdere DHCPclients. Er wordt nu DHCLIENT gebruikt; die zou je kunnen vervangen door een alternatief

[lordgandalf]

Brahiewahiewa schreef op donderdag 22 mei 2014 @ 13:51:
Ik zou toch wel even willen weten of de DHCPserver een antwoord stuurt op het request.
Als dat niet het geval is, is het einde oefening; gaan we workarounds toepassen.

Besides, vziw komt ubuntu met meerdere DHCPclients. Er wordt nu DHCLIENT gebruikt; die zou je kunnen vervangen door een alternatief

Wil ook wel weten wat zijn dhcp server probeert op het moment dat zijn dhcp aan de crap gaat en vooral waarom.

[sig69]

Ik heb een tcpdump vanaf boot tot het moment dat de routes verdwijnen (na de DHCPDISCOVER), ongeveer twee uur dus. Ik heb 'm geopend met wireshark, maar heb geen idee waar ik naar zit te kijken.. Zou een van jullie eens willen kijken? Hij staat hier (68KB). Ik had ook m'n /var/log/syslog open staan:

code:

## Start tcpdump
May 22 19:36:44 ubuntu kernel: [  266.536511] device eth1 entered promiscuous mode
## Deze lijkt goed te gaan
May 22 19:56:37 ubuntu dhclient: DHCPREQUEST of 10.30.134.199 on eth1 to 82.139.121.178 port 67
May 22 19:56:37 ubuntu dhclient: DHCPACK of 10.30.134.199 from 82.139.121.178
May 22 19:56:37 ubuntu dhclient: bound to 10.30.134.199 -- renewal in 1613 seconds.
May 22 20:17:01 ubuntu CRON[2275]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
## Deze gaat niet goed
May 22 20:23:30 ubuntu dhclient: DHCPREQUEST of 10.30.134.199 on eth1 to 82.139.121.178 port 67
May 22 20:24:01  dhclient: last message repeated 5 times
May 22 20:25:04  dhclient: last message repeated 4 times
May 22 20:26:05  dhclient: last message repeated 5 times
May 22 20:27:05  dhclient: last message repeated 4 times
May 22 20:28:05  dhclient: last message repeated 4 times
May 22 20:29:05  dhclient: last message repeated 4 times
May 22 20:30:05  dhclient: last message repeated 5 times
May 22 20:31:05  dhclient: last message repeated 4 times
May 22 20:32:05  dhclient: last message repeated 4 times
May 22 20:33:05  dhclient: last message repeated 4 times
May 22 20:34:05  dhclient: last message repeated 5 times
May 22 20:35:05  dhclient: last message repeated 6 times
May 22 20:36:06  dhclient: last message repeated 4 times
May 22 20:37:06  dhclient: last message repeated 4 times
May 22 20:38:06  dhclient: last message repeated 3 times
May 22 20:39:06  dhclient: last message repeated 5 times
May 22 20:40:06  dhclient: last message repeated 4 times
May 22 20:41:06  dhclient: last message repeated 6 times
May 22 20:42:06  dhclient: last message repeated 3 times
May 22 20:43:06  dhclient: last message repeated 5 times
May 22 20:44:06  dhclient: last message repeated 6 times
May 22 20:44:53  dhclient: last message repeated 2 times
## Deze gaat naar 255.255.255.255? Weet niet of dat hoort maar hij gaat wel goed zo te zien
May 22 20:44:53 ubuntu dhclient: DHCPREQUEST of 10.30.134.199 on eth1 to 255.255.255.255 port 67
May 22 20:44:53 ubuntu dhclient: DHCPACK of 10.30.134.199 from 10.30.128.1
May 22 20:44:53 ubuntu dhclient: bound to 10.30.134.199 -- renewal in 1354 seconds.
## Deze weer niet
May 22 21:07:27 ubuntu dhclient: DHCPREQUEST of 10.30.134.199 on eth1 to 82.139.121.178 port 67
May 22 21:08:38  dhclient: last message repeated 5 times
May 22 21:09:38  dhclient: last message repeated 5 times
May 22 21:10:38  dhclient: last message repeated 4 times
May 22 21:11:38  dhclient: last message repeated 3 times
May 22 21:12:38  dhclient: last message repeated 5 times
May 22 21:13:39  dhclient: last message repeated 4 times
May 22 21:14:39  dhclient: last message repeated 5 times
May 22 21:15:39  dhclient: last message repeated 5 times
May 22 21:16:39  dhclient: last message repeated 4 times
May 22 21:17:01  dhclient: last message repeated 2 times
May 22 21:17:01 ubuntu CRON[2500]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
## Deze ook niet
May 22 21:17:14 ubuntu dhclient: DHCPREQUEST of 10.30.134.199 on eth1 to 82.139.121.178 port 67
May 22 21:18:19  dhclient: last message repeated 4 times
May 22 21:19:21  dhclient: last message repeated 5 times
May 22 21:20:24  dhclient: last message repeated 7 times
May 22 21:21:31  dhclient: last message repeated 5 times
May 22 21:22:39  dhclient: last message repeated 5 times
May 22 21:23:39  dhclient: last message repeated 5 times
May 22 21:24:39  dhclient: last message repeated 5 times
May 22 21:25:40  dhclient: last message repeated 4 times
May 22 21:26:40  dhclient: last message repeated 4 times
May 22 21:27:40  dhclient: last message repeated 5 times
May 22 21:28:40  dhclient: last message repeated 3 times
May 22 21:29:40  dhclient: last message repeated 5 times
May 22 21:30:40  dhclient: last message repeated 3 times
May 22 21:31:40  dhclient: last message repeated 4 times
May 22 21:32:40  dhclient: last message repeated 6 times
## Nu naar zowel 82.139.121.178 als 255.255.255.255
May 22 21:32:47 ubuntu dhclient: DHCPREQUEST of 10.30.134.199 on eth1 to 82.139.121.178 port 67
May 22 21:33:01 ubuntu dhclient: DHCPREQUEST of 10.30.134.199 on eth1 to 255.255.255.255 port 67
May 22 21:34:09  dhclient: last message repeated 5 times
May 22 21:35:10  dhclient: last message repeated 4 times
May 22 21:36:10  dhclient: last message repeated 4 times
May 22 21:37:11  dhclient: last message repeated 4 times
May 22 21:38:11  dhclient: last message repeated 4 times
May 22 21:39:11  dhclient: last message repeated 4 times
May 22 21:39:54  dhclient: last message repeated 2 times
## Na deze DHCPDISCOVER zijn m'n routes weg
May 22 21:39:54 ubuntu dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 3
May 22 21:39:54 ubuntu dhclient: DHCPREQUEST of 10.30.134.199 on eth1 to 255.255.255.255 port 67
May 22 21:39:54 ubuntu dhclient: DHCPOFFER of 10.30.134.199 from 10.30.128.1
May 22 21:39:54 ubuntu dhclient: DHCPACK of 10.30.134.199 from 10.30.128.1
May 22 21:39:54 ubuntu dhclient: bound to 10.30.134.199 -- renewal in 1583 seconds.
## Einde tcpdump
May 22 21:40:18 ubuntu kernel: [ 7680.390041] device eth1 left promiscuous mode

[ Voor 89% gewijzigd door sig69 op 22-05-2014 21:53 ]

[lordgandalf]

DHCP server 1: 82.139.121.178
DHCP server 2: 10.30.128.1

De DHCP naar 255.255.255.255 is goed hij stuurt een broadcast met het verzoek alle DHCP servers op het netwerk offer mij een IP. En dan gaan er dhcp servers reageren

Regel 32-35 gaat je dhcp request goed en krijg je een ip van 10.30.128.1
Regel 50 gaat hij na een uur een ip vragen aan 82.139.121.178 (waarom ?)
Regel 77 vreemd dat hij hier pas stuk gaat vermoedelijk omdat hij dan geen dhcp meer kan krijgen en de lease afloopt

Zal vanaaf als ik tijd heb even in de capture gaan grasduinen

[Brahiewahiewa]

't Heeft even geduurd, maar ik snap nu - geloof ik - wat je probeert te doen:
Je hebt een (virtuele) PC met één netwerk kaart waarop je twee IP-adressen wilt. Eentje voor internet en wat dies meer zij, dat moet via je eigen router op het 192.168.1.0/24 segment. En eentje voor IPTV in het 10.30.128.0/18 segment. En omdat de default gateway van die laatste je internet in de war gooit, verwijder je 'm en voeg je handmatig de routes toe die je voor IPTV nodig hebt

En dat blijkt allemaal (onverwacht, wat mij betreft) goed te gaan zolang je NIC er maar in slaagt om z'n IP-lease te refreshen. Maar als die refresh niet lukt gaat er een DHCP discover sequence gebeuren met als netto resultaat dat je route tabel gereset wordt. Wat - op zich - logisch is, vanuit het perspectief van de DHCP client

En nu heb jij de pech dat je IP-provider van z'n DHCP back-end een zooitje heeft gemaakt, waardoor de DHCP-refresh niet werkt. Althans, vooruitlopend op ndeleeuw's bevindingen, is er inderdaad sprake van twee DHCP servers, maar dan beiden op het back-end.
10.130.128.1 is een DHCP relay agent maar die forwardt DHCP ack's van zowel 82.139.121.178 als van 82.139.121.162 (frame 4610 en 4611)

[sig69]

Nou het is "opgelost". Gisteravond verveelde ik me dus heb ik even een Ubuntu 14 installatie gedaan, dezelfde settings als mijn Ubuntu 12 machine, en ik heb nu nog steeds m'n routes na 13 uur! Het log ziet er ook netjes uit, geen rare meldingen meer. Geen idee wat het nou was maar vind het wel prima

[Brahiewahiewa]

Andere DHCP-client, schat ik zo

[Hero of Time]

Nee, nieuwere versie.

[Raven]

Misschien een idee om in de changelogs van de dhcp-client te kijken om erachter te komen of er iets relevants gefixed is?

[Rainmaker]

Het is vrij logisch dat de DHCP client de routes weggooid; hij verwacht nieuwe van de server...

Probeer anders in dhclient.conf een een specifieke lease time aan de server te vragen:

code:

send dhcp-lease-time 86400;

of uit "request" "routers" weghalen en zelf een route add default gw draaien.

request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, domain-search, host-name,
dhcp6.name-servers, dhcp6.domain-search,
netbios-name-servers, netbios-scope, interface-mtu,
rfc3442-classless-static-routes, ntp-servers,
dhcp6.fqdn, dhcp6.sntp-servers;

Als dit niet werkt, zit ik toch te denken aan een probleem op de DHCP server. Kun je weinig aan doen, maar wat je kan proberen is eens met een alternatief MAC adres (wellicht een ARP issue op de server door een duplicate MAC).

/edit: Hmm, er was een pagina 2
Blij dat het "opgelost" is in ieder geval.

[ Voor 4% gewijzigd door Rainmaker op 27-05-2014 23:54 ]

[sig69]

Ja het werkt nu probleemloos. Toch bedankt voor de moeite