一个MSS参数引发的“血案”
最近在玩一些淘汰下来的FW,在马云家淘了一些二手的玩玩,在家搭建了一台zabbix监控,配置了onealert的免费通知插件(支持微信、QQ、邮件、短信、电话等),用来监控我家小PP看动画片时长,时间过长就要远程断网或shutdown交换机接口,因为当着面关他电视后果很严重,断他网他会知道是“坏了”,没那么闹腾。
专注于为中小企业提供成都网站设计、成都做网站、外贸网站建设服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业额敏免费做网站提供优质的服务。我们立足成都,凝聚了一批互联网行业人才,有力地推动了1000+企业的稳健成长,帮助中小企业通过网站建设实现规模扩充和转变。
回到正题,以前一直用无线路由器做NAT转发,发现即使是cisco 6900和网件R 7000等千元路由器级别都会用到死机。后来帮别人做项目发现juniper ssg和SRX这种企业级的FW在某宝只要几百元,果断出手搞了一些不同型号来测试。
本文的主角:JUNIPER SRX 210H正式登场
当我用210配置完PPPOE后,部分网站可以打开,部分网站打不开,并且在JUNIPER SSG5上面没有这个问题,所以断定问题在210上。排错思路如下:
一、检查PPPOE链路状态
看起来正常
admin@YY-SRX100H#run show interfaces pp0
Physical interface: pp0, Enabled, Physical link is Up
Interface index: 128, SNMP ifIndex: 501
Type: PPPoE, Link-level type: PPPoE, MTU: 1532
Device flags : Present Running
Interface flags: Point-To-Point SNMP-Traps
Link type : Full-Duplex
Link flags : None
Input rate : 232 bps (0 pps)
Output rate : 0 bps (0 pps)
Logical interface pp0.0 (Index 79) (SNMP ifIndex 563)
Flags: Point-To-Point SNMP-Traps 0x0 Encapsulation: PPPoE
PPPoE:
State: SessionUp, Session ID: 34772,
Session AC name: SZ-BJ-BAS-5.MAN.NE40E, Remote MAC address: da:86:8e:6c:00:19,
Configured AC name: None, Service name: None,
Auto-reconnect timeout: 10 seconds, Idle timeout: Never,
Underlying interface: fe-0/0/1.0 (Index 78)
Input packets : 24
Output packets: 16
Keepalive settings: Interval 10 seconds, Up-count 1, Down-count 3
Keepalive: Input: 3 (00:00:08 ago), Output: 7 (00:00:01 ago)
LCP state: Opened
NCP state: inet: Opened, inet6: Not-configured, iso: Not-configured, mpls: Not-configured
CHAP state: Closed
PAP state: Success
Security: Zone: Null
Protocol inet, MTU: 1492
Flags: Sendbcast-pkt-to-re, User-MTU, Negotiate-Address
Addresses, Flags: Kernel Is-Preferred Is-Primary
Destination: 183.12.26.1, Local: 183.12.26.79
二、检查区域和策略
也都正常,策略全放开
三、根据网上的建议调整MTU为1400
然并卵,问题依旧
set interfaces pp0 unit 0 family inet mtu 1400
四、根据度娘搜遍了大量相关的蛛丝马迹,发现一个很少有人问津的tcp-mss参数调整
凭借我多年运维的经验直觉告诉我,真相很快就要浮出水面了。
The maximum segment size (MSS) is a parameter of the options field of the TCP header that specifies the largest amount of data, specified in bytes, that a computer or communications device can receive in a single TCP segment. It does not count the TCP header or the IP header.[1] The IP datagram containing a TCP segment may be self-contained within a single packet, or it may be reconstructed from several fragmented pieces; either way, the MSS limit applies to the total amount of data contained in the final, reconstructed TCP segment.
To avoid fragmentation in the IP layer, a host must specify the maximum segment size as equal to the largest IP datagram that the host can handle minus the IP header size and TCP header sizes.[2] Therefore, IPv4 hosts are required to be able to handle an MSS of 536 octets (= 576[3] - 20 - 20) and IPv6 hosts are required to be able to handle an MSS of 1220 octets (= 1280[4] - 40 - 20).
Small MSS values will reduce or eliminate IP fragmentation, but will result in higher overhead.[5]
Each direction of data flow can use a different MSS.
For most computer users, the MSS option is established by the operating system.
上面一段话其实简要概之就是,它和TCP有关。。。也别太较真了
于是乎就抱着试一试的态度,结果之前打不开的网页都能打开了
set security flow tcp-mss all-tcp mss 1350
五、pppoe全部配置参考本人以下博文
http://yangye.blog.51cto.com/922715/1874180
本文名称:一个MSS参数引发的“血案”
当前路径:http://azwzsj.com/article/ihsiog.html