Autonomic Networking Configuration Guide, Cisco IOS XE Release 3S
Autonomic Networking
Downloads: This chapterpdf (PDF - 1.7MB) The complete bookPDF (PDF - 2.42MB) | The complete bookePub (ePub - 231.0KB) | Feedback

Autonomic Networking

Autonomic Networking

Last Published Date: March 30, 2014

Autonomic networking makes network devices intelligent by introducing self-management concepts that simplify network management for the network operator.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/​go/​cfn. An account on Cisco.com is not required.

Prerequisites for Autonomic Networking

  • The Autonomic Networking Infrastructure feature supports Ethernet ports and IPv6 addresses only.
  • All interfaces are “up” by default, to exchange the adjacency discovery (AD) messages, if there is no startup configuration in the device.
  • All devices must be contiguously autonomic on Layer 3. If there is no continuity, manual configuration is required to configure a tunnel through a nonautonomic network. Support for connectivity between autonomic devices across a nonautonomic Layer 2 cloud is supported through Autonomic Channel Discovery (CD).
  • Autonomic Registrar, commonly known as registrar, is required for the Autonomic Networking Infrastructure feature to work. At least one device in the network should be configured as a registrar.
  • Each registrar supports one autonomic domain only. The registrar is needed only when new autonomic devices join the domain.
  • All new devices must have a physical connectivity to at least one autonomic device to contact the registrar for authentication and authorization.
  • If the autonomic device is already part of another domain, it is not invited to join a new domain. Two devices that are part of different domains cannot, by default, communicate with each other.

Restrictions for Autonomic Networking

General Restrictions

  • Autonomic networking only supports Ethernet ports and unique device identifier (UDI)-based devices.
  • All devices in an autonomic network should be contiguously autonomic. If there is no continuity, physical configuration is required to configure a tunnel through a nonautonomic network.
  • The inclusion of a nonautonomic device between autonomic devices is not supported. This is because the autonomic device may not be able to detect the VLAN tag when connected to a nonautonomic device.
  • The IPv6 generic routing encapsulation (GRE) tunnel, IPsec session, and authentication, authorization and accounting (AAA) elements created by an autonomic network cannot be nvgenned or manually deleted.

Restrictions for Cisco ASR 900 Aggregation Services Routers

  • The default settings and the default mode of ports are shipped with the device. The default settings allow tagged and untagged packets and cannot be modified.
  • Routed ports allow untagged traffic, and VLAN-tagged traffic is dropped.
  • You must configure the ipv6 unicast-routing command.
  • Autonomic networking is not high availability (HA)-aware.
  • The time to validate a neighbor and join a domain must not exceed 60 seconds (assuming 10 devices are configured per domain).
  • Additional increase in traffic may be seen when autonomic networking hello packets are sent based on the neighbor table.
  • The default port state is admin down.
  • The EVC scale for Cisco ASR 900 RSP1 A cards is reduced.

Information About Autonomic Networking

Overview of Autonomic Networking

The aim of autonomic networking is to create self-managing networks to overcome the rapidly growing complexity of the Internet and other networks to enable their further growth. In a self-managing autonomic system, network management takes on a new role: instead of controlling the network elements individually and directly, the administrator defines network-wide policies and rules that guide the self-management process.

The following diagram provides a high-level architecture of an autonomic network.

Figure 1. High-Level Architecture of an Autonomic Network



Autonomic Networking is controlled by a separate software entity running on top of traditional operating systems that include networking components, such as IP, Open Shortest Path First (OSPF), and so forth. Traditional networking components are unchanged and unaware of the presence of the autonomic process. The autonomic components use normal interfaces that are exposed by the traditional networking components and interact with different devices in the network. The autonomic components securely cooperate to add more intelligence to devices so that the devices in an autonomic network can autonomically configure, manage, protect, and heal themselves with minimal operator intervention. They can also securely consolidate their operations to present a simplified and abstracted view of the network to the operator.

