Gateway niet gevonden bij verkeer via Subnet (WinServer)

[.Gertjan.]

Ik zit met een probleempje op een van mijn servers (hosted via Hetzner) waar ik zelf niet echt meer uit kom. Ik heb contact gehad met de support desk van Hetzner, maar zij vinden het een software/configuratie probleem en zeggen min of meer dat ik het maar zelf moet uitzoeken. De help functie van Hetzner levert weinig resultaten op en lijkt meer geschreven te zijn voor Linux/BSD systemen. Windows is schijnbaar niet erg “bekend” binnen hetzner. Het enige waar ze mij mee op weg wilde helpen is het verwijzen naar ARP. Daar heb ik naar zitten kijken maar het heeft nog niet echt geholpen.

Het probleem is als volgt. Op de gehuurde server (dedicated) hebben we een IP adres toegewezen gekregen (144.76.x.y), hierbij is ook een gateway aangewezen (144.76.65.161). Dit werkt allemaal prima. Echter hebben wij het verzoek ingediend om meerdere IP adressen te krijgen, hierbij is een subnetje toegewezen (in de 78.47.a.b reeks). Deze IP adressen zijn toegevoegd aan de netwerk settings en lijken op het eerste oog te werken.

De settings van de adapter:

code:

IP Address:                           144.76.x.y
Subnet Prefix:                        144.76.x.0/24 (mask 255.255.255.0)
IP Address:                           78.47.a.b
Subnet Prefix:                        78.47.a.b/32 (mask 255.255.255.255)

IP Address:                           78.47.a.c
Subnet Prefix:                        78.47.a.c/32 (mask 255.255.255.255)

Default Gateway:                      144.76.65.161
Gateway Metric:                       1
InterfaceMetric:                      10

etc

Echter treed er na verloop van tijd vreemd gedrag op op de ip’s in het subnet. Na een aantal minuten inactiviteit raken deze onbereikbaar. De site die er op draait werkt niet, maar ook een ping geeft geen resultaat. Na een ping het primaire ip (de 144) werken IP’s in het subnet wel weer. We hebben ook ontdekt dat zolang er een verbinding open staat (via bijv ping –t of rdp) de subnets blijven werken, maar om via een andere server een ping –t te doen is natuurlijk een beetje hacky

Toen we hetzner confronteerde met dit verhaal gaven ze aan dat zij een strikte koppeling van MAC en IP hanteerde en dat we het met die informatie maar verder moesten uitzoeken. Vervolgens hebben we wat zitten “spelen” met het vastleggen van IP/ARP koppelingen maar niets hielp.

Een tijdje geleden heb ik wireshark eens laten meelopen en ontdekte het volgende: de ping requests komen wel binnen op het subnet en de server probeert de gateway op te vragen. Dit doet hij echter via een van de subnet adressen. In het screenshot zie je dan ook een request voor de gateway met als response adres het subnet. Hier wordt echter niet op gereageerd. Als ik vervolgens een ping naar het primaire ip stuur komt dezelfde broadcast request nogmaals maar dan met een Tell 144 (dus het primaire adres), hierop volgt een directe response en er wordt een ping reply verzonden. Op dat moment gaan ook direct de ping reply’s van het subnet goed. Het lijkt er dus op dat de machine zijn gateway “vergeet” na verloop van tijd en deze enkel kan opvragen via het primaire adres. Dit verklaart waarom de boel blijft werken op het primaire adres en waarom het subnet ook weer reageert zodra het primaire adres is aangesproken.



Maar nu natuurlijk de hamvraag, hoe krijg ik windows zo ver om ook het subnet goed te laten werken. Er waren voor mij een aantal opties, de eerste is het mac-adres van de gateway vastpinnen, dit lijkt mij gevaarlijk (stel dat de gateway vervangen wordt, dan is de machine onbereikbaar) en dit leek niet mogelijk (ik krijg een foutmelding als ik dat doe via het arp commando). Een andere oplossing zou zijn dat het systeem wel luistert naar het subnet maar al het verkeer over het primaire adres naar buiten gooit (dan gaat de broadcast voor de gateway ook goed), ik heb echter geen flauw idee waar ik dit kan instellen (en of dit het probleem oplost of mogelijk zelfs extra problemen oplost). Ook spelen met de subnet masks leek niets uit te halen (we hadden het vermoeden dat het subnet mask er voor zorgde dat de gateway request vanuit de 78 ip’s niet goed ging).

Er loopt hier vast wel iemand rond die hier iets zinnigs over kan zeggen. Onze vorige hoster gaf ons ook extra ip’s, maar daar hebben we nooit dit soort problemen gekend (daar kwamen de ip’s uit de zelfde range). Ik kan mijn weg redelijk vinden op Windows servers, maar dit gaat momenteel even mijn pet te boven. Advies is daarom zeer welkom

Mocht er meer informatie gewenst zijn hoor ik dit uiteraard graag!

Volgens mij moet dit probleem hier en niet in Professional Networking & Servers, zo wel hoor ik dat graag. Daarnaast twijfelde ik hoe ik dit probleem moest beschrijven in de titel, hopelijk is hij toch duidelijk genoeg.

[ Voor 6% gewijzigd door .Gertjan. op 27-05-2013 13:16 . Reden: Bijwerken van de adapter settings op verzoek ]

[Kabouterplop01]

Ik denk dat je een route moet instellen voor je nieuwe subnet, een default route naar de gateway.
(Al het verkeer wat niet herkend wordt moet naar de default gateway)
met een route print kun je zien welke routeringen er zijn berekend door het systeem. Met een route add (-p for persistency) kun je een route toevoegen.
als er geen default route is (route add -p 0.0.0.0 mask 0.0.0.0 144.76.65.161) dan denk ik dat je daar even mee moet stoeien!
route adddestinationmasksubnetmaskgatewaymetriccostmetricifinterface

[webfreakz.nl]

Die eerste 4 ARP requests doen ook aanvraag naar een indirecte gateway, logisch dat dit niet werkt.

Hoe is alles geconfigureerd? Zijn die 78.47.x.y adressen secundaire adressen?

Welke gateway heb je voor die 78.47.x.y adressen gekregen? Kan je die pingen met:

> ping $78.47-gateway -S 78.47.x.y

[.Gertjan.]

