Natives Dual Stack in Baden-Württemberg?

In vielen Netzen von Unitymedia sind Internet und Telefonie bereits verfügbar.
Forumsregeln
  • Kunden aus Hessen und Nordrhein-Westfalen können über die Rufnummer 0221 / 466 191 00 Hilfe bei allen Problemen in Anspruch nehmen.
  • Kunden aus Baden-Württemberg können über die Rufnummer 0711 / 54 888 150 Hilfe bei allen Problemen in Anspruch nehmen.
Mr.Goodcat
Kabelneuling
Beiträge: 44
Registriert: 10.11.2015, 13:34

Re: Natives Dual Stack in Baden-Württemberg?

Beitrag von Mr.Goodcat » 13.05.2018, 15:25

tq1199 hat geschrieben:
13.05.2018, 15:16
Wenn man den traceroute _direkt_ auf dem Gerät mit pFSense macht, wird die LAN-IP-Adresse der pFSense nicht angezeigt. D. h. der 1. hop ist schon eine IP-Adresse von außerhalb. OK, ist bei deinem Bekannten aber nicht so gemacht worden.
Das in viewtopic.php?f=53&t=36865&p=403652#p403634 gepostete ist von einem Rechner hinter der Firewall gemacht worden - und das sind Hop 1 und 2 definitiv LAN bzw. RFC1918.

Bei viewtopic.php?f=53&t=36865&start=375#p403616 sagte er es wäre von der PFSense aus gemessen worden. Allerdings stimme ich zu, dass von dort PFSense selbst nicht als Hop auftauchen dürfte. Ich habe nochmal angefragt wie das nun gemessen wurde.

addicted
Kabelkopfstation
Beiträge: 4103
Registriert: 15.03.2010, 02:35

Re: Natives Dual Stack in Baden-Württemberg?

Beitrag von addicted » 13.05.2018, 15:37

tq1199 hat geschrieben:
13.05.2018, 14:41
Und mit einem Linux auf dem border device, geht das auch:
Ja klar geht das. Aber halt auch mit dem normalen traceroute, mtr braucht man nicht dafür.

Ich bin allerdings dafür, RFC1918-Space nicht auf dem WAN-Interface zu akzeptieren. Da machen die meisten Home-Router mal zur Abwechslung etwas richtig.

tq1199
Glasfaserstrecke
Beiträge: 2042
Registriert: 07.02.2014, 09:05

Re: Natives Dual Stack in Baden-Württemberg?

Beitrag von tq1199 » 13.05.2018, 16:22

addicted hat geschrieben:
13.05.2018, 15:37
Ja klar geht das. Aber halt auch mit dem normalen traceroute, mtr braucht man nicht dafür.
Ich sehe hier aber keinen wesentlichen Unterschied, in den Informationen die mtr im Vergleich zu traceroute (und umgekehrt) liefert:

Code: Alles auswählen

:~ $ traceroute -4 -n -q 2 -w 4 -z 1 -F 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  37.##.##.1  10.387 ms  16.150 ms
 2  172.30.10.117  9.801 ms  10.084 ms
 3  84.116.190.90  15.843 ms  13.687 ms
 4  84.116.190.129  15.667 ms  14.017 ms
 5  84.116.140.201  15.463 ms  14.090 ms
 6  84.116.132.178  13.077 ms  15.155 ms
 7  195.219.50.106  13.764 ms  11.348 ms
 8  195.219.50.174  12.695 ms  12.534 ms
 9  195.219.148.122  12.848 ms  14.562 ms
10  1.1.1.1  14.460 ms  14.367 ms
Eigentlich ist es egal, was man verwendet.
Office Internet & Phone 50, AVM FRITZ!Box 6360 Cable (kbw) - FRITZ!OS 06.52 - , an Arris-CMTS, zusätzlich eine feste statische IPv4-Adresse für meinen Server, am Bridge-Anschluss (FB6360-cable wird ohne feste IPv4-Adresse als Router verwendet.)
Konfig-Datei der FB: b2b-staticip1_50000_5000_ipv4_sip_wifi-on.bin
Speedtest: Hosted by bc-networks (Remseck) [13.51 km]: 28.612 ms, DL: 53.41 Mbit/s; UL: 4.73 Mbit/s
Ping vom border device zum default gateway = i. M. 10.448 ms

rv112
Glasfaserstrecke
Beiträge: 2013
Registriert: 28.10.2014, 07:18

Re: Natives Dual Stack in Baden-Württemberg?

Beitrag von rv112 » 13.05.2018, 18:09

Hier mal von mir aus:

Code: Alles auswählen

