IOx

Application Networking

The application hosting framework (CAF) running on an IOx node creates and manages multiple logical networks depending on the configuration on the platform. Typically, at least one bridge and one nat network is available. Each logical network is identified by a unique name.

Code Snippet

Copy$ ioxclient platform network  list_networks
Currently using profile :  local
Command Name: plt-network-list_networks
List of networks:
 1. name=>iox-bridge0     :: type=>bridge
 2. name=>iox-nat0        :: type=>nat

At the time of activation, the administrator can associate each interface requested by the application to a logical network available on the platform.

How will your app get ip address?

Applications will be provisioned with IP address using DHCP.

MAC address for applications

CAF manages MAC addresses for each interface requested by the application. The MAC address assigned to the application will always be a Locally Administered Address

Depending on the network associated with the interface, the MAC address assignment and subsequent IP address assignment differs.

Bridge network

CAF assigns a random mac address. It will be in the range 52:54:dd:[0x01-0xFF]:[0x01-0xFF]:[0x01-0xFF]
Application will get IP address from the configured DHCP server. DHCP can be configured as a local pool on IOS, or as a relay to an external DHCP server.
The IP address assigned in this case will be "non local" to the hosting environment.
Since the IP address is non local, the application's requested ports will be exactly same as what will be assigned.
Corresponding NAT rules may need to be configured on IOS to allow traffic to the ports requested by the application.
MAC address reservation or static IP mapping should be configured on the DHCP server. CAF will only ensure that the application gets the same MAC address across its lifecycle operations (start/stop/upgrade/activate/deactivate etc.,)

NAT network

CAF assigns a free MAC address from a pool of addresses between 52:54:99:99:00:00 to 52:54:99:99:00:{len_ip_range}
len_ip_range is the number of IP addresses in the configured NAT IP range in CAF's network configuration
The IP address assigned to the interface will be locally managed by CAF based on the range configured.
IP address will be local to the hosting environment
Each tcp port requested by the application will be mapped to an available higher order port on the system (external tcp port typically between 40000-41000)
Each udp port requested by the application will be mapped to an available higher order port on the system (external udp port typically between 42000-43000)
One can override auto-assignment of external NAT ports while activating the app on a nat network. See Custom port mapping below.
CAF manages the required NAT rules on the hosting environment so that the traffic gets to the application ports
Corresponding NAT rules may need to be configured on IOS to allow traffic to the higher order ports associated to the application.

The associated network, ip address, requested port, external port and other network details are available via CAF APIs. Below are some examples showing the application information when configured with both bridge and nat network.

Notice the differences specifically in the "networkInfo" section where the network-name, port mapping, ip address, mac address etc., differs between bridge and nat networks.

Bridge Network

Code Snippet

Copyioxclient app info nt
Currently using profile :  local
Command Name: application-info
Details of App : nt
-----------------------------
{
 "appCustomOptions": "",
 "appType": "paas",
 "author": "Cisco Systems",
 "authorLink": "http://www.cisco.com",
 "dependsOn": {
  "cartridges": [
   {
    "id": "urn:cisco:system:cartridge:language-runtime:python",
    "version": "2.7"
   }
  ]
 },
 "description": "Provides a REST end point on port 9000 and also tests outbound traffic",
 "id": "nt",
 "is_service": false,
 "name": "PyNetTest",
 "networkInfo": {
  "eth0": {
   "ipv4": "192.168.196.208",
   "ipv6": null,
   "libvirt_network": "dpbr_0",
   "mac": "52:54:DD:34:BB:AF",
   "mac_address": "52:54:dd:34:bb:af",
   "network_name": "iox-bridge0",
   "port_mappings": {
    "tcp": [
     [
      9000,
      9000
     ]
    ],
    "udp": [
     [
      10000,
      10000
     ]
    ]
   }
  }
 },
 "resources": {
  "cpu": 200,
  "disk": 10,
  "memory": 64,
  "network": [
   {
    "interface-name": "eth0",
    "network-name": "iox-bridge0",
    "ports": {
     "tcp": [
      9000
     ],
     "udp": [
      10000
     ]
    }
   }
  ],
  "profile": "c1.small",
  "vcpu": 1
 },
 "state": "RUNNING",
 "toolkitServicesUsed": null,
 "version": "2.5"
}

NAT Network

Code Snippet

Copy~ ❯❯❯ ioxclient app info nt
Currently using profile :  local
Command Name: application-info
Details of App : nt
-----------------------------
{
 "appCustomOptions": "",
 "appType": "paas",
 "author": "Cisco Systems",
 "authorLink": "http://www.cisco.com",
 "dependsOn": {
  "cartridges": [
   {
    "id": "urn:cisco:system:cartridge:language-runtime:python",
    "version": "2.7"
   }
  ]
 },
 "description": "Provides a REST end point on port 9000 and also tests outbound traffic",
 "id": "nt",
 "is_service": false,
 "name": "PyNetTest",
 "networkInfo": {
  "eth0": {
   "ipv4": "192.168.223.10",
   "ipv6": null,
   "libvirt_network": "dpbr_n_0",
   "mac": "52:54:99:99:00:00",
   "mac_address": "52:54:99:99:00:00",
   "network_name": "iox-nat0",
   "port_mappings": {
    "tcp": [
     [
      9000,
      40028
     ]
    ],
    "udp": [
     [
      10000,
      42028
     ]
    ]
   }
  }
 },
 "resources": {
  "cpu": 200,
  "disk": 10,
  "memory": 64,
  "network": [
   {
    "interface-name": "eth0",
    "network-name": "iox-nat0",
    "ports": {
     "tcp": [
      9000
     ],
     "udp": [
      10000
     ]
    }
   }
  ],
  "profile": "c1.small",
  "vcpu": 1
 },
 "state": "RUNNING",
 "toolkitServicesUsed": null,
 "version": "2.5"
}

Understanding Network Time Protocol

The Network Time Protocol (NTP) is designed to time-synchronize a network of devices. NTP runs over User Datagram Protocol (UDP), which runs over IP. NTP is documented in RFC 5905.

An NTP network usually gets its time from an authoritative time source, such as a radio clock or an atomic clock attached to a time server. NTP then distributes this time across the network. NTP is extremely efficient; no more than one packet per minute is necessary to synchronize two devices to within a millisecond of one another.

NTP uses the concept of a stratum to describe how many NTP hops away a device is from an authoritative time source. A stratum 1 time server has a radio or atomic clock directly attached, a stratum 2 time server receives its time through NTP from a stratum 1 time server, and so on. A device running NTP automatically chooses as its time source the device with the lowest stratum number with which it communicates through NTP. This strategy effectively builds a self-organizing tree of NTP speakers.

NTP avoids synchronizing to a device whose time might not be accurate by never synchronizing to a device that is not synchronized. NTP also compares the time reported by several devices and does not synchronize to a device whose time is significantly different than the others, even if its stratum is lower.

The communications between devices running NTP (known as associations) are usually statically configured; each device is given the IP address of all devices with which it should form associations. Accurate timekeeping is possible by exchanging NTP messages between each pair of devices with an association. However, in a LAN environment, NTP can be configured to use IP broadcast messages instead. This alternative reduces configuration complexity because each device can simply be configured to send or receive broadcast messages. However, in that case, information flow is one-way only.

The time kept on a device is a critical resource; you should use the security features of NTP to avoid the accidental or malicious setting of an incorrect time. Two mechanisms are available: an access list-based restriction scheme and an encrypted authentication mechanism.

Cisco’s implementation of NTP does not support stratum 1 service; it is not possible to connect to a radio or atomic clock. We recommend that the time service for your network be derived from the public NTP servers available on the IP Internet.

For more information, refer to the Network Time Protocol: Best Practices White Paper at: https://www.cisco.com/c/en/us/support/docs/availability/high-availability/19643-ntpm.html

For information about NTP on the specific IoT platforms, see the following pages under the Platforms section:

Custom Port Mapping

For an app that is activated on a NAT network, CAF uses internal ports from the application yaml and auto assigns corresponding external ports for NAT translation.

With Custom Port mapping, it is possible to assign custom external ports to the application while being activated on a NAT network.

During activation REST call, an activation payload is passed to CAF in the following json format:

Code Snippet

CopyExample Activate payload:
        {
            "resources": {
            "profile": "custom",
            "cpu": "50",
            "memory": "50",
            "disk": "100",
            "network": [{"interface-name": "eth0", "network-name": "iox-nat0", "port_map":{ } }]
            }
        }

When "port_map" in above activate payload is empty { }, or when it is not provided at all (legacy behavior), auto external port mapping is done by CAF.
"port_map": {"mode": "auto"} can also be provided in activate payload to achieve the same auto port mapping behavior. (All app ports auto mapped)
In auto port mapping mode, tcp ports defined in app yaml will get external ports from tcp port range (typically between 40000-41000) and udp ports defined in app yaml will get external ports from udp port range (typically between 42000-43000).
"port_map": {"mode": "1to1"} can be used to force all application ports to be mapped to 1to1 external nat ports