Kabouterplop01 schreef op zondag 26 mei 2013 @ 15:26:
Ik denk dat je een route moet instellen voor je nieuwe subnet, een default route naar de gateway.
(Al het verkeer wat niet herkend wordt moet naar de default gateway)
met een route print kun je zien welke routeringen er zijn berekend door het systeem. Met een route add (-p for persistency) kun je een route toevoegen.
als er geen default route is (route add -p 0.0.0.0 mask 0.0.0.0 144.76.65.161) dan denk ik dat je daar even mee moet stoeien!
route adddestinationmasksubnetmaskgatewaymetriccostmetricifinterface

Die default route stond er al in. Het probleem is denk ik ook niet zozeer dat het systeem de niet wist waar hij heen moest (je ziet hem ook de requests doen waar de gateway is) maar dat hij via het subnet de gateway niet kon vinden. Het systeem weet wel hoe hij naar buiten moet maar krijgt via de gateway request geen response. Zodra het mac adres van de gateway bekend is (dus is gevonden) werkt al het verkeer weer prima (ook via de subnet adresjes).

Ik heb net even wat zitten spelen met de routes (kijken of een route 78 -> primair iets zou uithalen) maar helaas lost dat niets op (of ik doe iets wat niet de bedoeling is).

webfreakz.nl schreef op zondag 26 mei 2013 @ 15:32:
Die eerste 4 ARP requests doen ook aanvraag naar een indirecte gateway, logisch dat dit niet werkt.

Wat versta je onder indirecte gateway?

Hoe is alles geconfigureerd? Zijn die 78.47.x.y adressen secundaire adressen?

Ik heb ze gewoon toegevoegd in de assigned ip adressen (zie screenshot in de openingspost). Ik ben niet op de hoogte van het verschil tussen primaire en secundaire adressen (of hoe je het kunt instellen).

Welke gateway heb je voor die 78.47.x.y adressen gekregen? Kan je die pingen met:

> ping $78.47-gateway -S 78.47.x.y

Helaas heb ik voor die adressen geen gateway gekregen. We kregen een IP range (met daarin 2 adressen die niet gebruikt mochten worden (het eerste en laatste)). Ik heb al een keertje geprobeerd het eerste adres uit de range op te geven als gateway, maar dat gaf geen resultaat.

[webfreakz.nl]

nvm.

[ Voor 98% gewijzigd door webfreakz.nl op 26-05-2013 16:14 ]

[.Gertjan.]

webfreakz.nl schreef op zondag 26 mei 2013 @ 16:09:
[...]


Wel heel vreemd dat je die niet gekregen hebt... Dat is de reden dat de eerste 4 ARP request falen.

Ik zal daar eens achteraan gaan.

Maar het vreemde is dat zodra de machine weet waar hij de 144 gateway kan vinden het verkeer over de 78 reeks wel goed lijkt te gaan (in het screenshot zie je dat na een ping op het 144 adres de andere pings ook ineens reageren).

Mijn kennis van netwerken houdt hier zo ongeveer wel op als ik eerlijk ben. Het lijkt erop dat er misschien iets geknutseld moet worden zodat windows het verkeer van de 78 adressen intern over het primaire adres stuurt (deze werkt namelijk altijd en kan wel de gateway vinden). Ik weet echter niet of dit kan of dat dit onzin is

[.Gertjan.]

Er schijnt geen gateway adres te worden uitgegeven. Men verwijst naar hun Wiki waarin dat staat uitgelegd:

Please read this article completely:
http://wiki.hetzner.de/index.php/Zusaetzliche_IP-Adressen/en

You should pay special attention to point 3 :
-----------------%<-----------------
Subnets are statically routed on the main IP address of the server, which is why no gateway is needed for the additional IP addresses. Therefore, all IP addresses, except the network address (first) and broadcast address (last), are usable. The router does not take up an IP address of the subnet.
-----------------%<-----------------

Echter wordt er niet uitgelegd hoe je dit fatsoenlijk in windows kunt inrichten. Het verkeer komt volgens Windows wel binnen op het 78 adres en hij zal namens dat adres willen reageren (en dus ook via dat adres proberen te achterhalen waar de gateway zich bevindt).

[.Gertjan.]

Het lijkt erop dat ik inmiddels de oplossing heb gevonden. Aan de hand van jullie feedback ben ik nog eens wat verder in het verhaal gedoken en het bleek dat de adressen uit het subnet moesten worden ingesteld als niet primair.

Op de een of andere manier heeft men in Windows 2008 R2 iets gedaan waardoor de voorkeur bij de IP's komt te liggen die "lager" zijn in plaats van de gene die als eerste is aangemaakt. Hierdoor had Windows op de een of andere manier de voorkeur bij de 78 adressen liggen. Wat zoekwerk op internet leerde mij dat het aan te raden was om de adressen niet via de GUI toe te voegen maar middels een netsh command. Het commando netsh int ipv4 add address "Local Area Connection" 78.47.a.b/24 SkipAsSource=true zorgde er voor dat de machine het 144 adres als hoofd adres ging beschouwen (uiteraard pas na een verplichte reboot ).

Bij route print toonde het systeem voorheen altijd de 78.x adressen als interface en nu staan daar netjes de 144 adressen. Een kleine analyse met wireshark laat zien dat de broadcasts voortaan altijd lijken te verlopen via de 144 (ook bij een ping op de 78 range). Het lijkt er dus op dat het probleem is opgelost.
Overigens waren er voorheen ook geregeld invalid vermeldingen in de arp tabel, op de een of andere manier zat het dus echt niet lekker in het systeem

De route print geeft nu netjes:

code:

Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0    144.76.65.161    144.76.x.y     11
     78.47.a.b  255.255.255.255         On-link     144.76.x.y    266
     78.47.a.c  255.255.255.255         On-link     144.76.x.y    266

Voorheen stond onder de interface het 78 adres en ontbraken de onlink vermeldingen. Het verkeer lijkt nu netjes over de 144 te gaan

Ik kan technisch nog niet helemaal verklaren/vertellen wat er nu is opgelost en vooral waarom, maar het lijkt nu goed te werken, de ip's in het subnet blijven reageren zonder problemen.

Bronnen:
http://www.confusedamused...th-multiple-ips-on-a-nic/
http://social.technet.mic...d-48d5-b408-62530b628940/
http://blogs.technet.com/...med-windows-computer.aspx

Allen dank voor de input
Leek mij wel netjes om even de oplossing te plaatsen, heb zelf ook een hekel aan het lezen van een probleem waarop gepost wordt "Ik ben er al uit" zonder een oplossing. http://xkcd.com/979/

edit:

Helaas heeft dit het probleem maar tijdelijk verholpen. Om 23:23 gisteren nacht is de boel alsnog in de soep gelopen...

[laurens0619]