Routenverfolgung zu 1dot1dot1dot1.cloudflare-dns.com [1.1.1.1]
über maximal 30 Hops:

  1     6 ms     8 ms     7 ms  HSI-KBW-37-49-100-1.hsi14.kabel-badenwuerttemberg.de [37.49.100.1]
  2     8 ms     6 ms     7 ms  172.30.22.41
  3    20 ms     8 ms     8 ms  de-fra04a-rc1-ae60-0.aorta.net [84.116.191.29]
  4     9 ms     9 ms    11 ms  de-fra03b-ri1-ae5-0.aorta.net [84.116.133.118]
  5     8 ms     9 ms     9 ms  ix-ae-27-0.tcore1.fr0-frankfurt.as6453.net [195.219.50.106]
  6    13 ms    11 ms    11 ms  if-ae-6-2.thar1.f2c-frankfurt.as6453.net [195.219.50.174]
  7    11 ms     8 ms     9 ms  195.219.148.122
  8     8 ms     8 ms     9 ms  1dot1dot1dot1.cloudflare-dns.com [1.1.1.1]
KabelBW Internet seit 2003

Bild
- 2 Play FLY 400 DS / VDSL 50 DS
- Technicolor TC4400 / DrayTek Vigor130
- pfSense 2.4
- Cisco SPA112

Conan179
Übergeordneter Verstärkerpunkt
Beiträge: 862
Registriert: 25.01.2015, 22:38

Re: Natives Dual Stack in Baden-Württemberg?

Beitrag von Conan179 » 13.05.2018, 18:15

Routenverfolgung zu 1dot1dot1dot1.cloudflare-dns.com [1.1.1.1]
über maximal 30 Hops:

1 2 ms 3 ms 2 ms *** [192.168.1.****]
2 3 ms 20 ms 11 ms HSI-KBW-078-042-032-001.hsi3.kabel-badenwuerttemberg.de [78.42.32.1]
3 14 ms 13 ms 30 ms HSI-KBW-078-042-032-001.hsi3.kabel-badenwuerttemberg.de [78.42.32.1]
4 19 ms 16 ms 14 ms 172.30.22.33
5 28 ms 30 ms 28 ms de-fra04a-rc1-ae60-0.aorta.net [84.116.191.29]
6 16 ms 18 ms 26 ms de-fra03b-ri1-ae5-0.aorta.net [84.116.133.118]
7 23 ms 15 ms 21 ms ix-ae-27-0.tcore1.fr0-frankfurt.as6453.net [195.219.50.106]
8 23 ms 20 ms 15 ms 195.219.148.122
9 17 ms 22 ms 12 ms 1dot1dot1dot1.cloudflare-dns.com [1.1.1.1]
BildBildBild
cust-own_400000_40000_ds_sip_wifi-on.bin

Wechseler
Übergeordneter Verstärkerpunkt
Beiträge: 558
Registriert: 06.02.2018, 03:54

Re: Natives Dual Stack in Baden-Württemberg?

Beitrag von Wechseler » 13.05.2018, 18:31

addicted hat geschrieben:
13.05.2018, 15:37
Ich bin allerdings dafür, RFC1918-Space nicht auf dem WAN-Interface zu akzeptieren. Da machen die meisten Home-Router mal zur Abwechslung etwas richtig.
Machen sie nicht, Numerierungspläne können sich immer mal ändern und pauschales Filtern von bspw. 5.0.0.0/8 (ehemals IANA-RESERVED) führt dann immer und überall zu Problemen.

Dumme CPEs sollten alle zum Default-Router rausschieben, was sie selbst nicht kennen. Der ISP filtert dann weg, was nicht ins Internet gehört. Natürlich kann man selbst Filterregeln anlegen, aber einfach pauschal ohne Eingriffsmöglichkeit alles wegzuwerfen wie die Fritte sollte nicht passieren.
Bild
Hardware: Technicolor TC4400 (derzeit außer Betrieb) / Zyxel Speedlink 5501 | Linksys WRT1200AC (OpenWrt 18.06.1) | Gigaset C430 IP | Cisco SPA112

rv112
Glasfaserstrecke
Beiträge: 2013
Registriert: 28.10.2014, 07:18

Re: Natives Dual Stack in Baden-Württemberg?

Beitrag von rv112 » 13.05.2018, 18:33

Wieso dumme CPE? Die pfSense routet auch ans Standardgateway was sie nicht kennt und das ist auch gut so.
KabelBW Internet seit 2003

Bild
- 2 Play FLY 400 DS / VDSL 50 DS
- Technicolor TC4400 / DrayTek Vigor130
- pfSense 2.4
- Cisco SPA112

Benutzeravatar
Andreas1969
Carrier
Beiträge: 11240
Registriert: 05.03.2015, 07:50
Wohnort: Unitymedia NRW

Re: Natives Dual Stack in Baden-Württemberg?

Beitrag von Andreas1969 » 13.05.2018, 21:55