Defining Custom ports:

"port_map" in activate payload can provide custom mappings to override a subset of application ports.

Example 1 - override auto mode with custom mapping:

Code Snippet

Copy"port_map": {
        "mode": "auto",
        "tcp": {
        "9000": "15000",
        "10100-10200": "20100-20200"},
        "udp": {
        "19000": "25000"}
        }
tcp port 9000 is custom mapped to external port 15000
tcp port range "10100-10200" is custom mapped to external port range "20100-20200"
udp port 19000 is custom mapped to external port 25000
Any tcp, udp ports not mentioned in the "port_map" get auto external ports because "mode" is auto.
This way, not all mappings need to be passed to CAF, just the ones that override the given mode.

Example 2 - override 1to1 mode with custom mapping:

Code Snippet

Copy"port_map": {
        "mode": "1to1",
        "tcp": {
        "9000": "15000",
        "10100-10200": "20100-20200"},
        "udp": {
        "19000": "25000"}
        }
tcp port 9000 is custom mapped to external port 15000
tcp port range "10100-10200" is custom mapped to external port range "20100-20200"
udp port 19000 is custom mapped to external port 25000
Any tcp, udp ports not mentioned in the "port_map" get 1to1 external ports because "mode" is 1to1.
This way, not all mappings need to be passed to CAF, just the ones that override the given mode.

IOx Advanced Networking Concepts:

The internal logical networks that you can activate the interfaces of your app on are provided by IOx when it comes up on a particular platform. Typically, one bridge and one nat network is available by default as explained above. This should be enough for outside connectivity of most applications.

IOx's nat and bridge logical networks depend on internal bridges that IOx creates. Typically default networks iox-bridge0 and iox-nat0 go through a bridge named svcbr_0. You can see more information about the iox bridges and the logical networks that are tied to them using ioxclient:

Code Snippet

Copy$ ioxclient platform network bridge list
Currently active profile :  239
Command Name: plt-network-bridge-list
List of hosting bridges:
[
 {
  "bridge_ip": {
   "mode": "dhcp"
  },
  "default_mode": "bridge",
  "description": "Default Network",
  "dynamically_created": false,
  "external_interface": "VPG0",
  "interface": "svcbr_0",
  "interface_info": {
   "interface_name": "svcbr_0",
   "ipv4_address": "192.168.0.3",
   "ipv6_address": "fe80::200:bbff:febb:0/64",
   "mac_address": "00:00:bb:bb:00:00",
   "status": "UP",
   "subnet_mask": "255.255.255.0"
  },
  "lease_info": {
   "dns": "171.70.168.183",
   "domain_name": "\"cisco.com\"",
   "fixed_address": "192.168.0.3",
   "routers": "192.168.0.1",
   "subnet_mask": "255.255.255.0"
  },
  "logical_network_info": {
   "iox-bridge0": {
    "type": "bridge"
   },
   "iox-nat0": {
    "gateway_ip": "192.168.10.1",
    "ip_end": "192.168.10.30",
    "ip_range": "192.168.10.2-192.168.10.30",
    "ip_start": "192.168.10.2",
    "setup_private_routing": true,
    "subnet_mask": "255.255.255.224",
    "type": "nat"
   }
  },
  "supported_modes": [
   "nat",
   "bridge"
  ],
  "vlan_id": null
 }
]

Creating an additinal IOx bridge and Associated Logical Networks:

This feature is enabled in limited number of platforms (eg. IE4K) where IOx allows the administrator to create additional bridges and associated logical networks for app connectivity. If your application's usecase requires this, read on.

ioxclient example to create additional iox bridge:

Code Snippet

Copy$ ioxclient platform network bridge create
NAME:
   create - Create logical networks

USAGE:
   command create <json_file_with_input>

DESCRIPTION:

To create a network, pass a JSON file containing appropriate payload.
Below is a sample payload.
{
        "description": "Dynamic Network",
        "vlan_id": "10",
        "external_interface": "intsvc0",
        "supported_modes": ["nat", "bridge"],
        "bridge_ip": {
                "mode": "static",
                "ip": "192.168.0.15",
                "subnet_mask": "255.255.255.0",
                "bridge_gw_ip": "192.168.0.1",
                "dns": "8.8.4.4",
                "domain": "abc.com"
        },
        "nat": {
                "nat_range_cidr": "192.168.10.32/27"
        }
}
*vlan_id is optional
*mode can be static or dhcp. In case of dhcp, ip, bridge_gw_ip, dns, domain etc., are not needed.

