Pages

Showing posts with label Cisco. Show all posts
Showing posts with label Cisco. Show all posts

Thursday 6 July 2023

Understanding and Configuration of VRF-Lite in Cisco IOS

Introduction

Virtual Routing and Forwarding Instances (VRFs) are used to segregate traffic at Layer 3. They are similar in concept to VLANs that are used to segregate traffic at Layer 2. VRFs create virtual routers with separate instances of the routing table (RIB) and forwarding table (FIB) independent from the global routing table. VRFs segment traffic in the data-plane and the control-plane based on the logical or physical interface that you assign to the VRF. The concept of VRFs is similar to that of virtual machines (VMs). It is important to note that the concept of VRF is locally significant to the device on which it is configured. VRFs improve network functionality because network paths can be segmented without requiring multiple physical routers. VRF-Lite is a feature of VRF that provides VRF without MPLS configuration.

If VRFs are configured on more than one router to ensure end to end connectivity, the links interconnecting the routers will need to be configured as a trunk (for layer 2 switches) or sub-interfaces (for routers) if a single link is to be shared with traffic from other separate VRFs or the default routing table. VRFs leverage trunk links with 802.1Q encapsulation to maintain connectivity with same VRFs on remote devices.

By default, all routers have single running VRF instance referred to as the global VRF instance. All interfaces, the global routing table, the forwarding table are assigned to this global VRF instance. One or more VRF instances can be configured on a single router that are separate from the global routing VRF instance. The configured VRF instances can then be identified by their configured VRF names. Interfaces or sub-interfaces are then assigned to the configured VRFs. IP addresses configured on these VRF instances can overlap if the interfaces are assigned to different VRFs. These IP addreses are not included in the global routing table. If routing protocols are configured for each VRF instance, then separate SFP (OSPF) or DUAL (EIGRP) calculation instances take place for each VRF instance.

VRFs generically segment traffic at Layer 3. However, it is possible to leak traffic between VRFs if such connectivity is required. This can be done through:

  • Through importing or exporting routes between the multiple routing tables.
  • Static routing.
  • Physical cable to leak traffic.

Minimum configuration of VRF is called VRF Lite; VRFs without any MPLS configuration. The main reason for VRF Lite is separation of the control-plane.

The number of VRFs on a single device should be limited to a small number as each VRF instance consumes local resources.

Business Use Cases of VRF

  • ISPs use VRFs to keep IP routing tables of customers logically separate to create separate VPNs for each customer when layer 3 end-to-end connectivity is provided; thus the technology is also referred to as VPN routing and forwarding.
  • Network segmentation for different applications, departments
  • Security concerns
  • Corporate mergers
  • Data Centre access

VRF-Aware Routing

To support dynamic routing in VRFs, the routing protocols in use should be VRF aware. Static routes support VRF. VRF-aware dynamic routing protocols include: RIP, EIGRP, OSPF, IS-IS, MP-BGP. Policy routing is also VRF-aware.

Configuration

Step 1: Specify Locally Significant VRF Name

VRFs can be configured in one of two ways:

  • ip vrf <vrf-name>: This global configuration command supports only IPv4 VRFs.

    R2(config)#ip vrf RESEARCH
    R2(config)#ip vrf FINANCE
    R2(config-vrf)#description Finance VRF

  • vrf definition <name>: This global configuration command supports IPv4 and IPv6 VRFs. It is generally recommended to configure VRFs using this format. The address family should be additionally configured using the VRF mode command address-family ipv4. The address family needs to be explicitly configured after defining the VRF name.

    R3(config)#vrf definition RESEARCH
    R3(config-vrf)#description Research and Development Department VRF
    R3(config-vrf)#address-family ipv4
    R3(config-vrf-af)#exit
    R3(config-vrf)#exit
    R3(config)#vrf definition FINANCE
    R3(config-vrf)#description Finance Department VRF
    R3(config-vrf)#address-family ipv4

Cisco IOS has additional commands that enable VRFs created using the command ip vrf <vrf-name> to support IPv6. To enable support for IPv6 VRFs, in global configuration mode issue the command vrf upgrade-cli multi-af-mode common-policies vrf <vrf-name> . By default all VRFs will be configured to support IPv4 and IPv6. If the optional VRF name is configured, only the specified VRF will support IPv4 and IPv6. The keyword common-policies copies the pre-configured parameters such as route-target, route distinguisher to be applied to IPv6 as previously configured under IPv4. Any IPv6 addresses configured on the interfaces assigned to any VRF will be removed. When you view the running configuration file, the syntax will be changed to vrf definition <vrf-name> which is the new format.

The VRF description can be added to provide helpful information on the purpose of the VRF. It can be added using the VRF mode command description <description>.

CAUTION:

  • If deleting a VRF using the command no ip vrf <vrf-name> the IPv4 addresses configured on the interfaces assigned to that VRF will be removed.
  • VRF names are case sensitive. It is recommended to use all upper case letters for VRF names.

In VRF-lite, there is no need to specify the import and export route target (RT). and route distinguisher (RD).

Step 2: Apply VRF to the Interface

Interfaces, physical or logical, can belong to only one VRF at a time. Interfaces assigned to the VRF belong to that VRF's routing table instance. Interfaces not in a VRF are in the global or default VRF. Interfaces are assigned to VRFs depending on the way the VRF was created using one of the following interface mode commands:

  • ip vrf forwarding <vrf-name>: This command is used when the VRF was created using the global configuration command ip vrf <name>.

    R1(config)#interface gigabitethernet1/0
    R1(config-if)#ip vrf forwarding FINANCE

  • vrf forwarding <vrf-name>: This command is used when the VRF was created using the global configuration command vrf definition <vrf-name>.

    R3(config)#interface gigabitethernet3/0
    R3(config-if)#vrf forwarding FINANCE

Caution: If an IP address was configured on the interface, it gets removed. Always view the interface configuration for IP address before assigning any interface to a VRF.

Step 3: Routing with the VRF

VRF-aware Static Route

To configure a static route for a VRF, run the global configuration command: ip route vrf <vrf-name> <network> <mask> <next-hop>

R1(config)#ip route vrf FINANCE 172.17.1.0 255.255.255.0 10.20.13.2

VRF-Aware Dynamic Routing

The following routing protocols are VRF-aware: EIGRP, IS-IS, OSPF, BGP, RIP.

EIGRP

EIGRP is VRF-aware in both classic and named mode. The configuration of VRF routing for classic and named mode is similar.

EIGRP Named Mode

router eigrp EIGRP_NAMED
address-family ipv4 vrf <vrf-name> autonomous-system <id>

R2(config)#router eigrp EIGRP_NAMED
R2(config-router)#address-family ipv4 unicast vrf FINANCE autonomous-system 1

EIGRP Classic Mode

R2(config)#router eigrp 1 vrf FINANCE

OSPF

router ospf <process-id> vrf <vrf-name>

R2(config)#router ospf 1 vrf RESEARCH
R2(config-router)#capability vrf-lite

The command R2(config-router)#capability vrf-lite causes OSPF to not perform PE specific checks.

BGP

