Jaderné noviny – 1. 10. 2014: Foo přes UDP (diskuse)

[první]

767 přečtení a zatím žádný první komentář?

[Petr Ježek]

Obrázek (ne)znalostí obecenstva. Jinak by se to tu hemžilo komentáři k síťové bezpečnosti.

[Jiří J.]

Může mi někdo prosím ujasnit smysl ip-fou? Proč se nenastavují oba endpointy jako IPIP s UDP enkapsulací, stejně jako to máme u gre/gretap/sit/..?

Dovedu si představit zjednoduššení klientské části, ale není to pak jen snadná náplast pro "složitost" použití IPIP rozhraní? Jak se klient pak má vypořádat s více tunnely od různých serverů (nebo různých portů stejného serveru)?

Chápu význam samotné UDP enkapsulace a použití nad libovolným tunnelem, jen nechápu nutnost "ip fou".

Díky.

[Michal Kubeček]

Může mi někdo prosím ujasnit smysl ip-fou? Proč se nenastavují oba endpointy jako IPIP s UDP enkapsulací, stejně jako to máme u gre/gretap/sit/..?

Můžete trochu rozvést, co konkrétně tím myslíte?

Jak se klient pak má vypořádat s více tunnely od různých serverů (nebo různých portů stejného serveru)?

V čem konkrétně vidíte problém?

[Jiří J.]

Můžete trochu rozvést, co konkrétně tím myslíte?

(níže se odkazuji na původní mail)

Konkrétně nechápu rozdělení na "RX" a "TX" části, kdy se každá konfiguruje jinak. Např. klasický IPIP tunel se konfiguruje jako:

strojA$ ip link add tunel type ipip remote 2.2.2.2 local 1.1.1.1
strojB$ ip link add tunel type ipip remote 1.1.1.1 local 2.2.2.2

A to je vše. Jednoduchá enkapsulace přidáním jedné IP hlavičky.

Pokud jsem dobře pochopil, rychlostní benefity odkazovaného patchsetu spočívají v tom, že routery/switche/síťovky počítají s tím, že nad IP je buď TCP nebo UDP, ale ne už další IP - fungovat budou, ale nebudou asi moci použít hardwarové optimalizace. Řešením je tedy zabalit provoz do ještě jedné UDP hlavičky - to bych si představoval jako (cca):

strojA$ ip link add tunel type ipip remote 2.2.2.2 local 1.1.1.1 \
          encap udp encap-sport 1111 encap-dport 2222
strojB$ ip link add tunel type ipip remote 1.1.1.1 local 2.2.2.2
          encap udp encap-sport 2222 encap-dport 1111

Má otázka tedy je - proč se to neudělalo takto jednodušše? Proč se přidávalo celé nové API pro iproute2 s vlastní sadou příkazů?

V čem konkrétně vidíte problém?

Když si čtu původní článek znovu, nedochází mi, proč by "ip fou" měl vůbec existovat. Chápu myšlenku odstranění enkapsulace a vražení zpět do síťového stacku, ale nechápu použití. Proč tu enkapsulaci nedovede rozbalit kód tunelu? Původní email se zmiňuje, že to rozbalení dělá XFRM, tak proč nebylo použito rozhraní ip-xfrm?

Nevím, přijde mi to jako příliš nepodstatný a primitivní "hack" na to, aby měl vlastní API. Nebo se mi naopak líbí ten jednoduchý nápad a nechápu, proč je implementace limitována na IPIP - např. na několika místech používám gretap a zvýšení výkonu enkapsulací do UDP bych uvítal.

Díky.

[Petr Ježek]

"Added 'ip fou...' commands to enable/disable UDP ports for doing foo-over-udp and Generic UDP Encapsulation variant. Arguments are port number to bind to and IP protocol to map to port (for direct FOU)." Je tam i celý patch, který říká vše.

[Michal Kubeček]

Sice mi to vzalo trochu času, naučil jsem se ale jednu cennou techniku ladění:

 #undef EINVAL
 #define EINVAL __LINE__

To by nesměly být v jádře soubory, které mají víc než 4095 (MAX_ERRNO) řádků.

[mmmmario]

Říká se UDP paket nebo UDP datagram?

[Michal Kubeček]

Oboje. :-)

Purista by asi používal paket pro označení celého IP paketu s UDP protokolem a datagram pro samotnou UDP hlavičku a payload, ale ono je to většinou jedno. Buď je to jasné z kontextu nebo je stejně lepší explicitně napsat, co má člověk na mysli.