aktion licht ins dunkel...
hallo i386, hallo gandlz,
i386, meine aussage von früher...
"...faktum ist, daß beim gandlz, der bei der umstellung den offiziellen weg gegangen ist, das bridging funkt..."...gilt nimmer. der gandlz hat von demselben prob wie du berichtet:
viewtopic.php?f=20&t=56479&p=468785&#p468782nachdem jetzt 4 wirklich verschiedene router von 2 leuten angetestet wurden und von einem gerät sogar ein quervergleich an einem ta-anschluß vorliegt, dürfte das prob bei tele2 liegen, und da denk ich gar nicht so sehr ans comtrend, sondern eher an die interne netz- bzw. infrastruktur von tele2.
die vorschläge, die jetzt kommen werden, dienen nur dazu, informationen für die tecs von tele2 herauszuschälen, sodaß sie sich bei der problembehebeung leichter tun, und wenn ihr schwein habt, könnt ihr schon von außen das prob so stark eingrenzen, daß die behebeung nur noch ein klacks ist.
0. grundsätzliches
- meine vorschläge sind für openwrt und dd-wrt gedacht und sollten mit diesen sws auch funken.
- gemeinsam arbeiten und testergebnisse vergleichen. manchmal gibts kleine unterschiede, die sehr aufschlußreich sein können. werd auf dieses thema am ende meines posts noch zurückkommen.
1. i386, dein 2. user ("bridgeuser") erinnert mich an ein ziemlich nerviges prob,,..
...das ein user vor längerer zeit mit seinem xpirio-zugang hatte.
das inet funkte net sauber und die situation damals war genau so diffus wie eure heute. ich ging der sache nach und sah mit traceroute auf die ip des user eine routing loop im netz von xpirio. damit war das prob schon ziemlich eingegrenzt, aber noch nicht gelöst, weil die diskussionen mit den tecs von xpirio auf ein patt hinausliefen:
auf der einen seite schlossen die routing experten von xpirio routing loops in ihren netzen völlig aus, auf der andren seite gabs aber doch die traces mit der loop, die auch von xpirio reproduziert werden konnten. uns allen ging der schmäh aus, und ein tec schlug als last resort brainstorming vor. ich solle ein mail mit problembeschreibung, testergebnissen und, sehr wichtig, allen ungereimtheiten, auffälligkeiten und fragen, die mir im zusammenhang mit dem prob in den sinn kämen, an eine bestimmte mail-addr, die für schwierige probs vorgesehen war und auf die alle tecs von xpirio zugreifen konnten, schicken. wirklich überzeugt war ich von dem ansatz nicht, schickte aber mangels alternativen doch ein mail an die angegebene adresse. damit war die sache für mich vorerst mal erledigt, ich stellte mich geistig auf eine längere bearbeitungszeit- tage, wenn nicht gar wochen- ein und war mehr als überrascht, als der tec, der das brainstorming vorgeschlagen hatte, bereits nach 1, 2 stunden! zurückrief und mir mitteilte, daß der user 2 zugangsdatensätze habe und mit dem falschen unterwegs sei. er müsse die "andren" zugangsdaten nehmen.
tjo, und das wars dann auch wirklich:
http://www.dieschmids.at/forum/4-fragen ... art=0#7720ingesamt hat die ganze aktion grad mal ein paar stunden gedauert, was auf die klasse des ehemaligen xpirio support
und die flache organisationsstruktur, typisch für kleinprovider, zurückzuführen ist. bei tele2 werdet ihr euch etwas wärmer anziehen müssen, das is'n großprovider mit opulenten organisations- und verwaltungsstrukturen...
meine fragen in diesem zusammenhang:
i386:
wozu ist der "bridgeuser" gut? hast du schon versucht, mit diesem user einzuwählen (falls er kein eigenes pw hat, das pw vom standarduser nehmen)?
und wenn die einwahl gelingt, was passiert dann?
gandlz:
falls du auch einen 2. user hast, denselben versuch durchführen.
2. traceroute vor und nach dem bruch durchführen
targets sind der acs, den du, i386, nach dem bruch noch pingen kannst, und externe destinations.
mit der aktion sollen 2 fragen geklärt werden:
- ändert sich das routing im netz von tele2 nach dem bruch?
- seht ihr routing loops oder black holes nach dem bruch im netz von tele2?
3. ips und routen an *euren* routern vor und nach dem bruch vergleichen/dokumetieren
ich geh davon aus, daß da genau nix passieren wird, weil bereits 4 spielzeuge getestet wurden. für die leute von tele2 ist das aber nicht so klar, und es besteht die gefahr, daß sie ihre routing probs auf euch abwälzen.
also einfach vor und nach dem bruch...:
- Code: Alles auswählen
> ip a
> ip r
...machen und die outputs in eine datei kopieren. tut nicht weh...
4. und jetzt das sahnehäubchen: ppp debugging
es ist sehr wichtig zu wissen, ob vor dem bruch irgendwas auf ppp-ebene passiert oder ob der bruch quasi aus "heiterem himmel passiert".
der debugging mode kann beim pppd ganz einfach mit SIGUSR1 dynamisch aktiviert und deaktiviert werden. blöderweise werden im debug mode all die lcp echoreqs und lcp echoreps, die in schöner regelmäßigkeit rein- und rausgehen, mitgeloggt, sodaß die log buffers von kleinen routern innerhalb kurzer zeit komplett zugemüllt werden und man nichts mehr sieht.
bei periodischen probs kann man diesem flooding ausweichen, indem man das debugging mit einem cronjob ein paar minuten vor dem vorhersehbaren, kritschen zeitpunkt aktiviert und ein paar minuten danach wieder deaktiviert.
bei aperiodischen ereignissen, und diese situation liegt bei euch vor, ist der kritische zeitpunkt nicht vorhersehbar und man muß zwangsläufig auf dauer-debugging gehen. und um da diese informationsflut abzufangen, gibts nur 2 möglichkeiten:
- externer syslog-server mit hinreichend großer speicherkapazität.
- konsolenpuffer auf "unendlich" stellen und direkt über die konsolensitzung mit "tail -f" die logs mitverfolgen.
variante #2 ist einfacher, und ich spiel sie jetzt mal kurz beispielhaft durch:
i. konsolensitzung (telnet, ssh) starten.
ii. konsolenpuffer hochschrauben.
iii. ppp debugging aktivieren:
- Code: Alles auswählen
# mit ps die pid vom pppd ermitteln:
> ps
# danach debugging aktivieren mit:
> kill -SIGUSR1 <pid-von-pppd>
iv. link-control zur markierung des kritischen ereignisses setzen:
pings auf eine zuverlässige ip loslassen, die entweder über einen cronjob gesteuert werden oder eine ordinäre
while-schleife:
- Code: Alles auswählen
> # ich nehm als ping target einen der 2 alten timeserver der uni wien (131.130.1.11, 131.130.1.12),
# die dinger funken sehr zuverlässig.
> while : ; do ping -c 1 131.130.1.11 >/dev/null || logger -p error "*** WAN link down ***"; sleep 60; done &
# ausgabe ist die pid des hintergrundprozesses, mit der ihr die while-schleife nach beendigung des tests killen könnt
# oder ihr macht halt einfach
> kill %1
v. log tracing anwerfen mit:
- Code: Alles auswählen
> tail -f /var/log/messages
vi. danach einfach nur die logs mit der msg "*** WAN link down ***" abwarten und die while-schleife samt ppp debugging stoppen.
5. wenn ihr das alles habt, gibts- tata-tata- den auftritt bei tele2- ***GEMEINSAM!***
es gilt das motto:"einmal is keinmal, zweimal ist oft".
und dieses motto is grad in der it sehr ernstzunehmen: wenn ihr auf einem egotrip seid, dann läuft ihr gefahr, als (trauriges) einzelschicksal abgetan zu werden. wenn ihr hingegen euer problem fundiert bündelt, dann habt ihr gute chancen, von einem großunternehmen kaliber tele2 wahrgenommen zu werden, und das is nun mal der erste schritt in die richtige richtung...
m2c & lg
zid
Verfasst: Mo 09 Feb, 2015 18:59
.
