PDA

Bekijk Volledige Versie : Server onbereikbaar voor adsl gebruikers



joelouburg
24/04/13, 18:48
since een paar dagen kamp ik met mijn server met een gek probleem.

een paar keer per dag is mijn server onbereikbaar voor adsl gebruikers maar voor kabel of 3G of dsl vanuit het buitenand blijft de server gewoon bereikbaar. nadat de server een reboot heeft gekregen is deze wel weer gewoon via adsl te bereiken en gaat het weer een paar uur goed.

heb hier nu zo'n week last van en ontstond nadat snachts de server onbereikbaar was voor alle verbindingen toen zijn ze in het datacenter er achter gekomen dat er een bug was in een sisco router waar ze een workaround op hebben toegepast toen deed alles het weer voor 2 dagen maar nu dus om de paar uur wordt de server onbereikbaar voor alleen adsl gebruikers.

weet iemand wat dit zou kunnen zijn ?

visser
24/04/13, 19:09
since een paar dagen kamp ik met mijn server met een gek probleem.

een paar keer per dag is mijn server onbereikbaar voor adsl gebruikers maar voor kabel of 3G of dsl vanuit het buitenand blijft de server gewoon bereikbaar. nadat de server een reboot heeft gekregen is deze wel weer gewoon via adsl te bereiken en gaat het weer een paar uur goed.

heb hier nu zo'n week last van en ontstond nadat snachts de server onbereikbaar was voor alle verbindingen toen zijn ze in het datacenter er achter gekomen dat er een bug was in een sisco router waar ze een workaround op hebben toegepast toen deed alles het weer voor 2 dagen maar nu dus om de paar uur wordt de server onbereikbaar voor alleen adsl gebruikers.

weet iemand wat dit zou kunnen zijn ?

Alle adsl gebruikers ? Er zijn wat verschillende netwerken.
Wat is de server (naam/ip)
OS van de server
Controleer je ip/subnetmask en default gateway instelling extra.


[ga je ook naar de dokter met de vraag 'ik heb ergens last van, wat kan dat zijn ' ? ]

Heb je al eens gedebugged toen het probleem aan de gang was ?
ping naar de server (vanaf een probleem adsl, en vanaf een werkende aansluiting)
traceroute naar de server (vanaf een probleem adsl, en vanaf een werkende aansluiting)

En tcp dump op de server draaien en kijken wat je qua ip verkeer van een niet-werkende adsl aansluiting ziet binnenkomen (moet je die hebben, of iemand die met je test vanaf een adsl die 'het niet doet' op dat moment. )

joelouburg
24/04/13, 19:27
als de storing zich voor deed heb ik het getests via de volgende netwerken.

os unbuntu 12.4 met plesk 11 admin
server heeft since november gewoon goed gedraait en is er aan de ip/subnet of default gatewy niet gesleuteld.

netwerken met storing:

kpn adsl
wanadoo / online adsl

netwerken zonder storingen:

upc horizon vanaf 2 locaties
3G t-mobile
3G ben
At&t uverse dsl usa

tijdens de storing ingelogs via idrac dit loopt via ander netwerk ander netwerk van het datacenter en blijft op alles werken

server is gewoon online kan ook naar buiten pingen naar bijv. google zonder probleemen

alleen acces_log is dan wat rustiger

pingen naar de server gaat gewoon goed via de werkende netwerken maar gaan in een timeout via de geteste adsl verbindingen

trace route op de nog wel werkende verbindingen is niets te zien via adsl is de server ip niet te vinden en gaat in timeout

Pantsy
24/04/13, 19:34
Als ik jou was zou ik dit probleem neerleggen bij je netwerk leverancier, klinkt als bepaalde routes die fout of vol lopen. Zal hoogstwaarschijnlijk niet server gerelateerd zijn.

systemdeveloper
24/04/13, 19:40
Niet toevallig dat je csf oid hebt draaien en gewoon hele subnets blocked? Het kan aan je netwerkboer liggen, maar het is wel toevallig dat het direct weer werkt na een reboot zonder iets van faiilover oid bij het dc waardoor je route anders loopt.

