Support for the IR1100X-XP and IR1100X-P Expansion Modules

The IR1101 ISR has an expansion module that adds key capabilities such as an additional pluggable slot supporting LTE and mSATA SSD, SFP and Digital GPIO. These two expansion modules offer the following:

■1 GE SFP

■1 Pluggable slot

■4 GPIO + 1 Return (Digital I/O)

■mSATA SSD slot

Cisco IOS-XE detects the existence of the expansion module at bootup and performs an anti-counterfeit check. If the check passes, the base IR1101 powers up the expansion module and adds the extra capabilities of the expansion module.

The IR1100X expansion modules will be available in the second half of Calendar year 2019. More information can be found in the product data sheet at:

https://www.cisco.com/c/en/us/products/collateral/routers/1101-industrial-integrated-services-router/datasheet-c78-741709.html

When the IR1100X expansion modules become available, installation and configuration details will be available here:

https://www.cisco.com/c/en/us/support/routers/1101-industrial-integrated-services-router/model.html

Smart Licensing Support for Evaluation Expired Syslog after 365 Days

For the 16.11.1 release, evaluation expired syslog messages will be displayed after 365 days, and it is enabled by default. Customers will not see the evaluation period syslog messages for one year. There are no CLI or show command changes.

This feature changes only when the evaluation syslog messages are sent if the product instance is not registered, for example, the license usage is in Evaluation Mode. The actual 90-day evaluation period will not change. The only change is when these evaluation period syslog messages are sent, which is one year from the date the license has actually expired.

This one-year period will include the 90-day evaluation period, such that after the evaluation period expires, the smart agent will not send the evaluation mode syslog messages for another 275 calendar days.

The 90-day evaluation period will still trigger the following events:

■After 90 days of usage the evaluation period will expire.

■The show usage and show status CLI commands will show that the evaluation period has expired.

The following three evaluation period syslog messages are at issue. With the previous 90-day evaluation period, these are sent only if the product instance is not registered. However, with the evaluation expired syslog after 365-days in effect, none of these messages are logged in the syslog.

%SMART_LIC-3-EVAL_EXPIRED

■Evaluation period just expired.

■Sent at the time the evaluation period expires

%SMART_LIC-4-EVAL_WILL_EXPIRE_WARNING

■Evaluation period will expire soon.

■Currently sent prior to expiration on the following schedule.

–60 days before.

–30 days before.

–Every week in the last month

–Every day in the last week

–Every hour on the last day.

%SMART_LIC-4-EVAL_EXPIRED_WARNING

■The evaluation period expired in the past.

■Sent once per week after the expiration. Includes the timestamp of the expiration.

Licensing Event History Logging

In the 16.11.1 release, logging of the licensing event history has been enabled. This feature will always be on for continuous logging of events, and available across a reboot. These logs will be independent of btrace, and will contain:

■Boot log

■Registration & Renewal log

■Authorization log

■The regular log will contain all of the information.

This event history logging would be present across all the subsystems like smart agent, smart licensing infrastructure and platforms.

To display the licensing event history log, execute the show license eventlog CLI.

Sample output from the CLI:

Support for sub-interface on GigabitEthernet0/0/0

The 16.11.1 release supports sub-interfaces and dot1q configuration on the g0/0/0 interface. For example:

Serviceability Features

Cisco IOS-XE show tech-support functionality is extensively used by technical support for various platforms that run IOS-XE and comprises of a library of shell scripts that spawn various show commands to obtain the state of the device for debugging purposes. The tech-support output is very critical in debugging various problems in the system and has been a key component in debug infrastructure.

The show tech-support series of commands has been a part of the Cisco IOS and IOS-XE release since release 4.0(0)N1(1a). The IoT products follow the core IOS-XE software functionality.

The output from the show tech-support command is very long. To better manage this output, you can redirect the output to a file (for example, show tech-support > filename) in the local writable storage file system or the remote file system.

You can use one of the following redirection methods:

> filename — Redirects the output to a file.

>> filename — Redirects the output to a file in append mode.

Examples

This example shows how to display technical support information:

This example shows how to redirect the technical support information to a file:

This example shows how to display the brief technical support information for the device:

This example shows how to display the technical support information for a specific feature:

This example shows how to display the commands used to generate the technical support information:

For Cisco IOS-XE release 16.11.1, improvements were made to improve the monitoring capabilities of forwarding plane (QFP) using CLI and SNMP. show platform resources would display QFP details and an SNMP MIB walk would include all QFP objects including memory related MIB objects. show inventory and show inventory oid will display the related Forwarding processor and its OID information.

