Inode ADSL Probleme - Analyse? Zyxel durch Cisco ersetzen?

[zid]

eine andere alternative wäre der draytek vigor 120 annex a
http://www.store.ctn-systeme.de/draytek ... modem.html
dann könnte sich der cisc mit pppoe einwählen:
viewtopic.php?f=20&t=53500&p=439726&#p439622

lg
zid

[wicked_one]

ADSL WIC wird sich schon noch auftreiben lassen ...

[jutta]

und noch eine info, die ich grad bekommen habe: es gibt bei UPC nach wie vor p324, bloss ist die garantie schon abgelaufen, daher wird er nicht mehr gratis umgetauscht. (die router gehen ja, zum unterschied von den modems, ins eigentum des kunden ueber, daher traegt der kunde das risiko und muss im fall des falles einen neuen kaufen.)

das waer natuerlich die allereinfachste loesung, weil der passend vorkonfiguriert geliefert werden koennte und nur angesteckt werden muss.

vielleicht war die kommunikation mit dem servicetechniker diesbezueglich unklar.

[sebaat]

Hallo zusammen,

Mann, was ist das für ein Forum!!?! So gut, schnell und umfänglich bin ich ja noch nirgendwo beraten worden!!

- du hast dich bei deiner verschleierungsaktion vertan, und es wird doch ein /30er netz durchgeroutet

Ja, richtig Ich habe einfach unachtsam ein paar Stellen der IP geändert. Es handelt sich tatsächlich um ein /29 Netz, von welchem aber nur 2 IPs genutzt werden.
Was kann ich mir unter "dreckig routen" vorstellen?

sollte ein overlay vorliegen- und damit meine ich, daß das tg eine grundverbindung aufbaut, über die dann ein pptp-tunnel für den eigentlichen traffic gelegt wird, dann inode ersuchen, dieses unnötige konstrukt zu beseitigen und direkt zu routen.

Aus meiner Sicht, sieht das so aus, wie du beschrieben hast. Du meinst also, Inode könnte mir das /30er Netz auch direkt auf die dynamisch per PPPoA vergebene Dialer IP routen?

im notfall könnt ich dir im austausch ein vorkonfiguriertes ding zukommen lassen

Vielen Dank für das Angebot!!

Eine ADSL WIC für den Cisco wäre für mich nicht allzu schwer aufzutreiben, aber dann bliebe immer noch das Problem der Config (PPTP).

Also, wie gesagt, ich habe keine Möglichkeit, vor Ort an den Geräten rumzuschrauben. Allein mein Anfahrtsweg würde der Wirtschaftlichkeit dieser Aktion widersprechen. Deshalb bin ich darauf angewiesen "an dem Ast zu sägen, auf welchem ich sitze". Vor Ort gibt es nur fachfremdes Personal, welches nach Anweisung Kabel stecken kann. Deshalb würde eine Umkonfiguration des Thomson erst mal nicht in Frage kommen, zumal ich ja gar nicht mal per Telnet auf das Dingen draufkomme.

Nehmt es mir nicht übel, aber ich werde es zunächst damit versuchen, die PPTP Einwahl auf dem Cisco zu realisieren, und damit den Zyxel rauszuhauen. Ich bin ein Cisco Nerd, und habe gestern auch noch von einem Provider meines Vertrauens die Info bekommen, dass dies - auch wenn es nicht offiziell supported wird - funktionieren soll. Der Vorteil dieser Variante ist, dass ich erstmal nichts investieren muss

Ich habe auch soeben die Info bekommen, dass ein "Wartungsfenster" vor Ort erst am kommenden Dienstag möglich ist. D.h. also, erst mal warten...

Sollte das nicht funktionieren, würde ich die anderen Möglichkeiten angehen. Habe mir (weil es ein gutes Angebot war, und nur noch ein paar Stunden lief) bei Ebay vorsorglich ein neues P324 für 14,90 inkl. Versand gekauft. Die Config vom jetzigen habe ich bereits gesichert. So könnte ich den neuen einfach damit betanken und vor Ort tauschen lassen.

