hallo allerseits! aktuell vorhanden: Business Internet mit fixer IP, PPPoE und Centro Business 2.0. der CB 2.0 laeuft mit PPPoE Passthrough, router/firewall habe ich je nach lust und laune: Ubiquiti EdgeRouter-X ER-X, pfSense oder Sophos UTM. laeuft auch alles einwandfrei. nun moechte ich das ganze aber ohne Centro Business 2.0 ans laufen kriegen. ich habe ein G.fast SFP modul von Swisscom und einen tp-link MC220L medienkonverter. leider kriege ich das so nicht zum funktionieren. weder mit noch ohne VLAN 10 auf der WAN schnittstelle bekomme ich eine verbindung. weiss jemand ob das ueberhaupt so hinzubekommen ist und falls ja: wie? schoene gruesse aus bern, m.

Unser SFP benötigt Treiber in der Software des CPEs. Die haben bislang nur die IBP und IBS und einige Cisco-Router. CPE-Hersteller können die Treiber bei Metanoia bekommen. Ansonsten sind mir neben der IB2, dem CB2 und der Internet-Box von Sunrise keine CPEs bekannt, die g.fast derzeit unterstützen.

mein medienkonverter hängt am glas, müsste jedoch theoretisch mit dem g.fast modul auch synchronisieren. hast du die dhcp option 60 eingetragen? z.b beim edge router müsste das etwa so aussehen: interfaces { ethernet eth0 { duplex auto speed auto vif 10 { address dhcp address dhcpv6 bandwidth { } description Internet dhcp-options { client-option "send vendor-class-identifier "100008,0001";"

hallo konfuzius danke fuer deine antwort. mein anschluss laeuft aber, wie oben erwaehnt, mit PPPoE. somit duerfte die DHCP option 60 wenig hilfreich sein..?

niemand eine idee ob und allenfalls wie man G.fast ohne Centro Business 2.0 ans laufen bekommen kann? ist es moeglich mit dem G.fast SFP modul von swisscom? gibt es G.fast bridges am freien markt?

sauber, danke fuer die kompetente antwort!

> * * * > > @Anonym schrieb: > > Ansonsten sind mir neben der IB2, dem CB2 und der Internet-Box von Sunrise keine CPEs bekannt, die g.fast derzeit unterstützen. > > * * * Die [Fritzbox 7582](https://avm.de/produkte/fritzbox/fritzbox-7582/) kann g.fast, soll aber zunächst nur an Provider ausgeliefert werden. Wobei sich das Interesse daran von Seiten Swisscom wohl in Grenzen halten wird.

@Anonym ich habe mir einen abgegoogelt, bin aber leider nicht fuendig geworden: welche cisco router haben die benoetigte firmware fuer das G-fast SFP modul onboard? danke schon mal!

Keine Ahnung. Weiss nur, dass Cisco das gemacht hat. Business-Router sind nicht mein Bereich.

> * * * > > @"mikeboss"#49226 schrieb: > > ich habe mir einen abgegoogelt, bin aber leider nicht fuendig geworden: welche cisco router haben die benoetigte firmware fuer das G-fast SFP modul onboard? > > danke schon mal! > > * * * Probiere doch mal bei Cisco anzufragen, vielleicht hast Du Glück! [https://www.cisco.com/c/de\_ch/support/index.html](https://www.cisco.com/c/de_ch/support/index.html)

Lieber @"mikeboss"#49226 Zufällig habe ich auf folgendes Dokument gestossen, auf dem die Unterstützung des G.fast-Moduls fürs C897VA-K9 erwähnt wird. Woanderes konnte ich nicht irgendwelchen Hinweis zu G.fast-Modul ausfindig machen können. (Bin selbst auf der Suche nach so einem Plattform Cross Platform Release Notes for Cisco IOS Release 15.5M&T - Features and Important Notes for Cisco IOS Release 15.5(3)M \[Cisco IOS 15.5M&T\] - Cisco [https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/15-5m-and-t/release/notes/15-5m-and-t-book/155-3MNEWF.html#con\_163597](https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/15-5m-and-t/release/notes/15-5m-and-t-book/155-3MNEWF.html#con_163597) \> G.Fast SFP is a small form-factor pluggable module for use in a customer premise equipment (CPE) on existing C897VA-K9 platform to get Gigabit access rate on copper cable at any time. Ich persönlich würde mich sehr interessieren, ob es auch mit den ähnlichen Plattformen wie C892FSP oder C891F funktionieren täte. Wenn es eh G.fast ist, was wir schliesslich brauchen, brauchen wir ja auch kein VDSL2-Modem eingebaut![😉](https://community.swisscom.ch/html/@371E6B894055D81C5FEC7CB8590B7AEA/images/smilies/winking.png "😉") Ausserdem habe ich folgendes Blatt gefunden, auf dem das Plattform C1113 als G.fast-fähig erwähnt wird. Auch sehr interessant, jedoch ist es dabei zu beachten, dass das eingebaute G.fast-Modem noch nicht von Swisscom offiziell zugelassen ist. [https://www.cisco.com/c/dam/en/us/products/collateral/routers/1000-series-integrated-services-routers-isr/q-and-a-c67-739639.pdf](https://www.cisco.com/c/dam/en/us/products/collateral/routers/1000-series-integrated-services-routers-isr/q-and-a-c67-739639.pdf) Grüss

danke! den cisco habe ich dann am ende auch gefunden. ich bezweifle jetzt aber mal stark, dass der preislich auch nur ansatzweise interessant sein koennte... vermutlich preislich attraktiv und mit an sicherheit grenzender wahrscheinlichkeit kompatibel durfte die G.fast bridge von HUAWEI sein. immerhin ist meines wissens auf der seite swisscom auch HUAWEI equipment im seinsatz. Huawei MT992-10 leider nur bei alibaba zu kaufen gefunden bis jetzt. grz! m.

G.fast ohne Swisscom CPE moeglich?

rayman01

Guten Abend @iichikocchi

Konnte die Versionen soeben testen. Es würde mit beiden funktioneiren. Habe einen kleinen Konfigurationsfehler gemacht. Da der VDSL 8 Controller auf das GigabitEthernet 8 gemapped ist, habe ich pppoe vergessen auf dem GigabitEthernet 8 zu konfigurieren...

Nun funktioniert alles wie gewünscht. Nur erreiche ich noch nicht meine mögliche Bandbreite.

Muss dies nun noch genau abklären

Danke aber vielmals für deine Hilfe.

Liebe Grüsse und bis bald

rayman01

user109

@rayman01 schon die Hausinstallation angepasst (BBR-Installation)? BBR Installation: U72M 1x2x0.5 Kabel vom Router direkt zum UP.

rayman01

@user109, ja der Elektriker war diese Woche bei mir und hat das Kabel ausgetauscht. Danke aber für die Idee.

user109

@rayman01 habe schon erlebt, das die von Swisscom verlegten uralt Kabel zuviel Dämpfung auf der Leitungslänge haben und deshalb Du nicht die versprochenen Access erreichst. Aber achtung Accessprofile ist was anderes als Userprofil.

netztier

@rayman01 schrieb:

Nur erreiche ich noch nicht meine mögliche Bandbreite.

Hallo rayman01

Meinst du die Werte, welche bei...

show controller vdsl 8

(vgl Post 35 in diesem Thread)... ersichtlich werden, oder meinst du den Netto-Durchsatz, gemessen mit einer der diversen Speed-Test-Sites?

Falls es bei zweiteren "klemmt", musst du unbedingt die CPU-Last des Routers im Auge behalten.

show proc cpu history

IPv4-NAT bzw. NAT-Overload treibt die CPU kräftig in den roten bereich auf den 800ern. Die jüngeren C8xx sind besser als die älteren CISCO8xx (genaue Modellnummer anschauen mit "show inventory"): ein älterer CISCO891 hatte bei mir schon bei ca _80Mbit/s seine Grenzen erreicht, und zuvor der CISCO881 bei _60Mbit/s. Der neuere C892FSP packt die 100Mbit, welche ich auf dem DSL derzeit erreichen kann.

Ausweg aus dieser Situation: HW-Upgrade des Routers (Bei Cisco geht das dann Richtung ISR1000- oder ISR4000-Serie, ggf. mit BOOST-Lizenz). Bitter, aber ist so.

Falls hingegen an den Werten der DSL-Leitung (NDR, ATTNDR) klemmt, dann fällt der Fokus wohl auf die Verkabelung bis zum G.fast-SFP.

Cheers

Marc

rayman01

Hallo @netztier

Danke für dein Tipp mit der CPU. Werde dies prüfen. Ja, ich meinte die 2. Variante (speed test website).

Habe ein 897VA. Die Zweidrahtleitung wurde diese Woche durch einen Elektriker ausgetauscht (somit sollte diese in Ordnung sein).

Cheers and thanks,

Remy

rayman01

Hallo @user109@"x"#44768

ich bin nun in zusammenarbeit mit meinem Provider etwas schlauer. Es sieht aus als würde bridge tap die Aufschaltung von g.fast verhindern...

Könnte das der Grund sein, dass ich die maximale Bandbreite nicht beziehen kann?

Danke für eure Hilfe

Gruss Remy

user109

@rayman01 wenn dein Elekriker sauber gearbeit hat dürftest Du keine Bridgetabs mehr haben, es sei denn es gibt ein Problem mit der Zuleitung von Aussen zu UP. Oder ist der MCAN in deinem Gebäude installiert?

rayman01

@user109 ich bin mir nicht sicher od der MCAN bei uns im Gebäude ist. Wir wohnen im einem Mehrfamilienhaus.

Könntest du mir kurz erklären was ein MCAN ist? Sorry. Kenne mich im ISP Umfeld zu wenig aus.
Auf jeden Fall wurde die Leitung vom Gebäudeeingang bis zum Routeranschluss ersetzt. Trotzdem sieht mein Provider noch ein bridge tab.

user109

@rayman01 das kann mit dem Bridgetap kann gut sein kommt aber vom MCAN von der Strasse.

siehe hier: http://www.cablex.ch/ger/News/2016-07-07-Wissen-Sie-was-eine-Muffe-ist-oder-ein-FTTS-Micro-CAN

rayman01

@user109, danke vielmals für die Erklärung. Das würde heissen, dass ich via meinen ISP auf die Swisscom zugehen sollte, oder?

user109

@rayman01 solltest Du so machen.

netztier

als würde bridge tap die Aufschaltung von g.fast verhindern...

Könnte das der Grund sein, dass ich die maximale Bandbreite nicht beziehen kann?

Ein "bridge tap" ist eine Abzweigung im Kabel, oder ein sonstiger Kabelfehler, bevor das Aderpaar die "Digitaldose" bzw das xDSL-Gerät erreicht. Die "Modem"-Bausteine (wenn mam denn hier noch von "Modem" sprechen mag) an beiden Enden der Leitung messen sowas aus und "schalten dann quasi nicht in die oberen Gänge".

Das müsste sich nach meinem Verständnis aber niederschlagen in den (im Vergleich zum Line-Checker) zu tiefen) Werten, welche bei "show controller vdsl 8" auftauchen. Was sagt dir dein Cisco hier?

rayman01

Hallo netztier, sorry meine extrem späte Antwort. Leider ist das BridgeTap noch immer da. Die Leitung etwas stabieler, aber eventuell hast du mir noch einen Tipp:
Log des Routers:

001025: *May 4 02:51:05.592: %PQII_PRO_FE-3-TXERR: Ethernet0: Fatal transmit error. Restarting...
001026: *May 4 02:51:08.592: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state to up
001027: *May 4 02:51:14.780: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state to down
001028: *May 4 05:02:16.739: %PQII_PRO_FE-3-TXERR: Ethernet0: Fatal transmit error. Restarting...
001029: *May 4 05:02:19.739: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state to up
001030: *May 4 05:02:24.987: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state to down
001031: *May 4 07:13:27.899: %PQII_PRO_FE-3-TXERR: Ethernet0: Fatal transmit error. Restarting...
001032: *May 4 07:13:30.899: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state to up
001033: *May 4 07:13:35.195: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state to down
001034: *May 4 09:24:39.002: %PQII_PRO_FE-3-TXERR: Ethernet0: Fatal transmit error. Restarting...
001035: *May 4 09:24:42.002: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state to up
001036: *May 4 09:24:45.410: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state to down
001037: *May 4 11:35:49.978: %PQII_PRO_FE-3-TXERR: Ethernet0: Fatal transmit error. Restarting...
001038: *May 4 11:35:52.982: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state to up
001039: *May 4 11:35:55.618: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state to down
001040: *May 4 13:47:01.045: %PQII_PRO_FE-3-TXERR: Ethernet0: Fatal transmit error. Restarting...
001041: *May 4 13:47:04.045: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state to up
001042: *May 4 13:47:05.841: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state to down
001043: *May 4 15:58:12.069: %PQII_PRO_FE-3-TXERR: Ethernet0: Fatal transmit error. Restarting...
001044: *May 4 18:10:27.524: %PQII_PRO_FE-3-TXERR: Ethernet0: Fatal transmit error. Restarting...
001045: *May 4 18:10:30.524: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state to up
001046: *May 4 18:10:36.248: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state to down
001047: *May 4 20:21:38.608: %PQII_PRO_FE-3-TXERR: Ethernet0: Fatal transmit error. Restarting...
001048: *May 4 20:21:41.608: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state to up
001049: *May 4 20:21:46.456: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0, changed state to down

show controllers vdSL 8
Controller VDSL 8 is UP

Modem Status: SHOWTIME

FTU-R (DS) FTU-O (US)
G.994.1 vendor ID: 0xB5004D5449418811 0xB5004244434DB1C2
G.994.1 country code: 0xB500 0xB500
G.994.1 provider code: MTIA BDCM
G.994.1 vendor info: 0x8811 0xB1C2

System vendor ID: 0xB5004353434F0000 0xB5004244434D0000
System country code: 0xB500 0xB500
G.994.1 provider code: CSCO BDCM
G.994.1 vendor info: 0x0000 0x0000

NT Version number: 8811r038 MT5321
NT Version number(octet): 0x3838313172303338204D543533323120
DPU Version number: v11.03.66 ^@
DPU Version number(octet):0x7631312E30332E363620202020202000

NT vendor serial number: FCZ1818931Q C897VA-K 15.5(3)M8^@^@
NT vendor serial number(octet): 0x46435A3138313839333151204338393756412D4B2031352E352833294D380000
DPU vendor serial number: eq nr port:02 oemid softwarerev
DPU vendor serial number(octet): 0x6571206E7220706F72743A303220206F656D696420736F667477617265726576

NDR: 229328 kbits/s 77247 kbits/s
ATTNDR: 230865 kbits/s 61176 kbits/s
ATTETR: 177876 kbits/s 0 kbits/s

Danke vielmals im Voraus

netztier

Hallo Rayman

Dein Log zeigt Events des Ethernet0. Ist das wirklich das Interface, zu welchem dein SFP gehört?

Ich hab grad keinen 897 zur Hand... aber müsste das SFP-Interface des controller vdsl 8 nicht als _Gigabit_Ethernet 8 auftauchen?

Kann es sein, dass du deine Instabilität gar nicht auf dem WAN/DSL-Seite hast, sondern auf der LAN-Seite? Was ist denn ein Ethernet0 und was hängt dort dran?

Hier nochmal deine Werte (bisschen umformatiert)

show controllers vdSL 8
Controller VDSL 8 is UP

Modem Status:            SHOWTIME

                          FTU-R (DS)             FTU-O (US)
G.994.1 vendor ID:        0xB5004D5449418811     0xB5004244434DB1C2
G.994.1 country code:     0xB500                 0xB500
G.994.1 provider code:    MTIA                   BDCM
G.994.1 vendor info:      0x8811                 0xB1C2

System vendor ID:         0xB5004353434F0000     0xB5004244434D0000
System country code:      0xB500                 0xB500
G.994.1 provider code:    CSCO                   BDCM
G.994.1 vendor info:      0x0000                 0x0000

NT Version number:        8811r038 MT5321
NT Version number(octet): 0x3838313172303338204D543533323120
DPU Version number:       v11.03.66 ^@
DPU Version number(octet):0x7631312E30332E363620202020202000

NT vendor serial number:   FCZ1818931Q C897VA-K 15.5(3)M8^@^@
NT vendor serial number(octet): 0x46435A3138313839333151204338393756412D4B2031352E352833294D380000
DPU vendor serial number:  eq nr port:02 oemid softwarerev
DPU vendor serial number(octet): 0x6571206E7220706F72743A303220206F656D696420736F667477617265726576

NDR:                       229328 kbits/s       77247 kbits/s
ATTNDR:                    230865 kbits/s       61176 kbits/s
ATTETR:                    177876 kbits/s       0 kbits/s

Zum Vergleich meine hier:

DSLBridge#show controllers vdSL 8
Controller VDSL 8 is UP

Modem Status:           SHOWTIME

                          FTU-R (DS)                     FTU-O (US)
G.994.1 vendor ID:        0xB5004D5449418811               0xB5004244434DB1C2
  G.994.1 country code:   0xB500                           0xB500
  G.994.1 provider code:  MTIA                             BDCM
  G.994.1 vendor info:    0x8811                           0xB1C2

System vendor ID:         0xB5004353434F0000               0xB5004244434D0000
  System country code:    0xB500                           0xB500
  G.994.1 provider code:  CSCO                             BDCM
  G.994.1 vendor info:    0x0000                           0x0000

NT Version number:        8811r038 MT5321
NT Version number(octet): 0x3838313172303338204D543533323120
DPU Version number:       v11.03.66      ^@
DPU Version number(octet):0x7631312E30332E363620202020202000

NT vendor serial number:              C892FSP- 15.9(3)M^@^@^@
NT vendor serial number(octet): 0x202020202020202020202020433839324653502D2031352E392833294D000000
DPU vendor serial number: eq nr port:02  oemid softwarerev
DPU vendor serial number(octet): 0x6571206E7220706F72743A303220206F656D696420736F667477617265726576

NDR:                      452166 kbits/s                   128225 kbits/s
ATTNDR:                   455038 kbits/s                   116857 kbits/s
ATTETR:                   408223 kbits/s                   0 kbits/s

Und ein "Down/Up" liest sich dann so im Log:

Feb 4 11:48:29.725 CET: %CONTROLLER-5-UPDOWN: Controller VDSL 8, changed state to down
Feb 4 11:48:30.725 CET: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet8, changed state to down
Feb 4 11:53:24.248 CET: %LINK-3-UPDOWN: Interface GigabitEthernet8, changed state to up
Feb 4 11:53:25.248 CET: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet8, changed state to up
Feb 4 11:53:33.656 CET: %CONTROLLER-5-UPDOWN: Controller VDSL 8, changed state to up

Zeig doch mal noch ein show interface des Ethernet Interface, welches zu deinem G.fast-SFP-Modem gehört, und achte auf die lost carrier" - bei mir waren es (bisher) 8.

GigabitEthernet8 is up, line protocol is up
  Hardware is PQ3_TSEC, address is f4cf.e2a9.6b0d (bia f4cf.e2a9.6b0d)
  Description: * xDSL Line *
  MTU 1500 bytes, BW 128225 Kbit/sec, DLY 700 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full Duplex, 1Gbps, media type is MT
  output flow-control is XON, input flow-control is XON
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 6883
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  30 second input rate 546000 bits/sec, 49 packets/sec
  30 second output rate 23000 bits/sec, 24 packets/sec
     1625695225 packets input, 2141966779668 bytes, 0 no buffer
     Received 456339308 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 0 multicast, 10872518 pause input
     554572848 packets output, 91588664594 bytes, 0 underruns
     0 output errors, 0 collisions, 6 interface resets
     0 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     8 lost carrier, 0 no carrier, 0 pause output
     0 output buffer failures, 0 output buffers swapped out

« Pagina precedente