Je hebt helemaal gelijk. Je moet ze via netsh met die parameter toevoegen anders pakt Windows 2008 als uitgaand ip adres het adres wat het dichste bij de gateway ligt. Echter jouw verhaal lijkt daar niet mee te rijmen dus vaag...

[.Gertjan.]

laurens0619 schreef op zondag 26 mei 2013 @ 21:14:
Je hebt helemaal gelijk. Je moet ze via netsh met die parameter toevoegen anders pakt Windows 2008 als uitgaand ip adres het adres wat het dichste bij de gateway ligt. Echter jouw verhaal lijkt daar niet mee te rijmen dus vaag...

Dat het verhaal niet helemaal rijmt blijkt helaas te kloppen. Na een paar uur correct draaien is de boel vannacht toch nog een aantal keer omver gevallen volgens de monitoring tool.
Ik was gisteren natuurlijk blij dat de boel werkte, maar helaas weer te vroeg gejuicht

Na een paar uur zonder problemen te hebben gedraaid begon de ellende vannacht weer en leek het om het half uur terug te komen. Dan krijgt de monitoring een aantal keer een time-out om vervolgens na enkele minuten weer verbinding te krijgen. Wat er gebeurt zodra er weer verbinding ontstaat is mij nu nog even onbekend. Er lijkt in ieder geval een patroon zichtbaar (kan natuurlijk ook met de monitoring interval te maken hebben), maar in de logs zie ik dat hij voor het eerst offline knalde rond +/- 23:23, daarna een paar minuten plat blijft (wat ook een aantal tussen checks markeert als failed) om vervolgens rond 23:37 weer tot leven te komen. Dit patroon lijkt zich te herhalen waarbij de tijd steeds iets korter is dan een uur (de laatste om was iets over 6).

Conclusie: het werk nog steeds niet naar behoren... Het oude gedrag is dus weer vrolijk terug... Net lag het handeltje even plat maar een pingetje naar het main IP loste de ellende weer (tijdelijk) op. Waarom de boel tot 23:23 correct is blijven werken vind ik behoorlijk vaag, er draaide voor zover ik weet geen processen die het main IP in de gaten hielden, dus wat daar is gebeurd is mij een raadsel.

Mocht iemand alsnog een briljant idee hebben (evt gebaseerd op de andere antwoorden) hoor ik dit graag. Inmiddels heb ik de neiging mijn verlies te nemen en die server daar op te doeken. De helpdesk van Hetzner blijft naar hun Wiki wijzen, maar rept daar geen woord over Windows...

[Oid]

wat zegt dit commando dan? Laat die de juiste skip waardes zien?

netsh int ipv4 show ipaddresses level=verbose

komt uit een van de artikelen die je noemt.

[.Gertjan.]

Oid schreef op maandag 27 mei 2013 @ 09:01:
wat zegt dit commando dan? Laat die de juiste skip waardes zien?

netsh int ipv4 show ipaddresses level=verbose

komt uit een van de artikelen die je noemt.

Ze staan allemaal op skip

code:

Address 78.47.a.b Parameters
---------------------------------------------------------
Interface Luid     : Local Area Connection
Scope Id           : 0.0
Valid Lifetime     : infinite
Preferred Lifetime : infinite
DAD State          : Preferred
Address Type       : Manual
Skip as Source     : true

Address 78.47.a.c Parameters
---------------------------------------------------------
Interface Luid     : Local Area Connection
Scope Id           : 0.0
Valid Lifetime     : infinite
Preferred Lifetime : infinite
DAD State          : Preferred
Address Type       : Manual
Skip as Source     : true

Address 144.76.x.y Parameters
---------------------------------------------------------
Interface Luid     : Local Area Connection
Scope Id           : 0.0
Valid Lifetime     : infinite
Preferred Lifetime : infinite
DAD State          : Preferred
Address Type       : Manual
Skip as Source     : false

Helaas zonder het gewenste resultaat...

[Z-Dragon]

Aangezien Hetzner blijkbaar Unix-georiënteerd is, zou ik het proberen wat meer in te stellen zoals op Unix (in elk geval op FreeBSD) gebruikelijk is. Dat betekent voor het primaire adres het subnet dat je gekregen hebt, en voor alle andere adressen (aliassen) 255.255.255.255. (Je mag een subnet altijd nauwer maken en in dit geval beperk je het tot een hostadres.) Al het uitgaande verkeer komt dan van het primaire adres. Het enige nut van een ruimer subnet is dat je dan andere hosts binnen dat subnet zou kunnen bereiken zonder via de gateway te gaan, maar in zo'n geval heb je extra interfaces nodig in plaats van aliassen.

[ Voor 20% gewijzigd door Z-Dragon op 27-05-2013 10:14 ]

[HMS]

Heb je hier iets aan? Is voor het instellen van een alternatief IP adres bij een andere hoster, maar die levert iig wel een handleiding voor Windows Server 2008 aan

http://help.ovh.co.uk/IpAlias#link12

[Z-Dragon]

Dat lijkt te bevestigen wat ik zojuist schreef. Zelf net ook nog even door de Hetzner-wiki gekeken en ook daar gebruikt men steevast /32 (= 255.255.255.255) voor aliassen. Het feit dat je een subnet hebt toegewezen gekregen, zegt alleen dat je die adressen ter beschikking hebt; niet dat je dat ook als masker moet gebruiken.

[markvt]

Hoe staat de metric, automatisch of heb je die zelf ingesteld?

[.Gertjan.]

Z-Dragon schreef op maandag 27 mei 2013 @ 10:07:
Aangezien Hetzner blijkbaar Unix-georiënteerd is, zou ik het proberen wat meer in te stellen zoals op Unix (in elk geval op FreeBSD) gebruikelijk is. Dat betekent voor het primaire adres het subnet dat je gekregen hebt, en voor alle andere adressen (aliassen) 255.255.255.255. (Je mag een subnet altijd nauwer maken en in dit geval beperk je het tot een hostadres.) Al het uitgaande verkeer komt dan van het primaire adres. Het enige nut van een ruimer subnet is dat je dan andere hosts binnen dat subnet zou kunnen bereiken zonder via de gateway te gaan, maar in zo'n geval heb je extra interfaces nodig in plaats van aliassen.

Goed punt, nadat ik eerst een kleine fout maakte en de server helemaal omver trok heb ik nu het subnet wat krapper gemaakt. Het was mij in de voorbeelden niet eens opgevallen (mede ook omdat ik ze niet helemaal begreep). Kijken of dit (icm de SkipAsSource) de boel oplost.

