1681V VDSL Login Probleme Telekom

keats · Beitrag von **keats** » 01 Okt 2012, 21:50

Hallo,

folgendes Problem: Wir haben in der Firma einen 1681V mit 8.62.0050-RU2 an VDSL 50 (feste IP) der Telekom und einer ADSL2+ Backup-Leitung von Easybell laufen.

Seit Freitag ist kein Login mehr bei der Telekom möglich. Die meiste Zeit sagt der Lancom, dass die Gegenstelle nicht antwortet. Alle paar Minuten wird dann eine Verbindung ausgehandelt und nach exakt vier angezeigten Sekunden wieder getrennt. Die Backup-Verbindung arbeitet tadellos, allerdings bricht das VPN darüber zusammen, wenn die Primärverbindung für ein paar Sekunden besteht. Vermutlich um dann die reguläre Route zu gehen....

Das ganze Problem hatten wir vor 6-8 Wochen schon mal, allerdings nur einen Tag lang. Irgendwann ging es einfach wieder.

VLAN steht auf 7, VPI/VCI auf 1/32 und die Zugangsdaten wurden sowohl über Assistenten als auch manuell neu eingegeben. Neustarts, vom Strom trennen, aktuelle Firmware haben alles nicht geholfen. Sync ist dauerhaft stabil mit jeder Menge Reserve.

Die Telekom hat einen Techniker geschickt, der sich, wenn ich es richtig verstanden habe, vom Outdoor-DSLAM aus erfolgreich einloggen konnte. Der meinte aber, er sie für Privatkunden und die Sache mit der festen IP sei nicht seins... ich meine mal irgendwo gelesen zu haben, dass das extra Login-Server sind. Kann es diesbezüglich Probleme geben? VDSL für Biz Kunden läuft bei der Telekom ja eher als Exot. Die Biz Hotline will nichts von VDSL wissen und die Privatkundenhotline nichts von den Biz Kunden....

Kann mir da zufällig jemand helfen?

Danke
keats

Dr.Einstein · Beitrag von **Dr.Einstein** » 01 Okt 2012, 22:25

Hallo keats,

ein ppp-Trace könnte Sicherheit bringen für die Ursache. Mich wundert, dass
angeblich alle paar Minuten eine erfolgreiche Einwahl stattfinden soll.
Normalerweise hat man ein paar Minuten Timeout, nachdem beim BB-RAR 3-
4 Versuche hintereinander erfolglos waren (z.B. falsche Zugangsdaten).

Ich tippe einfach mal auf den BB-RAR, der nicht erreichbar sein wird.
Entweder, weil der DSL Port ein Schuss weg hat, oder vielleicht ein anderes
Problem Richtung Uplink (meist verbunden mit Wartungsarbeiten für IPv6)
besteht.

Ein Ersatz-VDSL-Modem zum Testen hast du nicht zufällig, z.B. Speedport
oder einen Argus ?

Zur Randinfo: VPI und VCI gibts nicht wirklich bei VDSL. Sollte leer gelassen
werden.

Gruß Dr.Einstein

keats · Beitrag von **keats** » 01 Okt 2012, 22:58

Hallo Dr. Einstein,

Trace wie nachfolgend. Ich hoffe, ich habe das richtig gemacht. Da war auch eine dieser erfolgreichen Verbindungen über ein paar Sekunden dabei, zumindest lt. LAN-Monitor. Manchmal passiert das recht schnell hintereinander.

Die Daten für VPI/VCI wurden vom Assistenten so gesetzt. Wirklich entfernen kann man die nicht. Die werden dann automatisch durch 0/0 ersetzt, was tatsächlich reguläre Angaben wären?

Ein anderes VDSL-Modem habe ich bedauerlicherweise nicht zur Hand.

Code: Alles auswählen

                                                            
[TraceStarted] 2012/10/01 22:41:50,221
Used config:
# Trace config
trace + PPP

# Show commands
show bootlog 
[ShowCmd] 2012/10/01 22:41:50,261
Result of command: "show bootlog "
Boot log (159 Bytes):

****

10/01/2012 09:35:38  System boot after power on

DEVICE:           LANCOM 1681V
HW-RELEASE:       A
VERSION:          8.62.0050RU2 / 07.08.2012

[Sysinfo] 2012/10/01 22:41:50,265
Result of command: "sysinfo"

