Telekom vs Cludflare probléma

Sziasztok,

a régi időkben volt itt Telekomos :) Remélem most is van olyan ember aki tud segíteni, mi miért történik.
Februárban 4 napig, de most lassan 10 napja használhatatlan a Cloudflare telekom hálózatból. (kifli/telex/discord/Argo tunnelek)

Szerintem nyilvánvaló routing hiba, de olyan mintha más ok lenne mögötte, mert csak a maszatolás megy. Miért éri meg a belföldre routeolható címeket kiküldeni a nagyvilágba?

Argo Smart routing előfizetéssel így néz ki a trace telekom hálózatból:

Tracing route to 172.66.41.46
over a maximum of 30 hops:

  1     1 ms     1 ms     2 ms  192.168.1.1
  2     3 ms     2 ms     3 ms  lo1.bsr3-kobanya.net.telekom.hu [145.236.238.140]
  3     4 ms     4 ms     4 ms  c-ge1-2.osr0-krisztina.net.telekom.hu [81.183.246.63]
  4     3 ms     3 ms     3 ms  81.183.3.139
  5     *        *        *     Request timed out.
  6     8 ms     7 ms     8 ms  80.156.160.221
  7     *       18 ms    19 ms  if-bundle-12-2.qcore2.fnm-frankfurt.as6453.net [195.219.25.30]
  8    60 ms    60 ms    70 ms  if-ae-55-2.tcore2.fnm-frankfurt.as6453.net [195.219.87.56]
  9   147 ms   157 ms   145 ms  162.158.84.55
 10   142 ms   139 ms   122 ms  172.66.41.46

Trace complete.

KIFÜ:
Tracing route to 172.66.41.46
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  10.88.0.1
  2     2 ms     2 ms     2 ms  193.224.3.9
  3     3 ms     3 ms     5 ms  tg0-1-0-12.rtr1.vh.hbone.hu [195.111.100.48]
  4     1 ms     1 ms     1 ms  hungarnet-ias-geant-gw.bud.hu.geant.net [83.97.88.81]
  5     3 ms     2 ms     2 ms  cloudflare.bix.hu [193.188.137.27]
  6     2 ms     1 ms     1 ms  172.66.41.46

Trace complete.

Viktor

Hozzászólások

Miért éri meg a belföldre routeolható címeket kiküldeni a nagyvilágba?

Khm. üzletpolitikai okokból.

A hasznalhatatlan azt jelenti hogy nem megy vagy "csak" szerinted lassu, nem idealis? Sajnos internet elerest szolgaltatnak, nem infra-t, ami fix, iidealis es valtozatlan. 

8    60 ms    60 ms    70 ms  if-ae-55-2.tcore2.fnm-frankfurt.as6453.net [195.219.87.56]
  9   147 ms   157 ms   145 ms  162.158.84.55

Valóban nem 170, de nagy ugrás. Ez azt szokta jelenteni, hogy áthalad a tengeren túlra, de frankfurtig a 60ms is nagyon sok, az olyan 15-20 körül kéne legyen.

Miért éri meg a belföldre routeolható címeket kiküldeni a nagyvilágba?

Ha Cloudflare, akkor őket kell kérdezni. Lehet, hogy nincs nekik magyar címtartományuk, így ha egy magyar cím megy be cloudflare mögé, akkor bizony megjárja a külföldet. Ez esetben a miértre is megvan az ok: DDoS védelem.

A Cloudflare azt mondja ticketben, hogy mindent megtesznek, hogy Telekom-nak jó legyen, de nekik nem jó semmi.
Mondom oké csak Magyarországon millió számban mérhető a Telekom előfizető (mobil+vezetékes) és nem érik el a szolgáltatásainkat este... Erre kaptam, hogy akkor a Telekom forgalmát szűrjem ASN szűréssel és ne proxyzzam, jeee....

RViktor

Szerkesztve: 2024. 05. 28., k – 09:27

Miért lenne ez routeolási hiba? A Telekom hálózatából ez a legrövidebb route, ami van a 172.66.41.46 host felé. 
A Magyar Telekomnak a BIX-ben selective peeringje van, valószínűleg a Cloudflare felé nincs. A KIFÜ-nek meg Open/Free peeringje van a BIX-ben, ahogy a CloudFlare-nek is, így ott ki tudják cserélni a forgalmat.