Service providers use BGP VRFs extensively to segregate customer traffic. To utilize VRFs in BGP, the route distinguisher needs to be configured to uniquely identify traffic. Configuration of the route target is done using the VRF configuration mode command rd <ASN:nn> or rd <ip-address:nn> The RD is used to keep the routes from various clients unique regardless of whether the IP addresses used are overlapping; how we distinguish one route in one VRF from a route in another VRF particularly when the IP addresses are overlapping in prefix and prefix-length. In some versions of IOS, the RD needs to be configured otherwise the following error message is displayed when configuring VRF support in BGP.

R2(config)#router bgp 65000
R2(config-router)#bgp router-id 2.2.2.2
R2(config-router)#address-family ipv4 unicast vrf FINANCE
% VRF FINANCE does not have an RD configured.

In the newer versions, you can skip over this step.

If two VRF instances X and Y have overlapping IP addresses, such as 10.0.0.0/24. and VRF X has a configured RD of 1:1 and Y 2:2, the addresses will be differentiated such that X's addresses will be 1:1:10.0.0.0/24 and Y 2:2:10.0.0./24. In the case of MP-BGP, these count as two separate routes.

R2(config)#ip vrf FINANCE
R2(config-vrf)#rd 65000:100
R2(config)#router bgp 65000
R2(config-router)#address-family ipv4 unicast vrf FINANCE
R2(config-router-af)#neighbor 10.20.13.2 ebgp-multihop 2
R2(config-router-af)#address-family vpnv4 unicast

On remote router:

R3(config-router)#vrf definition FINANCE
R3(config-vrf)#rd 65001:200
R3(config-if)#router bgp 65001
R3(config-router)#address-family ipv4 unicast vrf FINANCE
R3(config-router-af)#neighbor 10.20.12.2 remote-as 65000
R3(config-router-af)#neighbor 10.20.12.2 ebgp-multihop 2
R3(config-router-af)#network 10.3.10.0 mask 255.255.255.0
R3(config-router)#address-family vpnv4 unicast

Verification

All testing or verification commands have to include the specific VRF whose features you would like to view.

show ip route vrf <vrf-name>

To view the IP routing table of a specific VRF.

R2#show ip route vrf RESEARCH

Routing Table: RESEARCH
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 10 subnets, 3 masks
C        10.2.14.0/24 is directly connected, Loopback14
L        10.2.14.1/32 is directly connected, Loopback14
C        10.2.15.0/24 is directly connected, Loopback15
L        10.2.15.1/32 is directly connected, Loopback15
B        10.3.14.0/24 [20/0] via 10.10.13.2, 00:43:49
B        10.3.15.0/24 [20/0] via 10.10.13.2, 00:44:17
B        10.3.16.0/24 [20/0] via 10.10.13.2, 00:44:09
C        10.10.12.0/30 is directly connected, GigabitEthernet0/0.10
L        10.10.12.2/32 is directly connected, GigabitEthernet0/0.10
O        10.10.13.0/30 [110/2] via 10.10.12.1, 01:17:12, GigabitEthernet0/0.10
      172.30.0.0/24 is subnetted, 1 subnets
O        172.30.0.0 [110/3] via 10.10.12.1, 01:17:12, GigabitEthernet0/0.10
      172.31.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.31.1.0/24 is directly connected, GigabitEthernet1/0
L        172.31.1.1/32 is directly connected, GigabitEthernet1/0
R2#

ping vrf <vrf-name>

Check reachability of remote networks.

R2#ping vrf RESEARCH 10.2.14.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.14.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/12 ms
R2#

show run vrf <vrf-name>

To view VRF configurations for a specific vrf.

R2#show run vrf FINANCE
Building configuration...

Current configuration : 715 bytes
ip vrf FINANCE
 description Finance VRF
 rd 65000:100
!
!
interface GigabitEthernet0/0
 no ip address
 duplex auto
 speed auto
 media-type gbic
 negotiation auto
!
interface GigabitEthernet0/0.20
 encapsulation dot1Q 20
 ip vrf forwarding FINANCE
 ip address 10.20.12.2 255.255.255.252
!
interface FastEthernet4/0
 ip vrf forwarding FINANCE
 ip address 172.16.1.10 255.255.255.0
 duplex auto
 speed auto
!
router eigrp 1
!
address-family ipv4 vrf FINANCE autonomous-system 1
  network 10.20.12.0 0.0.0.3
 exit-address-family
!
router bgp 65000
 !
 address-family ipv4 vrf FINANCE
  neighbor 10.20.13.2 remote-as 65001
  neighbor 10.20.13.2 ebgp-multihop 2
  neighbor 10.20.13.2 activate
 exit-address-family
!
end

show ip vrf

To view configured VRFs.

R2#show ip vrf
  Name                             Default RD          Interfaces
  FINANCE                          65000:100           Gi0/0.20
                                                       Fa4/0
  RESEARCH                         65000:200           Gi0/0.10
                                                     Gi1/0
                                                     Lo14
                                                     Lo15

show ip route vrf *

To view the IP routing table for all VRFs at once.

R2#show ip route vrf *
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is not set


Routing Table: FINANCE
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 7 subnets, 3 masks
B        10.3.10.0/24 [20/0] via 10.20.13.2, 04:25:16
B        10.3.11.0/24 [20/0] via 10.20.13.2, 02:22:08
B        10.3.12.0/24 [20/0] via 10.20.13.2, 02:21:21
B        10.3.13.0/24 [20/0] via 10.20.13.2, 01:45:26
C        10.20.12.0/30 is directly connected, GigabitEthernet0/0.20
L        10.20.12.2/32 is directly connected, GigabitEthernet0/0.20
D        10.20.13.0/30
           [90/3072] via 10.20.12.1, 05:28:49, GigabitEthernet0/0.20
      172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
C        172.16.1.0/24 is directly connected, FastEthernet4/0
L        172.16.1.10/32 is directly connected, FastEthernet4/0
D        172.16.2.0/24
           [90/28672] via 10.20.12.1, 05:28:49, GigabitEthernet0/0.20

Routing Table: RESEARCH
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 10 subnets, 3 masks
C        10.2.14.0/24 is directly connected, Loopback14
L        10.2.14.1/32 is directly connected, Loopback14
C        10.2.15.0/24 is directly connected, Loopback15
L        10.2.15.1/32 is directly connected, Loopback15
B        10.3.14.0/24 [20/0] via 10.10.13.2, 01:24:15
B        10.3.15.0/24 [20/0] via 10.10.13.2, 01:24:43
B        10.3.16.0/24 [20/0] via 10.10.13.2, 01:24:35
C        10.10.12.0/30 is directly connected, GigabitEthernet0/0.10
L        10.10.12.2/32 is directly connected, GigabitEthernet0/0.10
O        10.10.13.0/30 [110/2] via 10.10.12.1, 01:57:38, GigabitEthernet0/0.10
      172.30.0.0/24 is subnetted, 1 subnets
O        172.30.0.0 [110/3] via 10.10.12.1, 01:57:38, GigabitEthernet0/0.10
      172.31.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.31.1.0/24 is directly connected, GigabitEthernet1/0
L        172.31.1.1/32 is directly connected, GigabitEthernet1/0
R2#