vlan_id is optional
supported_modes can be nat only, bridge only or both nat and bridge.
bridge_ip is only needed if nat is one of the supported modes. If only bridge mode is supported bridge_ip is ignored.
bridge_ip mode can be static or dhcp. In case of dhcp, ip, bridge_gw_ip, dns, domain etc., are not needed.
If nat is one of the supported modes, nat_range_cidr needs to be provided. This defines the range of ip addresses that apps get assigned on that network.
external_interface the bridge uses is platform specific and should be obtained from platform documentation.

Editing an IOx bridge:

Only editing Description and nat range of a bridge is currently allowed.

Here is ioxclient example:

Code Snippet

Copy$ ./ioxclient platform network bridge edit
Insufficient Args.

NAME:
   edit - Edit information pertaining a bridge

USAGE:
   command edit <bridge_id> <json_file_with_input>

DESCRIPTION:

Currently it is allowed only to change description and nat range of a network.
Below is a sample JSON payload.
{
        "description": "Dynamic Network",
        "nat": {
                "nat_range_cidr": "192.168.10.32/27"
        }
}

Deleting an IOx bridge:

Only deleting dynamically created bridges is allowed. Deleting bridges that come with IOx by default is not allowed.
Deleting a bridge also deletes its associated logical networks (nat and bridge)
If an app is activated on any of the logical networks of the hosting bridge, deleting that bridge is not allowed.

ioxclient example:

Code Snippet

Copy$ ./ioxclient platform network bridge delete svcbr_0
Currently active profile :  239
Command Name: plt-network-bridge-delete
Error. Server returned 500
{
 "description": "Cannot delete default network svcbr_0.",
 "errorcode": -1034,
 "message": "Error deleting network: Cannot delete default network svcbr_0."
}

Statically assigning IP addresses

Administrators can assign a static IP address to the interfaces requested by the application.

Below are the rules for static ip address assignment:

Static IP address allocation is ONLY APPLICABLE for container based applications (PaaS, Docker, LXC)
Will not work for VM style applications at the moment.
The interface MUST be associated to a BRIDGE network.
Interfaces that are associated to a NAT network cannot be assigned with static ip address.
Administrator should provide the following data at the time of deployment:
ipv4 address (Mandatory)
prefix (Mandatory, in CIDR notation)
DNS Servers: A list of DNS servers can be specified (Optional)
Gateway address: If the interface has to be marked as default gateway, next hop address (gateway) must be specified. Else, it is optional.
CAF doesn't perform any kind of validation on the provided values. For instance, if admin provides a static address that cannot be reached, CAF will not be able to detect this and warn.

Note that currently, it is possible to set static ip address via Fog director and ioxclient. Support from Local Manager will be available shortly.

Here is a sample activation payload that can be used with ioxclient:

Code Snippet

Copy{
    "resources": {
        "profile": "c1.small",
        "network": [{
            "interface-name": "eth0",
            "network-name": "iox-bridge0",
            "mode": "static",
            "ipv4": {
                "ip": "1.1.1.1",
                "prefix": "24",
                "gateway": "1.1.1.2",
                "dns": "1.1.1.2",
                "default": true
            }
        }]
    }
}

IPv6 Support

IPv6 support is added for IR800 platforms at this point.

Why do we need IPv6

Provides much more IP address space for networked devices in the Internet world
Simplified Network Configuration
Eliminates need of NATing which we generally do in IPv4 (Because of the scarcity of IPv4 addresses, much of the Internet relies on NAT (Network Address Translation). With IPv6, every device can literally have its own unique public IP address.)
Easy IPv6 address assignment with IPv6 auto configure option

IPv6 address assignment options

There are different ways of IPv6 address assignment for hosts. Here we are describing some of the options.

** Stateless Address Auto Configuration (SLAAC)**

Stateless address auto-configuration (SLAAC) provides a convenient method to assign IP addresses to IPv6 nodes.
This method does not require any human intervention from an IPv6 user.
Nodes on the network listen for ICMPv6 Router Advertisements (RA) messages periodically sent out by routers on the local link, or requested by the node using an RA solicitation message.
Then nodes create an IPv6 address by combining the MAC address on Ethernet interfaces plus the Link Prefix obtained via the Router Advertisement.

