This chapter describes the system\'s support for Network Mobility
(NEMO) and explains how it is configured. The product Administration Guides
provide examples and procedures for configuration of basic services on the
system. It is recommended that you select the configuration example that best
meets your service model and configure the required elements for that model, as
described in the respective product Administration Guide, before using the
procedures in this chapter.
When enabled through
a feature license key, the system includes NEMO support for a Mobile IPv4
Network Mobility (NEMO-HA) on the existing Enterprise Home Agent (EHA) platform
to interconnect LAN segments behind Mobile Routers (MRs) equipped with a 3G
interface with Fixed Networks served by the Private IP (PIP) networks and
Wavelength Division Multiplexing Networks (WDN) . The new NEMO functionality
allows bi-directional communication that is application-agnostic between users
behind the MR and users or resources on the Fixed Network sites.
The same NEMO4G-HA
service and its bound Loopback IP address supports NEMO connections whose
underlying PDN connection comes through GTP S5 (4G access) or PMIPv6 S2a (eHRPD
The following figure
shows a high-level view of NEMOv4 Architecture.
Figure 1. NEMO Overview
The system supports
the usage of dynamically learned, overlapping customer prefixes. These prefixes
are advertised through BGP in a manner similar to pool routes in the current
EHA implementation. NEMO includes the following features:
Interoperates with the Mobile IPv4
NEMO implementation of the Cisco ISR CPE routers.
structures, formats and encoding.
flags and parameters.
the specifics of the Mobile IPv4 NEMO operation of the Cisco ISR CPE routers.
the second Mobile IPv4 NEMO Control Messaging.
GRE NEMO-Tunnel termination (One NEMO-Tunnel per MR).
explicit LAN Prefix registration mode.
private customer addressing, routing and traffic segmentation
overlapping WAN-IP addresses.
overlapping LAN Prefixes.
Prefix advertisement from the EHA egress contexts via BGP
traffic segmentation and mapping of the incoming NEMO-Tunnels to the
seamlessly integrate with the existing MPN service environment.
suppression or replacement of specific fields in the NEMO Mobile IPv4 Control
Messaging sourced by the CPE routers.
of the incoming NEMO Control and Forwarding traffic with the existing control
and flow structures related to the HWIC device processing by the underlying
IS-835/MIP logic in the EHA.
with the existing AAA requirements.
IS-835/PPP/MIP timers shall be compatible with today's EHA implementation.
idle timeout (2 hrs)
absolute timer (24 hrs)
session re-registration timer (1hr 55min)
NEMO-HA is not
required to generate AAA accounting records (START/STOP) for the NEMO MIP
session. On the other hand, accounting records are generated for the MR's HWIC
MIP session, just like with any other MIP sessions.
explicit registration mode and does not require authorization/validation of the
LAN Prefixes sent by the MR.
authentication of the NEMO MIP session fails, the underlying HWIC IS-835/MIP
session is maintained since the NEMO function may attempt to establish the
supported by ICSR. All the information related to NEMO-HA (NEMO MIP session
state, and so on) is synchronized with the standby EHA and the total failure of
the active EHA does not require existing NEMO tunnels to be re-established.
dynamically advertise the LAN prefixes of any given MR to the upstream
corporate router, but it does have the ability to suppress the MR's MR-HADDR
address from the route advertisement via route-map configuration.
The existing EHA
support for interface MTU configuration also applies to NEMO-HA enabled
supports Local Authentication - the N-MHAE-SPI/KEY values are stored in the
NEMO-HA. NEMO-HA supports two options to provision the SPI/KEY information in
level: each MR would has a unique SPI/KEY pair.
level: each Enterprise uses unique security credentials and all the MR's of a
given Enterprise uses the same SPI/KEY pair.
A new RADIUS
attribute (VSA) is supported that can be passed to the EHA during the
establishment of the first IS-835/MIP session between the MR's HWIC and the
EHA. This new RADIUS attribute represents the authorization of a second NEMO
MIP RRQ for the associated MR. The EHA verifies if the new NEMO-related VSA is
present in the Access-Accept for the first IS-835/MIP session. If so, NEMO-HA
caches this information to properly authorize the second NEMO MIP session. This
allows the AAA to control the authorization of NEMO sessions more efficiently
without the need for a second AAA message.
Upon any failure
with the establishment of a second NEMO MIP session, the EHA does not take any
actions with the underlying IS-835/MIP session. In other words, it does not
tear down the first IS-835/MIP session.
supports overlapping WAN-IP addresses for differing enterprises.
RFC 5177 is
are unique to the enterprise. Two different enterprises do not share the same
VLAN ID in the egress context(s)
If no NEMO-HA
service is defined, it is not using NEMO.
The NEMO HA
support both dynamic address allocation and static address assignment.
Multi-VRF - The
existing design of HA NEMOv4 is extended to allow more than one VRF. For more
information on Multi VRF, see
NEMOv4 with Multi-VRFs.
PMIPv6 - Mobile Private Network (MPN) utilized Network Mobility
Services (NEMO) to provide wireless connectivity between Enterprise Core
Network and remote Enterprise sites over 3G/4G network, and supported only IPv4
addressing scheme. To expand the addressing scheme to IPv6, PMIPv6 support is
now added. The LMA functionality will be provided externally by the ASR9000.
Up to 300 virtual routing
tables per context and 64 BGP peers per context.
Up to 5k host routes
spread across multiple VRFs per BGP process. Limited to 6000 pool routes
Up to 2048 VRFs per
Up to 512K NEMO framed
MNPs (Mobile Private Networks) per system.
IETF RFC 3025 (February
2001) "Mobile IP Vendor/Organization Specific Extensions"
Commands used in the configuration samples in this section provide
base functionality to the extent that the most common or likely commands and/or
keyword options are presented. In many cases, other optional commands and/or
keyword options are available. Refer to the
Command Line Interface Reference for complete
information regarding all commands.
To configure the system for NEMO:
Create a VRF on the router and assign a VRF name.
Set the neighbors and address family to exchange routing
information with a peer router.
Redistribute connected routes between routing domains.
Create a NEMO HA.
Save your configuration to flash memory, an external memory
device, and/or a network location using the Exec mode command
save configuration. For additional
information on how to verify and save configuration files, refer to the
System Administration Guide and the
Command Line Interface Reference.