pmtud问题，请版主过来看看

ssffzz1

首先说说这个吧。第一个问题，我在ISP R2的外出接口配置了ip mtu 1300，如何在linux server上看到该server收到了MTU of next hop: 1276这样的消息呢？
####抓包看ICMP差错报文。

我对pmtud的理解是：Windows和Linux操作系统默认启用了pmtud特性，路由器需要配置ip tcp path-mtu-dis（cisco ios，我在三台路由器上都启用了）。对于小包，触发不了
                                                                                                                        ### （不太清楚这个参数作用，感觉只是针对路由器自身的TCP连接起作用）
pmtud机制，此时没问题；对于大包，还得是tcp包，如果触发了该机制后，若中间某台路由器的mtu比其他的小，那这台路由器会发送相应数据包，告诉后方的路由器，后方路由器一直传输到pc（这里我不知道在路由器上传输df位被设置的数据包是需要特殊的配置还是默认就转发的，请版主对这点赐教一下），数据包传输到pc后，pc自动调整mtu之后再发送数据，就ok了。---我这么理解不是到是否确切？
######再看看PMTU的原理，这个不是依靠大小包来触发的。是建立连接前的一个动作。WIN和LINUX好像默认都不开启。


第二个问题：如果isp在中间的某台路由器上配置了1300的mtu，那我在自己的出口路由器（R3）的那个接口配置ip mtu恰当呢（我不想让数据包被分段）？版主说的是在外部接口配置，只能在外边的接口配置吗？
###MTU的检查是包在出接口的时候进行的。对于接收的包并不检查MTU。因此要配置在出接口。


第三个问题：在路由器连接内网的接口上配置ip tcp adjust-mss 1300之后，pc在和server进行tcp握手的时候是如何得知自己上游路由器的mss的？是这样知道的吗：pc首先和路由器建立tcp连接？
####配置adjust-mss是另外一种情况了。路由器会修改TCP握手时候的MSS协商参数。你两端抓包即可发现。


周日一天就在这个问题上郁闷的度过了 请版主帮忙啊

shichunda

原帖由 ssffzz1 于 2009-12-7 09:46 发表
首先说说这个吧。第一个问题，我在ISP R2的外出接口配置了ip mtu 1300，如何在linux server上看到该server收到了MTU of next hop: 1276这样的消息呢？
####抓包看ICMP差错报文。

您还是说清楚点吧，什么是icmp差错报文啊？如果可以的话，您是否可以上传个.cap文件？

shichunda

我对pmtud的理解是：Windows和Linux操作系统默认启用了pmtud特性，路由器需要配置ip tcp path-mtu-dis（cisco ios，我在三台路由器上都启用了）。对于小包，触发不了
                                                                                                                        ### （不太清楚这个参数作用，感觉只是针对路由器自身的TCP连接起作用）
pmtud机制，此时没问题；对于大包，还得是tcp包，如果触发了该机制后，若中间某台路由器的mtu比其他的小，那这台路由器会发送相应数据包，告诉后方的路由器，后方路由器一直传输到pc（这里我不知道在路由器上传输df位被设置的数据包是需要特殊的配置还是默认就转发的，请版主对这点赐教一下），数据包传输到pc后，pc自动调整mtu之后再发送数据，就ok了。---我这么理解不是到是否确切？
######再看看PMTU的原理，这个不是依靠大小包来触发的。是建立连接前的一个动作。WIN和LINUX好像默认都不开启。

再看看PMTU的原理，这个不是依靠大小包来触发的。

先不说这个，我昨晚上抓了几个包，看到了如下的结果“
拓扑图是pc---(f0/1)R3
pc的ip为192.168.1.199，R3的fa0/1的ip是192.168.1.200

1 当只在R3和pc连接的接口上(f0/1)配置r3(config-if)#ip tcp adjust-mss 900时，在抓包时看到的syn包中

的mss是1260！！！---1.pcap,第7、8个包

2 在R3和pc连接的接口上配置r3(config-if)#ip tcp adjust-mss 900和ip mtu 940的时候，在抓包时看到的

syn中的mss是900！！！---2.pcap，第8、9个包

3 在R3和pc连接到接口上配置r3(config-if)#ip mtu 940的时候，抓包看到的syn中的mss是900！！！---

3.pcap，第7、8个包

结论：ip tcp adjust-mss到底管不管用？？？ip mtu是管用的！！！


个人感觉：pc---router---server的时候pc要和server建立tcp连接，他们协商的mss是1300，如果中间路由器

配置的mss是1000的话，连接应该建立不成功，就是说pc和server之间的tcp连接也要求router开一个tcp端口并

且这三者一起协商mss，扩大点来说，在internet上的pc要和一个server建立tcp连接时，中间isp的所有路由器

，每个路由器都需要建立tcp连接，并且每个路由器配置的mss要大于pc和server协商的mss！！！---不知道这

样理解对否。”

另外我看文档上说win和linux默认好像都是开启pmtud的，看看附件pdf还有图片

shichunda

忘了添加cap文件了

shichunda

第三个问题：在路由器连接内网的接口上配置ip tcp adjust-mss 1300之后，pc在和server进行tcp握手的时候是如何得知自己上游路由器的mss的？是这样知道的吗：pc首先和路由器建立tcp连接？
####配置adjust-mss是另外一种情况了。路由器会修改TCP握手时候的MSS协商参数。你两端抓包即可发现。

这个问题也先放放，先讨论一下抓包文件的怪异现象吧

testvpn

通常来说，MTU=MSS+20+20，2个20是对应TCP和IP的报头，所以你改了MTU，MSS就自动变了

ssffzz1

ip tcp adjust-mss

这个好像对穿越路由器的起作用。

testvpn

路由器是转发SYN包的时候偷偷把MSS给改了
两端都是以对方发过来的MSS发包的

比如客户端的MSS是1460，过路由器被改成1200了，服务器收到的是1200，而服务器端返回的SYN中MSS是1460，所以客户端可以发送1500大小的包，而服务器返回的时候只能返回1240的包，因为对端的MSS是1200
都是以对端的MSS来发包的

testvpn

他们没有协商mss，这个不是用来协商的，当你看到对端mss是1200的时候，你记下就行了，以后别发大于1200的包就行了。
你自己还是要给对方发送你自己的mss，该是1460还是1460.

当然这是我试验得出来的结论，不是书上看的

shichunda

能说明一下你的实验过程以及配置参数吗？