Autonomic Networking Infrastructure

The Autonomic Networking Infrastructure feature simplifies the network bootstrap functionality by removing the need for any kind of prestaging, thereby allowing devices to join a domain securely, after which devices can be configured. The goal of the Autonomic Networking Infrastructure feature is to make new and unconfigured devices securely reachable by an operator or network management system. This is carried out in the following steps:

  1. One device is defined and configured as the registrar. The registrar is the first autonomic domain device.
  2. The network administrator collects a list of legitimate device identifiers of the devices to be added to the network. This list controls the devices that are added to the autonomic domain. Devices are identified by their unique device identifier (UDI). The list is compiled as a simple text file, one UDI per line. This step is optional because in the absence of a whitelist, all devices are allowed to join the domain. A whitelist is an approved list of entities that is provided a particular privilege, service, mobility, access, or recognition. Whitelisting means to grant access.
  3. The whitelist of known devices is uploaded to the registrar as part of its configuration. This step is optional.
  4. Any new autonomic device that is directly connected to the registrar, or another already enrolled domain device, will automatically receive a domain certificate from the registrar.
  5. The autonomic control plane is automatically established across the autonomic domain to make new devices reachable.

The benefits of Autonomic Networking Infrastructure are as follows:

  • Autonomic discovery of Layer 2 topology and connectivity by discovering how to reach autonomic neighbors.
  • Secure and zero touch identity of new devices by using the device name and domain certificate.
  • A virtual autonomic control plane that enables communications between autonomic nodes.

Autonomic behavior is enabled by default on new devices. To enable autonomic behavior on existing devices, use the autonomic connect command. To disable, use the no form of this command.

The components of autonomic networking are as follows:

  • Registrar—A domain-specific registration authority in a given enterprise that validates new devices in the domain, provides them with domain-wide credentials, and makes policy decisions. Policy decisions can include whether a new device can join a given domain based on a preloaded whitelist. The registrar also has a database of devices that join a given domain and the device details.
  • Channel Discovery—Used to discover reachability between autonomic nodes across nonautonomic Layer 2 networks.
  • Adjacency Discovery—Used to discover autonomic neighbors. Adjacency discovery is done on Layer 3. It is also possible to discover autonomic neighbors across preestablished Layer 3 Generic Routed Encapsulation (GRE) tunnels.

New Device Joining the Autonomic Network

The following figure illustrates how a new device joins an autonomic network.

Figure 2. New Device Joining the Autonomic Network



  1. The new device sends out a hello message to the neighbor. In this case, the neighbor is part of an autonomic network domain.
  2. The hello message includes the unique device identifier (UDI) of the new device.
  3. The autonomic device acts as a proxy and allows the new device to join this autonomic network domain. The autonomic network device advertises itself with the domain information to its Layer 3 neighbors.
  4. On receiving the autonomic network hello message from the neighbor and detecting the UDI information, the new device is validated with the autonomic registrar.
  5. The new device advertises its domain certificate in its hello message with all neighbors. The neighbor information is exchanged every 10 seconds.

Note


If the neighbor information changes, the entry is deleted and neighbor discovery is restarted. In the absence of a domain certificate and devices working with UDI, UDI is exchanged at a 10-second interval.

Working of the Registrar

One device in the network is configured as the registrar to validate all new devices locally and accept all devices that try to join the domain managed by the registrar. The registrar issues a domain certificate to devices using the domain name provided by the administrator.


Note


The domain name is a group of devices in the network managed by the same set of rules. Any neighbor communicating with the registrar using the UDI certificate is sent an invitation to join the domain by registrar.

Currently, the registrar validates the new devices based on an optional list of UDIs that is specified when configuring the registrar. The list specifies a set of devices that are allowed to join the network.

Figure 3. Provisioning Registrar in an Autonomic Network



