Onderwerp: Add ip werkt niet?

Oorspronkelijk geplaatst door MaartenPol

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.

Dan ligt de bal nu echt bij TransIP.
(even aangenomen dat met je primaire IP een ping naar de default gateway wel werkt ? )

Oorspronkelijk geplaatst door visser

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.

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.

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 )

Oorspronkelijk geplaatst door Patrick_st

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.

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?

Code:

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

Code:

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.

Oorspronkelijk geplaatst door MaartenPol

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?

Code:

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

Code:

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 )

Oorspronkelijk geplaatst door visser

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:

Code:

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.

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.