Andreas1969 hat geschrieben:
12.05.2018, 05:01
why_ hat geschrieben:
12.05.2018, 01:46
Ich glaube das ist eher Placebo bei dir. Poste doch mal ne traceroute zu speed.myloc.de Das sollte bei dir Paderborn -> Kerpen -> Düsseldorf laufen und somit von der Latenz sehr niedrig sein.
1 <1 ms <1 ms <1 ms fritz.box [192.168.2.1]
2 10 ms 57 ms 37 ms ip-109-91-202-1.hsi12.unitymediagroup.de [109.91.202.1]
3 15 ms 22 ms 18 ms 172.23.160.224
4 14 ms 18 ms 14 ms de-bfe01c-rd02-ae0-0.aorta.net [84.116.196.194]
5 22 ms 14 ms 18 ms de-fra01b-rc1-ae17-0.aorta.net [84.116.197.198]
6 20 ms 13 ms 13 ms de-fra04c-ri1-ae5-0.aorta.net [84.116.133.113]
7 20 ms 19 ms 14 ms 172.30.64.214
8 14 ms 16 ms 17 ms 172.30.64.213
9 21 ms 18 ms 21 ms de-fra04c-ri1-ae15-101.aorta.net [84.116.191.6]
10 25 ms 18 ms 23 ms de-fra01b-rc1-ae5-0.aorta.net [84.116.133.114]
11 24 ms 44 ms 20 ms de-dus23e-rc1-ae21-0.aorta.net [84.116.138.201]
12 18 ms 19 ms 23 ms 84.116.191.118
13 19 ms 18 ms 23 ms b2b-5-147-248-82.unitymedia.biz [5.147.248.82]
14 24 ms 17 ms 19 ms speed.myloc.de [62.141.47.66]
So, hab jetzt ne andere IP aus 178.203.x.y
im Prinzip hat sich nichts verändert, Routing ist genau so beschissen, Ping hat sich nicht verbessert, UL macht auch noch Probleme

1 <1 ms <1 ms <1 ms fritz.box [192.168.2.1]
2 69 ms 13 ms 12 ms ip-178-203-240-1.hsi10.unitymediagroup.de [178.203.240.1]
3 20 ms 19 ms 20 ms 172.23.160.224
4 21 ms 18 ms 17 ms de-bfe01c-rd02-ae0-0.aorta.net [84.116.196.194]
5 18 ms 19 ms 17 ms de-fra01b-rc1-ae17-0.aorta.net [84.116.197.198]
6 21 ms 19 ms 17 ms de-fra04c-ri1-ae5-0.aorta.net [84.116.133.113]
7 16 ms 17 ms 19 ms 172.30.64.214
8 21 ms 15 ms 14 ms 172.30.64.213
9 23 ms 20 ms 19 ms de-fra04c-ri1-ae15-101.aorta.net [84.116.191.6]
10 21 ms 25 ms 22 ms de-fra01b-rc1-ae5-0.aorta.net [84.116.133.114]
11 28 ms 37 ms 39 ms de-dus23e-rc1-ae21-0.aorta.net [84.116.138.201]
12 20 ms 17 ms 18 ms 84.116.191.118
13 61 ms 22 ms 19 ms b2b-5-147-248-82.unitymedia.biz [5.147.248.82]
14 44 ms 21 ms 17 ms speed.myloc.de [62.141.47.66]
Denken gehört zu den schwersten Dingen, die man tun kann. Vielleicht ist das der Grund, warum es so Wenige tun. :kratz:
Bild
Alle sagten: Es geht nicht. Da kam einer, der das nicht wusste und tat es einfach. :D

Conan179
Übergeordneter Verstärkerpunkt
Beiträge: 862
Registriert: 25.01.2015, 22:38

Re: Natives Dual Stack in Baden-Württemberg?

Beitrag von Conan179 » 13.05.2018, 22:00

Hmmm

Routenverfolgung zu ip-178-203-240-1.hsi10.unitymediagroup.de [178.203.240.1]
über maximal 30 Hops:

1 3 ms 2 ms 2 ms ***
2 3 ms 20 ms 34 ms HSI-KBW-078-042-032-001.hsi3.kabel-badenwuerttemberg.de [78.42.32.1]
3 12 ms 13 ms 33 ms 172.30.22.33
4 26 ms 17 ms 16 ms 172.30.22.33
5 22 ms 24 ms 22 ms de-fra04a-rc1-ae60-0.aorta.net [84.116.191.29]
6 26 ms 19 ms 21 ms de-fra01b-rc1-ae15-0.aorta.net [84.116.133.102]
7 23 ms 18 ms 25 ms de-bfe01c-rd02-ae2-0.aorta.net [84.116.197.197]
8 29 ms 20 ms 27 ms de-bfe01c-rd01-ae0-0.aorta.net [84.116.196.193]
9 26 ms 26 ms 37 ms ip-178-203-240-1.hsi10.unitymediagroup.de [178.203.240.1]

über maximal 30 Hops:

1 3 ms 2 ms 2 ms ***
2 4 ms 14 ms 12 ms HSI-KBW-078-042-032-001.hsi3.kabel-badenwuerttemberg.de [78.42.32.1]
3 11 ms 13 ms 14 ms 172.30.22.33
4 13 ms 20 ms 28 ms de-fra04a-rc1-ae60-0.aorta.net [84.116.191.29]
5 19 ms 21 ms 19 ms de-fra01b-rc1-ae15-0.aorta.net [84.116.133.102]
6 27 ms 25 ms 20 ms de-dus23e-rc1-ae21-0.aorta.net [84.116.138.201]
7 24 ms 20 ms 19 ms de-dus23e-rc1-ae21-0.aorta.net [84.116.138.201]
8 20 ms 22 ms 21 ms 84.116.191.118
9 71 ms 20 ms 21 ms b2b-5-147-248-82.unitymedia.biz [5.147.248.82]
10 31 ms 35 ms 19 ms speed.myloc.de [62.141.47.66]

Ablaufverfolgung beendet.
BildBildBild
cust-own_400000_40000_ds_sip_wifi-on.bin

Edding
Übergeordneter Verstärkerpunkt
Beiträge: 655
Registriert: 13.12.2009, 23:22

Re: Natives Dual Stack in Baden-Württemberg?

Beitrag von Edding » 13.05.2018, 22:04

Andreas1969 hat geschrieben:
13.05.2018, 21:55
1 <1 ms <1 ms <1 ms fritz.box [192.168.2.1]
2 69 ms 13 ms 12 ms ip-178-203-240-1.hsi10.unitymediagroup.de [178.203.240.1]
3 20 ms 19 ms 20 ms 172.23.160.224
4 21 ms 18 ms 17 ms de-bfe01c-rd02-ae0-0.aorta.net [84.116.196.194]
5 18 ms 19 ms 17 ms de-fra01b-rc1-ae17-0.aorta.net [84.116.197.198]
6 21 ms 19 ms 17 ms de-fra04c-ri1-ae5-0.aorta.net [84.116.133.113]
7 16 ms 17 ms 19 ms 172.30.64.214
8 21 ms 15 ms 14 ms 172.30.64.213
9 23 ms 20 ms 19 ms de-fra04c-ri1-ae15-101.aorta.net [84.116.191.6]
10 21 ms 25 ms 22 ms de-fra01b-rc1-ae5-0.aorta.net [84.116.133.114]
11 28 ms 37 ms 39 ms de-dus23e-rc1-ae21-0.aorta.net [84.116.138.201]
12 20 ms 17 ms 18 ms 84.116.191.118
13 61 ms 22 ms 19 ms b2b-5-147-248-82.unitymedia.biz [5.147.248.82]
14 44 ms 21 ms 17 ms speed.myloc.de [62.141.47.66]

hmm was auffält ist das du ziemlich viele Hops in FFM drinne hast das ungewöhnlich
und mit 172.30.0.0/16 wohl noch ein Bogon prefix drin.
Bild
Meine Bitcoin-Adresse: 1BPVf25GT7WWpBAhuv5m4hAR9Q63kaR78i
Meine Ether-Adresse: 0xf841b13449a3db0D4C2EFa2FFAFDAB537308A5C0

rv112
Glasfaserstrecke
Beiträge: 2013
Registriert: 28.10.2014, 07:18

Re: Natives Dual Stack in Baden-Württemberg?

Beitrag von rv112 » 13.05.2018, 22:07

Das stimmt, er wird noch mal zur 172. IP geroutet und dann wieder nach FFM. Aber dennoch, daran liegt es nicht. Wenn der erste Hop im Schnitt schon 20ms hat, kann es dahinter nicht besser werden. Ich tippe in seinem Fall auch aufs CMTS. Vielleicht mal eine Störung über zu hohen Ping melden bzw. mit dem Chat darüber diskutieren. Ja, das ist Jammern auf hohem Niveau, aber mich würde das auch fuchsen.

@Edding

RFC1918, nicht Bogon ;)
KabelBW Internet seit 2003

Bild
- 2 Play FLY 400 DS / VDSL 50 DS
- Technicolor TC4400 / DrayTek Vigor130
- pfSense 2.4
- Cisco SPA112

Benutzeravatar
Andreas1969
Carrier
Beiträge: 11240
Registriert: 05.03.2015, 07:50
Wohnort: Unitymedia NRW

Re: Natives Dual Stack in Baden-Württemberg?

Beitrag von Andreas1969 » 13.05.2018, 22:14

rv112 hat geschrieben:
13.05.2018, 22:07
Wenn der erste Hop im Schnitt schon 20ms hat, kann es dahinter nicht besser werden. Ich tippe in seinem Fall auch aufs CMTS.
Ja, ist dieser schei.... Casa
Vorher beim Arris hatte ich da gute 8-9 ms
rv112 hat geschrieben:
13.05.2018, 22:07
Vielleicht mal eine Störung über zu hohen Ping melden
Bringt nichts, laut UM ist das noch im Rahmen.
Es nervt einfach, weil es ja vorher mal lief und weil der UL nicht vernünftig hoch kommt.
Denken gehört zu den schwersten Dingen, die man tun kann. Vielleicht ist das der Grund, warum es so Wenige tun. :kratz:
Bild
Alle sagten: Es geht nicht. Da kam einer, der das nicht wusste und tat es einfach. :D

