WinMTR - Telenet

[Emile51]

Wat denken jullie hiervan? Min of meer correct of niet?

[Splitter]

ziet er prima uit

[Stormlord]

@Splitter,

dus volgens u is 100% packetloss op de eerste 4 hops binnen telenet "normaal"?

I Think Not!

Een schending van RFC1122 als ze ICMP droppen - zelfs komt alles er prima door!!!

Ik heb ook dergelijke fenomenen, alleen: bij mij is het niet steeds (rond de) 100% - wat wijst op een onderliggend probleem met capaciteit (en is intussen ook bevestigd door de engineer die is langsgeweest: én een probleem met interferentie door een beschadigde kabel én een overbelaste node op piekmomenten van de dag).

@Emile51

zijn je down- en uploadsnelheden wat ze moeten zijn? (de mijne niet, in de verste verte zelfs niet ... 5-15% onder de beloofde snelheid kan nog als enigzins normaal worden beschouwd, maar veel meer niet).

Mvg,

David

[CCatalyst]

Een schending van RFC1122 als ze ICMP droppen - zelfs komt alles er prima door!!!

RFC's zijn niet verplicht na te leven (ttz, soms moet je ze uit praktische redenen natuurlijk wel naleven of je gaat problemen hebben, maar hier is dat niet het geval).

Ik denk persoonlijk ook niet dat het fraai is om ICMP Echo te blokkeren. Zeker niet als dit geconfigureerd wordt door mensen die zelf wel regelmatig ICMP Echo gebruiken om te troubleshooten. Maar helaas valt er niets te doen aan achterhaalde ideeën/overtuigingen inzake security, zoals security through obscurity.

[Splitter]

dus volgens u is 100% packetloss op de eerste 4 hops binnen telenet "normaal"?

jazeker, routers laten icmp verkeer als eerste droppen indien er hogere load is, en kunnen zelfs zo ingesteld worden dat ze het gewoon uberhaupt droppen.
dat wil zeker niet zeggen dat er iets mis is - enkel dat dat device niet op icmp reageert, of mogelijk hoge load ervaart.
zolang er geen packetloss is op het eind van de bestemming, of de packetloss niet oplopend is, is er in principe geen probleem.

of dat een schending is van de RFC's ga ik niet op in - dat doet namelijk niet ter zake dat het gewoon feitelijk voorvalt dat routers icmp droppen,
en ook effectief ingesteld kunnen worden op die manier.
en vaak is dat ook iets dat default zo zal zijn (of dat een goede zaak is, is een ander verhaal en discussie)

Ik heb ook dergelijke fenomenen, alleen: bij mij is het niet steeds (rond de) 100% - wat wijst op een onderliggend probleem met capaciteit

dat kan kloppen, again: icmp zal als eerste gedropt worden.
100% loss duidt echter op het feit dat dit gewoon by default gedropt is, en niet dat er (noodzakelijk) hogere load is.
de eindbestemming geeft ook duidelijk evenveel replies aan als de start, dus er is geen loss - alleen is een tussenliggende hop van mening dat icmp niet belangrijk is.

én een probleem met interferentie door een beschadigde kabel én een overbelaste node op piekmomenten van de dag).

telenet (coax) is wel gekend om problemen met piekmomenten te hebben, en als je een slechte kabel hebt is zowel op coax als dsl overspraak idd een mogelijkheid,
alsook verlies naar aarde etc.
maar dat zie je dan weer niet (noodzakelijk) uit een mtr

effect op de snelheid is hier trouwens niet gevraagd, maar als er idd iets is met de snelheid, zal er wat anders aan de hand zijn - maar dat toont de mtr dan weer niet.

[Emile51]

@Stormlord : snelheden d/u zijn OK.

[Stormlord]

@Splitter
Ik volg je redenering, maar die RFC bestaan om een reden - met name standaarden vast te leggen mbt. tot het TCP/IP protocol (in dit geval).
Als je deze standaarden niet volgt breek je dingen en zorg je ervoor dat sommige zaken niet naar behoren gaan werken.
M.a.w. als Telenet als een van de grootste internetproviders deze RFC niet volgt, is het niet 100% compatible met TCP/IP.
In mijn geval zijn de stats met WinMTR mogelijke indicator dat er daar wat misloopt, getuige ook de snelheden die bij mij NIET worden gehaald - alsook verschillende andere gebruikers op mijn node (alleen klagen zij mogelijk niet allemaal), Emile51 heeft dat probleem blijkbaar niet - gelukkig maar.

Bon, in elk geval: voor mij is het duidelijk - ik heb mijn overstap naar Orange aangevraagd na >20 jaar.
Jammer voor Telenet, maar als je klachten niet ernstig behandelt en steeds maar verder de prijs verhoogt krijg je dit.
Dat zal technisch niet veel veranderen aan de zaak tot ze effectief het probleem op mijn node oplossen, maar dan betaal ik tenminste daar gevoelig minder.

[permutatie]

RFC1812 heeft het volgende te zeggen over compliance:

Likewise, routers may provide, except where explicitly prohibited by
this memo, options which cause them to violate MUST or MUST NOT
requirements. A router that provides such options is compliant
(either fully or conditionally) if and only if each such option has a
default setting that causes the router to conform to the requirements
of this memo.

En dit over Time Exceeded:

A router MUST generate a Time Exceeded message Code 0 (In Transit)
when it discards a packet due to an expired TTL field. A router MAY
have a per-interface option to disable origination of these messages
on that interface, but that option MUST default to allowing the
messages to be originated.

De optie om Time Exceeded berichten uit te zetten is niet expliciet verboden, dus op basis van de traceroute je kan niet zomaar stellen dat de router niet compliant is.

[selder]