DEVICE:           LANCOM 1681V
HW-RELEASE:       A
SERIAL-NUMBER:    xxx
MAC-ADDRESS:      xxx
IP-ADDRESS:       192.168.xxx.xxx
IP-NETMASK:       255.255.255.0
INTRANET-ADDRESS: 0.0.0.0
INTRANETMASK:     0.0.0.0
VERSION:          8.62.0050RU2 / 07.08.2012
NAME:             xxx
CONFIG-STATUS:    1056;0;af22442e01b4997f438fbcc0c22227d8fe30e824.00000000000000.115
FIRMWARE-STATUS:  1;1.4;1.1;8.50.0214RU4.13122011.3;8.62.0050RU2.07082012.4
HW-MASK:          00000000000000000000000011100011
FEATUREWORD:      00000000001000000000000100011100
REGISTERED-WORD:  00000000001000000000000100011100
FEATURE-LIST:     02/F
FEATURE-LIST:     03/F
FEATURE-LIST:     04/F
FEATURE-LIST:     08/F
FEATURE-LIST:     15/F
TIME:             22415001102012
HTTP-PORT:        80
HTTPS-PORT:       443
TELNET-PORT:      23
TELNET-SSL-PORT:  992
SSH-PORT:         22
Production-Date:  2012-02-06
MOD-Level:        A2
LOCATION:         
COMMENT:          
MYVPN:            0
MYVPN-HOSTNAME:   

[PPP] 2012/10/01 22:41:52,281  Devicetime: 2012/10/01 22:41:53,000

Transmit PADI frame to peer ff:ff:ff:ff:ff:ff for session 0000
Service: (any)
Host-ID: 41 b0 92 c6 20 d8 49 63


[PPP] 2012/10/01 22:42:01,614  Devicetime: 2012/10/01 22:42:02,220

Transmit PADI frame to peer ff:ff:ff:ff:ff:ff for session 0000
Service: (any)
Host-ID: e4 8d ae 2e 72 46 d7 17

[PPP] 2012/10/01 22:42:02,001  Devicetime: 2012/10/01 22:42:02,720

Transmit PADI frame to peer ff:ff:ff:ff:ff:ff for session 0000
Service: (any)
Host-ID: e4 8d ae 2e 72 46 d7 17

[PPP] 2012/10/01 22:42:03,001  Devicetime: 2012/10/01 22:42:03,720

Transmit PADI frame to peer ff:ff:ff:ff:ff:ff for session 0000
Service: (any)
Host-ID: e4 8d ae 2e 72 46 d7 17

[PPP] 2012/10/01 22:42:05,020  Devicetime: 2012/10/01 22:42:05,720

Transmit PADI frame to peer ff:ff:ff:ff:ff:ff for session 0000
Service: (any)
Host-ID: e4 8d ae 2e 72 46 d7 17


[PPP] 2012/10/01 22:42:09,055  Devicetime: 2012/10/01 22:42:09,720

Transmit PADI frame to peer ff:ff:ff:ff:ff:ff for session 0000
Service: (any)
Host-ID: e4 8d ae 2e 72 46 d7 17


[PPP] 2012/10/01 22:42:17,023  Devicetime: 2012/10/01 22:42:17,550

LCP polling timeout for peer TELEKOM - 

[PPP] 2012/10/01 22:42:18,494  Devicetime: 2012/10/01 22:42:18,940

Transmit PADI frame to peer ff:ff:ff:ff:ff:ff for session 0000
Service: (any)
Host-ID: 87 f5 77 75 ae 42 38 9a

[PPP] 2012/10/01 22:42:18,922  Devicetime: 2012/10/01 22:42:19,440

Transmit PADI frame to peer ff:ff:ff:ff:ff:ff for session 0000
Service: (any)
Host-ID: 87 f5 77 75 ae 42 38 9a

[PPP] 2012/10/01 22:42:19,755  Devicetime: 2012/10/01 22:42:20,440

Transmit PADI frame to peer ff:ff:ff:ff:ff:ff for session 0000
Service: (any)
Host-ID: 87 f5 77 75 ae 42 38 9a

[PPP] 2012/10/01 22:42:21,721  Devicetime: 2012/10/01 22:42:22,440

Transmit PADI frame to peer ff:ff:ff:ff:ff:ff for session 0000
Service: (any)
Host-ID: 87 f5 77 75 ae 42 38 9a


[PPP] 2012/10/01 22:42:25,721  Devicetime: 2012/10/01 22:42:26,440

Transmit PADI frame to peer ff:ff:ff:ff:ff:ff for session 0000
Service: (any)
Host-ID: 87 f5 77 75 ae 42 38 9a


[PPP] 2012/10/01 22:42:34,941  Devicetime: 2012/10/01 22:42:35,660