** Statefull IPv6**

It functions exactly the same as IPv4 DHCP in which hosts receive both their IPv6 address and additional configuration options, usually like DNS, NTP, etc from the DHCP server.

** Static IPv6 address assignment**

This is same as IPv4, we can assign static IPv6 address to IOx apps.

What capabilities of IPv6 are supported

Static, auto-configured and DHCPv6 IPv6 address assignment for an IOx application
Stateless auto-configured IPv6 address (SLAAC) assignment for Guest OS

IPv6 Address assignment for Guest OS

For Guest OS, IPv6 address assignment to its service bridge (svcbr_0) will be done with "stateless IPv6 address auto-configuration" (SLAAC) option.

The bridge interface will have the following addresses:

IPv6 link local address: this address is used by tpmc to communicate with tpms for pam authentication, platform information retrieval etc.
IPv4 dynamic address: Guest OS is typically assigned with a private IPv4 address from the DHCP pool defined in IOS. With NAT configured in IOS, this private IPv4 address is translated to the routable IPv4 address of the external facing interface on IR8x9, which is used by FD/LM/ioxclient to reach CAF.
IPv6 stateless auto-configured address: this address can be used by FD/LM/ioxclient to reach CAF. It requires
IPv6 unit-casting to be enabled in IOS
IPv6 network prefix configured in GigE 2(IR809) or GigE 5 (IR829) in IOS
(optional) DHCPv6 pool configured in IOS to provide DNS, TFTP, NTP server etc
proper IPv6 routing Guest OS uses the IPv6 network prefix advertised in the RAs from GigE interface in IOS and auto-generates an IPv6 address using the MAC address of svcbr_0 in EUI-64 format.

On Guest OS side, svcbr_0 has both Link Local and auto-generated IPv6 addresses (Since the DHCP server is also configured in IOS, svcbr_0 gets an IPv4 address as well)

Here is an example for IPv6 address assignment for GOS:

Code Snippet

Copyiox-ir809-01-GOS-1:/home/root/iox/caf/config# ifconfig svcbr_0
svcbr_0   Link encap:Ethernet  HWaddr 02:00:01:90:8b:05
          inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::1ff:fe90:8b05/64 Scope:Link
          inet6 addr: 2001:192:168:1:0:1ff:fe90:8b05/64 Scope:Global
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:18396 errors:0 dropped:3654 overruns:0 frame:0
          TX packets:16133 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:6862783 (6.5 MiB)  TX bytes:9599026 (9.1 MiB)

Guest OS can ping GigE in IOS using either address

Code Snippet

Copyiox-ir809-01-GOS-1:/home/root/iox/caf/config# ip -6 neigh
fe80::200:cff:fe8a:9fb9 dev svcbr_0 lladdr 00:00:0c:8a:9f:b9 router REACHABLE
2001:192:168:1::1 dev svcbr_0 lladdr 00:00:0c:8a:9f:b9 router STALE

  iox-ir809-01-GOS-1:/home/root/iox/caf/config# ping6 2001:192:168:1::1
  PING 2001:192:168:1::1(2001:192:168:1::1) 56 data bytes
  64 bytes from 2001:192:168:1::1: icmp_seq=1 ttl=64 time=3.84 ms
  iox-ir809-01-GOS-1:/home/root/iox/caf/config# ping6 fe80::200:cff:fe8a:9fb9 -I svcbr_0
  PING fe80::200:cff:fe8a:9fb9(fe80::200:cff:fe8a:9fb9) from fe80::1ff:fe90:8b05 svcbr_0: 56 data bytes
  64 bytes from fe80::200:cff:fe8a:9fb9: icmp_seq=1 ttl=64 time=0.556 ms

IPv6 Address Assignment to an IOx Application

The following docker application shows how the IPv6 address assignment will be done for its interfaces:

Network interfaces inside a docker container will have the following addresses:

Link Local address
IPv6 address from SLAAC option
IPv6 address from dhcp
IPv4 adddress (Since the IPv4 DHCP server is also configured in IOS, app gets an IPv4 address as well)

Note: Statefull DHCP ipv6 addressing is not supported for LXC type of applications

Code Snippet

