IoT Edge Router 2.5

Modem Replacement Use Case Application Note

SMART CITY EDGE CONNECTIVITY PROVIDED BY THE IOT EDGE ROUTER FOR MODEM REPLACEMENTS

The Itron IoT Edge Router can be used to replace existing cellular modems in customer network environments. This document addresses this use case from an installation and configuration perspective. Most of this document describes IPv6 modem replacements specifically. Details specific to IPv4 modem replacement are covered in the section IPv4 Modem Replacement Specifics. Included in this document:

  • About the IoT Edge Router
  • About the Cellular Modem Use Case
  • Assumptions
  • Architecture
  • Installation
  • Configuration
  • End Device Setup
  • Management, Operation, and Maintenance
  • IPv4 Modem Replacement Specifics
  • Contact Itron

About the IoT Edge Router

The IoT Edge Router is a hardware device that enables customers to securely connect a variety of city and utility devices—including those that require legacy-protocol support— across a common RF mesh network infrastructure using proven open standards and interfaces, and providing networking protocol support. Support includes a secure and standards-based architecture for both IPv4 and IPv6 communications with Linux-based network-edge computing capability.

The device is intended for existing Itron deployments where cities wish to host additional city-focused applications on their network. In typical scenarios, cities are able to connect parking-services kiosks or digital signage to their network, replace existing cellular modems, or connect Citilog XCam smart cameras mounted on street lights to aid in switching or dimming lights in response to real-time traffic conditions. For information about using the XCam with the IoT Edge Router, see Chapter 3 Using the IoT Edge Router.

The IoT Edge Router solution can:

  • Provide wired-device connectivity to Itron for devices that support Ethernet or HDMI connections.
  • Provide IPv6- or IPv4-device connectivity to Itron. IPv4 is currently most common, and, in these cases, the IoT Edge Router is responsible for encapsulating IPv4 packets in an IPv6 wrapper and transporting payloads across the network.
  • Provide a back-end application responsible for de-capsulation of connected-device traffic allowing third-party devices to access a third-party cloud through an Address Family Transition Router (AFTR).
  • Provide an option for replacing existing cellular modems.

About the Cellular Modem Use Case

Currently, cellular modems are typically used for transmitting between devices on a mesh network and the back office. This can be a costly solution, with these costs applied on a monthly basis, and using a device such as the IoT Edge Router can help to reduce these costs. Finally, cellular solutions can use private networks with static IP addresses, which adds to customer monthly costs.

From a reliability perspective, the IoT Edge Router can provide improved uptime and reachability across the network when compared with cellular solutions. Also, cellular solutions generally do not provide service level agreements (SLAs), whereas these can be provided by Itron for the IoT Edge Router modem replacement solution. This can be essential for ensuring service predictability to those responsible for the network.

The IoT Edge Router can be used instead of cellular modems, for example, for connecting to digital signs, cabinet controllers for street lights, electric vehicle charging controllers, bicycle rental stations, and traffic controllers.

Assumptions

  • Details in this document assume that you are using the first production release of the IoT Edge Router and Itron Solutions UtilOS 3.10.1 firmware.
  • This document does not cover AT commands or any other modem-specific details. Rather, it discusses using the IoT Edge Router in cases where the customer is deploying a 3G-based solution to provide IPv4 or—in this case—IPv6 connectivity.

Architecture

As the following figure shows, at a high level, the AP meshes with IoT Edge Routers and connects back to the back office via a standard AP IPsec 6 in 4 tunnel terminated on a Cisco RFC 2893 router. This provides IPv6 connectivity from the IoT Edge Router to the Cisco router in the data center. Then the customer device IPv6 prefixes from the Cisco router are routed to the local LAN so there is end-to-end IPv6 connectivity from the IoT Edge Router to the back office and Registrar.