Vielen Dank noch mal an alle - ich melde mich, wenn's was neues gibt.

[jutta]

> Eine ADSL WIC für den Cisco wäre für mich nicht allzu schwer aufzutreiben, aber dann bliebe immer noch das Problem der Config (PPTP).

weit verbreiteter irrglaube

wenn der cisco selbst das modem ist, braucht er kei pptp machen, sondern pppoa. und das kann er! alte und neue ciscos sind bei businessanschluessen der ta/a1 in verwendung und die sind (bis aufs routing) technisch gleich realisiert wie dein anschluss. configs dafuer gibts hier, wie ich in meiner ersten antwort schon erwaehnt habe.

@Forum: danke fuer die blumen wir sind alle gluecklich, wenn einmal ein interessantes problem auftaucht und nicht nur "mein ping ist sch****e"

[zid]

hallo sebaat,

>"...Was kann ich mir unter "dreckig routen" vorstellen?..."
das ist forumsjargon und beschreibt die siuation, in der eine ip eines gerouteten netzes am dialer liegt. wenn man jetzt dem lan-intf des einwählenden routers eine ip aus dem geroutetem netz gibt, dann entsteht ein routing konflikt, mit dem manche router nicht umgehen können. s.a. juttas bemerkungen zu diesem thema:
viewtopic.php?f=20&t=53350&p=437974&#p437975
abhilfen:
- man betreibt den dialer unnumbered
- man macht proxy arp
viewtopic.php?f=46&t=53314&p=437825&#p437756
- wenn das netz hinreichend groß ist (min. /29) und man nur wenige ips braucht, kann man es teilen.

>"...Deshalb bin ich darauf angewiesen "an dem Ast zu sägen, auf welchem ich sitze"..."
*das* kenn ich, sehr unangenehme situation.

>"...dass dies - auch wenn es nicht offiziell supported wird - funktionieren soll..."
pptp am cisco würde "einige" leute *sehr* interessieren. ich hab schon eine längliche diskussion mit einem ciscorianer über dieses thema, aber wir kommen nicht weiter. falls du eine lösung findest, wärs nett, wenn du sie hier posten würdest.

>"...Der Vorteil dieser Variante ist, dass ich erstmal nichts investieren muss..."
das müßtest du auch nicht, wenn du das tg umkonfigurierst. und das haut nicht nur sicher, sondern ist auch aus technischer sicht einfacher, weil du dann auf der strecke cisc <-> tg keinen doppeltunnel (ipsec + pptp) hast. aber zugegeben, pptp mim cisc ist definitiv *viel* interessanter als ordinäres routing am tg...

lg
zid

[sebaat]

Ich habe heute den Versuch gestartet, die PPTP Einwahl auf den Cisco zu schieben. Dazu hatte ich eine Textdatei mit folgender Config im Flash des Cisco gespeichert:

Code: Alles auswählen

service internal

logging buffered 64000

interface Ethernet0
ip address 10.0.0.140 255.255.255.0
no crypto map VPNMAP

interface Loopback0
ip address <WAN-GW> 255.255.255.255 secondary
ip address <WAN-IP vom Eth0> 255.255.255.255

crypto map VPNMAP local-address Lo0

vpdn enable
!
vpdn-group pptp
request-dialin
  protocol pptp
  pool-member 1
initiate-to ip 10.0.0.138
!
interface Dialer0
no shutdown
ip address negotiated
encapsulation ppp
dialer pool 1
dialer string 1234
dialer vpdn
dialer-group 1
no cdp enable
ppp chap hostname <username>
ppp chap password <password>
crypto map VPNMAP
!
ip route 0.0.0.0 0.0.0.0 Dialer0

no ip route 0.0.0.0 0.0.0.0 <WAN-GW>

do show running-config | append flash:conf.txt
do show ip int brie | append flash:shintbr.txt
do show vpdn | append flash:shvpdn.txt
do show crypto isa sa det | append flash:shcrypto.txt
do sh int | append flash:shint.txt
do sh logg | append flash:shlog.txt