Transmit PADI frame to peer ff:ff:ff:ff:ff:ff for session 0000
Service: (any)
Host-ID: 63 14 06 83 dc 32 80 61

[PPP] 2012/10/01 22:42:35,171  Devicetime: 2012/10/01 22:42:35,687

Received PADO frame from peer 00:90:1a:a2:bf:dc for session 0000
AC-Name: BRAX72-ths, accepted
Host-ID: 63 14 06 83 dc 32 80 61, accepted
Service: (any), accepted
Cookie:  0b 54 88 87 5f 72 30 e3 d4 b3 f3 19 fd 4e 3e 17, accepted

[PPP] 2012/10/01 22:42:35,171  Devicetime: 2012/10/01 22:42:35,687

Transmit PADR frame to peer 00:90:1a:a2:bf:dc for session 0000
Host-ID: 63 14 06 83 dc 32 80 61
Service: (any)
Cookie:  0b 54 88 87 5f 72 30 e3 d4 b3 f3 19 fd 4e 3e 17

[PPP] 2012/10/01 22:42:35,171  Devicetime: 2012/10/01 22:42:35,803

Received PADS frame from peer 00:90:1a:a2:bf:dc for session 07db
Service: (any), accepted
Host-ID: 63 14 06 83 dc 32 80 61, accepted

[PPP] 2012/10/01 22:42:35,171  Devicetime: 2012/10/01 22:42:35,803
Change phase to ESTABLISH for TELEKOM
Lower-Layer-Up event for LCP
Initializing LCP restart timer to 3000 milliseconds
Waiting up to 200ms for connection
Starting LCP restart timer with 200 milliseconds

[PPP] 2012/10/01 22:42:35,597  Devicetime: 2012/10/01 22:42:36,000
Positive Restart-Timeout event for LCP
Stop waiting for connection
Initializing LCP restart timer to 3000 milliseconds
Generating LCP configure-request for peer TELEKOM
Inserting local MRU 1492
Inserting local magic number 83a1c310
Sending LCP configure-request with ID 00 and length 14 to peer TELEKOM (channel 1)
Starting LCP restart timer with 3000 milliseconds

[PPP] 2012/10/01 22:42:35,597  Devicetime: 2012/10/01 22:42:36,198

Received LCP frame from peer TELEKOM (channel 1)
Evaluate configure-request with ID d5 and size 18
Peer MRU 1492 accepted
Peer requests authentication protocol PAP, accepted
Peer magic number 620d58e3 accepted
Positive Configure-Request-Received event for LCP
Sending LCP configure-ack with ID d5 and length 20 to peer TELEKOM (channel 1)

[PPP] 2012/10/01 22:42:35,597  Devicetime: 2012/10/01 22:42:36,198

Received LCP frame from peer TELEKOM (channel 1)
Evaluate configure-ack with ID 00 and size 14
Configure-Ack-Received event for LCP
Initializing LCP restart timer to 3000 milliseconds
This-Layer-Up action for LCP
Change phase to AUTHENTICATE for TELEKOM
Generating PAP-request for peer TELEKOM
Resolved peer as TELEKOM in PPP table

Sending PAP-request with ID 4f, size 52 and peer-id xxx@t-online-com.de to peer TELEKOM (channel 1)
Stopping LCP restart timer

[PPP] 2012/10/01 22:42:36,707  Devicetime: 2012/10/01 22:42:37,424

Received PAP frame from peer TELEKOM (channel 1)
Evaluate PAP ack with ID 4f and size 5
This-Layer-Up action for LCP
Change phase to CALLBACK for TELEKOM
This-Layer-Up action for LCP
Change phase to NETWORK for TELEKOM
Lower-Layer-Up event for IPCP
Initializing IPCP restart timer to 3000 milliseconds
Generating IPCP configure-request for peer TELEKOM
Inserting IP address 0.0.0.0
Inserting primary DNS address 0.0.0.0
Inserting secondary DNS address 0.0.0.0
Sending IPCP configure-request with ID 00 and length 22 to peer TELEKOM (channel 1)
Starting IPCP restart timer with 3000 milliseconds

[PPP] 2012/10/01 22:42:37,107  Devicetime: 2012/10/01 22:42:37,451

Received IPCP frame from peer TELEKOM (channel 1)
Evaluate configure-nak with ID 00 and size 22
Peer NAKs IP address xxx.xxx.xxx.xxx (unsere feste IP), accepted
Peer NAKs primary DNS address 217.237.149.205, accepted
Peer NAKs secondary DNS address 217.237.151.51, accepted
Configure-Nak/Rej-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds
Generating IPCP configure-request for peer TELEKOM
Inserting IP address xxx.xxx.xxx.xxx (unsere feste IP)
Inserting primary DNS address 217.237.149.205
Inserting secondary DNS address 217.237.151.51
Sending IPCP configure-request with ID 01 and length 22 to peer TELEKOM (channel 1)
Starting IPCP restart timer with 3000 milliseconds

[PPP] 2012/10/01 22:42:37,107  Devicetime: 2012/10/01 22:42:37,476

Received IPCP frame from peer TELEKOM (channel 1)
Evaluate configure-ack with ID 01 and size 22
Configure-Ack-Received event for IPCP
Initializing IPCP restart timer to 3000 milliseconds

[PPP] 2012/10/01 22:42:37,107  Devicetime: 2012/10/01 22:42:37,527

Received IPCP frame from peer TELEKOM (channel 1)
Evaluate configure-request with ID cb and size 10
Peer requests IP address 217.0.117.222, accepted
Positive Configure-Request-Received event for IPCP
Sending IPCP configure-ack with ID cb and length 12 to peer TELEKOM (channel 1)
Stopping IPCP restart timer
This-Layer-Up action for IPCP

[PPP] 2012/10/01 22:42:38,398  Devicetime: 2012/10/01 22:42:39,109
Administrative-Close event for LCP
This-Layer-Down action for LCP
Lower-Layer-Down event for BACP
Stopping BACP restart timer
Lower-Layer-Down event for CCP
Stopping CCP restart timer
Lower-Layer-Down event for IPCP
This-Layer-Down action for IPCP
Stopping IPCP restart timer
Lower-Layer-Down event for IPXCP
Stopping IPXCP restart timer
Initializing LCP restart timer to 3000 milliseconds
Change phase to TERMINATE for TELEKOM
Sending LCP terminate-request with ID 02 and length 4 to peer TELEKOM (channel 1)
Starting LCP restart timer with 3000 milliseconds

[PPP] 2012/10/01 22:42:39,085  Devicetime: 2012/10/01 22:42:39,142

Received LCP frame from peer TELEKOM (channel 1)
Terminate-Ack-Received event for LCP
Stopping LCP restart timer
This-Layer-Finish action for LCP
Disconnecting because LCP was finished

[PPP] 2012/10/01 22:42:39,085  Devicetime: 2012/10/01 22:42:39,143
Change phase to DEAD for TELEKOM
Stopping LCP restart timer
Stopping IPCP restart timer
Stopping CCP restart timer
Stopping BACP restart timer

[PPP] 2012/10/01 22:42:39,085  Devicetime: 2012/10/01 22:42:39,143

Transmit PADT frame to peer 00:90:1a:a2:bf:dc for session 07db

[PPP] 2012/10/01 22:42:39,663  Devicetime: 2012/10/01 22:42:40,370

Transmit PADI frame to peer ff:ff:ff:ff:ff:ff for session 0000
Service: (any)
Host-ID: f9 cd 0d a9 91 5e 05 f4

[PPP] 2012/10/01 22:42:40,192  Devicetime: 2012/10/01 22:42:40,870

Transmit PADI frame to peer ff:ff:ff:ff:ff:ff for session 0000
Service: (any)
Host-ID: f9 cd 0d a9 91 5e 05 f4

[PPP] 2012/10/01 22:42:41,152  Devicetime: 2012/10/01 22:42:41,870

Transmit PADI frame to peer ff:ff:ff:ff:ff:ff for session 0000
Service: (any)
Host-ID: f9 cd 0d a9 91 5e 05 f4

[PPP] 2012/10/01 22:42:43,171  Devicetime: 2012/10/01 22:42:43,870

Transmit PADI frame to peer ff:ff:ff:ff:ff:ff for session 0000
Service: (any)
Host-ID: f9 cd 0d a9 91 5e 05 f4


[PPP] 2012/10/01 22:42:47,187  Devicetime: 2012/10/01 22:42:47,870

Transmit PADI frame to peer ff:ff:ff:ff:ff:ff for session 0000
Service: (any)
Host-ID: f9 cd 0d a9 91 5e 05 f4


[PPP] 2012/10/01 22:42:56,371  Devicetime: 2012/10/01 22:42:57,090

Transmit PADI frame to peer ff:ff:ff:ff:ff:ff for session 0000
Service: (any)
Host-ID: ff 93 43 9e 7f c9 a1 cf

