5
PPPoE LCP Link Up
Problem nach Austausch einer SonicWALL
Hallo,
habe beim Kunden eine SonicWALL TZ180 gegen eine SonicWALL TZ215 ausgetauscht.
Nun bekomme ich keine (feste) Verbindung am WAN-Interface zustande (PPPoE).
Könnte das mit der Einstellung LinkSpeed am WAN-Interface zusammenhängen? Eingestellt ist "AutoNegotiate", möglich sind noch 10Mbps, 100Mbps Full und Half-Duplex.
Das Log sieht etwa so aus:
Kennt jemand das Problem?
Hilft LinkSpeed 10Mbps Halfduplex und MTU 1492 ?
Mein Problem, die SonicWALL ist beim Kunden, der ist weit weg und hat von der Materie keine Ahnung, muss ihn dann telefonisch navigieren...
Kann somit nicht viel 'probieren'.
Freu mich über eure Hilfe.
Gruß
LS
habe beim Kunden eine SonicWALL TZ180 gegen eine SonicWALL TZ215 ausgetauscht.
Nun bekomme ich keine (feste) Verbindung am WAN-Interface zustande (PPPoE).
Könnte das mit der Einstellung LinkSpeed am WAN-Interface zusammenhängen? Eingestellt ist "AutoNegotiate", möglich sind noch 10Mbps, 100Mbps Full und Half-Duplex.
Das Log sieht etwa so aus:
time="2012-04-27 00:46:10" fw=0.0.0.0 pri=6 c=1 m=593 msg="Received PPPoE Active Discovery Offer" n=1
time="2012-04-27 00:46:10" fw=0.0.0.0 pri=6 c=1 m=595 msg="Sending PPPoE Active Discovery Request" n=1
time="2012-04-27 00:47:10" fw=0.0.0.0 pri=6 c=1 m=127 msg="Starting PPPoE discovery" n=4
time="2012-04-27 00:47:49" fw=0.0.0.0 pri=6 c=1 m=593 msg="Received PPPoE Active Discovery Offer" n=2
time="2012-04-27 00:47:49" fw=0.0.0.0 pri=6 c=1 m=595 msg="Sending PPPoE Active Discovery Request" n=4
time="2012-04-27 00:47:49" fw=0.0.0.0 pri=6 c=1 m=594 msg="Received PPPoE Active Discovery Session_confirmation" n=1
time="2012-04-27 00:47:49" fw=0.0.0.0 pri=6 c=1 m=133 msg="PPPoE discovery process complete" n=1
time="2012-04-27 00:47:49" fw=0.0.0.0 pri=6 c=0 m=295 msg="PPP: Starting PAP authentication" n=1
time="2012-04-27 00:47:50" fw=0.0.0.0 pri=6 c=0 m=289 msg="PPP: Authentication successful" n=1
time="2012-04-27 00:47:50" fw=0.0.0.0 pri=6 c=1 m=128 msg="PPPoE LCP Link Up" n=1
time="2012-04-27 00:48:30" fw=80.153.89.181 pri=6 c=1 m=131 msg="PPPoE Network Connected" n=1
time="2012-04-27 00:48:46" fw=0.0.0.0 pri=6 c=1 m=738 msg="PPPoE Client: Previous session was connected for 0 Days, 0 Hours, 0 Minutes, 56 Seconds " n=1
time="2012-04-27 00:48:46" fw=0.0.0.0 pri=6 c=1 m=132 msg="PPPoE Network Disconnected" n=1
time="2012-04-27 00:50:24" fw=80.153.89.181 pri=6 c=1 m=131 msg="PPPoE Network Connected" n=2
time="2012-04-27 00:55:21" fw=0.0.0.0 pri=6 c=1 m=168 msg="Disconnecting PPPoE due to traffic timeout" n=1
time="2012-04-27 00:55:21" fw=0.0.0.0 pri=6 c=1 m=132 msg="PPPoE Network Disconnected" n=2
time="2012-04-27 00:55:21" fw=0.0.0.0 pri=6 c=1 m=738 msg="PPPoE Client: Previous session was connected for 0 Days, 0 Hours, 7 Minutes, 31 Seconds " n=2
time="2012-04-27 00:55:21" fw=0.0.0.0 pri=6 c=1 m=129 msg="PPPoE LCP Link Down" n=1
time="2012-04-27 00:55:24" fw=0.0.0.0 pri=6 c=1 m=127 msg="Starting PPPoE discovery" n=8
time="2012-04-27 00:55:24" fw=0.0.0.0 pri=6 c=1 m=593 msg="Received PPPoE Active Discovery Offer" n=3
time="2012-04-27 00:55:24" fw=0.0.0.0 pri=6 c=1 m=595 msg="Sending PPPoE Active Discovery Request" n=5
time="2012-04-27 00:56:43" fw=0.0.0.0 pri=6 c=1 m=127 msg="Starting PPPoE discovery" n=10
time="2012-04-27 00:57:48" fw=0.0.0.0 pri=6 c=1 m=127 msg="Starting PPPoE discovery" n=14
time="2012-04-27 00:58:48" fw=0.0.0.0 pri=6 c=1 m=127 msg="Starting PPPoE discovery" n=18
time="2012-04-27 00:59:29" fw=0.0.0.0 pri=6 c=1 m=593 msg="Received PPPoE Active Discovery Offer" n=4
time="2012-04-27 00:59:29" fw=0.0.0.0 pri=6 c=1 m=595 msg="Sending PPPoE Active Discovery Request" n=8
time="2012-04-27 00:59:29" fw=0.0.0.0 pri=6 c=1 m=594 msg="Received PPPoE Active Discovery Session_confirmation" n=2
time="2012-04-27 00:59:29" fw=0.0.0.0 pri=6 c=1 m=133 msg="PPPoE discovery process complete" n=2 Kennt jemand das Problem?
Hilft LinkSpeed 10Mbps Halfduplex und MTU 1492 ?
Mein Problem, die SonicWALL ist beim Kunden, der ist weit weg und hat von der Materie keine Ahnung, muss ihn dann telefonisch navigieren...
Kann somit nicht viel 'probieren'.
Freu mich über eure Hilfe.
Gruß
LS
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 184375
Url: https://administrator.de/contentid/184375
Printed on: April 18, 2024 at 12:04 o'clock
5 Comments
Latest comment
Die Sonicwall hat kein integriertes Modem, richtig ?? Du arbeitest also mit einem externen Modem.
Das sollte immer auf Fulldup negotiaten denn Fullduplex ist Standard. Die Zeiten von Halfduplex sind längst vorbei, vergiss das also.
Du kannst mit dem entsprechenden "show" Kommando auf der Sonicwall ja sehen wie der Port mit dem Modem negotiated.
Da Modems in der Regel nur 100 Mbit machen sollte der Anschluss immer auf 100, Fullduplex stehen !
Du kannst ihn fest auf 100 Mbit, Fulldup einstellen, da fixt dir aber nur rein physische Autonegotiation Probleme zwischen Modem und Firewallport.
Sehr viel wichtiger ist der MTU Wert bzw. der MSS Wert auf dem Interface. Der muss zwingend auf 1492 angepasst werden sonst kann es zu Encapsulation Mismatches kommen mit dem dahinterliegenden DSL Netz was auf ATM basiert.
Wie immer solltest du dir mal genauer deine Log Fehlermeldungen ansehen was du vermutlich noch gar nicht gemacht hast !!!
Wer lesen kann und will....
Dort steht doch ganz groß ""Disconnecting PPPoE due to traffic timeout"
Fazit: Die PPPoE Session wird runtergenommen weil der Idle Timer zuschlägt, da 7 Minuten keinerlei Traffic über den DSL Anschluss gelaufen ist.
DAS ist also dein eigentliches Problem und weder MTU (obwohl diese Einstellung zwingend ist...) oder Negotiation Probleme.
Letztere können es auch niemals sein denn sonst wäre logischerweise niemals eine LCP Session zustandegekommen und schon vorher an der Physik Schluss.... also denk auch erstmal ein bischen logisch nach bevor du im Blindflug alles rumprobierst was dir in den Sinn kommt !!
Das sollte immer auf Fulldup negotiaten denn Fullduplex ist Standard. Die Zeiten von Halfduplex sind längst vorbei, vergiss das also.
Du kannst mit dem entsprechenden "show" Kommando auf der Sonicwall ja sehen wie der Port mit dem Modem negotiated.
Da Modems in der Regel nur 100 Mbit machen sollte der Anschluss immer auf 100, Fullduplex stehen !
Du kannst ihn fest auf 100 Mbit, Fulldup einstellen, da fixt dir aber nur rein physische Autonegotiation Probleme zwischen Modem und Firewallport.
Sehr viel wichtiger ist der MTU Wert bzw. der MSS Wert auf dem Interface. Der muss zwingend auf 1492 angepasst werden sonst kann es zu Encapsulation Mismatches kommen mit dem dahinterliegenden DSL Netz was auf ATM basiert.
Wie immer solltest du dir mal genauer deine Log Fehlermeldungen ansehen was du vermutlich noch gar nicht gemacht hast !!!
Wer lesen kann und will....
Dort steht doch ganz groß ""Disconnecting PPPoE due to traffic timeout"
Fazit: Die PPPoE Session wird runtergenommen weil der Idle Timer zuschlägt, da 7 Minuten keinerlei Traffic über den DSL Anschluss gelaufen ist.
DAS ist also dein eigentliches Problem und weder MTU (obwohl diese Einstellung zwingend ist...) oder Negotiation Probleme.
Letztere können es auch niemals sein denn sonst wäre logischerweise niemals eine LCP Session zustandegekommen und schon vorher an der Physik Schluss.... also denk auch erstmal ein bischen logisch nach bevor du im Blindflug alles rumprobierst was dir in den Sinn kommt !!
Hallo aqui,
vielen Dank für die ausführlichen Infos. Ja, die SW hängt an einem Modem. Werde übermorgen mal schaun, ob ich Erfolg habe.
Schönen Abend
LS
vielen Dank für die ausführlichen Infos. Ja, die SW hängt an einem Modem. Werde übermorgen mal schaun, ob ich Erfolg habe.
Schönen Abend
LS
Übermorgen ist vorbei und wenn es das denn nun war bitte
How can I mark a post as solved?
nicht vergessen.
How can I mark a post as solved?
nicht vergessen.
Hallo,
werde sie Sonicwall noch einmal selbst (nicht beim Kunden) testen.
vG
LS
werde sie Sonicwall noch einmal selbst (nicht beim Kunden) testen.
vG
LS
Hallo,
ich wollte mal abschließend noch schreiben, was nun daraus geworden ist.
Nach einem Firmwareupdate der Sonicwall war das Problem komplett gelöst.
Gruß
LS
ich wollte mal abschließend noch schreiben, was nun daraus geworden ist.
Nach einem Firmwareupdate der Sonicwall war das Problem komplett gelöst.
Gruß
LS