Diese Textdatei habe ich per "copy flash:datei.txt run" in die running-config kopiert.

Dann habe ich vor Ort den Cisco direkt auf den Thomson stecken lassen. Leider war das Gerät auch nach einigen Minuten trotzdem nicht erreichbar.

Hier der output vom "show vpdn", was direkt nach dem Einspielen der Config abgesetzt wurde:

Code: Alles auswählen

#more flash:shvpdn.txt


%No active L2TP tunnels

%No active L2F tunnels

PPTP Tunnel and Session Information Total tunnels 1 sessions 1

LocID Remote Name     State    Remote Address  Port  Sessions VPDN Group
2     10.0.0.138      wt-cnnct 10.0.0.138      1723  1        pptp

LocID RemID TunID Intf    Username      State   Last Chg Uniq ID
2     0     2     Vi1                   wt-tun  never    n/a


Tja, war wohl leider nix. Ich habs wieder zurückstecken lassen, und den Cisco durch einen Reload auf den alten Config-stand zurückbefördert.

Als nächstes werde ich wohl den kürzlich erworbenen Zyxel P324 mit den Config des mutmaßlich defekten Geräts betanken und hinschicken....

[sebaat]

Hallo zusammen,

ein Gedanke, der mir dummerweise erst jetzt gekommen ist, ist das Firmware Update. Aktuell läuft der P324 auf

Modellname : Prestige 324 ML
ZyNOS Firmware-Version: V3.61(JF.0) | 04/30/2004

Macht es Sinn, da erstmal ein Update durchzuführen? Ist das aus der Ferne überhaupt ohne Bedenken möglich?

Hier gibt es anscheinend noch neuere Versionen.

[jutta]

grundsaetzlich sind firmware updates aus der ferne bei zyxel routern moeglich. sie funktionieren oft auch voellig problemlos. manchmal ist es aber noetig, auch das rom-0 file neu einzuspielen (dh die default-config). und dann sind erst einmal die einstellungen weg und dann tut man sich remote etwas schwer, wenn man keinen 2. schleichweg ins lan hat.

manche updates sind auch so gross, dass man sie nur entweder mit tftp oder mit einem speziellen windows-tool auf den router bekommt. letzteres ist jedenfalls nur lokal moeglich.

was du tun koenntest:

a) in dem zip-paket mit der firmware ist meistens auch in pdf mit dem changelog und mit hinweisen fuers upgrade. vielleicht steht da was ueber moegliche fallen bei genau dieser version drinnen. sicher steht drinnen, welche bugs gefixt wurden.

b) den businesssupport von inode/upc fragen. die haben erfahrung mit dem remote upgrade von zyxel routern.

c) den klaus koenig fragen (e-mail adresse hast du eh)

[sebaat]

a) in dem zip-paket mit der firmware ist meistens auch in pdf mit dem changelog und mit hinweisen fuers upgrade. vielleicht steht da was ueber moegliche fallen bei genau dieser version drinnen. sicher steht drinnen, welche bugs gefixt wurden.

... das war der Tip des Jahrhunderts!!

Zitat aus den aktuellen Firmware Release Notes:

Modifications in V3.61(JF.1)b1 | 03/17/2005
(...)
5. [BUG FIX]
Symptom: PPtP will drop when higher DSL-Speed as 768/128

Da hätte ich mal vorher schauen sollen. Das ist ja genau das Problem, was ich habe.

Ich denke, ich mache dann das Update auf dem neuen Zyxel, den ich hier auf dem Schreibtisch habe und schicke den dan fix & fertig los. Ein Update auf dem Dingen vor Ort ist mir dann doch zu riskant

[jutta]

> Da hätte ich mal vorher schauen sollen.

die support-notes der zyxel-firmware sind tatsaechlich fundgruben. aber sie werden wohl nur seltenst gelesen. (ich hab vor jahren router-tests fuer zyxel gemacht, als es massive probleme an oesterreichischen anschluessen mit pptp-einwahl gab, daher kenne ich die doku.)

[zid]

dieses schei** cef, aber jetzt gehts- endlich...

