06-27-2006 03:13 AM - edited 03-03-2019 01:08 PM
I have a dual homed AS using to eBGP connections, through one of the connections I can access hotmail.com but through the other link I can't access the hotmail.com unless I change the MTU in users PCs or in the PROXY server.
If one have any experience or justification please reply.
Solved! Go to Solution.
06-27-2006 06:05 AM
Osama
These symptoms sound like Path MTU Discovery is working through one provider and is not working through the other provider. The basis of PMTUD is to send a packet and to look for a response of ICMP "fragmentation required but DF set" which informs the end stations that they need to use a smaller frame.
If the end station is sending through the provider where PMTUD is working then the end station will dynamically find out that it needs to use smaller packets, it does so, and the application works. If the end station is sending through the other provider then it does not receive the ICMP error and does not know that it needs to use smaller packets, keeps sending large packets which get dropped, and the application does not work until you configure the end station for smaller MTU.
The most common reason for PMTUD to not work is that someone is filtering and denying the ICMP error messages. I would guess that the second provider (or someone you go through from the second provider) is filtering ICMP and that this is the cause of your problem.
Many people believe that there is some risk in ICMP (especially to/from outside their network) and filter ICMP. This is one example of why filtering all ICMP is frequently not a good idea.
HTH
Rick
06-27-2006 06:02 AM
Hi,
looks MTU along one path is not 1500 Bytes but less. In case too large IP packets with DF bit set are encountered they will be dropped. This might or might not be within your network.
To solve the problem enable TCP path-mtu-discovery in your client PCs and in the PROXY (can be done through registry (f.e. with a program called DrTCP).
Or you set the TCP MSS to a lower value in the router, f.e.:
R(config)# ip tcp mss-adjust 1400
This should solve your problems.
Hope this helps! Please rate all posts.
Regards, Martin
06-27-2006 06:05 AM
Osama
These symptoms sound like Path MTU Discovery is working through one provider and is not working through the other provider. The basis of PMTUD is to send a packet and to look for a response of ICMP "fragmentation required but DF set" which informs the end stations that they need to use a smaller frame.
If the end station is sending through the provider where PMTUD is working then the end station will dynamically find out that it needs to use smaller packets, it does so, and the application works. If the end station is sending through the other provider then it does not receive the ICMP error and does not know that it needs to use smaller packets, keeps sending large packets which get dropped, and the application does not work until you configure the end station for smaller MTU.
The most common reason for PMTUD to not work is that someone is filtering and denying the ICMP error messages. I would guess that the second provider (or someone you go through from the second provider) is filtering ICMP and that this is the cause of your problem.
Many people believe that there is some risk in ICMP (especially to/from outside their network) and filter ICMP. This is one example of why filtering all ICMP is frequently not a good idea.
HTH
Rick
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide