Cloudflare - Magyar Telekom nemzetközi peering

[alienhun11]

Sziasztok!

Ismét "elromlott" a nemzetközi peeringje a telekomnak a CloudFlare felé, érdekes hogy a legnagyobb magyar Telco cég nem képes a BIX-be routolni be az egyik legnagyobb CDN forgalmát. Főleg úgy, hogy rengeteg magyar weblap is cloudflare-en "él". 

A DTAG cső szinte megint fullra van telítve, 50% PL-al. Nem lehetne rendezni végre a peeringet nemzetközi irányba, ha már ténylegesen oda kéne kimenni a forgalomnak? 

[MBali28]

17 órája, Telekomód írta:

Mi a célpont (IP)? 

Lehet a a tartomány nincs (még) felvéve, ugyanis a TK csak a hozzáadott, problémás tartományok felé nyújt megoldást. 

A probléma megoldódott a Tranzitkanyar segítségével. Mindenkinek ajánlom kipróbálását, és bárkinek bármi kérdése, problémája, nyűgje van, mindenképp gyertek fel a FXTELEKOM Discord szerverre, ahol nagyon segítőkész emberek 10 perc alatt hozzá is adták a problémás tartományt megoldva ezzel a packet lossos nehézséget. Innen is köszi! 🙂

https://tranzitkanyar.pages.dev/?src=mt_signature

https://discord.gg/mpwSnMQy 

[AttilaEXSVK]

Álljon itt egy jó hír is, bármennyire is ritka a Telekom esetében  A KONFERnetes elérés problémám megoldódni látszik, igaz írtam a Telekomnak, a VNET-nek (az esetemben rajtuk keresztül ment a forgalom Bécs és Pozsony között, és ott láttam a lassulást) és a KONFERnetnek is (ahol egyébként dolgoztam, így jóban vagyok a tulajdonossal a mai napig). Ma felhívtak a Telekomtól, hogy a DTAG peering politikája miatt kacifántos az útvonal (szokásos rizsa), de azért nézzek már rá, hátha most jobb. Meglepően jobb lett, de nem tudom melyik fél jóvoltából

Ez volt a régi traceroute, itt olyan 40% körüli volt a packet loss:

Ez pedig az új:

Most 0%-os a packet loss, de előfordulnak 150-200ms pingek is, úgy minden 5.-6. ilyen:
--- 178.23.89.xxx ping statistics ---
125 packets transmitted, 125 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 11.353/45.319/371.434/56.490 ms

[benedict]

7 órája, AttilaEXSVK írta:

Álljon itt egy jó hír is, bármennyire is ritka a Telekom esetében  A KONFERnetes elérés problémám megoldódni látszik, igaz írtam a Telekomnak, a VNET-nek (az esetemben rajtuk keresztül ment a forgalom Bécs és Pozsony között, és ott láttam a lassulást) és a KONFERnetnek is (ahol egyébként dolgoztam, így jóban vagyok a tulajdonossal a mai napig). Ma felhívtak a Telekomtól, hogy a DTAG peering politikája miatt kacifántos az útvonal (szokásos rizsa), de azért nézzek már rá, hátha most jobb. Meglepően jobb lett, de nem tudom melyik fél jóvoltából

Ez volt a régi traceroute, itt olyan 40% körüli volt a packet loss:

Ez pedig az új:

Most 0%-os a packet loss, de előfordulnak 150-200ms pingek is, úgy minden 5.-6. ilyen:
--- 178.23.89.xxx ping statistics ---
125 packets transmitted, 125 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 11.353/45.319/371.434/56.490 ms

Nem sokáig tartott a jóvilág.... Újra a rohadt DTAG-on megy keresztül minden, újra ***** minden..... 

[AttilaEXSVK]

18 órája, benedict írta:

Nem sokáig tartott a jóvilág.... Újra a rohadt DTAG-on megy keresztül minden, újra ***** minden..... 