hallo sebaat,

bin jetzt mit einem c1841 (sw: c1841-advipservicesk9-mz.151-3.T2.bin) und pptp online, das prob war das cef. ich hatte folgende config:

Code: Alles auswählen

!
service internal
!
...
! *** das war das prob! ***
ip cef
!
...
vpdn enable
!
vpdn-group ST
request-dialin
  protocol pptp
  pool-member 2
initiate-to ip 10.0.0.138
!
...
interface FastEthernet0/0.1
encapsulation dot1Q 1 native
ip address 192.168.1.2 255.255.255.0
ip nat inside
ip tcp adjust-mss 1440
no cdp enable
!
interface FastEthernet0/1.1
encapsulation dot1Q 1 native
ip address 10.0.0.1 255.255.255.0
no cdp enable
!
...
!
interface Dialer1
mtu 1460
ip address negotiated
no ip redirects
no ip unreachables
ip nat outside
ip virtual-reassembly in
encapsulation ppp
dialer pool 2
dialer string 1
dialer vpdn
dialer-group 1
ppp authentication chap callin
ppp chap hostname xxx
ppp chap password 0 xxx
no cdp enable
!
ip nat inside source list masquerade-ppp interface Dialer1 overload
ip route 0.0.0.0 0.0.0.0 Dialer1 5
!
...
ip access-list standard masquerade-ppp
permit 192.168.1.0 0.0.0.255
!
...
!
dialer-list 1 protocol ip permit
!


mit diesen einstellungen wählt der cisc sauber ein:

Code: Alles auswählen