show tech-support is enhanced to include the following CLIs:

New CLIs that have been added are:

Detailed information on all of these commands can be found in the Catalyst 9500 Switches Command Reference:

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/16-10/command_reference/b_1610_9500_cr/interface_and_hardware_commands.html#wp3848147936

1	4 GPIO + 1 Return (Digital I/O)
2	SFP Connector
3	Pluggable Module
4	mSATA SSD Slot
5	Digital I/O LEDs

Interface Naming Conventions

With the addition of the new Expansion Modules, there are additional interfaces.

 

Digital I/O

The IR1101 has two different Expansion Modules, the IRM-1100-SP and IRM-1100-SPMI. The IRM-1100-SPMI comes with a Digital I/O connector which has 4 GPIO connections plus 1 Return connection. Both Dry and Wet contacts up to 60Volts.

■Dry contact is isolated from a voltage source (or “No Volt”), with an embedded relay function (NPN transistor), usually used to indicate an event. For example: open/close, alarm.

■Wet contact is a contact with external power (+3.3V to +60V, max 150mA of current allowed at high voltage) applied, usually used to energize something. For example: solenoid, light.

Digital I/O is similar to the ALARM IN and ALARM OUT supported on the IR800 series routers. The differences are that on the IR800 series, ALARM IN is a dedicated input, the ALARM OUT is a dedicated output. With Digital I/O, it can be input or output. ALARM OUT includes a relay to provide the Normally Open (NO) or Normally Close (NC) terminals. Digital I/O does not include a relay.

More information on the Digital I/O hardware capabilities can be found in the IR1101 Industrial Integrated Services Router Hardware Installation Guide.

Configuration Commands

You can set the alarm severity to critical, major, minor, or none. The severity is included in the alarm message when the alarm is triggered.

To configure and show alarms on the IR1101, use the Command Line Interface (CLI). The first step in configuring the Digital I/O is to enable the alarm contact. Failure to enable the alarm contact and configuring either the severity, threshold or trigger first will return the error message "Alarm / Digital IO Port x is not enabled”.

 

Configuration Examples

Configure an alarm.

To show the alarm status:

Example of an alarm being generated:

To show the alarm status during an event:

Example of an alarm being cleared:

Note : There are no traps generated for alarms from the GPIO.

Layer 2 Tunneling Protocol Version 3 (L2TPv3) on SVI Interfaces

SVI on the IR1101 router is also designed to provide basic Layer 3 functions for the Layer 2 switch ports that belong to a specific VLAN. To provide LAN extension between remote sites; SVI is used as the Layer 2 tunnel termination point. The SVI does not provide the same feature set and functions as the integrated Layer 3 Ethernet port of the routers and should not be used to entirely replace the Layer 3 Ethernet ports.

Note : L2TPv3 was already supported on Gigabit Ethernet 0/0/0 on release 16.10.1, and GI0/0/0 sub-interfaces on release 16.11.1.

There will be no changes to existing CLIs. Below are the example CLIs used to configure the Ethernet vlan segment:

Existing features of L2TPv3 ethernet vlan will be same.

For complete information on L2TPv3, see the Wide-Area Networking Configuration Guide: Layer 2 Services.

Serial Relay

Serial Relay service on the IR1101 enables IOx apps to communicate with the Async Serial port (/dev/ttyS1 under IOS-XE). The configuration of Serial Relay service is similar to that of the IR800.

On the IR1101, IOS-XE has complete control over the data path and control path of the Async Serial port. This aspect is essential to other encapsulations supported on the Aysnc port such as PPP, raw-socket, SCADA, etc. The IOx app is never allowed to exercise full control over the device. All data and configurations are passed through IOS-XE before going to the device. Instead of exposing the actual Serial port to IOx apps, the Serial relay service creates a software emulated serial tty device enumerated as /dev/ttyTun0 (shown below). The pair of devices /dev/ttyTun0 and /dev/ttyTun1 represent a data tunnel whose primary function is to act as a pass-through gateway during any data transfer. /dev/ttyTun1 is open by IOS-XE and all the ingress/egress data from IOS to the app uses this device during data transfer. Line 0/0/0 is used to communicated with /dev/ttyTun1. Serial relay service should be configured beforehand to allow the connection between two lines.

 

Data Path:

1. When the IOx app sends a character to /dev/ttyTun0, the tunnel driver automatically pushes the data to /dev/ttyTun1.

