We had two concerns with our old name(s). First, Chesapeake suggests a small, regional identity, but we have over 350 employees now, and we are deepening our coverage of the U.S. beyond our New York, San Jose, Falls Church, Annapolis, and Annapolis Junction (Columbia MD) training sites. Second, we conceived of and own Mentor Labs, developers of VLAB (TM) -- but this wasn't clear to a lot of folks. No, we were not bought out, and yes, we do plan to continue our emphasis on quality in training, consulting, virtual labs, remote classrooms, and e-learning. There should also be some interesting partnership and other announcements by or around the time you read this. We've got some ideas that we hope will energize e-learning! But you're here looking for information, not marketing information...
This month's topic is Mobile IP. Cisco IOS releases 12.0(1) T or 12.1 support it, so it has been around for long enough to be stable (one hopes). And Cisco has big plans for it in the cell phone arena. It might also be useful in other areas. For example, consider mobile devices in an 802.11 wireless Ethernet setting, where the wireless coverage is big enough for multiple subnets to be desirable. And what about those wireless networked devices coming soon to new automobiles near you?
Rumor mill: I hear that Aironet 802.11 11 Mbps wireless Ethernet is selling extremely well, as in first month Cisco sales exceeded the previous 12 months as a separate company. Talk about validating a market! The obvious use is factory/warehouse floor (replacing older IBM wireless gear with open standards). But with the Cisco-Xircom partnership to produce wireless NIC cards, if prices come down, where does that leave Bluetooth? With prestigious backers (IBM, Intel) for Bluetooth, it seems to come down to speed versus cost with a time-to-market wildcard. What do you think?
First of all, understand that not all mobile applications require Mobile IP. For example, many of us have been moving laptops around from subnet to subnet. We've learned to cope with DHCP by doing ipconfig /release and ipconfig /renew under Windows NT, or other variants with other Operating Systems. That suffices for us to work effectively.
The intent with Mobile IP however is for us to keep one IP address and use it no matter where we are connected. There is a price to pay for this (configuration, load on routers, and so on). So it behooves us to understand the trade-offs.
What works well with the DHCP approach so many of us use is the pull model. We get email by having our mail software reach out and do POP or IMAP or some other protocol to a home email gateway. We launch whatever tool we use to get file and print access (Microsoft Network Neighborhood, FTP Explorer, etc.) We know how to make this work. And it scales very well.
The drawback to this pull approach is that we have to initiate every action ourselves. We have to check our email. It's just like having to use your cell phone to check your desktop phone's voice mail, if you don't have or don't know how to activate call forwarding. If you want instant notification, pull is not a very good model. (Sidetrack: I've been discovering the virtues of cell phone on Silent. It is amazing how much control it puts back into your life!)
For wireless IP-based telephony, we need some way to make the phone ring. We'd like one address (probably), we'd certainly like one phone number. For building-scale mobility, Cisco's IP Telephone and Call Manager software give us the one phone number with DHCP for addressing, and solid mobility within switched subnets. That approach however will not scale to carrier cell phone scale. We also need paging and instant notification, or push type of services. The only way these work is if we have tracking of our current IP address, or we use one constant IP address. The former is more of an application gatewaying approach, which means re-implementing it for each application. The latter provides connectivity for all applications in a more transparent and simpler way.
In summary, then, don't use Mobile IP if you don't need it. Mobile IP certainly brings some interesting machinery to bear on larger scale mobility. But if DHCP solves your mobility problem, use it, by all means.
In the following, we'll talk briefly about a Cisco technique called Local Area Mobility (LAM), that solves smaller scale mobility issues, and then we'll discuss full Mobile IP. The reason for covering LAM is that you may hear about it or run into it, and I'd like you to know about it so you won't confuse it with full Mobile IP. It also provides a possible mobility approach intermediate between DHCP and full Mobile IP.
Here's how LAM works. When at its home or base location, the LAM computer connects to a subnet that connects somehow to a router. It is addressed normally and everything works as usual. Let's refer to these as the home subnet and home router.
Sometimes the LAM computer is attached to a different segment (subnet), the remote subnet. We configure the remote router connected to the remote subnet to allow LAM, and this gives the LAM computer the connectivity it needs. (The router connected to the remote subnet must be the travel router). The remote router detects the LAM computer via ARP, and advertises a host route for it. Since we wisely left proxy ARP enabled on the home router, the /32 host route causes the home router to respond to ARP requests for the LAM computer. Thus packets destined for the LAM computer go instead to the home router, thence to the remote router (following the host route), and finally to the LAM computer itself. I presume the LAM computer ARPs for hosts on its home subnet or for its default gateway. In either case, the remote router, wisely doing proxy ARP as well, responds and routes the packets to their destination.
In summary, for this to work we need proxy ARP enabled on home and remote routers, and we need the travel router to create and advertise a host route. Proxy ARP is on by default, so that part is easy. The ip mobile arp interface command does the host route part for us. Here is the syntax of the command:
[no] ip mobile arp [timers keepalive hold-time] [access-group access-list-number | name]
In this command, the timers keyword indicates you wish to set the timers. Keepalive is the time in seconds between unicast ARP messages to the LAM computer, verifying it is still present (default, 300 seconds or 5 minutes). Hold-time is the time, in seconds, the LAM computer is considered present without receiving an ARP or unicast from the host, typically three times the keepalive time (default, 900 seconds or 15 minutes). The numbered or named access list is a standard access list giving you control over which IP host addresses are allowed to be LAM computers. You will probably want to use this option. If you don't, and you turn on LAM in a large part of your network, you may go quite a while with misconfigured IP addresses on hosts before you catch on. Note that if you're doing DHCP, you'll want one address pool for the hosts permitted to do LAM, and another for the ones not permitted LAM.
LAM first appeared in release 11.0 and is supported on Ethernet, Token Ring, and FDDI interfaces only.
You need to redistribute the LAM routes into your routing protocol, which has to support host routes (hence, be classless: EIGRP, OSPF, or IS-IS for IP). You also need to have bridging enabled on the interface.
Note (added 12/26/2000): a reader reported on trying this in the lab. The
documentation does state that bridging is required on the LAM interface.
His lab testing showed that bridging is not in fact required. Example:
bridge 1 protocol ieee
access-list 10 permit 192.100.100.55
interface ethernet 0
ip mobile arp access-group 10
bridge-group 1router eigrp 100
redistribute mobile metric 10 2000 255 1 1500
It turns out that once you've learned the basic terminology of Mobile IP, you probably have enough of the basic idea as well, enough to configure it. The computer that moves around but keeps the same IP address is the mobile node. When at home, it is on the home network. The router connected to the home network is the home agent. When the node is away from home, it communicates via a foreign agent router.
A computer the mobile node is talking to is referred to as a correspondent node. The correspondent node sends packets via normal routing. When the packets reach the home agent, the home agent knows whether the mobile node is at home or not. (Think: administrative assistants for people?) If the mobile node is at home, normal ARP and normal LAN transmission are used at Layer 2 to send frames to the mobile node.
When the mobile node is away, it needs to get in touch with the foreign agent and work with it to register with the home agent. This informs the home agent that the mobile node is away, and tells it the Care-of Address, an address on the foreign agent to forward packets to. (Just as if you've visiting friends for a while, so that your physical "snail" mail is to be forwarded Care Of your friends).
The home agent uses a one-way IP over IP tunnel to send packets to the foreign agent. It can use this tunnel for several mobile nodes at one time, if need be. The foreign agent has ARP information, the MAC address of the mobile node, and so it can forward the packets to the mobile node without a tunnel.
When the mobile node needs to send a reply to the correspondent node, it sends via the foreign agent and normal routing.
Aspects that I found myself wondering about as I read the RFC:
To make Mobile IP work, you need three things: protocol stack support on the mobile node supporting Mobile IP, a configured home agent for each mobile node, and configured foreign agents. Protocol stack support is likely to be a bit of a challenge in the short term. It will presumably be available from your wireless provider -- but for those looking to experiment, you'll want a non-wireless Mobile IP stack.
Source of Mobile IP information, including URL's for some stacks implementing Mobile IP:
Information about Mobile IP:interface ethernet0The router mobile command enables Mobile IP. The redistribute mobile command is needed to redistribute the virtual networks declared in ip mobile network commands. The virtual networks allow the router to support mobile nodes which are never "at home", that is, never connected to a physical interface off that home agent router. Redistribution allows advertisement of such networks, so that packets from correspondent nodes that need to find the mobile node arrive at the home agent and get handled properly.
ip address 192.16.100.1 255.255.255.0
!
router eigrp 100
network 192.16.100.0
redistribute mobile
!
! Enable Mobile IP
router mobile
!
! Define a virtual network
ip mobile network 10.0.0.0 255.0.0.0
!
! Define which hosts are on the virtual network,
! and the care-of access list
ip mobile host 10.0.0.1 10.0.0.5 virtual-network 10.0.0.0 255.0.0.0 care-of-access 2
! Define which mobile hosts are on Ethernet 0,
! with a lifetime of one hour
ip mobile host 192.16.100.51 192.16.100.55 interface Ethernet0 lifetime 3600
!
! The next five lines specify security associations
! for mobile hosts on virtual network 10.0.0.0
ip mobile secure host 10.0.0.1 spi 100 key secret1
...
ip mobile secure host 10.0.0.5 spi 200 key secret5
!
! The next five lines specify security associations for
! mobile hosts on Ethernet0
ip mobile secure host 192.16.100.51 spi a1 key sanfran1
...
ip mobile secure host 192.16.100.55 spi a1 key sanfran5
!
! Deny access to anyone on network 10.0.0.0
! trying to register on network 13.0.0.0
access-list 2 deny 13.0.0.0
access-list 2 permit any
The ip mobile host ... virtual network command then specifies the legal range of mobile hosts considered to be on the virtual network. We have chosen to use the care-of-access option, specifying an access list controlling the care-of addresses we will allow those mobile nodes to use. (Perhaps we do not have a reciprocity or billing arrangement with some providers or networks).
We also see a ip mobile host command for the mobile nodes "normally" connected to Ethernet0. The configuration demonstrates that security is available, and specifying Security Parameter Index (SPI) and encryption keys per mobile node. (This can also be done per-foreign-agent). And that's it!
Not shown: you can also use an access list to specify which hosts are permitted to roam (use foreign agents at all). One imagines this might be useful to block customers who haven't paid their bills, or terminated employees who have not yet turned in their laptop and wireless equipment.
interface Ethernet0The router mobile enables Mobile IP. The ip mobile foreign-agent care-of command tells the router the interface to obtain the care-of address from. The ip mobile foreign-service interface command enables the router to advertise being a foreign agent. The advertisements themselves use IRDP (ICMP Router Discovery Protocol). We greatly reduce the IRDP timers from the default values so that mobile nodes will discover the foreign agent more quickly. This reduces the wait for connectivity while the mobile node discovers the local foreign agent and registers the new care-of address with its home agent.
ip address 192.16.150.17 255.255.255.252
!
interface Ethernet1
ip address 192.16.200.1 255.255.255.0
ip irdp
ip irdp maxadvertinterval 10
ip irdp minadvertinterval 7
ip mobile foreign-service
ip mobile registration-lifetime 3600
!
router mobile
!
ip mobile foreign-agent care-of Ethernet0
show ip mobile globals
show ip mobile host [addr | interface int | network addr | group]
show ip mobile interface [interface]
show ip mobile secure {host | visitor | foreign-agent | home-agent} address
show ip mobile binding
show ip mobile traffic
show ip mobile tunnel [interface]
show ip mobile violation [address]
show ip mobile visitor [pending] [address]
show ip route mobile
clear ip mobile traffic
clear ip mobile binding ! (CAUTION: can break sessions)
clear ip mobile secure ! (CAUTION: can break sessions)
clear ip mobile visitor ! (CAUTION: can break sessions)
debug ip mobile advertise
debug ip mobile host
Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw@netcraftsmen.net .