Rou18(config-if)#no shu
Rou18(config-if)#
.Aug  9 05:32:14.010: %LINK-3-UPDOWN: Interface Dialer1, changed state to up
.Aug  9 05:32:23.397: %LINK-3-UPDOWN: Interface Virtual-Access3, changed state to up
.Aug  9 05:32:23.397: %DIALER-6-BIND: Interface Vi3 bound to profile Di1
.Aug  9 05:32:23.397: Vi3 PPP: Sending cstate UP notification
.Aug  9 05:32:23.397: Vi3 PPP: Processing CstateUp message
.Aug  9 05:32:23.401: PPP: Alloc Context [66947BB8]
.Aug  9 05:32:23.401: ppp75 PPP: Phase is ESTABLISHING
.Aug  9 05:32:23.401: Vi3 PPP: Using dialer call direction
.Aug  9 05:32:23.401: Vi3 PPP: Treating connection as a callout
.Aug  9 05:32:23.401: Vi3 PPP: Session handle[4A000051] Session id[75]
.Aug  9 05:32:23.401: Vi3 LCP: Event[OPEN] State[Initial to Starting]
.Aug  9 05:32:23.401: Vi3 PPP: No remote authentication for call-out
.Aug  9 05:32:23.401: Vi3 LCP: O CONFREQ [Starting] id 1 len 14
.Aug  9 05:32:23.401: Vi3 LCP:    MRU 1460 (0x010405B4)
.Aug  9 05:32:23.405: Vi3 LCP:    MagicNumber 0x810D5DEC (0x0506810D5DEC)
.Aug  9 05:32:23.405: Vi3 LCP: Event[UP] State[Starting to REQsent]
.Aug  9 05:32:25.405: Vi3 LCP: O CONFREQ [REQsent] id 2 len 14
.Aug  9 05:32:25.405: Vi3 LCP:    MRU 1460 (0x010405B4)
.Aug  9 05:32:25.405: Vi3 LCP:    MagicNumber 0x810D5DEC (0x0506810D5DEC)
.Aug  9 05:32:25.405: Vi3 LCP: Event[Timeout+] State[REQsent to REQsent]
.Aug  9 05:32:25.425: Vi3 PPP: I pkt type 0xC021, datagramsize 22 link[ppp]
.Aug  9 05:32:25.425: Vi3 PPP: I pkt type 0xC021, datagramsize 18 link[ppp]
.Aug  9 05:32:25.425: Vi3 LCP: I CONFREQ [REQsent] id 1 len 18
.Aug  9 05:32:25.425: Vi3 LCP:    MRU 1460 (0x010405B4)
.Aug  9 05:32:25.425: Vi3 LCP:    AuthProto PAP (0x0304C023)
.Aug  9 05:32:25.425: Vi3 LCP:    MagicNumber 0xF2AA724C (0x0506F2AA724C)
.Aug  9 05:32:25.429: Vi3 LCP: O CONFNAK [REQsent] id 1 len 9
.Aug  9 05:32:25.429: Vi3 LCP:    AuthProto CHAP (0x0305C22305)
.Aug  9 05:32:25.429: Vi3 LCP: Event[Receive ConfReq-] State[REQsent to REQsent]
.Aug  9 05:32:25.429: Vi3 LCP: I CONFACK [REQsent] id 2 len 14
.Aug  9 05:32:25.429: Vi3 LCP:    MRU 1460 (0x010405B4)
.Aug  9 05:32:25.429: Vi3 LCP:    MagicNumber 0x810D5DEC (0x0506810D5DEC)
.Aug  9 05:32:25.429: Vi3 LCP: Event[Receive ConfAck] State[REQsent to ACKrcvd]
.Aug  9 05:32:25.449: Vi3 PPP: I pkt type 0xC021, datagramsize 23 link[ppp]
.Aug  9 05:32:25.449: Vi3 LCP: I CONFREQ [ACKrcvd] id 2 len 19
.Aug  9 05:32:25.449: Vi3 LCP:    MRU 1460 (0x010405B4)
.Aug  9 05:32:25.449: Vi3 LCP:    AuthProto CHAP (0x0305C22305)
.Aug  9 05:32:25.449: Vi3 LCP:    MagicNumber 0xF2AA724C (0x0506F2AA724C)
.Aug  9 05:32:25.449: Vi3 LCP: O CONFACK [ACKrcvd] id 2 len 19
.Aug  9 05:32:25.449: Vi3 LCP:    MRU 1460 (0x010405B4)
.Aug  9 05:32:25.449: Vi3 LCP:    AuthProto CHAP (0x0305C22305)
.Aug  9 05:32:25.449: Vi3 LCP:    MagicNumber 0xF2AA724C (0x0506F2AA724C)
.Aug  9 05:32:25.449: Vi3 LCP: Event[Receive ConfReq+] State[ACKrcvd to Open]
.Aug  9 05:32:25.469: Vi3 PPP: Phase is AUTHENTICATING, by the peer
.Aug  9 05:32:25.469: Vi3 LCP: State is Open
.Aug  9 05:32:25.469: Vi3 PPP: I pkt type 0xC223, datagramsize 41 link[ppp]
.Aug  9 05:32:25.469: Vi3 CHAP: I CHALLENGE id 1 len 37 from "c72-2.ix1.vie.at"
.Aug  9 05:32:25.473: Vi3 CHAP: Using hostname from interface CHAP
.Aug  9 05:32:25.473: Vi3 CHAP: Using password from interface CHAP
.Aug  9 05:32:25.473: Vi3 CHAP: O RESPONSE id 1 len 41 from "xxx"
.Aug  9 05:32:25.537: Vi3 PPP: I pkt type 0xC223, datagramsize 8 link[ppp]
.Aug  9 05:32:25.537: Vi3 PPP: I pkt type 0x8021, datagramsize 14 link[ip]
.Aug  9 05:32:25.537: Vi3 CHAP: I SUCCESS id 1 len 4
.Aug  9 05:32:25.537: Vi3 PPP: Phase is FORWARDING, Attempting Forward
.Aug  9 05:32:25.537: Vi3 PPP: Queue IPCP code[1] id[1]
.Aug  9 05:32:25.541: Vi3 PPP: Phase is ESTABLISHING, Finish LCP
.Aug  9 05:32:25.541: Vi3 PPP: Phase is UP
.Aug  9 05:32:25.541: Vi3 IPCP: Protocol configured, start CP. state[Initial]
.Aug  9 05:32:25.541: Vi3 IPCP: Event[OPEN] State[Initial to Starting]
.Aug  9 05:32:25.541: Vi3 IPCP: O CONFREQ [Starting] id 1 len 10
.Aug  9 05:32:25.541: Vi3 IPCP:    Address 0.0.0.0 (0x030600000000)
.Aug  9 05:32:25.545: Vi3 IPCP: Event[UP] State[Starting to REQsent]
.Aug  9 05:32:25.545: Vi3 PPP: Process pending ncp packets
.Aug  9 05:32:25.545: Vi3 IPCP: Redirect packet to Vi3
.Aug  9 05:32:25.545: Vi3 IPCP: I CONFREQ [REQsent] id 1 len 10
.Aug  9 05:32:25.545: Vi3 IPCP:    Address 77.220.110.79 (0x03064DDC6E4F)
.Aug  9 05:32:25.545: Vi3 IPCP: O CONFACK [REQsent] id 1 len 10
.Aug  9 05:32:25.545: Vi3 IPCP:    Address 77.220.110.79 (0x03064DDC6E4F)
.Aug  9 05:32:25.545: Vi3 IPCP: Event[Receive ConfReq+] State[REQsent to ACKsent]
.Aug  9 05:32:25.545: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to up
.Aug  9 05:32:25.565: Vi3 PPP: I pkt type 0x8021, datagramsize 14 link[ip]
.Aug  9 05:32:25.565: Vi3 IPCP: I CONFNAK [ACKsent] id 1 len 10
.Aug  9 05:32:25.565: Vi3 IPCP:    Address 195.x.x.217 (0x0306C310EED9)
.Aug  9 05:32:25.565: Vi3 IPCP: O CONFREQ [ACKsent] id 2 len 10
.Aug  9 05:32:25.569: Vi3 IPCP:    Address 195.x.x.217 (0x0306C310EED9)
.Aug  9 05:32:25.569: Vi3 IPCP: Event[Receive ConfNak/Rej] State[ACKsent to ACKsent]
.Aug  9 05:32:25.589: Vi3 PPP: I pkt type 0x8021, datagramsize 14 link[ip]
.Aug  9 05:32:25.589: Vi3 IPCP: I CONFACK [ACKsent] id 2 len 10
.Aug  9 05:32:25.589: Vi3 IPCP:    Address 195.16.238.217 (0x0306C310EED9)
.Aug  9 05:32:25.589: Vi3 IPCP: Event[Receive ConfAck] State[ACKsent to Open]
.Aug  9 05:32:25.597: Vi3 IPCP: State is Open
.Aug  9 05:32:25.597: Di1 IPCP: Install negotiated IP interface address 195.x.x.217
.Aug  9 05:32:25.601: Di1 Added to neighbor route AVL tree: topoid 0, address 77.220.110.79
.Aug  9 05:32:25.601: Di1 IPCP: Install route to 77.220.110.79
.Aug  9 05:32:25.605: Vi3 PPP: I pkt type 0x0021, datagramsize 80 link[ip]
.Aug  9 05:32:26.545: Vi3 PPP: I pkt type 0xC021, datagramsize 16 link[ppp]
.Aug  9 05:32:26.545: Vi3 LCP: I ECHOREQ [Open] id 1 len 12 magic 0xF2AA724C
.Aug  9 05:32:26.545: Vi3 LCP: O ECHOREP [Open] id 1 len 12 magic 0x810D5DEC