In heb voorheen wel wat zitten spelen met het subnet, maar toen maakte ik het juist breder (255.0.0.0 en 255.255.255.0).

Overigens ben ik het volledig met je opmerking in de DevSchuur eens dat ik eigenlijk niet slim bezig ben door me nu te begeven op een vlak wat onbekend is, maar ik wil het wel leren. Echter kwamen er nu net iets te veel zaken op mij af en probeerde ik teveel dingen tegelijk Slechte troubleshoot-eigenschap, eigenlijk moet je stapje voor stapje proberen...

Probleem zit waarschijnlijk aan mijn kant (hoewel ik de stugge houding van Hetzner wel jammer vind, maar aan de andere kant ook begrijpelijk). Het verhuizen naar een andere partij lost mijn knowledge-gap niet op en is mogelijk enkel het verplaatsen van het probleem

markvt schreef op maandag 27 mei 2013 @ 11:02:
Hoe staat de metric, automatisch of heb je die zelf ingesteld?

Op welke metric doel je? Voor zover ik kan zien in de instellingen is alles automatic metric.

[markvt]

An explanation of the Automatic Metric feature for Internet Protocol routes

Heb zelf weleens een soortgelijk issue gehad waarbij de verkeerde 'nic' gebruikt werd door de automatische metric.

[.Gertjan.]

markvt schreef op maandag 27 mei 2013 @ 12:26:
An explanation of the Automatic Metric feature for Internet Protocol routes

Heb zelf weleens een soortgelijk issue gehad waarbij de verkeerde 'nic' gebruikt werd door de automatische metric.

Kan er wel eens naar kijken, maar we hebben maar 1 nic (en 1 gateway) dus ik vermoed dat dat niet het probleem is.

[.Gertjan.]

Helaas heeft het niet geholpen

Na verloop van tijd raakt hij het adres van de gateway kwijt uit de ARP cache. Als ik een ping doe naar een adres in het subnet zie ik nog steeds in wireshark de melding:
Who has 144.76.65.161? Tell 78.47.a.b
Een ping op het hoofd ip zorgt er voor dat de request wordt verzonden vanuit het primaire adres en er wel een response komt. Maar op de een of andere manier blijft hij het verkeer vanaf het subnet dus verwerken namens dat adres waardoor de gateway niet gevonden kan worden.

De subnet adressen zijn allemaal aangemaakt met subnetmask 255.255.255.255 en zijn ingesteld als SkipAsSource=true. In de route tabel worden ze ook vermeld als on-link:

code:

Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0    144.76.65.161    144.76.x.y     11
     78.47.a.b  255.255.255.255         On-link     144.76.x.y    266
     78.47.a.b  255.255.255.255         On-link     144.76.x.y    266

Begin er steeds minder van te begrijpen

[Z-Dragon]

Is het mogelijk om zo veel mogelijk op te ruimen van alles wat je eerder hebt geprobeerd, dus ook dat SkipAsSource, extra's routes etc.? Daarna ook liever even rebooten. Het mag echt niet zo ingewikkeld zijn om een paar aliassen in te stellen; mogelijk werken die andere instellingen je nu tegen. Als het op Linux/BSD zo gepiept is, moet dat op Windows ook zo zijn zolang de instellingen goed vertaald worden.

En werk je overzicht adapterinstellingen even bij a.u.b.; ik weet vrijwel zeker dat die /32 moet blijven, dus zo blijven wij ook actueel.

[ Voor 20% gewijzigd door Z-Dragon op 27-05-2013 13:08 ]

[.Gertjan.]

Z-Dragon schreef op maandag 27 mei 2013 @ 13:01:
Is het mogelijk om zo veel mogelijk op te ruimen van alles wat je eerder hebt geprobeerd, dus ook dat SkipAsSource, extra's routes etc.? Daarna ook liever even rebooten. Het mag echt niet zo ingewikkeld zijn om een paar aliassen in te stellen; mogelijk werken die andere instellingen je nu tegen. Als het op Linux/BSD zo gepiept is, moet dat op Windows ook zo zijn zolang de instellingen goed vertaald worden.

Ik heb zojuist het hele verhaal met de extra ip's eruit gegooid en 2 van de adressen opnieuw toegevoegd. Daarnaast heb ik wat ik destijds met de arp routes heb gedaan ook ongedaan gemaakt. Echter lijkt dat nog niet te helpen. Als ik de SkipAsSource eruit haal ziet hij het laagste IP adres als interface adres en toont hij die dus ook in de route tabel.

Je zou inderdaad verwachten dat het makkelijk moet zijn om het in te richten, maar schijnbaar ligt die combinatie redelijk dwars.

edit: De OP is op verzoek aangepast naar de goede ip data

[Z-Dragon]

In dat geval ga je toch bijna twijfelen aan de claim van Hetzner dat er inderdaad static routing plaatsvindt van de subnets naar je hoofd-IP, want als de Tell niet aankomt, weet de gateway je kennelijk niet te vinden. Maar ik zoek nog even verder voor je...

Blijft de boel wel draaien als je een statische ARP-entry toevoegt?

code:

arp -s 10.0.0.200 00-10-54-CA-E1-40

Maar dan dus met het IP en MAC-adres van de gateway.

[ Voor 26% gewijzigd door Z-Dragon op 27-05-2013 13:50 ]

[Z-Dragon]

Hier is alvast een kleine correctie op wat ik eerder schreef:

quote: http://forums.freebsd.org/showthread.php?t=38317

An IP address in a certain network gets its proper netmask (e.g. 255.255.255.248). An alias in that same network on the same interface gets a 255.255.255.255 netmask.

Repeat for every separate network, whether it's on the same interface or not.

So:

code:

ifconfig_em0="inet x.x.x.20 netmask 255.255.255.248"
ifconfig_em0_alias0="inet x.x.x.21 netmask 255.255.255.255"
ifconfig_em0_alias1="inet x.x.x.22 netmask 255.255.255.255"

ifconfig_em0_alias2="inet y.y.y.44 netmask 255.255.255.248"
ifconfig_em0_alias3="inet y.y.y.45 netmask 255.255.255.255"
ifconfig_em0_alias4="inet y.y.y.46 netmask 255.255.255.255"

Dit is dan wel FreeBSD, maar in feite is het gewoon networking, dus universeel geldig. Ik ga er vanuit dat je het voorbeeld wel begrijpt.

Het is jammer dat je IP's geheim zijn; dat maakt het onmogelijk voor ons om het te controleren.

[ Voor 5% gewijzigd door Z-Dragon op 27-05-2013 14:14 ]

