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.