joelouburg
24/04/13, 19:41
i vermoede dit zelf ook, ook doordat het dus ontstaan is nadat een router bij het datacenter een bug had en alles het weer deed voor 2 dagen. alleen is het dan weer gek dat een server reboot tijdelijk het probleem verhelpt aan de andere kant als het aan de server zo liggen zou je denken dan loopt ie gewoon vast en is ie nergens te bereiken of zou dan de reboot de route tijdelijk ontlasten zodat het weer werkt ?

visser
24/04/13, 20:53
als de storing zich voor deed heb ik het getests via de volgende netwerken.

os unbuntu 12.4 met plesk 11 admin
server heeft since november gewoon goed gedraait en is er aan de ip/subnet of default gatewy niet gesleuteld.

netwerken met storing:

kpn adsl
wanadoo / online adsl

netwerken zonder storingen:

upc horizon vanaf 2 locaties
3G t-mobile
3G ben
At&t uverse dsl usa

tijdens de storing ingelogs via idrac dit loopt via ander netwerk ander netwerk van het datacenter en blijft op alles werken

server is gewoon online kan ook naar buiten pingen naar bijv. google zonder probleemen

alleen acces_log is dan wat rustiger

pingen naar de server gaat gewoon goed via de werkende netwerken maar gaan in een timeout via de geteste adsl verbindingen

trace route op de nog wel werkende verbindingen is niets te zien via adsl is de server ip niet te vinden en gaat in timeout

"de ip niet te vinden en gaat in timeout " ...
Hoe ver komt een traceroute vanaf een niet-werkende adsl naar de server , gaat dat een heel eind goed , tot aan je datacenter en dan pas timeout ?
Of gaat het bij zo'n beetje de eerste hop in het dsl netwerk al mis ?
(cut & paste van de output liefst)
traceroute naar hostnaam, of naar IP ?

En een traceroute terug op dat moment, vanaf je server naar een dsl aansluiting, hoe ver komt die als het probleem er is, en hoe loopt de traceroute normaal naar die dsl als het wel werkt ?

Overigens, als het zich oplost met een reboot van de server zit het waarschijnlijk toch ergens in de server, of heel misschien iets tussen server en 1e gateway router.

visser
24/04/13, 20:56
i vermoede dit zelf ook, ook doordat het dus ontstaan is nadat een router bij het datacenter een bug had en alles het weer deed voor 2 dagen. alleen is het dan weer gek dat een server reboot tijdelijk het probleem verhelpt aan de andere kant als het aan de server zo liggen zou je denken dan loopt ie gewoon vast en is ie nergens te bereiken of zou dan de reboot de route tijdelijk ontlasten zodat het weer werkt ?

Zo werkt routing niet, een server reboot heeft geen effect buiten het subnet.
De enige vage netwerk theorie die ik kan verzinnen zijn verkeerde subnets (of routes) die 'werken' vanwege icmp redirects of proxy arp.
Maar goed, zonder echte informatie blijven het slagen in de lucht.

joelouburg
24/04/13, 21:26
"de ip niet te vinden en gaat in timeout " ...
Hoe ver komt een traceroute vanaf een niet-werkende adsl naar de server , gaat dat een heel eind goed , tot aan je datacenter en dan pas timeout ?
Of gaat het bij zo'n beetje de eerste hop in het dsl netwerk al mis ?
(cut & paste van de output liefst)
traceroute naar hostnaam, of naar IP ?

En een traceroute terug op dat moment, vanaf je server naar een dsl aansluiting, hoe ver komt die als het probleem er is, en hoe loopt de traceroute normaal naar die dsl als het wel werkt ?

Overigens, als het zich oplost met een reboot van de server zit het waarschijnlijk toch ergens in de server, of heel misschien iets tussen server en 1e gateway router.


zal zodra het probleem weer voor doet effies pingen en traceroute uitvoeren vanaf en naar de server en deze hier posten voordat ik de server reboot

visser
24/04/13, 23:39
zal zodra het probleem weer voor doet effies pingen en traceroute uitvoeren vanaf en naar de server en deze hier posten voordat ik de server reboot

Thx.
Geef dan ook nog (op je server) de volgende commando's als root en bewaar de output :

