From: ccie2be (ccie2be@nyc.rr.com)
Date: Sat May 28 2005 - 19:49:40 GMT-3
Hi guys,
Many of you have shared a lot of info with me and helped me make sense of
things I didn't fully understanding. In the past couple days I've been
trying to get a handle on Mobile IP. Personally, I feel that this topic
isn't very well documented by Cisco on the Doc-CD, so I just got the new
Cisco Press book on this and it's plugged a lot of the holes in my
understanding of this topic. I suspect that many people on GS, like me a few
days ago, don't have a solid grasp of Mobile IP. So, consider this write up
my way of paying back all of you that have helped me. (Scott, Brian(s), Bob,
Bruce, Marvin and the rest of you guru's out there, I know this isn't real
pay back for you guys but I don't know what to do about that. What can I
tell you about networking you don't already know?)
As I learn Mobile IP, I've come to think that the key to really
understanding this is knowing what source and destination addresses are used
by which mobile ip entity under which circumstances. I think I've got that
down - at least for the moment (Who knows how long before the LBS kicks in).
So, here goes:
Starting knowledge (what different mobile IP entities know before a MN has
traveled to a foreign network but after Mobile IP has been configured):
MN - it knows the ip address of its HA b/c this address is pre-configured
manually. (Maybe DHCP can be used to dynamically provide this info but it
doesn't matter as far as how mobile ip works.)
it also knows it's own home ip address (either via dhcp or via
manual config) and some security info so it can have a secure communication
with the HA.
HA - Via normal IGP's, it knows how to reach any FA that may be out there
but it doesn't know (or care) which rtr's are FA. It also knows via manual
configuration which hosts can be MN's and their home subnet. And, it has
security info for each potential MN so it knows a legit MN when it sees one.
FA - FA's know what interfaces support visiting MN. It doesn't know (or
care) which rtr's are HA for MN's but FA also know how to reach the ip
address of HA via normal IGP's.
CN - Learns the MN's normal home network thru DNS and is never aware of
whether the MN is actually on its home network or is on a foreign network.
Before a MN moves off it's home network, everything works as normal, so none
of the above mobile specific info matters. But, once a MN moves to a
foreign network, here's what happens:
Once a MN is on a foreign network, 1 of 2 things happens:
1. If the router to which the MN attaches supports FA services, the FA is
pre-configured with it's FA-CoA and advertises this address via IRDP. When
the MN hears this IRDP, it learns the FA-CoA and the address of the FA.
(These 2 addresses can be but don't have to be different.) Once the MN
learns the FA-CoA, it can begin the mobile ip registration process. It
sends a RRQ pkt to the FA using it's home network address as the source ip
and the FA's address as the destination address. (The MN learned this from
the IRDP messages from before.)
The FA forwards this RRQ to the HA using it's FA-CoA as the source ip (???)
and the HA's address as the dest address. (The FA learned the HA's address
from the MN when the MN sent the RRQ.)
When the HA gets the RRQ from the FA, assuming the security info in the RRQ
is legit, it adds an entry in its mobility binding table associating the MN
home host address with the FA-CoA. It creates a tunnel to the FA-CoA and it
also adds a host route to its route table indicating that to get to the home
host address of the MN, send pkts out the tunnel. (This entry in the route
table appears as M routes.) Now, pkts addressed to the MN (from any host,
CN) are intercepted by the HA and tunneled to the FA.- CoA. Note that the
original source and dest ip addresses used by the CN don't change. However,
these pkts to the MN are encapsulated by the HA with a new dest address -
the FA-CoA. (I don't know what source address the HA uses when it tunnels
pkts to the FA.) Sorry <Shrug>
When the FA gets these pkts from the HA, it de-encapsulates the outer ip
addresses and forwards the pkts onto the subnet the MN is visiting. Notice
that FA forwards these pkts onto this subnet with the original source and
dest ip addresses Also notice that this dest address is the "normal" ip
address of the MN.
When the MN responds to the CN, it just swaps the source and dest addresses
as it would normally do when its on its own home network. The only
difference is that instead of getting its "normal" default gateway, when it
arp's, it gets the FA's mac address.
When the FA gets this pkt, it forwards it normally to the CN.
2. If the foreign network the MN is visiting doesn't support FA services
or the FA is too busy but DHCP is running on that subnet, the MN acquires
another address via DHCP which is called the Co-location CoA (CCoA). This
address is like a 2ndary address which the MN uses as its source address for
communication with the HA instead of its "normal" home subnet address.
The process that follows is similar to that described above with a couple
exceptions.
The MN, since there's no FA or its too busy, sends its RRQ directly to its
HA. When the HA gets this RRQ, it does the same as before except this time,
it sets up a tunnel all the way to the MN instead of the FA. Notice that
the HA when it sets up its mobility binding entry, it associates the
"normal" MN home address with the 2ndary address the MN has acquired from
the foreign network. Notice also that the MN, when its talking to other
hosts (CN's) on the network still uses its "normal" home network address as
the source address in pkts it sends to CN's. This is b/c when CN's want to
talk to the MN they must still send their pkts to the "normal" home network
address and the HA must still tunnel these pkts to the MN.
The process just described creates a triangular routing path and can be
considered the "normal" process. Pkts from the CN to the MN first go to the
HA. From the HA, the pkts are then tunneled to the MN (or FA) on the
foreign network. When the MN responds, pkts to the CN go directly to the
CN. Then the process repeats. Notice that pkts in this scenario are
tunneled in only one direction - from the HA to the MN (or FA).
This process works fine if we assume that the CN is not on the home network
of the MN. But let's assume the CN is on the home network of the MN. Now,
let's also assume the HA is configured with anti-spoofing features such as
an acl or unicast rpf. Recall that the MN when sending pkts to the CN uses
its "normal" home network ip address as the source ip. When such a pkt
arrives at the rtr configured as a HA, the rtr will see the source ip
address coming in on an interface different from the interface on which pkts
with this source ip address should come in from and, of course, will drop
these pkts.
Now, we've got a problem. To overcome this problem, instead of the tunnel
being just 1-way, mobile ip allows the tunnel to be 2-way. I'd tell you the
details of this if I knew them, but I don't - at least not yet.
OK, hope you were all able to follow the logic here and I hope this adds to
your understanding. If anybody has any comments or corrections, please let
me know.
Tim
This archive was generated by hypermail 2.1.4 : Fri Jun 03 2005 - 10:12:03 GMT-3