show ip interfaces vrf <vrf-name>

Display interfaces in specified VRF.

show ip protocols vrf <vrf-name>

View dynamic protocols running in a VRF.

R2#show ip protocols vrf FINANCE
*** IP Routing is NSF aware ***

Routing Protocol is "eigrp 1"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Default networks flagged in outgoing updates
  Default networks accepted from incoming updates
  EIGRP-IPv4 Protocol for AS(1) VRF(FINANCE)
    Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
    NSF-aware route hold timer is 240
    Router-ID: 172.16.1.10
    Topology : 0 (base)
      Active Timer: 3 min
      Distance: internal 90 external 170
      Maximum path: 4
      Maximum hopcount 100
      Maximum metric variance 1
      Total Prefix Count: 3
      Total Redist Count: 0

  Automatic Summarization: disabled        
  Maximum path: 4                          
  Routing for Networks:                    
    10.20.12.0/30                          
  Routing Information Sources:            
    Gateway         Distance      Last Update
    10.20.12.1            90      04:45:54
  Distance: internal 90 external 170      
                                          
Routing Protocol is "bgp 65000"            
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  IGP synchronization is disabled          
  Automatic route summarization is disabled
  Neighbor(s):                            
    Address          FiltIn FiltOut DistIn DistOut Weight RouteMap
    10.20.13.2                            
  Maximum path: 1                          
  Routing Information Sources:            
    Gateway         Distance      Last Update
    10.20.13.2            20      01:02:31
  Distance: external 20 internal 200 local 200

R2#

EIGRP

show ip eigrp vrf <vrf-name> topology

R2#show ip eigrp vrf FINANCE topology
EIGRP-IPv4 Topology Table for AS(1)/ID(172.16.1.10) VRF(FINANCE)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status
              
P 10.20.12.0/30, 1 successors, FD is 2816
        via Connected, GigabitEthernet0/0.20
P 172.16.2.0/24, 1 successors, FD is 28672
        via 10.20.12.1 (28672/28416), GigabitEthernet0/0.20
P 10.20.13.0/30, 1 successors, FD is 3072
        via 10.20.12.1 (3072/2816), GigabitEthernet0/0.20

show ip eigrp vrf <vrf-name> neighbors

R2#show ip eigrp vrf FINANCE neighbors detail
EIGRP-IPv4 Neighbors for AS(1) VRF(FINANCE)                                      
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
0   10.20.12.1              Gi0/0.20                 12 04:34:57   17   102  0  7
   Version 10.0/2.0, Retrans: 0, Retries: 0, Prefixes: 2                          
   Topology-ids from peer - 0                                                    

show ip eigrp vrf <vrf-name> interfaces

Alternative command show eigrp address-family ipv4 vrf <vrf-name> interfaces

R2#show ip eigrp vrf FINANCE interface detail
EIGRP-IPv4 Interfaces for AS(1) VRF(FINANCE)
                              Xmit Queue   PeerQ        Mean   Pacing Time   Multicast    Pending
Interface              Peers  Un/Reliable  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Gi0/0.20                 1        0/0       0/0          17       0/0           64           0  
  Hello-interval is 5, Hold-time is 15
  Split-horizon is enabled
  Next xmit serial
  Packetized sent/expedited: 1/0
  Hello's sent/expedited: 3579/2                  
  Un/reliable mcasts: 0/1  Un/reliable ucasts: 1/1
  Mcast exceptions: 0  CR packets: 0  ACKs suppressed: 0
  Retransmissions sent: 0  Out-of-sequence rcvd: 1
  Topology-ids on interface - 0
  Authentication mode is not set
R2#

BGP

show bgp vpnv4 unicast all

To view all the shared prefixes in all VRFs

R2(config-if)#do show bgp vpnv4 unicast all
BGP table version is 10, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path  
Route Distinguisher: 65000:100 (default for vrf FINANCE)              
 *>  10.3.10.0/24     10.20.13.2               0             0 65001 i
 *>  10.3.11.0/24     10.20.13.2               0             0 65001 i
 *>  10.3.12.0/24     10.20.13.2               0             0 65001 i
 *>  10.3.13.0/24     10.20.13.2               0             0 65001 i
Route Distinguisher: 65000:200 (default for vrf RESEARCH)            
 *>  10.2.14.0/24     0.0.0.0                  0         32768 i      
 *>  10.2.15.0/24     0.0.0.0                  0         32768 i      
 *>  10.3.14.0/24     10.10.13.2               0             0 65001 i
 *>  10.3.15.0/24     10.10.13.2               0             0 65001 i
 *>  10.3.16.0/24     10.10.13.2               0             0 65001 i
R2(config-if)#

show bgp vpnv4 unicast vrf <vrf-name> summary

To view routes in the BGP table in a specific VRF

R2(config-if)#do show bgp vpnv4 unicast vrf RESEARCH
BGP table version is 10, local router ID is 2.2.2.2                    
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,    
Origin codes: i - IGP, e - EGP, ? - incomplete                          
RPKI validation codes: V valid, I invalid, N Not found                  
                                                                        
     Network          Next Hop            Metric LocPrf Weight Path    
Route Distinguisher: 65000:200 (default for vrf RESEARCH)              
 *>  10.2.14.0/24     0.0.0.0                  0         32768 i        
 *>  10.2.15.0/24     0.0.0.0                  0         32768 i        
 *>  10.3.14.0/24     10.10.13.2               0             0 65001 i  
 *>  10.3.15.0/24     10.10.13.2               0             0 65001 i  
 *>  10.3.16.0/24     10.10.13.2               0             0 65001 i  

show bgp vpnv4 unicast vrf <vrf-name> neighbor

To view BGP neighbors formed in a specific VRF

R2#show bgp vpnv4 unicast vrf RESEARCH neighbor
BGP neighbor is 10.10.13.2, vrf RESEARCH, remote AS 65001, external link
  BGP version 4, remote router ID 3.3.3.3                          
  BGP state = Established, up for 00:36:27                        
  Last read 00:00:42, last write 00:00:27, hold time is 180, keepalive interval is 60 seconds
  Neighbor sessions:                                              
    1 active, is not multisession capable (disabled)              
  Neighbor capabilities:                                          
    Route refresh: advertised and received(new)                    
    Four-octets ASN Capability: advertised and received            
    Address family IPv4 Unicast: advertised and received          
    Enhanced Refresh Capability: advertised and received          
    Multisession Capability:                                      
    Stateful switchover support enabled: NO for session 1          
  Message statistics:                                              
    InQ depth is 0                                                
    OutQ depth is 0                                                
                                                                  
                         Sent       Rcvd                          
    Opens:                  1          1                          
    Notifications:          0          0                          
    Updates:                3          4                          
    Keepalives:            40         41                          
    Route Refresh:          0          0                          
    Total:                 44         46                          
  Default minimum time between advertisement runs is 0 seconds    
                                                                  
For address family: VPNv4 Unicast                                
  Translates address family IPv4 Unicast for VRF RESEARCH          
  Session: 10.10.13.2                                              
  BGP table version 10, neighbor version 10/0                      
  Output queue size : 0                                            
  Index 2, Advertise bit 0                                        
  2 update-group member                                            
  Slow-peer detection is disabled                                  
  Slow-peer split-update-group dynamic is disabled                
                                 Sent       Rcvd                  
  Prefix activity:               ----       ----                  
    Prefixes Current:               2          3 (Consumes 192 bytes)
    Prefixes Total:                 2          3                  
    Implicit Withdraw:              0          0                  
    Explicit Withdraw:              0          0                  
    Used as bestpath:             n/a          3                  
    Used as multipath:            n/a          0                  
                                                                  
                                   Outbound    Inbound            
  Local Policy Denied Prefixes:    --------    -------            
    Bestpath from this peer:              3        n/a            
    Total:                                3          0            
  Number of NLRIs in the update sent: max 1, min 0                
  Last detected as dynamic slow peer: never                        
  Dynamic slow peer recovered: never                              
  Refresh Epoch: 1                                                
  Last Sent Refresh Start-of-rib: never                            
  Last Sent Refresh End-of-rib: never                              
  Last Received Refresh Start-of-rib: never                        
  Last Received Refresh End-of-rib: never                          
                                       Sent       Rcvd            
        Refresh activity:              ----       ----            
          Refresh Start-of-RIB          0          0              
          Refresh End-of-RIB            0          0              
                                                                  
  Address tracking is enabled, the RIB does have a route to 10.10.13.2
  Connections established 1; dropped 0                            
  Last reset never                                                
  External BGP neighbor may be up to 2 hops away.                  
  Transport(tcp) path-mtu-discovery is enabled                    
  Graceful-Restart is disabled                                    
Connection state is ESTAB, I/O status: 1, unread input bytes: 0    
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 2
Local host: 10.10.12.2, Local port: 179
Foreign host: 10.10.13.2, Foreign port: 17911
Connection tableid (VRF): 2
Maximum output segment queue size: 50

Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x124CFC4):      
Timer          Starts    Wakeups            Next
Retrans            43          0             0x0
TimeWait            0          0             0x0
AckHold            45         41             0x0
SendWnd             0          0             0x0
KeepAlive           0          0             0x0
GiveUp              0          0             0x0
PmtuAger            0          0             0x0
DeadWait            0          0             0x0
Linger              0          0             0x0
ProcessQ            0          0             0x0

iss: 3387542972  snduna: 3387543921  sndnxt: 3387543921
irs: 2815833713  rcvnxt: 2815834735                
                                                  
sndwnd:  15436  scale:      0  maxrcvwnd:  16384  
rcvwnd:  15363  scale:      0  delrcvwnd:   1021  
                                                  
SRTT: 997 ms, RTTO: 1025 ms, RTV: 28 ms, KRTT: 0 ms
minRTT: 16 ms, maxRTT: 1000 ms, ACK hold: 200 ms  
Status Flags: passive open, gen tcbs              
Option Flags: VRF id set, nagle, path mtu capable  
IP Precedence value : 6

Datagrams (max data segment is 1460 bytes):
Rcvd: 90 (out of order: 0), with data: 46, total data bytes: 1021
Sent: 88 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 44, total data bytes: 948

 Packets received in fast path: 0, fast processed: 0, slow path: 0
 fast lock acquisition failures: 0, slow path: 0
TCP Semaphore      0x6AAD22B4  FREE

R2#

OSPF

OSPF commands do not require the inclusion of the VRF keyword and VRF name within the command.

show ip ospf

Displays the VRF operational state of OSPF.

R2#show ip ospf
 Routing Process "ospf 1" with ID 172.31.1.1
   Domain ID type 0x0005, value 0.0.0.1
 Start time: 00:00:55.892, Time elapsed: 06:21:24.020
 Supports only single TOS(TOS0) routes
 Supports opaque LSA
 Supports Link-local Signaling (LLS)
 Supports area transit capability
 Supports NSSA (compatible with RFC 3101)
 Connected to MPLS VPN Superbackbone, VRF RESEARCH
 Event-log disabled
 It is an area border router
 Router is not originating router-LSAs with maximum metric
 Initial SPF schedule delay 5000 msecs
 Minimum hold time between two consecutive SPFs 10000 msecs
 Maximum wait time between two consecutive SPFs 10000 msecs
 Incremental-SPF disabled
 Minimum LSA interval 5 secs
 Minimum LSA arrival 1000 msecs
 LSA group pacing timer 240 secs
 Interface flood pacing timer 33 msecs
 Retransmission pacing timer 66 msecs
 Number of external LSA 0. Checksum Sum 0x000000
 Number of opaque AS LSA 0. Checksum Sum 0x000000
 Number of DCbitless external and opaque AS LSA 0
 Number of DoNotAge external and opaque AS LSA 0
 Number of areas in this router is 1. 1 normal 0 stub 0 nssa
 Number of areas transit capable is 0
 External flood list length 0
 IETF NSF helper support enabled
 Cisco NSF helper support enabled
 Reference bandwidth unit is 100 mbps
    Area BACKBONE(0)
        Number of interfaces in this area is 2
        Area has no authentication
        SPF algorithm last executed 01:59:51.104 ago
        SPF algorithm executed 12 times
        Area ranges are
        Number of LSA 5. Checksum Sum 0x01F6CD
        Number of opaque link LSA 0. Checksum Sum 0x000000
        Number of DCbitless LSA 0
        Number of indication LSA 0
        Number of DoNotAge LSA 0
        Flood list length 0

Friday 23 June 2023

Cisco DNA Center Assurance

Introduction and Overview

Cisco DNA Center (DNAC) is the orchestration platform for designing, provisioning, and implementing policies on the network. It provides visibility into the network and an understanding of the user experience with network services. It collects telemetry from existing multiple devices, applications and users, applies advanced algorithms to uncover correlated insights and suggest remediation. This helps in minimizing troubleshooting time by identifying the root cause of issues on the network. DNAC generates health scores for client, network and applications in use; these are compiled from different metrics.

With Cisco DNA:

  • One gains full visibility of the network
  • It is possible to predict network performance and issues
  • Rapidly troubleshoot issues.

The DNA Center Assurance landing page provides summaries of network and client health. The network health displays health summaries (in percentages) of switches, routers, wireless LAN controllers, and access points. The client health displays summaries of wireless and wired clients.

Cisco DNA includes guided remediation which provides suggestions for correcting a detected issue.

A demo version of Cisco DNA Center can be found at the URL https://dcloud-dna-center-inst-rtp.cisco.com/dna/home. Login access uses the following credentials: username: demo password: demo1234!

SD-Access and DNA Setup

The following discussion on Cisco DNA Center is based on version 2.2.2.8 released on 17/June/2022. Other Cisco DNA Center releases can be found here.

The DNA Center version in use can be determined by clicking the "About" icon at the top right.

SD-Access fabric, in a campus network enables the maintenance of network policies to a roaming user regardless of their location. SD-Access uses IS-IS as the underlay protocol and LIST-VXLAN+TrustSec in the overlay protocol to allow users with their devices to be onboarded onto the network and maintain their same network configuration anywhere on the network.