[.Gertjan.]

Z-Dragon schreef op maandag 27 mei 2013 @ 13:42:
In dat geval ga je toch bijna twijfelen aan de claim van Hetzner dat er inderdaad static routing plaatsvindt van de subnets naar je hoofd-IP, want als de Tell niet aankomt, weet de gateway je kennelijk niet te vinden.
Maar ik zoek nog even verder voor je...

Thanks

Blijft de boel wel draaien als je een statische ARP-entry toevoegt?

code:

arp -s 10.0.0.200 00-10-54-CA-E1-40

Maar dan dus met het IP en MAC-adres van de gateway.

Het ging niet via arp -s, maar via netsh heb ik hem toekunnen voegen, ik heb nu een static route liggen naar de gateway. Maar ik ben bang dat het gevaarlijk is om hard-wired een gateway te kiezen op mac adres, wat gebeurt er als ze die ooit vervangen.

De kans is groot dat het nu blijft werkten, want zolang de MAC van de gateway bekend blijft (via een ping op de server naar de gateway) bleef de boel werken. Vorige week een hele week een ping -t naar de gateway open gehad op de server en de boel bleef draaien. Toen ik de ping -t de nek omdraaide viel het vrijwel direct om.

Z-Dragon schreef op maandag 27 mei 2013 @ 14:09:
Hier is alvast een kleine correctie op wat ik eerder zei:

Dit is dan wel FreeBSD, maar in feite is het gewoon networking, dus universeel geldig. Ik ga er vanuit dat je het voorbeeld wel begrijpt.

Ik begrijp hem (denk ik )
Voor zover ik kan zien heb ik dit ook zo ingeregeld. Het primaire adres heeft het netmask 255.255.255.0 (toegewezen door hetzner), de extra adressen 255.255.255.255.

Het is wel zo dat zij voor een van de y.y.y adressen ook subnetmask 255.255.255.248 waarbij ik voor al mijn "alternatieve" adressen 255.255.255.255 opstel.

Het is jammer dat je IP's geheim zijn; dat maakt het onmogelijk voor ons om het te controleren.

In het kader van de anonimiteit van de opdrachtgever doe ik dat liever niet. Ik snap dat het wel makkelijker zou zijn, dus waardeer het erg dat je toch wilt helpen

[Z-Dragon]

Nadat je alles hebt ingesteld, en let echt goed op wat in dezelfde range zit en wat niet, even controleren of al je adressen werken:

code:

ping -S eenvanjeips 8.8.8.8

(Vanuit de server.)

Rest kom ik nog op terug.

[ Voor 5% gewijzigd door Z-Dragon op 27-05-2013 14:38 ]

[webfreakz.nl]

Kan je het adres eens op een loopback interface instellen?

[Z-Dragon]

.Gertjan. schreef op maandag 27 mei 2013 @ 14:32:
Het ging niet via arp -s, maar via netsh heb ik hem toekunnen voegen, ik heb nu een static route liggen naar de gateway. Maar ik ben bang dat het gevaarlijk is om hard-wired een gateway te kiezen op mac adres, wat gebeurt er als ze die ooit vervangen.

Is ook geen blijvende oplossing. Nog steeds het probleem aan het isoleren.

Ik begrijp hem (denk ik )
Voor zover ik kan zien heb ik dit ook zo ingeregeld. Het primaire adres heeft het netmask 255.255.255.0 (toegewezen door hetzner), de extra adressen 255.255.255.255.

Het is wel zo dat zij voor een van de y.y.y adressen ook subnetmask 255.255.255.248 waarbij ik voor al mijn "alternatieve" adressen 255.255.255.255 opstel.

Maak die zin eens af... Want zo is het vaag. Nogmaals: voor elk ander subnet een keer het masker van het hele subnet en voor elke volgende /32.

[.Gertjan.]

Z-Dragon schreef op maandag 27 mei 2013 @ 15:05:
Maak die zin eens af... Want zo is het vaag. Nogmaals: voor elk ander subnet een keer het masker van het hele subnet en voor elke volgende /32.

Geloof mij, in mijn hoofd zat hij nog vager Het kwam er op neer dat ik niet helemaal begreep waarom er per subnet een adres een afwijkend mask moest hebben zoals in het voorbeeld.

Maar toen schoot er mij ineens iets te binnen, ik heb namelijk van Hetzner destijds dit mailtje ontvangen:

code:

Subnet: 78.47.x.32 /29
Mask:   255.255.255.248
Broadcast:  78.47.x.39
Usable IP addresses:
78.47.x.33 to 78.47.x.38

Ik heb net dus even 78.47.x.32 /29 toegevoegd. Meteen daarop schoten er volgens wireshark direct een aantal ARP requests over de lijn om de range van 33 -> 38 te bepalen. Voorheen gebeurde dit volgens mij ook maar kwamen er in mijn eigen ARP tabel ook met enige regelmaat regels te staan als markering invalid.

Het toevoegen van de .32 had ik al geprobeerd, maar dat werkte toe niet (waarschijnlijk omdat die toen de voorkeur kreeg omdat het ip nummer lager was dan het IP dat wel bij de gateway kon). Mogelijk dat dit in combinatie met de andere fixes werkt. Fingers crossed dus eventjes
Ik heb eventjes de hardcoded route verwijderd om te kijken hoe het gedrag nu is. Met die route leek het ook te blijven werken.

[Z-Dragon]

Ik ben er toch nog niet helemaal van overtuigd dat je 'm snapt. Ga eens naar www.subnet-calculator.com en check, voor elk IP en subnet dat je toegewezen hebt gekregen, welke bij elkaar horen. Bijvoorbeeld:

1. 76.43.6.80/24 (/24 = 255.255.255.0) = hoofd-IP
2. 78.47.2.35/29 (/29 = 255.255.255.248)
3. 78.47.2.37/29
4. 78.47.2.48/29

Het eerste octet (deel tot de eerste punt) is tussen de 1 en 126, dus het is allemaal Class A.
Vul het IP-adres in en selecteer het aantal Mask Bits of het Subnet Mask.

Voor 1 uit het lijstje is de Host Address Range (= Usable Addresses) 76.43.6.1 - 76.43.6.254.
Voor de 2-3 uit het lijstje is de Host Address Range 78.47.2.33 - 78.47.2.38, dus die horen bij elkaar (ze hebben hetzelfde subnet: 78.47.2.32/29), maar niet bij 1. Voor 4 is de Host Address Range 78.47.2.49 - 78.47.2.54, dus die hoort er niet bij 1 of 2-3 (het is een ander subnet: 78.47.2.48/29).

