Eksperymentowałem ostro z MTU, żeby ustawić na 1540 musiałem zmodyfikować kod rp-pppoe, bo tam były sztywne limity z góry i ostatecznie udało mi się ustawić tak jak chciałem, identycznie jak jest w FB. Wtedy nawet w tunelu DSLite było MTU 1500 i działał zarówno ping jak i trace - generalnie wszystko jest funkcjonalne. Ale po namyśle zdecydowałem się nie zawracać sobie głowy tym DSLite i podstawową konfigurację mam w DS, więc kwestia zapasu MTU na tunelowanie stała się nieaktualna. Poeksperymentowałem trochę z MTU w LAN, żeby ewentualnie wdrożyć coś egzotycznego lokalnie, ale z tego też zrezygnowałem, bo okazało się że zbyt wiele klientów mi tego nie wspiera, a w dodatku MTU w IPV6 ma znacznie większe znaczenie niż w IPV4, co z kolei ciągnie za sobą poważne konsekwencje jeśli jest ustawione za wysoko dla nawet niektórych. W tej sytuacji wróciłem do idei "jeden MTU dla wszystkich" i ustawiłem MTU na 1500 wszędzie - oczywiście z wyjątkiem interfejsu VLAN na WAN, ten ma MTU z takim zapasem jaki jest potrzebny dla MTU 1500 na ppp. Już bardziej kanonicznie się nie da, Wszytko hula jak złoto. Co do szczegółów negocjacji wartości MTU między ruterem a ISP, to widać je w logach ppp, przy zestawianiu sesji. Obie strony zostawiają tam swoje placet, więc jeśli coś jest nie tak to widzę. Gdyby ktoś był zainteresowany, to mogę udostępnić fragmenty tych logów w których widać jak zestawia sesję mój ruter, a także z pcap jak robi to FB3 (zmałpowałem zachowanie).
Reasumując: sesja PPPoE jest zestawiana na interfejsie który ma odpowiednio większe MTU, interfejs w ramach niej tworzony ma MTU 1500, ale jest to negocjowane w trakcie zestawiania sesji, na podstawie tego jakie MRU (!) deklaruje strona negocjująca (dla porządku ustawiam to symetrycznie, żeby sobie nie zawracać tym głowy później, ale technicznie można sobie wyobrazić MTU<>MRU). Można sobie też wyobrazić, że nie wszędzie Orange robi to identycznie - choć wątpię.
PS.
1). Co do "encaplimit none": bez tej opcji DSLite u mnie nie działa - tunel jest martwy jeśli tej opcji nie ma. Nie mam pojęcia do czego to jest i dlaczego tak, ale sprawdziłem to wielokrotnie i jestem pewien że opcja jest u mnie konieczna.
2). Co do NAT to oczywiście jest zagadnienie trochę zewnętrzne w stosunku do zestawiania tunelu, ale na potrzeby testów w zupełności NAT + masquarade mi wystarczył. Nie chciałem mojego LAN "przedłużać" do CGNAT. Nie za bardzo też chciałem się przekonywać co by było gdyby, ale chętnie się dowiem od Ciebie co wtedy się dzieje. Fakt trochę z tym "konieczny" przeszarżowałem, ale powiedzmy że jest... wskazany? Czy też nie?
3). Jeszcze raz podkreślę: w życiu nie miałem do czynienia z tymi ruterami o których jest mowa więc nie mam pojęcia co można a czego nie można tam skonfigurować, mnie o to nie pytaj. Przełożenie między klasycznym linuxem a OSem tego rutera nie musi być (i zapewne nie jest) 1:1. Mimo to uważam, że sporo można się dowiedzieć eksperymentując tu i tu. 😉