The SD-fabric is created by DNA center. A guided workflow is used to setup the entire SD-fabric. DNA Center is made up of four main modules. The following is a simplified sitemap of the DNA modules:

  1. Design: design of the physical layout of the network is developed including the addresses of the buildings, and geographical locations. Features that can be configured under Design include:
    • Network Hierarchy: create organizational hierarchies. Import and export of hierarchies is supported. The two export options are sites or maps.
    • Network Settings: consists of the following:
      • Network: Configure AAA, NTP and Image Distribution (SFTP) servers. Once devices are discovered, DNAC will deploy using these settings. Other settings are DNS server, message of the day (MoTD) with the option to not override the device MoTD; default is to override the device MoTD. These settings can be applied to a site or to all sites (global).
      • Device Credentials: credentials for CLI, SNMP (v2c and v3 - read and write), HTTP(S) - read and write.
      • IP Address pools: Address pools consist of the IP CIDR, gateway, DHCP and DNS servers for the various subnets of the organization. IPv4 and IPv6 address pools are supported.
      • SP Profiles: QoS settings.
      • Wireless: Wireless networks configured with the settings for:
        • SSID
        • Level of security (Enterprise or personal, WPA 2 or WPA 3)
        • Type of network: voice and data or data only.
        • Wireless option: dual band operation, dual band operation with band select, 2,4GHz only, 5GHz only.
        • AAA authentication
        • Fast transition(802.11r) configuration
      • Telemetry: Configure Syslog, traps, and NetFlow properties for devices. DNAC will deploy these settings after the devices have been assigned to a site or provisioned.
    • Image Repository: contains images for devices (physical and virtual) on the network.
    • Network Profiles: profiles supported are for Firewall, NFVIS, Wireless, Switching, Routing, Telemetry Appliance
    • Authentication Template
  2. Policy: identify the end-users and end-points and access authorizations.
    • AI Endpoint Analytics
    • Group-Based Access Control
    • Application
    • Traffic Copy
    • Virtual Network
  3. Provision: discover the network devices and onboard them. Additionally, provision module enables the creation of the network access fabric.
    • Network Devices:
      • Inventory: list of managed network devices and their sites of allocation
      • Plug and Play: detected network devices (through device discovery), can be assigned to a site and become managed devices
      • Inventory Insights
    • Fabric
    • Services
      • Service Catalog
      • Cisco User Defined Network
      • Application Visibility
      • Stealthwatch Security Analytics
      • App Hosting for Switches
      • Umbrella
      • Site to Site VPN
    • Cloud
  4. Assurance: monitor and troubleshoot the network.
    • Dashboards
      • Health
      • Issues
      • Sensors
      • Wi-Fi 6
      • Rogue and aWIPS
      • PoE
      • Dashboard Library
    • AI Network Analytics
      • Network Insights
      • Network Healthmap
      • Peer Comparison
      • Network Comparison
      • Baselines
    • Manage
      • Issue Settings
      • Health Score Settings
      • Sensors
      • Intelligent Capture Settings

To be able to gain insights into the performance of the network, DNA should be setup and devices enrolled. The procedure to setup DNAC is as follows:

  1. Install DNAC
  2. Create a site hierarchy: where the locations, building, floors are defined.
  3. Run discovery: using IP range, CDP or LLDP
  4. Inventory collection: DNA detects the devices
  5. Device manageability: DNA auto-pushes configuration to the device to enable it send telemetry to DNA
  6. Provision Devices: Assign devices to site/building/floor previously defined.
  7. Devices ready for assurance

Network devices such as APs, switches, routers, firewalls are enrolled into DNAC. These devices typically run on IOS-XE such as catalyst 9000 series switches, ISR-4400 series routers. DNA center communicates with these devices using programmability protocols NETCONF/RESTCONF. When DNA Center communicates with devices using NETCONF/RESTCONF, it creates a telemetry subscription through which the devices can stream data such as CPU, memory utilization, interface counters, ACL counters; basically all output from show commands are streamed to the DNA Center. DNA Center stores this information and logs it into a database with the timestamp of occurrence. This enables understanding these parameters across a time range. The information collected is from network devices as well as client information. DNA Center applies machine learning to this collected telemetry information to provide insights into the network performance and lists any detected issues degrading the network.

Design Network Hierarchy Structure

The DNA container hierarchy is divided into groups:

  • Areas high-level logical subdivisions. All areas are children of the Global area. Areas can contain other areas or buildings.
  • Buildings: actual physical locations. Buildings have a geo-location. Buildings can contain floors/floor plans.
  • Floors: physical sub-divided space in or out of a building.

Network Discovery

For devices to be managed, they must first be discovered. The discovery feature:

  • Scans the network for network devices
  • Inventories discovered devices
  • Can configure required network settings (if not already present).
Before discovery of devices, the device credentials need to be configured where:
  • The SNMP credential is for DNAC discovery
  • For SSH access, credentials should have the privilege level 15 for DNAC to be able to configure devices with appropriate commands when applying policies or resolving detected issues.

Discovery supports the following types of device discovery:

  • CDP: connect to a seed device and learn the next hop devices of the seed device. This process is repeated on the neighboring devices to the seed device to discover other devices.
  • IP address or range: scans the designated IP address range with ICMP to identify responding devices.
  • LLDP: operates similarly to CDP.

In DNA Center, to access the device discovery feature, Tools → Discovery

To create a new discovery, select Add Discovery. The following page is opened.

At least one CLI credential and one SNMP credential is required. NETCONF is required for 9800 series switches.

Add Device

A new device can be added manually through the Inventory tab under the Provisioning module. This is done by selecting the "Add Device" button. The following parameters are required when adding a new device:

  • Device type: options available include: network device, compute device, Meraki dashboard, Firepower Management Center.
  • Credentials: preconfigured credentials are selected for;
    • CLI
    • SNMP credential, version, retries and timeout values.
    • HTTP(S) credential and port number
  • NETCONF port
  • Authentication protocol: SSH or Telnet

Select "View Inventory" to view the newly added devices. To add the device to a site: Select "Actions", then Provision, then "Assign Device to Site". The serial number and device type are displayed to confirm the device and as well as the list of all sites. Discovered devices are added to the inventory by DNA. After initial discovery, DNAC maintains the inventory by polling the devices in inventory, by default, every 25 minutes to determine reachability. This can be modified to up to 24 hours. By default, only devices that have been active for less than a day are displayed.

Device Credentials

DNAC requires a set of global credentials to use when enrolling the devices into DNAC. These settings are the same as Discovery credential sets:

  • CLI credentials: username, password and enable password. This local user should have a privilege level of 15.
  • SNMPv2 / SNMPv3: SNMPv2 read/write community string (SNMPv3 is optional).
  • HTTPS (Optional): read/write string, username, password and port.

Credential sets define common global credentials, specified in global container, and instance specific credential sets, specified per container, for network devices in a discovery. Credentials in higher-level containers are inherited by lower level containers. DNAC allows multiple credentials to be specified for a defined credential type. Support for exceptions (non-common) credentials can be included in discovery.

In DNAC, these credentials can be added from the Design → Network Settings → Device Credentials.

The credentials can be set for the Global site or lower site in the organizational hierarchy. Credentials configured at the global level will be inherited by the sites under the Global location.