[PPP] 2012/10/01 22:42:57,196  Devicetime: 2012/10/01 22:42:57,590

Transmit PADI frame to peer ff:ff:ff:ff:ff:ff for session 0000
Service: (any)
Host-ID: ff 93 43 9e 7f c9 a1 cf

[PPP] 2012/10/01 22:42:57,871  Devicetime: 2012/10/01 22:42:58,590

Transmit PADI frame to peer ff:ff:ff:ff:ff:ff for session 0000
Service: (any)
Host-ID: ff 93 43 9e 7f c9 a1 cf

[PPP] 2012/10/01 22:42:59,872  Devicetime: 2012/10/01 22:43:00,590

Transmit PADI frame to peer ff:ff:ff:ff:ff:ff for session 0000
Service: (any)
Host-ID: ff 93 43 9e 7f c9 a1 cf


[PPP] 2012/10/01 22:43:03,871  Devicetime: 2012/10/01 22:43:04,590

Transmit PADI frame to peer ff:ff:ff:ff:ff:ff for session 0000
Service: (any)
Host-ID: ff 93 43 9e 7f c9 a1 cf

[TraceStopped] 2012/10/01 22:43:04,271
Used config:
# Trace config
trace + PPP

# Show commands
show bootlog 
[Legend] 2009/07/09 00:00:00,000
PPP, TraceStarted, TraceStopped, Sysinfo, ShowCmd
[Index] 2009/07/09 00:00:00,000
1,117,7;4,255,12;3,1105,36;0,187,7;0,186,6;0,186,6;0,186,6;0,187,7;0,187,7;0,113,4;0,186,6;0,186,6;0,186,6;0,187,7;0,187,7;0,186,6;0,307,8;0,244,7;0,208,6;
0,278,7;0,443,10;0,418,10;0,562,14;0,681,17;0,746,16;0,263,7;0,417,10;0,645,17;0,262,8;0,218,7;0,136,4;0,186,6;0,186,6;0,186,6;0,187,7;0,187,7;0,186,6;0,186,6;
0,186,6;0,187,7;0,186,6;2,117,7;

Danke und Grüße
keats

Dr.Einstein · Beitrag von **Dr.Einstein** » 01 Okt 2012, 23:36

So wie ich die Zeile:

[PPP] 2012/10/01 22:42:38,398 Devicetime: 2012/10/01 22:42:39,109

interpretiere, trennt der Lancom zumindest aktiv die PPP-Verbindung.

Zeile:

[PPP] 2012/10/01 22:42:39,085 Devicetime: 2012/10/01 22:42:39,142

bekommste sogar zurück, dass die Trennungsanfrage bestätigt wurde durch
den Provider.

Irgendein LinePolling aktiv, was hier vielleicht stört? Den Timer in der PPP-
Liste anders als "5" gesetzt ? Default-PPP Eintrag verändert ?

Gruß Dr.Einstein

MoinMoin · Beitrag von **MoinMoin** » 02 Okt 2012, 12:02

Moin, moin!

Ich tippe auch auf IP-Polling.

Ciao, Georg

keats · Beitrag von **keats** » 02 Okt 2012, 14:34

Hallo,

und so weit erst mal vielen Dank. Aber ich komme da nicht wirklich weiter. Der Timer in der PPP-Liste steht auf 5. Der Default-Eintrag ist unverändert und identisch mit einem anderen Lancom, mit dem ich das verglichen habe.

In der Polling-Tabelle steht bei dem Gerät nichts drin. Bewusst gesetzt oder gefunden habe ich nichts weiter? Kann ich noch irgendwo nachsehen? Seit der ursprünglichen Einrichtung gab es eigentlich gar keine weiteren Änderungen der Konfiguration.

Danke und Grüße
keats

MoinMoin · Beitrag von **MoinMoin** » 04 Okt 2012, 11:15

Moin, moin!

Wenn die Polling-Tabelle leer ist, dann wird auch kein IP-Polling gemacht. Ich seh da im PPP aber keinen Fehler.

Ciao, Georg

backslash · Beitrag von **backslash** » 04 Okt 2012, 19:03

Hi keats

hier wäre neben dem PPP-Traxce auch noch ein "Status" un ein "Error"-Trace hilfreich, denn daraus ergibt sich oftmals schon, wo das Problem liegt. Normalerweise würde ich bei einem sofortigen Abbau zwi Sekunden nach erfolgreicher Einwahl auch auf ein IP-Polling tippen...

