Velikost MTU pro PPTP na optice

mpcz

Zdravím,

mám připojeného klienta: klient RB750 -> WLAN WDS bridge 2x 711 -> RB750 PPTP klient + tunel přes optiku -> server PPTP. Při měření Btestem to jede nachlup 10 Mbit, jak má.

Měření z NB i PC do internetu ukazuje tak 3 Mbity a kolísá.

Zjistil jsem, že je souvislost velikostí MTU. Po zmenšení MTU v RB to jede krásně 10 Mbit. ALE - neotvírají se některé stránky.

Řešil takový případ již někdo a jak na to nejlépe? Změnit MTU ve všech PC mi nepřije dobré řešení.

Děkuji.

mpcz, 14/03/2013

majklik

A nastavil jsi jaké MTU a u čeho? Pokud MTU PPP vrstvy a dal jsi víc, jak cca 1464, tak to začne blbnout, pokud ta optické síť přenese jen MTU1500 na Ethernet vrstvě. PPTP záhlaví má v ROSu (pokud si pamatuji) 36 bajtů, takže tam musíš mít o 36 míň, než zvládá optická trasa mezi tím RB a serverem. To PPTP je tam proč?

Pokud by trasa zvládala i se síťovkama jumbo rámce, tak s MTU1500 na PPP vrstvě to bude fungovat ideálně. Nicméně, minimáoně RB750 umí 2k pakety.

