Onderwerp: Add ip werkt niet?

Oorspronkelijk geplaatst door Mark17

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.

Ik ga het bij ze neerleggen.. Ik houd jullie op de hoogte.

Oorspronkelijk geplaatst door getUP

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 ?

Oorspronkelijk geplaatst door MaartenPol

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.

Oorspronkelijk geplaatst door visser

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.

Oorspronkelijk geplaatst door getUP

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'.

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.

Oorspronkelijk geplaatst door visser

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.

Oorspronkelijk geplaatst door blaataap

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.

Oorspronkelijk geplaatst door visser

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.

Oorspronkelijk geplaatst door blaataap

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.

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

Code:

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

Code:

DEVICE=eth0:1
BOOTPROTO=static
IPADDR=149.210.135.33
ONBOOT=yes
ONPARENT=yes
NETMASK=255.255.255.0
IPV6INIT=no

Oorspronkelijk geplaatst door MaartenPol

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

Code:

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

Code:

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 )

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

Code:

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.