Bekijk Volledige Versie : Add ip werkt niet?
FunnyMedia
05/03/13, 19:20
Ik zit momenteel in het datacenter met een vreemd probleem.
Ik heb DirectAdmin op een nieuwe server geinstalleerd maar als ik de IP adressen toevoeg via het admin panel zie ik de IP adressen wel staan maar zijn ze niet opvraagbaar / pingbaar.
Wel is het hoofdIP adres bereikbaar maar de rest niet.
Via google kan ik niet snel een oplossing vinden, ga wel verder zoeken maar hier een specialist actief die mij direct de gouden tip kan geven?
Je moet de IP adressen ook toevoegen binnen het OS zelf, bv in /etc/network/interfaces onder Debian.
Ik meen dat dat juist niet hoeft/moet als je ze in DA toevoegt.
Arieh : dat meen ik mij juist ook te herinneren...
systemdeveloper
05/03/13, 20:55
Voor ipv6 wel, maar voor ipv4 hoef je ze niet in het os toe te voegen als het in hetzelfde subnet zit.
Anders moet je even een ifcfg-eth0:1 (of ifcfg-eth1 indien je de nic op een ander netwerk aangesloten hebt) aanmaken met de juiste gegeven, bv:
DEVICE=eth0:1 (of eth1)
BOOTPROTO=static
ONBOOT=yes
IPADDR=1.2.3.4
NETMASK=255.255.255.x
GATEWAY=w.x.y.z (alleen indien je een andere gateway nodig hebt)
Edit: en een 'service netwerk restart' doen uiteraard :)
dennis0162
05/03/13, 21:54
Kijk even of je ze wel ziet staan met ifconfig
eth0:1 eth0:2 etc.
Anders even het IP start script van DirectAdmin gebruiken: /usr/local/directadminn/scripts/startips
polle@vip.nl
06/03/13, 14:21
Ook ooit eens meet e maken gehad. behoorlijk frusti. Probeer eens een IP toe te voegen via OS? (interface) werkt waarschijnlijk
FunnyMedia
06/03/13, 15:01
Ik heb nu alle domeinnamen op 1 IP adres staan en alles is weer online.
Blijkbaar werken nu de IP adressen plots wel ondanks dat ik niets aangepast heb.
Nu krijg ik de shared pagina te zien en kan ik ze pingen.
Gisteren de server een aantal maal opnieuw opgestart zonder resultaat.
Na een nachtje slapen heeft de server zich blijkbaar bedacht :-)
Had je die extra IP's overgezet vanaf een andere server? Want dan heb je soms dat de router nog het MAC adres van de oude server in de ARP tables heeft staan. Omdat je hoofd IP wat verkeer genereert, leert de router daarbij vrij snel het correcte MAC adres, maar bij extra IP's is dat soms niet het geval.
MaartenPol
25/01/14, 10:52
Sorry dat ik deze oude thread nog eens open gooi.
Ik heb een vergelijkbaar probleem. In DirectAdmin (op CentOS 6) ook een nieuw IP adres toegevoegd. Met ifconfig zie ik hem staan.
eth0 Link encap:Ethernet HWaddr 52:54:00:FD:60:0D
inet addr:*.*.*.200 Bcast:*.*.*.255 Mask:255.255.255.0
inet6 addr: *:*:*:*::*/48 Scope:Global
inet6 addr: *::*:*:*:*/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:26338 errors:0 dropped:0 overruns:0 frame:0
TX packets:22036 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:16318640 (15.5 MiB) TX bytes:27824711 (26.5 MiB)
eth0:0 Link encap:Ethernet HWaddr *:*:*:*:*:0D
inet addr:*.*.*.33 Bcast:*.*.*.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Het .200 adres werkt probleemloos, maar het .33 adres niet. Lokaal kan ik hem gewoon pingen. Van elke externe locatie niet. Heb er inmiddels een nacht overheen laten gaan, lijkt me dat eventuele ARP probleem zoals eerder aangegeven dan wel voorbij zijn. Kan iemand me in de goede richting drukken?
Even bij de basis beginnen:
- Kun je vanaf de server zelf .200 pingen? Als dit niet werkt tijdelijk ping toe gaan staan voor de overige tests.
- Kun je vanaf de server zelf .33 pingen?
- Kun je vanaf een ander systeem in de betreffende /24 de .200 pingen? *
- Kun je vanaf een ander systeem in de betreffende /24 de .33 pingen? *
- Kun je vanuit een ander netwerk de .200 pingen? Als dit niet werkt tijdelijk ping toe staan voor de overige tests.
- Kun je vanuit een ander netwerk de .33 pingen?
* Meld het als je geen ander systeem in die /24 hebt, sla deze test dan over.
De antwoorden hier vertellen of het een netwerk probleem is of dat het ergens anders zit. Als dit allemaal werkt is het netwerk deel goed en verneem ik graag wat er precies op de .33 niet werkt, overigens kan het bij deze tests handig zijn als iets niet werkt om te kijken of er een firewall staat die tijdelijk uitgezet kan/moet worden.
Vergeet ook niet dat sommige partijen, al valt dat in Nederland nog wel mee volgens mij, IP adressen toewijzen op basis van het MAC-adres.
dennis0162
25/01/14, 11:51
Ik neem aan dat je het IP-adres van je provider toegewezen hebt gekregen?
Wellicht vergeten zijn ACL te updaten.
MaartenPol
25/01/14, 12:32
Bedankt voor jullie snelle responsen.
Even bij de basis beginnen:
- Kun je vanaf de server zelf .200 pingen? Als dit niet werkt tijdelijk ping toe gaan staan voor de overige tests.
- Kun je vanaf de server zelf .33 pingen?
- Kun je vanaf een ander systeem in de betreffende /24 de .200 pingen? *
- Kun je vanaf een ander systeem in de betreffende /24 de .33 pingen? *
- Kun je vanuit een ander netwerk de .200 pingen? Als dit niet werkt tijdelijk ping toe staan voor de overige tests.
- Kun je vanuit een ander netwerk de .33 pingen?
* Meld het als je geen ander systeem in die /24 hebt, sla deze test dan over.
De antwoorden hier vertellen of het een netwerk probleem is of dat het ergens anders zit. Als dit allemaal werkt is het netwerk deel goed en verneem ik graag wat er precies op de .33 niet werkt, overigens kan het bij deze tests handig zijn als iets niet werkt om te kijken of er een firewall staat die tijdelijk uitgezet kan/moet worden.
Vanaf de server zelf kan ik .200 pingen. Ook .33 pingen werkt.
Een andere systeem binnen de betreffende /24 heb ik niet
Vanaf werk/thuis kan ik .200 pingen, de .33 niet.
Ik heb dezelfde test herhaalt met de firewall uit, zelfde resultaat.
Ik neem aan dat je het IP-adres van je provider toegewezen hebt gekregen?
Wellicht vergeten zijn ACL te updaten.
Ik heb het IP-adres gisterochtend van mijn provider (TransIP) gehad ja. Ik heb een VPS daar.
Kun je naar de .200 en .33 een traceroute maken? Aangezien hij lokaal wel werkt en over het internet niet is mijn vermoeden op dit moment dat er een netwerk instelling ergens (of op de VPS of bij TransIP) niet goed staat en een traceroute geeft hier mogelijk informatie over. Eventueel is dit ook typisch iets dat opgelost kan worden door TransIP lijkt mij.
MaartenPol
25/01/14, 13:26
Kun je naar de .200 en .33 een traceroute maken? Aangezien hij lokaal wel werkt en over het internet niet is mijn vermoeden op dit moment dat er een netwerk instelling ergens (of op de VPS of bij TransIP) niet goed staat en een traceroute geeft hier mogelijk informatie over. Eventueel is dit ook typisch iets dat opgelost kan worden door TransIP lijkt mij.
Als ik dat doe, ben ik in 9 stappen bij de .200
De laatste stappen:
7 19 ms 19 ms 18 ms asd2-rou-1043.NL.eurorings.net [134.222.229.101]
8 22 ms 22 ms 56 ms 134.222.97.205
9 36 ms 22 ms 22 ms *-*-*-200.colo.transip.net [*.*.*.200]
Bij de .33 gaat het vanaf stap 7 zo:
7 23 ms 23 ms 22 ms asd2-rou-1044.NL.eurorings.net [134.222.224.4]
8 21 ms 22 ms 22 ms asd2-rou-1043.NL.eurorings.net [134.222.227.81]
9 * * * Time-out bij opdracht.
10 * * * Time-out bij opdracht.
11 * * * Time-out bij opdracht.
12 * * * Time-out bij opdracht.
13 * * * Time-out bij opdracht.
Heb ook al contact gehad met TransIP, maar die zeggen in eerste instantie dat er geen support zit op de VPS. Dat mag ik zelf uitzoeken.
Dit lijkt er anders heel erg op als of een hop bij TransIP een route ontbreekt (ip .33 naar het systeem met IP 134.222.97.205). Hier lijkt het op het eerste gezicht fout te gaan, de informatie die je hier hebt verzameld zou ik naar TransIP sturen (maar dan zonder IPs onzichtbaar te maken) met eventueel een link er bij naar dit topic. Zodra ze zorgen dat het ip in hun netwerk de goede route volgt gaat het waarschijnlijk goed.
MaartenPol
25/01/14, 14:12
Ik ga het bij ze neerleggen.. Ik houd jullie op de hoogte.
Vergeet ook niet dat sommige partijen, al valt dat in Nederland nog wel mee volgens mij, IP adressen toewijzen op basis van het MAC-adres.
IPv4 ? Hosting ? WTF ?
Kun je eens uitleggen welke partijen dat zijn, en hoe ze dat dan zouden doen ?
Je hebt het toch niet over consumenten (kabel) access en dhcp leases ofzo ?
Sorry dat ik deze oude thread nog eens open gooi.
Ik heb een vergelijkbaar probleem. In DirectAdmin (op CentOS 6) ook een nieuw IP adres toegevoegd. Met ifconfig zie ik hem staan.
eth0 Link encap:Ethernet HWaddr 52:54:00:FD:60:0D
inet addr:*.*.*.200 Bcast:*.*.*.255 Mask:255.255.255.0
inet6 addr: *:*:*:*::*/48 Scope:Global
inet6 addr: *::*:*:*:*/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:26338 errors:0 dropped:0 overruns:0 frame:0
TX packets:22036 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:16318640 (15.5 MiB) TX bytes:27824711 (26.5 MiB)
eth0:0 Link encap:Ethernet HWaddr *:*:*:*:*:0D
inet addr:*.*.*.33 Bcast:*.*.*.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Het .200 adres werkt probleemloos, maar het .33 adres niet. Lokaal kan ik hem gewoon pingen. Van elke externe locatie niet. Heb er inmiddels een nacht overheen laten gaan, lijkt me dat eventuele ARP probleem zoals eerder aangegeven dan wel voorbij zijn. Kan iemand me in de goede richting drukken?
Ik wordt zo moe van dat IP adres verstoppen.
Wie heeft er nou een probleem, als je hulp wilt moet je het niet nodeloos moeilijk maken om je te helpen.
ARP tijden is in de orde van vijf minuten tot hooguit vier uur.Een nacht wachten helpt niet.
Waarom de overige octets belangrijk zijn :
De vraag is of deze adressen in hetzelfde subnet zitten, en dus dezelfde gateway kunnen gebruiken. Dat zou te zien zijn aan de octets die je verstopt.
Netwerk technisch kun je best een paar verschillende subnets in hetzelfde vlan draaien, en dan heeft elk subnet z'n eigen (in-subnet) gateway.
Ik denk dat je dan ook het beste een extra routing table kunt gebruiken, en het andere ip z'n eigen routing table met default route geven.
De andere manier is natuurlijk als de provider het verkeer voorzien van vlan tag aanlevert, en jij twee vlan subinterfaces op je server gebruikt. Of één subnet met vlan tag en het andere zonder.
Een buiten-subnet IP op een server hebben, maar toch een gateway in het subnet laten gebruiken is netwerk technisch nogal smerig.
Je moet dan een paar dingen statisch instellen, en aan de provider kant zal dat ook nodig zijn.
Op ethernet is namelijk het hele idee dat je ARP'ed voor het mac adres van hosts binnen je subnet, en verkeer naar andere IP adressen stuurt naar het mac adres dat je voor de default gateway gevraagd hebt. Die koppeling via arp van mac adres , ip adres en een gateway binnen het subnet is omdat ethernet meerdere hosts op een segment kan hebben.
Heb je een Point to Point verbinding, dan kun je verkeer gewoon het interface ingooien ,het kan er maar aan één plek uitkomen. Zoals je kunt zien op bijvoorbeeld ppp-stijl access (dsl met pppoa/pppoe, klassiek dial-up) kan het IP adres aan 'de andere kant' in een heel ander netwerk zitten dan het IP adres aan jouw kant.
De andere manier waarop dat kan werken is als het primaire IP van de server in het subnet gezien wordt *router* naar het extra ip.
De provider zal dan een statische route zetten met als next-hop het normale server ip.
Zo'n extra IP zet je dan als /32 IPv4 op een extra loopback interface, en niet als /24 IP subnet op een interface alias.
Samenvattend :
Zitten je IPs in hetzelfde subnet , dan zou het 'gewoon' moeten werken. Zo niet, check je firewall en contacteer je provider.
Kijk dan ook met tcpdump of je arp requests voor je 2e ip ziet langskomen als je van buitenaf pingt naar het tweede ip.
Zitten je IPs in een verschillend subnet, vraag dan je provider of dat de bedoeling is en op welke manier het zou moeten werken. Hoewel ik het als provider zou vermijden, omdat het gegarandeerd vragen en extra support issues geeft zijn er een paar manieren waarop het mogelijk is. Ze zullen dan zeker moeten aangeven op welke manier zij het gebouwd hebben.
Bedenk trouwens ook dat als je twee IPs in hetzelfde subnet hebt, de server voor verkeer wat hij zelf start dat altijd van één van de twee zal doen. (Default).
Dat kan van belang zijn als je kijkt naar billing of verkeersprofielen op basis van IP en je server ook zelf sessies start.
Antwoorden komen wel van het IP waar de vraag op binnenkwam.
IPv4 ? Hosting ? WTF ?
Kun je eens uitleggen welke partijen dat zijn, en hoe ze dat dan zouden doen ?
Je hebt het toch niet over consumenten (kabel) access en dhcp leases ofzo ?
IPv4! Hosting!
Nee, ik heb het niet over access providers. Een partij als OVH heeft een netwerk structuur waarbij MAC-adressen mee spelen in het uitdelen van IP's. Hetzner trouwens ook.
IPv4! Hosting!
Nee, ik heb het niet over access providers. Een partij als OVH heeft een netwerk structuur waarbij MAC-adressen mee spelen in het uitdelen van IP's. Hetzner trouwens ook.
Ah. Met wat google vind ik een relatie met een failover IP service, en dan wordt het logischer.
Dan is het niet zozeer wat ik uit je post meende te lezen (vandaar WTF) dat het 'gewone' server IP adres mac gebaseerd zou zijn, maar dat voor failover IP adressen een mac adres gealloceerd wordt gerelateerd aan het IP.
In die situatie (ook bij HSRP en VRRP, waarbij een gateway redundant is) wordt ook een niet-hardware gebonden mac adres gebruikt, en waarbij je dan moet oppassen om te zorgen dat het wel binnen het segment uniek is .
Ik zie het ook voor virtual guest waarbij de host bridged. Het guest mac moet dan wel uniek binnen het segment gekozen zijn, en moet (dus) aangevraagd/assigned worden door de provider. Ook dat is logisch .
Maar ik zou dat niet omschrijven als 'het ip hangt af van het mac adres'.
systemdeveloper
25/01/14, 20:12
Bij transip krijg je een ip adres ook op basis van een dhcp lease. Standaard althans. Dat je het daarna static maakt mag uiteraard omdat het toch niet de bedoeling is dat het wijzigt natuurlijk.
IPv4 ? Hosting ? WTF ?
Kun je eens uitleggen welke partijen dat zijn, en hoe ze dat dan zouden doen ?
Je hebt het toch niet over consumenten (kabel) access en dhcp leases ofzo ?
Wij hebben ook een aantal /24 segmenten welke waar we ook IP adressen aan MAC addressen. Door de opzet die we hebben, hebben klanten in het zelfde segment er geen last van als iemand een verkeerd ip adres instelt.
Voordeel hiervan is dat elke klant zijn eigen ip's heeft, bij perongeluk het gateway adres instellen als IP, levert alleen voor deze klant problemen op. En bij instellen van een IP wat niet bij hem/haar hoord zal het systeem welke het IP werkelijk toegewezen heeft er ook geen last van hebben.
Wij hebben ook een aantal /24 segmenten welke waar we ook IP adressen aan MAC addressen. Door de opzet die we hebben, hebben klanten in het zelfde segment er geen last van als iemand een verkeerd ip adres instelt.
Hier is een woordje weggevallen .
IP adressen aan MAC adressen ?
Je wilt waarschijnlijk zeggen 'vast aan mac adressen koppelen' ?
Oftewel statische arp entries op de gateway router van het segment ?
Voordeel hiervan is dat elke klant zijn eigen ip's heeft, bij perongeluk het gateway adres instellen als IP, levert alleen voor deze klant problemen op. En bij instellen van een IP wat niet bij hem/haar hoord zal het systeem welke het IP werkelijk toegewezen heeft er ook geen last van hebben.
Statische arp entries gebruiken kan prima, het kost je administratieve overhead, maar je beperkt de impact van klungelende klanten er enorm mee.
Maar zeker voor deze setup zou ik niet zeggen dat 'het ip adres toegewezen wordt op basis van mac adres', en dat was de uitspraak die me erg verbaasde.
Hier is een woordje weggevallen .
IP adressen aan MAC adressen ?
Je wilt waarschijnlijk zeggen 'vast aan mac adressen koppelen' ?
Oftewel statische arp entries op de gateway router van het segment ?
Statische arp entries gebruiken kan prima, het kost je administratieve overhead, maar je beperkt de impact van klungelende klanten er enorm mee.
Maar zeker voor deze setup zou ik niet zeggen dat 'het ip adres toegewezen wordt op basis van mac adres', en dat was de uitspraak die me erg verbaasde.
Het zijn geen statische arp entries maar een meer complexe setup. En de IPs zitten ook niet vast aan het MAC address, de klant kan zijn/haar machine wisselen en het IP weer gebruiken zonder dat wij aanpassingen hoeven te doen. Statische arp entries kun je gebruiken als je het beheer van alle machines doet, de statische arp entries zullen namelijk op alle machines gedaan moeten worden. En dat beheer doen wij niet..
Heel in het kort maken: wij maken gebruik van VLANs welke op Layer2 met elkaar kunnen communiceren (dus geen routering) en waar tussen de VLANS op basis van Layer3 info (IP addressen) gefilterd wordt.
Maar het gaat te ver om dat in dit topic uit te leggen, omdat het over een IP probleem bij TransIP gaat.
Het zijn geen statische arp entries maar een meer complexe setup. En de IPs zitten ook niet vast aan het MAC address, de klant kan zijn/haar machine wisselen en het IP weer gebruiken zonder dat wij aanpassingen hoeven te doen. Statische arp entries kun je gebruiken als je het beheer van alle machines doet, de statische arp entries zullen namelijk op alle machines gedaan moeten worden. En dat beheer doen wij niet..
Heel in het kort maken: wij maken gebruik van VLANs welke op Layer2 met elkaar kunnen communiceren (dus geen routering) en waar tussen de VLANS op basis van Layer3 info (IP addressen) gefilterd wordt.
Maar het gaat te ver om dat in dit topic uit te leggen, omdat het over een IP probleem bij TransIP gaat.
Ah, met alleen statische ARP entries op gateway vang je inderdaad niet alles af, en (ook) statisch arp op de servers heeft wel veel administratieve overhead.
Om het compleet af te dichten zou je (in cisco termen) de combinatie van private vlans, (+secure mac), dynamic arp inspectie en anti-spoofing moeten gebruiken.
Dat kan helemaal automatisch met dhcp snooping (alleen de combinatie van mac/ip die bij dhcp gezien is wordt geaccepteerd voor IP en arp verkeer) . Het is natuurlijk vooral een noodzakelijke feature in access netwerken.
Aan de hosting kant zou het ook prima kunnen, zolang je de servers dhcp willen gebruiken. Je kunt prima hetzelfde IP toekennen op basis van hetzij mac adres, of de access poort waar de dhcp request doorheen kwam.
Alleen klanten verwachten natuurlijk dat dhcp = niet-statisch ip.
Hoewel het een topic drift is, is het m.i. wel goed om dit soort mogelijkheden en design keuzes te bespreken.
Sterker, dit zou ook nog de oorzaak van TS' probleem kunnen zijn, dat er geen enkel dhcp request gezien is voor zijn tweede IP....
Het zou zomaar kunnen, als TransIP een oplossing als dit gebruikt.
MaartenPol
28/01/14, 13:34
Ik kom nog niet heel veel verder met TransIP. Ze reageren nog niet concreet zeg maar gerust. Kan ik niets over het hoofd hebben gezien?
Om nog even een vraag te beantwoorden. IP adressen zitten in het zelfde subnet, gebruiken dezelfde gateway. Zie hieronder, de volledige ifconfig
ifconfig
eth0 Link encap:Ethernet HWaddr 52:54:00:FD:60:0D
inet addr:149.210.135.200 Bcast:149.210.135.255 Mask:255.255.255.0
inet6 addr: 2a01:7c8:aab2:22a::1/48 Scope:Global
inet6 addr: fe80::5054:ff:fefd:600d/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:27316 errors:0 dropped:0 overruns:0 frame:0
TX packets:23563 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4926687 (4.6 MiB) TX bytes:27526437 (26.2 MiB)
eth0:1 Link encap:Ethernet HWaddr 52:54:00:FD:60:0D
inet addr:149.210.135.33 Bcast:149.210.135.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1448 errors:0 dropped:0 overruns:0 frame:0
TX packets:1448 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:223890 (218.6 KiB) TX bytes:223890 (218.6 KiB)
Dit is nu mijn configuratie van ifcfg-eth0:1
DEVICE=eth0:1
BOOTPROTO=static
IPADDR=149.210.135.33
ONBOOT=yes
ONPARENT=yes
NETMASK=255.255.255.0
IPV6INIT=no
Ik kom nog niet heel veel verder met TransIP. Ze reageren nog niet concreet zeg maar gerust. Kan ik niets over het hoofd hebben gezien?
Om nog even een vraag te beantwoorden. IP adressen zitten in het zelfde subnet, gebruiken dezelfde gateway. Zie hieronder, de volledige ifconfig
ifconfig
eth0 Link encap:Ethernet HWaddr 52:54:00:FD:60:0D
inet addr:149.210.135.200 Bcast:149.210.135.255 Mask:255.255.255.0
inet6 addr: 2a01:7c8:aab2:22a::1/48 Scope:Global
inet6 addr: fe80::5054:ff:fefd:600d/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:27316 errors:0 dropped:0 overruns:0 frame:0
TX packets:23563 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4926687 (4.6 MiB) TX bytes:27526437 (26.2 MiB)
eth0:1 Link encap:Ethernet HWaddr 52:54:00:FD:60:0D
inet addr:149.210.135.33 Bcast:149.210.135.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1448 errors:0 dropped:0 overruns:0 frame:0
TX packets:1448 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:223890 (218.6 KiB) TX bytes:223890 (218.6 KiB)
Dit is nu mijn configuratie van ifcfg-eth0:1
DEVICE=eth0:1
BOOTPROTO=static
IPADDR=149.210.135.33
ONBOOT=yes
ONPARENT=yes
NETMASK=255.255.255.0
IPV6INIT=no
Zelfde subnet suggereert dat het in elk geval niet één van de meer complexe setups is die mogelijk zijn.
Ik zou nu even kijken met tcpdump naar ARP verkeer.
(Alleen naar ARP, zodat je niet overloopt in al het andere verkeer wat langskomt).
Als je nu pingt naar je tweede IP verwacht je een arp 'who has' te zien langskomen voor je tweede IP .
En eventueel al de icmp echo request.
Zie je de icmp echo request binnenkomen moet je echt goed gaan kijken naar iptables op je server.
Kijk ook eens met ping -I <tweede ip> <transip gateway IP> , en dan een tcpdump mee laten lopen (tcpdump -ni eth0 icmp or arp )
MaartenPol
28/01/14, 16:43
Bij een tcpdump -v arp blijft het angstvallig stil bij het pingen naar het tweede IP vanaf mijn thuis-pc.
Een tcpdump met een ping vanaf de server naar de gateway geeft
16:41:07.723388 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
149-210-135-33.colo.transip.net > v315.vrrp.transip.net: ICMP echo request, id 38982, seq *, length 64
Waar het * elke keer met één oploopt, tot ik de ping stop. De ping zelf geeft geen resultaat.
Bij een tcpdump -v arp blijft het angstvallig stil bij het pingen naar het tweede IP vanaf mijn thuis-pc.
Een tcpdump met een ping vanaf de server naar de gateway geeft
16:41:07.723388 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
149-210-135-33.colo.transip.net > v315.vrrp.transip.net: ICMP echo request, id 38982, seq *, length 64
Waar het * elke keer met één oploopt, tot ik de ping stop. De ping zelf geeft geen resultaat.
Dan ligt de bal nu echt bij TransIP.
(even aangenomen dat met je primaire IP een ping naar de default gateway wel werkt ? )
MaartenPol
28/01/14, 17:02
Dan ligt de bal nu echt bij TransIP.
(even aangenomen dat met je primaire IP een ping naar de default gateway wel werkt ? )
Ja, dat werkt gewoon. Alles met het primaire IP is ok. Ik zal de extra info ook nog naar TransIP sturen.
Patrick_st
28/01/14, 20:52
Mask:255.255.255.0
Heb je dit subnetmask zelf zo ingesteld of krijg je dat via DHCP/van TransIP?
Als je dit zelf hebt ingesteld dan kan ik me voorstellen dat dit de oorzaak van je probleem is. Als een IP een broadcast doet naar een adres wat geen broadcast adres is, dan gaat het niet werken lijkt me.
Ik heb geen ervaring met meerdere IP adressen op een hosted server/vps maar als ik een DSL lijn aanvraag met meerdere IP adressen, dan krijg ik bijvoorbeeld 255.255.255.248 als subnet mee.
Verder kan een "ip route show" commando ons wellicht ook wat meer inzicht geven.
MaartenPol
28/01/14, 21:19
Ik heb dit nu zelf ingegeven in ifcfg-eth0:1, maar dit staat ook zo vermeld in het TransIP paneel, dat dit zo is. Stel ik het niet in, pakt hij dit ook zelf.
ip route show kan ik nu even niet doen, heb vanaf hier geen toegang tot de server ( geen wachtwoorden paraat )
Heb je dit subnetmask zelf zo ingesteld of krijg je dat via DHCP/van TransIP?
Als je dit zelf hebt ingesteld dan kan ik me voorstellen dat dit de oorzaak van je probleem is. Als een IP een broadcast doet naar een adres wat geen broadcast adres is, dan gaat het niet werken lijkt me.
Ik heb geen ervaring met meerdere IP adressen op een hosted server/vps maar als ik een DSL lijn aanvraag met meerdere IP adressen, dan krijg ik bijvoorbeeld 255.255.255.248 als subnet mee.
Verder kan een "ip route show" commando ons wellicht ook wat meer inzicht geven.
Dat gaat niet zo hard mis. Subnet broadcasts worden niet zo veel gebruikt door servers, zeker niet door systemen die feitelijk niks met hun buren van doen hebben, zoals een gehoste server. (dingen als windows workgroups, sommige printer discovery protocollen e.d. gebruiken broadcasts).
Historisch wordt dan ook nog vaak een 'globale broadcast' gedaan (255.255.255.255), en dat is 'altijd goed'
Waar het wel een beetje mis kan gaan is in het bereiken van systemen die volgens jouw subnet mask 'lokaal' zijn, maar in werkelijkheid via de gateway router moeten omdat het subnet kleiner is dan je ingesteld hebt.
Jouw systeem doet dan een arp request voor het mac adres van een ip binnen het (volgens jou) lokale subnet, en daar hoort niemand op te antwoorden omdat dat IP niet lokaal is. Je had het naar de default gateway moeten sturen (en voor diens mac adres arpen ).
Ik schrijf 'hoort' omdat de gateway router proxy arp zou kunnen doen (moet uit, staat niet altijd uit) en op die manier kan het toch redelijk werken.
Ook dit valt niet meteen op, omdat een gehoste server niet zo vaak wat met andere servers in hetzelfde subnet doet (-als dat wel zo is, zijn het vaak je eigen servers en heb je wellicht ook daar het subnetmask op dezelfde manier verkeerd staan - en werkt het toch ).
Ook een thuisgebruiker merkt niet zo snel dat IP met een paar honderd ip-buren niet werkt. Bijna het hele internet is wel bereikbaar.
Andersom, heb je het subnet kleiner ingesteld dan de realiteit, is de impact ook beperkt tot nabije IP adressen, nl die wel in werkelijkheid in het subnet zitten, maar volgens je config fout erbuiten.
De gateway, waar je dan je verkeer onterecht naar toe stuurt, zal het (eventueel) routeren - weer het subnet in dus, en zal ook ICMP redirect te sturen .
Kortom, niet optimaal , maar zolang de default gateway wel binnen het ingestelde subnet valt hoef je een verkeerd netmask niet meteen te ontdekken.
MaartenPol
29/01/14, 10:26
Volgens TransIP zit er geen blokkade op het IP en zou het toch iets op de server moeten zijn. Kan het liggen aan de instellingen van eth0?
DEVICE="eth0"
ONBOOT=yes
TYPE="Ethernet"
HWADDR=52:54:00:fd:60:0d
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=yes
NAME="System eth0"
BOOTPROTO=static
IPADDR=149.210.135.200
GATEWAY=149.210.135.1
NETMASK=255.255.255.0
IPV6INIT=yes
IPV6ADDR=2a01:7c8:aab2:22a::1/48
IPV6_DEFAULTGW=2a01:7c8:aab2::1
IPV6ADDR_SECONDARIES=""
en dan in combinatie met eth0:1
DEVICE=eth0:1
BOOTPROTO=static
IPADDR=149.210.135.33
ONBOOT=yes
ONPARENT=yes
NETMASK=255.255.255.0
IPV6INIT=no
Ik heb natuurlijk ook verder gezocht en kwam nog wat tegen over NetworkManager, dat deze de boel in de war kan schoppen, maar dit heb ik er niet op staan.
Volgens TransIP zit er geen blokkade op het IP en zou het toch iets op de server moeten zijn. Kan het liggen aan de instellingen van eth0?
DEVICE="eth0"
ONBOOT=yes
TYPE="Ethernet"
HWADDR=52:54:00:fd:60:0d
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=yes
NAME="System eth0"
BOOTPROTO=static
IPADDR=149.210.135.200
GATEWAY=149.210.135.1
NETMASK=255.255.255.0
IPV6INIT=yes
IPV6ADDR=2a01:7c8:aab2:22a::1/48
IPV6_DEFAULTGW=2a01:7c8:aab2::1
IPV6ADDR_SECONDARIES=""
en dan in combinatie met eth0:1
DEVICE=eth0:1
BOOTPROTO=static
IPADDR=149.210.135.33
ONBOOT=yes
ONPARENT=yes
NETMASK=255.255.255.0
IPV6INIT=no
Ik heb natuurlijk ook verder gezocht en kwam nog wat tegen over NetworkManager, dat deze de boel in de war kan schoppen, maar dit heb ik er niet op staan.
Daar zie ik echt niets mis staan.
Ping eens naar andere hosts in het subnet, met je primaire en met je tweede IP adres ?
(even test met je primaire ip, of van buiten, welke IPs in je subnet in gebruik zijn ).
Kijk dan ook mee met tcpdump, en let ook op wat je als mac adres ziet van de buren.
(ik zou een capture maken - "tcdump -s0 -ni eth0 -w /tmp/ping-test.pcap icmp or arp " , en die met wireshark bekijken )
MaartenPol
29/01/14, 11:22
Daar zie ik echt niets mis staan.
Ping eens naar andere hosts in het subnet, met je primaire en met je tweede IP adres ?
(even test met je primaire ip, of van buiten, welke IPs in je subnet in gebruik zijn ).
Kijk dan ook mee met tcpdump, en let ook op wat je als mac adres ziet van de buren.
(ik zou een capture maken - "tcdump -s0 -ni eth0 -w /tmp/ping-test.pcap icmp or arp " , en die met wireshark bekijken )
Ik had tcpdump nog niet lopen, maar pingen naar m'n buurman:
ping -I 149.210.135.33 149.210.135.3
PING 149.210.135.3 (149.210.135.3) from 149.210.135.33 : 56(84) bytes of data.
64 bytes from 149.210.135.3: icmp_seq=1 ttl=64 time=1.86 ms
64 bytes from 149.210.135.3: icmp_seq=2 ttl=64 time=0.483 ms
64 bytes from 149.210.135.3: icmp_seq=3 ttl=64 time=0.441 ms
64 bytes from 149.210.135.3: icmp_seq=4 ttl=64 time=0.482 ms
64 bytes from 149.210.135.3: icmp_seq=5 ttl=64 time=0.504 ms
Dat werkt dus gewoon. Ik denk dat ik nu eens boos ga worden.
MaartenPol
30/01/14, 18:01
We zijn eruit, de technische dienst heeft gekeken en ontdekt dat er ergens nog een oude, handmatige blokkade op het IP adres stond die verder nergens op te sporen was. Nu die eruit is, werkt het allemaal probleemloos.
Mag ik jullie bedanken voor het testen, en uitvogelen waar het probleem zat.