Welnu, als je weet welke adressen bij elkaar horen, pas je de volgende regels toe:
- Het eerste adres een de groep (Host Address Range) dat aan jou is toegewezen (78.47.2.35 in het voorbeeld) geef je het Subnet Mask van de groep (255.255.255.248).
- Elk volgende adres uit dezelfde groep (Host Address Range) dat aan jou is toegewezen (alleen 78.47.2.37 in het voorbeeld) geef je 255.255.255.255.

In het voorbeeld zou dat resulteren in de volgende instellingen:

1. IP=76.43.6.80, netmask=255.255.255.0
2. IP=78.47.2.35, netmask=255.255.255.248
3. IP=78.47.2.37, netmask=255.255.255.255
4. IP=78.47.2.48, netmask=255.255.255.248

Als dat allemaal goed staat, test je het ping-commando zoals hierboven beschreven met elk van deze adressen als bron.

Als dat werkt, moeten we afwachten hoe het met de ARP-cache gaat.

P.S. Ik snap het probleem met deze IP's zo op een publiek forum zetten. Eventueel kun je de instellingen via een DM met me doornemen, als je daar geen probleem mee zou hebben.

[.Gertjan.]

Z-Dragon schreef op maandag 27 mei 2013 @ 17:47:
Ik ben er toch nog niet helemaal van overtuigd dat je 'm snapt.

Ik doe mijn best, maar je zou zomaar gelijk kunnen hebben

Ga eens naar www.subnet-calculator.com en check, voor elk IP en subnet dat je toegewezen hebt gekregen, welke bij elkaar horen. Bijvoorbeeld:

1. 76.43.6.80/24 (/24 = 255.255.255.0) = hoofd-IP
2. 78.47.2.35/29 (/29 = 255.255.255.248)
3. 78.47.2.37/29
4. 78.47.2.48/29

Als ik dit doe komt er volgens de calculator uit dat de range 78.47.x.32 met het toegewezen subnet (/29) resulteert in een host address range van 78.47.x.33 - 78.47.x.38. Dit zijn ook de adressen die ik toegewezen heb gekregen.

Het andere (primaire) adres valt in het subnet 144.76.65.160/27 (waarbij de gateway de eerste is is uit de adres range).

Volgens jouw verhaal zou ik dus de volgende data in mijn lijst moeten opnemen:
1. IP=144.76.65.x, netmask=255.255.255.224
2. IP=78.47.x.33, netmask=255.255.255.248
3. IP=78.47.x.34, netmask=255.255.255.255
4. IP=78.47.x.35, netmask=255.255.255.255
....
X. IP=78.47.x.38, netmask=255.255.255.255

Hoewel ik hier twijfelde of ik het .32 adres wel of niet moet opnemen (maar aangezien het het subnet ID is lijkt mij dat niet het geval). Ik zie net dat ik namelijk wel een aantal keer heb geprobeerd het subnet ID te gebruiken door hem op te nemen in de lijst, mogelijk dat dat ook niet echt lekker ging.

Zit ik nu wel enigszins in de goede richting?
Moet zeggen dat ik mij momenteel bijster weinig intelligent voel

[Z-Dragon]

Het eerste adres is inderdaad het subnet-ID en dient nooit gebruikt te worden; het laatste adres is het broadcastadres en mag ook nooit gebruikt worden. Daar krijg je de vreemdste problemen van.

Zoals hierboven lijkt het goed te zijn; de enige inconsistentie die ik nu zie is dat je nu zegt dat het primaire adres in /27 (= 255.255.255.224) valt terwijl je eerder /24 (= 255.255.255.0) aangaf. Gebruik de juiste.

[.Gertjan.]

Z-Dragon schreef op maandag 27 mei 2013 @ 20:23:
Het eerste adres is inderdaad het subnet-ID en dient nooit gebruikt te worden; het laatste adres is het broadcastadres en mag ook nooit gebruikt worden. Daar krijg je de vreemdste problemen van.

Zoals hierboven lijkt het goed te zijn; de enige inconsistentie die ik nu zie is dat je nu zegt dat het primaire adres in /27 (= 255.255.255.224) valt terwijl je eerder /24 (= 255.255.255.0) aangaf. Gebruik de juiste.

Ik was nog even naar het start script van hetzner aan het kijken en zag daar /24. Dat heb ik per ongeluk dus een keer gewijzigd.

De machine is nu ingericht zoals hierboven en heeft een ARP clean en reboot gehad. Nu even kijken hoe hij zicht gedraagt.

In ieder geval nogmaals dank, hopelijk lost dit het op Zo niet, dan meld ik mij weer

[Z-Dragon]

Ik wacht in spanning af.

[.Gertjan.]

Z-Dragon schreef op maandag 27 mei 2013 @ 20:44:
Ik wacht in spanning af.

Helaas... Afgelopen nacht heeft de server alsnog met enige regelmaat last gehad van verbindingsproblemen. Het is lastig om te zien wanneer de server eindelijk goed is ingesteld aangezien er op de een of andere manier heel veel verkeer op het netwerk is. Met enige regelmaat gaat er een ping of andere request over het hele netwerk waardoor het primaire adres ook aangeraakt wordt. Wanneer dit adres geraakt wordt (de 174) wordt de gateway gevonden en zal het verkeer in het subnet ook goed werken. Gisterenavond heb ik regelmatig met de hand een pingetje gedaan (en is de monitoring blijven lopen), dat ging enkele uren goed (waarschijnlijk ook door bovenstaande toevalligheid) maar vannacht is de handel weer plat gegaan.

Het probleem dat verkeer dat binnenkomt op het subnet probeert via het subnet adres de gateway te vinden blijft helaas bestaan. Ik blijf in WireShark helaas hetzelfde gedrag zien als wat ik in de OP beschrijf. er komt een request binnen op een van de subnet adressen, vervolgens wordt er een ARP uitgestuurd om de gateway te vinden en dat lukt niet. Als er vervolgens een request binnenkomt op de main IP dan komt er een ARP namens dat IP en wordt de gateway gevonden. Zodra deze bekend is wordt het verkeer op alle adressen netjes afgehandeld.

Het enige wat langdurig blijkt te werken is het MAC van de gateway vastleggen via netsh neighbors, dat zorgt er voor dat het goed blijft werken, echter is dit erg risicovol en zorgt dit voor outage wanneer de gateway ooit wordt vervangen.

