Setting up an FMIPv6 testbed
Setting up an FMIPv6 testbed
This document provides a step by step explanation on the setup process for an FMIPv6 (Fast Handovers for Mobile IPv6, RFC4068) testbed. Please keep in mind that this document presents a testbed such as the one used for developing the fmipv6.org implementation and may not correspond to your needs: hardware and/or software requirements may vary depending on your particular setup.
The Testbed
Uplink
|
| 2001:660:4701:ffff::2
| eth0
+-----------+
eth2 \| Home |/ eth3
2001:660:4701:1::1 /| Agent |\ 2001:660:4701:2::1
+-----+-----+
| eth1
| 2001:660:4701:3::1
|
|
|
2001:660:4701:3::2 | 2001:660:4701:3::3
+------------+ eth0 +---------+ eth0 +------------+
| AR 1 |--------------| Hub |--------------| AR 2 |
| | +---------+ | |
+------------+ +------------+
/\ eth1 eth1 /\
2001:660:4701:4::1 2001:660:4701:5::1
The top router, which is also acting as a Home Agent, has four interfaces:
- the uplink, in this example eth0;
- one link connected to the backbone, in this example eth1;
- an interface, eth2, used by the Correspondent Node to connect;
- and an interface, set as the home network, in this example eth3.
Both Access Routers are connected to the backbone through their eth0 interfaces and offer wireless connectivity through eth1 which is either a wireless card or a wired interface directly connected to an 802.11 dedicated Access Point. The same is valid for eth2 and eth3 on the Home Agent.
Requirements
Hardware
The following hardware is needed to set up an operational testbed:
- 1 router acting as a Home Agent;
- at least 2 Access Routers;
- Access Points;
- Mobile Node and Correspondent Node;
- hub and cables :o)
NOTE: We first used Soekris net4521 cards for routers and despite slightly lower performance, which mostly showed when creating inter router tunnels, they served their purpose very well. Yet, for purely conventional reasons, we decided to switch to a set of Twisters, which apart from being more powerful are also a more convinient for an development platform where updates, changes in configuration as well as a more complete set of tools are needed.
Any Linux supported wireless card should work with fmipv6.org implementation. We nevertheless achieved best performances with cards based on an Atheros chipset with a few improvments of the Madwifi driver. We hope these changes will soon be integrated into Madwifi distribution to facilitate the use of FMIPv6.
Software
Requirements for the Home Agent:
- routing daemon (e.g. quagga);
- RA daemon (e.g. radvd);
- Linux kernel with MIPL2 patch applied;
- MIPL2 daemon.
Requirements for both Access Routers:
- routing daemon (e.g. quagga);
- RA daemon (e.g. radvd);
- Linux kernel with MIPL2 patch applied;
- fmipv6-ar daemon.
And finally, the Mobile Node needs:
- MIPL2 modified kernel (with a minor modification for better fmipv6.org performance) and userspace daemon (also slightly modified);
- fmipv6-mn daemon.
Setting up the Testbed
Setting up a fully functional IPv6 network
Before starting experimentation with FMIPv6, we need a fully functional IPv6 network. All nodes should be able to communicate with (send packets to) each other. This is a crucial part. If, for example, an AR is not able to reach the HA, then BUs coming from behind it will not create any bindings. A good way of verifying connectivity is through the "ping" program.
We'll give brief instructions on how we are to get IPv6 routing up in our testbed. For more detailed manual on setting up an IPv6 network, you can read Peter Bieringer's excellent Linux IPv6 HOWTO.
NOTE: you may choose to set up static routes, in this case you do not need to install and configure quagga or any other routing software.
In case you want dynamic routes (well... good choice) you'll need to run a routing daemon. Quagga comes with many routing daemons but for IPv6 routing you may choose between ospf6d and ripngd. We used the latter in our examples.
Don't forget to activate zebra and ripngd daemons on the routers:
# This is an example of quagga daemons configuration file
# /etc/quagga/daemons
zebra=yes
bgpd=no
ospfd=no
ospf6d=no
ripd=no
ripngd=yes
isisd=no
Zebra daemon takes care of your interface, it configures them for you. Let's do that on the Home Agent:
! This is an example of quagga zebra daemon configuration file
! /etc/quagga/zebra.conf on Home Agent
hostname put_your_own
password put_your_own
enable password put_your_own
!
interface eth0
ipv6 address 2001:660:4701:ffff::2/64
ipv6 nd suppress-ra
!
interface eth1
ipv6 address 2001:660:4701:3::1/64
!
interface eth2
ipv6 address 2001:660:4701:1::1/64
ipv6 nd suppress-ra
!
interface eth3
ipv6 address 2001:660:4701:2::1/64
ipv6 nd suppress-ra
!
ipv6 nd suppress-ra
!
interface lo
!
interface sit0
ipv6 nd suppress-ra
!
ip forwarding
! ipv6 route ::/0 2001:660:4701:ffff::1
!
line vty
NOTE: you may need to define a static default route if you don't receive ripng advertisements through your uplink in case you need internet connectivity.
And configure ripngd:
! This is an example of quagga ripngd daemon configuration file
! /etc/quagga/ripngd.conf on Home Agent
hostname put_your_own
password put_your_own
!
router ripng
network eth0
network eth1
network eth2
network eth3
redistribute connected
redistribute static
redistribute kernel
!
log stdout
Let's do the same for the Access Routers:
! This is an example of quagga zebra daemon configuration file
! /etc/quagga/zebra.conf on AR 1
hostname put_your_own
password put_your_own
enable password put_your_own
!
interface eth1
ipv6 address 2001:660:4701:4::1/64
ipv6 nd suppress-ra
!
interface eth0
ipv6 address 2001:660:4701:3::2/64
ipv6 nd suppress-ra
!
ipv6 nd suppress-ra
!
interface lo
!
interface sit0
ipv6 nd suppress-ra
!
ip forwarding
!
line vty
And for ripngd:
! This is an example of quagga ripngd daemon configuration file
! /etc/quagga/ripngd.conf on AR 1
hostname put_your_own
password put_your_own
!
router ripng
network eth0
network eth1
redistribute connected
redistribute static
!
log stdout
If everything is OK, you should now be able to ping any host on your new network from any other machine in the testbed.
Broadcasting RAs
Stateless address autoconfiguration in IPv6 requires periodic broadcasts of Router Advertisement messages. We will be using radvd for doing just that.
The /etc/radvd.conf file on the Home Agent should contain:
# This is an example of radvd configuration file
# /etc/radvd.conf on Home Agent
# RAs broadcaster over Correspondent network (for the CN)
interface eth2
{
AdvSendAdvert on;
AdvIntervalOpt on;
MinRtrAdvInterval 200;
MaxRtrAdvInterval 600;
prefix 2001:660:4701:1::1/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
};
# RAs broadcaster on the Home Network
interface eth3
{
AdvSendAdvert on;
AdvIntervalOpt on;
MinRtrAdvInterval 200;
MaxRtrAdvInterval 600;
AdvHomeAgentFlag on;
AdvHomeAgentInfo on;
HomeAgentLifetime 1800;
HomeAgentPreference 10;
prefix 2001:660:4701:2::1/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
};
The /etc/radvd.conf file on the Access Routers should look the following:
# This is an example of radvd configuration file
# /etc/radvd.conf on AR 1
# RAs broadcaster over AR 1
interface eth1
{
AdvSendAdvert on;
AdvIntervalOpt on;
MinRtrAdvInterval 300;
MaxRtrAdvInterval 600;
prefix 2001:660:4701:4::1/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
};
Configuring MIPL (for Mobile IPv6)
For complete instructions on building and configuring MIPL you should read the proper documentation provided with the project itself.
Here is the configuration file we use on the Home Agent:
# This is an example of mip6d Home Agent configuration file
# /usr/local/etc/mip6d.conf
NodeConfig HA;
## If set to > 0, will not detach from tty
DebugLevel 0;
DoRouteOptimizationCN disabled;
## List of interfaces where we serve as Home Agent
Interface "eth1";
Interface "eth2";
Interface "eth3";
##
## IPsec configuration
##
UseMnHaIPsec disabled;
## Key Management Mobility Capability
KeyMngMobCapability disabled;
IPsecPolicySet {
HomeAgentAddress 2001:660:4701:2::1;
HomeAddress 2001:660:4701:2::2/64;
IPsecPolicy HomeRegBinding UseESP;
IPsecPolicy MobPfxDisc UseESP;
IPsecPolicy TunnelMh UseESP;
}
Then configure your Mobile Node.
Now your Mobile Node should be able to move from one network to another. It may take time for the MN to retrieve its Care-of-Address on the new link, due to large intervals in RA broadcasts. Note that this does not affect FMIPv6 mobility but if you need faster address autoconfiguration without FMIPv6 and flooding your links doesn't bother you, you may lower these values to the ones recommended in RFC3775 (i.e. MinRtrAdvInterval=0.03s and MaxRtrAdvInterval=0.07s).
Configuring FMIPv6 daemons
Sorry, no doc for now! Read fmipv6.org manpages.
Testing
No doc neither. Please help us by submitting.