In the following figure, note that the "consumer application" could be a central management software (CMS), such as Itron Streetlight.Vision (SLV), or it could be any application that communicates directly to the "customer device" via IPv6. In fact, the "consumer application" here could be in the same back office segment as the Itron components (mainly Registrar and TMB), or could be in the customer back office or even on the Internet (though there are security considerations in that case).

  • The IoT Edge Router can be provisioned with the IP address of the AFTR in the network infrastructure (note that pre-provisioning is not provided during device manufacturing), and it registers with the nearest Access Point either to access hosts on the Internet or in the back-office (where DNS and other back-office services complete the registration process).
  • The AFTR is also provisioned with an IPv4 network address translation (NAT) pool that is used for devices connected to the IoT Edge Router. These steps complete device registration for Itron.

Installation

At a high level, installation requires the standard setup procedure for the AP (including configuring the IPsec tunnels) and the Cisco IPsec router.

Configuration

IoT Router IPv6 Prefix Configuration

The only requirement for the IoT Edge Router is to setup the IPv6 prefix that will be used by the IPv6 end devices that are connected to the IoT Edge Router; this is used to generate an IPv6 address for itself. This prefix usually comes from a larger block of IPv6 address space (a /60, for example).

On the IoT Edge Router, you use the new network_prefix Net Manager command. You can perform this locally on the IoT Edge Router or remotely against the IPv6 address of the IoT Edge Router. The following example is for setting it locally (while logged into the IoT Edge Router):

$ net_mgr_3_10_1 -i iotr network_prefix show

Secondary Network Prefix: Not Set

$ net_mgr_3_10_1 -i iotr network_prefix set fdc9:ccbe:1dc7:fc22::/64

AP Configuration

On one or more APs that are providing communications for the IoT Edge Router, you need to enable RIPng on each AP. This is required to support IoT Edge Router IPv6 subnet/prefixes for edge networks/hosts.

Before proceeding, note that a unique IPv6 network prefix must be selected for the v6 network on the "Ethernet" side of the IoT Edge Router. On the IoT Edge Router itself, the NIC must be configured with an address from this unique IPv6 prefix by following the RFC 4193 standard.

One can be calculated here:

http://unique-local-ipv6.com/

or by following the standard RFC 4193.

Then the prefix must be set on each IoT Edge Router using the following Net Manager command:

net_mgr -d $IP iotr network_prefix set xxxx:yyyy:zzzz:abcd/64

Historically, users usually set the subnet portion (abcd in the above command string) to match the last four digits of the interface’s MAC address. However, Itron is currently developing a more comprehensive administrative process for selecting and tracking such prefixes (to prevent re-use/conflict).

To enable RIPng for IoT Edge Router prefix/subnet support for SYSVAR configured APs

  1. Set the RIPng (IPv6) update interval to reduce traffic on the WAN.

net_mgr -d $IPv6 conf rip v6_period 180

  1. Enable RIPng (IPv6).

net_mgr -d $IPv6 conf rip v6_on 1

  1. Restart the AP, and wait for it to re-establish communications with the back office (expect this to take a number of minutes).

net_mgr -d $IPv6 restart now

  1. Verify that RIPng for IPv6 is working.

net_mgr -d $IPv6 stat ripv6

To enable RIPng for IoT Edge Router prefix/subnet support for Lua-script configured APs

  1. Create a new Lua init script called ap_init-ripng.

-- enable RIPng (IPv6) to support IoTR IPv6 subnet(s)

rip.on=0 -- disable rip v4

rip.v6_period=180 -- set ripv6 update period (def 30 seconds)

rip.v6_on=1 -- enable rip v6

  1. Upload the new Lua init script.

>net_mgr -d $IPv6 lua config upload_init ap_init-ripng ap_init-ripng

  1. Determine which Lua init and config scripts are already loaded (note that vars need to be loaded before the script that uses them).

net_mgr -d $IPv6 lua config list

  1. Update Lua setboot to include the previously loaded scripts and the new script