rv112
Glasfaserstrecke
Beiträge: 2013
Registriert: 28.10.2014, 07:18

Re: Natives Dual Stack in Baden-Württemberg?

Beitrag von rv112 » 13.05.2018, 22:15

Der UL muss aber ein anderes Problem sein, also doch mal ein Ticket erstellen und mit dem Techniker über Dein Ping Problem sprechen ;)
KabelBW Internet seit 2003

Bild
- 2 Play FLY 400 DS / VDSL 50 DS
- Technicolor TC4400 / DrayTek Vigor130
- pfSense 2.4
- Cisco SPA112

Benutzeravatar
Andreas1969
Carrier
Beiträge: 11240
Registriert: 05.03.2015, 07:50
Wohnort: Unitymedia NRW

Re: Natives Dual Stack in Baden-Württemberg?

Beitrag von Andreas1969 » 13.05.2018, 22:22

rv112 hat geschrieben:
13.05.2018, 22:15
Der UL muss aber ein anderes Problem sein, also doch mal ein Ticket erstellen und mit dem Techniker über Dein Ping Problem sprechen ;)
Ich lass jetzt alles so, wie es ist.
Ende Juli hab ich hier einen Vectoring Anschluss.
Dann ziehe ich meinen persönlichen Vergleich.
Der bessere gewinnt das Rennen, der schlechter wird dann irgendwann gekündigt.
Denken gehört zu den schwersten Dingen, die man tun kann. Vielleicht ist das der Grund, warum es so Wenige tun. :kratz:
Bild
Alle sagten: Es geht nicht. Da kam einer, der das nicht wusste und tat es einfach. :D

rv112
Glasfaserstrecke
Beiträge: 2013
Registriert: 28.10.2014, 07:18

Re: Natives Dual Stack in Baden-Württemberg?

Beitrag von rv112 » 13.05.2018, 22:27

Dann mal hier ein Vorgeschmack. Der Ping ist zwar höher (kein Fastpath) aber dafür deutlich stabiler:

UM:
Bild

Telekom:
Bild
KabelBW Internet seit 2003

Bild
- 2 Play FLY 400 DS / VDSL 50 DS
- Technicolor TC4400 / DrayTek Vigor130
- pfSense 2.4
- Cisco SPA112

addicted
Kabelkopfstation
Beiträge: 4103
Registriert: 15.03.2010, 02:35

Re: Natives Dual Stack in Baden-Württemberg?

Beitrag von addicted » 13.05.2018, 22:30

Wechseler hat geschrieben:
13.05.2018, 18:31
addicted hat geschrieben:
13.05.2018, 15:37
Ich bin allerdings dafür, RFC1918-Space nicht auf dem WAN-Interface zu akzeptieren. Da machen die meisten Home-Router mal zur Abwechslung etwas richtig.
Machen sie nicht, Numerierungspläne können sich immer mal ändern
Du erwartest eine Änderung am RFC1918-Space?
Das finde ich... gewagt. IPv4 ist ein Legacy-Protokoll.
Wechseler hat geschrieben:
13.05.2018, 18:31
und pauschales Filtern von bspw. 5.0.0.0/8 (ehemals IANA-RESERVED) führt dann immer und überall zu Problemen.
5/8 ist nicht Teil von RFC1918.

Wechseler
Übergeordneter Verstärkerpunkt
Beiträge: 558
Registriert: 06.02.2018, 03:54

Re: Natives Dual Stack in Baden-Württemberg?

Beitrag von Wechseler » 14.05.2018, 01:38

addicted hat geschrieben:
13.05.2018, 22:30
Du erwartest eine Änderung am RFC1918-Space?
Das finde ich... gewagt. IPv4 ist ein Legacy-Protokoll.
IPv4-Adressen sind immer noch knapp. Da wird sich noch einiges ändern.
Wechseler hat geschrieben:
13.05.2018, 18:31
und pauschales Filtern von bspw. 5.0.0.0/8 (ehemals IANA-RESERVED) führt dann immer und überall zu Problemen.
5/8 ist nicht Teil von RFC1918.
Und war trotzdem in diversen Default-Filtern drin. Und dann kam es zum Assignment und plötzlich gab's Ärger.
Bild
Hardware: Technicolor TC4400 (derzeit außer Betrieb) / Zyxel Speedlink 5501 | Linksys WRT1200AC (OpenWrt 18.06.1) | Gigaset C430 IP | Cisco SPA112

Benutzeravatar
Andreas1969
Carrier
Beiträge: 11240
Registriert: 05.03.2015, 07:50
Wohnort: Unitymedia NRW

Re: Natives Dual Stack in Baden-Württemberg?

Beitrag von Andreas1969 » 14.05.2018, 06:11

rv112 hat geschrieben:
13.05.2018, 22:07
Das stimmt, er wird noch mal zur 172. IP geroutet und dann wieder nach FFM. Aber dennoch, daran liegt es nicht. Wenn der erste Hop im Schnitt schon 20ms hat, kann es dahinter nicht besser werden.
Ich nehme jetzt mal folgendes daraus mit:

- Das Routing (gut oder schlecht) ist einzig von der IP, bzw. der Anbindung des CMTS abhängig, egal, welche IP man als Kunde zugewiesen bekommt.
- Der Ping (gut oder schlecht) ist von der Qualität des CMTS abhängig (Intel oder alternativer Chipsatz), und wenn die HFC-Werte noch so gut sind und im Segment kaum was los.

Wenn beide Dinge zusammentreffen (schlechte IP des CMTS, bzw. mieses Routing und hoher Ping aufgrund mieser HW des CMTS) hat man halt gewisse Qualitätseinbußen, die man als Kunde selbst nicht beeinflussen kann.

Abschließend kann man noch sagen, daß ein CMTS von Casa Systems (neuere Bauart) den Ping gegenüber einem Arris oder Casa Systems (älterer Bauart) um 10+ ms erhöht.
Ich vermute mal, das Casa Systems den Chipsatz bei neueren Varianten von Broadcom oder ähnlich auf Intel (Puma Plattform) gewechselt hat und es somit zu dem höheren Ping kommt.
Es gibt ja auch Leute, die trotz Casa System CMTS keinen erhöhten Ping haben (vermutlich eine ältere Baureihe).

Edit: Und wenn man an so einem Anschluss dann eine Puma Box (Fritzbox FW 6.50 oder eine ConnectBox) betreibt, wird's richtig böse. :nein:
Denken gehört zu den schwersten Dingen, die man tun kann. Vielleicht ist das der Grund, warum es so Wenige tun. :kratz:
Bild
Alle sagten: Es geht nicht. Da kam einer, der das nicht wusste und tat es einfach. :D

sch4kal
Übergeordneter Verstärkerpunkt
Beiträge: 504
Registriert: 15.02.2018, 12:15

Re: Natives Dual Stack in Baden-Württemberg?

Beitrag von sch4kal » 14.05.2018, 07:34

rv112 hat geschrieben:
13.05.2018, 18:33
Wieso dumme CPE? Die pfSense routet auch ans Standardgateway was sie nicht kennt und das ist auch gut so.
Das sollten eigentlich alle IP-Router machen ^^ Was Sie nicht kennen (0.0.0.0 / default) -> Standard-Gateway A.B.C.D.
Bei der pfSense im Speziellen kannst ja sogar die RFC1918 am WAN explizit verbieten, was eben Fritten ungefragt machen, man jedoch auch nicht beeinflussen kann.
Genau dieses Verhalten ist, wie Wechseler schon geschrieben hat, höchst bedenklich, gerade WEIL es so wenig unassigned IPv4-Blöcke gibt und evtl. manche 1918-Adressblöcke vielleicht doch noch zugewiesen werden.
Da bist du dann, insbesondere bei älteren CPEs, die den Traffic nach "/dev/null routen", auf die Laune deines Routerherstellers angewiesen, auch noch für ältere Geräte Updates anzubieten.
Bild
VF Red Internet & Phone Business 200/50 | [email protected] | [email protected] | UAP AC-Pro | SPA112

rv112
Glasfaserstrecke
Beiträge: 2013
Registriert: 28.10.2014, 07:18

Re: Natives Dual Stack in Baden-Württemberg?

Beitrag von rv112 » 14.05.2018, 08:04

Naja, bei Consumerroutern ist man doch eh den Entwicklern ausgeliefert.
KabelBW Internet seit 2003

Bild
- 2 Play FLY 400 DS / VDSL 50 DS
- Technicolor TC4400 / DrayTek Vigor130
- pfSense 2.4
- Cisco SPA112

addicted
Kabelkopfstation
Beiträge: 4103
Registriert: 15.03.2010, 02:35

Re: Natives Dual Stack in Baden-Württemberg?

Beitrag von addicted » 14.05.2018, 08:37

Ich weiß nicht, was Ihr so raucht, aber es ist extrem unwahrscheinlich, das RFC1918-Blöcke jemals eine andere Verwendung finden werden.
An der Nutzung dieser Adressblöcke hängt soviel anderes dran. Es gibt unzählige Protokolle, die auf RFC1918 verweisen. Die Adressen befinden sich überall im Einsatz. Der Schaden des Renumbering wäre immens.
Zudem würde niemand die Adressen nutzen wollen, eben weil sie überall intern belegt sind und daher die Hosts mit diesen Adressen sowieso von niemandem erreichbar wären.

