Home > Articles > Cisco Network Technology > Wireless/Optical/High Speed > Mobile IP Technology and Applications

Mobile IP Technology and Applications

Chapter Description

This chapter highlights the major concepts of IOS Mobile IP configuration in a simple lab topology. It presents in detail the most important concepts in IOS Mobile IP configuration. We start out by using six routers to examine each component individually. Several alternatives requiring fewer routers are presented at the end of the chapter.

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.

Home Agent

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#

Mobile Node

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:

  1. Ensure that the Mobile Node has received agent advertisements from one or more FAs.
  2. 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.
  3. 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."

FA

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.

3. Examining the Routing Table | Next Section Previous Section