Hallow, na een cyber incident bij ons staat ICMP zelfs overal expliciet uit, 'een schending' hahah

[Sinna]

Bon, in elk geval: voor mij is het duidelijk - ik heb mijn overstap naar Orange aangevraagd na >20 jaar.
Jammer voor Telenet, maar als je klachten niet ernstig behandelt en steeds maar verder de prijs verhoogt krijg je dit.
Dat zal technisch niet veel veranderen aan de zaak tot ze effectief het probleem op mijn node oplossen, maar dan betaal ik tenminste daar gevoelig minder.

Ik hoop dat je bij Orange niet van het kastje naar de muur gestuurd wordt: zij zijn immers afhankelijk van Telenet wat het onderliggende netwerk betreft.
Laat je zeker je bevindingen weten.

[CCatalyst]

Als je deze standaarden niet volgt breek je dingen en zorg je ervoor dat sommige zaken niet naar behoren gaan werken.

Is in casu niet het geval. Wees gerust - als men dingen zou breken door ze niet te volgen, dan volgt men de RFC wel (meestal ).

Hallow, na een cyber incident bij ons staat ICMP zelfs overal expliciet uit, 'een schending' hahah

Interessant. Zou dit incident niet gebeurd zijn met ICMP (ik veronderstel ICMP Echo dan) aan? Kan het niet opnieuw gebeuren zonder ICMP (via een iets ander werkwijze dan)?

Wij zetten zelf - net zoals de meesten denk ik - ook een rate limit op het aantal ICMP pakketten dat naar de control planes van de routers mogen - wat de DDoS of eventuele amplification pistes afsluit zonder ICMP als debugging tool volledig onbruikbaar te maken, de ideale compromise. Helemaal ICMP uitschakelen doen we niet. We maken zelf ook vaak dankbaar gebruik van ping, traceroute of MTR in externe netwerken om snel een diagnose te stellen; in de veronderstelling dat anderen dat ook bij ons doen blijft ICMP dus aan als goed nabuurschap (internet is geven en nemen).

Niet dat ik beweer dat dit bij jullie wel zo is, maar onze veiligheid berust niet op het ons onzichtbaar maken voor ICMP verzoeken. Soms wordt dit "security through obscurity" argument immers nog wel eens boven gehaald, maar obv van de analysis van de inbraakpogingen die we zien, heeft ICMP bij ons geen factor daarin.

Een schending is het idd niet, maar ik ben wel geinteresseerd wat de achtergrond is om ICMP volledig uit te schakelen bij jullie. Oprechte vraag, geen troll, geen kwestie van "wie heeft gelijk," de situatie en dus de aanpak is voor iedereen immers anders.

[Stormlord]

Wat je intern op je eigen LAN doet is natuurlijk ook een ander gegeven dan wat je als een groot telco provider op internet doet - vind ik, maar bon.

Op mijn werk staat intern voor de gewone endusers VLAN ICMP ook uit vanaf de gateway.

Ik denk echter dat dat hier bij telenet op onze node niet het geval is - want het is niet steeds 100% loss (soms veel, soms weinig loss) - dus waarschijnlijk dropped hij eerst de ICMP eerder uit "selfpreservation" als er een saturatie is of dreigt ...

In elk geval haal ik ook verre van normale snelheid, en zoals de laate unit-t tech die ik over de vloer kreeg ook heeft toegegeven:
er is een probleem door een beschadigde kabel waarvoor een vergunningsaanvraag en onderboring nodig is voor de herstelling én er is op piekmomenten overbelasting op de node... Als je die beide cumuleert dan kan het natuurlijk zijn dat je net zoals ik met downsnelheden zit van 200-500 mbit, waar ik nu sinds meer dan een half jaar meestal land(met een 1GbE). Je zou verwachten dat ze zoiets monitoren en aanpakken, maar vermits er geen oplossing kwam ben ik uiteindelijk na verschillende maanden geduld te hebben geoefend klachtenforms beginnen invullen. Upload is meestal geen probleem, overwegend 37-38mbit, hoewel ik enkele dagen geleden ook eens even daar rond de 25 zat (maar dat is eerder uitzonderlijk).

@sinna: ik hoop het ook, en ik weet ook dat ze daar deels van Telenet afhankelijk zullen zijn om het probleem uiteindelijk op te lossen - maar bij gebrek aan betere opties is dit dé manier om duidelijk te maken aan Telenet dat ze niet met vaste langdurige klanten hun voeten moeten blijven spelen (én als added bonus toch voldoende minder te betalen voor ongeveer hetzelfde). 1 klant gaat het verschil niet maken natuurlijk, maar als vele dat beginnen doen zal misschien hun frank vallen dat ze voor wat zij vragen aan € toch betere service mogen leveren ... Je wordt gewoon NIET teruggecontacteerd na de eerste call en evt. opsturen van een tech om te vragen of je probleem nu opgelost is bijvoorbeeld - er is dus gewoon GEEN noemenswaardige opvolging (nu al ondervonden bij meerdere calls). Dus, heb ik dit weekend mijn overstap naar Orange in gang gezet.

Jammer dat ik nog niet op FTTH kan aansluiten momenteel, anders had ik natuurlijk eerder daarvoor gegaan.
VDSL hier is povertjes 20-30 / 2 en heb om die reden zelfs geen koper laten binnenbrengen ....

[ITnetadmin]

Ik word ook onnozel van RFC non-compliance.
Van routers die ICMPs droppen of negeren, tot ISPs die verkeerdelijk 10/8 subnets gebruiken voor CGNAT terwijl dat 100.64/10 moet zijn.
Wat mij betreft mocht correcte implementatie best wat meer verplicht en/of afdwingbaar zijn.