2. IOS reads the data which it then passes to the Serial relay service.

3. The Serial relay service retrieves information about the other end of the relay service (Line 0/2/0 in this case) and forwards the data to the Line's buffer.

4. The line driver actively pushes the data into the actual serial device (/dev/ttyS1) based on buffer availability.

5. The reverse path functions the same with the roles of /dev/ttyS1 and /dev/tun0 reversed.

Control Path:

1. When the IOx app performs TCGETS ioctl call on /dev/ttyTun0, the tunnel driver uses /dev/cttyTun to send request to the CTTY handler service running in IOS.

2. CTTY handler service and the kernel driver use a client-server architecture to communicate configuration objects.

3. Upon receiving the request about TCGETS from /dev/cttyTun, the CTTY handler examines the request and requests Line driver to populate the required data into control data structures.

4. Upon receiving the control data structures, CTTY handler sends out a response to /dev/cttyTun which eventually goes back to /dev/ttyTun0.

5. /dev/ttyTun0 passes the control data to IOx app as requested.

6. Similar path can be extrapolated for TCSETS where the CTTY handler requests the Line driver to update the settings of the underneath /dev/ttyS1 driver.

7. Line driver of Line 0/2/0 and driver config on /dev/ttyTun0 are always in sync with each other. Any configuration changes such as baud rate modification is transparently propagated to the Line driver without any additional configuration overhead. This emulates the propagation feature of Serial relay on the IR800 series where the virtual serial port can configure the parameters of the real serial port.

Configuration:

 

Cisco SD-WAN Support

Cisco SD-WAN is a cloud-first architecture that separates data and control planes, managed through the Cisco vManage console. You can quickly establish an SD-WAN overlay fabric to connect data centers, branches, campuses, and co-location facilities to improve network speed, security, and efficiency.​

Cisco SDWAN adopts a cloud based solution, it consists of vOrchestrator, vManage, vSmart and vEdge.

■vOrchestrator is responsible for launching all controllers VMs in the cloud.

■vManage is the management plane for the overall SDWAN solution. It uses netconf/YANG to talk to vEdge devices.

■vSmart is the control plane for the overall SDWAN solution. It talks to the vEdge device, acts as the route reflector, key reflector, and policy engine.

■vEdge is the data plane of the overall SDWAN solution. The IR1101 platform talks to vSmart, vManage, as part of the SDWAN network.

The follow diagram shows the high level architecture of SDWAN:

 

Frequently Asked Questions

Question : What is the minimum cEdge software version supporting SDWAN on the IR1101?

Answer : The minimum cEdge software version supporting SDWAN on the IR1101 is IOS-XE 16.12.1, the ir1101-ucmk9-XX image.

Question : What is the minimum SDWAN controller software version supporting the IR1101?

Answer : The minimum SDWAN controller software version supporting the IR1101 is 19.2.

Question : Where can I find SDWAN documentation?

Answer : Cisco SDWAN documentation is available from

https://www.cisco.com/c/en/us/support/routers/sd-wan/tsd-products-support-series-home.html

https://sdwan-docs.cisco.com/Product_Documentation/Software_Features

Question : Can I use 2 LTE pluggables with SDWAN?

Answer : Cisco IOS-XE SDWAN version 16.12.1 does not support 2 LTE pluggable interfaces. Both the Base or Expansion Module can support 4G module, but still only one 4G module, in current May 2019 vManage and IOS XE 16.12.1 releases.

Question : Can I convert an IR1101 IOS-XE to a cEdge IR1101?

Answer : For migration from Cisco IOS-XE to cEdge image, please refer to

https://www.cisco.com/c/dam/en/us/td/docs/routers/sdwan/migration-guide/SDWAN-migration-guide.pdf

Question : Is IOx supported when running a cEdge image?

Answer : IOx is not supported on the IR1101 SDWAN 16.12.1 version.

All of the technical documentation for Cisco SD-WAN can be found here:

https://www.cisco.com/c/en/us/support/routers/sd-wan/tsd-products-support-series-home.html

mSATA

Mini-SATA, or mSATA, is a low-profile interface connector that enables more effective Serial ATA (SATA) integration in small form-factor drives roughly the size of a business card, such as solid state disks (SSDs).

The IRM-1100-SPMI Expansion Module provides the capability for adding a 100GBmSATA SSD. The PID is IR1100-SSD-100G.

There is a single LED that provides status of the mSATA SSD:

■Off - Not powered on or no activity

■Flashing Green - mSATA being accessed

Highlights of the mSATA Pluggable Module are:

■Provides an additional 100GB of additional flash memory storage

■Main purpose is to provide space to store application data for IOx

■Field Replaceable unit, but is not hot-swappable.

mSATA Partitioning

IOS-XE release 16.11.1 divided the mSATA SSD into 3 partitions. One partition used by IOS-XE and the other two for IOx. IOS-XE release 16.12.1 divides the mSATA SSD into 2 partitions. One for IOS-XE and the other for IOx. Examples used in this document are for release 16.12.1.

■Partition 1:

–Used by IOS-XE

–34GB is allocated to IOS-XE

–Can be accessed using dir msata :

■Partition 2:

–Used by IOx Applications

–64GB is allocated to IOx

–Space allocated can be viewed from IOx CLI

Note : If the customer upgrades from release 16.10.1 or 16.11.1 to 16.12.1, applications should be re-installed due to the partition changes. All the application data will be lost along with the application.

Additional information about the mSATA use can be found in the Cisco IR1101 Integrated Services Router Software Configuration Guide.

New Cellular Pluggable Modules

Release 16.12.1 supports new pluggable modules/modems. The IR1101 with an Expansion Module supports DUAL LTE (Active/Active), DUAL SIM and DUAL Radio.

■Dual LTE (active/active or active/backup) is supported on the IR1101 equipped with an expansion module and two LTE pluggable interfaces. One on the base unit, the other on the expansion module.

■With DUAL SIM, the two SIMs operate in active/backup mode on the single LTE pluggable module. With DUAL Radio the two LTE pluggable modules operate in active/active mode with each of the two SIMs assigned to a specific cellular radio on the DUAL Radio.

See the following table for details on the new SKUs.

SFP Support

The SFP interface on the Expansion Module operates differently than on the Base unit. The SFP interface on the IR1101 base module is part of the combo port (SFP/RJ45) for GigabitEthernet0/0/0. It may be configured as Layer-3 (default) or Layer-2 interface.

The SFP interface on the Expansion Module is only an SFP interface. It is named GigabitEthernet0/0/5, and is a Layer-2 interface. For Layer-3 feature set, it must be assigned to a VLAN interface.

Note : On the Expansion Module, here is no need to explicitly configure the media-type for the SFP. When using the SFP combo interface on the Base, you MUST use the command to enable SFP on the Gi 0/0/0 interface. The command is media type sfp.

Details about the SFP Interface can be displayed using the show interfaces transceiver detail CLI, for example:

You can find all of the supported SFP Interfaces in the IR1101 Industrial Integrated Services Router Hardware Installation Guide

Serviceability features

With additional functionality added to the IR1101 with its Expansion Modules, there have been changes made to some of the CLIs.

■ show platform resources displays QFP details and SNMP MIB walk includes all QFP objects including memory related MIB objects.

■ show inventory and show inventory oid displays the related forwarding processor and its OID information.

■ show led displays what the LED status is on the device.

■ show tech-support is enhanced to include the following CLIs:

Open Caveats for Release 16.9.1

■ CSCvk34807

SCEP authentication/enrollment fails when RA or CA hostname is resolved to an IPv6 address.

Symptoms : Release 16.9.1 only supports SCEP enrollment to RA-CA/IPv4, or RA-CA/hostname-to-ipv4, or RA-CA/IPv6.

Conditions : If the RA-CA hostname is resolved to IPv6 address, SCEP will always fail to resolve the configured RA-CA hostname to the actual IPv6 address, thus causing the SCEP authorization and enrollment to fail.

Workaround : There is no workaround.

■ CSCvj86161

raw-socket: encap raw-tcp default config line with packet-length 0

Symptoms : When you encapsulate raw-tcp to async 0/2/0, it automatically configures the line with raw-socket packet-length 0. This is out of range from <10-1400>.

Workaround : There is no workaround.

Resolved Caveats for Release 16.9.1

There are no open issues at this time.

Open Caveats for Release 16.10.1

There are no open issues at this time.

Resolved Caveats for Release 16.10.1

■ CSCvk34807

SCEP authentication/enrollment fails when RA or CA hostname is resolved to an IPv6 address.

Symptoms : Release 16.9.1 only supports SCEP enrollment to RA-CA/IPv4, or RA-CA/hostname-to-ipv4, or RA-CA/IPv6.