Es gibt einen deutlichen Unterschied zwischen RFC1918 und dem sonstigen Reserved Space: RFC1918 regelt klar, dass diese Adressen nicht zwischen verschiedenen Entitäten ausgetauscht werden sollen:
Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links. Routers in networks not using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information about private networks.
Reserved Space ist halt Reserved. Das heißt lediglich, dass dafür zum aktuellen Zeitpunkt niemand ein Nutzungsrecht hat, dort kann es sich aber in der Tat ändern.
Reserved sollte man als ISP auch filtern, weil das Abuse-Potential sehr hoch ist. Das wird heute zum Glück auch fast überall so gemacht (man prüft halt darauf, ob der Peering-Partner/Downlink berechtigt ist, eine bestimmte Route zu announcen).

Reserved kann sich durchaus ändern. ISPs aktualisieren Ihre Filter aber, also kein Problem.
Bei CPEs gibt es natürlich keine Updates, weshalb es auch gut ist, dass dort ausser RFC1918 nicht gefiltert wird.

Ihr könnt meinetwegen RFC1918 an Eurem Border ungefiltert lassen. Müsst Ihr ja selbst wissen, ob Ihr bei einem Tippfehler in der IP-Adresse direkt die Pakete an Euren ISP übergeben wollt, egal was drinsteht. Ich würd's nicht empfehlen.
Bei einigen Hostern/RZ-Betreibern wird Euer Port stillgelegt, wenn Ihr da RFC1918 drauf liefert.

sch4kal
Übergeordneter Verstärkerpunkt
Beiträge: 504
Registriert: 15.02.2018, 12:15

Re: Natives Dual Stack in Baden-Württemberg?

Beitrag von sch4kal » 14.05.2018, 08:49

addicted hat geschrieben:
14.05.2018, 08:37
Ich weiß nicht, was Ihr so raucht, aber es ist extrem unwahrscheinlich, das RFC1918-Blöcke jemals eine andere Verwendung finden werden.
An der Nutzung dieser Adressblöcke hängt soviel anderes dran. Es gibt unzählige Protokolle, die auf RFC1918 verweisen. Die Adressen befinden sich überall im Einsatz. Der Schaden des Renumbering wäre immens.
Zudem würde niemand die Adressen nutzen wollen, eben weil sie überall intern belegt sind und daher die Hosts mit diesen Adressen sowieso von niemandem erreichbar wären.

Es gibt einen deutlichen Unterschied zwischen RFC1918 und dem sonstigen Reserved Space: RFC1918 regelt klar, dass diese Adressen nicht zwischen verschiedenen Entitäten ausgetauscht werden sollen:
Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links. Routers in networks not using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information about private networks.
Reserved Space ist halt Reserved. Das heißt lediglich, dass dafür zum aktuellen Zeitpunkt niemand ein Nutzungsrecht hat, dort kann es sich aber in der Tat ändern.
Reserved sollte man als ISP auch filtern, weil das Abuse-Potential sehr hoch ist. Das wird heute zum Glück auch fast überall so gemacht (man prüft halt darauf, ob der Peering-Partner/Downlink berechtigt ist, eine bestimmte Route zu announcen).

Reserved kann sich durchaus ändern. ISPs aktualisieren Ihre Filter aber, also kein Problem.
Bei CPEs gibt es natürlich keine Updates, weshalb es auch gut ist, dass dort ausser RFC1918 nicht gefiltert wird.

Ihr könnt meinetwegen RFC1918 an Eurem Border ungefiltert lassen. Müsst Ihr ja selbst wissen, ob Ihr bei einem Tippfehler in der IP-Adresse direkt die Pakete an Euren ISP übergeben wollt, egal was drinsteht. Ich würd's nicht empfehlen.
Bei einigen Hostern/RZ-Betreibern wird Euer Port stillgelegt, wenn Ihr da RFC1918 drauf liefert.
Ich würde es jedenfalls begrüßen, damits richtig schön kracht :smile: Vielleicht erfolgt dann ein Umdenken vieler SW-Entwickler, vielleicht doch vollen IPv6-Support einzubauen. Zur Not kommt bei Legacy-Software eben ein Portmapper/Tunnel davor und gut ist.
Bild
VF Red Internet & Phone Business 200/50 | [email protected] | [email protected] | UAP AC-Pro | SPA112

Leseratte10
Glasfaserstrecke
Beiträge: 1479
Registriert: 07.03.2013, 15:56

Re: Natives Dual Stack in Baden-Württemberg?

Beitrag von Leseratte10 » 14.05.2018, 11:26

Naja, krachen wird es bei den Leuten, die das Pech haben, Blöcke aus 10/8 oder sonstwo zugeteilt bekommen, weil kein Mensch die nutzen kann. Ungefähr so wie die Einführung von DS-Lite: Kaum einer kann drauf zugreifen, also will keiner DS-Lite. genauso würde es bei einer hypothetischen Freigabe von RFC1918-Adressen fürs öffentliche Routing passieren. Und wenn man eh einmal alle Router, Endgeräte, etc. im ganzen Internet anpassen muss um 10/8 durchzulassen, kann man auch direkt auf IPv6 umstellen.