net_mgr -d $IPv6 lua config setboot ap_var_6in4only_gsm_2e ap_init ap_init-ripng apconfig_new4

  1. Restart the AP, and wait for it to re-establish communications with the back office (expect this to take a number of minutes).

net_mgr -d $IPv6 restart now

  1. Check to see if all Lua init and config scripts loaded successfully.

net_mgr -d $IPv6 lua config list

  1. Confirm the scripts.

net_mgr -d $IPv6 lua config confirm

  1. Verify that RIPng (V6) is working.

net_mgr -d $IPv6 stat ripv6

Tunnel Router Configuration

You must enable RIPng on each IPsec tunnel in order to enable routing for the IPv6 prefix. Following is an example of this. Note you also have to setup routing on the outgoing interface (through, for example, OSPF or static routes).

interface Tunnel1993

 description "Bridge 001350fffe101993"

 no ip address

 ipv6 enable

 ipv6 rip ripng enable

 tunnel source GigabitEthernet0/1

 tunnel mode ipv6ip

 tunnel destination 192.168.1.93

You must also set the RIP timers. By default, they are send too much data for cellular connections. Set these for both cellular and Ethernet APs if you have a mixed deployment. The defaults are fine for an all Ethernet deployment (although this is rarely the case).

ipv6 router rip RIP4IOT

timers 180 720 540 1440

Ensure that RIP updates are permitted to RIPng multicast address. The following describes the required configuration if RIPng multicast access is missing. [CUSTOMER_CODE] is a variable, and it should match the Remedy customer code.

ipv6 access-list [CUSTOMER_CODE]_IN6

remark "IPv6 rule to allow RIPng multicast"

permit ipv6 any host FF02::9

!

ipv6 access-list [CUSTOMER_CODE]_OUT6

remark "IPv6 rule to allow RIPng multicast"

permit ipv6 any host FF02::9

In order to be efficient if you have a large number of these tunnel routes, you should add RIP summarization.

Full Router Configuration Example

In the following example:

  • PAR indicates a specific deployment name.
  • PROD01 indicates that the configuration is for a specific production environment.
  • RED_RO6 indicates to Redistribute RIP to OSPF for IPv6.
  • RED_SO4 indicates to Redistribute Static to OSPF for IPv4.

 

!

ipv6 router rip RIP6_PAR

#Neteng team suggested to use standard naming convention which is “RIP6_[CUSTOMER_CODE]”

timers 180 720 540 1440

poison-reverse

!

interface Tunnel9901

description "Evesa Bourdelle (LAB) FD05:A40B:7AE7:9901:213:50ff:fe10:c1a1"

no ip address

ipv6 enable

ipv6 rip RIP6_PAR enable

#Summarize IOT Prefix RIP route towards AP

ipv6 rip RIP6_PAR summary-address FD05:A40B:6F6::/48

 #Summarize NAN Prefix RIP route towards AP, Not sure this is required, will be tested in lab soon. Mesh at some point in the future may support peer to peer networking.

ipv6 rip RIP6_PAR summary-address FD05:A40B:6F6::/48

 tunnel source 10.47.112.0

tunnel mode ipv6ip

tunnel destination 10.1.10.36

!  

ipv6 prefix-list RED_RO6 seq 10 permit FD05:A40B:6F6::/48 ge 64 le 64   

!

route-map RED_RO6 permit 10

match ipv6 address prefix-list RED_RO6

set metric 10

set metric-type type-2

!

ipv6 router ospf 127

router-id 10.47.112.9

passive-interface default

no passive-interface GigabitEthernet0/0

no passive-interface GigabitEthernet0/1

redistribute static route-map RED_SO6

redistribute rip RIP6_PAR route-map RED_RO6

 

ipv6 access-list PAR_IN6

remark "IPv6 rule to allow RIPng multicast"

permit ipv6 any host FF02::9

!

ipv6 access-list PAR_OUT6

remark "IPv6 rule to allow RIPng multicast"

permit ipv6 any host FF02::9

Firewall Configuration Considerations and Example

Note the following considerations:

  • Itron normally blocks all ports from the back office to the NAN except ports in the range of 645–648.
  • Assuming that your device uses a particular port (for example, port 8080 for certain cabinet controllers) and the IoT Edge Router status monitor uses port 8443, you need to open ports 8080 and 8443.

In the following example:

  • PAR indicates a specific deployment name.
  • PROD01 indicates that the configuration is for a specific production environment.

 

Firewall Changes

 

!

object network OBJ6_PAR_PROD01_IOT

subnet fd05:a40b:6f6::/48

description "PAR_PROD01 IOT Prefix" (New prefix assigned to the Ethernet side of IoT)

!

object-group service IOTR_ADMIN_TCP tcp

description "TCP Ports allowed to manage IoT router"

port-object eq 2022

!

access-list PAR_PROD01_IN extended permit tcp object OBJ6_PAR_PROD01 object OBJ6_SLN_PROD01_NAN object-group IOTR_ADMIN_TCP

access-list PAR_PROD01_IN extended permit icmp6 object OBJ6_PAR_PROD01 object OBJ6_PAR_PROD01_IOT

access-list PAR_PROD01_IN extended permit tcp object OBJ6_PAR_PROD01 object OBJ6_PAR_PROD01_IOT object-group ILON_TCP

!

access-list OUTSIDE_IN extended permit icmp6 object OBJ6_PAR_PROD01_IOT object OBJ6_PAR_PROD01

access-list OUTSIDE_IN extended permit icmp6 object OBJ6_PAR_PROD01_IOT object OBJ6_PAR_DMZ_PROD01

access-list OUTSIDE_IN extended permit tcp object OBJ6_PAR_PROD01_IOT object OBJ6_PAR_DMZ_PROD01 object-group ILON_TCP

!

access-list PAR_DMZ_PROD01_IN extended permit icmp6 object OBJ6_PAR_DMZ_PROD01 object OBJ6_PAR_PROD01_IOT

access-list PAR_DMZ_PROD01_IN extended permit tcp object OBJ6_PAR_DMZ_PROD01 object OBJ6_PAR_PROD01_IOT object-group ILON_TCP

!

end

End Device Setup

The end device connected to the IoT Edge Router via the Ethernet interface needs to support stateless address autoconfiguration (SLAAC). This standards-based IETF protocol allows IPv6 end devices to configure their own IPv6 interfaces based on a IPv6 prefix announced on the network by the IoT Edge Router. Typically, the end device concatenates the prefix with their local MAC address to form the full IPv6 address.

Management, Operation, and Maintenance

For any questions about or assistance with managing, operating, and maintaining the IoT Edge Router not cover in the document or in the IoT Edge Router Installation and User Guide, contact your Itron representative.

IPv4 Modem Replacement Specifics

Note: The information in this section is also provided in the IoT Edge Router Installation and User Guide.

Installation/Configuration

From an end user perspective, refer to the installation information in the IoT Edge Router Installation and User Guide.

Configure the IoT Edge Router for AFTR

The net_mgr command to set the parameters is as follows:

net_mgr [-h cmd] [-d] v6|-i iotr <option>action> [<value>]

-h cmd Help for a command, or general help

-d address of the NCC you are messaging

-i RF card you are messaging

Possible IoT Edge Router options and actions are as follows:

aftr_address set <IPv6_address>

Set DSLITE AFTR IPv6 address

aftr_address delete

Delete the DSLITE AFTR address

aftr_address show

Show the DSLITE AFTR address

Back Office Requirements

  • Customers can use OpenVPN (or a similar tool) on the third-party device to achieve inbound IPv4 connectivity from the Internet/Back Office software to the IoT Edge Router.
  • SaaS customers use a shared AFTR in the Itron San Diego data center.
  • Licensed and Managed customers require their own AFTR/A10vThunder.