為什么GRE隧道的TCP MSS也要設置1436？.doc

由于GRE是將一個數(shù)據(jù)包封裝到另一個數(shù)據(jù)包中，因此你可能會遇到GRE的數(shù)據(jù)報大于網(wǎng)絡接口所設定的數(shù)據(jù)包最大尺寸的情況。接近這種問題的方法是在隧道接口上配置ip tcp adjust-mss 1436。 另外，雖然GRE并不支持加密，但是你可以通過tunnel key命令在隧道的兩頭各設置一個密鑰。這個密鑰其實就是一個明文的密碼。 由于GRE隧道沒有狀態(tài)控制，可能隧道的一端已經(jīng)關閉，而另一端仍然開啟。這一問題的解決方案就是在隧道兩端開啟keepalive數(shù)據(jù)包。它可以讓隧道一端定時向另一端發(fā)送keepalive數(shù)據(jù)，確認端口保持開啟狀態(tài)。如果隧道的某一端沒有按時收到keepalive數(shù)據(jù)，那么這一側的隧道端口也會關閉。-以下是GRE Tunnel MSS設置的幾個例子In the diagram above, when the Client wants to access a page on the Internet, it establishes a TCP session with the Web Server. During this process, the Client and Web Server announce their maximum segment size (MSS), indicating to each other that they can accept TCP segments up to this size. Upon receiving the MSS option, each device calculates the size of the segment that can be sent. This is called the Send Max Segment Size (SMSS), and it equals the smaller of the two MSSs. For more information about TCP Maximum Segment Size, see RFC 879 .For the sake of argument, lets say the Web Server in the example above determines that it can send packets up to 1500 bytes in length. It therefore sends a 1500 byte packet to the Client, and, in the IP header, it sets the dont fragment (DF) bit. When the packet arrives at R2, the router tries encapsulating it into the tunnel packet. In the case of the GRE tunnel interface, the IP maximum transmission unit (MTU) is 24 bytes less than the IP MTU of the real outgoing interface. For an Ethernet outgoing interface that means the IP MTU on the tunnel interface would be 1500 minus 24, or 1476 bytes.R2 is trying to send a 1500 byte IP packet into a 1476 byte IP MTU interface. Since this is not possible, R2 needs to fragment the packet, creating one packet of 1476 bytes (data and IP header) and one packet of 44 bytes (24 bytes of data and a new IP header of 20 bytes). R2 then GRE encapsulates both of these packets to get 1500 and 68 byte packets, respectively. These packets can now be sent out the real outbound interface, which has a 1500 byte IP MTU.However, remember that the packet received by R2 has the DF bit set. Therefore, R2 cant fragment the packet, and instead, it needs to instruct the Web Server to send smaller packets. It does this by sending an Internet Control Message Protocol (ICMP) type 3 code 4 packet (Destination Unreachable; Fragmentation Needed and DF set). This ICMP message contains the correct MTU to be used by the Web Server, which should receive this message and adjust the packet size accordingly.Note: Refer to Important Information on Debug Commands before you use debug commands.We can view the ICMP messages sent by R2 by enabling the debug ip icmp command:ICMP: dst (10.10.10.10) frag. needed and DF set unreachable sent to 10.1.3.4Blocked ICMP MessagesA common problem occurs when ICMP messages are blocked along the path to the Web server. When this happens, the ICMP packet never reaches the Web server, thereby preventing data from passing between client and server.SolutionsOne of these four solutions should solve the problem.o Find out where along the path the ICMP message is blocked, and see if you can get it allowed.o Set the MTU on the Clients network interface to 1476 bytes, forcing the SMSS to be smaller, so packets wont have to be fragmented when they reach R2. However, if you change the MTU for the Client, you should also change the MTU for all devices that share the network with this Client. On an Ethernet segment, this could be a large number of devices.o Use a proxy-server (or, even better, a Web cache engine) between R2 and the Gateway router, and let the proxy-server request all the Internet pages.o If the GRE tunnel runs over links that can have an MTU greater than 1500 bytes plus the tunnel header, then another solution is to increase the MTU to 1524 (1500 plus 24 for the GRE overhead) on all interfaces and links between the GRE endpoint routers.Further SolutionsIf the above options are not feasible then the following options may be useful.o Use policy routing to clear and set the DF bit in the data IP packet (available in Cisco IOS?/SUP release 12.1(6) and higher).o interface ethernet0 o . o ip policy route-map clear-df o !- This command is used to identify a route map o !- to use for policy routing on an interface, o !- use the ip policy route-map command in o !- interface configuration mode. o route-map clear-df permit 10 o match ip address 101 o set ip df 0 o !- This command is used to change the Dont Fragment (DF) o !- bit value in the IP header, use this command o !- in route-map configuration mode.access-list 101 permit tcp 10.1.3.0 0.0.0.255 anyThis will allow the data IP packet to be fragmented before it is GRE encapsulated. The receiving end host must then reassemble the data IP packets. This is usually not a problem.o Change the TCP MSS option value on SYN packets that traverse through the router (available in IOS 12.2(4)T and higher). This reduces the MSS option value in the TCP SYN packet so that its smaller than the value in the ip tcp adjust-mss value command, in this case 1436 (MTU minus the size of the IP, TCP, and GRE headers). The end hosts now send TCP/IP packets no larger than this value.o interface tunnel0 o . o ip tcp adjust-mss 1436 o !- This command is used to adjust the maximum segment size (MSS) o !- value of TCP SYN packets going through the router. o !- The maximum segment size is in the range from 500 to 1460.o A final option is to increase the IP MTU on the tunnel interface to 1500 (available in IOS 12.0 and higher). However, increasing the tunnel IP MTU causes the tunnel packets to be fragmented because the DF bit of the original packet is not copied to the tunnel packet header. In this scenario, the router on the other end of the GRE tunnel must reassemble the GRE tunnel packet before it can remove the GRE header and forward the inner packet. IP packet reassembly is done in process-switch mode and uses memory. Therefore, this option can significantly reduce the packet throughput through the GRE tunnel.o interface tunnel0 . ip mtu 1500!- This command is used to set the maximum transmission unit (MTU)!- size of IP packets sent on an interface. The minimum size o !- you can configure is 128 bytes; the maximum depends on the interface medium.In conclusion, the most common cause of not being able to browse the Internet over a GRE tunnel is due to the above mentioned fragmentation issue. The solution is to allow the ICMP packets or work around the ICMP problem with any of the above solutions.-背景知識MTU: Maxitum Transmission Unit 最大傳輸單元MSS: Maxitum Segment Size 最大分段大?。ㄅ际侵弊g，翻譯的不好，不要打俺PP）PPPoE: PPP Over Ethernet（在以太網(wǎng)上承載PPP協(xié)議）分析過程先說說這MTU最大傳輸單元，這個最大傳輸單元實際上和鏈路層協(xié)議有著密切的關系，讓我們先仔細回憶一下EthernetII幀的結構DMAC+SMAC+Type+Data+CRC由于以太網(wǎng)傳輸電氣方面的限制，每個以太網(wǎng)幀都有最小的大小64bytes最大不能超過1518bytes，對于小于或者大于這個限制的以太網(wǎng)幀我們都可以視之為錯誤的數(shù)據(jù)幀，一般的以太網(wǎng)轉發(fā)設備會丟棄這些數(shù)據(jù)幀。（注：小于64Bytes的數(shù)據(jù)幀一般是由于以太網(wǎng)沖突產(chǎn)生的“碎片”或者線路干擾或者壞的以太網(wǎng)接口產(chǎn)生的，對于大于1518Bytes的數(shù)據(jù)幀我們一般把它叫做Giant幀，這種一般是由于線路干擾或者壞的以太網(wǎng)口產(chǎn)生）由于以太網(wǎng)EthernetII最大的數(shù)據(jù)幀是1518Bytes這樣，刨去以太網(wǎng)幀的幀頭（DMAC目的MAC地址48bit=6Bytes+SMAC源MAC地址48bit=6Bytes+Type域2bytes）14Bytes和幀尾CRC校驗部分4Bytes（這個部門有時候大家也把它叫做FCS），那么剩下承載上層協(xié)議的地方也就是Data域最大就只能有1500Bytes這個值我們就把它稱之為MTU。這個就是網(wǎng)絡層協(xié)議非常關心的地方，因為網(wǎng)絡層協(xié)議比如IP協(xié)議會根據(jù)這個值來決定是否把上層傳下來的數(shù)據(jù)進行分片。就好比一個盒子沒法裝下一大塊面包，我們需要把面包切成片，裝在多個盒子里面一樣的道理。當兩臺遠程PC互聯(lián)的時候，它們的數(shù)據(jù)需要穿過很多的路由器和各種各樣的網(wǎng)絡媒介才能到達對端，網(wǎng)絡中不同媒介的MTU各不相同，就好比一長段的水管，由不同粗細的水管組成（MTU不同）通過這段水管最大水量就要由中間最細的水管決定。對于網(wǎng)絡層的上層協(xié)議而言（我們以TCP/IP協(xié)議族為例）它們對水管粗細不在意它們認為這個是網(wǎng)絡層的事情。網(wǎng)絡層IP協(xié)議會檢查每個從上層協(xié)議下來的數(shù)據(jù)包的大小，并根據(jù)本機MTU的大小決定是否作“分片”處理。分片最大的壞處就是降低了傳輸性能，本來一次可以搞定的事情，分成多次搞定，所以在網(wǎng)絡層更高一層（就是傳輸層）的實現(xiàn)中往往會對此加以注意！有些高層因為某些原因就會要求我這個面包不能切片，我要完整地面包，所以會在IP數(shù)據(jù)包包頭里面加上一個標簽：DF（Donot Fragment）。這樣當這個IP數(shù)據(jù)包在一大段網(wǎng)絡（水管里面）傳輸?shù)臅r候，如果遇到MTU小于IP數(shù)據(jù)包的情況，轉發(fā)設備就會根據(jù)要求丟棄這個數(shù)據(jù)包。然后返回一個錯誤信息給發(fā)送者。這樣往往會造成某些通訊上的問題，不過幸運的是大部分網(wǎng)絡鏈路都是MTU1500或者大于1500。對于UDP協(xié)議而言，這個協(xié)議本身是無連接的協(xié)議，對數(shù)據(jù)包的到達順序以及是否正確到達不甚關心，所以一般UDP應用對分片沒有特殊要求。對于TCP協(xié)議而言就不一樣了，這個協(xié)議是面向連接的協(xié)議，對于TCP協(xié)議而言它非常在意數(shù)據(jù)包的到達順序以及是否傳輸中有錯誤發(fā)生。所以有些TCP應用對分片有要求-不能分片（DF）?；ㄩ_兩朵，各表一枝，說完MTU的故事我們該講講今天的第二個豬腳-PPPoE所謂PPPoE就是在以太網(wǎng)上面跑PPP協(xié)議，有人奇怪了，PP