Es könnte aber auch eine fehlerhafte Backup-Konfiguration sein, oder was hier im Forum auch schon auftauchte: eine Firewallregel, die als Aktion "Verbindung trennen" hat... Wenn die auf ein Paket matcht, das ins Internet geht, dann wird die Verbindung halt abgebaut... (Wenn das gar als Aktion bei IDS/DOS gesetzt ist, dann führt jesder Portscan zu einem Verbindungsabbau...)

Daher halte ich rein gar nichts von Aktionen wie Quell-IPs sperren, Verbindungen trennen etc... Diese Aktionen sind nur vorhanden, weil die selbsternannten Experten diverser Computerzeitschriften sowas toll finden und es für ein Sicherheitsfeature hatlen - in Wahrheit wird durch sowas ein DoS-Angriff erst perfekt...

Gruß
Backslash

keats · Beitrag von **keats** » 06 Okt 2012, 13:31

Hallo backslash,

in der Backup-Liste steht einfach nur, dass für die Gegenstelle "Telekom" als Backup "Easybell" verwendet werden soll. Trennung im Falle von DoS/IDS ist nicht aktiviert. 20 Minuten Sperre für die Absenderadresse schon. Aber ich hatte schon die komplette Firewall + VPN deaktiviert, einen Neustart gemacht und das Problem war unverändert vorhanden. Die Firewall-Regeln sind relativ langweilig, nur die konkreten Freigaben und dann Deny-All.

Ich habe am Mittwoch auch den Support mit dem obigen Trace im Anhang angeschrieben. Bisher kam jedoch keine Rückmeldung.

Was das IP-Polling betrifft, steht zumindest in der Polling-Tabelle nichts drin. Ich weiß aber nicht, ob das auf irgendwelche Umwege noch anders geht? [Edit: Habe eben erst gesehen, dass MoinMoin das schon beantwortet hat,]

Mich irritiert, dass das Problem vor ein paar Wochen halt schon mal einen Tag lang war und sich dann von alleine behoben hat...

Hier noch mal der Status/Error Trace. Wenn ich das richtig sehe, geht aber nicht so schrecklich viel Nützliches daraus hervor?

Code: Alles auswählen

[TraceData]

(Version)            8.30.0001
(Tracesessions)      0
(Comment)            {N/A}
(NumberOfMessages)   29
(OffsetToIndex)      8434
[EndOfHeader]
                                                                       
[TraceStarted] 2012/10/06 13:17:37,505
Used config:
# Trace config
trace + Error
trace + Status

# Show commands
show bootlog 
[ShowCmd] 2012/10/06 13:17:37,546
Result of command: "show bootlog "
Boot log (174 Bytes):

****

10/02/2012 19:13:56  System boot after manual coldboot request

DEVICE:           LANCOM 1681V
HW-RELEASE:       A
VERSION:          8.62.0050RU2 / 07.08.2012

[Sysinfo] 2012/10/06 13:17:37,550
Result of command: "sysinfo"

DEVICE:           LANCOM 1681V
HW-RELEASE:       A
SERIAL-NUMBER:    xxx
MAC-ADDRESS:      xxx
IP-ADDRESS:       192.168.xxx.xxx
IP-NETMASK:       255.255.255.0
INTRANET-ADDRESS: 0.0.0.0
INTRANETMASK:     0.0.0.0
VERSION:          8.62.0050RU2 / 07.08.2012
NAME:             xxx
CONFIG-STATUS:    1056;0;47e2babdafde84fe3a51a16dd93c9b35d77cd968.00000000000000.140
FIRMWARE-STATUS:  1;1.4;1.1;8.50.0214RU4.13122011.3;8.62.0050RU2.07082012.4
HW-MASK:          00000000000000000000000011100011
FEATUREWORD:      00000000001000000000000100011100
REGISTERED-WORD:  00000000001000000000000100011100
FEATURE-LIST:     02/F
FEATURE-LIST:     03/F
FEATURE-LIST:     04/F
FEATURE-LIST:     08/F
FEATURE-LIST:     15/F
TIME:             13174106102012
HTTP-PORT:        80
HTTPS-PORT:       443
TELNET-PORT:      23
TELNET-SSL-PORT:  992
SSH-PORT:         22
Production-Date:  2012-02-06
MOD-Level:        A2
LOCATION:         
COMMENT:          
MYVPN:            0
MYVPN-HOSTNAME:   

[Status] 2012/10/06 13:17:46,586  Devicetime: 2012/10/06 13:17:50,690
Status: VDSL-1: Disconnecting

[Status] 2012/10/06 13:17:46,988  Devicetime: 2012/10/06 13:17:50,707
Status: VDSL-1: Ready (No response)

