Operation and Evaluation/Troubleshooting
In the lab environment, roaming is simulated by toggling the FA to which the mobile router's roaming interface is connected. This is typically done by assigning different virtual LAN (VLAN) numbers to each FA and changing the VLAN assignment for the roaming interface on the mobile router. After the mobile router's roaming interface is connected to a FA at Layer 2, the mobile router should automatically register with the Home Agent through the FA.
The different mobility entities can be probed to assess proper functioning of the Mobile IP process.
Even though Mobile IP is an edge-intelligent routing protocol (that is, all routing decisions are made by the Mobile Node), a network administrator often does not have access to the Mobile Node for troubleshooting. Because the Home Agent is the anchor point in the network, it is a logical starting point for evaluation. The first checklist task at the Home Agent is to verify that the Mobile Node indeed has a mobility binding using the show ip mobile binding command. If no binding exists for the Mobile Node, the show ip mobile host command can provide information about any previous failed registration attempts.
Example 4-7 shows the output if the security association on the Mobile Node (192.168.100.10) did not match the one configured on the Home Agent. The output of the show ip mobile host command displays the failure as "Last code," which in this example is a failed authentication. The output also shows when the Home Agent last accepted a registration from the Mobile Node, and when the registration was last denied. In this example, the Mobile Node had four failed registration attempts, and had never successfully registered with the Home Agent.
Example 4-7 show ip mobile host Command
HA#show ip mobile binding 192.168.100.10 Mobility Binding List: HA#show ip mobile host 192.168.100.10 Mobile Host List:
192.168.100.10: Allowed lifetime 10:00:00 (36000/default) Roam status -Unregistered-, Home link on virtual network 192.168.100.0 /24 Accepted 0, Last time -never- Overall service time 00:00:21 Denied 4, Last time 07/24/03 13:43:29 Last code 'MN failed authentication (131)' Total violations 4 Tunnel to MN - pkts 0, bytes 0 Reverse tunnel from MN - pkts 0, bytes 0 HA#
Using the information learned through troubleshooting, the Mobile Node configuration can be corrected to send a proper RRQ message to the Home Agent. Upon successful authentication and validation of the RRQ, a mobility binding is established on the Home Agent, as shown in Example 4-8. A valid binding, however, might not indicate that everything is functioning correctly. Thus, you should also verify that the last accepted registration is more recent than the last denied registration using the show ip mobile host command.
Example 4-8 Valid Mobility Binding
HA#show ip mobile binding 192.168.100.10 Mobility Binding List: 192.168.100.10: Care-of Addr 192.168.6.1, Src Addr 192.168.4.2 Lifetime granted 10:00:00 (36000), remaining 09:59:52 Flags sbdmg-t-, Identification C2CA6BA8.4489393C Tunnel0 src 192.168.1.2 dest 192.168.6.1 reverse-allowed Routing Options - HA#
After looking at the Home Agent, the next best place to troubleshoot is at the Mobile Node. (The FA is often reserved for last, because the only deterministic way to identify the active FA is to look at the CoA that the Mobile Node is using.) Each Mobile IP client offers a different set of tools for troubleshooting, but the basic premise is the same as those available in IOS. Follow these troubleshooting steps:
- Ensure that the Mobile Node has received agent advertisements from one or more FAs.
- Determine which FA the Mobile Node has selected and whether the registrations are indeed accepted by the foreign and Home Agents. Also, the registration might be accepted, but the reply is dropped by the network.
- Determine whether and how data traffic is flowing.
Example 4-9 shows the output of the show ip mobile router agent command, which lists all currently valid agent advertisements. Because this mobile router is only seeing one FA, you can easily determine which FA is being used. Note that most clients have some method of indicating which FA is being used. This is useful when proceeding to the FA for further troubleshooting. If no FAs have been heard, it is likely a physical layer problem or a FA configuration problem.
Example 4-9 Current Agent Advertisements
MN#show ip mobile router agent
Mobile Router Agents:
Foreign agent 192.168.5.1: Care-of address 192.168.5.1 Interface Ethernet0/0, MAC aabb.cc00.6801 Agent advertisement seq 30828, Flags rbhFmG-t, Lifetime 36000 IRDP advertisement lifetime 9, Remaining 6 Last received 07/20/03 19:49:07 First heard 07/19/03 18:11:37
When you have determined that the Mobile Node has a valid FA, the next step is to look at the registration status. Example 4-10 shows the output of the show ip mobile router command. In the Monitor section of the output, the status of the registration is displayed, along with the current FA and CoA.
Example 4-10 Registration Status
MN>show ip mobile router Mobile Router Enabled 07/20/03 15:00:42 Last redundancy state transition NEVER
Configuration: Home Address 192.168.100.10 Mask 255.255.255.0 Home Agent 192.168.1.2 Priority 100 (best) (current) Registration lifetime 65534 sec Retransmit Init 1000, Max 5000 msec, Limit 3 Extend Expire 120, Retry 3, Interval 10
Monitor: Status -Registered- Active foreign agent 192.168.6.1, Care-of 192.168.6.1 On interface Ethernet0/0 Tunnel0
Finally, if the registration looks good and matches what the Home Agent has for the registration, you likely have a data plane problem. Check the interface counters and verify that traffic is coming into an out of the Mobile Node. You often find outbound traffic, but no inbound traffic. In this case, you likely have a problem with the tunneling. A number of common tunneling problems and solutions are covered in Chapter 6, "Metro Mobility: Client-Based Mobile IP," and Chapter 8, "Deployment Scalability and Management."
The FA stores the state of active Mobile Nodes in the visitor table. The output of the show ip mobile visitor command, shown in Example 4-11, is similar to the output of the show ip mobile binding command on the Home Agent. However, visitor entries in the FA can be misleading for troubleshooting. Entries are not flushed from the visitor table until the lifetime expires, so a Mobile Node could have briefly visited the FA, but the visitor entry can remain for many hours if the lifetime is long. Note that using the Registration Revocation mechanism, described in Chapter 6, alleviates this problem.
Example 4-11 FA Visitor Table Entry
FA1#show ip mobile visitor Mobile Visitor List: Total 1 192.168.100.10: Interface Ethernet1/0, MAC addr aabb.cc00.6a00 IP src 192.168.100.10, dest 192.168.5.1, UDP src port 434 HA addr 192.168.1.2, Identification C2EDFF2A.72710D54 Lifetime 10:00:00 (36000) Remaining 08:16:14 Tunnel0 src 192.168.5.1, dest 192.168.1.2, reverse-allowed Routing Options -
Mobile Nodes that have not successfully completed registration are kept in the pending visitor table, which is visible with the show ip mobile visitor pending command. If communication problems exist between the FA and Home Agent, several entries are often in the pending table. However, in most cases, entries do not stay in the pending table long enough to be visible.