Conditions : If the RA-CA hostname is resolved to IPv6 address, SCEP will always fail to resolve the configured RA-CA hostname to the actual IPv6 address, thus causing the SCEP authorization and enrollment to fail.

Workaround : There is no workaround.

■ CSCvj86161

raw-socket: encap raw-tcp default config line with packet-length 0

Symptoms : When you encapsulate raw-tcp to async 0/2/0, it automatically configures the line with raw-socket packet-length 0. This is out of range from <10-1400>.

Workaround : There is no workaround.

Open Caveats for Release 16.11.1

There are no open issues with this release.

Resolved Caveats for Release 16.11.1

There are no closed issues with this release.

Open Caveats for Release 16.12.1

■ CSCvp18328

The speed range should only show 10 or 100 for FE ports in the IR1101 switchport template.

Symptom : The FE ports can only be set to 10 or 100 Mbps. The template allows the full range of 10/100/1000/10000.

Workaround : Only use the 10 or 100 Mbps selections.

■ CSCvq13666

On the IR1100 with the cEdge image, the upgrade fails due to insufficient disk space.

Symptom : Occurs with an image upgrade of cEdge devices using vManage and returns a failure of insufficient flash space.

Workaround : There are two options:

1. vManage checks required diskspace before downloading the image and taking 40 min time and 4G bandwidth. First delete files to make room.

2. Limit tracelog on the flash to retain 2x 430MB (current image size) free space.

■ CSCvp48383

vManage: GPS enabling feature from vManage template fails.

Symptom : From AWS vManage, attempting to attach device-template, including a Cellular GPS feature-template, fails. Removing the GPS template allows the attach of template to progress to the next stage where it shows the configuration differences. With the GPS feature-template selected, it always shows as failed.

Workaround : Remove the GPS template.

■ CSCvp36305

vManage: CPU util shown by CLI doesn't match reported by vManage realtime.

Symptom : The CPU util doesn't match when comparing what was on IR1101 CLI sh plat soft status control brief with the realtime device CPU util on vManage. The vManage seems to be reporting CPU from sh proc cpu older IOS version CLI.

Workaround : Check each device using CLI commands

■ CSCvp48578

vManage: Allow cellular modem firmware image upload and upgrade via vManage.

Symptom : Currently, vManage doesn't have a device/feature template or Software Repository + Upgrade mechanism of cellular modem.

Workaround : There is no workaround, functionality to be added in a future release.

■ CSCvp48578

vManage: Allow cellular modem firmware image upload and upgrade via vManage.

Symptom : Currently, vManage doesn't have a device/feature template or Software Repository + Upgrade mechanism of cellular modem.

Workaround : There is no workaround, functionality to be added in a future release.

■CSCvq64265

“Found no Snowfinch (MCU) on this system” message displayed at bootup.

Symptom : At boot, “Found no Snowfinch (MCU) on this system” is displayed in the completion text.

Workaround : There is no workaround, the text does not effect functionality and will be corrected in a future release.

Resolved Caveats for Release 16.12.1

■ CSCvo24734

Gig0/0/0 WAN port comes up administratively down by default, pnp failure.

Open Caveats for Release 16.12.3

None for this release.

Resolved Caveats for Release 16.12.3

■ CSCvq13666

IR1100 cEdge: Image upgrade fails due to insufficient disk space.

■ CSCvs37437

Changed the out of the box baud rate in rommon to be 9600 baud.

■ CSCvp31354

VPN LED always ON even when the tunnel is down.

Open Caveats for Release 16.12.4

None for this release.

Resolved Caveats for Release 16.12.4

■ CSCvs73854

SPAN capture in both directions is only capturing in one way.

Symptoms : SPAN capture in IR1101 is only capturing in one way even if it is configured to capture in both directions. Only the traffic that goes out of the monitored interface is captured.

Open Caveats for Release 16.12.5

None for this release.

Resolved Caveats for Release 16.12.5

■ CSCvu78908

A debugging shell is started on the USB console.

Symptoms : This is a modification on the product to adopt new secure code best practices to enhance the security posture and resiliency of the product.

Conditions : Device running with the default configuration.

Workaround : Not available or not applicable.

■ CSCvw57687

Multicast throughput is slower.

Symptoms : multicast had a different bandwidth (traffic rate) when there is a receiver on the same VLAN or not. Checked the packet number and it was not matched.

Conditions : When there is no receiver on the same VLAN with a source, the traffic rate is reduced by around 1M. Source traffic rate was 50M.