If a list of credentials is available for a given site, select the appropriate credential that will be used by clicking the radio button of that corresponding credential.

DNAC automation can add missing credential sets to devices upon discovery for example if the CLI credentials are available but SNMP configuration is not working, DNA is able to access the device using the CLI credentials and enable SNMP with the configuration that was not previously functional but entered into DNA during the device enrolment. If multiple credentials are configured, DNA will start with the first credential, then the second, third ... up to the credential that works. DNA will remember the credential that worked for a given device.

Different device types are managed through different credential types:

  • SSH: standard Cisco devices.
  • CLI: standard Cisco devices.
  • SNMP: standard Cisco devices.
  • HTTP(S): NFVIS devices
  • NETCONF: all supported devices such as Cisco XE devices

For discovery to work, the required ports include:

  • Ping: ICMP echo and reply.
  • SSH: TCP port 22
  • SNMP Poll: UDP port 161
  • SNMP Trap: UDP port 162
  • Syslog: UDP port 514
  • NetFlow: UDP port 6007 or TCP 443

At a minimum, CLI and SNMP details are required for DNAC to discover devices. For SNMPv2c community read-only string is required. For SSH/Telnet device access, the user account should have a privilege level of 15.

The protocol order of the credentials can be specified. The options include SSH and Telnet. If Telnet is enabled, a warning message gets displayed about the insecure nature of Telnet.

Device Controllability

Device controllability is a feature that is enabled, by default, when adding a device to inventory from the Inventory page or through discovery. Device Controllability operates as follows:

  • If DNAC could not connect to the device using any of the SNMP credentials provided, but could connect using the CLI credentials, then DNAC will configure the first SNMP credential available in the request.
  • If available, the first SNMPv3 credential will be configured instead of SNMPv2c.
  • If NETCONF support exists in the device and DNAC could not connect to the device using NETCONF but could connect to the CLI credentials, then DNAC will configure NETCONF on the first port provided in the request.
  • NETCONF is supported on Polaris images version 16.5 or higher.

Configuration Changes on Wireless LAN Controllers (WLC)

During the network discovery process, there are several changes that DNAC automatically makes to WLCs:

  • Installs a certificate for streaming telemetry: this certificate secures all communications between DNAC and the device. This certificate is installed for all devices i.e., routers, switches, WLCs etc.
  • Configure streaming telemetry service (WSA)

DNAC becomes the network assurance service for that WLC from the start.

Configuration Changes on Switches

There are several changes that DNAC automatically makes to switches during discovery:

  • PKI
  • IPDT
  • HTTP server source interface is configured
  • SNMP RO & RW communities (if not configured).

  crypto pki trustpoint DNAC-CA
    enrollment mode ra
    enrollment terminal
    usage ssl-client
    revocation-check crl
  crypto pki certificate chain DNAC-CA
    <snip>
    quit
    
  device-tracking tracking
  !
  device-tracking policy IPDT_MAX_10
    limit address-count 10
    no protocol udp
    tracking enable
    !
  interface <ACCESS-INTERFACES>
    device-tracking attach-policy IPDT_MAX_10
    
  ip http client source-interface Loopback0
  
  snmp-server community <RO-COMMUNITY> ro
  snmp-server community <RW-COMMUNITY> rw

If an ACL is configured for SNMP community string, DNAC may remove the ACL during discovery. Remember to add the ACL after the DNAC discovery is complete.

Device Controllability in Host Tracking

When device discovery is performed with "Device Controllability" enabled, DNAC will enable IP device tracking(IPDT) on discovered devices. IPDT is activated on switch ports operating in the switchport access mode. IP Device Tracking keeps track of connected hosts on a switch. IPDT sends an ARP probe on that access interface to check that the device is alive. This ARP is not propagated out any other port. This helps in tracking where clients are connected in the network. By default, switches use MAC-address tracking for monitoring connected hosts. If a device is connected to the network but is silent (not accessing network services) MAC addresses timeout in the MAC address cache on the switch. This will assume that the device is off the network. With IPDT, the MAC address of a connected device is not allowed to timeout. When the MAC address timer is close to expiry, an ARP probe is sent out that particular access port that the device is connected to and when the device responds, the MAC address timer is reset.

Configuration Changes on Routers

There are several changes that DNAC automatically makes to routers during discovery:

  • PKI: certificate to ensure confidentiality between DNAC and the router.
  • HTTP server source interface is configured.
  • SNMP RO & RW communities are enabled if not already configured.

  crypto pki trustpoint DNAC-CA
    enrollment mode ra
    enrollment terminal
    usage ssl-client
    revocation-check crl
  crypto pki certificate chain DNAC-CA
    <snip>
    quit
    
  ip http client source-interface Loopback0
  
  snmp-server community <RO-COMMUNITY> ro
  snmp-server community <RW-COMMUNITY> rw

Telemetry

Device Provisioning

When device discovery is completed, a newly added device is placed under the Global site and categorized under "unassigned devices". Unassigned devices not not have a site allocation. Assurance requires devices to be assigned to a site in order to push telemetry. It is important to assign a device to a site. This is because network telemetry may not be received for the device if it is not assigned to a site. Assigning a device to a site does not push configuration to the device.

Telemetry

Syslog, SNMP and NetFlow properties can be configured for DNA Center managed devices. DNA Center will apply these configurations to the devices when they are assigned to a site or provisioned. DNA Center can be configured to be the SNMP trap server, syslog server or NetFlow collector server. Optionally, external servers can be configured in DNA Center for export of the telemetry data. By default, DNA Center is the SNMP server for managed devices.

Device Telemetry Profiles

Telemetry profiles can be configured to send Syslog, and NetFlow configs to supported devices. Telemetry profiles include two predefined profiles that send telemetry to DNA Center and one profile that does not send telemetry. Custom telemetry profiles can be added. The three default telemetry profiles for use in provisioning assurance configurations include: maximal, optimal and disable.

Profile Name Syslog level NetFlow version
Maximal Informational IPFIX
Optimal Informational
Disable

Profiles can be assigned at site or device level. The default telemetry profile is Disable. The recommendation is to apply Maximal to routers and Optimal to switches.

Custom telemetry profiles can also be created in exceptional use-cases where the best practice telemetry profile settings need to be altered. If custom telemetry profiles are configured and the device does not support the telemetry profile configurations e.g. NetFlow, then DNA will produce a notification message. The supported telemetry configuration will be pushed to DNA and the unsupported telemetry will not be pushed.

Telemetry profile push is used to assign profiles to specific devices and validate configuration push. If the predefined telemetry profiles are used, telemetry information gets pushed to DNAC immediately after being applied.

Verify assurance dashboards are being populated with expected telemetry data. DNAC sets itself up as a syslog server to be able to collect data from that device.

NetFlow

NetFlow data is required for Application Health data. DNA provisioning of NetFlow is only supported on routers running IOS v16 or newer. The current behaviour is for NetFlow to be enabled on all interfaces of routers.

DNA Center Dashboards

The landing page of DNA Center is the DNA Dashboard. The information displayed in the dashboard is aggregated over the last 24 hours.

DNA Center Assurance Issue Dashboard