und man kommt auch direkt vom cisc ins inet...:

Code: Alles auswählen

Rou18#ping 8.8.8.8

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/34/36 ms
Rou18#

...aus dem lan geht aber genau nix:

Code: Alles auswählen

root@sin:netu>ping -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms

root@sin:netu>

jetzt bin ich endlich auf die "glorreiche" idee gekommen, die packets zu tracen, und dazu muß man am cisc die beschleunigungsmechanismen deaktivieren, sodaß die packerl über die cpu gehen, also:

Code: Alles auswählen

Rou18(config)#no ip cef

und dann gehts (die traces erspar ich mir):

Code: Alles auswählen

root@sin:netu>ping -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=51 time=34.9 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=51 time=34.2 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=51 time=34.3 ms

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 34.242/34.520/34.972/0.322 ms
root@sin:netu>

erinnert mich ein wenig an das prob mit der ip acceleration beim st608wl...

lg
zid

[sebaat]

Es läuft also doch - ich wusste es

Mal schauen, vielleicht sind die Damen in der Außenstelle noch mal so gnädig und räumen mir vor dem Tausch des P324 ein weiteres Wartungsfenster zum testen ein.

jetzt bin ich endlich auf die "glorreiche" idee gekommen, die packets zu tracen, und dazu muß man am cisc die beschleunigungsmechanismen deaktivieren, sodaß die packerl über die cpu gehen