The registrar maintains a database of all devices that join or fail to join the domain. The failed devices can try to join the domain again. The registrar database tracks all devices in the domain and associates each device with the following states:

  • Accepted—Devices that successfully join the domain.
  • Pending—Devices that are in the process of joining the domain.
  • Quarantine—Devices that failed to join the domain.

Channel Discovery in Autonomic Networking

Autonomic networking uses channel discovery to discover the usable bridge domain for each neighbor. Channel discovery sends Layer 2 frames to all the interfaces in the network. Depending on the bridge domain allowed by the intermediate Layer 2 channel to a neighbor, frames in the allowed bridge domains are sent to the neighbor. For channel discovery to be successful, autonomic networking needs frames received on all bridge domains to be punted. Therefore, all devices in the network must punt channel discovery frames to all bridge domains configured on the receiver interface. The receiver selects a bridge domain and sends a response. Both the initiator and the responder start using that bridge domain for autonomic networking neighbor discovery and further autonomic networking communications.

Service Discovery in Autonomic Networking

Autonomic networking uses the multicast Domain Name System (mDNS) infrastructure to discover various services required by the devices in the autonomic networking domain. Few services discovered by the network using the mDNS infrastructure are the AAA server, the Syslog server, and the autonomic networking registrar. Autonomic networking listens to the mDNS advertisements on all the devices in the domain. From the devices hosting the services, autonomic networking initiates the mDNS advertisements.

Autonomic Control Plane

When a new device in the domain receives a domain certificate, it exchanges the domain certificate in the hello messages with its neighbors. This creates an autonomic control plane between two autonomic devices of the same domain. There are different types of autonomic control planes that can be created based on the different capabilities of the devices. The autonomic control plane is established by using the following mechanisms:

  • Configuring a loopback interface.
  • Configuring a generic routing encapsulation (GRE) tunnel.
  • Dynamically assigning an IPv6 address to the loopback interface.
  • Configuring an autonomic VPN routing and forwarding (VRF).

IPsec on Link Local GRE IPv6 Tunnels in Autonomic Networking

Autonomic control plane (ACP) is created by building hop-by-hop IPv6 generic routing encapsulation (GRE) tunnels between the pairs of autonomic neighbors. The GRE tunnels require a valid source and destination addresses on the physical interfaces. As the GRE tunnels are hop-by-hop, autonomic networking uses the link local addresses of the physical interfaces as the source or destination addresses of the tunnels. As the physical interfaces have no global IPv6 addresses, IPsec and IKE work with the link local addresses of the physical interfaces.

How to Configure Autonomic Networking

Configuring the Registrar

SUMMARY STEPS

    1.    enable

    2.    configure terminal

    3.    autonomic connect

    4.    autonomic service aaa ipv6-address auth-port authentication-port-number acct-port accounting-port-number key shared-key

    5.    autonomic registrar

    6.    domain-id domain-name

    7.    device-accept udi

    8.    whitelist filename

    9.    no shut

    10.    end