The DNAC Assurance issue dashboard is a centralized view of network issues allowing one to quicky identify and diagnose network problems. It provides insights into problems and provides recommendations on how to resolve the problems. By default, issue data is saved for up to 30 days.

The issue table contains a list of issues categorized by priority. Additionally, some issues are flagged as being identified by AI.

Issue Status

Issues have three types of status: open, resolved, and ignored. When the issue is ignored, it is ignored for a specific time period. An issue can be resolved in two ways:

  1. Manually changing the status
  2. Auto-resolution mechanism; support for autoresolution is available for some issues; others are continually being added.

Issues are classified according to priority. The options are:

  • P1: A critical issue that needs immediate attention which can result in wider impact on network operations.
  • P2: A major issue that can potentially impact multiple devices or clients.
  • P3: A minor issue that has a localized or minimal impact.
  • P4: A warning issue that may not be an immediate problem but addressing it can optimize the network performance.

The issues dashboard can be filtered to display issues detected for a specific site

By default, the dashboard displays issues detected over the last 24 hours. However, this can be filtered for a time range of 3 hours, 24 hours or 7 days. Additionally, filtering can be done for a specified date range:

The following images show how to resolve a detected issue:

DNA Center Assurance Health

The DNA Center Assurance health section displays the health status of the network, clients and applications. The health dashboard also displays the Top 10 Issues detected which are categorized by priority.

The Network Health page can be accessed via the Assurance → Health. This view provides an aggregated score of the health of monitored devices for the defined time range.

Network Health

The Network Health section of the DNA Assurance center displays the health status of network equipment such as routers, switches, wireless LAN controllers (WLC), and access points (AP). It gives a snapshot of the device health over the past 15 minutes and 24 hours. A score is provided for the current state of health of the network. Network devices are categorized based on their role or type i.e., wireless, core, access, distribution switch, router.

Selecting a particular device with detected issues opens up Device 360 where the details of detected issues are displayed with the option to resolve the issues detected.

Device 360

Device 360 gives a full view of the device displaying the most detailed raw telemetry data received from the device. You can monitor and preview the health parameters of the network. Device 360 displays the following parameters:

  • The current health score of the device: DNA monitors various parameters of a network device. These parameters include:
    • Memory utilization
    • CPU utilization
    • Data-plane parameters:
      • Noise and air-quality for wireless
      • Uplink availability
      • Link errors
    If the various parameters of the device have a score of 10/10 and only one parameter has a score of 2/10, the overall score of the device is 2/10.
  • The device details such as IP address, Product ID, and software version.
  • The device health score on a 24-hour timeline by default. Other timeline options include 7 days.
  • List of issues that occurred in the past 24-hours.

In the case of APs, the additional information collected includes:

  • Number of clients connected
  • Noise, air quality, interference

Device 360 provides a list of issues experienced by the network device. The timeline of the issues can be viewed by selecting the appropriate date/time. Suggested actions are provided on how to resolve any identified issues.

Device 360 includes a physical neighbor topology of the device. For a switch, it displays the clients connected and any uplink devices. This helps in determining the end-points that are affected when the switch or uplink device experiences a problem. The health score of the neighbors can also be determined by clicking on the neighboring devices in the physical topology.

Device 360 supports a pathtrace which enables performing a connectivity test between the device and a specified destination. It uses information learned from the network topology. It queries devices to, among other things, determine the availabilty of equal-cost multipaths. If intermediate devices are not managed e.g. MPLS, a cloud symbol is used to symbolize the unknown intermediate unmanaged devices.

Client Health

The client health page displays the health status of detected network clients. The following information is displayed about the clients:

  • Client devices are listed and segregated between wired clients and wireless clients.
  • Onboarding: A broken-down view of every step of the onboarding process is displayed making it possible to determine if the network infrastructure is causing the fault or the network service such as AAA. Clients that failed the onboarding process are displayed.
  • For wireless networks, the following information is displayed:
    • Client count per SSID
    • Client roaming times
    • Connectivity RSSI
    • Connectivity SNR

Client health status

Client network experience

List of clients

Client 360

From the list of clients displayed under the page Health → Client, selecting a client opens up the Client 360 page for the client and it displays the following information:

Application Health

Application health dashboard processes application data and gives an insight into application performance. Application Health page displays information about how your applications are performing across the entire network. Applications are classified as business-relevant (such as Office 365 apps), business-irrelevant (such as Netflix), and default. Cisco application visibility is used to classify the applications. This classification is done based on the NBAR (Network-based application recognition). Application Health enables the monitoring of application statistics and application response. Application experience is based on NetFlow records exported by the routers. It correlates KPIs sources of the network to identify the problem domain faster and make issue resolution recommendations. Application health includes vital information such as business-class, traffic class, packet-loss percentage and latency. Application health can be accessed under DNA Assurance → Health → Application.

To receive application telemetry, ensure that:

  1. DNA discovers the required network devices
  2. Provision the device and assign it to a site
  3. Enable NetFlow telemetry collection for the devices

By default, the application health dashboard displays application packet loss, average throughput, network latency for business relevant applications.

Application 360

Selecting a specific application from the application health page displays the Application 360 page. The Application 360 page displays the details of the network experience of an application; these include:

  • Issues experienced by the application such as network latency including the total number of occurences.
  • Network devices exporting the application telemetry including:
    • Usage in bytes
    • Throughput in Kbps
    • Packet loss
    • Jitter
    • Network latency
    • Client network latency and server network latency
    • Application server latency
  • Application endpoints i.e. client devices using the application. Selecting a client device opens up the Client 360 page for the client.

SNMP Collector

DNA can also be used to collect SNMP traps and informs. DNA is the default SNMP collector. It pools network devices to gather telemetry data. By default, the following information is collected by SNMP:

  • Device health: includes CPU utilization, memory, environment temperature, and device availability metrics. This information is gained through polling every 10 minutes by default.
  • Interface health: includes interface availability and metrics.
  • TCAM: polled
These SNMP configuration is accessible via: Systems Settings → Data Platform → Collectors. Select Collector-SNMP. The defaults are ok. If utilizing SD-WAN, then can make appropriate modifications suitable for SD-WAN. TODO: Add screenshot of SNMP.

Software Image Management (SWIM)

Software management allows the installation, upgrade, and patching the embedded operating system running in managed devices such as switches, routers, APs, etc. DNAC stores and categorizes software images. It makes recommendations on latest software images based on vulnerabilities. It allows the standardization of software images for devices on the network.

Software Maintenance Update (SMU)

An SMU is a package that provides point fixes and rolls security resolutions to software images that have already been published. DNAC supports SMUs for IOS-XE versions 16.x onwards.

SMUs can be helpful:

  • Due slower upgrade releases especially as software images require bug analysis, extensive testing, certification before official release.
  • Due to faster availability of newer (improved) code to improve device performance or reporting
  • When the time taken to copy images over slower VPN tunnels is significant.
  • If business downtime during image upgrades is not within acceptable time-frames

