A carrier reports that one web site on DCN-BSS network is not available. DCN-BSS is a VPN. One PC at CE of client side could ping to the IP address of one web server at remote CE, and the homepage could be opened. After entering the correct username and password, the user cannot access the site, and there is no obvious prompt for error.
Set the MTU values of all interfaces interconnecting S8016, NE40 and NE08 to 1548. The problem is solved, and access to web sites is normal.
For the topology, see the attachment.
The failure to access the website starts from the time that NE40-2 is upgraded, and that the link is added with bandwidth and the configurations are adjusted. Once the user enables LDP at the POS link connecting with M160 and the GE link connecting with S8016, the website access is normal then. After resuming the configurations being adjusted, the problem occurs again. According to checkup for route and LSP of public network that connects with DCN-BSS, the packets to CE at remote go over the path of NE08->NE40-1->M160, and the packets from the CE at remote only have the unique path, namely, M160->NE40-1->NE08. After the enlargment of link capacity and network adjustment, two links are added in fact, so all packets are transmitted over M160->NE40-2->S8016->NE08. So the problem could be located as coming from either M160, or NE40-2 or S8016. According to checkup, NE40-2 has no record for lost packet, but S8016 has because of mpls frame exceed mtu; that is, mpls packet is too big. After analysis on the forwarding of packets by NE40 and S8016, R&D confirms that the length of MPLS header is not numbered into MTU at NE80; at S8016, the length of MPLS header is numbered into the MTU, and the S8016 as P node does not fragment the packets. It is because S8016 fragments the ICMP packets even though they are configured with a tag for non-fragment, so no packet is discarded in pinging big packets.Thus, the contributor of the problem has been found.