Jo, občas je problém, když MTU pro koncáka není zachováno na 1500 (debilně nastavneé firewally obvykle někde cestou, zvláště u řady embedded krabiček běžný stav). :-(

Jiná varianta je povolit fragmentaci/asemblaci dat v PPP rámcíchj, čímž opticky klient uvidí průhzí MTU1500. Jen to musí uměr obě PPTP strany. ROS to umí. Nastavení MRRU=1500.

mpcz

A nastavil jsi jaké MTU a u čeho? Pokud MTU PPP vrstvy a dal jsi víc, jak cca 1464, tak to začne blbnout, pokud ta optické síť přenese jen MTU1500 na Ethernet vrstvě. PPTP záhlaví má v ROSu (pokud si pamatuji) 36 bajtů, takže tam musíš mít o 36 míň, než zvládá optická trasa mezi tím RB a serverem. To PPTP je tam proč?

Pokud by trasa zvládala i se síťovkama jumbo rámce, tak s MTU1500 na PPP vrstvě to bude fungovat ideálně. Nicméně, minimáoně RB750 umí 2k pakety.

Jo, občas je problém, když MTU pro koncáka není zachováno na 1500 (debilně nastavneé firewally obvykle někde cestou, zvláště u řady embedded krabiček běžný stav). :-(

Jiná varianta je povolit fragmentaci/asemblaci dat v PPP rámcíchj, čímž opticky klient uvidí průhzí MTU1500. Jen to musí uměr obě PPTP strany. ROS to umí. Nastavení MRRU=1500.

Zdravím,

dík, trošku jsem to zkoumal, zjistil jsem, že problém je v RB750. Pokud použiji tools z MKT, (výborná věc) tak vidím, že pokud pingám do internetu u zákazníka z jeho klientské antény (WDS klient) tak projde paket 1500. Pokud pingám až z jeho domácí RB 750, všechny ETH v bridge, tak projde jen max. 1460 bez fragmentace, od 1461 jsou fragmentovány.

Snad se již někdo s tímto problémem setkal.

Děkuji.

mpcz, 14.3.2013

upraveno

majklik

1460 je default hodnota kterou v ROS propustí PPTP tunel.

A co znamená, že neprojde paket delší než 1460? V tichosti zmízí bez odpovědi? Pokud ano, tak v tom paketu je nastaven příznak DF (nefragmentovat po cestě) a zároveň mezi odesilatelem a tím PPTP tunelem je někde po cestě firewall, který nepropoustí zpět ICMP hlášení, že je nutno posílat kratší pakety (ICMP typ 3, kód 4 - příliš velký paket).

Z toho WDS ti 1500 projde možná proto, že pakety odesílá bez nastaveného DF bitu, pak při vstupu do PPTP se rozsekne na dva pakety 1460 a zbytek. takže bych hledal, co po cestě ti zahazuje ICMP.

zero

My měli podobnej prob.

Na jedné mašině se nám zahazovala první část fragmentovaného paketu při odpovědi na ping a na zařízení, odkud se provádělo icmp echo, dorazila pouze payload část paketu.

Pomohlo odebrání/přidání NATu.

majklik

Těch možných scénářu atentátu na linku zatíženou zkráceným MTU je řada. To blokování ICMP je nejčastější. Viěl jsme i oarvdu vtipnou kombinaci se zkráceným MTU. Z jedná strany byl klient, který pro blbej firewall nedostal ICMP zkracovací hlášku zpět. Vyřešeno podovdem, kdy se ignoruje zákaz fragmentace, sláva, data se násilím i přes nesouhlas klienta fragmentují a posílají dál (I ROS tuhle prasárnu už umí - /ip firewall mangle add action=clear-df)... A stále nic. Na druhé straně totiž server, který okažitě zahazoval fragmentované pakety, proteže nemají co chodit.

Takže bych se snažil, ať to MTU 1500 prochází. Pokud to je přes optickou síť, která asi ti minimálně 100 Mbps dává, chceš pro klienta dosáhnout 10 Mbps a navíc je ještě za wifi PtP spojem, tak cesta nejmenšího odporu je použít to MRRU na tom PPTP spoji Při těchto rychlostech režie fragmentace/assemblace se zcela ztratí a klient uvidí průchozích 1500. Pro trošku lepší efektivitu jen na PPTP šáhat pomocí mangle pravidel do otvíraných TCP spojení a srážet MSS tak, aby u TCP to fragmentovat nemusel.

mpcz

Těch možných scénářu atentátu na linku zatíženou zkráceným MTU je řada. To blokování ICMP je nejčastější. Viěl jsme i oarvdu vtipnou kombinaci se zkráceným MTU. Z jedná strany byl klient, který pro blbej firewall nedostal ICMP zkracovací hlášku zpět. Vyřešeno podovdem, kdy se ignoruje zákaz fragmentace, sláva, data se násilím i přes nesouhlas klienta fragmentují a posílají dál (I ROS tuhle prasárnu už umí - /ip firewall mangle add action=clear-df)... A stále nic. Na druhé straně totiž server, který okažitě zahazoval fragmentované pakety, proteže nemají co chodit.

Takže bych se snažil, ať to MTU 1500 prochází. Pokud to je přes optickou síť, která asi ti minimálně 100 Mbps dává, chceš pro klienta dosáhnout 10 Mbps a navíc je ještě za wifi PtP spojem, tak cesta nejmenšího odporu je použít to MRRU na tom PPTP spoji Při těchto rychlostech režie fragmentace/assemblace se zcela ztratí a klient uvidí průchozích 1500. Pro trošku lepší efektivitu jen na PPTP šáhat pomocí mangle pravidel do otvíraných TCP spojení a srážet MSS tak, aby u TCP to fragmentovat nemusel.

Zdravím, trošku se v tom návodu ztrácím, hlavně nevidím souvislost s optikou. Pokud u zákazníka z jeho antény RB711 pakety 1500 chodí OK, pak už je jen UTP a z jeho domácího routeru RB750 (vše v bridge) už jen 1460, tak to může způsobit optika? Pokud ne, tak jak to prosím napravit?

Děkuji,

mpcz, 16.03.2013

majklik

1500 choí OK znamení co? A kam chodí?

Co ti vrací RB711 a ta domácí RB750 na:

/ping http://www.cz size=1500 do-not-fragment

mpcz

1500 choí OK znamení co? A kam chodí?

Co ti vrací RB711 a ta domácí RB750 na:

/ping http://www.cz size=1500 do-not-fragment

Zdravím,

je to popsáno nahoře, OK znamená, že z RB750 projde ping 1460 třeba na seznam.cz bez jakýchkoliv problémů, 1500 hodí hlášku chci fragmentovat a nemůžu ( MKT zakázal ).

Dík.

mpcz, 16/03/2013

majklik

A prochází ti komunikace od toro RB750 i RB711 tím PPTP tunelem? Nejde ti náhodou to RB711 bokem. Viz traceroute.

Jinka MTU1460 odpovídá výchozímu nastavneí PPTP tunelu, kolik povolí.

NAstav si ve vlastnostech PPTP klienta i serveru hodmotu MRRU na 1500 (defualtně je to nenastavneo).

mpcz

A prochází ti komunikace od toro RB750 i RB711 tím PPTP tunelem? Nejde ti náhodou to RB711 bokem. Viz traceroute.

Jinka MTU1460 odpovídá výchozímu nastavneí PPTP tunelu, kolik povolí.

NAstav si ve vlastnostech PPTP klienta i serveru hodmotu MRRU na 1500 (defualtně je to nenastavneo).

Zdravím,

hledám, kde se to všude nastavuje, mám Winbox, našel jsem jedno MRRU v RB, který buduje spojení PPTP a tam jsem to změnil na 1500. Víc jsem nenašel. Problém trvá.

Dík.

mpcz, 16/03/2013

majklik

Na serverové straně to nastavuje:

/interface pptp-server server set enabled=yes mrru=1600

Na klientské (pokud mám jen jednoho odchozího klienta):

/interface pptp-client set 0 mrru=1600

Když je to pak spojené, tak by jsi ve statusu měl vidět, že používá aktuálně MTU/MRU 1600 místo toho nastaveného MTU/MRU 1460, když to MRRU zafunguje.

mpcz

Na serverové straně to nastavuje:

/interface pptp-server server set enabled=yes mrru=1600

Na klientské (pokud mám jen jednoho odchozího klienta):

/interface pptp-client set 0 mrru=1600

Když je to pak spojené, tak by jsi ve statusu měl vidět, že používá aktuálně MTU/MRU 1600 místo toho nastaveného MTU/MRU 1460, když to MRRU zafunguje.

Zdravím,

ano zabralo to, ale ne úplně, teď proleze 1496 OK, 1497 fragmentuje. Mám dále zvyšovat?

Ještě prosím dotaz, kde se to stejné nastavuje ve Winboxu? Marně hledám. Jsem na Winbox více zvyklý...

Děkuji.

mpcz, 17/03/2013

hafieror

Přiznám se, že marně hledám mě moc nesedí. Když otevřeš okno, kde povoluješ pptp server, tak na tebe kouká pole MRRU a když otevřeš okno pptp klienta, tak na tebe kouká taky MRRU.

mpcz

Přiznám se, že marně hledám mě moc nesedí. Když otevřeš okno, kde povoluješ pptp server, tak na tebe kouká pole MRRU a když otevřeš okno pptp klienta, tak na tebe kouká taky MRRU.

OK, dík, ale já už mám server vytvořený a klienty taky. Takže jsem na to nikde nenarazil. Tak to je vyřešené, jen zbývá dořešit těch 1497. Proč asi zrovna tolik a jak to doladit na 1500?

Nebude to mít negativní vliv někde jinde?

Děkuji.

mpcz, 17/03/2013

majklik

1496 není špatný výsedek, to máš víc, než většina lidfí připojených přes PPPoE (ADSL a podobné). :-)

Když se podíváš na status toho PPTP spojení, kolik ti hlásí MRU/MTU na záložce status? Pokud aspoň těch 1500, tka by to mělo jít (1600 je potřeba při L2 tunelování přes PPP).

Když dáš ten /ping seznam.cz size=1500 do-not-fragment, tak ti to vrací hlášení, že je potřeba fragmentovat. U toho hlášneí vidíš IP adresu, kdo ti to posílá. Podle té hledej, kde to je. Pokud to bude IP toho PPTP klienta, tak to může mít vztah s tím PPTP tunelem (také by pánove v Mikrotiku mohli do ROSu přidat příkaz tracepath nebo přslušně doplnit traceroute).

mpcz

1496 není špatný výsedek, to máš víc, než většina lidfí připojených přes PPPoE (ADSL a podobné). :-)

Když se podíváš na status toho PPTP spojení, kolik ti hlásí MRU/MTU na záložce status? Pokud aspoň těch 1500, tka by to mělo jít (1600 je potřeba při L2 tunelování přes PPP).

Když dáš ten /ping seznam.cz size=1500 do-not-fragment, tak ti to vrací hlášení, že je potřeba fragmentovat. U toho hlášneí vidíš IP adresu, kdo ti to posílá. Podle té hledej, kde to je. Pokud to bude IP toho PPTP klienta, tak to může mít vztah s tím PPTP tunelem (také by pánove v Mikrotiku mohli do ROSu přidat příkaz tracepath nebo přslušně doplnit traceroute).

Zdravím,

provedeno, vyřešeno, vše jede. Teď jen chvíle strachu, jestli to nebude mít nějaké neblahé sekundární vlivy.

Dík za pomoc.

mpcz, 17/03/2013