Kleiner Tip am Rande: Mit den 15er IOS Versionen (ich glaube, sogar schon ab 12.4-20T) kann man Wireshark lesbare PCAP Files auf den Routern erstellen. Man kann auswählen, ob man den CEF Traffic oder den "Process-switched" Traffic mitschneiden will. Habe es bereits getestet und es funktioniert einwandfrei, Anleitung siehe hier.

[zid]

>"...Es läuft also doch - ich wusste es..."
ja, *du* hast leicht reden...
für uns wars echt frustrierend, daß der ppp-link stand und man nicht aus dem lan ins inet kam. aber zugegeben, im gegensatz zur dir sind wir wirklich vollidioten. ja, und was machen vollidioten, wenn sie eine konfig nicht in den griff bekommen? richtig! sie denken an einen bug und suchen eine "bugfreie" sw. und genau das haben wir getan, anstatt die überreste der grauen masse unter der schädeldecke anzuwerfen... hat uns viel zeit gekostet.

>"...Kleiner Tip am Rande:..."
danke für den hinweis. die epc kannte ich bereits, sehr schönes feature, man sollte es halt auch verwenden... btw. die bintecs haben sowas auch, und sogar die verpönten fb's können das.

lg
zid

[zid]

hm, sehr seltsam...

hallo sebaat,

also wirklich sauber rennt das pptp mit der konfig von früher nicht. ich hab in unregelmäßigen abständen unterbrechungen. sieht am tg (heute) so aus:

Code: Alles auswählen

=>systemlog show
...
<132> Aug 11 00:48:45 PPTP tunnel (PVC_DATA) down
<132> Aug 11 00:48:56 PPTP tunnel (PVC_DATA) up
<132> Aug 11 02:00:04 PPTP tunnel (PVC_DATA) down
<132> Aug 11 02:00:05 PPTP tunnel (PVC_DATA) up
<132> Aug 11 03:07:44 PPTP tunnel (PVC_DATA) down
<132> Aug 11 03:07:48 PPTP tunnel (PVC_DATA) up
<132> Aug 11 04:10:20 PPTP tunnel (PVC_DATA) down
<132> Aug 11 04:10:40 PPTP tunnel (PVC_DATA) up
<132> Aug 11 05:40:05 PPTP tunnel (PVC_DATA) down
<132> Aug 11 05:40:25 PPTP tunnel (PVC_DATA) up
<132> Aug 11 06:54:28 PPTP tunnel (PVC_DATA) down
<132> Aug 11 06:54:41 PPTP tunnel (PVC_DATA) up
<132> Aug 11 08:24:33 PPTP tunnel (PVC_DATA) down
<132> Aug 11 08:24:39 PPTP tunnel (PVC_DATA) up
<132> Aug 11 09:38:45 PPTP tunnel (PVC_DATA) down
<132> Aug 11 09:38:56 PPTP tunnel (PVC_DATA) up
<132> Aug 11 10:39:45 PPTP tunnel (PVC_DATA) down
<132> Aug 11 10:40:03 PPTP tunnel (PVC_DATA) up

diese unterbrechungen haben 2 eigenartige facetten:
1. sie werden durch ein "Authentication configuration changed" ausgelöst (die zeilen mit ! *** sind kommentare von mir):

Code: Alles auswählen

