On Jan 24, 2014, at 6:02 PM, Nick Cammorato <[email protected]> wrote:
> It's 1500 on both sides of the p2p between the SRX and the ASA. Wouldn't I > see fragmentation if it was an MTU problem? I had that a little wrong, but if you were setting the don’t fragment bit in your IP header for MTU discovery, you wouldn’t see fragments. But I was wrong anyway: as it turns out, Juniper advises on TCP-MSS value, not MTU. The document linked slow appears to have some more troubleshooting information, but I called this out in a spirit of crossing every eye and dotting every tee. <http://kb.juniper.net/library/CUSTOMERSERVICE/technotes/3500176-EN.PDF> > Configure Tcp-mss to Eliminate Fragmentation of TCP Traffic Across Tunnel > set security flow tcp-mss ipsec-vpn mss 1350 > Tcp-mss is negotiated as part of the TCP 3-way handshake. It limits the > maximum size of a TCP segment to better fit > the maximum transmission unit (MTU) limits on a network. This is especially > important for VPN traffic, as the IPsec > encapsulation overhead along with the IP and frame overhead can cause the > resulting Encapsulating Security Payload > (ESP) packet to exceed the MTU of the physical interface, thus causing > fragmentation. Fragmentation increases > bandwidth and device resources and is always best avoided. Note that the > value of 1350 is a recommended starting > point for most Ethernet-based networks with an MTU of 1,500 or greater. This > value may need to be altered if any > device in the path has lower MTU, or if there is any added overhead such as > Point-to-Point Protocol (PPP), Frame > Relay, etc. As a general rule, you may need to experiment with different > tcp-mss values to obtain optimal performance _______________________________________________ bblisa mailing list [email protected] http://www.bblisa.org/mailman/listinfo/bblisa