Wechseler
Übergeordneter Verstärkerpunkt
Beiträge: 558
Registriert: 06.02.2018, 03:54

Re: Natives Dual Stack in Baden-Württemberg?

Beitrag von Wechseler » 14.05.2018, 13:26

sch4kal hat geschrieben:
14.05.2018, 07:34
Genau dieses Verhalten ist, wie Wechseler schon geschrieben hat, höchst bedenklich, gerade WEIL es so wenig unassigned IPv4-Blöcke gibt und evtl. manche 1918-Adressblöcke vielleicht doch noch zugewiesen werden.
Da bist du dann, insbesondere bei älteren CPEs, die den Traffic nach "/dev/null routen", auf die Laune deines Routerherstellers angewiesen, auch noch für ältere Geräte Updates anzubieten.
RFC 1918 auf der WAN-Seite ist durchaus üblich, wie man an diversen Kabel- und Mobilfunknetzen sieht.

Ich kann mir übrigens auch vorstellen, daß man später von 10/8 was abzwackt, 172.16/12 komplett verwendet und nur 192.168/16 übrigläßt. Und dann ist da noch 240/4, was man sich noch nicht anzufassen traut...

Solche Einschnitte gab es immer wieder mal, wie bei bei Einführung von CIDR mit variablen Präfixlängen. Rücksicht genommen wird nur auf sauber implementierte Endgeräte, die das dann nicht betrifft. Ein uralter Classful IP Stack kann auch heute noch artig seinen IPv4-Verkehr beim Default-Router abliefern und wird davon nicht viel merken.
Leseratte10 hat geschrieben:
14.05.2018, 11:26
Und wenn man eh einmal alle Router, Endgeräte, etc. im ganzen Internet anpassen muss um 10/8 durchzulassen, kann man auch direkt auf IPv6 umstellen.
Das ganze Internet wird das wenig jucken, auf den professionellen Routern werden dann wieder mal die Filter angepaßt und die ganzen EoL-Fritten wandern halt in den Müll. Wenn ich mir die Nachfrage nach Native DualStack allein hier im UM-Forum ansehen, dann sieht mir das nicht so aus, als sei IPv4 nächstes Jahr schon vorbei. :D
Bild
Hardware: Technicolor TC4400 (derzeit außer Betrieb) / Zyxel Speedlink 5501 | Linksys WRT1200AC (OpenWrt 18.06.1) | Gigaset C430 IP | Cisco SPA112

tq1199
Glasfaserstrecke
Beiträge: 2042
Registriert: 07.02.2014, 09:05

Re: Natives Dual Stack in Baden-Württemberg?

Beitrag von tq1199 » 15.05.2018, 08:24

Andreas1969 hat geschrieben:
14.05.2018, 06:11
- Das Routing (gut oder schlecht) ist einzig von der IP, bzw. der Anbindung des CMTS abhängig, egal, welche IP man als Kunde zugewiesen bekommt.
Das sieht so aus, als ob das Routing zu erst über das default gateway (109.91.202.1) und danach über das CMTS, geht.

Code: Alles auswählen

1 <1 ms <1 ms <1 ms fritz.box [192.168.2.1]

2 10 ms 57 ms 37 ms ip-109-91-202-1.hsi12.unitymediagroup.de [109.91.202.1]

3 15 ms 22 ms 18 ms 172.23.160.224
4 14 ms 18 ms 14 ms de-bfe01c-rd02-ae0-0.aorta.net [84.116.196.194]
5 22 ms 14 ms 18 ms de-fra01b-rc1-ae17-0.aorta.net [84.116.197.198]
6 20 ms 13 ms 13 ms de-fra04c-ri1-ae5-0.aorta.net [84.116.133.113]

7 20 ms 19 ms 14 ms 172.30.64.214
8 14 ms 16 ms 17 ms 172.30.64.213
...
...
Ist lt. Log der FritzBox, die IP-Adresse 109.91.202.1 das default gateway?
Office Internet & Phone 50, AVM FRITZ!Box 6360 Cable (kbw) - FRITZ!OS 06.52 - , an Arris-CMTS, zusätzlich eine feste statische IPv4-Adresse für meinen Server, am Bridge-Anschluss (FB6360-cable wird ohne feste IPv4-Adresse als Router verwendet.)
Konfig-Datei der FB: b2b-staticip1_50000_5000_ipv4_sip_wifi-on.bin
Speedtest: Hosted by bc-networks (Remseck) [13.51 km]: 28.612 ms, DL: 53.41 Mbit/s; UL: 4.73 Mbit/s
Ping vom border device zum default gateway = i. M. 10.448 ms

Antworten

Wer ist online?

Mitglieder in diesem Forum: rv112 und 11 Gäste