...
! *** vor dem tunnelabbau das letzte, erfolgreiche lcp echorq/echorp, id 144
Aug 10 14:02:09.044: Vi1 LCP: O ECHOREQ [Open] id 144 len 12 magic 0x2573D04C
Aug 10 14:02:09.060: Vi1 PPP: I pkt type 0xC021, datagramsize 16 link[ppp]
Aug 10 14:02:09.060: Vi1 LCP: I ECHOREP [Open] id 144 len 12 magic 0xF942DCE1
Aug 10 14:02:09.060: Vi1 LCP: Received id 144, sent id 144, line up

! *** das ist diese seltsame meldung vor dem tunnelabbau.
Aug 10 14:02:12.628: Vi1 PPP DISC: Authentication configuration changed
Aug 10 14:02:12.628: PPP: NET STOP send to AAA.
Aug 10 14:02:12.628: %DIALER-6-UNBIND: Interface Vi1 unbound from profile Di1
Aug 10 14:02:12.628: Vi1 PPP: Block vaccess from being freed [0x10]
.Aug 10 14:02:12.632: Di1 Deleted neighbor route from AVL tree: topoid 0, address 77.220.110.79
.Aug 10 14:02:12.632: Di1 IPCP: Remove route to 77.220.110.79
.Aug 10 14:02:12.640: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to down
.Aug 10 14:02:12.640: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down

! *** der pppd kriegt nicht mit, daß das intf Vi1 down ist. er macht munter
! *** mit den echorqs weiter (ids 145 und 146 passen) und zählt nur hoch -> echo_cnt 2
.Aug 10 14:02:19.059: Vi1 LCP: O ECHOREQ [Open] id 145 len 12 magic 0x2573D04C
.Aug 10 14:02:29.074: Vi1 LCP: O ECHOREQ [Open] id 146 len 12 magic 0x2573D04C
.Aug 10 14:02:29.074: Vi1 LCP: echo_cnt 2, sent id 146, line up
.Aug 10 14:02:38.646: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up
.Aug 10 14:02:38.646: %DIALER-6-BIND: Interface Vi1 bound to profile Di1
.Aug 10 14:02:38.650: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up

! *** das Vi1 ist up, und die echorq wird von der gegenstelle beantwortet.
! *** da das lcp-echo-failure nicht erreicht wurde, war der ppp-link für den
! *** pppd nie tot. es gibt keine neue einwahl.
.Aug 10 14:02:39.090: Vi1 LCP: O ECHOREQ [Open] id 147 len 12 magic 0x2573D04C
.Aug 10 14:02:39.090: Vi1 LCP: echo_cnt 3, sent id 147, line up
.Aug 10 14:02:39.106: Vi1 PPP: I pkt type 0xC021, datagramsize 16 link[ppp]
.Aug 10 14:02:39.110: Vi1 LCP: I ECHOREP [Open] id 147 len 12 magic 0xF942DCE1
.Aug 10 14:02:39.110: Vi1 LCP: Received id 147, sent id 147, line up

also irgendwas mit aaa, nur hab ich halt in hinblick auf aaa nix konfiguriert, nur "no aaa new model"...

2. zuerst dachte ich, das dieses prob was mit den pptp-echoes zu tun hat. dieser fall liegt aber definitiv nicht vor, weil das pptp-echo-interval 60s beträgt und hier die ccrq 12,3 s nach dem letzten, erfolgreichen pptp-echo rausgeht:

c1841_pptp_tunnel_down_up.png (88.08 KiB) 9691-mal betrachtet

man sieht hier auch sehr schön, daß es nach dem tunnelaufbau eben keine ppp-einwahl (lcp -> auth -> ipcp) gibt. für den pppd war der link nie tot.
unterm strich ist "nicht viel" passiert:
- eine unterbrechung von rd. 26 s, die sehr nervig sein kann.
- eine änderung der call id des cisc (in dem fall 44156 -> 41178), das tg verwendet immer die call id 0.

hast du vielleicht eine idee, was das sein und wie man es beheben könnte? die unterbrechungen dauern bis zu 50s...

lg
zid