Common Troubleshooting Issues

A few issues are so common to Mobile IP deployments that they are worth calling out specifically. However, these are by no means the only problems that can be encountered when deploying a Mobile IP solution. The most common problems are Path maximum transmission unit (MTU) discovery failure, packet loss because of asymmetric routing and Reverse Path Forwarding (RPF) checks, and failure to transit tunneled packets. Some of these problems are easier to solve than others, but none should be insurmountable.

Path MTU Discovery

Path MTU discovery is a common part of Internet communication that is generally not understood or accounted for. Path MTU discovery, as defined in RFC 1191, determines the largest packet size that can transit the intermediate network without fragmentation. It works by setting the "do not fragment" bit for all flows. When a packet is too large to transit a link, the router drops the packet and returns an Internet Control Message Protocol (ICMP) unreachable message to the source, indicating the largest packet size that can transit the link. When the source receives the message, it decreases the packet size and retransmits it. More discussion on how path MTU discovery works is given in Chapter 6, "Metro Mobility: Client-Based Mobile IP."

The problem that is most often seen in path MTU discovery is that when firewalls are deployed, an explicit rule is often added to drop all ICMP packets. Thus, ICMP unreachable messages are dropped and the source just assumes that a failure in the path to its peer is causing the flow to fail. Path MTU discovery does not cause problems in day-to-day connectivity because most links support a packet size of 1500 bytes, the maximum packet size on an Ethernet network. Note that path MTU discovery failure is not a problem that is specific to Mobile IP. Rather, it is seen any time an encapsulation is added to an Ethernet link. This problem is commonly seen with protocols such as Point-to-Point Protocol over Ethernet (PPPoE) and IP Security (IPSec).

A common example of path MTU discovery failure occurs when web browsing. Have you ever browsed to a web page, and it appears that the web browser is connecting to the site but the page is never displayed? Many times, the screen just appears blank. This is often because the initial request returns a small 1-packet response with the Hypertext Markup Language (HTML) portion of the page, which is safely able to traverse the path. However, larger graphics cannot download and traverse the path because of MTU issues and, thus, the page is never rendered.

Some operating systems include a feature called black-hole detection. The idea behind black-hole detection is that after half of the retransmits have failed, path MTU discovery should be disabled. Although this works well, it introduces noticeable delays. All is not lost, though; the following options can eliminate the delay.

There is no "one size fits all" solution to the problem, but a number of strategies can minimize the impact of the problem. The ideal solution would be to fix all the firewalls to allow ICMP unreachable messages to do their job. But, as we know, ideal is not always practical. In fact, a recent analysis showed that a significant portion of top Internet websites do not allow ICMP unreachable messages to get back to their web servers. Fixing every website would be an insurmountable task.

The next best option is to lower the MTU on the Mobile Node. This is a highly reliable solution but a difficult or impossible task, depending on the quantity and capabilities of the Mobile Node. Fortunately, many current Mobile Node implementations automatically lower the MTU when Mobile IP is active.

Another option is to use an IOS feature that adjusts the Maximum Segment Size (MSS) option, which is part of Transmission Control Protocol (TCP) negotiation. Using the ip adjust-mss mss value command forces the router to intercept all TCP SYN packets that exit the interface and lower the MSS value. This method can be difficult to deploy because it must occur between the Mobile Node and any peer with which it can communicate. However, in some networks, this is easy to deploy because only a few egress points exist. Other networks can have more problems.

Reverse Path Forwarding Checks

Failures due to unicast Reverse Path Forwarding, or uRPF, checks were covered when reverse tunneling was introduced in Chapter 6, but it is a common problem and worth a recap. The idea behind uRPF is to eliminate packets with a spoofed source address at the edge of the network. Normal unicast forwarding is performed solely based on the destination address of a packet. When uRPF checks are enabled, the router checks its routing table to ensure that a route to the source address exists through the incoming interface. The assumption is that if a router would not send a packet out the interface to the source address, it should not receive one in the interface from that address. uRPF checks are widely deployed at the edge of service provider networks. However, it would not be surprising to see uRPF checks deployed within an enterprise to minimize the impact of viruses and worms and to make it easier to track down infected machines.

The original design of Mobile IP used an asymmetric routing design with direct delivery from the Mobile Node to the destination. When the Mobile Node is roaming, this results in topologically incorrect source addresses. These packets are then dropped when they reach a router running uRPF. Using reverse tunneling solves this problem. With reverse tunneling, packets are tunneled from the CoA back to the Home Agent so that they can be delivered as topologically correct. Although reverse tunneling solves this problem, it creates extra overhead because twice the tunneling must occur. Although not a major problem, it is something that must be accounted for when planning a Mobile IP deployment.

Tunnel Transit

Unicast RPF checks are not the only cause for transport failure. Tunnel packet loss can also occur when traversal of a NAT device or firewall is necessary, because both IP-in-IP and generic routing encapsulation (GRE) tunnels are less common protocols than TCP and User Datagram Protocol (UDP). In other cases, other network devices are unable to forward tunnel packets because of either design or implementation flaws. This has occurred when mobile cellular networks are used for transport. When IP-in-IP packets fail to traverse a link end to end, you should attempt to use GRE tunneling followed by UDP tunneling. IP-in-IP and GRE tunneling are more efficient and more widely supported than UDP tunneling. However, some networks, firewalls, and NAT devices do not allow encapsulation to traverse. In this case, the network needs to be eliminated from the list of allowable roaming networks.

Security Association Incompatibilities

Incompatibilities in the implementation of security associations are also common for items not explicitly specified in the standards. The most common problem is the specification of the SPI value. Some clients use decimal values, whereas others use hexadecimal values. Older versions of IOS allow the specification of only hexadecimal values that can easily be converted to a binary representation for interoperability. Newer versions of IOS simplify the process even further by allowing SPI values to be specified in either syntax.

Another problem is the use of ASCII-represented keys; some implementations use padding, whereas other versions do not. Newer versions attempt key calculation, both with and without padding, but still might not be compatible with all ASCII key implementations. Given all of these factors, hexadecimal keys should be used whenever possible. Finally, some implementations of the MN-AAA extension differ when implementing PPP-style Challenge Handshake Authentication Protocol (CHAP) for use with RADIUS servers. Although the standards define specific values, 2 for keyed MD5 and 3 for MD5-HMAC, some vendors allow the specific algorithms to be configured for any SPI. Newer versions of IOS support the ip mobile secure mn-aaa command, which allows these algorithms to be mapped to any of the nonreserved SPI values.