Hogy miért van a MT-nek selective peeringje? Üzletpolitika.

Ez nem routeolási hiba.

tudtommal az van - kifejtve a "selective peering" fogalmát, hogy adott sebesség forgalom (vagy átlagsebesség - ahogy nézzük) felett jelzi a másik félnek, hogy NEM kívánja a forgalmat publikus IX-en átvenni/átadni - kössenek össze direkt. 

emlékeim szerint pont a CF felé volt már ez a kör (nem feltétlen itthon, hanem talán .de)

 

Szerkesztve: 2024. 05. 28., k – 10:54

1. Azt te nem tudod, hogy kinek hova mi routeolható... Mindenkinek a saját dolga.

2. A 172.66.41.46 egyébként US, California, nem "belföldi" IP

Anno pár éve mikor a UPC felrúgta a komplett BIX-es szerződését, akkor MINDEN, az összes belföldi forgalom kiment és telia.net gerincen jött vissza talán.

"Sose a gép a hülye."

A CF ettől függetlenül hírdetheti a saját BIX csatlakozási pontján a tartományt. Például tőlem nézve Bécsben végződik a fenti tartomány. Gyanús, hogy a CF-esek nem minden POP-jukon hírdetik minden tartományukat, és pluszban még ez a selective egyéb marhaság bejöhet. A Telekomnak azért érdeke lenne, hogy ne a külföldjét (bármennyire széles is) darálja a CF-es forgalom. Sőt! még az itthon divatos direkt kapcsolat se lenne ördögtől való valszin.

ahogy nézzük:
a) oldalról a Telekom előfizetője morog, h x y z oldal rossz. jön a Telekom válasza: nahát, minden jelzett oldal a CF-nél van, a hiba nála lesz. minden más jó, ugye? naugye! 
Majd a tartalom szolgáltató (aki kap pénzt) megoldja a problémát...

b) oldalról a Telekom jelzi a tartalom szolgáltatójának, hogy "hello, dugulás lesz, bővíts" / "hello, elérted az ingerküszöböt, jó volna, ha összekötnénk direkt - nekem ez a pont lesz a jó, ugye neked is, és fizeted az interconnect díját? :-)"

mivel a Telekom elég nagy, és szinte végtelen a "külföldje" így neki sokkal kevésbé fáj, mint a másik félnek. Azon viszont nem csodálkoznék, hogy az egyszeri összekapcsolódás "adminisztrációs díja" az egész számú többszöröse lenne a műszaki költségeknek...

Hát a CF-vel rosszal kezd. Csak itthon 2x100G-s linket mutat a bix oldal náluk. :) Van olyan partner, ahol ez pénteken előjött, és eléggé el volt készülve, viszont mondani fogom neki, hogy jelentse be hibára a Telekomnál, ha kell akkor többször. Azon se lepődnék meg, ha internet szolgáltató cseréig mennének az irodában emiatt. Nagyon nem úgy van, hogy egy kellően mélyen beágyazott CF-ről csak úgy lejössz, annál olcsóbb, ha nemtelekom lesz.