ip link show
ip addr show
ip route show
ip neigh show
iptables -nvL

(of :
ifconfig -a
route -v
arp -na
iptables -nvL
)
(je kiijkt daarmee naar ip adres/subnet die op je interface(s) staan, de arp table, de routing table en eventuele iptables (firewall) rules .)

Je kunt het nu trouwens ook doen, dan heb je ook een voorbeeld van hoe het eruit ziet als er geen probleem is.
Op een 'gewone' server verwacht je van qua routes en arp table maar heel weinig , eigenlijk alleen een local subnet route en een default route , voor het internet-facing interface. En ook maar weinig arp entries.

Als je op een thuis-systeem ook linux draait kijk dan ook even hoe dat eruit ziet qua routes en interface. Dat zou zeker erg eenvoudig moeten zijn qua netwerk config (en dus output).

joelouburg
25/04/13, 00:40
onderstaand de gegevens als het systeem gewoon bereikbaar is

ip link show

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 90:b1:1c:19:db:6a brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 90:b1:1c:19:db:6b brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether a0:36:9f:06:98:da brd ff:ff:ff:ff:ff:ff
5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether a0:36:9f:06:98:db brd ff:ff:ff:ff:ff:ff

ip addr show

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 90:b1:1c:19:db:6a brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 90:b1:1c:19:db:6b brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether a0:36:9f:06:98:da brd ff:ff:ff:ff:ff:ff
inet 83.247.4.244/24 brd 83.247.4.255 scope global eth2
inet6 fe80::a236:9fff:fe06:98da/64 scope link
valid_lft forever preferred_lft forever
5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether a0:36:9f:06:98:db brd ff:ff:ff:ff:ff:ff

ip route show

default via 83.247.4.1 dev eth2 metric 100
83.247.4.0/24 dev eth2 proto kernel scope link src []


ip neigh show

83.247.4.1 dev eth2 lladdr 50:00:10:00:10:60 REACHABLE

iptables -nvL

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

visser
25/04/13, 01:21
onderstaand de gegevens als het systeem gewoon bereikbaar is

knip netwerk config


Dat ziet er nu in elk geval prima uit, 1x IPv4 in een /24 subnet met een default gateway, en alleen een arp entry voor de default gateway.
(en op moment ook prima te tracerouten vanaf adsl, en vanaf niet-adsl ).

joelouburg
25/04/13, 01:35
nu effies afwachten een colega had eerder een reboot gedaan voordat ik het in down situatie kon testen

joelouburg
25/04/13, 13:45
hierbij een test tijdens dat het probleem zich voor deed

alle config was het zelfde tijdens goede staat

alleen ip route show geeft wat anders

83.247.4.1 dev eth2 lladdr 50:00:10:00:10:60 REACHABLE
83.247.4.254 dev eth2 lladdr c4:7d:4f:6b:f4:80 STALE


en onderstaande de traceroute naar de server tijdens het probleem

1 52 ms 98 ms 101 ms static.kpn.net [194.121.231.49]
2 19 ms 19 ms 21 ms 195.190.243.14
3 * * * Time-out bij opdracht.
4 23 ms 23 ms 35 ms nl-asd-dc2-ice-ir01.kpn.net [139.156.112.132]
5 22 ms 22 ms 21 ms as6762-nl-asd-dc2-ice-ir01.kpn.net [193.172.217.46]
6 * * * Time-out bij opdracht.
7 26 ms 24 ms 32 ms 134.222.129.14
8 24 ms 24 ms 24 ms te-1-1.crs1.hil1.network.solcon.net [212.45.35.189]
9 32 ms 202 ms 204 ms te-1-3.crs2.ape1.network.solcon.net [212.45.35.186]
10 * * * Time-out bij opdracht.
11 * * * Time-out bij opdracht.
12 * * * Time-out bij opdracht.
13 * * * Time-out bij opdracht.
14 * * * Time-out bij opdracht.
15 * * * Time-out bij opdracht.
16 * * * Time-out bij opdracht.
17 * * * Time-out bij opdracht.
18 * * * Time-out bij opdracht.
19 * * * Time-out bij opdracht.
20 * * * Time-out bij opdracht.
21 * * * Time-out bij opdracht.
22 * * * Time-out bij opdracht.
23 * * * Time-out bij opdracht.
24 * * * Time-out bij opdracht.
25 * * * Time-out bij opdracht.
26 * * * Time-out bij opdracht.
27 * * * Time-out bij opdracht.
28 * * * Time-out bij opdracht.
29 * * * Time-out bij opdracht.
30 * * * Time-out bij opdracht.
De trace is voltooid.

