Witam!
Zastanawiam się nad ustawieniem optymalnej wartości MSS pod tunelem GRE.
Z moich wyliczeń wynika, że MSS przy MTU=1500 dla maksymalnych nagłówków IP powinno wynosić 1352:
[Max IP Source/Destination GRE] [GRE Hdr] [Max IP Hdr Original] [Max TCP Hdr]
60B 8B 60B 20B
MSS=MTU - (60+8+60+20) = 1352
Czy ma ktoś inną koncepcję? Proszę o propozycje.
ip tcp adjust-mss - optymalna wartość MSS dla tunelu GRE
Troszke za malo. To co musisz odjac od nominalnej wartosci MTU = 1500 bytes, to naglowek TCP/IP (40 bytes) oraz naglowek GRE/IP (24 bytes). Lacznie do odjecia jest 64 bytes. Wystarczy wiec przyjac MSS = 1436 bytes.
Wiecej o tej tematyce oraz sposobach ominiecia fragmentacji w tunelu znajdziesz pod ponizszymi linkami:
1. http://www.cisco.com/warp/public/105/56.html
2. http://www.cisco.com/warp/public/105/pmtud_ipfrag.html
Wiecej o tej tematyce oraz sposobach ominiecia fragmentacji w tunelu znajdziesz pod ponizszymi linkami:
1. http://www.cisco.com/warp/public/105/56.html
2. http://www.cisco.com/warp/public/105/pmtud_ipfrag.html
Podałeś wartości dla nagłówków standardowych bez żadnych opcji, z tymi wartościami się zgodzę, ale dlaczego podałeś, że GRE/IP ma 24B?gangrena pisze:Troszke za malo. To co musisz odjac od nominalnej wartosci MTU = 1500 bytes, to naglowek TCP/IP (40 bytes) oraz naglowek GRE/IP (24 bytes). Lacznie do odjecia jest 64 bytes. Wystarczy wiec przyjac MSS = 1436 bytes.
Na podstawie tego RFC stwierdzam, że nagłówek GRE ma 8B http://www.ietf.org/rfc/rfc2784.txt
Więc w sumie GRE/IP = 16B
Jeśli to tylko tunel (bez firewalli po drodze) o wiele wlaściwszym rozwiązaniem jest ustawienie ip mtu na tunelu i pozostawienie czarnej roboty PMTUD. Jeśli są FWle po drodze, to dodatkowo przepuszczenie ICMP 3/4 i problem z głowy. Rozwiązanie lepsze bo dla całej rodziny TCP/IP, nie tylko do TCP.
http://jelonek.info/ccie.pl/GRE_pure.jpg
http://jelonek.info/ccie.pl/GRE_SEQ_KEY.JPG
PJ
Tak i nie, jest kilka RFC dot. GRE. Jedno z nich przewiduje GRE 4B i takiego właśnie używa cisco. ;)nowy pisze:Na podstawie tego RFC stwierdzam, że nagłówek GRE ma 8B
http://jelonek.info/ccie.pl/GRE_pure.jpg
http://jelonek.info/ccie.pl/GRE_SEQ_KEY.JPG
PJ
Wyjasnienie tego, ze naglowek GRE ma 4 bajty moze byc troszke inne w tym przypadku. Otoz Cisco korzysta z implementacji GRE wedlug RFC 2784, co potwierdza chocby ten link opisujacy bugi: http://www.cisco.com/en/US/tech/tk827/t ... 2cd7b.html.
Jednak pola Checksum oraz Reserved sa opcjonalne, a ponadto wystepuja jedynie wowczas, gdy pierwszy bit Checksum Present jest ustawiony na 1.
Pjeter ma na pewno racje w tym, ze generalnie wszystko zalezy od implementacji danego producenta. Ktos kto robi GRE wedlug RFC 1701 lub RFC 2890 moze sprawic, ze naglowek bedzie mial nawet odpowiednio 20 i 16 bajtow.
Podobnie z naglowkiem IP, ktory standardowo ma 20 bajtow. Lacznie z GRE bedzie zatem 24 bajty.
Jednak pola Checksum oraz Reserved sa opcjonalne, a ponadto wystepuja jedynie wowczas, gdy pierwszy bit Checksum Present jest ustawiony na 1.
Pjeter ma na pewno racje w tym, ze generalnie wszystko zalezy od implementacji danego producenta. Ktos kto robi GRE wedlug RFC 1701 lub RFC 2890 moze sprawic, ze naglowek bedzie mial nawet odpowiednio 20 i 16 bajtow.
Podobnie z naglowkiem IP, ktory standardowo ma 20 bajtow. Lacznie z GRE bedzie zatem 24 bajty.
OK! Zgodzę się z wartością MSS=1436.
Pójdźmy dalej.
Pakiety GRE zamierzam następnie zaszyfrować w trybie tunelowym.
Używam następujących parametrów IPSec:
ESP-3DES
ESP-SHA-HMAC
Cisco stwierdza, iż overhead ESP nie powinien przekroczyć 58B (w tym 20B na nowy nagłówek IP). Na tej podstawie MSS powinno wynosić: 1378B.
Proszę o potwierdzenie.
Pójdźmy dalej.
Pakiety GRE zamierzam następnie zaszyfrować w trybie tunelowym.
Używam następujących parametrów IPSec:
ESP-3DES
ESP-SHA-HMAC
Cisco stwierdza, iż overhead ESP nie powinien przekroczyć 58B (w tym 20B na nowy nagłówek IP). Na tej podstawie MSS powinno wynosić: 1378B.
Proszę o potwierdzenie.
W przypadku IPSec lepiej byloby juz skorzystac z PMTUD, gdyz zmienny padding sprawia, iz dlugosc naglowka jest rowniez zmienna. Aczkolwiek nie zawsze PMTUD zadziala. Czasem trzeba skorzystac z innego rozwiazania. Pod linkiem, ktory podawalem wczesniej: http://www.cisco.com/warp/public/105/pm ... .html#more, znajdziesz taki oto fragment:
Cisco na tej samej stronie zaleca MTU=1400 zarowno dla GRE+IPSec (Transport Mode), jak i GRE+IPSec (Tunnel Mode), a wiec MSS=1360. W ramach testow moze uruchomic pinga z opcja "sweep range of sizes" oraz DF=1. Porownasz w ten sposob swoj rezultat z tym co podaje Cisco.Increase the "ip mtu" on the GRE tunnel interface to be equal to the outbound interface MTU. This will allow the data IP packet to be GRE encapsulated without fragmenting it first. The GRE packet will then be IPsec encrypted and then fragmented to go out the physical outbound interface. In this case you would not configure tunnel path-mtu-discovery command on the GRE tunnel interface. This can dramatically reduce the throughput because IP packet reassembly on the IPsec peer is done in process-switching mode.