igazából nem tudom, mennyi forgalom lenne a 2 fél között, de úgy gondolom a CF-nek nem volt túl nagy mutatvány azt mondani, hogy peer-eljünk össze a DPLX-ben n*10/40G-n. (plusz "alkotmányos költség - ami egyszeri díj, ha jól tudom)

úgy látom, akik igen jelentős "erővel bírnak" emellé betársul sajátságos nézet is. Lásd pl 3 résztvevőt (Google) aki meg éppen leköltözik a BIX route szerverekről és mindenktől kéri külön a BGP session felépítését. De hasonló az Amazon is.

 

CF<->DTAG/MT kozott nem az a nagy mutatvany, hogy allokalsz par portot es kifizeted a XC-et, hanem ezert a forgalomert a DTAG/MT penzt ker ($XX/Mbps/ho), ami egy egyiranyu utca, egyszer elkezdesz fizetni sosem szabadulsz ebbol a fiokbol.

A route server haszanalta mellett vannak pro/kontra ervek, oka (technikai) van annak, hogy nem haszanljak ezek a cegek az RS-t, de nem az hogy az ISP-ket szivassak, es mind a google-nek mind pedig az amazonnak van erre jol hasznalhato automatizalt peering portalja, ahol csak beklikkeled hol szeretnel felrantani egy BGP session-t es tadam 1-2 nap es megy is.

Az a UPC-es eset szinten ugyanabbol az okbol tortent mint a DTAG, csak a DTAG ot le kell cserelni a Liberty Global-ra (AS6830).
A CF vagy barki mas nemnagyon, de leginkabb sehogy nem talalkozik masik IX-en a DTAG-al. Gondolod az itt felsorolt ( https://www.peeringdb.com/asn/3320 ) port kapacitasok IX oldalon elegendoek barmire is?:)

Jogos amit írsz, én arra gondoltam belföldön route-olható ("belföldi" IP-re), hogy az én tunnelem BUD PoP-hoz csatlakozik és az általam kezelt hálózatokból amiből tudom tesztelni BUD vagy ritkán VIE PoP-on keresztül jön be a forgalom.
A Telekom hálózatából meg FRA (Frankfurt) vagy IAD (Washington) a jellemző :)
Amennyiben IAD a bejövő, akkor dial-up kapcsolat sebességű az elérés (ez csak 10 napja este 8 után jellemző)
Ha FRA akkor akkor nappal egész jó, de este 0,5-5 Mbit/s
A többi hálózatból 8-900 Mbit/s sebesség sem ritka.

RViktor

Mi is tapasztaltunk ilyet, hogy MT ISP oldalon CF elérés nagyon lassú, és nem csak válaszidő, hanem sávszélességben is problémák voltak az év elején. Jeleztük MT-nek, és Ügyfelek is, de szerintük nem náluk van a probléma. Sajnos routing-ban mindig DT felé route-olnak ha nincs közvetlen peering kiépítve, és így nem foglalkoznak vele.

Ugy tunik a szokasos eves DTAG (AS3320) es CloudFlare (AS13335) pelomeregetese folyik eppen. Ahogy fentebb mar emlitettek paran a dolog nem technikai jellegu hanem uzleti.

A DTAG egy Tier1, es e miatt nincs uplinkje, csak peer-el minden Tier1-el, ami sajnos csak reszben igaz, mert bar valoban minden Tier1 ISP-vel van kapcsolata, de ezek a linkek - foleg csucsidoban - koppon mennek. A DTAG termeszetesen ezt tudja, es direkt nem is valtoztat rajta, a cel az, hogy vagy toluk vegyel "internet"-et vagy fizetos peering legyen kozted es koztuk.
Ennek a paid-peering-nek termeszetesen az ara bar nem publikus, de azert mindenki tudja, hogy boven tobb mint a legdragabb Tier1 IP Transit aramkorok arai.
Igy szeretne a DTAG egy szeletet a masok tortaibol.

Mint Magyar Telekom-ot értettem nekik van egyedül Selective peering-je, de elfogadom hogy a Német is undorító :) Csak nem vígasztal. Idén másodjára van ez a probléma, tavaly is volt kétszer ilyen... és csak rosszabb minden alkalommal...
De most az az érzésem az eddig összeszedett infók alapján, hogy az MT nem tud semmit csinálni semmit és a CF mindenképpen külföldi forgalom lesz a DTAG miatt, így lassan keresnem kell másik céget a Cloudflare helyett... :(

Csak az anyagiak... a CF ára nagyon baráti a többihez képest 1TB-os forgalomnál és a szolgáltatásaikkal meg maximálisan elégedett vagyok.

RViktor

Szerkesztve: 2024. 05. 28., k – 20:22

A történelem ismétli önmagát.

2017 körül meg a mindigtv online streamjei rohadtak le telekomon, mert a közvetlen telekom-connectmedia kapcsolat lekorlátozta a forgalom sebességét. Valami hülye qos beállítás miatt az adatszelet eleje jött gyorsan, aztán meg lassítva. A bixen át más szolgáltatóknál meg simán ment minden.
https://prohardver.hu/tema/mindig_tv_mindenhol_digitalis_teve_www_mindi…