Ik begin echt het vermoeden te krijgen dat het hele verhaal niet echt denderend werkend te krijgen is in Windows, het feit dat Hetzner het alleen heeft over Linux baart mij nog steeds zorgen... er zit inmiddels redelijk wat tijd in en ik heb geen idee of er op korte termijn een goede oplossing te vinden is. Momenteel overweegt de klant om de boel bij Hetzner weg te trekken en een andere partij te zoeken... Zelf wil ik proberen te doorgronden wat er nu eigenlijk aan de hand is, maar krijg helaas niet echt een goed beeld van het probleem (laat staan van de oplossing).

[Z-Dragon]

Ik snap dat je geen voortgang ziet en intussen de frustratie alleen maar toeneemt, maar als buitenstaander zie ik wel duidelijke stappen in de goede richting. We hebben het intussen behoorlijk geïsoleerd en er blijven een paar hele concrete vragen over.

- Waarom worden ARP's in de vorm van "Who has <gateway>? Tell <extra IP>" niet beantwoord?

Het lijkt me dat je nu zo vrij kunt zijn die vraag wél bij Hetzner neer te leggen. Er is namelijk helemaal niks Windows aan. In feite gaat het over hun infrastructuur. Ook een antwoord in Linux-termen zou niks uitmaken. Alleen als men nu weer klakkeloos naar de wiki verwijst, zou ik wel teleurgesteld zijn.

- Gaat verkeer afkomstig van een extra IP wel daadwerkelijk eruit met je hoofd-IP als afzender? Zo niet, is het begrijpelijk dat de ARP ook de verkeerde afzender heeft. Zo wel, waarom heeft ARP dan een andere afzender?

- Is bovenstaand op Windows te wijzigen, voor alles of voor ARP?

Die laatste twee vragen heb ik vanmiddag een paar uurtjes voor uitgetrokken; VM's staan al klaar.

Hoe zeer je klant die neiging ook heeft, is het aan jou om die te weerhouden van paniekvoetbal. Afhankelijk van het antwoord op de eerste vraag uit het lijstje, is de kans heel groot dat het bij een andere partij niks beter gaat. Wat moet je klant ervan denken als je de hele boel omgooit en het probleem blijft bestaan?

Het ergste wat we op dit moment als optie overhouden, is om een service te laten draaien die altijd voldoende verkeer op het hoofd-IP houdt. Die kan gewoon op de server draaien (de gateway-ping). En ik heb al een paar dergelijke oplossingen langs zien komen voor andere problemen, in Linux nog wel. Dus zo smerig is het nog niet.

[pedorus]

Z-Dragon schreef op dinsdag 28 mei 2013 @ 07:56:
- Waarom worden ARP's in de vorm van "Who has <gateway>? Tell <extra IP>" niet beantwoord?

Het lijkt me dat je nu zo vrij kunt zijn die vraag wél bij Hetzner neer te leggen. Er is namelijk helemaal niks Windows aan. In feite gaat het over hun infrastructuur. Ook een antwoord in Linux-termen zou niks uitmaken. Alleen als men nu weer klakkeloos naar de wiki verwijst, zou ik wel teleurgesteld zijn.

Verwacht geen lastige antwoorden van support van een cheapo bare metal hoster lijkt mij Het antwoord lijkt me dat de router alleen op arp requests vanaf het primaire ip adres antwoord. De oplossing is om uit te vinden hoe je er voor zorgt dat je arp requests (alleen) vanaf dat ip adres maakt. Microsoft om support vragen gaat eerder werken.

Als workaround: wellicht kun je op de windows bak gewoon continue een ping request draaien richting de router bijvoorbeeld?

[.Gertjan.]

Z-Dragon schreef op dinsdag 28 mei 2013 @ 07:56:
Ik snap dat je geen voortgang ziet en intussen de frustratie alleen maar toeneemt, maar als buitenstaander zie ik wel duidelijke stappen in de goede richting. We hebben het intussen behoorlijk geïsoleerd en er blijven een paar hele concrete vragen over.

Daar heb je gelijk, het probleem is inderdaad redelijk ge-pinpoint Door de frustratie is het lastig om positief te blijven en voortgang te zien

- Waarom worden ARP's in de vorm van "Who has <gateway>? Tell <extra IP>" niet beantwoord?

Het lijkt me dat je nu zo vrij kunt zijn die vraag wél bij Hetzner neer te leggen. Er is namelijk helemaal niks Windows aan. In feite gaat het over hun infrastructuur. Ook een antwoord in Linux-termen zou niks uitmaken. Alleen als men nu weer klakkeloos naar de wiki verwijst, zou ik wel teleurgesteld zijn.

Die vraag heb ik ze meerdere malen neergelegd (ze hebben ook mijn Wireshark verhaal gekregen). Ze blijven naar de wiki wijzen met de vermelding dat ik het daar maar moet uitzoeken.

Ze kwamen in eerste instantie met een verhaal dat onze server niet zou luisteren naar hun ARP requests. Er komt weinig hulp vanuit Hetzner. We vragen ze ook niet om het op te lossen, we vragen enkel om suggesties. Maar helaas krijgen we steeds dezelfde reply.

- Gaat verkeer afkomstig van een extra IP wel daadwerkelijk eruit met je hoofd-IP als afzender? Zo niet, is het begrijpelijk dat de ARP ook de verkeerde afzender heeft. Zo wel, waarom heeft ARP dan een andere afzender?

Verkeer gaat (als het werkt), via het subnet IP naar buiten. Ik zie in Wireshark als afzender het subnet ip staan. Het is dus wel verklaarbaar dat het subnet ook probeert zelf de gateway te vinden.

- Is bovenstaand op Windows te wijzigen, voor alles of voor ARP?

Die laatste twee vragen heb ik vanmiddag een paar uurtjes voor uitgetrokken; VM's staan al klaar.

Thanks, tof dat je het wilt gaan uitzoeken, maar helaas is de boel nu al stopgezet. Desalniettemin ben ik wel erg benieuwd wat je resultaten zouden zijn. Op de een of andere manier boeit het probleem mij namelijk wel.

Hoe zeer je klant die neiging ook heeft, is het aan jou om die te weerhouden van paniekvoetbal. Afhankelijk van het antwoord op de eerste vraag uit het lijstje, is de kans heel groot dat het bij een andere partij niks beter gaat. Wat moet je klant ervan denken als je de hele boel omgooit en het probleem blijft bestaan?

Helaas is het leed geschied en heeft de klant de stekker eruit laten trekken door hetzner. Vanochtend is de server gecancelled en is het verzoek neergelegd om een andere partij te zoeken.