[Status] 2012/10/06 13:17:47,606  Devicetime: 2012/10/06 13:17:51,700
Status: VDSL-1: Establ. PPPoE


[Status] 2012/10/06 13:18:03,453  Devicetime: 2012/10/06 13:18:07,410
Status: VDSL-1: Disconnecting

[Status] 2012/10/06 13:18:03,507  Devicetime: 2012/10/06 13:18:07,427
Status: VDSL-1: Ready (No response)

[Status] 2012/10/06 13:18:04,364  Devicetime: 2012/10/06 13:18:08,420
Status: VDSL-1: Establ. PPPoE


[Status] 2012/10/06 13:18:20,027  Devicetime: 2012/10/06 13:18:24,130
Status: VDSL-1: Disconnecting

[Status] 2012/10/06 13:18:20,421  Devicetime: 2012/10/06 13:18:24,147
Status: VDSL-1: Ready (No response)

[Status] 2012/10/06 13:18:21,303  Devicetime: 2012/10/06 13:18:25,140
Status: VDSL-1: Establ. PPPoE


[Status] 2012/10/06 13:18:36,749  Devicetime: 2012/10/06 13:18:40,850
Status: VDSL-1: Disconnecting

[Status] 2012/10/06 13:18:37,122  Devicetime: 2012/10/06 13:18:40,867
Status: VDSL-1: Ready (No response)

[Status] 2012/10/06 13:18:37,752  Devicetime: 2012/10/06 13:18:41,860
Status: VDSL-1: Establ. PPPoE

[Status] 2012/10/06 13:18:38,213  Devicetime: 2012/10/06 13:18:42,316
Status: VDSL-1: Protocol

[Status] 2012/10/06 13:18:39,944  Devicetime: 2012/10/06 13:18:44,051
Status: VDSL-1: TELEKOM

[Status] 2012/10/06 13:18:40,351  Devicetime: 2012/10/06 13:18:44,052
Status: DSL-CH-1: Disconnecting (using DSL-1)

[Status] 2012/10/06 13:18:40,351  Devicetime: 2012/10/06 13:18:44,115
Status: DSL-CH-1: Ready (backup-end)

[Status] 2012/10/06 13:18:41,324  Devicetime: 2012/10/06 13:18:45,432
Status: DSL-CH-1: Establ.  (using DSL-1)

[Status] 2012/10/06 13:18:41,835  Devicetime: 2012/10/06 13:18:45,494
Status: DSL-CH-1: Protocol (using DSL-1)

[Status] 2012/10/06 13:18:41,835  Devicetime: 2012/10/06 13:18:45,515
Status: VDSL-1: Disconnecting

[Status] 2012/10/06 13:18:41,835  Devicetime: 2012/10/06 13:18:45,515
Status: DSL-CH-1: EASYBELL (using DSL-1)

[Status] 2012/10/06 13:18:41,835  Devicetime: 2012/10/06 13:18:45,553
Status: VDSL-1: Ready (backup-established)

[Status] 2012/10/06 13:18:42,447  Devicetime: 2012/10/06 13:18:46,550
Status: VDSL-1: Establ. PPPoE


[Status] 2012/10/06 13:18:58,169  Devicetime: 2012/10/06 13:19:02,270
Status: VDSL-1: Disconnecting

[Status] 2012/10/06 13:18:58,582  Devicetime: 2012/10/06 13:19:02,287
Status: VDSL-1: Ready (No response)

[Status] 2012/10/06 13:18:59,177  Devicetime: 2012/10/06 13:19:03,280
Status: VDSL-1: Establ. PPPoE


[TraceStopped] 2012/10/06 13:19:05,710
Used config:
# Trace config
trace + Error
trace + Status

# Show commands
show bootlog 
[Legend] 2009/07/09 00:00:00,000
Status, TraceStarted, TraceStopped, Sysinfo, ShowCmd
[Index] 2009/07/09 00:00:00,000
1,135,8;4,270,12;3,1105,36;0,104,3;0,110,3;0,105,4;0,104,3;0,110,3;0,105,4;0,104,3;0,110,3;0,105,4;0,104,3;0,110,3;0,104,3;0,99,3;0,98,3;0,120,3;0,111,3;
0,115,3;0,115,3;0,104,3;0,115,3;0,117,3;0,105,4;0,104,3;0,110,3;0,105,4;2,135,8;

Danke und Grüße
keats

keats · Beitrag von **keats** » 11 Okt 2012, 20:19

Hallo,