Látom és nagyon nem örülök neki:

 2  lo1.bsr0-pesterzsebet.net.telekom.hu (145.236.238.187)  6.681 ms  5.947 ms  5.325 ms
 3  81.183.3.32 (81.183.3.32)  6.639 ms
    81.183.0.37 (81.183.0.37)  9.447 ms
    81.183.3.32 (81.183.3.32)  6.914 ms
 4  81.183.3.95 (81.183.3.95)  7.475 ms
    81.183.1.3 (81.183.1.3)  7.768 ms
    81.183.1.15 (81.183.1.15)  8.084 ms
 5  80.156.161.104 (80.156.161.104)  14.787 ms  13.284 ms
    62.159.61.98 (62.159.61.98)  10.287 ms
 6  vie-sb5-i.vie.at.net.dtag.de (217.239.40.146)  195.601 ms
    vie-sb5-i.vie.at.net.dtag.de (217.239.40.157)  13.390 ms  13.117 ms
 7  62.159.61.127 (62.159.61.127)  14.497 ms  12.557 ms  12.681 ms
 8  vnet-a.s.edge3.vienna1.level3.net (212.73.202.86)  14.545 ms  16.268 ms  43.445 ms
 9  be55-4.sixasr.vnet.sk (185.176.72.150)  17.050 ms  17.164 ms  101.710 ms
10  109.74.147.186.host.vnet.sk (109.74.147.186)  13.781 ms  14.406 ms  14.634 ms
11  six.2.konfer.net (178.23.88.2)  16.205 ms  18.364 ms  13.452 ms
12  5g-static.88.254.konfer.net (178.23.88.254)  14.820 ms  16.077 ms  15.961 ms

Mindegy, megy az újabb hibajegy, aztán idővel vagy kötélnek állnak, vagy átmegyek a kék szolgáltatóhoz, itt áll ki a falból az ő optikájuk is. Áldom az eszem, hogy csak egy év hűséggel kötöttem meg a szerződést kettő helyett. 

[Slash86z]

Nemakarom elkiabálni de mintha történt volna valami lehet csak ideig órájig le jöttem vpn ről és gondoltam megnézem mi a szitu és meglepődve ezt kaptam többször is vissza.Igaz volt hogy 9 vagy 10 ponton ment de nem voltak magas pingek és a lényeg hogy packetet se droppol és nem megy a tengeren túlra hessen asztán bécs és nem a frankfruti clodfflarbe megy hanem bécsbe. Másnál mi a  helyzet? RViktor ha olvasod még a fórumot nálad? Holnap este ránézek megint.

[Watt768]

Pedig változatlanul ürülék az egész. Kár, hogy nem tapasztaltam amikor más felé ment.

Szerkesztve ekkor: szeptember 5. Szerkesztő: Watt768
Kicsillagozta elsőre...

[Slash86z]

Ma is jó.De még nem mondom le a vpn-t biztos ami biztos még 2 hét van belőle. Hátha megoldódig másnál is és így is marad.

[Zozzi]

Minőségi cucc:

VPN-nel megy, de pár percenként megszakad a kapcsolat, és beletelik pár másodpercig míg újracsatlakozik. Jelenleg VPN nélkül teljesen használhatatlan a net, VPN-nel pedig használhatatlan minden olyanra, ami állandó kapcsolatot igényel. Ez nem elegendő egy fogyasztóvédelmi feljelentéshez? Szeretném ha minimum a hűségidőmet megsemmisítenék, és lemondhatnám ezt a sz*rt...

[hmbl]

Ekkor: 2024. 09. 08. at 10:46, Zozzi írta:

...
Szeretném ha minimum a hűségidőmet megsemmisítenék, és lemondhatnám ezt a sz*rt...

Hűségidő alatt is van lehetőség felmondani a szolgáltatást. Feltételek:

• a bejelentett hibát a szolgáltató nem hárította el a 72 órás javítási időt követő 15 napon belül;
• a felmondást megelőző 90 napon belül több, mint 10 általa bejelentett hiba elhárítására került sor;
• a szolgáltató a szolgáltatást 30 napon át nem szerződésszerűen teljesítette.

Forrás.

Szerintem az első meg is áll, nem játszhatja ki a T azzal, hogy rajta kívül álló ok, hisz az NMHH ilyet nem támaszt feltételnek. A másik, mint látjuk, igenis nem a T-n kívüli probléma, mert jó routinggal, ahogy a többi szolgáltató csinálja, nem lenne probléma.