26
Cisco 4321 auf ADSL2 BNG Plattform der Telekom
Hi zusammen,
habe mit einem Cisco 4321 und zwei ATM Interfacen folgendes Problem.
Beide Interface an einem ADSL/VDSL getestet und beide laufen sauber.
Das erste Interface an einem normalen ADSL 2 (nicht BNG mit VLAN TAG1) läuft, der Anschluss war schon vorhanden.
Der zweite Anschluss wurde neue bereitgestellt und läuft über eine BNG Plattform. Also habe ich das Interface entsprechend VLAN Tag 7 (wie bei VDSL nur auf dem ATM Interface)
konfiguriert. Der Anschluss wird synchron, bekomme aber keine IP vom Provider. PPPoe Session kommt nämlich nicht hoch.
TAG 7 ist aber gesetzt (Konfig nachfolgend). Telekom hat wohl alles geprüft und auch mit Messgerät am Anschluss und Benutzerdaten erfolgreich getestet.
Im Debug sehe PADI Pakete rausgehend, kommt aber kein PADO zurück. Telekom sagt mir nicht, ob die eine PADI's sehen und mit PADO's antworten.
Hat jemand eine Idee? Was kann ich noch machen um Futter zu liefern? Habe ich etwas vergessen?
Vielen Dank im Voraus an Alle.
interface ATM0/1/0
description Backupleitung neue ADSL Ltg.
no ip address
no atm ilmi-keepalive
no atm enable-ilmi-trap
!
interface ATM0/1/0.7 point-to-point
no atm enable-ilmi-trap
pvc 1/32
bridge-dot1q encap 7
pppoe-client dial-pool-number 1
interface Dialer1
description neue Backupleitung ADSL2 ueber BNG
mtu 1492
ip address negotiated
ip mtu 1452
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication pap callin
ppp pap sent-username <entfernt>#0001@t-online.de password 7 <entfernt>
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
no cdp enable
crypto map VPNviaDSL1
habe mit einem Cisco 4321 und zwei ATM Interfacen folgendes Problem.
Beide Interface an einem ADSL/VDSL getestet und beide laufen sauber.
Das erste Interface an einem normalen ADSL 2 (nicht BNG mit VLAN TAG1) läuft, der Anschluss war schon vorhanden.
Der zweite Anschluss wurde neue bereitgestellt und läuft über eine BNG Plattform. Also habe ich das Interface entsprechend VLAN Tag 7 (wie bei VDSL nur auf dem ATM Interface)
konfiguriert. Der Anschluss wird synchron, bekomme aber keine IP vom Provider. PPPoe Session kommt nämlich nicht hoch.
TAG 7 ist aber gesetzt (Konfig nachfolgend). Telekom hat wohl alles geprüft und auch mit Messgerät am Anschluss und Benutzerdaten erfolgreich getestet.
Im Debug sehe PADI Pakete rausgehend, kommt aber kein PADO zurück. Telekom sagt mir nicht, ob die eine PADI's sehen und mit PADO's antworten.
Hat jemand eine Idee? Was kann ich noch machen um Futter zu liefern? Habe ich etwas vergessen?
Vielen Dank im Voraus an Alle.
interface ATM0/1/0
description Backupleitung neue ADSL Ltg.
no ip address
no atm ilmi-keepalive
no atm enable-ilmi-trap
!
interface ATM0/1/0.7 point-to-point
no atm enable-ilmi-trap
pvc 1/32
bridge-dot1q encap 7
pppoe-client dial-pool-number 1
interface Dialer1
description neue Backupleitung ADSL2 ueber BNG
mtu 1492
ip address negotiated
ip mtu 1452
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication pap callin
ppp pap sent-username <entfernt>#0001@t-online.de password 7 <entfernt>
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
no cdp enable
crypto map VPNviaDSL1
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 351970
Url: https://administrator.de/contentid/351970
Ausgedruckt am: 22.11.2024 um 12:11 Uhr
26 Kommentare
Neuester Kommentar
Eigentlich hast du alles richtig gemacht !
Zitat aus dem hiesigen Cisco_Tutorial:
Hier noch ein wichtiger Hinweis für Nutzer die einen neuen ADSL2+ BNG Anschluss der Telekom haben die ein VLAN 7 Tagging auf dem ADSL Interface erfordert.
Dort muss die Konfiguration des ATM Interfaces entsprechen angepasst werden das der Router wie bei VDSL ein VLAN 7 Tag mitschickt:
interface ATM0
description DTAG-BNG ADSL2plus
no ip address
no atm ilmi-keepalive
!
interface ATM0.7 point-to-point
pvc 1/32
bridge-dot1q encap 7
pppoe-client dial-pool-number 1
!
Hier ist eine laufende, aktuelle BNG Konfig über VDSL:
!
interface Ethernet0
no ip address
!
interface Ethernet0.7
description VDSL Verbindung
encapsulation dot1Q 7
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface Dialer0
description xDSL BNG Einwahl Interface
ip address negotiated
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1492
ip nat outside
ip virtual-reassembly in
encapsulation ppp
dialer pool 1
dialer-group 1
no keepalive
ppp authentication pap callin
ppp pap sent-username xxxxxxxx@t-online.de password 0 xxxxxxx
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
no cdp enable
!
Also entweder ist das kein BNG Anschluss oder noch was anderes Mau damit. Hast du mal den PPPoE Debugger laufen lassen um nachzusehen was da genau los ist auf der Leitung ?!
Zitat aus dem hiesigen Cisco_Tutorial:
Hier noch ein wichtiger Hinweis für Nutzer die einen neuen ADSL2+ BNG Anschluss der Telekom haben die ein VLAN 7 Tagging auf dem ADSL Interface erfordert.
Dort muss die Konfiguration des ATM Interfaces entsprechen angepasst werden das der Router wie bei VDSL ein VLAN 7 Tag mitschickt:
interface ATM0
description DTAG-BNG ADSL2plus
no ip address
no atm ilmi-keepalive
!
interface ATM0.7 point-to-point
pvc 1/32
bridge-dot1q encap 7
pppoe-client dial-pool-number 1
!
Hier ist eine laufende, aktuelle BNG Konfig über VDSL:
!
interface Ethernet0
no ip address
!
interface Ethernet0.7
description VDSL Verbindung
encapsulation dot1Q 7
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface Dialer0
description xDSL BNG Einwahl Interface
ip address negotiated
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1492
ip nat outside
ip virtual-reassembly in
encapsulation ppp
dialer pool 1
dialer-group 1
no keepalive
ppp authentication pap callin
ppp pap sent-username xxxxxxxx@t-online.de password 0 xxxxxxx
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
no cdp enable
!
Also entweder ist das kein BNG Anschluss oder noch was anderes Mau damit. Hast du mal den PPPoE Debugger laufen lassen um nachzusehen was da genau los ist auf der Leitung ?!
Hi Aqui,
beide Module hatte ich zusätzlich an einem VDSL erfolgreich getestet, entspricht Deiner Konfig. Es ist definitiv ein BNG Anschluss, da die Konfig mit TAG1 vorher auch nicht ging. Das es ein BNG Anschluss ist, hatte ich von den lokalen Ansprechpartnern erst später erfahren und dann umkonfiguriert auf Tag 7.
Anbei ein Debug. Es kommt schon gar nicht zum Austausch von Username und PW.
Debug liefert rausgehende PADI's, aber rein kommt nichts. Ich würde hier PADO's seitens DSLAM erwarten oder ist das am BNG Anschluss anders?
ct 16 07:56:35.448: pppoe_send_padi
contiguous pak, size 74
00 01 00 00 AA AA 03 00 80 C2 00 07 00 00 FF FF
FF FF FF FF 70 1F 53 04 A2 08 88 63 11 09 00 00
00 10 01 01 00 00 01 03 00 08 BC 00 00 01 00 00
1A E8 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 ...
Oct 16 07:57:07.710: pppoe_send_padi:
contiguous pak, size 74
00 01 00 00 AA AA 03 00 80 C2 00 07 00 00 FF FF
FF FF FF FF 70 1F 53 04 A2 08 88 63 11 09 00 00
00 10 01 01 00 00 01 03 00 08 BC 00 00 01 00 00
1A E8 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 ...
Sh Controller vdsl0/1/0
DS Channel1 DS Channel0 US Channel1 US Channel0
Speed (kbps): NA 16939 NA 2376
SRA Previous Speed: NA 0 NA 0
Previous Speed: NA 17178 NA 2337
Total Cells: NA 2475355745 NA 2752790581
User Cells: NA 34717159 NA 8930153
Reed-Solomon EC: NA 711 NA 4577
CRC Errors: NA 0 NA 2
Header Errors: NA 0 NA 1
Interleave (ms): NA 7.91 NA 5.70
Actual INP: NA 1.01 NA 1.15
beide Module hatte ich zusätzlich an einem VDSL erfolgreich getestet, entspricht Deiner Konfig. Es ist definitiv ein BNG Anschluss, da die Konfig mit TAG1 vorher auch nicht ging. Das es ein BNG Anschluss ist, hatte ich von den lokalen Ansprechpartnern erst später erfahren und dann umkonfiguriert auf Tag 7.
Anbei ein Debug. Es kommt schon gar nicht zum Austausch von Username und PW.
Debug liefert rausgehende PADI's, aber rein kommt nichts. Ich würde hier PADO's seitens DSLAM erwarten oder ist das am BNG Anschluss anders?
ct 16 07:56:35.448: pppoe_send_padi
contiguous pak, size 74
00 01 00 00 AA AA 03 00 80 C2 00 07 00 00 FF FF
FF FF FF FF 70 1F 53 04 A2 08 88 63 11 09 00 00
00 10 01 01 00 00 01 03 00 08 BC 00 00 01 00 00
1A E8 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 ...
Oct 16 07:57:07.710: pppoe_send_padi:
contiguous pak, size 74
00 01 00 00 AA AA 03 00 80 C2 00 07 00 00 FF FF
FF FF FF FF 70 1F 53 04 A2 08 88 63 11 09 00 00
00 10 01 01 00 00 01 03 00 08 BC 00 00 01 00 00
1A E8 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 ...
Sh Controller vdsl0/1/0
DS Channel1 DS Channel0 US Channel1 US Channel0
Speed (kbps): NA 16939 NA 2376
SRA Previous Speed: NA 0 NA 0
Previous Speed: NA 17178 NA 2337
Total Cells: NA 2475355745 NA 2752790581
User Cells: NA 34717159 NA 8930153
Reed-Solomon EC: NA 711 NA 4577
CRC Errors: NA 0 NA 2
Header Errors: NA 0 NA 1
Interleave (ms): NA 7.91 NA 5.70
Actual INP: NA 1.01 NA 1.15
Hallo,
bitte noch mal deine config Zeile für Zeile abgleichen....
die MTU Size ist unterschiedlich
du hast kein "no keepalive" konfiguriert (sollte aber keine Rolle spielen)
Dir fehlt in der T-online Kennung '#0001'
und noch ein paar andere details.
brammer
bitte noch mal deine config Zeile für Zeile abgleichen....
die MTU Size ist unterschiedlich
du hast kein "no keepalive" konfiguriert (sollte aber keine Rolle spielen)
Dir fehlt in der T-online Kennung '#0001'
und noch ein paar andere details.
brammer
Ich würde hier PADO's seitens DSLAM erwarten oder ist das am BNG Anschluss anders?
Das ist genau richtig !Auf dein PADI muss zwangsweise ein PADO vom DSLAM kommen !!
https://de.wikipedia.org/wiki/PPP_over_Ethernet
Wenn also dein Modem wirklich gesynct hat (blinkende LED leuchtet konstant) dann arbeitet der DSLAM nicht oder der Anschluß ist seitens der Telekom noch nicht aktiviert worden.
Dir fehlt in der T-online Kennung '#0001'
Nee, hat er nur eben entfernt aus der Konfig... 
Der fehlende PADO Reply des DSLAMs kommt aber vor der Authentisierung. Es kommt also erst gar keine PPPoE Session zustande weil der DSLAM nicht antwortet.
Kann natürlich auch das Anschlusskabel sein oder sowas. Wenn du das ausschliessen kannst ist vermutlich der Anschluß gar nicht aktiv seitens des Providers.
Was sagt denn ein sh contr vdsl xy detail ??
Kannst du dort ein:
Controller VDSL 0 is UP
Daemon Status: Up
XTU-R (DS) XTU-C (US)
Chip Vendor ID: 'BDCM' 'BDCM'
Modem Version Near: 15.6(3)M3
Modem Version Far: 0xb18c
Modem Status: TC Sync (Showtime!)
DSL Config Mode: AUTO
Trained Mode: G.993.2 (VDSL2) Profile 17a
TC Mode: PTM
Selftest Result: 0x00
DELT configuration: disabled
DELT state: not running
sehen ?? "Showtime!" zeigt den erfolgreichen Sync Prozess.
Ja den Suffix für den Hauptbenutzer habe ich entfern und ist nicht zwingend ab 12 Stellen.
Ich hätte noch auf die MTU (1492) auf dem dialer getippt, da 4 Byte für den Tag benötigt wird, aber dann hätte es schon beim VDSL Anschluss haken müssen, da der auch Tag 7 benötigt.
Der Controller meldet sauberen Connect und vernünftige downtime und Uptime
Hier der Status gekürzt. Die DTAG meldet auch synchroner Port am DSLAM. Zu den PADI/PADO sagen die mir nichts.
Modem Status: TC Sync (Showtime!)
DSL Config Mode: AUTO
Trained Mode: G.992.5 (ADSL2+) Annex J
TC Mode: ATM
Selftest Result: 0x00
DELT configuration: disabled
DELT state: not running
Failed full inits: 0
Short inits: 0
Failed short inits: 0
Modem FW Version: 4.14L.04
Modem PHY Version: B2pv6F039g1.d26d
Was mich stutzig macht ist, dass ein Techniker mit Messgerät und der gleichen Konfig (nicht easy config) sondern Sendung von unseren Benutzerdaten getestet hat und angeblich eine Internetverbindung bekommen hat.
Die IOS hat auch keinen BUG gemeldet, wenn auch nicht die recommended.
Egal ob Easy Config an oder aus, es will nicht.
Bin morgen vor Ort und teste mit zweitem Router und neuer IOS. DTAG Techniker kommt mittags wohl auch noch.
Wenn einer noch eine Idee bis dahin hat, herzlich willkommen.
Auf jeden Fall berichte ich eine Lösung hier für alle.
Vielen DAnk
Locke
Ich hätte noch auf die MTU (1492) auf dem dialer getippt, da 4 Byte für den Tag benötigt wird, aber dann hätte es schon beim VDSL Anschluss haken müssen, da der auch Tag 7 benötigt.
Der Controller meldet sauberen Connect und vernünftige downtime und Uptime
Hier der Status gekürzt. Die DTAG meldet auch synchroner Port am DSLAM. Zu den PADI/PADO sagen die mir nichts.
Modem Status: TC Sync (Showtime!)
DSL Config Mode: AUTO
Trained Mode: G.992.5 (ADSL2+) Annex J
TC Mode: ATM
Selftest Result: 0x00
DELT configuration: disabled
DELT state: not running
Failed full inits: 0
Short inits: 0
Failed short inits: 0
Modem FW Version: 4.14L.04
Modem PHY Version: B2pv6F039g1.d26d
Was mich stutzig macht ist, dass ein Techniker mit Messgerät und der gleichen Konfig (nicht easy config) sondern Sendung von unseren Benutzerdaten getestet hat und angeblich eine Internetverbindung bekommen hat.
Die IOS hat auch keinen BUG gemeldet, wenn auch nicht die recommended.
Egal ob Easy Config an oder aus, es will nicht.
Bin morgen vor Ort und teste mit zweitem Router und neuer IOS. DTAG Techniker kommt mittags wohl auch noch.
Wenn einer noch eine Idee bis dahin hat, herzlich willkommen.
Auf jeden Fall berichte ich eine Lösung hier für alle.
Vielen DAnk
Locke
Fakt ist aber das kein PADO kommt vom DSLAM. Tagging sollte ja auch stimmen mit 7.
Da sind wir mal gespannt was morgen dabei rauskommt
Da sind wir mal gespannt was morgen dabei rauskommt
So, war heute mit einem DTAG Techniker auf Fehlersuche, generell gehen die beiden BNG Anschlüsse. Einwahl mit dem ARGUS (Messgerät) geht und auch eine http Session. Beide NIM-VA-B Interface im Cisco ISR-4321 senden PADI's > aber expired da keine PADO Antwort.
Kann sein, dass die DTAG keine PADO sendet, weil etwas nicht i.O. ist. Konfig absolut sauber, auch nach Rücksprache mit DTAG Cisco Team.
Zyxel Modem transparent davor geschaltet und mit dem zweiten Ethernet Interface verbunden. Sub-Interface konfiguriert, Dialer gesetzt und BINGO Einwahl klappt, PPPoe Session steht.
Irgendwas stimmt mit der Übermittlung des TAGGING bei den NIM-VA-B Interfacen nicht, sobald es auf eine BNG geht. Getestet mit 2 x Cisco ISR-4321 mit jeweils zwei NIM-VA-B Interfacen. Wie gesagt ADSL2 (TAG 1) und VDSL (Tag 7) gehen problemlos.
Gibt es evtl. ein Problem mit der Modem Firmware beim Einsatz mit der BNG?
Soweit die Erkenntnisse, aber noch keine Lösung.
Sehr strange. Die Aktualisierung der Modem FW beim ISR-4321 ist leider nicht so trivial wie bei den 886VA.
Bleibt also spannend.
Falls noch jemand eine Idee hat bzw. etwas dazu findet, ich wäre dankbar....
Viele Grüße an Alle
Locke
Kann sein, dass die DTAG keine PADO sendet, weil etwas nicht i.O. ist. Konfig absolut sauber, auch nach Rücksprache mit DTAG Cisco Team.
Zyxel Modem transparent davor geschaltet und mit dem zweiten Ethernet Interface verbunden. Sub-Interface konfiguriert, Dialer gesetzt und BINGO Einwahl klappt, PPPoe Session steht.
Irgendwas stimmt mit der Übermittlung des TAGGING bei den NIM-VA-B Interfacen nicht, sobald es auf eine BNG geht. Getestet mit 2 x Cisco ISR-4321 mit jeweils zwei NIM-VA-B Interfacen. Wie gesagt ADSL2 (TAG 1) und VDSL (Tag 7) gehen problemlos.
Gibt es evtl. ein Problem mit der Modem Firmware beim Einsatz mit der BNG?
Soweit die Erkenntnisse, aber noch keine Lösung.
Sehr strange. Die Aktualisierung der Modem FW beim ISR-4321 ist leider nicht so trivial wie bei den 886VA.
Bleibt also spannend.
Falls noch jemand eine Idee hat bzw. etwas dazu findet, ich wäre dankbar....
Viele Grüße an Alle
Locke
Das ist sehrt gut möglich das es an der Modem Firmware liegt. Gut Möglich das du auch einen Annex A Adapter da hast. Der geht natürlich nicht. Es muss dann schon B oder J sein.
Das musst du alles mal ganz genau checken. Die Modem Firmware solltest du in jedem Falle updaten, am besten auf die Telekom zertifizierte Version.
Damit gehst du dann auf Nummer sicher. Es kann ja einzig nur noch daran liegen, denn wenn ein anderer Adapter mit der gleichen Grundkonfig die Verbindung herstellen kann bleibt nur noch das Modem an sich übrig.
Das musst du alles mal ganz genau checken. Die Modem Firmware solltest du in jedem Falle updaten, am besten auf die Telekom zertifizierte Version.
Damit gehst du dann auf Nummer sicher. Es kann ja einzig nur noch daran liegen, denn wenn ein anderer Adapter mit der gleichen Grundkonfig die Verbindung herstellen kann bleibt nur noch das Modem an sich übrig.
Hi Aqui, vielen Dank. Der Adapter ist ein B und wurde ja auch an ADSL2 und VDSL erfolgreich getestet.
Wo kann ich die von der Telekom zertifizierte Verseion nachschlagen, hast Du einen Link?
Vielen Dank und Grüße
Wo kann ich die von der Telekom zertifizierte Verseion nachschlagen, hast Du einen Link?
Vielen Dank und Grüße
Aber immer doch...:
https://software.cisco.com/download/release.html?mdfid=286006221&sof ...
https://software.cisco.com/download/release.html?mdfid=286006221&sof ...
Hi Aqui, die 3.16_19t ist drauf. Uch habe auch vom Dtag Techniker eine Kompatibilitätsmatrix und Konfigbeispiele für alle unterstützten Ciso Router bekommen, passt. Ein FW Upgrade wäre beim NIM-VA-B an der BNG nicht nötig. Echt komisch.
Möglich das die Module defekt sind ?! Wenn du sie unter Wartung hast mache einfach ein RMA.
Hi Aqui, ausgeschlossen. Habe 2 Nim Module im Router. Ein zweiter Router auch mit zwei NIMs, immer das gleiche Spiel. Laufen auch beide am VDSLer sowie ADSL mit Tag 1 (am nicht BNG Anschluss). Habe über unseren Partner jetzt einen Cisco Tac Cade offen und mache morgen ne Webex Session mit Cisco, da die Zeit drängt. Ich melde mich sobald ich mehr weiss.
Viele Grüße
Locke
Viele Grüße
Locke
OK, dann kann man einen Defekt in der Tat sicher ausschliessen.
Ein Feedback über den TAC Case wäre mal sehr interessant !
Gerade im Hinblick darauf, das die Router z.B. 880er und 890 mit ihren embeddeten xDSL Modems erwiesenermaßen fehlerlos mit den Telekom BNG Anschlüssen laufen.
In sofern würde man dann doch einen Firmware Bug vermuten.
Mal sehen was das TAC sagt.... Es bleibt spannend
Ein Feedback über den TAC Case wäre mal sehr interessant !
Gerade im Hinblick darauf, das die Router z.B. 880er und 890 mit ihren embeddeten xDSL Modems erwiesenermaßen fehlerlos mit den Telekom BNG Anschlüssen laufen.
In sofern würde man dann doch einen Firmware Bug vermuten.
Mal sehen was das TAC sagt.... Es bleibt spannend
Hi,
3,5 Stunden Trouble Shooting am System per Webex mit 2 Cisco Technikern, kein Ergebnis. Cisco US analysiert die Debugs im Nachgang. Evtl. Eine Inkompatibilität in diesem Szenario. Lt. Telekom aber alles kompatibel, bleibt weiterhin spannend. Mehr demnächst.
VG Locke
3,5 Stunden Trouble Shooting am System per Webex mit 2 Cisco Technikern, kein Ergebnis. Cisco US analysiert die Debugs im Nachgang. Evtl. Eine Inkompatibilität in diesem Szenario. Lt. Telekom aber alles kompatibel, bleibt weiterhin spannend. Mehr demnächst.
VG Locke
Das ist ja wie Tatort ! 
Hi,
Cisco hat sich endlich gemeldet. Angeblich gibt es in dieser Konstellation mit dem ISR4321 und den NIM-VA-B auf der BNG Plattform der DTAG IOS Probleme. Angeblich gab es noch einen Fall bei einem anderen Kunden und die Lösung war wohl Firmware Upgrade auf Cisco IOS XE 16.6.1.
Das ist wohl die einzige lauffähige IOS bei dem Router auf ner BNG. Witzig ist, daß die Telekom in Ihrer Kompatibilitätsmatrix schreibt, daß dieser Router mit deiesen Modulen kompatibel zur BNG Plattform ist und auch kein IOS Upgrade notwendig wäre >>> WITZIG. Die haben ja echt gut getestet. Ich mache nun, sobald mich mein Kunde läßt, das Upgrade und melde mich mit der hoffentlich finalen Lösung. Den zweiten Router habe ich damit schon bestückt, hier kommt dies aber wohl nicht zum tragen, da er eh an einen VDSLer kommt, der Fehler aber nur bei einem Tagging auf den ATM PVC auftritt.
Anbei ein Ausschnitt aus dem CISCO case. Der BUG wurde bisher von Cisco nicht veröffentlicht und daher gab es keine BUG Meldung für diesen Fehler. Wir haben angefordert dies publik zu machen, da der Schwenk auf die BNG Plattform seitens Telekom nun schnell voranschreitet.
Wenn einer die Kompatibilitätsmatrix und Doku der Anbindungen (von UC bis VDSL) der DTAG haben möchte, dann lasst es mich wissen.
Cisco ########
There is an internal bug documented for this behavior; however, it hasn’t been published as customer visible yet but, I can share with you the details to let you consider if we are hitting the same reported behavior:
Description: bridge-dot1q encap configured under ATM pvc not working on ISR4321
Symptoms - We are getting PADI timer expired !
Configuration :
interface ATM0/1/0
no ip address
load-interval 30
!
interface ATM0/1/0.1 point-to-point
no atm enable-ilmi-trap
pvc 1/32
bridge-dot1q encap 7
encapsulation aal5snap
pppoe-client dial-pool-number 1
Versions(To-be-fixed) : 16.6.1
Also, this situation was reported earlier with other customer and the situation was addressed by upgrading the Cisco IOS XE 16.6.1. Please let me know if you may have any queries or concerns; I look forward to hearing from you.
Cisco hat sich endlich gemeldet. Angeblich gibt es in dieser Konstellation mit dem ISR4321 und den NIM-VA-B auf der BNG Plattform der DTAG IOS Probleme. Angeblich gab es noch einen Fall bei einem anderen Kunden und die Lösung war wohl Firmware Upgrade auf Cisco IOS XE 16.6.1.
Das ist wohl die einzige lauffähige IOS bei dem Router auf ner BNG. Witzig ist, daß die Telekom in Ihrer Kompatibilitätsmatrix schreibt, daß dieser Router mit deiesen Modulen kompatibel zur BNG Plattform ist und auch kein IOS Upgrade notwendig wäre >>> WITZIG. Die haben ja echt gut getestet. Ich mache nun, sobald mich mein Kunde läßt, das Upgrade und melde mich mit der hoffentlich finalen Lösung. Den zweiten Router habe ich damit schon bestückt, hier kommt dies aber wohl nicht zum tragen, da er eh an einen VDSLer kommt, der Fehler aber nur bei einem Tagging auf den ATM PVC auftritt.
Anbei ein Ausschnitt aus dem CISCO case. Der BUG wurde bisher von Cisco nicht veröffentlicht und daher gab es keine BUG Meldung für diesen Fehler. Wir haben angefordert dies publik zu machen, da der Schwenk auf die BNG Plattform seitens Telekom nun schnell voranschreitet.
Wenn einer die Kompatibilitätsmatrix und Doku der Anbindungen (von UC bis VDSL) der DTAG haben möchte, dann lasst es mich wissen.
Cisco ########
There is an internal bug documented for this behavior; however, it hasn’t been published as customer visible yet but, I can share with you the details to let you consider if we are hitting the same reported behavior:
Description: bridge-dot1q encap configured under ATM pvc not working on ISR4321
Symptoms - We are getting PADI timer expired !
Configuration :
interface ATM0/1/0
no ip address
load-interval 30
!
interface ATM0/1/0.1 point-to-point
no atm enable-ilmi-trap
pvc 1/32
bridge-dot1q encap 7
encapsulation aal5snap
pppoe-client dial-pool-number 1
Versions(To-be-fixed) : 16.6.1
Also, this situation was reported earlier with other customer and the situation was addressed by upgrading the Cisco IOS XE 16.6.1. Please let me know if you may have any queries or concerns; I look forward to hearing from you.
Hallo,
Das die DTAG das als kompatibel betrachtet Wundert mich gar nicht... was ich dort an Antworten bekommen ist manchmal "interessant" .
Ich glaube auch weniger an einen Bug im IOS sondern eine Handlung Problem auf Seiten der BNG.
Aber wenn Cisco das handling durch ein IOS Update fixen kann... super...
Schön dass das Problem gelöst werden konnte umd du uns informiert hast.
Freut mich.
Brammer
Das die DTAG das als kompatibel betrachtet Wundert mich gar nicht... was ich dort an Antworten bekommen ist manchmal "interessant" .
Ich glaube auch weniger an einen Bug im IOS sondern eine Handlung Problem auf Seiten der BNG.
Aber wenn Cisco das handling durch ein IOS Update fixen kann... super...
Schön dass das Problem gelöst werden konnte umd du uns informiert hast.
Freut mich.
Brammer
Konnte bei diesen Symptomen auch eigentlich nur ein Bug sein. Aber gut wenn das nun geklärt ist.
Zum Test der Telekom mal keinen Kommentar...
Dank ebenfalls fürs Feedback. Sowas ist hilfreich.
Schreib mal obs dann final mit der 16.6.1er SW wirklich rennt...wär mal spannend.
Zum Test der Telekom mal keinen Kommentar...
Dank ebenfalls fürs Feedback. Sowas ist hilfreich.
Schreib mal obs dann final mit der 16.6.1er SW wirklich rennt...wär mal spannend.
Hi zusammen,
heute war Upgrade Tag, leider kein Erfolg mit der Version 16.6.1.
Nach wie vor Anschluss wieder synchron, aber keine IP.
Verhalten hat sich etwas geändert, jetzt schickt das ATM Interface gar nichts mehr raus, echt BOMBE.
Habe an Cisco zurückgemeldet und warte auf weitere Vorschläge, wie man es lösen will.
Der zweite Router bei dem Kunden an einem anderen Ort, allerdings an einem VDSLer, rennt super.
Ein weiterer ADSL BNG Anschluß bei einem anderen Kunden mit einem 886VA ging problemlos.
Bleibt leider spannend.
Ich werde weiter berichten.
heute war Upgrade Tag, leider kein Erfolg mit der Version 16.6.1.
Nach wie vor Anschluss wieder synchron, aber keine IP.
Verhalten hat sich etwas geändert, jetzt schickt das ATM Interface gar nichts mehr raus, echt BOMBE.
Habe an Cisco zurückgemeldet und warte auf weitere Vorschläge, wie man es lösen will.
Der zweite Router bei dem Kunden an einem anderen Ort, allerdings an einem VDSLer, rennt super.
Ein weiterer ADSL BNG Anschluß bei einem anderen Kunden mit einem 886VA ging problemlos.
Bleibt leider spannend.
Ich werde weiter berichten.
Klasse. Danke für das Feedback. Das ist ja spannender als ein Krimi.
Mal sehen ob die Ciscoianer im TAC das fixen können. Halt uns mal auf dem Laufenden...!
Mal sehen ob die Ciscoianer im TAC das fixen können. Halt uns mal auf dem Laufenden...!
Sorry, muss wieder etwas Spannung rausnehmen. Mir ist gestern leider nicht aufgefallen, dass nach dem Upgrade der Dial-Pool nicht mehr auf dem PVC gebunden war. Habe nach dem Upgrade wohl nicht mehr richtig geschaut. Gebunden und geht, daher Cisco mit der IOS XE 16.6.1 entlassen, die geht. Somit FINALE.
Vielen Dank an Alle für die Beiträge, aber besonders wieder an Aqui, der hier sehr aktiv unterstützt.
Besten Dank und bis demnächst.
Viele Grüße
Locke
Vielen Dank an Alle für die Beiträge, aber besonders wieder an Aqui, der hier sehr aktiv unterstützt.
Besten Dank und bis demnächst.
Viele Grüße
Locke
Tadaaa !! Das war dann die Ehrenrettung fürs Cisco TAC
...und danke für die Blumen.
...und danke für die Blumen.
Noch kurz zum Abschluß, dann begraben wir den Thread.
Von Cisco gibt es jetzt auch einen (CCO-)öffentlichen Bug: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvc67435
Viele Grüße
LOCKE
Von Cisco gibt es jetzt auch einen (CCO-)öffentlichen Bug: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvc67435
Viele Grüße
LOCKE
Interessant das das als "Moderate" eingestuft wurde. Bei den meisten Kunden in EMEA bedeutet der Bug die Funktionslosigkeit. Aber nundenn....
Danke für das ausführliche Feedback !
Danke für das ausführliche Feedback !
Hallo,
nun die Einstufung "Moderate" dürfte an der Häufigkeit dieser Konstellation liegen.
ein Cisco 4000 an einem BNG Anschluss ...davon wird es nicht so viele geben.
brammer
nun die Einstufung "Moderate" dürfte an der Häufigkeit dieser Konstellation liegen.
ein Cisco 4000 an einem BNG Anschluss ...davon wird es nicht so viele geben.
brammer