nachdem backslash eine fehlerhafte Backup-Konfiguration erwähnt hat, habe ich den Eintrag aus der Backup-Tabelle entfernt, als ich heute dort vor Ort war. Das hatte ich mich remote nicht getraut, um nicht komplett ausgesperrt zu werden. Tatsächlich klappte der Login bei der Telekom sofort. Backup wieder zugeschaltet, erst mal kein Einfluss. Dann Neustart gemacht und das Problem war wieder da.

In der Backup-Tabelle steht eigentlich nur, dass "Easybell" das Backup für "Telekom" ist. Das habe ich so auch an zwei anderen Standorten, wenn auch mit anderen Lancoms. Auch hier lief es ja mit dem einen Tag Ausnahme vor ein paar Wochen problemlos.

Ich habe das Backup jetzt nicht wieder aktiviert. Aber das ist dann vermutlich ein Bug, oder?

Grüße
keats

Dr.Einstein · Beitrag von **Dr.Einstein** » 11 Okt 2012, 21:08

Du hast bestimmt in der Routing Tabelle neben dem Eintrag Telekom noch
Easybell drin oder?

Das würde das ganze verhalten erklären ...

Gruß Dr.Einstein

keats · Beitrag von **keats** » 12 Okt 2012, 16:30

Hallo Dr. Einstein,

in der Tat. In der Routing-Tabelle steht auch Easybell drin, aber mit einem eigenen Routing-Tag. Ich schicke bzw. schickte per Firewall-Regel einen bestimmten Dienst absichtlich über diese Verbindung. Ist das falsch? An den anderen beiden Standorten habe ich das auch so und keine Probleme?

Der einzige Unterschied ist, dass das interne Modem dort die Backup-Verbindung stellt und die Primärverbindung per Plain-Ethernet über ein externes Modem bzw. Router hergestellt wird.

Habe ich da etwas Grundsätzliches nicht verstanden oder irgendeinen Logikfehler?

Grüße
keats

backslash · Beitrag von **backslash** » 12 Okt 2012, 16:45

Hi keats

in der Tat. In der Routing-Tabelle steht auch Easybell drin, aber mit einem eigenen Routing-Tag. Ich schicke bzw. schickte per Firewall-Regel einen bestimmten Dienst absichtlich über diese Verbindung. Ist das falsch?

das ist definitiv falsch... Denn sobald die Easybell-Verbindung hochkommt, wird vom Backup-Modul die Hauptverbindung (hier also die Telekom-verbindung) getrennt und neu aufgebaut. Sobald sie neu aufgebaut wurde, wird die Easybell-Verbindung getrennt. Wenn du nun die Easybell-Verbindung mit keep-Alive konfiguriert hast oder einfach traffic darüber läuft, wird sie sich erneut aufbauen und das Spielchen starten von neuem...

Du darfst niemals eine anderweitig genutzte Verbindung als Backup-Verbindung eintragen... In so einem Fall mußt du über die Aktionstabelle bei Abbruch der Hauptverbindung entweder die betroffenen Routen umschalten oder (besser noch) mit getaggten Routen arbeiten und in der Firewall die Routing-Tags umsetzen

Gruß
Backslash

keats · Beitrag von **keats** » 14 Okt 2012, 13:05

Hallo backslash,

erst mal vielen Dank, dass sich das Problem mit Hilfe des Forums hat lösen lassen.

Ich will jetzt auch gar nicht wegdiskutieren, dass der Fehler bei mir lag. Aber gibt es eine Erklärung, warum es über Wochen funktioniert hat? Oder war das einfach nur Glück oder die spezifische Situation lag nicht vor... ggf. zeitweise ein echter Ausfall der Hauptverbindung o.ä.? Ich habe auch an einem anderen Standort einen 1721+ stehen, bei dem über die Backup-Leitung die Weboberfläche einer Mailservers von außen angesprochen werden kann. Da ist das nicht anderes geregelt. In der Routing-Tabelle ein Eintrag mit eigenem Tag und eine entsprechende Firewall-Regel. Bricht die Primärverbindung zusammen, läuft alles über die Backup-Verbindung. Der Unterschied ist nur, dass die Primärverbindung dort tatsächlich per IP-Polling geprüft wird.

Aber um es abzukürzen, das ist also falsch bzw. braucht die Hilfe der Aktionstabelle. Die Backup-Verbindung sollte in einem einfachen Setup entsprechend gar keinen Eintrag in der Routing-Tabelle haben, sondern einfach nur in der Backup-Tabelle genannt werden?

Danke und Grüße
keats