New Capabilities in CCI Release 1.1

■City Wi-Fi Access Network with both Mesh and Non-mesh deployments

–Cisco Unified Wireless Network (CUWN) with 1562/1572, ESW 6300, IW3702 Outdoor Access Points with or without mesh, Ethernet bridging (WGB) option with CCTV connectivity

–SD Access Wireless based Wi-Fi

■Cisco DNA Spaces for Wi-Fi Analytics

■Cisco DNA Center v1.3.3.3 with Multicast traffic forwarding in CCI network

■Daisy-chained Ethernet Access Ring of size up to 30 Cisco Industrial Ethernet (IE) switches in the ring

■Inclusion of Policy Extended Nodes (PENs) and micro-segmentation in the Ethernet Access Ring

■Solution enhancements: PoP aggregation geo-redundancy, FND4.5, Cimcon LG5, IR1101 RPoP, IR managed IXM

This document also provides implementation details for overlaying CCI vertical use cases like Cities Safety and Security, Cisco Smart Street Lighting, and Roadways intersection on the CCI network. It is recommended to implement CCI network and vertical use cases, as depicted in Figure 1, which shows the flow of the material in this implementation guide:

Figure 1 CCI Solution Implementation Flow

The document addresses the implementation of the following CCI network horizontal and vertical use cases:

■CCI Underlay Network Implementation for basic network (Layer 3) IP forwarding and connectivity

■Implementation of shared services like Cisco DNA Center, Identity Service Engine (ISE), Cisco Wireless LAN Controller (WLC) and Cisco Prime Infrastructure (PI), DHCP, and DNS servers, as well as other shared IoT devices management applications such as Field Network Director (FND)

■Configuring Cisco SD-Access Fabric Site (Point-of-Presence aka PoP) as overlay network and Interconnection of the Fabric Sites leveraging Cisco DNA Center

■Implementation of Cisco Industrial Ethernet switches—Cisco Industrial Ethernet (IE) 4000, Cisco Industrial Ethernet (IE) 5000, Cisco Catalyst Industrial Ethernet 3300 and 3400 series switches—as fabric extended nodes, policy extended nodes, daisy-chained extended nodes (DC-EN) and daisy-chained policy extended nodes (DC-PENs) in Ethernet access network rings

■Implementation of Cisco Unified Wireless Network (CUWN) Wi-Fi Mesh and SD Access Wireless Wi-Fi access networks

■Implementation of headquarter site data center applications for vertical use cases and services on the fabric overlay network. It covers Cities Safety and Security, Video Surveillance Manager (VSM), and applications such as Certificate Authority (CA) services needed for Cisco Smart Street Lighting solution use cases along with Public Wi-Fi use cases

■Deployment details for DSRC and LoRaWAN in Remote PoP

■Deployment details for Remote PoP over cellular network backhaul for vertical use cases such as the CIMCON street lighting (Optional)

■Deployment details for LoRaWAN in Remote PoP (Optional)

■Implementation of end-to-end network security, which covers macro- and micro-segmentation of CCI networks using Virtual Networks (VNs) and Scalable Group Tags (SGT) and Scalable Group Access Control Lists (SGACL), network devices and endpoints security, and network firewall implementation in the DMZ

■End-to-end network QoS implementation for traffic classification, prioritization, queuing, and policing

■Implementation of multicast network forwarding in CCI. Enabling multicast in CCI is optional as it is needed if you want to implement any vertical use case which requires multicast traffic forwarding in CCI

Deployment Topology Diagrams

This section describes the different deployment network topologies that have been validated in the CCI Solution Implementation.

High Level Solution Validation Topology

Figure 2 depicts the CCI high level validation topology, including the endpoints for vertical use cases validated in this solution implementation:

Figure 2 CCI High Level Solution Validation Topology

The multiple layers of topology include:

1. Internet Cloud & Data Center layer, which includes:

–Network connectivity to Demilitarized Zone (DMZ) to access Internet/Applications on the cloud.

–A Headquarter or Data Center Site (HQ/DC Site) aka Application Servers Site consisting of:

• Application servers for hosting vertical specific applications needed on the CCI horizontal network
• Shared services like Cisco DNA Center, ISE, DHCP, and DNS servers along with other applications that are common to all vertical use cases like FND for both Cities and Transportation/Roadways.

2. Network backhaul layer interconnects PoPs and the Internet Cloud/Data Center layer with either the private enterprise Ethernet network or private MPLS network backhaul. Remote PoPs connect to the CCI network via cellular or private/public network backhaul.

3. Aggregation layer aggregates all PoPs traffic to the upper layers.

4. Ethernet access ring provides network access to gateways/endpoints validated in the solution.

5. Internet of Things (IoT) gateways and endpoints layer includes Access Points (AP) for Wi-Fi access, access gateways based on access technologies (such as DSRC, LoRaWAN, and CR-Mesh) and their endpoints validated in this solution.

Solution Validation Topologies

Two deployment models of the CCI solution have been validated during this implementation:

1. CCI network deployment topology with Cisco SD-Access Transit, henceforth referred to as SDA Transit interconnection of all sites. The validation is done over the Enterprise Ethernet Network backhaul (using Cisco Catalyst 9500 switches as the network core). This topology is depicted in Figure 3.

2. CCI network deployment topology with IP Transit interconnection of PoPs and headquarter sites with validation done over Private MPLS network backhaul, as shown in Figure 4.

Figure 3 SD-Access Transit with Enterprise Backhaul Network Topology

Note : In Figure 3, the PoP1 with C9500 SVL is also supported to connect IE switches to just the nearest Catalyst 9500 stack member – this could be likely when there is insufficient fiber pairs between the two physical locations that each stack member is housed, however in this case also a Port Channel is still used with single member link automated by DNA Center.

Figure 4 IP Transit with MPLS Backhaul Network Topology

Network topologies (as shown in Figure 3 and Figure 4) validated in this CVD show FlexVPN tunnels that are configured for securing the communication between the Cisco 1240 Connected Grid Router and the HER in Cisco Smart Street Lighting solution use cases implemented on the CCI network.

For more details about fabric device roles (B-Border, CP-Control Plane, E-Edge, T-Transit, X-Extended Node) in the network topology, refer to the Cisco Connected Communities Infrastructure CVD Solution Design Guide.

IP Addressing

This section captures the example IP addressing prefixes used in the solution lab topology, as shown in Figure 3.

Note: The IP addresses captured in this section are example IP addressing used only for the solution validation as internal sub-networks in the CVD lab. It provides a reference for selecting subnets for the solution implementation. It is recommended to choose private network prefixes/IP addressing scheme depending on the solution deployment and devices connected to the CCI network.

Addressing Convention followed in the IP Subnet Selection

Four prefixes are used in the network subnet for the network topology (where X is the site ID chosen for a PoP site/ transit site and the underlay network devices, if any).

■192.0.X. YY—Devices Loopback IP addresses prefix

■172.10.X. YY—Virtual Network (VN) subnets prefix

■192.168.X. YY—Fabric Overlay Border Handoff Network prefix

■192.100.X. YY—Fabric Extended Nodes IP Pool prefix

Note: Refer to IP Addressing of Solution Components for more details about IP addresses, including IP addresses used for underlay network connectivity for the network topologies, as shown in Figure 3, Figure 4, and Figure 5.

Solution Virtual Networks and Scalable Groups

In the CCI implementation, a Virtual Network (VN) is used for a vertical service. This macro-segmentation provides complete separation between services. One VN can communicate with another only by leaking routes between the VRF at the fusion router. Table 2 provides an example list of VNs used in the CCI solution validation.

Example VNs for the Cities and Roadways applications include Safety and Security, Cisco Smart Street Lighting, Iteris, Schneider, Cisco Kinetic for Cities, and LoRaWAN. Further micro-segmentation within a virtual network is possible by using Scalable Group Tags (SGT). Table 2 also provides an example list of SGTs for micro-segmentation of the VN.

Configuring Enterprise Ethernet Network Underlay

Ethernet as a backhaul, is one of the enterprise networks backhaul deployment methods that can be implemented in CCI horizontal network, as shown in Figure 3. The underlay network connectivity between shared services and all devices in each PoP site (including HQ/DC site) is provided through the backhaul network. The underlay network configuration is a basic network connectivity prerequisite for implementing the fabric overlay network for the CCI solution using the Cisco DNA Center.

Many protocols are available to configure IP routing, but in this implementation EIGRP is used as an example routing protocol for configuring underlay network connectivity and IP routing across PoP Sites and shared services. Cisco DNA Center uses Border Gateway Protocol (BGP) as the routing protocol when a border node connects to an IP transit, which means the configuration co-exists with the underlay configuration.

Configuring Cisco Catalyst 9300 Switch Stack for Fabric-in-a-Box

In the CCI Solution, all fabric/PoP sites leverage the Cisco Catalyst 9300 switch stack as an aggregation/distribution layer switch for aggregating traffic from access rings. Switch stack ensures redundancy. A stack of Cisco Catalyst 9300 switches appears to the operator and the rest of the network as one single switch, making it easier to manage and configure. Newer switch models add stateful failover capability, providing similar behavior as a chassis with dual supervisors in case of a failure or the need to update software on the stack.

Cisco Catalyst 9300 switch stack configuration is the initial step for provisioning a PoP site network (along with redundancy) for the access rings network and backhaul network connectivity network in the CCI topology. Refer to the following URL for configuring Cisco Catalyst 9300 switches in a stack:

■ https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/16-5/configuration_guide/stck_mgr_ha/b_165_stck_mgr_ha_9300_cg/managing_switch_stacks.html

Configuring Cisco Catalyst 9500 Switches StackWise Virtual (SVL) for Fabric-in-a-Box

Alternatively, Cisco Catalyst 9500 Series switches can be used as PoP sites aggregation/distribution layer switch for aggregating traffic from access rings in CCI. Cisco Catalyst 9500 platform StackWise Virtual technology allows the clustering of two physical switches, that are geographically separated, together into a single logical entity. The two switches operate as one; they share the same configuration and forwarding state. This technology allows for enhancements in all areas of network design, including high availability, scalability, management, and maintenance.

Cisco Catalyst 9500 switch SVL configuration is the initial step for provisioning a PoP site network (along with redundancy) for the access rings network and backhaul network connectivity network in the CCI topology.

StackWise Virtual domain is elected as the central management point for the entire system when accessed via management IP or console. The switch acting as the single management point is referred to as the SV active switch. The peer chassis is referred to as the SV standby switch. The SV standby switch is also considered a hot-standby switch, since it is ready to become the active switch and it takes over all functions of active switch when active switch fails.

When the Catalyst 9500 SVL is used in the role of the Fabric-in-a-Box (FiaB) (Border + Control Plane + Edge), the connection to a Transit Site ( For example, SD Access Transit switches) must be done with interfaces configured as a switchport trunk. A Switched Virtual Interface (SVI) is used for the Layer 3 configuration.

Conversion to StackWise Virtual mode

Refer to the section ‘How to Configure Cisco StackWise Virtual’ for configuring Cisco Catalyst 9500 switches in a SVL Mode at the following URL:

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/17-1/configuration_guide/ha/b_171_ha_9500_cg/configuring_cisco_stackwise_virtual.html

Configure Layer 3 on Ethernet Backhaul Network

Cisco Catalyst 9500 switches are used to provide the Ethernet network backhaul for interconnecting PoP sites and Shared Services, and Data Center applications in the HQ PoP Site, as shown in Figure 3.The following configuration provides an example configuration to enable Cisco Catalyst 9500 switches for the underlay network routing (Layer 3) for the network topology, as shown in Figure 3.

Configure the Layer 3 interface for the underlay network on Cisco Catalyst 9500 switches:

Example Interfaces Configuration on Cisco Catalyst 9500-1 (Transit Site)

1. Loopback interface is configured on the device for Cisco DNA Center discovery:

2. Configure an interface as a trunk to a PoP Site Cisco Catalyst 9300 stack:

3. Configure an SVI interface (example: VLAN 200) for underlay reachability between Fusion Router 1 and Cisco Catalyst 9300 stack, which is FiaB:

4. Configure L3 Port Channel between C9500 switches in Transit sites. On 9500-1:

5. EIGRP routing protocol is configured between fusion routers and Cisco Catalyst 9300 stack network devices to form neighbors:

Note : EIGRP is chosen as an example routing protocol for the underlay network routing configuration. Refer to the Cisco Connected Communities Infrastructure Design Guide for more details on recommended routing protocol for the underlay network routing configuration.

Example Interfaces Configuration on 9500-2 (Transit Site)

1. Loopback is configured on the device for Cisco DNA Center discovery:

2. Configure an interface on 9500-2 as a trunk to the Cisco Catalyst 9300 stack:

3. Configure an SVI interface (Example VLAN201) for underlay reachability between Fusion Router 2 and the Cisco Catalyst 9300 stack which is FiaB:

4. Configure L3 Port Channel between 9500 switches in Transit sites. On 9500-1:

5. EIGRP routing configuration between fusion routers and Cisco Catalyst 9300 stack network devices to form neighbors:

Example Interfaces Configuration on 9500-2 (Transit Site)

1. Loopback is configured on the device for Cisco DNA Center discovery:

2. Configure an interface on 9500-2 as a trunk to the Cisco Catalyst 9300 stack:

3. Configure an SVI interface (Example VLAN201) for underlay reachability between Fusion Router 2 and the Cisco Catalyst 9300 stack which is FiaB:

4. EIGRP routing configuration between fusion routers and Cisco Catalyst 9300 stack network devices to form neighbors:

Configure Layer 3 on Fabric-in-a-Box

An example Layer 3 routing configuration on the PoP site network device Cisco Catalyst 9300 stack or 9500 SVL, to reach fusion routers and shared services network:

1. Loopback interface on the Cisco Catalyst 9300 stack for Cisco DNA Center discovery:

2. Configure interfaces on the Cisco Catalyst 9300 stack as trunk ports to fusion routers:

3. Configure an SVI interfaces (example: VLAN200 and VLAN201) on the Cisco Catalyst 9300 stack to reach fusion routers:

4. Configure EIGRP neighbors between Cisco Catalyst 9300 Stack and Cisco Catalyst 9500 switches (fusion routers):

Note: The above are the example configurations for the PoP1 site, as shown in Figure 3. The same has to be applied for all the PoP sites, including the HQ/DC site, to reach the shared services network so that devices can be successfully discovered in the Cisco DNA Center.

Configuring Shared Services Network Connectivity

For all the network devices in a PoP site and fusion routers to reach the shared services network, configure the basic underlay routing between the fusion routers and shared services network. Refer to Figure 3 for the physical topology between the fusion router, Nexus, and the shared services network.

1. A pair of Nexus 5672UP switches in the HQ/DC site connecting to application servers is used for connecting the Cisco DNA Center appliance and the Cisco UCS server where other shared services applications are hosted. The following configuration provides an example configuration (Layer 3) on the Nexus switches for configuring the shared services network to Cisco Catalyst 9500 switches as fusion routers, as shown in Figure 3.

Nexus Switch-1 Configurations

a. Configure an SVI interface (example: shared service VLAN1000) in Nexus-1 to reach the shared services network:

b. Configure interface for connectivity to Cisco DNA Center appliance enterprise network interface:

c. Configure interface for connectivity to CSR1KV:

Nexus Switch 2 Configurations

a. Configure an SVI interface (VLAN1000) in Nexus-2 to reach the shared services network:

b. Configure Nexus-2 interface for connectivity to the CSR1KV:

2. Configure Cisco CSR1000V (fusion routers) to reach the shared services network.

a. For the shared services network (10.10.100.X), configure sub interfaces to reach Cisco DNA Center, DHCP, DNS, and ISE.

On Fusion Router 1:

On Fusion Router 2:

b. Cisco CSR1000v routers are configured as default routers for the shared services subnet with Next Hop Redundancy using the HSRP protocol. Configure HSRP to create gateway redundancy between the fusion routers for the shared services subnet. Example HSRP configuration on fusion routers:

On Fusion Router 1:

On Fusion Router 2:

3. Add the shared services network in the underlaying EIGRP routing configuration on both fusion routers, as shown in the example below.

Once the underlay routing configuration is complete for the Catalyst 9300 FiaB and fusion routers, the connectivity to the shared services (Cisco DNA, ISE, DHCP, WLC, Prime, etc.) network must be verified.

Transit Control Plane (C9500-1) IP Routing Verification:

FiaB IP Routing Verification:

Ping devices in Shared Services:

After successfully verifying the underlay connectivity from the Catalyst 9300 FiaB to the shared services, the edge fabric can start being provisioned.

Configuring Network Underlay for MPLS Backhaul Network

In addition to a Layer 3 enterprise network deployment, an edge fabric site can also be connected to the data center fabric site through an MPLS backhaul network. This network could be deployed by the city operator or a separate service provider. In either case, the fabric border device will act as a customer edge (CE) router and the connecting router in the MPLS core will act as the provider edge (PE) router. For this testing, a Layer 3 Virtual Private Network (L3VPN) was implemented. Explaining the differences in MPLS implementations is outside the scope of this document. This implementation is one of many ways a service provider can separate one customer's traffic from another.

Many ways exist for configuring a VRF-aware routing protocol between a PE and CE, but, in this implementation, eBGP was used. Cisco DNA Center only supports BGP as the routing protocol when a border node connects to an IP transit, which means the configuration can be combined with the underlay configuration. When the Catalyst 9300 is used in the role of the FiaB (Border + Control Plane + Edge), the connection to the PE must be done with an interface configured as a switchport trunk. An SVI is used for the Layer 3 configuration. For resiliency, another port on a different stack member can be connected to a different PE router.

Example Catalyst 9300 Configuration:

BGP Configuration:

Example Provider Edge Configuration:

VRF Definition:

Physical Interface:

Bridge Domain Interface:

BGP Configuration:

Note : Example VRF configuration is shown above for one VN. The configuration must be repeated if you add more VNs in the network.

Once the routing configuration is on the Catalyst 9300 FiaB and provider edge, connectivity to the shared services (Cisco DNA, ISE, DHCP, etc.) must be verified.

Provider Edge Verification:

FiaB Verification:

■Check Routing:

■Ping devices in shared services:

After successfully verifying the underlay connectivity from the Catalyst 9300 FiaB to the shared services, the edge fabric can start being provisioned.

Cisco DNA Center Installation and Initial Configuration

Cisco DNA Center offers centralized, intuitive management that makes it fast and easy to design, provision, and apply policies across your network environment. The Cisco DNA Center provides a centralized management dashboard for complete control of the CCI horizontal network.

Cisco DNA Center, which is a dedicated hardware appliance powered through a software collection of applications, processes, services, packages, and tools, is the centerpiece for Cisco® Digital Network Architecture (Cisco DNA™). This software provides full automation capabilities for provisioning and change management, reducing operations by minimizing the touch time required to maintain the network.

This section covers the installation and basic network configuration needed on the Cisco DNA Center for accessing its GUI in CCI deployment.

For step-by-step instructions for installing and configuring Cisco DNA Center, refer to the Cisco DNA Center Installation Guide, Release 1.3.3.0 at the following URLs:

Cisco DNA Center First Generation Appliance Installation Guide

■ https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center/1-3-3-0/install_guide/1atGen/b_cisco_dna_center_install_guide_1_3_3_0_1stGen.html

Cisco DNA Center Second Generation Appliance Installation Guide

■ https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center/1-3-3-0/install_guide/2ndGen/b_cisco_dna_center_install_guide_1_3_3_0_2ndGen.html

Preparing Cisco Identity Service Engine for SD-Access

Cisco Identity Services Engine (ISE) is a policy-based access control system that enables the enterprises, Smart Cities, and the like to enforce compliance and infrastructure security. ISE is an integral part of Cisco SD-Access acting as the authentication, authorization, and accounting (AAA) server for devices identity management, access control, and enforcement of access policies on fabric devices.

In the CCI solution, ISE is coupled with the Cisco DNA Center for dynamic mapping of users and devices to scalable groups, which simplifies end-to-end security policy management and enforcement at a greater scale than traditional network policy implementations relying on IP access lists.

ISE Installation and Initial Configuration

A centralized standalone deployment of ISE is configured with the Cisco DNA Center in the shared services network as shown in the network topology that is depicted in Figure 3. ISE can be installed in various ways; OVA deployment of ISE as a virtual machine is used in this implementation. Refer to the URL below for step-by-step instructions on installing ISE:

■ https://www.cisco.com/c/en/us/td/docs/security/ise/2-4/install_guide/b_ise_InstallationGuide24/b_ise_InstallationGuide24_chapter_011.html

Once the ISE installation is complete, update the Patch 11 on ISE, which is compatible with Cisco DNA Center SD-Access, by completing the following steps:

1. Download the ISE patch bundle ise-patchbundle-2.4.0.357-Patch11-19121619.SPA.x86_64.tar.gz.

Note: Software downloads from Cisco website requires a registered Cisco Account and Cisco software download access.

2. Log in to the ISE GUI and navigate to Administration > Maintenance > Patch Management.

3. Click Install, upload the patch file, and then click Install again. The installation will take ~1 hour and during the time, ISE will not be available.

4. To verify the patch is installed successfully, check Patch Management in to see whether the Patch 11 is listed, as shown in Figure 5:

Figure 5 Cisco ISE Patch Installation View

\

This completes the installation and relevant patch upgrade of ISE compatible with Cisco DNA Center Release 1.3.

Note: Refer to the Cisco SD-Access 1.3.3.x Hardware and Software Compatibility Matrix for more details on Cisco DNA Center 1.3.3-supported hardware and its software versions.

Integrating ISE with Cisco DNA Center

Once ISE installation and basic configuration is complete, it has to be integrated with the Cisco DNA Center. Refer to the section Integrate Cisco ISE with Cisco DNA Center in the Cisco DNA Center Installation Guide Release 1.3.3.0 at the following URL:

■ https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center/1-3-3-0/install_guide/2ndGen/b_cisco_dna_center_install_guide_1_3_3_0_2ndGen/b_cisco_dna_center_install_guide_1_3_2_0_M5_chapter_0111.html#task_ikj

Note: Before integrating ISE with the Cisco DNA Center, ensure that PxGrid services are online on ISE and that the cluster node is up in Cisco DNA Center.

Once integrated with Cisco DNA Center using PxGrid, information sharing between the two platforms is enabled, including device information and group information. This allows the Cisco DNA Center to define policies that are pushed to ISE and then rendered into the network infrastructure by the ISE Policy Service Nodes (PSNs). When integrating the two platforms, a trust is established through mutual certificate authentication. This authentication is completed seamlessly in the background during integration and requires both platforms to have accurate NTP time synchronization.

Configuring DHCP and DNS Services

DHCP Server

A DHCP Server is a network server that automatically provides and assigns IP addresses, default gateways, and other network parameters to client devices. It relies on the standard protocol known as Dynamic Host Configuration Protocol (DHCP) to respond to broadcast queries by clients.

DHCP services can be configured in the network in many ways. In this implementation, a centralized DHCP services in the CCI network shared services, running on a Windows 2016 server is used. This section covers the example DHCP scope and IP pools definition and discusses other scope options that are required for implementing SD-Access in the CCI network.

Refer to the step-by-step instructions on Microsoft Windows Server 2016: DHCP Server Installation & Configuration at the following URL:

■ https://social.technet.microsoft.com/wiki/contents/articles/51170.microsoft-windows-server-2016-dhcp-server-installation-configuration.aspx

After the DHCP server is successfully configured on a Windows 2016 server, create Scopes for all the IP pools configured on the Cisco DNA Center with options 43 (example pools are for extended node and host node pools) in the DHCP server, as shown in Figure 6:

Figure 6 Example IP Scope and Scope Options in CCI Network

For more information on DHCP options 43, refer to the section DHCP Controller Discovery in the Cisco Digital Network Architecture Center User Guide, Release 1.3.3.0 at the following URL:

■ https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center/1-3/user_guide/b_cisco_dna_center_ug_1_3/b_cisco_dna_center_ug_1_3_chapter_0110.html#id_90877

Domain Name Server (DNS)

In this implementation, Domain Name Servers (DNS) in the CCI network shared services, running on a Windows 2016 server (co-located on the DHCP server), are used.

Refer to the following URL for step-by-step instructions and configuration of the DNS on the Windows 2016 server for the CCI network:

■ https://www.microsoftpressstore.com/articles/article.aspx?p=2756482

Implementing Field Network Director (FND) for CCI

Cisco Field Network Director (FND) is an essential component for IoT solution deployments. FND in CCI provides easier deployment and management of devices such as Field Area Routers (CGR), Connected Grid End Points (CGEs) and IC3000 Industrial Compute Gateway. FND is the critical component of the FAN solution. FND is the one component that interacts with most of the components in the FAN solution.

For information about installing/configuring FND, refer to the following URL:

■ https://www.cisco.com/c/en/us/td/docs/routers/connectedgrid/iot_fnd/install/oracle/iot_fnd_oracle/installation_rpm_new_oracle.html

Note: FND with the Oracle database, which is used in this implementation, is needed for CGR mesh support.

Prerequisites for FND Installation

■In the CCI network, FND OVA (this OVA includes Oracle for mesh management (CGR, IR5x)), the user can download it from the following link:

– https://software.cisco.com/download/home/286287993/type/286320249/release/4.5.1

Note: -v containing image should be used for mesh deployment.