DETAILED STEPS
     Command or ActionPurpose
    Step 1enable


    Example:
    Device> enable
     
    Enables privileged EXEC mode.
    • Enter your password if prompted.
     
    Step 2configure terminal


    Example:
    Device# configure terminal
     
    Enters global configuration mode. 
    Step 3autonomic connect


    Example:
    Device(config)# autonomic connect
     
    (Optional) Connects a nonautonomic management device, such as an authentication, authorization, and accounting (AAA) server, or a syslog server, to the autonomic network. 
    Step 4autonomic service aaa ipv6-address auth-port authentication-port-number acct-port accounting-port-number key shared-key


    Example:
    Device(config)# autonomic service aaa 2001:DB8:1::1 auth-port 1645 acct-port 1646 key rad123
     
    (Optional) Advertises AAA server details to all nodes in the autonomic domain.
    Note    Only IPv6 is supported to facilitate communication with the AAA server. In Cisco IOS Release 15.3(3)S, autonomic devices must use 1645 as the authentication port, 1646 as the accounting port, and rad123 as the RADIUS key. Any other value will be ignored.
     
    Step 5autonomic registrar


    Example:
    Device(config)# autonomic registrar
     

    Enables a device as a registrar and enters registrar configuration mode.

     
    Step 6domain-id domain-name


    Example:
    Device(config-anra)# domain-id abc.com
     
    Represents a common group of all devices registering with the registrar. 
    Step 7device-accept udi


    Example:
    Device(config-anra)# device-accept "PID:A901-12C-FT-D SN:CAT1902U88Y"
     
    (Optional) Specifies the Unique Device Identifier (UDI) of a quarantined device to be accepted in the autonomic domain.
    • udi—Must be entered in double quotes to ensure that spaces and special characters are inclusive in the argument.
    Note    This command is not required when configuring the registrar. It is required only after the registrar is enabled to accept previously quarantined devices.
     
    Step 8whitelist filename


    Example:
    Device(config-anra)# whitelist flash:whitelist.txt
    PID:A901-12C-FT-D SN:CAT1602U32U
    PID:A901-12C-FT-D SN:CAT1604U92B
     
    (Optional) Allows loading a file on the local device that contains a list of devices to be accepted in a given domain.
    • The file must contain one UDI entry per line.
    Note    If this command is not configured, all devices are accepted into the domain.
     
    Step 9no shut


    Example:
    Device(config-anra)# no shut
     
    Enables the autonomic registrar. 
    Step 10end


    Example:
    Device(config-anra)# end
     
    Exits registrar configuration mode and returns to privileged EXEC mode. 

    Verifying and Monitoring Autonomic Networking Configuration

    SUMMARY STEPS

      1.    enable

      2.    show autonomic device

      3.    show autonomic neighbors [detail]

      4.    show autonomic registrar devices [accepted | quarantine | whitelist]

      5.    show autonomic control plane [detail]

      6.    show autonomic interfaces

      7.    debug autonomic {bootstrap | neighbor-discovery database | registrar | services} {aaa | all | ntp | events | packets} {info | moderate | severe}

      8.    clear autonomic {device | neighbor UDI}


    DETAILED STEPS
      Step 1   enable


      Example:
      Device> enable
      Enables privileged EXEC mode.
      • Enter your password if prompted.
      Step 2   show autonomic device


      Example:
      Device# show autonomic device 
      
      UDI                            PID:CISCO3945-CHASSIS SN:FGL154610WK
      Device ID                      Router-4
      Domain ID                      UABU.com
      Domain Certificate             (sub:) Router-4
      Device Address                 FD78:A419:B463::D253:5185:547E
      Displays the current state of an autonomic device including the global details.
      Step 3   show autonomic neighbors [detail]


      Example:
      Device# show autonomic neighbors detail
      
      UDI: "PID:A901-4C-F-D SN:CAT1611U085"
              Device Identifier              Router-2
              Domain Identifier              cisco.com
              State                          Nbr inside the Domain
              Credential                     Domain Cert
              Credential Validation          Passed
                 Local Interface:    Vlan2000(GigabitEthernet0/7)
                 Remote Interface:   Vlan2001
                 Link Local IP Addr: FE80::462B:3FF:FE48:D234
      Displays information about the discovered neighbors.
      Step 4   show autonomic registrar devices [accepted | quarantine | whitelist]


      Example:
      Device# show autonomic registrar
      
              Domain Name                    cisco
              Whitelist                      Status 
              ANR                            Live
              Address                        FD7A:F78C:911D::D253:5185:5472
              Certificate                    (sub:) cn=ANRA-CS
      Displays information about the autonomic registrar.
      Step 5   show autonomic control plane [detail]


      Example:
      Device# show autonomic control-plane
      
      VRF Name                       cisco_autonomic
      Device Address                 FD08:2EEF:C2EE::D253:5185:547A
      RPL                            Type = Node, Inst-Id = 0, OCP = 0, Mode = Storing
      Neighbor                                           ACP Channel     ACP Security 
      --------------------------------------------------------------------------------
      PID:A901-4C-F-D SN:CAT1611U085                     Tunnel100000
      
      
      Device# show autonomic control-plane detail
      VRF Name                       cisco_autonomic
      Device Address                 FD08:2EEF:C2EE::D253:5185:547A
      RPL                            Type = Node, Inst-Id = 0, OCP = 0, Mode = Storing
      Neighbor: PID:A901-4C-F-D SN:CAT1611U085
              ACP Channel: GRE Tunnel
                      Tunnel Name                    Tunnel100000
                      Tunnel Source Interface        Vlan2000
                      Tunnel Source                  FE80::C664:13FF:FEB0:DEF0
                      Tunnel Destination             FE80::462B:3FF:FE48:D234
              ACP Security: None
      Displays information about the autonomic control plane.
      Step 6   show autonomic interfaces
      Displays information about the interfaces in the autonomic domain.
      Step 7   debug autonomic {bootstrap | neighbor-discovery database | registrar | services} {aaa | all | ntp | events | packets} {info | moderate | severe}
      Enables debugging autonomic network.
      Step 8   clear autonomic {device | neighbor UDI}
      Clears or resets autonomic information.
      • The clear autonomic device command clears or resets all the device specific AN information, including the information obtained in bootstrapping process.
      • The clear autonomic neighbor command clears the neighbor-related information learned in the neighbor discovery. If no neighbor is specified, it clears the entire neighbor database.

      Configuration Examples for Autonomic Networking

      Example: Configuring the Registrar

      Device> enable
      Device# configure terminal
      Device(config)# autonomic service aaa 2008::5:16:20:100 auth-port 1645 acct-port 1646 key rad123
      Device(config)# autonomic registrar
      Device(config-anra)# domain-id abc.com
      Device(config-anra)# whitelist flash:anra-domain.txt
      Device(config-anra)# end

      Additional References for Autonomic Networking

      Related Documents

      Related Topic Document Title

      Cisco IOS commands

      Cisco IOS Master Command List, All Releases

      Autonomic Networking commands

      Cisco IOS Autonomic Networking Command Reference

      Technical Assistance

      Description Link

      The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

      http:/​/​www.cisco.com/​cisco/​web/​support/​index.html

      Feature Information for Autonomic Networking

      The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

      Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/​go/​cfn. An account on Cisco.com is not required.

      Table 1 Feature Information for Autonomic Networking Infrastructure

      Feature Name

      Releases

      Feature Information

      Autonomic Networking Infrastructure

      Cisco IOS XE Release 3.12S

      Autonomic networking makes network devices intelligent by introducing self-management concepts that simplify network management for the network operator. The Autonomic Networking Infrastructure feature simplifies the network bootstrap functionality by removing the need for any kind of prestaging, thereby allowing devices to join a domain securely, after which devices can be configured.

      The following commands were introduced or modified: autonomic connect, autonomic registrar, autonomic service, clear autonomic, debug autonomic, device-accept, domain-id, show autonomic control plane, show autonomic device, show autonomic interfaces, show autonomic neighbors, show autonomic registrar, show autonomic service, whitelist.

      IP tunnel: Autonomic Networking Support

      Cisco IOS XE Release 3.12S

      Autonomic control plane (ACP) is created by building hop-by-hop IPv6 generic routing encapsulation (GRE) tunnels between the pairs of autonomic neighbors. The GRE tunnels require a valid source and destination addresses on the physical interfaces. As the GRE tunnels are hop-by-hop, autonomic networking uses the link local addresses of the physical interfaces as the source or destination addresses of the tunnels.

      In Cisco IOS XE Release 3.12S, support was added for the Cisco ASR 900 Series Aggregation Services Routers.

      The following commands were introduced or modified: show autonomic control plane, show autonomic service.