Copy$ sudo ioxclient app console docker_app
/ # ifconfig
eth0      Link encap:Ethernet  HWaddr 52:54:DD:8B:4C:14
          inet6 addr: 2001:192:168:1:a955:48c4:729f:c197/64 Scope:Global
          inet6 addr: fe80::5054:ddff:fe8b:4c14/64 Scope:Link
          inet6 addr: 2001:192:168:1:5054:ddff:fe8b:4c14/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:32983 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1067 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2495123 (2.3 MiB)  TX bytes:349804 (341.6 KiB)

Refer this example if you want to assign a static ipv6 address to an IOx app. In this example following activation json file is used while activating the app:

Code Snippet

Copy# cat activation.json
{
        "resources": {
                "profile": "c1.small",
                "network": [{
                        "interface-name": "eth0",
                        "network-name": "iox-bridge0",
                        "mode": "static",
                        "ipv6": {
                                "ip": "2001:0db8:85a3:0000:0000:8a2e:0370:7334",
                                "prefix": "128",
                                "gateway": "2001:0db8:0:f101::1",
                                "dns": "2001:0db8:0:f101::1",
                                "default": true
                        }
                }]
        }
}

Activate the application with this activation file

Code Snippet

Copy# sudo ioxclient app activate test_ipv6 --payload activation.json
Payload file : activation.json. Will pass it as application/json in request body..
2017/11/15 14:40:44 POST /iox/api/v2/hosting/apps/test_ipv6/state?action=activate HTTP/1.1
Host: 1.100.30.61:8443
Content-Type: application/json
X-Token-Id: 96284dd6-4e9e-4317-9eb5-d6b8e785fe18

{
        "resources": {
                "profile": "c1.small",
                "network": [{
                        "interface-name": "eth0",
                        "network-name": "iox-bridge0",
                        "mode": "static",
                        "ipv6": {
                                "ip": "2001:0db8:85a3:0000:0000:8a2e:0370:7334",
                                "prefix": "128",
                                "gateway": "2001:0db8:0:f101::1",
                                "dns": "2001:0db8:0:f101::1",
                                "default": true
                        }
                }]
        }
}

App test_ipv6 is Activated

Check the assigned IPv6 address

Code Snippet

Copy# sudo ioxclient app start test_ipv6
Command Name: application-start
2017/11/15 14:41:11 POST /iox/api/v2/hosting/apps/test_ipv6/state?action=start HTTP/1.1
Host: 1.100.30.61:8443
X-Token-Id: 96284dd6-4e9e-4317-9eb5-d6b8e785fe18


App test_ipv6 is Started
# sudo ioxclient app console test_ipv6
2017/11/15 14:41:26 GET /iox/api/v2/hosting/apps/test_ipv6/console HTTP/1.1
Host: 1.100.30.61:8443
X-Token-Id: 96284dd6-4e9e-4317-9eb5-d6b8e785fe18


Console setup is complete..
Running command : [ssh -p 8022 -i test_ipv6.pem appconsole@1.100.30.61]
/ # ifconfig
eth0      Link encap:Ethernet  HWaddr 52:54:DD:85:5D:FA
          inet6 addr: 2001:db8:85a3::8a2e:370:7334/128 Scope:Global
          inet6 addr: fe80::5054:ddff:fe85:5dfa/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:18 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1168 (1.1 KiB)  TX bytes:876 (876.0 B)

/ #

How to access the Local Manager using IPv6 address

Here is an example how to access the Local Manager using IPv6 address:

Code Snippet

Copyhttps://[2001:192:168:1:0:1ff:fe90:8b05]:8443/admin

Where "2001:192:168:1:0:1ff:fe90:8b05" is a Guest OS's svcbr_0 interface IPv6 address.

Note that the IPv6 address should be enclosed in "[]" in a browser to access the LM.

Connect to an IOx application using IPv6 address

To Connect to an IOx application using IPv6 address, the following should be available:

IPv6 address from svcbr_0 interface of Guest OS
SSH should be available in the application

Here is an example to access an IOx application using IPv6 address:

An LXC application is used in this example which has SSH enabled inside it. Downloaded the pem file (nt05.pem) from the LM.

Code Snippet

Copy$ ssh -i nt05.pem appconsole@2001:192:168:1:0:1ff:fe90:8b05
Connected to domain nt05
Escape character is ^]
Poky (Yocto Project Reference Distro) 2.1.1 ir800-lxc /dev/tty1
ir800-lxc login: root
Last login: Tue Jul 11 16:18:12 +0000 2017 on /dev/pts/0.
root@ir800-lxc:~#