Images Supported in SWIM

  • Base images: all Cisco IOS, IOS-XE, AireOS, NX-OS images for supported devices
  • Patches: patches (or SMU) are only supported on IOS-XE
  • ROMMON: ROMMON is a firmware image on Cisco devices
  • AP Device Pack (APDP): APDP allows quick support for newer AP outside DNAC release using the patching framework.
  • AP Service Pack (APSP): allows quick support for point patches outside of DNAC release using the patching framework.
  • Sub-package: allows deployment of sub-technologies on devices.

Image Repository

DNAC stores software images and software maintenance updates for the network devices. The image repository provides the following functions:

  • Software images can be pushed to the devices.
  • Stores software images of the devices on the network.
  • Allows the designation of software images as golden. A golden image or SMU is a validated image that meets the compliance requirements of a particular device type. Designating a software image/SMU as golden saves time by eliminating the need to make repetitive configuration changes and ensures consistency across devices.

DNAC manages software and VNF (virtualization network functions) images. It also supports the management of third-party images. DNAC image management feature is accessible as a page under the Design module.

The DNA "Image Repository" page displays all images available. The "Delete" icon under "Action" indicates that an image has been downloaded to DNAC.

CCO credentials are the Cisco credentials for downloading firmware. These credentials can be used by DNA to access firmware repository. These credentials are configured in the DNAC "System Settings" page:

The following page displays image details with and without CCO configured:

With CCO configured, additional information about the image is provided compared to images without CCO information. If the CCO credentials are provided, DNAC provides guidance on the latest firmware updates and recommended images for a device.

When downloading image updates, the "Show Tasks" button shows download progress for firmware:

Distribution

DNAC uses the following protocols in their order of preference during the distribution of software images:

  1. HTTPS
  2. SCP
  3. SFTP

SWIM Times

Latency Should be less than 200ms between DNAC and the network devices
Distribution server DNAC internal storage or remote file server particularly for geo-dispersed sites.
Protocol HTTPS over SCP and SFTP
Software Version The software image to be upgraded may impact the upgrade process. The duration in the process for IOS-XE 17.3 is as follows:
  • Distribution for a single device: ~5 mins
  • Activation for single device: ~8 mins
  • Distribution and activation for stack: ~50 mins

SWIM Recommendations

  • Distribute the software images first well ahead of the activation window.
  • Leverage remote distribution support from Cisco DNA center for large geo-dispersed sites.
  • If upgrading software images on a large number of devices, upgrade up to 500 devices at once. DNAC does the upgrade in a rolling batch of 100 each. Devices are upgraded as rolling list of 40 concurrent threads.

Image Upgrade

The image upgrade process in DNAC is a granular one. It supports image distribution and activation at once on demand. It allows the scheduling of these activities on individual time-frames to go hand-in-hand with the organization's maintenance windows. DNAC regularly monitors the network for compliance with the standardized images and raises notifications for devices with images that deviate from the set standards. DNAC makes pre and post installation/upgrade checks to ensure that integrity of the network is intact.

Most of these steps happen automatically

  1. Import Image/SMU: DNAC can be pointed to the Cisco firmware download page. This will require the integration of image repository management with Cisco where you provide DNAC with the required credentials to download the firmware. Image management integration with Cisco involves accepting the EULA agreement to unlock further image details:
    • Get access to field notices and release notes.
    • Get Cisco recommended image information.
    • Get Cisco latest image information.
  2. Assign Image to a device family: so that the image is available to that device family.
  3. Define Golden image by device family: label a specific image as the golden image for that device family.
  4. System identifies devices not in compliance: DNAC checks the inventory for all devices that match that device family to establish the devices that are running that image and the ones that are not. DNAC then lets you know which devices are out-of-date.
  5. Precheck validation for disk and memory: checks for hardware requirements for the image upgrade. If any devices do not meet these minimum hardware requirements, the check fails and DNAC generates notification messages and the upgrade will not proceed. These checks are performed by custom Python precheck scripts. If the devices pass the minimum hardware requirements, the device is labelled as outdated and is ready for upgrade. The upgrade can then proceed for the device. The upgrade can be planned to be implemented immediately or at a scheduled time. The image can be pushed to flash memory

Devices requiring image upgrades can be viewed under Provisioning → Inventory → Focus →Software Images. The list of devices in inventory displays devices that require software image updates.

An image update readiness check is performed before the software image image upgrade takes place.

When upgrading software images for wireless infrastructure such as access points, and wireless LAN controllers, the protocol used for transfer of the images is SFTP. Additional support during wireless infrastructure image updates includes:

  • Custom pre/post installation checks
  • Sub-package support
  • Rolling AP upgrade
  • AP pre-download
  • Upgrade of Aire OS/IOS-XE based controllers
  • EWC upgrade workflow
  • APDP updates
  • APSP updates

For wired infrastructure such as switches, routers, firewalls, the following support is provided by DNAC during image upgrade:

  • Protocols used are HTTPS, SCP and SFTP. The default protocol is HTTPS.
  • Sub-package support
  • ROMMON support
  • Patches (SMU) support
  • Custom pre/post checks
  • Distributed SWIM
  • Redundancies: stacks, VSS, SVL
  • ISSU

When an image update has been activated for a device, DNA pushes the image to the device storage and starts the installation of the image. After a device completes an image update, DNA creates a wait period during which it expects the device to reboot and load the updated image. During this wait period, DNA may not update the status of the image on the device until after the wait period expires. DNA then carries out post-installation checks before updating the status in the DNA interface.

Troubleshooting using Cisco DNA Center

DNAC Assurance is the module of DNA that provides support with monitoring and troubleshooting of the network infrastrucure, client devices, and application performance. Most of the discussed features of DNAC assurance are used for troubleshooting purposes.

  • Overall Health: The overall health page is a great starting point for troubleshooting network issues. This displays information learned about the network in the last 3 hours, 24 hours, or 7 days. This data is usually aggregated for the various geographical locations. The scope can be refined for locations, buildings and even floors.
  • Network Health: Get an overview of the health of the network and network devices. Information is displayed in 5-minute intervals over the past 24 hours. Network devices section lists all the devices with the following scores:
    • Critical (1-3): displayed in red.
    • Warning(4-7): displayed in amber/orange
    • No errors(8-10): displayed in green
    • No data(0): displayed in gray
    Clicking each device opens up the device's Device 360 page.
  • Client Health: Client 360 can be used to view all raw telemetry information of the device.
  • Pathtrace: Pathtrace enables graphically seeing the path that applications and services take to reach the destination. Pathtrace is accessible Client 360 and Device 360.
  • Network Time Travel: Can view the past history of device and client network data.
  • Global Issues: Access all issues: open, resolved or ignored. Issues are categorized as:
    • Onboarding: Used to identify issues related to wireless and wired client onboarding.
    • Connectivity: Used to identify issues related to network connectivity, including routing protocols (OSPF [Open Shortest Path First], BGP [Border Gateway Protocol]), and tunnels.
    • Connected: Used to identify issues related to clients.
    • Device: Used to identify issues related to the device, such as CPU, memory, fans, and so on.
    • Availability: Used to identify any availability issues related to access points, wireless LAN controllers, and more.
    • Utilization: Used to identify issues related to utilization of access points, wireless LAN controllers, radios, and more.
    • Application: Used to identify issues related to application experience.
    • Sensor Test: Used to identify any global sensor issues.