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
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.
Este 8 után 0,5 Mbit/sec a csúcs tunnel sebesség, 30-50%-os packet lossal. Ezen időben a KIFÜ hálózatból 8-900 Mbit/s a sebesség.
RViktor
A 170-es ping se tűnik normálisnak europán belül.
Domain, tárhely és webes megoldások: aWh
Hol látsz te itt 170-es pinget?
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.
Csak épp ez nem ping, ez egy traceroute kimenet. Ennek az értékei köszönő viszonyban sincsenek a ping eredményével.
Valóban, mert udp-vel megy a traceroute általában. Ettől még az adott hop válaszidejét mutatja.
Nagyon nem.
Próbaképpen egy hálózaton elindítottam egy traceroute-ot, és a célállomás értékei ezek voltak:
4.606 ms 4.829 ms 4.524 ms
Ugyanez a cím ugyanarról a forrásról ping eredmény:
rtt min/avg/max/mdev = 0.794/0.914/1.058/0.109 ms
Nem ritka a 170-es ping (nem trace) esténként. :( Amit le is szarnék, ha nem 0,5 Mbit/s lenne a tunnel sebesség. A Kifü hálózatán 800-900 Mbit a tunnel sebessége.
RViktor
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.
Hát ez a hozzászólás nem tudom miért született. Anycast megvan?
Nem én problémáztam azon, hogy egy belföld/belföld kapcsolat időnként megjárja a külfölet.
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
Hát, jah, csak az a ne proxyz csak akkor jó, ha csak CDN-ezel, de ha már van worker vagy page, stb. akkor már nem tudod ezt megtenni.
Domain, tárhely és webes megoldások: aWh
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.
Ettől még nem épp jófejség, ugye.
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)
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 nagy ötlet lehetett, mert a nem open-peering jóval drágább. :)
Viszont lehet, hogy több pénze jön be abból, hogy a többi partnert meg paid peeringre tudja terelni ezáltal, mivel ő Tier 1-es backbone cég. Elég nagy szereplő a DTAG ahhoz, hogy ezt megtehesse.
A másikra írtam. Minden esetre a CF erősen vállrándít, mert akkor majd Bécsben vagy Frankfurtban, vagy más nagy IX-en találkoznak. A Telekom a saját ügyfeleit szivatja, nem a CF-et.
ameddig minden más jó az Ügyfélnek - kivéve a CF - háttérinfó nélkül simán lenyomja az ügyfélszoli, h a CF-nél van a gond...
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?:)
Hát azért itt-ott jelen van a CF: https://www.peeringdb.com/asn/13335
Nem is veluk van a gond.
172.66.41.46 ARIN-os igen, de hirdetik (és valszeg végződtetik is) a bix-en keresztül amúgy.
Domain, tárhely és webes megoldások: aWh
A Cloudflare CDN anycast-et használ, tehát igazából nem értelmezhető, hogy a konkrét IP "van valahol", mert sok helyen van ugyanaz az IP.
https://developers.cloudflare.com/reference-architecture/architectures/…
https://en.wikipedia.org/wiki/Anycast
OK, ez valid, erre nem gondoltam.
"Sose a gép a hülye."
Ez it csacskaság.
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.
Na így legalább a koncepciót értem. Undorító. Most megnéztem a telekom az egyetlen akinek Selective peeringje van a magyar szolgáltatók közül, ez is sokat elmond.
RViktor
Amennyiben a telekom alatt a Magyar Telekom-ot erted, akkor nekik ehhez sok kozuk nincs, azt csinaljak amit a DTAG enged nekik. KB az a helyzetuk mint a magyar upc-nek volt az LGI leanyakent.
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
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…
A fél internet túsz a DT és a Cloudflare vitájában
lenne meglepetés, ha a CF egyszerűen leválna a DT-ről és mivel van alternatív irány, működnie kéne
Erről szól a poszt. Pont ez van most, hogy működik most is, nincs közvetlen peering a két hálózat között, ezért aztán jó nagy kört megy minden. Látszik is, hogy az AS6453 az átkötő hálózat.
arról szól a poszt, hogy kikényszerítik a DT érdekkörben lévő magyar telekomnál, hogy kizárólag a DT-CF dedikált irányból engedjék a forgalmat, pedig lenne más, jobb alternatíva.
De nincs DT-CF dedikált irány, a DT és a CF nem cserél adatot direktben.
Az AS5483 (a Magyar Telekom) csak a BIX-ben van jelen, és ott selective peeringje van üzletpolitikai okokból.
szelectív peering: csak a dt vonalat használja, hogy a dt zsaroléhassa a cf-et a lassítással
ezt most nem teljesen értem.
Pont az a helyzet, hogy most a CF és DT nem cserél _direkt_ adatot, csakis tranzit szolgáltatón keresztül.
A DT a BIX-en "selective peering" azaz eldöntheti, hogy kivel cserél ki forgalmat. Ennek a csatlakozási módnak jelentősen magasabb a díja.
A DT szeretne egy olyan összeköttetést a CF-el, ami a CF-nek kevesebbe kerül mint a tranzit (de többe, mint az IX peering) - és ezt a pénzt szeretné Ő zsebre vágni.
nem hiszem, hogy a CF kizárólag DT hálózaton át kommunikál a külvilággal. A DT zsarolását a legegyszerűbb kábelelvágással orvosolni. Majd akkor hajlandóak lesznek a meglévő és nem is plusz költségbe kerülő peeringeket nem elkerülni.
Te másik mozit nézel: "nem hiszem, hogy a CF kizárólag DT hálózaton át kommunikál a külvilággal"
a probléma pont ott van, hogy CF a külvilágon át kommunikál a DT hálózattal - ehelyett, hogy ezt IX-en (értsd: internet exchange) tenné.
A DT úgy van vele, hogy ez a másik félnek jobban fáj, mint neki, ezért a másik félnek olcsóbb egy (fizetős) peering-et kialakítani, mint tranzit irányba küldeni a forgalmat.
csak par pontositas,
* a DT (3320) nem bix tag
* egy paid peering a DT-vel jelentosen tobbe kerul mindennel, (IP tranzit, IXP), igy akarnak ok is "reszesedni" a masik fel munkajabol szarmazo bevetelbol
ha a paid peering többe kerül mint az IP tranzit, akkor hol a probléma? tranziton kell küldeni a forgalmat. Őszintén szólva csodálkoznék, ha a DT-nek az adott irányú tranzit linkje bedugulna...
Csodalkoznal?:)
itt mar leirtam https://hup.hu/comment/3064213#comment-3064213
ezzel kapcs.irtam PM
hopp, duplicate...
Nahat nemetek nemetkednek. Legjobb dontes volt telekomtol megszabadulni