Het ergste wat we op dit moment als optie overhouden, is om een service te laten draaien die altijd voldoende verkeer op het hoofd-IP houdt. Die kan gewoon op de server draaien (de gateway-ping). En ik heb al een paar dergelijke oplossingen langs zien komen voor andere problemen, in Linux nog wel. Dus zo smerig is het nog niet.

Het zou een optie zijn, maar lijkt me helaas fout gevoelig. Er liep een ping -t naar de gateway, maar dat is niet echt iets waar ik blij van werd. Het voelt niet goed om zulke work-arounds te moeten doen.

pedorus schreef op dinsdag 28 mei 2013 @ 08:35:
[...]

Verwacht geen lastige antwoorden van support van een cheapo bare metal hoster lijkt mij Het antwoord lijkt me dat de router alleen op arp requests vanaf het primaire ip adres antwoord. De oplossing is om uit te vinden hoe je er voor zorgt dat je arp requests (alleen) vanaf dat ip adres maakt. Microsoft om support vragen gaat eerder werken.

Voor die vraag ben ik redelijk het internet aan het afstruinen geweest, zonder resultaat helaas. Wat ik begreep van de Linux voorbeelden (en de ander wiki pagina's) is dat men een soort interne routing opzet. Voor zover ik weet gaat dat niet zo heel makkelijk in Windows, er is wel enige routing mogelijk, maar dan moet je de routing rol installeren (waar ook nadelen aan zitten).

Als workaround: wellicht kun je op de windows bak gewoon continue een ping request draaien richting de router bijvoorbeeld?

Dat is toevallig een van de oplossingen van Hetzner geweest. Dit werkt (net als het vastprikken van de ARP richting de gateway (dus IP->Mac), maar is helaas niet echt een gewenste oplossing. Een server van buiten het primaire adres laten pingen werkte ook, maar dat vind ik ook niet echt een oplossing.

Het is redelijk fout gevoelig en je moet een user actief houden (mogelijk kun je iets schedulen, maar dan is er alsnog een user sessie). De suggestie is goed, maar helaas geen duurzame oplossing.

---

Desalniettemin iedereen bedankt voor het meedenken en de geboden oplossingen.

[Z-Dragon]

Die ping is echt niet zo veel mis mee hoor. Giet hem in een service zodat hij altijd op de achtergrond draait, ook al is er niemand ingelogd. Een simpel script dat kijkt wat je standaard gateway is, en hoe snel je ARP-cache verloopt, en dan vaak genoeg die gateway pingt. Niet mooi, wel effectief.

Desondanks heb ik zojuist bevestigd gezien dat Unix altijd het hoofd-IP gebruikt voor ARP-requests, ook als je een alias pingt of als source-IP gebruikt voor een ping vanuit Unix zelf. Op Windows 7 gebruikt hij consistent het alias voor alles, ook met SkipAsSource. Het blijkt echter dat de werking van SkipAsSource behoorlijk verschilt tussen verschillende versies van Windows; het wisselt zelfs met service packs en hotfixes (dat is wel een beetje typisch Microsoft). Was je helemaal bij met de updates van Windows? Straks hetzelfde testen met 2008R2. Ook al heeft het voor Hetzner dan geen zin meer, de kans is groot dat je er bij je volgende hoster ook mee te maken krijgt. IP4-adressen zijn schaars, dus zelfs als je nu al je IP's in hetzelfde blok krijgt, komt er vanzelf een dag dat je nog een IP nodig hebt, en dat wel uit een ander blok komt. En het staat nog niet eens vast dat het met alles uit hetzelfde blok wel goed gaat. Betere service in het algemeen is natuurlijk wel een plus.

[ Voor 5% gewijzigd door Z-Dragon op 28-05-2013 11:13 ]

[webfreakz.nl]

webfreakz.nl schreef op maandag 27 mei 2013 @ 14:50:
Kan je het adres eens op een loopback interface instellen?

Heb je dit nou al eens geprobeerd?

.Gertjan. schreef op dinsdag 28 mei 2013 @ 06:41:
[...]
Ik begin echt het vermoeden te krijgen dat het hele verhaal niet echt denderend werkend te krijgen is in Windows, het feit dat Hetzner het alleen heeft over Linux baart mij nog steeds zorgen...

Welke stappen raden zij aan om het onder Linux te doen?

[.Gertjan.]

Z-Dragon schreef op dinsdag 28 mei 2013 @ 11:10:
Desondanks heb ik zojuist bevestigd gezien dat Unix altijd het hoofd-IP gebruikt voor ARP-requests, ook als je een alias pingt of als source-IP gebruikt voor een ping vanuit Unix zelf. Op Windows 7 gebruikt hij consistent het alias voor alles, ook met SkipAsSource. Het blijkt echter dat de werking van SkipAsSource behoorlijk verschilt tussen verschillende versies van Windows; het wisselt zelfs met service packs en hotfixes (dat is wel een beetje typisch Microsoft). Was je helemaal bij met de updates van Windows? Straks hetzelfde testen met 2008R2.

Thanks, zoiets had ik inderdaad ook al ergens gelezen. Wij hadden alle service packs voor zover ik kon zien (in SP1 van 2008R2 zou de bug verholpen moeten zijn). Mogelijk dat er toch ergens een fix is blijven hangen en we dus inderdaad daar het probleem door hadden.

Ik heb de server destijds een aantal keer laten updaten voordat we hem in gebruik namen, dus ik ga er eigenlijk vanuit dat we up-to-date waren.

webfreakz.nl schreef op dinsdag 28 mei 2013 @ 17:41:
[...]
Heb je dit nou al eens geprobeerd?

Sorry, heb ik inderdaad naar gekeken, maar zonder resultaat. Het koppelen van de IP's aan de loopback zorgde er voor dat de server helemaal niet bereikbaar was.

Welke stappen raden zij aan om het onder Linux te doen?

Ze hadden volgens mij 2 opties, de ene was als alias (met het gedrag zoals Z-Dragon beschreef, dus verkeer altijd via het primaire IP) of via een routing (maar dat was volgens mij vooral als je ging virtualiseren).

[Brahiewahiewa]

.Gertjan. schreef op dinsdag 28 mei 2013 @ 18:50:
...Sorry, heb ik inderdaad naar gekeken, maar zonder resultaat. Het koppelen van de IP's aan de loopback zorgde er voor dat de server helemaal niet bereikbaar was....

Als je de extra IP-adressen op een loopback-interface zet, moet je nog wel de routing van Windows aanzetten (iets met enable IP forwarding = dword(1) in HKLM/SystemServices/...)