DiederikL
25/04/13, 14:23
heb hier nu zo'n week last van en ontstond nadat snachts de server onbereikbaar was voor alle verbindingen toen zijn ze [b]in het datacenter[b] er achter gekomen dat er een bug was in een sisco router waar ze een workaround op hebben toegepast toen deed alles het weer voor 2 dagen maar nu dus om de paar uur wordt de server onbereikbaar voor alleen adsl gebruikers.




83.247.4.1 dev eth2 lladdr 50:00:10:00:10:60 REACHABLE
83.247.4.254 dev eth2 lladdr c4:7d:4f:6b:f4:80 STALE


Ik heb hier ook even een tracert uitgevoerd voor je, echter viel mij het volgende op:
3 gn-rc0002-cr102-irb-202.core.as9143.net (213.51.138.193) 21.280 ms 21.295 ms 21.339 ms
4 asd-tr0409-cr101-ae2-0.core.as9143.net (213.51.158.16) 23.350 ms 23.410 ms 28.914 ms
5 ams-ix1.ams1.network.solcon.net (195.69.144.165) 30.728 ms 30.386 ms 30.786 ms
6 vlan301.crs2.dro2.network.solcon.net (212.45.35.162) 33.482 ms 36.765 ms 36.664 ms
7 te-4-3.crs1.ape1.network.solcon.net (212.45.45.241) 36.581 ms 21.216 ms 21.246 ms
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * dsl-083-247-004-254.solcon.nl (83.247.4.254) 21.751 ms *

De server staat in een 'datacenter' wat aangesloten zit op een DSL lijn? Maar goed, buiten dat... De tracert die je zelf hebt uitgevoerd geeft aan dat de problemen zich voordoen binnen het netwerk van Solcon en dus dichtbij het eindput (je server) mis gaat. Het ligt dus niet bij de adsl provider(s). Uit je reacties hier kan ik niet echt opmaken dat je contact hebt gezocht met je leverancier terwijl dit al wel is aangedragen door Pantsy, waarom niet?

