classic.ISPforum.cz

ahoj, nevím jeslti nedělám něco špatně ale nijak nevidím hodnotu max l2 mtu na síťovkách, který mám na x86 storojích a to má za následek že tam neprocpu například VPLS, je to nějaká chyba a nebo normální stav? nemá se třeba někde něco nastavit aby to fungovalo? síťovky jsou na sezanmu podporovaného HW od MK, tak tonechápu. jediné kde to funguje síťovka přímo od MK, ta ale bohužel není nic moc. nedovedu si představit že velké firmy který používají vpls jsou omezeni pouze na MK síťovky...

Díky

Mx L2MTU nevidíš možná proto, že neexistuje jednotný způsob, jak to ze síťovky načíst, tak se to o to ROS nesnaží. U jejich síťovky to vidíš, protože ji zná a ukáže hodnotu, co má ROS v sobě pro ni namlácenou.
Když zkusíš jumbo paket použít, tak to ROS zkusí a v závislosti na driveru to buď funguje nebo hodně často nefunguje (respektive funguje jen jedním směrem, že dlouhé pakety jdou odesílat, ale nejdou přijímat, případně naopak...).

OK, díky a je tedy vůbec nějaký seznam karet které jdou použít pro VPLS?

No, ona platforma X86 špatně nese ten L2MTU koncept, kdy L2MTU mám posunuté a MTU přitom 1500. Mělo by fungovat na nějakých VIA chipsetech.

Jinak ojebávka je tak, že nenastavíš na 1524 L2MTU, ale přímo MTU, pak by to na většině síťovek mělo jek por VPLS/MPLS OK.
ALE, má to jedno velké ALE (jak je všeobecným dobrým zvykem v ROSu). Pokud na X86 posuneš MTU 1524, tak stejně musíš posunout všechny další zařízení na tom L2 segmentu, jinak budou problémy, a to včetně OSPF na tom segmentu, který začně hnedka řvát, že jeden router hlásí MTU1524 a já mám MTU1500, takže nebudu fungovat. Ano, opět tu chybí v ROSu ta krásná Cisco like volba "ospf mtu-ignore" - můžeš žhavit support s feature request.

tak to mi torchu vytáhlo trn z paty jen mě napadá proč tenkrát jak jsme to zkoušeli na té atom bráně x86 jsme to tak neudělali

Protože je to dost zákeřné. Opravdu musíš důsledně tu MTU nastavit stejně na všem na tom L2 segmentu, včetně VLAN. Jak na něco zapomeneš, tak krom toho složeného OSPF (což je pak dobrá detekce, že někde je to špatně), tak se záhadně ztrácí data a pak koukáš jak vejr. Problém dělá provoz, co na tom X86 vzniká a míří do segmentu, na kterém dáš to MTU 1524. Pokud bude mířit na počítač, který MTU 1524 (bude např na klasických 1500) nebude mít nastaven, tak příchozí paket delší 1500 obvykle zahodí v tichosti a máš smůlu. Pak se tam budeš snažit připojit pomocí něčeho, co posílá jen krátké pakety a budeš se modlit, aby ti to neposlao paket 1500+, čímž to spojení záhadně odumře. Forwardovaný provoz, který příšel odjinud a příchází už zařezán n MTU1500 spokojeně prochází, jenom s tím X86 routerem se najednou nemůžeš bavit....
Takže to chce domyslet, co vše tma je a dodržet tu MTU kázeň.

Možná by to šlo ojebat pomocí SW bridge, aby jsi nemusel MTU1524 pro provoz nastavovat v celém tom segmentu, Síťovce dáš MTU1524, ale uděláš bidge, kterému nastavíš ručně MTU1500 a vše honíš nad tím bridge (IP, OSPF, VLANy, MPLS, ...), místo přímo síťovky. Tím by jsi asi dosáhl, že máš pro normální věci MTU1500 a síťovka přitom pustí 1524 a nerozbíjet celý segment. V podstatě se podobná ojebávka dělá třeba kvůli bond rozhraním, asi by to mohlo jít přímo i se síťovkou, takže variace na:
/interface bonding
add lacp-rate=1sec mii-interval=250ms mode=802.3ad mtu=1512 name=bond-area0 slaves=ether5,ether10
/interface bridge
add admin-mac=02:00:00:00:01:11 auto-mac=no mtu=1500 name=bridge-area0 protocol-mode=none
/interface bridge port
add bridge=bridge-area0 interface=bond-area0
/interface vlan
add arp=disabled interface=bridge-area0 name=vl-wifi-usr vlan-id=166
/mpls ldp interface
add interface=bridge-area0
add interface=vl-wifi-usr
....

Nicméně pořád platí, že některé karty v X86 ROSu nesnesou korektně MTU nad 1500, zvláště v kombinaci v VLAN tagy.