Mobile IPv6 with Linux
Now the scene is complete, and we can start experimenting with mobility. Before we start, remember the following about MIP: movement detection is the trigger; binding updating (registration) is the action. We'll start by letting the MN move, then check whether movement was detected. Upon witnessing movement detection, we'll check whether a BU was established successfully. Figure 2 shows the network's state before moving. To simulate movement, we use iwconfig to switch the MN's wireless interface from one ESS (wireless cell) to another:
[raven]# iwconfig wlan0 essid "remote"
Upon moving, the wireless interface should acquire a new address, and a new default gateway should appear (Listing 3).
Listing 3. Moving
... Before Moving (At the Home Network) ... [raven]# iwconfig wlan0 | grep ESSID wlan0 IEEE 802.11b ESSID:"home" [raven]# ifconfig wlan0 | grep inet6 inet6 addr: 2001:db8::beef/64 Scope:Global inet6 addr: fe80::205:5dff:fef2:db2b/64 Scope:Link inet6 addr: 2001:db8::205:5dff:fef2:db2b/64 Scope:Global [raven]# ifconfig ip6tnl1 | grep inet6 inet6 addr: fe80::205:5dff:fef2:db2b/64 Scope:Link [raven]# route -A inet6 | grep ::/0 ::/0 fe80::202:6fff:fe06:bcf UGDA 1024 0 0 wlan0 ... Triggering Movement ... [raven]# iwconfig wlan0 essid remote ... After Moving (At the Foreign Network) ... [raven]# iwconfig wlan0 | grep ESSID wlan0 IEEE 802.11b ESSID:"remote" [raven]# ifconfig wlan0 | grep inet6 inet6 addr: 2001:db8:1:0:205:5dff:fef2:db2b/64 Scope:Global inet6 addr: fe80::205:5dff:fef2:db2b/64 Scope:Link [raven]# ifconfig ip6tnl1 | grep inet6 inet6 addr: 2001:db8::beef/128 Scope:Global inet6 addr: fe80::205:5dff:fef2:db2b/64 Scope:Link [raven]# route -A inet6 | grep ::/0 ::/0 :: U 128 0 0 ip6tnl1 ::/0 fe80::202:6fff:fe06:4610 UGDA 1024 4 2 wlan0 [raven]#
Using a packet capturing tool (sniffer), such as tcpdump, we should see a different router appearing on the link. The Mobility Dæmon log messages should indicate movement detection (md in the logs stands for movement detection). Now that the MN has detected movement and acquired a new CoA address, it should send a BU to its HA. A sniffer should be able to display the BU message as:
IP6 2001:db8:1:0:205:5dff:fef2:db2b > 2001:db8::: ↪DSTOPT mobility: BU seq#=54814 AH lifetime=262140 IP6 2001:db8:: > 2001:db8:1:0:205:5dff:fef2:db2b: srcrt ↪(len=2, type=2, segleft=1, 2001:db8::beef) ↪mobility: BA status=0 seq#=54814 lifetime=262140
In addition, the Mobility Dæmon should have a BU List Entry (BULE) that shows the HoA, CoA and HA addresses:
[raven]# telnet localhost 7777 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. mip6d> bul mip6d> bul == BUL_ENTRY == Home address 2001:db8:0:0:0:0:0:beef Care-of address 2001:db8:1:0:205:5dff:fef2:db2b CN address 2001:db8:0:0:0:0:0:0 lifetime = 262140, delay = 249033000 flags: IP6_MH_BU_HOME IP6_MH_BU_ACK ack ready dev wlan0 last_coa 2001:db8:1:0:205:5dff:fef2:db2b lifetime 262136 / 262140 seq 19428 resend 0 delay 249033(after 249030s) expires 262136 mps 2 / 3 mip6d>
We can see whether the BU was received and accepted by looking at the HA's Mobility Dæmon log messages and by displaying the HA's BC:
[denali]# telnet localhost 7777 mip6d> bc mip6d> bc hoa 2001:db8:0:0:0:0:0:beef status registered coa 2001:db8:1:0:205:5dff:fef2:db2b flags AH-- local 2001:db8:0:0:0:0:0:0 lifetime 262068 / 262140 seq 19429 unreach 0 ↪mpa 13133 / 13221 retry 0 mip6d>
As shown above, the Mobility Dæmon provides a virtual terminal interface to its internal data structures that you can access by a establishing a Telnet session to port 7777. Figure 3 shows the network's state after moving.
We can't conclude a networking experiment without some action from our old crony ping. From the MN, we'll start by sending ping requests to the HA interface, while the MN is on the home link. We'll then move and see what happens. This exercise is shown as follows:
[raven]# ping6 2001:db8:: 64 bytes from 2001:db8::: icmp_seq=7 ttl=64 time=3.72 ms 64 bytes from 2001:db8::: icmp_seq=8 ttl=64 time=3.70 ms ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument ping: sendmsg: Invalid argument ping: sendmsg: Operation not permitted 64 bytes from 2001:db8::: icmp_seq=13 ttl=63 time=142 ms 64 bytes from 2001:db8::: icmp_seq=14 ttl=63 time=122 ms
Note that in responding to ping requests, the HA interface is actually acting as a CN. Note how, upon the handover, the MN loses connectivity for some time, called the handover latency, and then re-establishes it. Note also how the delay increases tremendously as the MN moves.
A more interesting test is to use a program that sends video like VLC or GnomeMeeting and visually assess how smooth the handover is. Although the ultimate goal of MIPv6 is to achieve smooth and lossless handover, in reality, there is a blackout period during which packets are lost or delayed. Much of the effort put into developing and standardizing MIPv6 is to enhance the smoothness of the handover and ultimately achieve seamless handover. As with any other technology, realizing the limitations is as crucial as recognizing the value.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Sony Settles in Linux Battle
- Libarchive Security Flaw Discovered
- Profiles and RC Files
- Maru OS Brings Debian to Your Phone
- The Giant Zero, Part 0.x
- Snappy Moves to New Platforms
- Understanding Ceph and Its Place in the Market
- Git 2.9 Released
- Astronomy for KDE
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide