2 basty:
OT: omlouvám se za OT, ale pro srandu - jeden zákazník mi rozporoval naměřených 45Mbps na domácí přípojce speedtestem přímo před ním se stejnou konfigurací IP a přes jeho wifi na čínské destičce s androidem 1,5Mbps a chtěl slevu, a mlel to pořád dokola
❗️Toto je původní verze internetového fóra ISPforum.cz do února 2020 bez možnosti registrace nových uživatelů. Aktivní verzi fóra naleznete na adrese https://telekomunikace.cz
Zase ten NAT 1:1 - může to fungovat i z vnitřní sítě?
nejak nevim tu souvislost s cim by mi mel radius pomoci v takove situaci. 
ale tak to je klasika tohle... Resime to idividualne... obecne proste "garantujeme za SXT na kabelu" jen se to musi dobre okecat. Ale jeho zarizeni, jeho problem
ale tak to je klasika tohle... Resime to idividualne... obecne proste "garantujeme za SXT na kabelu" jen se to musi dobre okecat. Ale jeho zarizeni, jeho problem
0 x
řešilo se dokazování, jestli to zákazníkoj jede / nejede ... když zákazník hlásí problém, monitoruje dostupnost na CPE (smokeping, grafy přenesených dat, uptimy zařízení, pády lan porů/wlan interfaců), že to je vidět v radiusu na odpojování pppoe je další varianta (když chybuje linka jak se ptal dalibor)
0 x
Jj, ale defakto u WiFi když budu monitorovat odpojování od vysílače, tak je to cca to samé jako u rádiusu... Když beru v potaz že síť je dál ok... Takže co se týče monitoringu mi to přijde stejně...
0 x
basty píše:Mne treba vadi takto dalsi prvek o ktery se musim starat a bez kterého to "nepojede" radius. Mel bych tedy mit 2 na jinych mistech a ty 2 musim patricne synchronizovat, zalohovat (+ co se tyce napajeni) a spravovat. Co se tyce dokazovani jestli klient jel nebo ne... Stejne je vetsina problemu zpusobena u nej doma a tam vam to pppoe nijak nepomuze. Pokud je to kokot a bude se s vami hadat, tak stejne i kdyz mu to ukazete, tak stejne plati: "zakaznik ma vzdy pravdu". U normalniho zakaznika to nebudete potrebovat. Pokud bych se chtel hadat ve smyslu vymahani penez... tak stejne vetsina lidi nejde az tak do dusledku a data z pignu nebo radiusu jsou svym zpusobem rovnocena. Nic neni nijak oficialne prokazatelny, obe hodnoty si muzes nakraslit nebo udelat jak chces.
Jak jsem psal, nikoho nenutim, aby pouzival PPPoE apod. Jen jsem rikal, jaky jsou vyhody. Jinak jo, pokud nekdo nezkusil tak nevi. A starat se o server? Stejne je vzdy system ktery to obsluhuje, takze ono je to fuk.
0 x
vsak jasne... kazdy musi zvazit...
no ano, pokud nejede system tak se nic nedeje... jen nemam statistiky apod... ale kdyz nejede radius tak sice pripojeni klienti jedou(jak dlouho?), ale novi apod. se nepripoji...
Docela by me zajimal ten interval protoze to by jinak treba u toho fryzla velke casti lidem jelo a ne ze bylo off uplne vsechno, krom tech 20% co maji statiku.
no ano, pokud nejede system tak se nic nedeje... jen nemam statistiky apod... ale kdyz nejede radius tak sice pripojeni klienti jedou(jak dlouho?), ale novi apod. se nepripoji...
Docela by me zajimal ten interval protoze to by jinak treba u toho fryzla velke casti lidem jelo a ne ze bylo off uplne vsechno, krom tech 20% co maji statiku.
0 x
Nefunguje pouze overeni (+ acc), portoze to dela radius, takze jedou tak dlouho doku se nerozpadne PPPoE, takze klidne rok.
0 x
Tak to je dobře... V tom případě už vůbec nechápu toho fryzla.
0 x
TVL, to jste fakt tohle řešili i na Štedrý den, což je den pohádek, jak třeba Karkulka zapíchla vlka: https://www.youtube.com/watch?v=I4Far7J-cb8 potom trochu romantiky se štastným koncem, jak třeba se lev nažral a džungle zůstala celá: https://www.youtube.com/watch?v=AIXUgtNC4Kc a na závěr, tak malé zasavení a zamyšlení na tradiční půlnoční: https://www.youtube.com/watch?v=1zN7J64IeBo a ne nějaké praštěné PPPoE.....
Jinak, k té evangelizační PPPoE misi je dobře říci, že telco svět se snaží od PPPoE utéci. Respektive se chce zbavit té PPP vrstvy při zachování všech ostatních vlastností toho PPPoE spojení (accounting, dynamické řízení bod-bod spojení, trasy a tunelování, ověření koncového zřízení, princip spojení se stavem běží/neběží, izolace klientů od sebe a hlavně izolaci od systémů ISP, ...). Což ve světe ROSu spol je hodně vzdálená fikce. Natož, abych v PPPoE accouning datech měl vložena data o přenosové vrstvě, jak je u některých systémů možné (třeba info o kvalitě a parametrech wirelessu přes který to jde). Takže u ROSu můžeme být rádi, pokud prvně dodělají toto do telco kvality. Třeba už jen ve vzahu k IPv6 je dost věcí chybějících, stejně tak podpora pro dynamické rozkládání zátěže mezi víc PPPoE serverů, natož některé novější broadband specifikaci pro nepopiratelnost. PPPoE intermediate agent byl již dříve zmíněn. Také by mohli přidat HW podporu pro PPPoE, kterou umí některé Ethernet chipsety v Mikrotikách používané, takže se odlehčí tím CPU.............
Fryzl: Napadá mě jendoduchý scénář, jak to mohlo nastat. Chcíplo mu spojení k tomu cloudovému pronajatému managementu, nebo chcípl ten managemet, udělal restart PPPoE serveru, tím naráz odpojil hodně zákošů, kteří se náledně nemohli připojit zpět, dokud nevyřešil nefunkčnost toho vzdáleného Radiusu. Zkrátka je třeba to mít u sebe a ve dvou distančních kopiích, pokud se svěřuji cízí vzdálené službě, tak počítám s tím, že to občas nebude fungovat (stejně od května 2018 se stane takováto konfigurace možná ekonomicky nezajimavá s ohledem na náklady kvůli dodržení požadavků GDPR)...
L2 filtr na PPPoE jsem mínil to, že co nejlíže k zákazníkovi od něj přijmu jen Ethernet rámce typu PPPoE data, PPPoE discovery a ostatní drop. L2 filtr nd bridgem v Mikrotiku ty 3 pravidla dává v pohodě, protože majorita paketů vyhoví prvnímu pravidlu. Plu izolace všech klientů od sebe na L2 vrstvě, aby jednak nemohl někdo podstrčit falešný PPPoE server a druhák si přes to L2 dělat tunely mezi koncovými místy mimo moji kontrolu.
Vliv zkrácení MTU na L2TP/IPsec klienta ve Windows - to je v pohodě, klient neumí path MTU dicovery, ale je nastven, že počítá s MTU1480, takže v pohodě. A případně jde MTU na Win klientovi snížit v registrech. A pak stále mohu už hrát na to, že ROS už umí jen PPPoE s MTU1500, pokud přenosová vrstva má na to rezervu (ale fakticky funční je to až od ROS6.37, ve starších je to nějak poprzněno a obvykle uskočí na nouzových MTU1480, že selže detekce L2MTU).
Souhlas s tím, e pro firemní přípojky PPPoE necpat, tam udělat spoj (kliendě jako VPLS tunel, ať to mám jednotné) v kterém pojedu normální spojovák /30 a naroutuji to. Pokud si ted firma platí firemní přípojku a ne home tarif.
Jinak, k té evangelizační PPPoE misi je dobře říci, že telco svět se snaží od PPPoE utéci. Respektive se chce zbavit té PPP vrstvy při zachování všech ostatních vlastností toho PPPoE spojení (accounting, dynamické řízení bod-bod spojení, trasy a tunelování, ověření koncového zřízení, princip spojení se stavem běží/neběží, izolace klientů od sebe a hlavně izolaci od systémů ISP, ...). Což ve světe ROSu spol je hodně vzdálená fikce. Natož, abych v PPPoE accouning datech měl vložena data o přenosové vrstvě, jak je u některých systémů možné (třeba info o kvalitě a parametrech wirelessu přes který to jde). Takže u ROSu můžeme být rádi, pokud prvně dodělají toto do telco kvality. Třeba už jen ve vzahu k IPv6 je dost věcí chybějících, stejně tak podpora pro dynamické rozkládání zátěže mezi víc PPPoE serverů, natož některé novější broadband specifikaci pro nepopiratelnost. PPPoE intermediate agent byl již dříve zmíněn. Také by mohli přidat HW podporu pro PPPoE, kterou umí některé Ethernet chipsety v Mikrotikách používané, takže se odlehčí tím CPU.............
Fryzl: Napadá mě jendoduchý scénář, jak to mohlo nastat. Chcíplo mu spojení k tomu cloudovému pronajatému managementu, nebo chcípl ten managemet, udělal restart PPPoE serveru, tím naráz odpojil hodně zákošů, kteří se náledně nemohli připojit zpět, dokud nevyřešil nefunkčnost toho vzdáleného Radiusu. Zkrátka je třeba to mít u sebe a ve dvou distančních kopiích, pokud se svěřuji cízí vzdálené službě, tak počítám s tím, že to občas nebude fungovat (stejně od května 2018 se stane takováto konfigurace možná ekonomicky nezajimavá s ohledem na náklady kvůli dodržení požadavků GDPR)...
L2 filtr na PPPoE jsem mínil to, že co nejlíže k zákazníkovi od něj přijmu jen Ethernet rámce typu PPPoE data, PPPoE discovery a ostatní drop. L2 filtr nd bridgem v Mikrotiku ty 3 pravidla dává v pohodě, protože majorita paketů vyhoví prvnímu pravidlu. Plu izolace všech klientů od sebe na L2 vrstvě, aby jednak nemohl někdo podstrčit falešný PPPoE server a druhák si přes to L2 dělat tunely mezi koncovými místy mimo moji kontrolu.
Vliv zkrácení MTU na L2TP/IPsec klienta ve Windows - to je v pohodě, klient neumí path MTU dicovery, ale je nastven, že počítá s MTU1480, takže v pohodě. A případně jde MTU na Win klientovi snížit v registrech. A pak stále mohu už hrát na to, že ROS už umí jen PPPoE s MTU1500, pokud přenosová vrstva má na to rezervu (ale fakticky funční je to až od ROS6.37, ve starších je to nějak poprzněno a obvykle uskočí na nouzových MTU1480, že selže detekce L2MTU).
Souhlas s tím, e pro firemní přípojky PPPoE necpat, tam udělat spoj (kliendě jako VPLS tunel, ať to mám jednotné) v kterém pojedu normální spojovák /30 a naroutuji to. Pokud si ted firma platí firemní přípojku a ne home tarif.
1 x