Note: After download, please use the iot-fnd-oracle-4.4.0-79.ova file to install the FND Application.

■FND is installed in the shared services network in CCI so that it can be accessible by FAR and other headend components. The installation steps can be found at the following link (refer to section “Prerequisites > Installing the OVA”).

– https://www.cisco.com/c/en/us/td/docs/routers/connectedgrid/iot_fnd/install/ova/installation-ova-fnd-4-3-1.html#pgfld-1544292

■RHEL needs an active account with access to subscription management, needed for performing yum updates, yum install, and so on. Addressing these prerequisites is beyond the scope of this document. Please refer to Red Hat documentation.

■IP address configuration on a couple of interfaces:

–a) One interface configured with the IP Address of the FND:

• The interface must be configured with an IPv4 address and an IPv6 address.

–b) Another temporary interface providing internet connectivity.

Implementation of FND

■The FND implementation guide is available in the section “Implementing Field Network Director” for detailed implementation (user can skip the sub-sections “Integrating FND with TPS Proxy” and “Integrating FND with FND-DB”) at the following URL:

– https://salesconnect.cisco.com/#/content-detail/da249429-ec79-49fc-9471-0ec859e83872

■After successful implementation, you should check the status of FND in the CLI:

Implementation of Cisco IC3000 Industrial Compute Gateway

In CCI, the IC3000 Industrial Compute Gateway connected to the edge switch via the management port learns about the FND via the DHCP server through option 43 and connects to the FND. Registration succeeds assuming the CSV file is uploaded to the FND and connectivity exists between the FND and the IC3000 Industrial Compute Gateway. As part of registration, FND enables the data ports for data traffic if enabled from the IC3000 Industrial Compute Gateway template under the FND.

For information about managing/deploying IC3000 Industrial Compute Gateway, refer to the Cisco IC3000 Industrial Compute Gateway Deployment Guide at the following URL:

■ https://www.cisco.com/c/en/us/td/docs/routers/ic3000/deployment/guide/DeploymentGuide.html

Configuring Fog Director for CCI

The FND Oracle-embedded database does not have Fog Director included by default and, therefore, to manage applications on IC3000 Industrial Compute Gateway, a separate Fog Director is required. The details here demonstrate installing and running Cisco Kinetic Edge and Fog Processing Module (EFM) through the Fog Director.

Note: Fog Director manages the applications on IC3000 Industrial Compute Gateway such as EFM whereas Field Network Director (FND) manages the hardware on the IC3000 Industrial Compute Gateway such as upgrading/downgrading firmware.

To download EFM, please refer to following URL:

■ https://www.cisco.com/c/en/us/support/cloud-systems-management/edge-fog-fabric-version-1-0/model.html#~tab-downloads

1. Log in to the Fog Director portal and upload the application package (EFM package for IC3000) via APPS > Import App as shown in Figure 7:

Figure 7 Fog Director Upload New Applications

2. Once the app is uploaded, add the IC3000 device using the management IP address (IP address can be obtained from FND), port and credentials (updated through FND). Under DEVICES > Add New Device, add the device as shown in Figure 8:

Figure 8 Fog Director Add New Device

3. Install the application on IC3000 via APPS > EFM > Install > Add Selected Devices while also updating the following parameters/attributes for EFM in Data Center connectivity:

a. Under Installation Summary > Customize Configuration, update broker.upstream to True, URL to the IP address of EFM in the Data Center, and other attributes.

b. Under Installation Summary > Configure Networking, select corresponding networks and assign the networks by selecting REASSIGN NETWORKS for upstream (EFM in Data Center) and downstream (RSU - Road Side Unit) connectivity. For example, if int1 is connected to upstream network, then eth0 should be assigned with int1(bridge) and if int2 is connected to downstream network, then eth1 should be assigned with int2 (bridge). Refer to the CCI Solution Design Guide for IC3000 networking details.

c. Install the application with the above configured changes via Installation Summary > Done Let's Go.

4. Refer to Figure 9 for successfully installed and started application where the App Status changes to RUNNING:

Figure 9 Fog Director Applications Installation Status

5. Once the application is installed, the connection with upstream broker is established. For connecting RSU to EFM running on IC3000, the IP address of downstream, which can be obtained via DEVICES > IC3000 > App/Service Details, as shown in Figure 10, should be used:

Figure 10 Fog Director Devices and Applications Detailed View

Implementing Centralized WLC for CUWN

In CCI, Cisco Catalyst 9800 Series Wireless Controller (C9800-40) is configured as a Centralized Wireless LAN Controller (WLC) with High Availability (HA) for managing Cisco Unified Wireless Network (CUWN) with Wi-Fi mesh deployments in PoPs. Refer to the “Cisco Unified Wireless Network (CUWN) with Mesh” section in the Connected Communities Infrastructure Design Guide at the following URL for more details on the design.

■ https://www.cisco.com/c/en/us/td/docs/solutions/Verticals/CCI/CCI/DG/cci-dg.html

This section covers the initial installation and HA configuration of C9800-40 WLC in CCI Shared Services network. This section applies to you if you are doing CUWN wireless, and deploying WLC centrally in Shared Services.

Cisco WLC (C9800-40) Installation and initial configuration

The Cisco Catalyst 9800-40 Wireless Controller is a 40-G wireless controller that offers a compact form factor that consumes less rack space and power while offering 40 Gbps forwarding throughput. This section covers the installation and Day-0 Configuration required to setup the C9800 WLC.

Refer to the following URL for rack mounting and installing the C9800-40 hardware:

■ https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/9800-40/installation-guide/b-wlc-ig-9800-40/installing-the-controller.html

Once the WLC is rack mounted, verify the following:

1. The network interface cable or the optional Management port cable is connected.

2. The chassis is securely mounted and grounded.

3. The power and interface cables are connected

4. Terminal server is connected to the console port.

There are two modes in which a IOS XE software image on a Catalyst 9800 WLC can run: Install mode; Bundle mode.

Install Mode

The install mode uses pre-extracted files from the binary file into the flash in order to boot the controller. The controller uses the ‘packages.conf’ file that was created during the extraction as boot variable.

Bundle Mode

The system works in bundle mode if the controller boots with the binary image (.bin) as boot variable. In this mode the controller extracts the.bin file into the RAM and runs from there. This mode uses more memory than install mode since the packages extracted during boot up are copied to the RAM.

Note: Install mode is the recommended mode to run the wireless controller.

Boot the controller in INSTALL mode:

Step 1: Make sure to boot from flash:packages.conf (and we don't have other boot files specified in our config)

Step 2: Install software image to flash. The install add file bootflash:<image.bin> activate commit command moves the switch from bundle-mode to install-mode where image.bin is our base image.

Step 3: Type yes to all the prompts. Once the installation is completed the controller proceeds to reload.

Step 4: After the controller bootup, you can verify the current installation mode of the controller. Run the show version command to confirm the mode.

For more details on WLC power up and initial configuration, refer to the following URL:

■ https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/9800-40/installation-guide/b-wlc-ig-9800-40/power-up-and-initial-configuration.html

Day-0 Manual Configuration using the Cisco IOS-XE CLI:

C9800-40 WLC is connected to shared services network with 10G link. The steps to access WLC CLI to perform the initial configuration on the controller is provided below.

Step 1: Terminate the configuration wizard (this wizard it’s not specific for wireless controller):

Step 2: Press Return and continue with the manual configuration.

Step 3: Press Return to bring up the WLC> prompt and Type enable to enter privileged EXEC mode.

Step 4: Enter the config mode and set the hostname:

Step 5: Configure login credentials:

Step 6: Configure the VLAN for wireless management interface. Shared services VLAN in CCI network.

Step 7: Configure the SVI for wireless management interface.

Step 8: Configure the interface TenGigabitEthernet0/0/1 as trunk:

Step 9: Configure a default route (or a more specific route) to reach the box:

Step 10: Disable the wireless network to configure the country code:

Step 11: Configure the AP country domain. This configuration is what will trigger the GUI to skip the DAY 0 flow as the C9800 needs a country code to be operational:

Step 12: Specify the interface to be the wireless management interface:

Step 13: For the Controller to be discovered by the Cisco DNA Center or Prime Infrastructure, CLI, SSH and SNMP credentials should be configured on the devices along with Netconf:

Verify that you can ping the wireless management interface and then just https://<IP of the device wireless management interface>. Use the credentials you have entered earlier. Since the box has a country code configured, the GUI will skip DAY 0 page and you will get access to the main Dashboard for DAY 1 configuration.

Accessing C9800-40 WebUI:

Access the C9800 Web UI using https://<IP_addr_of_C9800-40-WLC>.The username and password configured during the Day-0 configuration of WLC must be used to log on to WLC Web UI. Figure 11.1 shows C9800-40 WLC Web UI dashboard view after successful login.

Figure 11 Cisco 9800-40 WLC Web UI Login – Dashboard View

Cisco WLC (C9800-40) High Availability (HA) configuration

High availability has been a requirement on wireless controllers to minimize downtime in live networks. This section provides information on the theory of operation and configuration for the Catalyst 9800 Wireless Controller as it pertains to supporting stateful switchover of access points and clients (AP and Client SSO).

The redundancy explained on this document is 1:1, which means that one of the boxes will be in Active State while the other one will be in Hot Standby. If the active box is detected to be unreachable, the Hot Standby unit will become Active and all the APs and clients will keep its service through the new active box.

Once both boxes are synchronized with each other, the standby 9800 WLC will mimic its configuration with the primary box. Any configuration change is done on the active unit will be replicated to the standby unit via the Redundancy Port (RP). Configuration changes are no longer allowed to be performed on the standby 9800 WLC.

Besides the synchronization of the configuration between boxes, they also synchronize the APs in UP state (not APs in downloading state or APs in DTLS handshaking), clients in RUN state (this means that if there is a client in Web Authentication required state and a switchover occurs, that client will have to restart its association process), RRM configuration along other settings.

For more details on deployment and configuration, refer to the following URL:

■ https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-1/config-guide/b_wl_17_11_cg/high-availability.html

HA Prerequisites:

■HA Pair can only be form between two wireless controllers of the same form factor

■Both controllers must be running the same software version in order to form the HA Pair

■Maximum RP link latency = 80ms RTT, minimum bandwidth = 60 Mbps and minimum MTU = 1500

Configure HA on 9800 WLC Hardware:

C9800-40-K9 Wireless controller has two RP Ports as shown in Figure 11.2:

Figure 12 C9800-40 WLC Front View

In Figure 12:

1. RJ-45 Ethernet Redundancy port

2. SFP Gigabit Redundancy Port

The HA Pair always has one active controller and one standby controller. If the active controller becomes unavailable, the standby assumes the role of the active. The Active wireless controller creates and updates all the wireless information and constantly synchronizes that information with the standby controller. If the active wireless controller fails, the standby wireless controller assumes the role of the active wireless controller and continues to the keep the HA Pair operational. Access Points and clients continue to remain connected during an active-to-standby switchover.

Figure 13 C9800-40 WLC HA Network Topology

Redundancy SSO is enabled by default but you still need to configure the communication between the boxes. Follow the step-by-step instructions below for deploying WLC in HA.

Step 1: Make sure both the C9800 WLCs are reachable to each other. Wireless management interface from both boxes must belong to the same VLAN and subnet. Connected to Nexus5k in our case.

Step 2: Connect both 9800 WLC to each other through its RP port.

There are two options to connect both 9800 WLCs to each other, choose the one that fits you more. In this example implementation, RJ45 Ethernet ports are connected.

1. Redundancy Port - RJ45 10/100/1000 redundancy Ethernet port, as shown in Figure 14:

Figure 14 C9800-40 WLC RJ45 Redundancy Ports Connection

2. Redundancy Port - 10-GE SFP ports, as shown in Figure 15:

Figure 15 C9800-40 WLC 10GE SFP Redundancy Ports Connection

Step 3: Provide the required redundancy configurations to both 9800 WLCs.

Step 4: On WLC Web UI, Navigate to Administration > Device > Redundancy. Enable “Redundancy Configuration”, check ‘RP’ for “Redundancy Pairing Type” and enter the desired IP address along with the Active and Standby Chassis Priorities. Both boxes should have its own IP address, and both should belong to the same subnet.

On the Active controller, the priority is set to a higher value than the standby controller. The wireless controller with the higher priority value is selected as the active during the active-standby election process. If we do not choose a specific box to be active, the boxes themselves will elect Active based on lowest MAC address. The Remote IP is the IP address of the standby controller’s redundancy port IP.

C9800-40 WLC1 & C9800-40 WLC2:

Figure 16 Redundancy Pairing on both C9800-40 WLCs

Step 4: Switch to C9800 WLC CLI and configure Chassis HA interface

Step 5: Configures the priority of the specified device

Cisco Prime Infrastructure Installation and Configuration

Cisco Prime Infrastructure (PI) will act as a dedicated Network Management Server (NMS) providing network device and client monitoring and reporting services. The solution will integrate WLCs and APs with the existing virtual PI deployment. All configuration for WLCs and APs can be deployed using PI with the aid of configuration templates.

This section describes how to configure and integrate Catalyst 9800 Series Wireless Controllers with Prime Infrastructure (3.7) which uses CLI, Simple Network Management Protocol (SNMP) and NETCONF. Configuration details for SNMPv2 and SNMPv3 are included.

PI 3.7 Installation:

PI 3.7 Virtual Appliance (VA) is installed in Shared Services network. Refer to the installation guide at the following URL which describes how to install Cisco Prime Infrastructure 3.7 as an OVA on VMware. Download the OVA file PI-VA-3.7.0.0.159.ova from Cisco.com. Verify the integrity of the OVA file using its checksum listed on Cisco.com.

■https://www.cisco.com/c/en/us/td/docs/net_mgmt/prime/infrastructure/3-7/quickstart/guide/bk_Cisco_Prime_Infrastructure_3_7_0_Quick_Start_Guide.html

Figure 17 Prime Infrastructure 3.7 Verification

Access the PI WebUI with the IP address configure:

Figure 18 Cisco Prime Infrastructure Web UI - Dashboard View

Managing Catalyst 9800 WLC with Prime Infrastructure using SNMP v3 and NetCONF

In order for Prime Infrastructure to configure, manage and monitor Catalyst 9800 Series Wireless LAN Controllers, it needs to be able to access Cat9800 via CLI, SNMP and Netconf. When adding Cat9800 to Prime Infrastructure, telnet/SSH credentials as well as SNMP community string, version etc will need to be specified. PI uses this information to verify reachability and to inventory Cat9800 WLC. It will also use SNMP to push configuration templates as well as support traps for AP and client events. However, in order for PI to gather Access Point (AP) and Client statistics, Netconf is leveraged. Netconf is not enabled by default on Cat9800 WLC and needs to be manually configured.

For more details, refer to the following URL:

■ https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9800-series-wireless-controllers/214286-managing-catalyst-9800-wireless-controll.html

Configuration on C9800 WLC

SNMPv2 Configuration on Cat 9800 WLC

GUI:

Step 1. Navigate to Administration > Management > SNMP > Slide to Enable SNMP

Step 2. Click on Community Strings and create a Read-Only and a Read-Write community name

CLI:

SNMPv3 Configuration on Cat 9800 WLC

GUI:

Note: As of 17.1 IOS-XE, the web UI will only allow to create read-only v3 users. Follow the CLI procedure to create a read-write v3 user.

Click on V3 users. Create a user, choose "authPriv", SHA and AES protocols and chose long passwords as show in below image.

Figure 19 Cisco 9800-40 WLC SNMP Configuration

CLI:

Note: SNMPv3 User Config is not reflected on running-configuration. Only SNMPv3 group configuration is seen

NETCONF configuration on the Cat 9800 WLC:

GUI:

Navigate to Administration > Management > HTTP/HTTPS/NetConf

CLI:

Note: If aaa new-model is enabled on Cat9800, then we will also need to configure

Netconf on 9800 uses the default method (and we cannot change this) for both aaa authentication login as well as aaa authorization exec. In case we want to define a different method for SSH connections, we can do so under the "line vty" command line. Netconf will keep using the default methods.

Cisco Prime Infrastructure 3.7 Configuration

GUI:

Navigate to Configuration > Interface > Wireless

Step 1. Capture the Wireless Management IP address configured on the Catalyst 9800 WLC

CLI:

Navigate to Administration > User Administration

Step 2. Capture the privilege 15 user credentials as well as enable password

CLI:

Step 3. Get the SNMPv2 community strings and/or SNMPv3 user as applicable

GUI:

For SNMPv2, Navigate to Administration > Management > SNMP > Community Strings

For SNMPv3, Navigate to Administration > Management > SNMP > V3 Users

CLI:

Step 4. On Prime Infrastructure GUI, navigate to click on Configuration > Network : Network Devices > Click on Drop-Down beside + > Select Add Device

Step 5. On the Add Device pop-up, enter the interface IP address on 9800 that will be used to establish communication with Prime Infrastructure.

Step 6. Navigate to SNMP tab and provide SNMPv3 details configured on Cat9800 WLC. From Auth-Type Drop-down match the previously configured authentication type and from Privacy Type Drop-Down select the encryption method configured on Cat9800 WLC.

Step 7. Navigate to Telnet/SSH tab of Add Device, provide the Privilege 15 Username and Password along with Enable Password. Click on Verify Credentials to ensure CLI, SNMP credentials work fine. Then click on Add, as shown in Figure 20.

Figure 20 Adding C9800 WLC to the PI

Verification:

Step 1. Verify that Netconf is enabled on Cat9800:

Step 2. Verify the telemetry connection to Prime from the Cat9800

Step 3. On Prime Infrastructure, navigate to Inventory > Network Devices > Device Type and verify the status as shown in Figure 21.

Figure 21 C9800 WLC on the PI as a Managed Device

Preparing Cisco DNA Center for PoP Site Provisioning

In the Cisco DNA Center, the “Design” area is where you create the structure and framework of your network, including the physical topology, network settings, and device type profiles that you can apply to devices throughout your network. Create a network hierarchy of areas, buildings, and floors that reflect the physical deployment. In later steps, discovered devices are assigned to respective PoP sites in Cisco DNA Center GUI, so that they are displayed hierarchically in the topology maps.

To prepare to design your Cisco DNA Center for CCI network fabric implementation, refer to the Chapter "Design Network Hierarchy & Settings” in the Cisco Digital Network Architecture Center User Guide, Release 1.3.3.0 at the following URL:

■ https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center/1-3-3-0/user_guide/b_cisco_dna_center_ug_1_3-3-0/b_cisco_dna_center_ug_1_3_2_0_chapter_0110.html

1. Creating Network Hierarchy

In this implementation, three fabric sites are created as shown in Figure 3 and Figure 4 for various deployment models of the network topologies with IP Transit and SD-Access Transit fabric interconnection. Example fabric sites with the names MGRoad, Hebbal, Elex City are configured for the fabric sites PoP1 Site, PoP2 Site, PoP3 Site respectively. In Figure 22, the sites with names Cessna and Koramangala are configured as HQ/DC site and SDA transit site respectively.

Note: In CCI deployment, a PoP site can be mapped to an area with a building under that area in Cisco DNA Center network hierarchy. By creating buildings, you can apply settings to a specific area or a PoP site.

For more details about Network Hierarchy and steps to configure the hierarchy of PoP sites and HQ/DC Site, refer to the following URL:

■ https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center/1-3-3-0/user_guide/b_cisco_dna_center_ug_1_3_3_0/b_cisco_dna_center_ug_1_3_2_0_chapter_0110.html

Figure 22 shows an example Network Hierarchy under the Design tab in the Cisco DNA Center user interface for the CCI network implementation:

Figure 22 Example CCI Network Hierarchy View in Cisco DNA Center

2. Configure Network Settings

Set up network properties such as AAA, DHCP, DNS, and NTP for the CCI network. Cisco DNA Center will configure the network settings on the devices while provisioning the discovered devices in the fabric.

Refer to the following sections to configure network settings:

–About Global Network Settings:

• https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center/1-3-3-0/user_guide/b_cisco_dna_center_ug_1_3_3_0/b_cisco_dna_center_ug_1_3_2_0_chapter_0110.html#concept_gvs_1rd_wy

–About configuring Global Network Servers:

• https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center/1-3-3-0/user_guide/b_cisco_dna_center_ug_1_3_3_0/b_cisco_dna_center_ug_1_3_2_0_chapter_0110.html#task_bw1_vyb_yz

Figure 23 shows an example Network Settings configured in the Cisco DNA Center for the CCI network topology:

Figure 23 Example Global Network Settings View in Cisco DNA Center

3. Setting Device Credentials for Device Discovery

–Device credentials refer to the CLI, SNMP, and HTTPS credentials that are configured on network devices. Cisco DNA Center uses these credentials to discover and collect information about the devices in your network. Configure global/site level device credentials to discover all the network devices in the CCI network for fabric/PoP site provisioning.

Refer to the following sections for configuring device credentials in the Cisco DNA Center:

–About Global Device Credentials:

• https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center/1-3-3-0/user_guide/b_cisco_dna_center_ug_1_3_3_0/b_cisco_dna_center_ug_1_3_2_0_chapter_0110.html#concept_zww_qtd_wy

–About configuring Global CLI Credentials:

• https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center/1-3-3-0/user_guide/b_cisco_dna_center_ug_1_3_3_0/b_cisco_dna_center_ug_1_3_2_0_chapter_0110.html#task_a5t_5xg_2z

–About configuring SNMPv3 Credentials:

• https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center/1-3-3-0/user_guide/b_cisco_dna_center_ug_1_3_3_0/b_cisco_dna_center_ug_1_3_2_0_chapter_0110.html#task_fgz_lyg_2z

4. Configure IP Address Pools

IP address pools that will used for fabric infrastructure provisioning, extended nodes in the CCI network, and data network are manually defined and configured on the Cisco DNA Center. It reserves pools as a visual reference for use in fabric sites (PoPs). In this implementation, a windows DHCP server is used.

Alternatively, you can integrate third party IP Address Manager (IPAM) servers to Cisco DNA Center in order reduce IP address management tasks. IPAM integration with Cisco DNA Center provides:

–Access to existing IP address scopes, referred to as IP address pools in Cisco DNA Center.

–When configuring new IP address pools in Cisco DNA Center, the pools populate to the IPAM server automatically.

To integrate IPAM server to Cisco DNA Center, refer to the "Configure an IP Address Manager" section at the following URL:

– https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center/1-3-3-0/user_guide/b_cisco_dna_center_ug_1_3_3_0/b_cisco_dna_center_ug_1_3_2_0_chapter_0110.html#task_umt_4kt_pcb

Refer to the following sections for adding and reserving IP address pools as needed in CCI network deployment:

–Configure IP Address Pool:

• https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center/1-3-3-0/user_guide/b_cisco_dna_center_ug_1_3_3_0/b_cisco_dna_center_ug_1_3_2_0_chapter_0110.html#task_znt_jdc_yz

–Reserve an IP Pool:

• https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center/1-3-3-0/user_guide/b_cisco_dna_center_ug_1_3_3_0/b_cisco_dna_center_ug_1_3_2_0_chapter_0110.html#id_105306

Figure 24 and Figure 25 show example IPv4 address pools with global network prefixes and reserved IP pools in a site for fabric border network handoff, extended node, and data networks on fabric overlay VNs:

Figure 24 Example Global IPv4 Address Pools View in Cisco DNA Center

Figure 25 Example IPv4 Address Pools Reserved in a Fabric/PoP Site

This completes the initial preparation of Cisco DNA Center for devices discovery and fabric site provisioning.

Discovering Devices in the Network

Cisco DNA Center is used to discover and manage the SD-Access underlay network devices that are compatible with the Cisco DNA Center. For the list of the devices supported by Cisco DNA Center, refer to the following URL:

■ https://www.cisco.com/c/en/us/solutions/enterprise-networks/software-defined-access/compatibility-matrix.html

To discover equipment in the network, the appliance must have IP reachability to these devices, and CLI and SNMP management credentials must be configured on the devices. Once discovered, the devices are added to Cisco DNA Center's inventory, allowing the controller to make configuration changes through provisioning.

1. For the Network devices to be discovered by the Cisco DNA Center, CLI and SNMP credentials should be configured on the devices as configured at the Cisco DNA Center in the previous section.

The example configuration used network devices in this implementation:

a. Configure CLI SSH user credentials on the network device. Example configuration on Cisco Catalyst 9300 Switch Stack:

b. Configure SNNMPv3 credentials on the network device. Example configuration on Cisco Catalyst 9300 Switch Stack:

c. Enable SSH Version 2 access on the network device. Example configuration on Cisco Catalyst 9300 Switch Stack:

Repeat the above configurations on all the network devices in the network to be discovered by the Cisco DNA Center.

2. For detailed step-by-step instructions on discovering all the device in the CCI network on Cisco DNA Center, refer to the chapter "Discover your Network"in the Cisco Digital Network Architecture Center User Guide, Release 1.3.3.0 at the following URL:

– https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center/1-3-3-0/user_guide/b_cisco_dna_center_ug_1_3_3_0/b_cisco_dna_center_ug_1_3_2_0_chapter_010.html

Once device discovery is successful, all the devices are added to Cisco DNA Center Inventory, as shown in the example in Figure 26:

Figure 26 Example List of Discovered Devices in Cisco DNA Center Inventory

Provisioning Devices in SD-Access

Once the devices are discovered and managed in the Cisco DNA Center inventory, devices have to be provisioned to the sites for SD-Access Deployment.

For more details and step-by-step instruction for provisioning devices in SD-Access site, refer to the following section in the Software-Defined Access for Distributed Campus Deployment Guide at the following URL:

■ https://www.cisco.com/c/en/us/td/docs/solutions/CVD/Campus/SD-Access-Distributed-Campus-Deployment-Guide-2019JUL.html#_Toc13487388

For how to assign the device to sites and provisioning devices, click “Process 5: Deploying SD-Access with the Provision Application” and follow Procedures 1 and 2 at the following URL:

■ https://www.cisco.com/c/en/us/td/docs/solutions/CVD/Campus/SD-Access-Distributed-Campus-Deployment-Guide-2019JUL.html#_Toc13487382

Once the devices are provisioned to the sites, all the details added in the network settings like AAA, NTP, DHCP, and DNS are configured on the devices by Cisco DNA Center.

Provisioning Fabric Overlay Network

Once devices are provisioned to a site, the fabric overlay workflows can begin. This starts through the creation of transits, the formation of a fabric domain, and the assignment of sites, buildings, and/or floors to this fabric domain.

Fabric domain is configured in the Cisco DNA Center for a fabric overlay network. After adding the sites to the Network Hierarchy, the network sites have to be part of a fabric domain. Once the fabric domain is added, add the transit networks (either IP transit or SDA transit or both) for interconnecting multiple fabric sites (PoPs). In this implementation, both the transit network types (IP Transit and SD-Access Transit) are validated for the network topologies, as shown in Figure 3 and Figure 4.

Configuring Fabric Domain and Transit Network(s)

Depending on your network deployment and backhaul network for interconnecting fabric sites, you can choose to deploy either IP Transit or SD-Access Transit as applicable:

1. For provisioning the fabric domain and creating a IP-based transit network in the Cisco DNA Center, click "Process 6: Provisioning the Fabric overlay"and follow Procedures 1, 3, and 4 in the Software-Defined Access for Distributed Campus Deployment Guide at the following URL:

– https://www.cisco.com/c/en/us/td/docs/solutions/CVD/Campus/SD-Access-Distributed-Campus-Deployment-Guide-2019JUL.html#_Toc13487387

2. Optionally, follow Procedure 2 to create an SD-Access transit network for an example network topology, as shown in Figure 3.

Note: For the SD-Access transit network, it is required to assign the transit control plane nodes (example: Cisco Catalyst 9500 switches) to a site that will be provisioned as a SD-Access transit site, by completing the steps mentioned in Provisioning Devices in SD-Access.

Figure 27 shows an example fabric domain: IP-based Transit and SD-Access Transit networks created for the network topology in Figure 3 and Figure 4 :

Figure 27 Example Fabric Domain, IP-based and SD-Access Transit Networks

Assigning Fabric Role (Fabric-in-a-Box)

Once the sites are added to the fabric domain in the Cisco DNA Center, a Cisco Catalyst 9300 Stack that is added in a site is provisioned with fabric roles. A fabric overlay consists of three different fabric nodes: control plane node, border node, and edge node. To function, a fabric must have an edge node and control plane node. This allows endpoints to traverse their packets across the overlay to communicate with each other (policy dependent). The border node allows communication from endpoints inside the fabric to destinations outside of the fabric along with the reverse flow from outside to inside.

In the CCI network fabric site (PoP), a switch stack (Cisco Catalyst 9300) is configured with all the fabric roles (i.e., border, control plane, and edge called FiaB). Fabric is provisioned with an overlay VN; i.e., macro-segmentation for the overlay network is defined. (Note that the overlay network will only be fully created until the host onboarding stage). This process virtualizes the overlay network into multiple self-contained VNs.

1. Creating Overlay VN

In the CCI network, VNs and SGTs are created for each vertical use case overlaid on the CCI network. An example list of VNs created in this implementation are available in Table 2.

–To create VNs in the fabric as needed, refer to Procedure 1 under section "Process 4: Creating Segmentation with the Cisco DNA Center Policy Application"in the Software-Defined Access for Distributed Campus Deployment Guide.

2. Associate VN to Fabric Domain

IP address pools enable host devices to communicate within the fabric domain. Associate IP addresses pools for end-points data traffic in the overlay VN.

–Follow the "Select Authentication Template and Associate Virtual Networks to Fabric Domain" procedures of the section "Configure a Fabric Domain" in the chapter "Provision your network" in the Cisco Digital Network Architecture User Guide, Release 1.3.3.0.

Note: Select "No Authentication" for the default Authentication Template for a fabric site. The No Authentication template is selected as default template.

Figure 28 shows an example VN and overlay IP pools associated with a VN (SnS_VN) in the CCI network:

Figure 28 Example Virtual Network and IP Pools Association in CCI Network

–Similarly, associate an IP pool in the fabric default INFRA_VN for Extended Nodes IP addressing.

3. Provisioning Fabric-in-a-Box (FiaB)

Once the VNs are associated with the fabric sites, provision a Cisco Catalyst 9300 Switch stack as FiaB in the CCI fabric (PoP) site. A Layer 3 handoff that extends the fabric VNs to the next hop (i.e., fusion router, in the case of IP-based Transit or SDA Transit CP or intermediate network device, in the case of SDA Transit). This will allow the end-points in the fabric to access shared services once the fusion router configuration is completed.

Complete the following steps to provision a Cisco Catalyst 9300 Switch stack in a fabric/PoP site as FiaB for IP-based transit network topology, as shown in Figure 3:

a. In Cisco DNA Center, navigate to Provision > Fabric.

b. Select the Fabric Enabled Site (Bangalore) that was created.

c. Select the PoP site (MGRoad) from the fabric-enabled sites in the left pane.

d. Select the device to be provisioned as a FiaB. A slide pane appears.

e. On the slide pane, select the roles Edge node, control plane, and border node, as shown in Figure 29:

Figure 29 Example FiaB Provisioning View for IP Transit

f. Click Configure next to Border Role, configure the local Autonomous number for the site, and select the Layer 3 handoff network pool associated with the site.

g. Under the Transit/Peer networks, enable the option Default to all Virtual networks and then select the transit site. In this case, we used SD Access Transit.

h. Select the Transit Control Plane devices and then click Add.

Example provisioning for IP transit external interfaces is shown in Figure 30:

Figure 30 Example FiaB Border Configuration for SD-Access Transit in CCI Network

i. Once done, click Add and Save to provision the FiaB and for the successful provisioning of the Fabric message in the Cisco DNA Center UI.

j. Verify the FiaB provisioning in Cisco DNA Center UI for the network site. No errors should be reported in the Fabric Infrastructure map view of the FiaB.

Alternatively, if you are deploying an IP Transit based network topology, as shown in Figure 4, you need to configure the FiaB Border to connect to an SD-Access Transit Network created in Step 2 of the Configuring Fabric Domain and Transit Network(s).

Refer to the following URL for steps to create the IP Transit network in Cisco DNA Center:

■https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center/1-3-3-0/user_guide/b_cisco_dna_center_ug_1_3_3_0/b_cisco_dna_center_ug_1_3_2_0_chapter_01100.html?bookSearch=true#id_75992

This completes the FiaB provisioning or fabric role assignment in the fabric overlay network for a PoP site connected to either the SD-Access Transit or IP-based Transit network.

Implementing Wireless LAN Controller (WLC) in a PoP

In CCI, Cisco Catalyst 9800 Series Wireless Controller (C9800-L) or Cisco Catalyst 9300 Series Switch Stack with embedded Wireless Controller can be configured. C9800-L WLC manages Cisco Unified Wireless Network (CUWN) Wi-Fi access mesh and non-mesh deployments. Alternatively, an embedded WLC on C9300 switch stack can be deployed for managing SD Access Wireless (Wi-Fi) networks. Refer to the “CCI Wi-Fi Access Network Solution” section in the Connected Communities Infrastructure Design Guide at the following URL for more details on the CCI Wi-Fi design.

■ https://www.cisco.com/c/en/us/td/docs/solutions/Verticals/CCI/CCI/DG/cci-dg.html

Implementing Cisco Unified Wireless Network WLC (C9800-L)

Cisco Catalyst 9800-L Wireless Controller can be configured as a per PoP Wireless LAN Controller (WLC) with High Availability (HA) for managing CUWN Wi-Fi networks within a PoP. Cisco Catalyst 9800-L Wireless Controller is the first low-end controller that provides a significant boost in performance and features from Cisco 3504 Wireless Controller. This section covers the initial installation and HA configuration of C9800-L WLC in a CCI PoP.

For more details on C9800-L controller, refer to the following URL:

■ https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/9800-L/installation-guide/b-wlc-ig-9800-L/overview.html

For rack mounting and installing the C9800-L hardware, refer to the following URL:

■ https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/9800-L/installation-guide/b-wlc-ig-9800-L/Installing-the-Cisco-Catalyst-9800-L-Wireless-Controller.html

Once the WLC is rack mounted make sure the following:

1. The network interface cable or the optional Management port cable is connected.

2. The chassis is securely mounted and grounded.

3. The power and interface cables are connected

4. Terminal server is connected to the console port

Note: Install mode is the recommended mode to run the wireless controller.

Boot the controller in INSTALL mode:

Step1: Make sure to boot from flash:packages.conf (and you don't have other boot files specified in your config)

Step2: Software install image to flash. The install add file bootflash:<image.bin> activate commit command moves the switch from bundle-mode to install-mode where image.bin is our base image.

Step3: Type yes to all prompts. When the install is complete, the controller reloads.

Verify:

After the controller reboot we can verify the current installation mode of the controller. Run show version to confirm.

For more details on WLC power up and initial configuration, refer to the following URL:

■ https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/9800-L/installation-guide/b-wlc-ig-9800-L/Power-Up-and-Initial-Configuration.html

Day-0 Manual Configuration using the Cisco IOS-XE CLI:

C9800-L WLC is connected to one of our CCI PoP sites MGRoad C9300 FiaB Switch with 10G link.

This section shows you how to access the CLI to perform the initial configuration on the controller.

Step 1: Terminate the configuration wizard (this wizard it’s not specific for wireless controller)

Step 2: Press Return and continue with the manual configuration:

Step 3: Press Return to bring up the WLC> prompt and Type enable to enter privileged EXEC mode.

Step 4: Enter the config mode and set the hostname

Step 5: Configure login credentials

Step 6: Configure the underlay vlan for wireless management interface. For example, vlan 199, IP: 10.10.199.199 with gateway 10.10.199.1 in underlay EIGRP 2000 AS.

Step 7: Configure the SVI for wireless management interface

Step 8: Configure the interface TenGigabitEthernet0/0/0 as trunk:

Step 9: Configure a default route (or a more specific route) to reach the box:

Step 10: Disable the wireless network to configure the country code:

Step 11: Configure the AP country domain. This configuration is what will trigger the GUI to skip the DAY 0 flow as the C9800 needs a country code to be operational:

Step 12: Specify the interface to be the wireless management interface

Step 13: For the Controller to be discovered by the Cisco DNA Center or Prime Infrastructure, CLI,SSH and SNMP credentials should be configured on the devices along with Netconf.

Verify that we can ping the wireless management interface and then just https://<IP of the device wireless management interface>. Use the credentials you have entered earlier. Since the box has a country code configured, the GUI will skip DAY 0 page and you will get access to the main Dashboard for DAY 1 configuration.

Accessing C9800-L Web UI:

Access the C9800 Web UI using https://<C9800-L-WLC-IP>. The username and password configured during the Day-0 configuration is used to log on to WLC Web UI.

Figure 31 Cisco 9800-L WLC Web UI Dashboard View

Cisco WLC (C9800-L) High Availability (HA) configuration

The HA Pair always has one active controller and one standby controller. If the active controller becomes unavailable, the standby assumes the role of the active. The Active wireless controller creates and updates all the wireless information and constantly synchronizes that information with the standby controller. If the active wireless controller fails, the standby wireless controller assumes the role of the active wireless controller and continues to the keep the HA Pair operational. Access Points and clients continue to remain connected during an active-to-standby switchover. Follow the steps below for configuring C9800-L WLC with HA in a PoP.

Note: Redundancy SSO is enabled by default but you still need to configure the communication between the boxes.

Step1: Make sure both the C9800 WLCs are reachable to each other. Wireless management interface from both boxes must belong to the same VLAN and subnet. Connected to C9300 FiaB, one of our PoP sites in our case.

Step2: Connect both 9800 WLC to each other through its RP port. Connecting C9800-L Wireless Controllers using RJ-45 RP Port for SSO:

Figure 32 C9800-L WLC Redundancy Ports Connection

Step3: Provide the required redundancy configurations to both 9800 WLCs.

On WLC Web UI:

Navigate to Administration > Device > Redundancy. Enable “Redundancy Configuration”, check ‘ RP ’ for “ Redundancy Pairing Type ” and enter the desired IP address along with the Active and Standby Chassis Priorities. Both boxes should have its own IP address, and both should belong to the same subnet.

On the Active controller, the priority is set to a higher value than the standby controller. The wireless controller with the higher priority value is selected as the active during the active-standby election process. If we do not choose a specific box to be active, the boxes themselves will elect Active based on lowest MAC address. The Remote IP is the IP address of the standby controller’s redundancy port IP.

C9800-L WLC1 & C9800-L WLC2 :

Figure 33 Redundancy Pairing on both C9800-L WLCs

CLI:

Configuring Chassis HA interface

Configure the priority of the specified device

Configuring SD Access Wireless embedded WLC on C9300 Stack

Integrating the Wireless with the SD Access brings the best of both the architectures like Simplifying the Control & Management Plane, optimizing the data plane and Integrating Policy & Segmentation end to end. This section covers the installation of Cisco Catalyst Embedded 9800 Wireless Controller (eWLC) on Catalyst 9K series Switches and bring up with Cisco DNA Center.

In CCI, Cisco Catalyst Embedded 9800 Wireless Controller (eWLC) is installed in PoP sites which require SD Access Wireless (Wi-Fi) on C9300 FiaB switch stack. Follow the steps below to configured eWLC on C9300 switch stack.

We will categorize this section into two parts:

■ Installation of eWLC (c9800-sw) on C9300 FiaB PoP Site

■Enable Embedded SDA-Wireless through DNA Center Provisioning & AP Onboarding:

Installation of eWLC (c9800-sw) on C9300 FiaB PoP Site:

The steps to install eWLC on the C9300 FiaB switch are the following:

1. Check that license is dna-advantage

2. Boot the switch in install mode

3. Install the eWLC package

4. Enable netconf-yang

Step1: Check that license is dna-advantage

For eWLC package to install properly you need to have the dna-advantage active on the switch. You can check this through show version command.

Step2: Boot the switch in install mode

When we boot the switch passing directly the.bin image, this is called "bundle mode". Packaging only works, when the switch is booted in "install mode". To verify the mode, run "show version":

Make sure to boot from flash:packages.conf (there are no other boot files specified in our config)

a. Software install image to flash. The install add file bootflash:<image.bin> activate commit command moves the switch from bundle-mode to install-mode where image.bin is our base image.

b. Type yes to all the prompt. Once the install is completed the switch proceeds to reload.

After the controller reboot we can verify the current installation mode of the controller. Run the show version command in order to confirm.

Step3: Install the eWLC package.

After downloading the eWLC image to the switch you can install the wireless package using one single command line:

In our CCI, eWLC version installed is C9800-SW-iosxe-wlc.17.01.01s.SPA.bin

Where "flash:ewlc_pkg.bin" is our ewlc package. Alternatively, we can also install it from tftp directly.

Say "yes" to all questions. The switch should then reload and come up with ewlc package installed.

Verification:

After reloading we can confirm the install with the install summary command.

Step4: Enable netconf-yang

To enable netconf on the switch these three commands needs to be on the switch.

Verification:

We can check netconf is running by hitting the following command.

Enable Embedded SDA-Wireless through DNA Center Provisioning & AP Onboarding:

Prerequisites:

–Make sure we don’t have a WLC in the site where you plan to enable Embedded SDA-Wireless.

–It is important that we do the discovery after we have installed the -wlc pkg otherwise DNACenter will not display the “embedded wireless” option in fabric view.

–Configure our AP IP pool and attach it to INFRA_VN. In that DHCP scope, point DHCP option 43 DNA Center with this PnP will discover the AP

Reserving IP Pool for Access Points:

Navigate to Design > Network Settings > IP Address Pools, for MG Road PoP Site reserve IP Pool for SDA Wireless Access Points, as shown in Figure 21.4

Figure 34 AP IP Pool Reservation on Cisco DNA Center

Attaching AP IP Pool to INFRA_VN:

Navigate to Provision > Fabric and choose the Bangalore Fabric and navigate to MG Road PoP site. Under Host Onboarding, click on ‘INFRA_VN’ and attach the AP IP Pool and choose Pool Type as AP as shown in Figure 35.

Figure 35 Attaching AP Pool to INFRA_VN on DNA Center Host Onboarding

The workflow is as follows:

1. Discover device

2. Assign to site

3. Provision switch

4. Add device as FiaB

5. Enable Embedded wireless

6. Provision AP (Will be added to DNAC automatically by joining the Catalyst 9800 WLC)

7. Configure onboarding SSID (Refer “Implementing Wi-Fi Access Networks Section, page <x>”)

a. When configuring the discovery properties, click the add credentials and configure the netconf port to 830.

Figure 36 eWLC discovery on Cisco DNA Center

b. Assign the switch to MGRoad PoP Site.

c. Provision the device. Refer to the section “Device Provisioning, page <x>” for the device provisioning steps.

d. Add the device as Fabric in a Box (configure as Border, Control and Edge Node) and Enable Embedded Wireless.

Figure 37 Enabling Embedded Wireless on FiaB Switch

e. Connect the SDA Wireless APs connect to either Fabric Edge (FE) ports, or Extended Node (EN) ports. It is recommended to resync of the switch for it to add the AP. Go to Provision > Devices and resync the switch. The APs will be shown in the Devices tab for us to assign to our eWLC site and provision.

Note: Latency between AP and WLC needs to be < 20 ms.

Figure 38 AP PnP Onboarding

Note: To assign the APs to the Site, Floors should be created under the Building under Network Hierarchy.

Figure 39 AP Provisioning

Note: By default, the RF profile that you is marked as default under Network Settings > Wireless > Wireless Radio Frequency Profile is selected in the RF Profile drop-down list. You can change the default RF Profile value for an AP by selecting a value from the RF Profile drop-down list. The options are: High, Typical, and Low. The AP group is created based on the RF profile selected.

For verifying successful provisioning of SD Access Wireless on C9300 Stack in a PoP site, navigate to Provision -> Fabric -> Fabric Infrastructure view as shown in Figure 40.

Figure 40 SD Access Wireless AP view on Fabric Infrastructure

PoP Interconnection over Ethernet Network Backhaul

This section covers the example configuration of fabric interconnection for the SD-Access Transit-based network topology shown in Figure 3.

When configuring the interfaces on a fabric border to communicate with SD-Access transit, Cisco DNA will configure a VRF for each VN in the fabric site Border (i.e., FiaB and Transit Control Plane (T-CP) nodes). BGP peering is configured between the T-CP node and FiaB to enable overlay routing. In this implementation, two Cisco Catalyst 9500 switches as Ethernet network backhaul are provisioned as "SD-Access Transit" T-CP nodes, as shown in Figure 5. When connecting fabric sites to a SD-Access Transit network, each VN with subnets configured for data traffic is created as a VRF in FiaB and VN subnet(s) network prefixes for data traffic are registered with T-CP nodes in the SD-Access Transit site.

Example FiaB VRF Configuration:

Cisco DNA Center automatically configured the BGP peering between the FiaB Border and SD-Access Transit Control Plane nodes (i.e., Cisco Catalyst 9500 switches in this implementation) using lookback interfaces configured (routing enabled in the underlay network) on these devices. It leverages the existing underlay physical interfaces/network connectivity to backhaul network. Therefore, no separate physical interface selection is required.

Note: P subnet pools configured for extended nodes are added in the Global Routing Table (GRT) address family in the BGP routing configuration outside of the VRF address family.

Example FiaB Border BGP routing automatically configured by Cisco DNA Center

Example SD-Access Transit Control Plane Node BGP routing automatically configured by Cisco DNA Center

PoP Interconnection via IP Transit over MPLS Network Backhaul

When configuring the interfaces on a fabric border to communicate with an IP transit, the Cisco DNA Center will configure a VRF for each VN in the fabric site. This is known as VRF-lite because the VRFs are only locally significant. When connecting to an MPLS backhaul, the provider will use its own VRFs to keep different customers' traffic separated. Using a VRF-aware routing protocol within the service provider gives them the ability to keep the VRF configuration at the service provider edge instead of every single device in the core. These VRFs, however, are not related to the VRFs configured on the fabric border. To maintain the macro-segmentation provided by a VN's use of VRFs between fabric sites over an IP transit, the service provider must also provide a VRF for each VN configured at a fabric site.

Example Provider Edge VRF Configuration

When configuring the border services, Cisco DNA will automatically configure a VLAN interface on the border node. When configuring the provider edge node, there must be a matching VLAN configuration to enable connectivity. The border configuration is shown in Figure 41 :

Figure 41 Border Node External Interface

On the provider edge interface facing the edge fabric border, the services are separated using a different service instance. Each service instance is then associated with a bridge domain interface. For ease of administration, the VLAN encapsulation and bridge-domain should match. If the IP transit is owned by a different operator, they will have to ensure the encapsulation matches the VLAN configured on the fabric border.

The VRF is also added to the service provider's BGP configuration:

A service provider interface will be connected to the data center (fusion router, in this implementation) and this must have all the VRFs configured to maintain segmentation end to end. Because these devices are not part of the fabric, the configuration must be done manually.

Provider Edge VRF facing the fusion router:

Since the VLAN encapsulation is not automatically generated by Cisco DNA for this connection, there are no mandates on the VLAN other than what the service provider may require:

The VRF is then added to the service provider's BGP configuration:

A complementary configuration also exists on the customer edge device (fusion router, in this implementation):

Because the VRF separation is maintained within the IP transit network, the VN will maintain its macro-segmentation from one fabric site to another.

Configuring a Fusion Router in IP-Based Transit Network

For the IP Transit scenario, a Cisco ASR 1000 Series Router was used as the fusion router, but the only requirement is that the router must support route leaking between VRFs. In this implementation, the shared services were part of the global routing table, but they could also be part of a separate shared services VRF.

1. The fusion router configuration is outside the scope of Cisco DNA and must therefore be done manually. The first step is to configure a VRF for every VN configured in Cisco DNA.

2. The fusion router must then have interfaces configured in the VRF, which can connect to a fabric border node or other non-fabric router. In the case of a fabric border node, Cisco DNA will configure the interface and BGP configuration as part of the border configuration. The fusion router side must be done manually. The following is an example of the automatically generated border node interface configuration:

3. The following is the complementary interface configuration manually entered on the fusion router:

4. Cisco DNA also automatically generates the BGP config for the VRF on the border node:

5. The fusion router must be manually configured to successfully neighbor with the border node:

6. Because the VRF creates a routing table separate from the GRT, routes must be shared between them for the VRF to have access to the shared services, and vice versa. One way to achieve this is with prefix lists and route maps.

Example from fusion router:

7. The route-map must then be imported into the target VRF:

8. Verifying the routes on a fabric site:

9. Additionally, routes from the VRF must be exported to the GRT so the shared services can reach interfaces in the VRF:

10. The route map must then be exported from the target VRF:

11. Verifying the routes on the fusion router:

Configuring a Fusion Router in SD-Access Transit Network

Implementation of fusion routers in SD-Access Transit-based network topology (Figure 3) is similar to IP-based Transit since both network topologies connect to fusion routers via the IP Transit network. In this implementation, an IP Transit network interconnects a HQ/DC site with an external network outside of fabric overlay in order to provide access to shared services. Therefore, steps to configure the fusion router is similar to what was described in the previous section.

This section discusses an example implementation of redundant fusion routers in HQ/DC site, as shown in Figure 5, for a CCI implementation (with an SD-Access Transit-based network topology). A couple of Cisco Cloud Services Routers 1000V are used as redundant fusion routers in this implementation.

1. Configure VRF for every VN configured in Cisco DNA Center on the fusion router. Example VRF configuration:

Figure 42 shows an example VLAN automatically created by the Cisco DNA Center Border while FiaB role provisioning:

Figure 42 Example Border Configuration Connecting to IP Transit

2. In Figure 42, GigabitEthernet2/0/6 is a physical link connecting to a fusion router (CSR1000V-1 used as fusion router) and GigabitEthernet1/0/6 is a physical link to redundant (secondary) fusion router (CSR1000V-2). Example VLAN configurations automatically configured by the Cisco DNA Center on HQ/DC Site FiaB border:

3. Configure complementary interface configurations matching this VLAN interfaces on the fusion router:

4. Cisco DNA Center automatically generates the BGP config for the VRF (SnS_VN) and INFRA_VN on the border node:

5. The fusion router must be manually configured to successfully neighbor with the border node:

6. Configure prefix-lists and to match shared services network routes:

7. Configure route-map to import shared services network into the target VRF:

8. The route-map must then be imported into the target VRF. Example configuration for a VN (SnS_VN):

9. Verifying the routes on a fabric site (for example, on the HQ/DC site):

10. Additionally, routes from the VRF must be exported to the GRT so that the shared services can reach interfaces in the VRF:

11. The route map must then be exported from the target VRF:

12. Verify the routes on the fusion router:

13. This completes the fusion routing configuration on CSR1000v-1. Repeat the same steps for the secondary fusion router (CSR1000v-2) in the network.

Note: Shared services network prefixes are advertised to other fabric sites (PoP) via Control Plane nodes (SD-Access Transit) BGP neighborship between all PoP sites border and Transit Site control plane nodes.

Configuring Internet Connectivity

Regardless of how the rest of the network itself is designed or deployed outside of the fabric, a few things are going to be in common in deployments due to the configuration provisioned by the Cisco DNA Center. Providing Internet access to PoP (fabric) site devices is one of such common use cases to be provisioned in the deployments. In the CCI network, Internet access to PoP sites are configured on the fusion router that connects to DMZ network as Internet Edge.

Refer to the following URL for mode details on different types for fabric border.

■ https://community.cisco.com/t5/networking-documents/guide-to-choosing-sd-access-sda-border-roles-in-cisco-dnac-1-3/ta-p/3889472

In the SD-Access Transit based network topology as shown in Figure 3, the fusion routers (CSR1000V) are acting as Internet edges to HQ/DC site FiaB. Alternatively, on IP based Transit network topology, as shown in Figure 4, a couple of Catalyst 9500 switches as fusion routers are the Internet Edges.

This section covers an example implementation of configuring Internet access to PoP sites via HQ/DC site which is connected to Internet edge as shown in Figure 3. The FiaB border in HQ/DC site will have the SD-Access network prefixes in its VRF routing tables. As a prerequisite for being "connected-to-Internet," it will also have a default route to its next hop (fusion router as Internet edge) in its Global Routing Table.

Note: Make sure that in order to provide Internet access to other SD-Access Transit-connected PoP (Fabric) sites, the Fabric Border which connects to your network Internet edge is configured with the "Connected to the Internet" checkbox enabled as shown in Figure 43.

In this implementation, the HQ/DC site border (FiaB) connects to the Internet edge and provides Internet access to other PoP sites via SD-Access network. Therefore, the border is configured with the "Connected to the Internet" checkbox enabled as shown in Figure 43:

Figure 43 Example Border Configuration for Internet Connectivity

The fusion router as Internet edge has the default route in its GRT to the next-hop of the Internet (i.e., FirePower2140 in DMZ network in this implementation).

Default static route in underlay network on fusion router:

This default route must be advertised from the GRT to the VRFs. This allows packets to egress the fabric domain towards the Internet. In addition, the SD-Access prefixes in the VRF tables on the border nodes must be advertised to the external domain (outside of the fabric domain) to draw (attract) packets back in.

These SD-Access network prefixes are already configured in fusion routers; however, they must be added in the Firepower configuration. For detailed Firepower implementation in DMZ network in this implementation, refer to the Configure Static and Dynamic Routing. It includes, the configuration required to enable Internet access for endpoints/devices in the PoP sites.

VRF and BGP configurations have already been provisioned by Cisco DNA Center, along with the Layer 3 handoff. All fabric domain prefixes will be learned in the GRT of the Internet edge routers. Configure the default route on the fusion router (Internet edge) to advertise the default route. The default route is injected into the BGP RIB of VRFs needing Internet access, resulting in a general advertisement to all BGP neighbors via SD-Access Transit for the VRF.

Advertising a default route in BGP has different methods, each with its own caveats. In this implementation, the "network 0.0.0.0" method is used as an example.

–This will inject the default route into BGP if there is a default route present in the GRT.

–The route is then advertised to all configured neighbors.

Example BGP configuration on fusion router (Internet edge)

1. Verify the default route is injected on the border (FiaB) VRF:

2. Once the Firepower in DMZ is configured for Internet access, verify the Internet access from border (FiaB) via VRF as shown belowL

This completes the Internet access configuration for the PoP sites in overlay VNs. For more details on Internet access for fabric sites, refer to the section "Configuring Internet Connectivity" in the Software-Defined Access for Distributed Campus Deployment Guide.

Implementation of Ethernet Access Network

The Ethernet network access in a PoP site is provided by connecting Cisco Industrial Ethernet (IE) switches in a ring topology. This section covers the implementation of Ethernet access ring(s) in a PoP site to provide network access to wired endpoints or gateways (examples: IP Camera, Cohda RSU, ICS300, and CGR) connected to the CCI network. Follow the steps covered in this section to complete the implementation of Ethernet access rings in PoP sites.

Extended Nodes & Policy Extended Nodes Onboarding

Extended nodes (EN) and Policy Extended Nodes (PEN) in SD-Access extend the Fabric Edge for IoT devices and provide SD-Access to IE switches. The IE switches (IE4000, IE5000 & IE3300 Series) in the ring connected directly to the Fabric Edge/FiaB are referred as Extended Nodes (EN) and the IE switches which are indirectly connected to Fabric Edge/FiaB via daisy-chained ring topology are referred as Daisy-Chained Extended Nodes (DC-EN).

In an Extended Nodes access ring (a ring with a mixture of ENs and DC-ENs), Extended Nodes are provisioned by the Cisco DNA Center, which onboards the extended nodes in fabric overlay network leveraging Plug and Play (PnP) provisioning. An extended node is configured by an automated workflow. After configuration, the extended node device is displayed on the fabric topology view.

The IE3400 series switches in the Ethernet access ring connected directly to the Fabric Edge/FiaB are referred as Policy Extended Nodes (PEN). The IE3400 switches which are indirectly connected to Fabric Edge/FiaB via daisy-chained ring topology are referred as Daisy-Chained Policy Extended Nodes (DC-PEN).

Note: DNA Advantage license is must on IE3400 switches for onboarding it as Policy Extended Node(PEN).

This section discusses the steps to onboard an EN or PEN in an Ethernet access ring.

Prerequisites for extended node onboarding:

■Configure a network range for the extended node. Refer to Step Configure IP Address Pools for steps to configure the IP Address Pool. This comprises adding an IP Pool and reserving the IP Pool at the site level. Ensure that the CLI and SNMP credentials are configured.

■Assign the extended IP address pool to INFRA_VN under the Fabric > Host Onboarding tab. Select Extended Node as the pool type. Cisco DNA Center configures the extended IP address pool and VLAN on the supported fabric edge device. This enables the onboarding of extended nodes.

■Configure the DHCP server with the extended IP address pool and Option-43. Refer to section "DHCP Control-ler Discovery" in the Cisco Digital Network Architecture Center User Guide, Release 1.3.3.0.

■Ensure that FiaB is provisioned and that the extended node IP pool default gateway configured on FiaB (Edge) is reachable from the Cisco DNA Center.

Complete the following steps to onboard EN or PEN:

1. Connect the extended node device (Cisco Industrial Ethernet 4000 (IE-4000)/Cisco Industrial Ethernet 5000 (IE-5000)) to the fabric edge device (FiaB in this case). You can have multiple links from the extended node device to the fabric edge. In this deployment, two links from the IE-4000/IE-5000 switch to each member of Cisco Catalyst 9300 stack are used.

2. Power-up the extended node device if it has no previous configuration. If the extended node switch has any previous configurations, execute the following steps on the extended node switch before starting the onboarding process:

The Cisco DNA Center adds the EN or PEN device to the Inventory and assigns the same Site as the fabric edge. The EN or PEN is then added to the fabric. Now the EN or PEN is onboarded and ready to be managed.

Once the configuration is complete, the EN or PEN appears in the Fabric topology with a tag (X) indicating that it is an extended node, as shown in Figure 44.

Figure 44 Cisco DNA Center Fabric Infrastructure View for the Extended Node

Repeat the above steps to onboard a second EN or PEN in the access ring.

Note: If any errors exist in the workflow while configuring an EN or PEN, an error notification is displayed as a banner on the topology window. Click See more details to check the errors.

Provisioning Device using Cisco DNA Center Templates

Cisco DNA Center configuration templates feature is used to automate the configuration of DC-EN nodes in the Cisco DNA Center inventory. Cisco DNA Center is moving customers away from manual approach to configurations and helps achieve the automating device configurations using Day-N Configuration Templates.

A template can be modular and configurable enough to apply to a variety of devices. Refer to the following URL for the step to create and automate device configurations using Templates on Cisco DNA Center:

■ https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center/1-3-3-0/user_guide/b_cisco_dna_center_ug_1_3_3_0/b_cisco_dna_center_ug_1_3_2_0_chapter_01000.html

Configuring Extended Node Access Ring

The recommended Ethernet access network topology for CCI is a REP ring formed by IE switches connected back to back that terminates both ends of the ring on a stack of Fabric Edge (FiaB) devices. Refer to the “CCI Ethernet Network Access Solution” section on Cisco Connected Communities Infrastructure (CCI) Design Guide at the following URL:

■ https://www.cisco.com/c/en/us/td/docs/solutions/Verticals/CCI/CCI/DG/cci-dg.html

To configure an Extended Node access ring (i.e., a ring with a mixture of ENs and DC-ENs) with the ring of up to 30 switches in a PoP access ring topology, it is recommended to use Cisco DNA Center templates feature for automating the configuration and provisioning of DC-ENs in the ring. The REP topology is also configured with the help Cisco DNA Center Day N templates.

This section covers the formation the ethernet access ring using the automation scripts and templates leveraging the DNA Center Day-N template provisioning feature.

Prerequisites:

Before starting to form the DC-EN REP ring topology using the automation scripts and templates, make sure the following prerequisites are met:

1. Fabric overlay configured for the specific fabric domain and Fabric Edge (FiaB) switches are already provisioned.

2. Nodes are connected together in a ring and ready to be connected to provisioned

3. Extended Nodes (ENs)

4. Node-1 and Node-N are directly connected to Fabric Edge

5. (FiaB) and onboarded using PnP and ENs.

6. Get required

7. Cisco DNA Center templates & network profile configuration by referring to the “Configuring Daisy-Chained Ring Templates in Appendix section”, of this document.

8. All Day-N templates are created and ensure all the IE Switches PIDs in the ring are selected. Create a Network Profile with switch type as ‘Switches & Hubs’, it will simplify and ensure template is applicable for all switches.

Daisy-Chaining & REP Ring Automation Workflow

The following steps summarizes the DC-ENs and REP ring automation workflow using templates.

1. Tag FiaB switch and Extended Nodes with same device tag (in our example RA) used while creating Day N templates and network profile and push the DHCP pool template named DHCP_POOL to one of the directly connected extended nodes that are already provisioned (say Node 1 or Node N).

2. Bring down the port channel interface on the Fabric-in-a-box (FiaB) switch connecting to the Node N using the template INTERFACE_TOGGLE. This step is to prevent forming any switching loops.

3. Power up the DC-EN devices (other than ENs). If devices have any previous configurations, execute the factory reset commands and then reload. PnP flow triggers on the DC-EN and DC-ENs register themselves with Cisco DNA Center as “unclaimed” device.

4. On the DNA Center dashboard, Navigate to Provision > Devices > Plug and Play, and claim all the above nodes with appropriate hostname and assign the site parameter. While claiming make sure to Clear the image Configuration.

5. Once devices are claimed, Navigate to Provision > Devices > Inventory and make sure all the devices are now available under the particular site.

6. Tag all the newly provisioned ring devices with same device tag (in our example RA) used while creating Day N templates and network profile.

7. Push the Extended_Node template to all devices in the ring (except for directly connected nodes Node 1, Node N and FiaB switch). This template configures device for extended node functionality.

8. Push the PORT_CHANNEL template on directly connected ENs (Node 1 and Node N) for downstream interface connected to the ring.

9. Push REP_Template to all the nodes which are part of REP ring except the REP edge device. This template will configure REP segment on all port-channels associated within the ring.

10. Push REP_Edge template to configure REP edge port on specific interface.

Figure 45 below illustrates the Cisco DNA Center templates used in a sequence to form an Extended Node access ring.

Figure 45 REP Ring Automation Template Workflow on Extended Node Ring

Follow the step-by-step instructions for configuring daisy-chained REP ring using Cisco DNA Center templates.

Step1:

a. Tag the FiaB and Extended Nodes with RA, as shown in Figure 46.

Figure 46 Inventory devices with the Tag

b. Push the DHCP pool template named DHCP_POOL to one of the directly extended nodes by following the steps to apply the templates for device provisioning.

Selective Templates Provisioning

• On the DNA Center dashboard, Navigate to Provision > Devices > Inventory and select the first Extended Node device are under the target site. Now Navigate to Actions > Provision > Provision Device.
• Now under the Advanced Configuration tab, all Day-N templates attached to the Network Profile assigned to this site are available.
• The flag ‘apply_template’ is used as variable in all templates. When set to 1, template gets pushed to selected devices. This allows selective push of templates.

For example, pushing the selected template, in this case DHCP_POOl, set the ‘apply_template’ to 1 and provide the necessary inputs as shown in Figure 25.3.

Note: For rest of the templates in addition to setting the ‘apply_template’ variable to 0, assign all the variables to 0 as well.

Select ‘Push these templates even if its deployed before’ checkbox while pushing template so template pushed before can be pushed again.

Figure 47 Selective template push example

Step 2: Refer “Selective Template Provisioning, page <x>” section to push the ‘INTERFACE_TOGGLE’ template on FiaB switch which brings down the port channel on the Fabric Edge switch connecting to the Node N.

Step 3: Power up the devices connected in the ring, if devices are already having old configuration run CLIs mentioned in Step2 of “Prerequisites for EN or PEN onboarding, page 79” to delete the existing configuration and reset the device.

Step 4: On the DNA Center dashboard, Navigate to Provision > Devices > Plug and Play, and claim all the above nodes with appropriate hostname and assign the site parameter. While claiming make sure to clear the image Configuration.

Refer to the ‘Day-zero provisioning of switch onboarded with PnP’ section in the following URL to claim the device from PnP:

■ https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Campus/dnac-network-device-onboarding-deployment-guide-2019nov.pdf

Note: At max only 25 nodes can be claimed at a time while provisioning nodes via PnP, it’s recommended to claim the nodes batch wise.

Step 5: Navigate to Provision > Devices > Inventory and make sure all the devices are now available under the particular site.

Step 6: Tag all the newly provisioned Ring devices with same device tag (in our example RA) used while creating Day N templates and network profile.

In Figure 48, you can see all the newly PnP provisioned nodes are available under “Elex City” Site and are tagged with the flag ‘RA’.

Figure 48 PnP provisioned devices with the tag

Step 7: Refer to “Selective Templates Provisioning” section to push the Extended_Node template to all devices in the ring (except for directly connected nodes Node 1, Node N and FiaB switch). This template configures device for extended node functionality.

Step 8: Refer to “Selective Templates Provisioning” section to push the Port_Channel on directly connected extended nodes (Node 1 and Node N) for downstream interface connected to the ring.

Step 9: Refer “Selective Templates Provisioning” section to push REP_Template to all the nodes which are part of REP ring except the REP edge device. This template will configure rep segment on all port-channel associated with the ring.

Step 10: Refer “Selective Templates Provisioning” section to Push REP_Edge template to configure REP edge port on specific interface in CCI its FiaB switch.

Verification :

On DNA Center dashboard, navigate to Provision > Devices >Inventory, select a device and at Run command tab, check ‘show rep topology’ to confirm REP ring is formed.

Note : Extended Nodes (ENs) should be either IE4000 or IE5000 platforms. If IE3300 is used as an Extended Node (EN), REP ring should be formed using manual provisioning steps without the port-channel between the daisy chained nodes. Refer to the section “Configuring Policy Extended Nodes Ring” for the steps to manually provision daisy-chained EN ring.

1. To configure newly inserted node in the ring, need to unconfigure existing REP ring. Use REP_TEMPLATE with flag rep_config=0 to trigger remove rep segment config on all nodes.

2. On REP Edge Nodes, remove the REP edge configuration using the REP_EDGE template with flag config=0

3. New Node automatically acquires local DHCP IP and reaches the Fabric and subsequently registers with DNAC as unclaimed device in Device > Plug and Play

4. Claim the device and assign to the correct site and Provision the device with extended node configuration using the Extended_Node template

5. Push REP_TEMPLATE to all the nodes which are part of REP ring except the REP edge interfaces. This template will configure rep segment on all port-channel associated with the ring

6. Configure REP edge port on specific interface using EDGE_PORT template

Configuring Policy Extended Nodes Ring

An access ring of all IE3400 switches is referred as a Policy Extended Node ring aka PEN ring. The IE3400 switches connected directly to the Fabric Edge/FiaB are referred as Policy Extended Nodes (PEN) and the IE3400 switches in the ring which are indirectly connected to Fabric Edge/FiaB via daisy-chained ring topology are referred as Daisy-Chained Policy Extended Nodes (DC-PEN).

Steps to onboard a PEN in CCI PoP using Cisco DNA Center is similar to onboarding an EN. Refer to “Extended Nodes & Policy Extended Nodes Onboarding for onboarding PENs in the PEN ring.

Unlike DC-ENs, the DC-PENs in the PEN ring are configured manually. This section covers the steps to manually configure Daisy-Chained Policy Extended Nodes (DC-PENs) in the ring using Cisco DNA Center. Once the DC-PENs are successfully onboarded in Cisco DNA Center, you can extend the fabric overlay network access to all the nodes in the ring.

Prerequisites:

1. Make sure all the DC-PENs are physically connected in a ring topology using fiber cable.

2. If the devices are already having old configuration, complete the Step 2 in “Prerequisites for EN or PEN onboarding” page 79, to delete the existing configuration and reset the device.

3. Make sure the DC-PENs are booted with active ‘dna-advantage’ license.

4. Capture the automatically configured extended node IP pool VLAN ID (example: VLAN 1021) in the PoP site FiaB switch.

Complete the below steps on each DC-PEN node to discover in DNA Center and form the REP ring:

1. Configure the Extended Node vlan on all the DC-PEN nodes (example: vlan 1021)

2. Configure the physical interfaces connected to uplink and downlink IE switches on each of the DC-PENS to be configured in the ring as trunk port and configure CTS manual and trusted sgt for enabling SGT inline tagging.

Example configuration on DC-PEN interface connected to PEN:

3. Create an SVI on a DC-PEN switch for the extended node vlan (example: vlan 1021) and assign IP for the SVI in the same extended node subnet, as shown in the example configuration below:

Note: Alternatively, IP address for the SVI can be assigned from DHCP server as follows:

4. Configure the default gateway on the DC-PEN in case when IP address was configured manually in the above step. Otherwise skip this step.Extended node IP pool SVI IP address is configured as default gateway, as shown in the example below:

Verify the reachability:

5. If the reachability is successful, refer to the section “Discovering Devices in the Network” for discovering the DC-PENs nodes as non-fabric devices in the Cisco DNA Center.

6. Once devices are discovered and available in the Cisco DNA Center Inventory with the Managed status, provision each device by adding its respective PoP site. Figure 49 shows a PEN ring topology view in a CCI PoP site (fabric site view).

Figure 49 PEN Access ring on Cisco DNA Center

Configure REP in PEN Ring

The Resilient Ethernet Protocol (REP) is a Cisco proprietary protocol that provides an alternative to the Spanning Tree Protocol (STP). REP provides a way to control network loops, handle link failures, and improve convergence time. It controls a group of ports connected in a segment, ensures that the segment does not create any bridging loops, and responds to link failures within the segment.

For step-by-step instructions on configuring REP Protocol on IE switches, refer to the chapter "Configuring Resilient Ethernet Protocol" in the Cisco Catalyst IE3x00 Rugged Series Switches Configuration Guide at the following URL:

■ https://www.cisco.com/c/en/us/td/docs/switches/lan/cisco_ie3X00/software/17_1/b_17_1x_ie3x00_ess3300_scg/b_17_1x_ie3x00_ess3300_scg_chapter_0110.html

A REP segment is a chain of ports connected to each other and configured with a segment ID. Each segment consists of standard (non-edge) segment ports and two user-configured edge ports. A switch can have no more than two ports that belong to the same segment, and each segment port can have only one external neighbor. An example Closed REP ring topology configuration validated in this implementation is covered in this section.

a. Configure REP admin vlan on all the ring devices PENs, DC-PENs and FiaB switch. For example,

Note: Make sure admin vlan shouldn’t be any fabric vlan including the Extended_Node vlan. Create a separate vlan which is not part of any Virtual Network on all the nodes. In the above example, vlan 40 is configured as the admin vlan.

b. Configure REP segment on all the REP member ports

In this example, interface Gi1/1 of DC-PEN is connected to PEN

c. Configure REP segment on the REP edge ports

In this example, FiaB is acting as a REP Edge and Port-Channel 5 is connected to one of the PENs

Verify the REP segment with ‘show rep topology’ command on any of the REP nodes

Configure AAA and Cisco TrustSec (CTS) feature on DC-PEN:

Refer to the section “Policy Extended Node Access Ring Configuration” for detailed commands and provisioning of AAA and CTS features on all DC-PENs in the PEN ring.

This completes the REP ring topology configuration for Ethernet access. Repeat the steps above to configure other PEN ring(s) in a PoP site.

Network Assurance

Using the Assurance features of Cisco DNA Center provides a detailed view of the network health. The overall network health can be viewed as well as an individual device health in Device 360. Assurance focuses on network visibility aspect of the network by identifying the issues, trends in the network. Assurance also focuses on the operational efficiencies by focusing on faster troubleshooting. Assurance provides the following benefits:

–Provides actionable insights into network, client, and application related issues. These issues consist of basic and advanced correlation of multiple pieces of information, thus eliminating white noise and false positives.

–Provides both system-guided as well as self-guided troubleshooting. For a large number of issues, Assurance provides a system-guided approach, where multiple Key Performance Indicators (KPIs) are correlated, and the results from tests and sensors are used to determine the root cause of a problem, after which possible actions are provided to resolve the problem. The focus is on highlighting the issue rather than monitoring data. Quite frequently, Assurance performs the work of a Level 3 support engineer.

–Provides in-depth health scores for a network and its devices, clients, applications, and services. Client experience is assured both for access (onboarding) and connectivity.

In CCI network where there will be IE nodes in a fabric site, it will be important to have a single view of the network health. Some examples of the network health are shown below:

Figure 50 Device360 Network Health

Figure 51 Industrial Ethernet Switch Device Health

For more detailed information about using Cisco DNA Assurance, refer to the Cisco DNA Assurance User Guide, Release 1.3.3.0 at the following URL:

■ https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center/1-3-3-0/user_guide/b_cisco_dna_center_ug_1_3_3_0/b_cisco_dna_center_ug_1_3_2_0_chapter_01101.html

Implementing Cisco Resilient Mesh Access Network

Refer to Implementation of the Field Area Network for more details about CR-Mesh access network implementation.

Implementing DSRC Access Network

Dedicated Short-Range Communications (DSRC) carries information between Vehicles to Infrastructure (V2I) and Vehicles to Vehicles (V2V). Cisco Kinetic Edge and Fog Processing Module (EFM) is used for making decisions and to forward traffic more quickly at the edge or higher layers. In CCI, DSRC traffic received from the On-Board Unit/Roadside Unit (OBU/RSU) is forwarded to the EFM running in the data center via the EFM running in the IC3000 Industrial Compute Gateway. The DSRC data can be customized through the EFM in the data center.

Data ports for the Cisco IC3000 Industrial Compute Gateway are enabled through FND and EFM installed through the Fog Director. Once EFM on the Cisco IC3000 Industrial Compute Gateway successfully connects to the EFM in the data center, the DSRC DSlink (a wrapper/container with specific functionality exposed to EFM) can be installed and started on IC3000 Industrial Compute Gateway for sending/receiving messages to/from radio devices (RSU/OBU).

Notes:

■Cohda OBU and RSU devices were used in this implementation for transporting DSRC messages. Please refer to Cohda documentation for OBU and RSU configuration.

■EFM has been used in this implementation to validate the access network, but EFM by itself hasn't been validated.

■Refer to the EFM Configuration Guide at the following URL:

– https://www.cisco.com/c/en/us/support/cloud-systems-management/edge-fog-fabric/products-user-guide-list.html

Implementing LoRaWAN Access Network

LoRaWAN is a media access control (MAC) protocol for wide area networks defined by the LoRa Alliance (https://www.lora-alliance.org) on top of the LoRa radio physical layer. The LoRa Alliance is an open and nonprofit standards association that includes hundreds of registered members from service providers, solution providers, service integrators, application developers, and sensor and chipset manufacturers. It is designed to allow low-powered devices to communicate with Internet-connected applications over long range wireless connections.

Cisco Wireless Gateway for LoRaWAN is a module from Cisco Internet of Things (IoT) extension module series (IXM Gateway). It can be connected to the Cisco 809 and 829 Industrial Integrated Services Routers (IR800 series) or be deployed as standalone for low-power wide-area (LPWA) access. It is a carrier-grade gateway for indoor and outdoor deployment, including harsh environments.

■ https://www.cisco.com/c/en/us/solutions/internet-of-things/lorawan-solution.html

There are two LoRaWAN gateway deploy modes as below:

■Virtual interface mode – IR800 series including the LoRaWAN module as a virtual interface

■Standalone mode – The LoRaWAN module working alone as an Ethernet backhaul gateway or attached to a cellular router through Ethernet.

FND can mange IXM Gateway in both virtual and standalone mode, the deployment options of IXM are as shown in the table below:

Table 11 LoRaWAN Deployment Options