Daarnaast nog een kleine opmerking, het gebruik van hoofdletters (en komma's) vergroot de leesbaarheid van je teksten.

joelouburg
25/04/13, 14:26
ook is mij opgevallen dat als ip via upc een traceroute uit voer de voorlaatste hop verschilt
9 35 ms 27 ms 31 ms te-4-3.crs1.ape1.network.solcon.net [212.45.45.2
41]

met de voorlaatste hop die adsl van kpn gebruikers krijgen

9 25 ms 26 ms 23 ms te-1-3.crs2.ape1.network.solcon.net [212.45.35.1
86]

visser
25/04/13, 15:35
ook is mij opgevallen dat als ip via upc een traceroute uit voer de voorlaatste hop verschilt
9 35 ms 27 ms 31 ms te-4-3.crs1.ape1.network.solcon.net [212.45.45.2
41]

met de voorlaatste hop die adsl van kpn gebruikers krijgen

9 25 ms 26 ms 23 ms te-1-3.crs2.ape1.network.solcon.net [212.45.35.1
86]

Dat kan vrij normaal zijn.
Als Solcon de peering met UPC over een ander pad heeft lopen dan de connectie met KPN.
Het doet natuurlijk (nog meer) denken dat de oorzaak in één van de solcon routers zit.

Aangezien solcon 'dsl' in de reverse DNS van je server heeft staan wordt die naamgeving blijkbaar niet helemaal up te date gehouden.
Het zal een IP range zijn die ooit, of deels, voor dsl gebruikt wordt en waarvan ze de reverses en RIPE entry niet aangepast hebben.
Omdat de ping/trace tijd vrijwel niet hoger wordt dan de eerste hop (posting DiederikL) kun je wel zeggen het in elk geval geen dsl *is*, want zou je nog een keer +20msec zien .
Anyway, als jouw server- reverse DNS niet up to date is, kun je ook net wat minder zeker aannemen dat crs2 en crs1 aparte routers zijn. (het zijn wel andere IP adressen, maar dat kunnen ook andere interfaces op dezelfde router zijn).

Fwiw, crs{nummer} doet vermoeden dat het een Cisco CRS-1 (of CRS-3) router zal zijn (te-1-3 is dan TenGigabitEthernet1/3, ape = Apeldoorn). Dat zijn wel echte high end routers. http://www.cisco.com/en/US/products/ps5763/index.html

joelouburg
25/04/13, 15:36
Ik heb gedurende alle stappen solcon op de hoogte gebracht. Deze is ook aan het onderzoeken waar het aan kan liggen. Op basis van de gegevens die ik hun toestuur.

De server zit aan een gigabit netwerk.

joelouburg
25/04/13, 15:44
Voorop gesteld zoals ik in mijn eerste post aan gaf was er in beginsel een probleem met een Sisco router, hier heeft toen Solcon een workaround op toegepast zodat het weer werkte paar dagen later was het dus weer foute boel maar nu alleen richting ADSL.

visser
25/04/13, 15:46
hierbij een test tijdens dat het probleem zich voor deed

alle config was het zelfde tijdens goede staat

alleen ip route show geeft wat anders

83.247.4.1 dev eth2 lladdr 50:00:10:00:10:60 REACHABLE
83.247.4.254 dev eth2 lladdr c4:7d:4f:6b:f4:80 STALE


Daar zie ik nog geen relatie in met je probleem. (tenminste, het is een ip neigh show )
Dat is een arp entry die al eventjes bestaat, voor een host die in je subnet zit (je zit in een /24) .
Er is dus ietwat verkeer geweest tussen jouw server en dat .254 adres.

Als het zich oplost met een reboot van je server kun je nog proberen of het zich ook oplost als je je ethernet interface naar solcon toe even down brengt en dan weer up.
(let op dat je dat via een ilo/drac connectie doet natuurlijk) .
Daarmee gaat ook de access poort aan de kant van je ISP even down en up, en dat flusht een aantal dingen.

Maar hiermee lijkt het er nog meer op dat er gewoon iets mis is in het datacenter van je netwerk provider.
Wat je hier test kan je provider helpen zoeken,maar de oplossing moet uiteindelijk daar vandaan komen.

[knip trace die bij laatste of voorlaatste hop van de provider mis begint te lopen]
Oja : had je nog een trace vanaf jouw server naar adsl en niet-adsl toe tijdens het probleem ?

joelouburg
25/04/13, 16:08
Daar zie ik nog geen relatie in met je probleem. (tenminste, het is een ip neigh show )
Dat is een arp entry die al eventjes bestaat, voor een host die in je subnet zit (je zit in een /24) .
Er is dus ietwat verkeer geweest tussen jouw server en dat .254 adres.

Als het zich oplost met een reboot van je server kun je nog proberen of het zich ook oplost als je je ethernet interface naar solcon toe even down brengt en dan weer up.
(let op dat je dat via een ilo/drac connectie doet natuurlijk) .
Daarmee gaat ook de access poort aan de kant van je ISP even down en up, en dat flusht een aantal dingen.

Maar hiermee lijkt het er nog meer op dat er gewoon iets mis is in het datacenter van je netwerk provider.
Wat je hier test kan je provider helpen zoeken,maar de oplossing moet uiteindelijk daar vandaan komen.

[knip trace die bij laatste of voorlaatste hop van de provider mis begint te lopen]
Oja : had je nog een trace vanaf jouw server naar adsl en niet-adsl toe tijdens het probleem ?


Zal dat de volgerde ronde proberen en zien wat er gebeurd.

joelouburg
25/04/13, 19:09
Solcon geeft aan dat ze weer wat veranderd hebben aan de workaround dus wordt het afwachten of het probleem inderdaad verholpen is