Cisco SD-WAN IPsec Tunnel Configuration

This blog post describes configuring a site-to-site IPsec VPN tunnel from a Cisco SD-WAN IOS-XE-based router to a non-SD-WAN device.

How to enable configure Cisco SD-WAN IPsec Tunnels to a non-SD-WAN device? In Cisco SD-WAN template-based deployment, IPsec tunnels are configured via the Cisco VPN Interface IPsec feature template. This template is then applied to the Transport VPN (0) or one of the Service VPNs.

Cisco SD-WAN IPSec Tunnels Step-by-step

Figure 1. Configuration Map: Elements Diagram
Figure 1. Configuration Map: Elements Diagram

The logical elements required to be configured shown in Figure 1. All pre-configured elements have check mark symbols next to them.

In our example, the edge device has a device template attached with basic configuration applied, such as system and transport interfaces, sufficient for the router to have control connections to the controllers.

The device template uses a service VPN, which is described by the Cisco VPN feature template. This type of template, despite its name, is not related to IPsec VPN settings. Cisco VPN feature template defines VRF settings and is a container for routing and participating interface information. In our example, the user-facing interface is assumed to be configured and associated with the VRF.

While it is possible to configure all child templates from within the device template, in our example, we will pre-configure child feature templates first and then select them in the device template.

Create and Configure Cisco VPN Interface IPsec Feature Template

The first two steps deal with configuration of IPsec feature template.

Figure 2. Configuration Map: Cisco VPN Interface IPsec Feature Template
Figure 2. Configuration Map: Cisco VPN Interface IPsec Feature Template

Step 1. Create feature template

  • Select Configuration section of the side menu
  • Click on Templates
  • Click on the Feature tab
  • Click on Add Template button
  • Select model of devices that this feature template will be applied
  • Select Cisco VPN Interface IPsec
Figure 3. Create new feature template in vManage
Figure 3. Create new feature template in vManage

Step 2. Configure feature template

Customize IPSec tunnel parameters. There are 5 sections in IPsec template:

  • Basic configuration, such as name and IP address of the tunnel interface and its underlying source (local router) and destination (remote router)
  • Dead-peer detection settings
  • IKE or Phase 1 parameters
  • IPSEC or Phase 2 parameters
  • Advanced Settings

SD-WAN requires an IP-numbered interface (/30) and supports route-based tunnels known as VTI (Virtual Template Interface) in Cisco IOS documentation.

Instead of specifying interesting traffic using ACL known as policy-based tunnels, route-based tunnels use static or dynamic routing over a tunnel interface.

Figure 4. Configure feature template in vManage
Figure 4. Configure feature template in vManage

As figure 4 shows, there are various options available for both IKE and IPSEC security parameters. These need to match between tunnel endpoints.

Adjust device template to use IPsec Feature Template

Figure 5. Configuration Map: Device Template reference to IPsec Interface Feature Template
Figure 5. Configuration Map: Device Template reference to IPsec Interface Feature Template

Step 3. Add feature template to the device template.

IPsec interface template can now be attached to the service VPNs. Figure 6 shows how to modify the existing device template.

Figure 6. Add IPsec template to service-side VPN.
Figure 6. Add IPsec template to service-side VPN.

Routing Configuration

Figure 7. Configuration Map: Static Routes over IPsec interface
Figure 7. Configuration Map: Static Routes over IPsec interface

Step 4. Set-up routing over the tunnel. This can be static or dynamic-routing protocol-based. In the screenshot below, the static route configuration is shown.

Figure 8. Configure routing over IPsec tunnels
Figure 8. Configure routing over IPsec tunnels

Step 5. Test the tunnel.

As the tunnels are VTI-based and have Layer 3 addresses on both sides, the simplest test is to ping the remote side of the tunnel.

There is limited information available via real-time monitoring using vManage web interface. Native SD-WAN tunnels are also IPSec-based. These tunnels have centralized authentication and key management done by OMP instead of IKE/ISAKMP protocols used in non-SD-WAN tunnels. Real-time device options that contain string IKE in their name will be relevant to us in the context of this article.

Figure 9. Validate IKE tunnel status
Figure 9. Validate IKE tunnel status

Using SSH connection to the router these 2 commands can be used to check operational details of the tunnel:

  • show crypto isakmp sa / show crypto ikev2 sa
  • show crypto ipsec sa

We will demonstrate output of these commands in the practical example below.

Cisco SD-WAN IPSec Tunnels Example

Now it’s time for a practical example. We will establish an IPsec tunnel to a Cisco IOS-XE router configured to match VPN gateways settings in public clouds. For example, AWS provides sample configuration files for different platforms (see this URL). We will apply configuration from the Cisco IOS sample, and we can assume that if our router can work with it, it will work with a real AWS gateway. The configuration is slightly adjusted to use IKEv2 by replacing all isakmp commands with IKEv2-variants.

Figure 10 Cisco SD-WAN IPSec Tunnel Lab Diagram
Figure 10 Cisco SD-WAN IPSec Tunnel Lab Diagram

External router configuration

Non SD-WAN router shown on the top in figure 10 has the following configuration:

interface GigabitEthernet2
 ip address 5.5.5.10 255.255.255.0

ip route 0.0.0.0 0.0.0.0 5.5.5.1

crypto ikev2 keyring KEYRING-1
 peer 21.1.1.2
  address 21.1.1.2
  pre-shared-key cisco

crypto ikev2 proposal IKE-PROPOSAL-1 
 encryption aes-cbc-256
 integrity sha1
 group 16

crypto ikev2 policy IKE-POLICY-1 
 match address local 5.5.5.10
 proposal IKE-PROPOSAL-1

crypto ikev2 profile IKE-PROFILE-1
 match address local interface GigabitEthernet2
 match identity remote address 21.1.1.2 255.255.255.255 
 authentication remote pre-share
 authentication local pre-share
 keyring local KEYRING-1

crypto ipsec transform-set TRANSFORM-SET esp-256-aes esp-sha-hmac 
 mode tunnel

crypto ipsec profile IPSEC-PROFILE-1
 set security-association lifetime kilobytes 102400000
 set transform-set TRANSFORM-SET
 set ikev2-profile IKE-PROFILE-1

interface Tunnel0
 ip address 169.254.23.2 255.255.255.252
 ip tcp adjust-mss 1400
 tunnel source GigabitEthernet2
 tunnel mode ipsec ipv4
 tunnel destination 21.1.1.2
 tunnel protection ipsec profile IPSEC-PROFILE-1

ip route 192.168.22.0 255.255.255.0 Tunnel0

SD-WAN configuration

We followed the same steps described in the first part of the article to configure vManage. To make it easier to follow, the majority of parameters are hardcoded into the template. In a real deployment, per-device variables can be used to allow for template re-use.

Figure 11 Cisco SD-WAN IPSec Feature Template Configuration
Figure 11 Cisco SD-WAN IPSec Feature Template Configuration

Then the feature template was added to the device template under VPN 1 section (see Figure 6 above) and route to 192.168.15.0/24 was added to VPN 1 feature template (see Figure 8).

Testing and Validation

Let’s assume that we have access only to the SD-WAN router, and testing will be done only from one side of the connection. We will use the router’s command-line interface via SSH from the vManage web console, as it gives access to information not available via the web interface.

The first test that we perform is checking if the remote side of the tunnel is reachable. The “vrf 1” parameter makes sure that the router uses the correct interface.

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

If ping responses are not received, we can run “show crypto ikev2 sa” and “show crypto ipsec sa” commands. The first command displays if the IKEv2 security association is established, which is a prerequisite for IPSEC security associations. The troubleshooting should start here. If IKEv1 is used, the command is “show crypto isakmp sa.”

CSR01#show crypto ikev2 sa
  IPv4 Crypto IKEv2  SA 
 Tunnel-id Local                 Remote                fvrf/ivrf            Status 
 1         21.1.1.2/500          5.5.5.10/500          none/1               READY  
       Encr: AES-CBC, keysize: 256, PRF: SHA1, Hash: SHA96, DH Grp:16, Auth sign: PSK, Auth verify: PSK
       Life/Active Time: 86400/545 sec
 IPv6 Crypto IKEv2  SA 

We were running ping of the tunnel interface in our example, which is directly connected to both routers. This test might be successful; however, the connectivity between devices behind the tunnel gateways may still not work.

In this case, we can use the “show crypto ipsec sa” command. It displays a set of counters for the number of encrypted and decrypted packets. 

If the encrypted packets count is not increasing, that usually suggests a local routing problem when traffic is not being sent out of the tunnel interface.

If the encrypted packets count does increase but decrypted doesn’t, it can mean that the remote router has routing misconfiguration.

CSR01#show crypto ipsec sa
 interface: Tunnel100001
     Crypto map tag: Tunnel100001-head-0, local addr 21.1.1.2
 protected vrf: 1
    local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
    remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
    current_peer 5.5.5.10 port 500
      PERMIT, flags={origin_is_acl,}
     #pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
     #pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5
     #pkts compressed: 0, #pkts decompressed: 0
     #pkts not compressed: 0, #pkts compr. failed: 0
     #pkts not decompressed: 0, #pkts decompress failed: 0
     #send errors 0, #recv errors 0
 <output truncated>

There are some useful debug commands available, such as “debug crypto ikev2”. It can generate extensive output on a router with multiple tunnels, so be careful not to overload the production router. In the example below, we’ve changed the key on the other side of the tunnel to break the tunnel. Auth exchange failed message is logged, suggesting that we have mismatched keys and “show crypto ikev2” will not display any tunnels.

CSR01#debug crypto ikev2
 Payload contents: 
  VID IDi AUTH SA TSi TSr NOTIFY(INITIAL_CONTACT) NOTIFY(SET_WINDOW_SIZE) NOTIFY(ESP_TFC_NO_SUPPORT) NOTIFY(NON_FIRST_FRAGS) 
 *Jul 10 00:46:36.630: IKEv2:(SESSION ID = 2,SA ID = 1):Sending Packet [To 5.5.5.10:500/From 21.1.1.2:500/VRF i0:f0] 
 Initiator SPI : EE7E2D729412F370 - Responder SPI : B37D8CA8BAB8C150 Message id: 1
 IKEv2 IKE_AUTH Exchange REQUEST 
 Payload contents: 
  ENCR 
 *Jul 10 00:46:36.633: IKEv2:(SESSION ID = 2,SA ID = 1):Received Packet [From 5.5.5.10:500/To 21.1.1.2:500/VRF i0:f0] 
 Initiator SPI : EE7E2D729412F370 - Responder SPI : B37D8CA8BAB8C150 Message id: 1
 IKEv2 IKE_AUTH Exchange RESPONSE 
 Payload contents: 
  NOTIFY(AUTHENTICATION_FAILED) 
 *Jul 10 00:46:36.633: IKEv2:(SESSION ID = 2,SA ID = 1):Process auth response notify
 *Jul 10 00:46:36.633: IKEv2-ERROR:(SESSION ID = 2,SA ID = 1):
 *Jul 10 00:46:36.633: IKEv2:(SESSION ID = 2,SA ID = 1):Auth exchange failed
 *Jul 10 00:46:36.633: IKEv2-ERROR:(SESSION ID = 2,SA ID = 1):: Auth exchange failed
 *Jul 10 00:46:36.633: IKEv2:(SESSION ID = 2,SA ID = 1):Abort exchange
 *Jul 10 00:46:36.633: IKEv2:(SESSION ID = 2,SA ID = 1):Deleting SA
 CSR01# show crypto ikev2 sa
 CSR01#

And finally we can perform end to end test from the test machines using ping and tracert commands.

Figure 12 End-to-end testing
Figure 12 End-to-end testing

Cisco IP SLA IOS-XE

Cisco IP Service Level Agreements (SLAs) is a proprietary feature available on Cisco routers and switches, which actively generates monitoring traffic, processes replies, and measures network performance.

This feature can be used to perform continuous end-to-end connectivity testing with automated re-routing over failover links. It can also simulate different application behavior, such as voice and video to check if the network provides the expected level of service.

The examples and features described in this article are based on Cisco IOS-XE version 16.9.

Configuration Components

IP SLA configuration starts with defining an SLA operation and then scheduling it to run immediately or at a specific time.

SLA Operation Definition

To create or edit an SLA operation use the “ip sla <operation-id>” global configuration mode command. It places CLI into the IP SLA configuration sub-mode, where you can select one of the IP SLA types and provide corresponding configuration parameters.

One of the simplest types of IP SLA operations is icmp-echo. The router pings a specified IP address and records round-trip times if the remote side is reachable. In the example below, we will set the type of SLA entry as ICMP echo with the destination’s IP address of 10.0.3.1. The sample topology is shown in Figure 1.

Figure 1. IP SLA Test Topology
Figure 1. IP SLA Test Topology

The configuration mode changes to IP SLA echo where you can adjust different optional parameters, such as request sending frequency and timeout for replies.

X(config)#ip sla 1 
X(config-ip-sla)# icmp-echo 10.0.3.1 source-ip 10.0.0.1
X(config-ip-sla-echo)#?
IP SLAs Icmp Echo Configuration Commands:
  data-pattern       Data Pattern
  default            Set a command to its defaults
  exit               Exit operation configuration
  frequency          Frequency of an operation
  history            History and Distribution Data
  no                 Negate a command or set its defaults
  owner              Owner of Entry
  request-data-size  Request data size
  tag                User defined tag
  threshold          Operation threshold in milliseconds
  timeout            Timeout of an operation
  tos                Type Of Service
  verify-data        Verify data
  vrf                Configure IP SLAs for a VRF

Scheduling IP SLA

Once SLA is defined and optional parameters are specified, start it by running the “ip sla schedule <id>” command. IP SLA can be configured to start at a specific time or as soon as the command is entered, which is shown in the example below.

X(config)#ip sla schedule 1 start-time now life forever

To check SLA operation’s details use the “show ip sla statistics <id> details” command.

X#show ip sla statistics 1 details 
IPSLAs Latest Operation Statistics

IPSLA operation id: 1
        Latest RTT: 1 milliseconds
Latest operation start time: 10:08:18 UTC Sat Jan 30 2021
Latest operation return code: OK
Over thresholds occurred: FALSE
Number of successes: 2
Number of failures: 0
Operation time to live: Forever
Operational state of entry: Active
Last time this entry was reset: Never

To see configuration details, including default values for various parameters, use the “show ip sla configuration” command.

X#show ip sla configuration  
IP SLAs Infrastructure Engine-III
Entry number: 1
Owner: 
Tag: 
Operation timeout (milliseconds): 5000
Type of operation to perform: icmp-echo
Target address/Source address: 10.0.3.1/10.0.0.1
Type Of Service parameter: 0x0
Request size (ARR data portion): 28
Data pattern: 0xABCDABCD
Verify data: No
Vrf Name: 
Schedule:
   Operation frequency (seconds): 60  (not considered if randomly scheduled)
   Next Scheduled Start Time: Start Time already passed
   Group Scheduled : FALSE
   Randomly Scheduled : FALSE
   Life (seconds): Forever
   Entry Ageout (seconds): never
   Recurring (Starting Everyday): FALSE
   Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
   Number of statistic hours kept: 2
   Number of statistic distribution buckets kept: 1
   Statistic distribution interval (milliseconds): 20
Enhanced History:
History Statistics:
   Number of history Lives kept: 0
   Number of history Buckets kept: 15
   History Filter Type: None

Once SLA operation is scheduled, it cannot be modified. Instead, the old operation can be deleted, and then a new one created again using the same ID.

Different IP SLA Types

To view available types of SLA operations, use context-sensitive help as shown in the next example.

X(config-ip-sla)#?
IP SLAs entry configuration commands:
  dhcp         DHCP Operation
  dns          DNS Query Operation
  ethernet     Ethernet Operations
  exit         Exit Operation Configuration
  ftp          FTP Operation
  http         HTTP Operation
  icmp-echo    ICMP Echo Operation
  icmp-jitter  ICMP Jitter Operation
  mpls         MPLS Operation
  path-echo    Path Discovered ICMP Echo Operation
  path-jitter  Path Discovered ICMP Jitter Operation
  tcp-connect  TCP Connect Operation
  udp-echo     UDP Echo Operation
  udp-jitter   UDP Jitter Operation

The next subsections will review some of them.

Jitter operations

Jitter is a variation in the delay between packets. The smaller the jitter the better performance of time-sensitive applications such as voice. It also means that the network delivers packets with a predictable delay and doesn’t experience congestions causing intermittent delays along the paths.

There are 2 types of SLA operations performing Jitter measurements – ICMP and UDP-based.

ICMP Jitter

ICMP Jitter SLA operation is based on ICMP message types (Timestamp Request and Timestamp Reply). The destination can be any device that supports these ICMP messages. Not all devices support it, or it can be blocked by the firewalls. The previously shown ICMP Echo operation is based on more commonly used Echo and Reply message types.

The configuration in the example below demonstrates how to configure ICMP jitter operation and, that once launched, it reports the round-trip-time (RTT) and jitter statistics from the source to the destination, and vice versa.

X(config)# ip sla 2 
X(config-ip-sla)# icmp-jitter 10.0.3.1 source-ip 10.0.0.1
X(config)# ip sla schedule 2 start-time now life forever

X#show ip sla statistics 2
IPSLAs Latest Operation Statistics

IPSLA operation id: 2
Type of operation: icmp-jitter
        Latest RTT: 1 milliseconds
Latest operation start time: 00:20:39 UTC Sun Jan 31 2021
Latest operation return code: OK
RTT Values:
        Number Of RTT: 10               RTT Min/Avg/Max: 1/1/1 milliseconds
Latency one-way time:
        Number of Latency one-way Samples: 0
        Source to Destination Latency one way Min/Avg/Max: 0/0/0 milliseconds
        Destination to Source Latency one way Min/Avg/Max: 0/0/0 milliseconds
Jitter Time:
        Number of SD Jitter Samples: 9
        Number of DS Jitter Samples: 9
        Source to Destination Jitter Min/Avg/Max: 0/1/1 milliseconds
        Destination to Source Jitter Min/Avg/Max: 0/1/1 milliseconds
Over Threshold:
        Number Of RTT Over Threshold: 0 (0%)
Packet Late Arrival: 0
Out Of Sequence: 0
        Source to Destination: 0        Destination to Source 0
        In both Directions: 0
Packet Skipped: 0       Packet Unprocessed: 0
Packet Loss: 0
        Loss Periods Number: 0
        Loss Period Length Min/Max: 0/0
        Inter Loss Period Length Min/Max: 0/0
Number of successes: 4
Number of failures: 0
Operation time to live: Forever

To measure jitter, a source router sends a number of packets (10, by default) periodically. The time between these packets is called interval (20ms). The operation is repeated at a specified frequency (60 seconds by default).

The example below shows default configuration values – every 60 seconds the router will send 10 packets with 20 milliseconds interval between each packet.

X#show ip sla configuration 2
IP SLAs Infrastructure Engine-III
Entry number: 2
Owner: 
Tag: 
Operation timeout (milliseconds): 5000
Type of operation to perform: icmp-jitter
Target address/Source address: 10.0.3.1/10.0.0.1
Packet Interval (milliseconds)/Number of packets: 20/10
Type Of Service parameter: 0x0
Vrf Name: 
Schedule:
   Operation frequency (seconds): 60  (not considered if randomly scheduled)
<output is truncated>

UDP Jitter and IP SLA responder

UDP is used in voice and video communications. Using UDP traffic for measurements suits better to simulate such applications. In an IP SLA operation configuration codec type can be specified, and this will define packet size and enable various voice-specific metric calculations, such as Mean Opinion Score (MOS).

Figure 2. IP SLA Responder Configuration
Figure 2. IP SLA Responder Configuration

To use the UDP Jitter destination device must also be a Cisco device with an IP SLA responder feature enabled on it. The responder’s basic configuration is completed with the single command on router Z:

Z(config)#ip sla responder

Back on the router X, IP SLA configuration is done per the example below.

X(config)#ip sla 3
X(config-ip-sla)#udp-jitter 10.0.3.1 2345 source-ip 10.0.0.1
X(config)#ip sla schedule 3 start-time now life forever
X#show ip sla statistics 
IPSLAs Latest Operation Statistics

IPSLA operation id: 3
Type of operation: udp-jitter
        Latest RTT: 1 milliseconds
Latest operation start time: 05:53:56 UTC Sun Jan 31 2021
Latest operation return code: OK
RTT Values:
        Number Of RTT: 10               RTT Min/Avg/Max: 1/1/1 milliseconds
Latency one-way time:
        Number of Latency one-way Samples: 0
        Source to Destination Latency one way Min/Avg/Max: 0/0/0 milliseconds
        Destination to Source Latency one way Min/Avg/Max: 0/0/0 milliseconds
Jitter Time:
        Number of SD Jitter Samples: 9
        Number of DS Jitter Samples: 9
        Source to Destination Jitter Min/Avg/Max: 0/1/1 milliseconds
        Destination to Source Jitter Min/Avg/Max: 0/1/1 milliseconds
Over Threshold:
        Number Of RTT Over Threshold: 0 (0%)
Packet Loss Values:
        Loss Source to Destination: 0
        Source to Destination Loss Periods Number: 0
        Source to Destination Loss Period Length Min/Max: 0/0
        Source to Destination Inter Loss Period Length Min/Max: 0/0
        Loss Destination to Source: 0
        Destination to Source Loss Periods Number: 0
        Destination to Source Loss Period Length Min/Max: 0/0
        Destination to Source Inter Loss Period Length Min/Max: 0/0
        Out Of Sequence: 0      Tail Drop: 0
        Packet Late Arrival: 0  Packet Skipped: 0
Voice Score Values:
        Calculated Planning Impairment Factor (ICPIF): 0
        Mean Opinion Score (MOS): 0
Number of successes: 1
Number of failures: 0
Operation time to live: Forever

Path operations

When measuring latency between two hosts it is useful to know how much delay is contributed by each hop along the path. Path-type SLAs work by running traceroute first and then performing echo or jitter operation against each discovered hop.

X(config)#ip sla 4
X(config-ip-sla)#path-echo 10.0.3.1 source-ip 10.0.0.1
X(config)#ip sla schedule 4 start-time now life forever

The configuration is based on the same network topology with 2 paths available to the destination.

Figure 3. IP SLA Path Operations
Figure 3. IP SLA Path Operations

The “show ip sla statistics aggregated 4 details” command will display round-trip time statistics for each hop. For example, the command output below shows statistics for the first hop in the path going via router B. The remaining hops statistics are omitted in the example below.

X#show ip sla statistics aggregated 4 details 
IPSLAs aggregated statistics

Distribution Statistics:
Bucket Range: 0 to < 20 ms
Avg. Latency: 1 ms
Percent of Total Completions for this Range: 100 %
Number of Completions/Sum of Latency: 1/1 
Sum of RTT squared low 32 Bits/Sum of RTT squared high 32 Bits: 1/0
Operations completed over threshold: 0
Start Time Index: *09:54:47.234 UTC Tue Feb 2 2021
Path Index: 3
Hop in Path Index: 1
Type of operation: path-echo
Number of successes: 18
Number of failures: 0
Number of over thresholds: 0
Failed Operations due to Disconnect/TimeOut/Busy/No Connection: 0/0/0/0
Failed Operations due to Internal/Sequence/Verify Error: 0/0/0
Failed Operations due to Control enable/Stats retrieve Error: 0/0
Target Address 172.16.100.6
<output is truncated>

Other operations

IP SLA can perform application-specific monitoring, for example, it can run HTTP or FTP operations against a remote server. For generic TCP applications, TCP operation can be used, which validates if the TCP connection can be established and how long it takes to connect to the server.

The other available operation types are DHCP (checks how long it takes to obtain an IP address) and DNS queries.

Reactions and Proactive Monitoring

In the previous sections, we’ve reviewed different types of SLA operations and how to check their operations using CLI. By using SNMP-based monitoring software, administrators can poll SLA data from routers periodically, which is a more scalable approach to monitoring. Cisco provides SNMP MIB called RTTMON that provides access to IP SLAs from monitoring software.

It is also possible for a router to send an SNMP trap or Syslog message if a certain event happens. IP SLA includes a feature called proactive threshold monitoring. To enable it IP SLA reaction must be configured.

SLA reaction configuration command references an IP SLA operation and has a mandatory parameter specifying what monitored element of SLA we want to monitor. For example, this can be a timeout or threshold-based value. Available monitored elements vary based on the type of IP SLA operation. A compatibility table is available on this page. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipsla/configuration/xe-16-9/sla-xe-16-9-book/sla-threshold-mon.html

The example below uses a previously configured IP SLA operation of icmp-echo type.

ip sla 1
 icmp-echo 10.0.3.1 source-ip 10.0.0.1
ip sla schedule 1 life forever start-time now

The reaction configuration below references SLA operation 1 and selects timeout as a monitored element. Then we enable simple SNMP configuration to send a trap when operations times out.

X(config)#ip sla reaction-configuration 1 react timeout action-type trapOnly threshold-type immediate
X(config)#snmp-server enable traps ipsla
X(config)#snmp-server host 10.0.0.5 PUBLIC

To test it, I’ve turned off the interface on router Z and enabled debug of SNMP packets to confirm that SNMP traps were generated by the router.

X#debug snmp packets
*Feb  4 09:41:49.232: SNMP: Queuing packet to 10.0.0.5
*Feb  4 09:41:49.232: SNMP: V1 Trap, ent rttMonNotificationsPrefix, addr 10.0.0.1, gentrap 6, spectrap 2 
 rttMonCtrlAdminTag.1 =  
 rttMonHistoryCollectionAddress.1 = 0A 00  03 01    
 rttMonCtrlOperTimeoutOccurred.1 = 2
<output is truncated>

Enhanced Object Tracking

The final section of this document addresses how a router can change its data plane operation in response to IP SLA operational status.

The feature responsible for translating the status of IP SLA operations to the data plane protocols is called Enhanced Object Tracking. First-Hop Redundancy Protocols, such as HSRP and VRRP use the tracking objects to take over or release data forwarding roles. Static and policy-based routing can also use the tracking objects to re-route around degraded paths.

EEM (Embedded Event Manager) scripts can monitor tracking object’s status changes. This makes it possible to run powerful EEM scripting in response to track status change.

A Track object can have 2 states – Up and Down. IP SLA operations can have several return codes. For the purpose of object tracking, we are interested in the 3 return codes discussed below. All other codes that are not covered in this article translate into the Down state of the Track object.

Let’s re-use the IP SLA ICMP Echo operation from the previous example and check the code of the operation. The second command in the listing shows how to check the default threshold (5000ms):

X#show ip sla statistics 1 | incl code           
Latest operation return code: OK
X#show ip sla configuration 1 | include Threshold
Threshold (milliseconds): 5000

The operation’s return code is OK, which means that the ping operation is successful and its round-trip time is within the threshold (in our network it is 1ms). OK status always translates to the UP state of the corresponding track object.

If we will turn off the remote interface on router Z, the return code will change to Timeout, as per the listing below. This is the second SLA operation code, which always translates into the Down state of the Track object.

X#show ip sla statistics 1 | incl code
Latest operation return code: Timeout

The third code that is relevant for the purpose of track operation is OverThreshold. To demonstrate it, we increased the request data size to 5000 bytes, so the operation takes longer than 1ms. We also decreased the threshold to 1ms, so the operation goes over the threshold.

The OverThreshold code translates differently to the track object state, which we will discuss in the next section.

X(config)#ip sla 2
X(config-ip-sla)#icmp-echo 10.0.3.1 source-ip 10.0.0.1
X(config-ip-sla-echo)# request-data-size 5000
X(config-ip-sla-echo)# threshold 1
X(config)#ip sla schedule 2 start-time now life forever

X#show ip sla statistics 2               
IPSLAs Latest Operation Statistics

IPSLA operation id: 2
        Latest RTT: 2 milliseconds
Latest operation start time: 09:44:48 UTC Sat Feb 6 2021
Latest operation return code: Over threshold
Number of successes: 2
Number of failures: 0
Operation time to live: Forever

IP SLA Track State vs. Reachability

track <id> ip sla <sla-id>” command creates a track object that references SLA operation. There are 2 types of track objects for SLA – reachability, and state. Let’s configure both types against the previously configured SLA 2 to see the difference.

X(config)#track 1 ip sla 2 reachability
X(config)#track 2 ip sla 2 state

X#show track 
Track 1
  IP SLA 2 reachability
  Reachability is Up
    1 change, last change 00:00:29
  Latest operation return code: Over threshold
  Latest RTT (millisecs) 2
Track 2
  IP SLA 2 state
  State is Down
    1 change, last change 00:00:17
  Latest operation return code: Over threshold
  Latest RTT (millisecs) 2

Track 1 is based on reachability and it is UP, even when the underlying IP SLA object is over the threshold. As the name suggests, we only interested in the fact that we can reach the remote side of the connection. Track 2 is state-based and it returns DOWN for the same IP SLA object. Track of the state type checks both reachability and that the IP SLA object is under the specified threshold.

Static Routes

The next listing demonstrates how to use the track objects with static routes:

X(config)#ip route 0.0.0.0 0.0.0.0 172.16.100.2 track 1 200
X(config)#ip route 0.0.0.0 0.0.0.0 172.16.100.6 track 2

X#sh ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "static", distance 200, metric 0, candidate default path
  Routing Descriptor Blocks:
  * 172.16.100.2
      Route metric is 0, traffic share count is 1

The route via 172.16.100.6 is the preferred, as it has the default administrative distance of 1. The route via 172.16.100.2 is a backup route with an administrative distance of 200. However, the route table shows that the router prefers the route via 172.16.100.2.

For a route to be installed into the routing table the corresponding track must be UP. Because track object #2 is Down, the static route via 172.16.100.6 is withdrawn and the backup route is chosen and installed into the routing table.

EEM Scripts with IP SLA

The final example of this article is an EEM (Embedded Event Manager) script that adjusts the router configuration, generates a Syslog message in response to the Track state change.

The script is triggered when Track object #1 goes down, with the “event track <object-id> state down” command.

The access-list is being adjusted by the script in this example only for demonstration purposes. It can be adjusted to suit real-life requirements. For example, the script can reconfigure VPN tunnel endpoints or enable a backup interface. EEM can perform many other non-CLI actions as well.

X(config)#event manager applet TRACK-1-DOWN 
X(config-applet)#event track 1 state down
X(config-applet)#action 1 cli command "enable"
X(config-applet)#action 2 cli command "conf t"
X(config-applet)#action 3 cli command "ip access-list extended INTERNET-IN"
X(config-applet)#action 4 cli command "permit ip host 1.2.3.4 any"         
X(config-applet)#action 5 syslog msg "TEST Message"

X#show run | section ^ip access-list
<none>

To test the script, I’ve turned off the remote interface on router Z causing IP SLA and track to go down. The router generates a test Syslog message and creates an access-list, as shown in the listing below. “terminal monitor” command displays console messages into VTY lines, such as SSH or Telnet.

X#terminal monitor
*Feb  6 10:13:50.285: %TRACK-6-STATE: 1 ip sla 2 reachability Up -> Down

*Feb  6 10:13:50.530: %HA_EM-6-LOG: TRACK-1-DOWN: TEST Message

X#sh run | section ^ip access-list
ip access-list extended INTERNET-IN
 permit ip host 1.2.3.4 any

Cisco DNA Center

This article describes the role and functions of Cisco DNA Center in the context of CCNA exam blueprint requirements.

Relevant CCNA exam topics are available here:

  • Explain the role and function of network components: Controllers (Cisco DNA Center and WLC*)
  • Compare traditional campus device management with Cisco DNA Center enabled device management

* Wireless LAN Controllers functions were discussed in the blog post dedicated to wireless devices, however, this article will use WLCs along with other types of controllers for comparison.

DNA Center Overview

Cisco DNA Center is a management software and a controller for SD-Access. At the time of the writing, it is available only as a hardware appliance. DNA Center is positioned in Cisco’s product line as the replacement for Cisco APIC-EM. It can also replace Cisco Prime Infrastructure.

There are 3 available options of hardware appliances to choose from:

  • DN2-HW-APL (C220 M5, 44 cores) – up to 1000 devices
  • DN2-HW-APL-L (C220 M5, 56 cores) – up to 2000 devices
  • DN2-HW-APL-XL (C480 M5, 112 cores) – up to 5000 devices

Cisco supports a single node deployment or a cluster of 3 appliances for high availability.

DNA Center can operate with 2 types of networks:

  • Traditional campus networks
  • SD-Access fabric

Traditional Networks

DNA Center can work with non-SD-Access networks similar to traditional network management software. Policy-driven automation is available in this mode, but it is optional. Assurance and analytics functionality can be opened with even only read-only access to the network and provide a safe way to get familiar and to evaluate DNA Center’s features.

SD-Access Fabric

Cisco introduced a new paradigm for medium- to large- size enterprise networks called intent-based networking. In this architecture, an administrator communicates intent to the controller or requesting “what” he wants to achieve. He doesn’t need to specify device-specific instructions (“how?”) for the changes to be applied. A controller accepts instructions from an administrator via GUI or from an application via API and then applies configuration to the devices it controls.

Software-Defined Access or SD-Access is an implementation of this paradigm. We’ve published an article called SD-Access Components and it explains functions of DNA Center only briefly; this blog post is expanding its coverage. SD-Access has multiple underlying protocols to provide scalable and flexible, but relatively complex virtualized network infrastructure. DNA Center is the key that hides the complexity by providing a level of abstraction that allows network operators to focus their attention on more high-level configuration concepts, such as policies.

Role in the network

In SD-Access fabric, DNA Center plays a more essential role compared to one in the non-SDA network. With SD-Access fabric, while the underlay network can be built manually, the overlay networks are created and operated via DNA Center. In the traditional network, an administrator can decide which tasks should be performed by DNA Center and which ones are to be done directly on the device.

DNA Center has ability to perform many tasks in the network lifecycle:

  • Day 0. Onboarding and discovery. During this stage DNA Center can be used for zero-touch provisioning (ZTP) with Plug and Play (PnP) protocol
  • Day 1. Provisioning. Policy-based templates can be defined and applied to multiple devices grouped into a hierarchy of sites
  • Day 2, N. Operation via policy configuration, monitoring, troubleshooting, and software patching. DNA Center has multiple features simplifying network operations tasks, including, Software and Image Management, zero-touch RMA

Controller operations

Management plane

A network controller can use many protocols to interact with the network devices and this communication is referred to as Southbound connectivity. DNA Center can use multiple management protocols, for example, CLI, Netconf or SNMP. To provide some comparison with other controllers – Cisco SD-WAN uses Netconf to push configuration from vManage to vEdge devices and Cisco WLC uses CAPWAP protocol to communicate with access points.

End devices, such as switches and routers run normal IOS-XE software. Their configuration mode can be accessed locally and changes pushed from DNA Center can be observed via a device’s configuration files.

Control plane

Cisco DNA Center in both modes of operations is distributed across switches, access points and routers. It keeps the network devices in charge of their control plane operation. The network will continue to function if the DNA Center appliance is not reachable. For example, it doesn’t participate in dynamic route propagation or reflection, as vSmarts in SD-WAN.

Data plane

Cisco DNA Center doesn’t perform transit data forwarding functions. In comparison, Cisco Wireless LAN Controller can switch traffic in certain deployment modes.

Features and Functions

DNA Center functions and features can be divided into 4 groups, as shown in Figure 1.

Figure 1. DNA Center Features and Functions
Figure 1. DNA Center Features and Functions

Automation

This group of features is responsible for performing operational and provisioning tasks without applying the configuration manually to the devices. Some of the examples are available below.

Network Design and Profiles

Logical separation of the network into a hierarchy of regions and sites. The profiles, which include common parameters, such as DNS, DHCP server details, are then associated with this logical containers, so all sites under them inherit the settings.

Software Image Management (SWIM)

This feature ensures that consistent software image versions are deployed to devices in the network. DNA Center performs checks prior and post-installation. For example, free space on the flash memory is one of such checks.

Network Plug and Play (PnP)

A very useful feature when the number of deployed devices is high. A device just needs to be plugged in and receive an IP address to receive its configuration automatically. To locate DNA Center several discovery methods are supported, such as using a DHCP option and a DNS name.

QoS Configuration Automation

One of the challenging aspects of the day-to-day operation of the network is QoS policy implementation. Applications on the network can change or new ones are added. If the network is managed manually, keeping configuration up-to-date with properly classified traffic and its preferred treatment can consume a lot of time. Different hardware QoS implementation on different models of devices further increases the complexity.

DNA Center provides an intuitive user interface that allows the administrator to select one of the pre-defined application templates and to choose if its business-relevant or not. Then scope, or which devices should have this policy, is selected and configuration is applied to the network.

Assurance

Another function of a controller is to provide centralized monitoring. DNA Center component responsible for it is called DNA Assurance. It provides many unique features, such as the correlation of different types of information; focused 360 views for the network devices and clients; and retrospective view with Network time travel feature.

Dashboards

There are multiple dashboards available each focusing on different aspects of network health. Performance of business-relevant applications, clients and network devices is monitored and top issues are displayed.

Device 360, Client 360 and Network Time Travel

These features provide a device-centric view of a device or a client. It provides an administrator with ability to quickly access relevant to an endpoint or device information and its health score. For example, it simplifies troubleshooting when a user complains about application performance. By using the search function to quickly locate the user and his device, an administrator can identify if there are issues with the network reachability, such as poor RF signal or packet drops.

It also usually takes some time after an issue occurs and before an administrator starts working on the ticket. By that time, an alert can be cleared out making troubleshooting more difficult. Network Time Travel allows focusing the device view on a specific time in the past (up to 14 days) to see events and alerts that were active at that time.

Path Trace

Path Trace visually displays every device in the path between two IP addresses across the network. It can optionally include information about devices that can be blocking the traffic with access lists, as well as interface and QoS (Quality of Service) statistics.

AI Network Analytics

Analytics powered by Artificial Intelligence/Machine Learning algorithms helps to proactively identify issues. First, the network-specific baseline is gathered and learning occurs. This information is then used to evaluate anomalies to alert the administrator of a possible issue.

SD-Access

This group of functions is specific to SD-Access. Includes functions required to perform the SD-Access controller’s management features for fabric infrastructure and fabric wireless.

Fabric Assurance

DNA Center provides additional monitoring features for fabric, such as the correlation of fabric’s underlay and overlay, reachability between fabric edge, control and border nodes.

Group-based Policy Configuration

DNA Center integrates with Cisco ISE (Identity Service Engine) to enable the use of identity-based policies using Cisco TrustSec. Group-based Policy configuration allows an administrator to configure group and policy management from the user interface of the DNA Center, which then communicates with ISE and fabric.

The main purpose of this feature is to let network devices to infer user identity without relying on IP address or VLAN information mapping. For example, when a user or a device is authenticated with ISE, traffic from this device is marked with a special tag called SGT (Security/Scalable Group Tag). SD-Access places this tag into VXLAN header, so other devices can tell which user or group this datagram belongs to and use this information to apply security and QoS policies.

Platform

In the management plane section, we introduced the concept of Southbound protocols in Software Defined Networks, i.e. from the controller to end devices, such as switches and routers. Northbound protocols, as their name suggests are working in the opposite direction, and are responsible for communication from external services to the controller for 3rd party integration. Cisco DNA Center supports REST (Representational State Transfer) APIs for such integration.

Integration with Service Management Platforms

Cisco DNA Center can be integrated via API with Service Management Platforms. This integration provides the ability to interact with platforms such as ServiceNow. For example, the Software Imaging feature of the DNA Center can log a change request in ServiceNow and perform image push only once it is approved. Another use case can be automated ticket logging when DNA Center discovers an issue.

IPAM Integration

IP Address management provides centralized management of IP pool allocation. Integrating with such a system allows DNA Center to reserve pools for workflows.

Self-test questions

What are 2 types of networks that DNA Center can work with?
• Traditional networks as a management platform

• SD-Access fabric as a controller and a management platform
DNA Center supports Southbound and Northbound protocols. What are they?
• Southbound protocols are responsible for communication from a controller to managed devices

• Northbound protocols or APIs provide access to the controller from external systems

Explain Role and Function of Network Components – Part 3 – Routers, Firewalls, and IPSs

This is the third article about the roles and functions of different network components (clock on the links for the first and second parts). In this part we will discuss operations of devices deployed on the network edge – Routers, Firewalls and Intrusion Protection Systems (IPSs).

Network edge provides connectivity between the company’s branch offices, data centers, remote workers, business partners, and the Internet. These devices must support a variety of transport technologies and provide security services.

There are two main types of edge connectivity:

  • Internet
  • WAN

Internet connectivity due to its public nature needs higher security control and devices such as firewalls, IPSs are usually deployed to enable the perimeter protection. Wide Area Network (WAN) in many environments was traditionally considered as a trusted network with only routers installed at the edge of each campus and branch.

In general, WAN links are more expensive and may not be available at every location. WAN connectivity is usually backed by agreed service level contracts and has guaranteed bandwidth and predictable latency. On the other hand, Internet links are cheap and offer more bandwidth, but no end-to-end service performance guarantees.

VPN tunneling over the Internet is used as a backup WAN connectivity method in many networks. Newer technologies, such as Cisco SD-WAN often use several Internet connections – as primary and backup WAN transport. SD-WAN routers can actively monitor links performance end-to-end and re-route traffic automatically based on the configured policy.

With these trends, the dividing line between WAN and Internet becomes less clear. Implementing security services on SD-WAN routers or installing firewalls behind it can be a reasonable choice.

Routers

The main function of a router is to perform Layer 3 forwarding or in most networks route IP (or IPv6) packets. Routers can run dynamic routing protocols to find the best paths to remote networks.

As we discussed in part 1 of this series, a Layer 3 Switch performs a similar function.

What is the difference between a Layer 3 switch and a router?

Historically, switches performed only Layer 2 functions and routers were responsible for Layer 3 operations. Topologies, such as router on a stick for inter-VLAN routing, were often deployed. Figure 1 displays a sample network demonstrating how the traffic between VLAN 10 and VLAN 20 hairpins via a router.

Figure 1. Router on a stick
Figure 1. Router on a stick

With the introduction of Layer 3 functionality in switches, inter-VLAN routing functionality was moved to them from routers. The term Layer 3 switching is used to describe fast, hardware-accelerated routing.

For example, aggregation-level router, such as Cisco ASR 1002-HX has a performance of up to 78Mpps, which is outperformed by the entry-level Catalyst C9200-24PXG access switch capable of switching up to 262 Mpps (million packets per second).

There is a balance between flexibility and performance. Routers are capable of providing more services and this is the reason they have lower layer 3 processing performance numbers. For example, routers support many types of WAN links (such as DSL variations and 4G LTE), can accept full Internet routing table, provide advanced QoS capability and application awareness, perform firewall zone-based services, establish VPN tunnels, act as voice gateways and many other features.

Cisco website has a tool called Feature Navigator that allows us to look up a feature that a specific platform or software version provides.

Cisco router product portfolio

Cisco routers can be grouped based on the type of location where they are typically deployed:

  • Branch routers: ISR 900, ISR 1000, ISR 4000, Meraki MX
  • WAN aggregation: ASR 1000, NCS 5000/5500
  • Datacenter and clouds: CSR 1000v, Meraki vMX100
  • Service provider routers: ASR 1000, ASR 9000, Cisco 8000 Series

Cisco router software

Previously, all enterprise Cisco routers were running the Cisco IOS software. It is now mostly replaced by IOS-XE. ISR 900 models are the only devices in the current product line that use IOS.

IOS-XE is IOS’s successor and the majority of enterprise-level devices, including ISR 1000, ISR 4000, ASR 1000 and CSR 1000v, are running it. IOS-XE is based on Linux kernel with IOS being a process called IOSd. IOS-XE and IOS share command-line syntax.

Enterprise platforms running IOS-XE can also run the SD-WAN version of the software, which allows the router to be managed by SD-WAN controllers (more information about SD-WAN platforms is available here).

Service provider routers, such as NCS 5000/5500 and ASR 9000 are running IOS XR software.

Self-test question: What are the functions of a router?
• Layer 3 (in most cases IP or IPv6) traffic forwarding
• Maintains remote network reachability information via static configuration or dynamic exchange with other routers
• Supports a wide variety of interfaces, such as Ethernet, DSL, and LTE
• Has application visibility and ability to apply granular Quality of Service policies
• Provides different services, such as VPN, firewall and VoIP services

Firewalls and Intrusion Protection Systems (IPSs)

Let’s start this section by describing the logical functions of a firewall and an intrusion protection system.

Cisco firewall and IPS functions

A firewall evaluates traffic against configured ruleset and then allows or blocks it. A stateful firewall keeps track of allowed connections and can recognize return traffic, i.e. being part of an existing session, so it can be allowed too.

An Intrusion Protection System performs the security policy enforcement on transit traffic by either comparing its content to a set of patterns or by analyzing its behavior. These pre-defined patterns are called signatures and must be regularly updated.

Traditional firewalls and IPSs

Cisco product line used to have two different types of devices – one performing the firewall functions and another one was responsible for intrusion protection. Cisco PIX and its successor ASA (and routers with security feature set enabled) were performing traditional stateful firewall functions. They had some a limited IPS feature set too. However, for the full IDS/IPS functionality, Cisco IPS appliances and hardware modules were required. After SourceFire acquisition, its standalone IPS products were also added to Cisco’s product line.

Cisco provided integration options, however, they were based on two separately managed systems running in parallel. For example, ASA could accept an expansion module providing IPS functionality connected via ASA’s backplane. Later, hardware modules were replaced by virtual software processes using ASA as a host.

Next-Generation firewalls

Many security vendors took an approach of closely integrating both types of features in a single device, which became known as a Next-Generation Firewall (NGFW). Cisco also released a unified software platform that inherited ASA code as a stateful firewall engine and Snort IPS as intrusion protection system. This software is running on the current NGFW platforms and is called Firepower Threat Detection (or FTD).

In addition to stateful firewall and IPS functions, Next-generation firewalls can also provide remote and site-to-site VPN services, malware protection and URL filtering. The intelligence behind FTD NGFW services is provided by Cisco’s TALOS group that collects and analyzes threats to develop definition updates.

All FTD software platforms can be centrally controlled by Firepower Management Center. Smaller models can be configured locally with Web-based Firepower Device Management.

Cisco firewall and IPS product portfolio

Current Cisco’s firewall and IPS product portfolio includes:

  • Firepower 1000/2100 (ASA or FTD image; locally or centrally managed)
  • Firepower 4100/9000 (ASA or FTD image; only central management for FTD)
  • Cisco NGFWv (virtual FTD – hypervisors and public clouds)
  • Cisco ASAv (virtual ASA – hypervisors and public clouds)
  • Cisco NGIPSv (for VMware)
  • ASA 5500-X
  • Meraki MX

Firewall deployment modes

Firewalls and IPSs are typically deployed on the network boundary with external networks, such as the Internet. Cisco NGFWs support 2 deployment modes:

  • Routed
  • Transparent
Figure 2. Firewall Routed vs Transparent Deployment Modes
Figure 2. Routed vs Transparent Deployment Modes

In routed mode, a firewall acts as a Layer 3 device, with each interface is assigned an IP address. Example in Figure 2 has NGFW in the routed mode option on the left. Notice that the workstation uses the INSIDE interface of the firewall as its default gateway.

On the right side, NGFW operates in transparent mode and performs the role of a Layer 2 device. It must be placed between the local network and the router, as there is no explicit configuration on the workstation, such as default gateway configuration to force the traffic to traverse the firewall.

The diagram shows that the transparent firewall is physically connected to the router ensuring that non-local traffic is not able to bypass the firewall.

In cases when such connectivity is not possible, so-called VLAN stitching can be used. To implement it, the connection between the router and the firewall external interface is allocated to different VLANs, which are stitched together by the firewall.

Self-test question: What are the functions of a Next-Gen Firewall?
• Enforce security policy by blocking or allowing packets
• Perform deep packet analysis with application awareness to provide intrusion protection
• Provide additional services, such as VPN, Malware protection and URL filtering
Self-test question: What are two deployment modes of a Next-Gen Firewall?
• Routed mode. In this mode, firewall operates similar to a router and has different IP addresses on interfaces
• Transparent mode. In this mode operates as a network switch and don’t have IP addresses assigned to data interfaces

Explain Role and Function of Network Components – Part 2 – Cisco Access Points and WLCs

This is the second part of the series of articles about the roles and functions of different network components (the first part is available here). In this part, we will discuss the operations of Cisco Wireless Access Points (APs) and Cisco WLAN Controllers (WLCs).  The purpose of this blog post is to explain what a Cisco-based wireless network consists of and how these elements interact with each other.

Wireless Standards

IEEE 802.11 set of standards defines Layer 1 and Layer 2 operations of wireless networks. The latest standard that Cisco Access Points support at the time of writing is 802.11ax (Wi-Fi 6).

IETF’s RFC 5415 standardizes communication protocol between a WLC and an Access Point – Control And Provisioning of Wireless Access Points (CAPWAP).

Access Points (APs)

Wireless clients connect to an Access Point to communicate with each other and with the devices on the wired network that the AP is connected to. Single Access Point forms a BSS (Basic Service Set), which is identified by its MAC address.

Access Point advertises one or many wireless networks identified by an SSID (Service Set ID). A WLAN can be mapped to a VLAN on the wired side of an access point.

ESSID is the same wireless network, as identified by an SSID but advertised by multiple Access Points that are connected to the same wired network.

Models

The current portfolio of Cisco Access Points is represented by:

  • Wi-Fi 6 (802.11ax) models, such as Catalyst 9115, 9117, 9120 and 9130
  • 802.11ac Wave 2 models, such as Aironet 1815, 2800, 3800 and 4800
  • Outdoor and Industrial, such as Aironet 1540, 1552, 1560 and 1570
  • Meraki MR45 and MR55
  • Small Business 100, 300 and 500 series

Cisco website provides a selector tool that performs a side-to-side comparison of different AP and controller models. It can be accessed via this URL.

Autonomous vs Lightweight APs

Access Point’s mode of operations can be either Autonomous or Controller-based. Let’s consider the difference between management, control and data planes for Access Points operating in different modes to understand their functions.

Management Plane

The management plane deals with the static configuration of Access Points. APs in autonomous mode can be managed directly via Web interface or CLI. In contrast, controller-based APs don’t allow direct configuration changes and, instead, are managed by the controller, which provides a centralized interface for an administrator. The controller is not always a dedicated physical or virtual appliance, it can also be cloud-based service (Meraki) or even another access point (Mobility Express and Embedded WLC).

Control Plane

The control plane is responsible for dynamic access point operations, such as radio parameters management and user authentication. Autonomous APs perform all these tasks on their own. Controller-based (or Lightweight) APs shift these tasks to the controller. For example, a controller can instruct access points to change a radio channel and decrease transmit power, as it can make more informed decisions based on data received from several adjacent access points in the network.

Data Plane

The Data plane is responsible for moving data between wireless clients and the wired networks. An autonomous AP switches data directly to the wired network based on its SSID-to-VLAN mapping. Lightweight APs have different mode operations which define how they switch data:

  • Local or Split MAC mode. In this mode, all user data traffic is tunneled to WLC
  • FlexConnect – central switching mode. Data plane is similar to local mode, however, some traffic can be switched locally. When the controller is not reachable, AP operates as an autonomous AP
  • FlexConnect – local switching mode. Data plane is similar to autonomous AP, which switches traffic locally to wired network based on configured SSID-to-VLAN mapping using 802.1q tagging
  • SD-Access mode. In this mode, AP connects to the SD-Access Edge switch and transmits data via SD-Access fabric using VXLAN encapsulation (check this link for more information on SD-Access).
Self-test question: What are the functions of an Access Point?
• Advertises one or more wireless networks identified by SSIDs and allows wireless clients to connect to these networks

• Allows wireless clients to communicate with each other and access wired network
Self-test question: What are the two modes of Access Points operations and their difference?
• Autonomous. Standalone Access Point that operates independently and is individually managed

• Lightweight or controller-based. Requires a controller to perform management and control plane tasks. Data plane operations may be performed locally or tunneled to WLC

Wireless LAN Controllers (WLCs)

Managing a number of autonomous APs is getting more difficult as device number grows, as the configuration must be consistent across many devices. WLCs solve this problem by providing centralized management of the wireless network.

Models

Current Cisco portfolio of controllers consists of:

  • WLC 3504 (AireOS)
  • WLC 5520 (AireOS)
  • WLC 8540 (AireOS)
  • Mobility Express on APs (AireOS)
  • Catalyst 9800 series (IOS-XE): 9800-L, 9800-40, 9840-80, 9800-CL (virtual)
  • Embedded WLC on APs and Switches (IOS-XE)

The recently released versions of WLCs can be compared using the same tool shown in the Access Points section.  

Software

Cisco Wireless LAN Controllers were traditionally running AireOS software. The Cisco controller-less solution with the WLC role performed by an 802.11ac Access Points is called Cisco Mobility Express.

Newer controllers are now IOS-XE software-based. New Catalyst 9100 Access Points can run the WLC role and this newer IOS-XE based solution is called Embedded Wireless Controller. Based on the fact that new controllers are IOS-XE based, AireOS most likely will be replaced by IOS-XE. A feature comparison of both platforms can be found here.

A controller can have multiple functions depending on types of the deployment. The next sections discuss available options.

Meraki cloud-based management

Meraki MR APs are first associated with their serial numbers with Meraki Cloud, which provides management access for the wireless LAN deployment. The AP-to-Controller communication is out-of-band and Meraki MR APs will continue to function when connectivity to Meraki Cloud is lost. During connectivity outages ability to perform configuration changes is not available.

No user data is being transferred through Meraki Cloud infrastructure. Security operations, such as authentication are performed by Meraki Access Point locally. For example, RADIUS authentication requests for WPA2 Enterprise are being sent directly from an access point.

Split-MAC

This type of deployment is suitable for large campuses, where sufficient infrastructure exists for the controller to be deployed locally. In this scenario, controllers are actively participating in data forwarding. Access Points establish CAPWAP tunnels to the controller. One tunnel is used for the control plane and another carries encapsulated data payload.

From a wired network perspective, all wireless users traffic is originating from WLC’s LAN interface. This simplifies the configuration of switching infrastructure, as access point facing ports no longer require 802.1q trunk configuration and maintenance of allowed VLANs on that interface. Such ports can be configured as access ports. CAPWAP traffic is unicast UDP traffic between the AP and the WLC.

Figure 1 shows a simplified view of the traffic flow with the split MAC. If A sends a frame to C, AP will send it over the CAPWAP tunnel (in yellow) to WLC. AP and WLC can be in different VLANs, as CAPWAP is IP routed traffic. WLC will de-capsulate it and send it on its LAN interface connected to port 2 of the switch. The switch will learn the MAC address of A via port #2 (facing WLC).

Figure 1. Split MAC Traffic Flow
Figure 1. Split MAC Traffic Flow

Split-MAC configuration usually offers faster roaming when the user moves from one access point to another. There are some associated drawbacks, such as the requirement to maintain a dedicated WLC, and bandwidth scaling limits imposed by the controller’s platform and increased dependency on the WLC, as Lightweight Access Points cannot operate without an active connection to it.

FlexConnect

The WLC and access points also support FlexConnect mode of operation. It allows Lightweight Access Point to locally switch some or all of the user traffic instead of sending it to the controller via the CAPWAP tunnel. This mode’s purpose is to decrease the amount of traffic that needs to be sent to a controller from the branch offices.

WLC appliances support 2 modes – Central Switching and Local Switching.

When WLAN is configured to use Central Switching, traffic from an AP is still tunneled to WLC, however, local-site traffic can be enabled for local switching by configuring Split Tunneling. When there is an active connection between WLC and AP, it is in Connected Mode. When the connection is lost, AP moves into a standalone mode and performs switching locally.

AP in FlexConnect Local Switching mode switches all traffic locally, even when AP can reach WLC. It is similar to the operation of autonomous APs which also switches traffic locally by mapping SSIDs to VLANs. Access Points are still controlled by WLC retaining the benefits of centralized management.

Figure 2. FlexConnect Local Switching Traffic Flow
Figure 2. FlexConnect Local Switching Traffic Flow

Embedded WLCs (and Mobility Express) rely on FlexConnect Local Switching operation, as there is no benefit in sending encapsulated data over the tunnel to another Access Point that performs the role of WLC.

SD-Access Mode

SD-Access fabric-integrated WLC actively participates in the fabric operation via the control plane integration. For example, a WLC can update host tracking databases of the edge switch when a client registers, so this information is then distributed via a fabric LISP-based control plane.

WLC controls fabric-integrated access points perform the same functions as non-fabric WLCs, plus fabric specific operations. For example, a WLC provides an Access Point with VXLAN information (VNI) during client registration. By integrating with Cisco ISE, WLC can also provide AP with security tags (SGTs), so the policy can be enforced upstream.

In fabric mode, a WLC doesn’t participate in the data plane operation and all data is encapsulated locally by the fabric access point.

Self-test question: What are the functions of a WLC?
• Provide centralized management of the wireless network

• In some modes of operation transmit user traffic received from APs via CAPWAP tunnel
Self-test question: What are two types of the Cisco WLCs software?
• AireOS. This is the traditional Cisco WLC platforms software

• IOS-XE. New controllers are based on this version of the software
Self-test question: What is Split-MAC WLC mode of operation?
• An Access Points sends all user traffic to WLC where it breaks out centrally

The 3rd part of the series is now available.

Explain Role and Function of Network Components – Part 1

This blog post provides an overview of different network components and their role and functions. The article’s target audience is CCNA candidates and students looking for introductory information about computer network components. In this first post of the 3-article series, we will start by exploring the functions of endpoints and servers. Then the section about LAN switches will follow focusing on the difference between Layer 2 and Layer 3 switch operation.

Endpoints and Servers

The purpose of the infrastructure that the network devices create is to connect endpoints, such as computers, laptops, mobile and IP phones, and servers. A typical endpoint usually runs client applications, for example, a web browser and mail client that interact with the users. These network-enabled applications use services provided by network protocol stacks, drivers, and hardware components.

Out of all network components, endpoints have the most obvious role – they generate useful network payloads, such as digitized voice or Excel spreadsheets that are being transmitted over the network. And their function is to interact with a user, follow specific standards and protocols, so the transmitted data can be decoded on the receiving side of the connection.

Endpoints have an Operating System, which interacts with physical hardware using drivers. Operating System manages networking stack and provides APIs, so the application developers can work with the network without having to program low-level hardware components.

The most common type of wired connectivity is Ethernet, which is described by multiple IEEE 802.3 standards. Wireless communication is defined by IEEE 802.11 standards. Both types of connections use the same addressing, which is used to send frames between devices on the same network. Usually, this type of communication is referred to as Layers 1 and Layer 2 operations of the 7-layer OSI reference model. Layer 1 deals with physical specifications, such as electronic signals transferred over the wire. Layer 2 uses services provided by Layer 1 and is responsible for data framing and addressing.

Figure 1. OSI 7-Layer Model
Figure 1. OSI 7-Layer Model

Almost all OS stacks support and prefer one of two versions of IP protocol (IPv4 or IPv6). Each endpoint is assigned with an IP address that is used for addressing when a packet needs to be transmitted over multiple physical networks. This type of communication is referred to as Layer 3 connectivity.

There are two IP protocols operating on Layer 4 – Transport Control Protocol (TCP) and User Datagram Protocol (UDP). A connection or flow between two devices is identified by source and destination port (both TCP and UDP use concept of ports). Connection is usually initiated by a client. Servers wait for new connections to be established by listening on a specific port. TCP port 0 to 1023 are well-known ports allocated to the specific applications. Client-side uses dynamically allocated ports.

Layer 2 Switches

CCNA blueprint doesn’t include Ethernet hubs, as there are now fully replaced by the switches. However, it is still helpful to understand the way a hub operates to understand the benefits that Layer 2 switches provide.

Early Ethernet network technologies were either bus or star topology-based. Bus topology would have end devices sequentially connected to each other with a coaxial cable. A hub allowed building a star-like topology where all UTP (twisted pair) cabling would terminate in a single location with the hub being the center of the star. In both cases, the network was shared medium and each machine must first listen if there is an active transmission on the network before sending any traffic on its own.

If 2 devices send traffic at the same time a collision occurs and both devices pause for some random amount of time before trying again. Such mode of operation is called CSMA/CD (Carrier-Sense Multiple Access with Collision Detection).

Hubs create a collision domain by re-sending traffic to every port except the ingress one, which makes total available bandwidth smaller as the number of devices increases.

Layer 2 switch solves the issue of sending traffic to all ports by inspecting incoming traffic and learning addresses of devices behind each port, so it can then send unicast traffic through the correct port, as opposed to flooding. BUM traffic (Broadcast, Unknown Unicast and Multicast) is still sent out of all ports. Switches also can store some amount of traffic in its buffers if there is more traffic to be sent than the port’s available bandwidth.

Endpoints connected to a switched port don’t need to listen if other hosts on the network are sending traffic and can send data at any time. Such ports are operating in full-duplex and will not experience collisions as the devices connected to hub ports.

Ethernet Layer 2 switches are usually placed at the access level with the end-users, phones, and printers connected to them. Most of the Cisco Ethernet switches have 24 or 48 ports.

In the topology shown below, the switch uses only hardware MAC address information to forward frames. Both PCs and servers will also have Layer 3 address, such as IP or IPv6, however, for a Layer 2 switch operation, this information is not being processed for traffic forwarding.

Figure 2. Layer 2 Switch Operation
Figure 2. Layer 2 Switch Operation

Layer 2 switches provide connectivity between hosts on Layer 2 with connected endpoints sharing the same broadcast domain and IP subnet. All 3 devices in the figure above are in the same VLAN and can communicate with each other. The switch will maintain a table of MAC address to port mappings.

Layer 2 switch can create broadcast domain boundaries by placing a group of ports into different VLANs, but it cannot provide communication between these domains. In the sample topology below A and B (ports 1 and 2) are in VLAN 10 and communicate with each other. C and D (ports 3 and 4) are in VLAN 20 and can also communicate with each other. There is no communication between VLAN 10 and VLAN 20 possible with only Layer 2 switch.

Figure 3. Layer 2 Switch Operation - VLANs
Figure 3. Layer 2 Switch Operation – VLANs

A layer 3 device is required to perform this function. In the campus network, it is the responsibility of a Layer 3 switches to provide connectivity between VLANs.

Self-test question: What are the functions of Layer 2 switch?
• Provide wired full-duplex connectivity to the end users and phones

• Divide collision domains. Each port is a separate collision domain

• Ability to create isolated broadcast domains with VLANs

Layer 3 Switches

Layer 3 switches traditionally were placed at the distribution level, however, in modern networks routed access becomes more common. Almost all current Cisco switching platforms can perform inter-VLAN routing and can act as Layer 3 switches on the network. Therefore, the distinction between Layer 2 and Layer 3 switches is in their configuration, not the specific model.

Layer 3 switching is essentially IP routing or packet forwarding based on Layer 3 addressing. Modern Layer 3 switches perform routing in hardware and can provide very high throughput comparable to Layer 2 switching. However, Layer 3 switches have a smaller feature sets when comparing to routers, which can usually be found at the WAN edge of the network.

To perform its operation Layer 3 switch must have either a logical interface in VLANs that it routes for or a physical interface with IP address assigned to it.

Switched Virtual Interface (SVI) is a logical interface named after VLAN it is connected to. It has an IP address allocated to it, to provide routing for this VLAN clients. As shown in the diagram below, Layer 3 switch has 2 SVIs – VLAN10 and VLAN20. Notice that now devices are shown with IPv4 addresses allocated to them instead of hardware MAC addresses, as this is the information relevant for Layer 3 switch operation.

Layer 2 operations are still performed in exactly the same way as described in the Layer 2 switch section. For example, if the workstation A sends a packet to the server B, no routing is required and Layer 2 forwarding is used to deliver the frame.

If host A will try to communicate to host D inter-VLAN routing will be performed by the switch, which will involve two-step process – Layer 2 communication between host A and switch VLAN 10 SVI; and another one between switch’s VLAN 20 SVI and the server D.

Figure 4. Layer 3 Switch Operation – SVIs

Physical IP interfaces are usually used on transit segments. Consider the topology shown in the next diagram. Switch connects to two routers. A point-to-point subnet of /30, which can accommodate only 2 hosts, has been to allocate to each of the connections. We now have two configuration options. The top router is connected via Layer 2 port which is a member of VLAN 254. We then create an SVI on the L3 switch for VLAN 254. As we assigned only a single Layer 2 port to this VLAN, the connection is point-to-point. This is similar to the previous example.

The second option is to configure the physical port, in our case, it is GigabitEthernet1/0/10 as Layer 3 port. We don’t have to consume a VLAN ID and configuration is contained within a single interface.

Figure 5. Layer 3 Switch Operation – L3 Interfaces
Self-test question: What are the functions of Layer 3 switch?
• Can perform all functions of Layer 2 switch

• Performs high-speed routing between VLANs

• Traditionally deployed at distribution layer of the campus network

• Can be deployed at the access layer when routed access design is used

In the second part of these series of articles, we will discuss the operation of another type of LAN device which provides connectivity to the wireless clients – Access Points. Wireless LAN Controller functions will also be presented.

The third part of this series will be dedicated to devices that are usually found at the edge of the network, such as routers, firewalls, and IPSs.

DNA Center is introduced in its own article.

Reference materials

Cisco SD-Access

Collapsed core and three-tier architecture

Cisco Clock Timezone Configuration

This article provides sample Cisco configuration commands for popular cities using “clock timezone” and “clock summer-time” commands. It also aggregates information about different time zones and their daylight saving dates.

Many services are dependent on the clock and time zone configuration on Cisco devices. Services such as certificate validity checks, logging are the obvious ones. The other examples include time-based ACLs or scheduled tasks that can cause outages during the daylight saving changes. The daylight savings rules are also changing time after time.

Time Zones and Daylight Settings

The time zone represents an area or region that observes the same time. Coordinated Universal Time (UTC) is the reference time. Time zones are expressed as an offset from it. Offset can be either negative or positive represented in a number of hours and in some cases in minutes.

Some regions observe daylight savings time when clocks are adjusted twice a year so there is an extra hour of daylight in the evening during summer. There are more daylight hours in summer than during winter. The difference is more noticeable when moving away from the equator. The adjustment is done in spring by moving clocks forward (spring forward) and then reversed in autumn by moving clocks back (fall back). Note that summer starts in December in some of the countries in the Southern hemisphere.

Time Configuration on Cisco devices

We recommend using NTP to ensure that time is accurately synchronized. NTP server sends time information in UTC, so it is important to set the correct time zone.

If manual clock settings are in use, the router assumes that the time is specified in the router’s local time zone, which is UTC by default. Therefore, the time zone settings should be configured before setting the clock manually, as otherwise, it will need to be re-adjusted after the router applies time zone configuration.

The following paragraphs show how to configure the correct time zone and daylight savings settings on the device.

To specify time zone and daylight settings two commands are used:

R1(config)#clock ?        
   summer-time     Configure summer (daylight savings) time
   timezone        Configure time zone

Time zone configuration requires only 2 parameters:

clock timezone zone hours-offset [minutes-offset]

Summer-time configuration can be either recurring or date-specific:

clock summer-time zone recurring [week day month hh:mm week day month hh:mm [offset]]
 clock summer-time zone date date month year hh:mm date month year hh:mm [offset]

Time Configuration on Cisco devices

The easiest way to lookup information is by navigating to the timeanddate.com website and browsing to the world clock page.

Then find the city name and click on it. Select the Time Zone button and it will display abbreviation and up-to-date information on when DST starts.

Below are the configuration samples for some of the popular cities with updated daylight information as of March 2020.

North America

CityCommand
Honolulu, US# Hawaii Standard Time
clock timezone HST -10
Vancouver, Canada# Pacific Standard Time
clock timezone PST -8

# Pacific Daylight Time
clock summer-time PDT recurring 2 Sun Mar 2:00 1 Sun Nov 2:00
Los Angeles, US
San Francisco, US
Las Vegas, US
Seattle, US
# Pacific Standard Time
clock timezone PST -8

# Pacific Daylight Time
clock summer-time PDT recurring 2 Sun Mar 2:00 1 Sun Nov 2:00
Mexico City, Mexico# Central Standard Time
clock timezone CST -6

# Central Daylight Time
clock summer-time CDT recurring 1 Sun Apr 2:00 1 Sun Nov 2:00
Denver, US# Mountain Standard Time
clock timezone MST -7

# Mountain Daylight Time
clock summer-time MDT recurring 2 Sun Mar 2:00 1 Sun Nov 2:00
Cancun, Mexico# Eastern Standard Time
clock timezone EST -5
Panama, Panama# Eastern Standard Time
clock timezone EST -5
New Orleans, US
Kansas City, US
Austin, US
Dallas, US
Milwaukee, US
# Central Standard Time
clock timezone CST -6

# Central Daylight Time
clock summer-time CDT recurring 2 Sun Mar 2:00 1 Sun Nov 2:00
Ottawa, Canada
Ontario, Canada
Montreal, Canada
Quebec, Canada
# Eastern Standard Time
clock timezone EST -5

# Eastern Daylight Time
clock summer-time EDT recurring 2 Sun Mar 2:00 1 Sun Nov 2:00
Havana, Cuba# Cuba Standard Time
clock timezone EST -5

# Cuba Daylight Time
clock summer-time EDT recurring 2 Sun Mar 2:00 1 Sun Nov 1:00
Washington DC, US
Florida, US
Tampa, US
Atlanta, US
Indianapolis, US
Louisville, US
Baltimore, US
Boston, US
Michigan, US
New York, US
Philadelphia, US
Pittsburgh, US
Portsmouth, US
# Eastern Standard Time
clock timezone EST -5

# Eastern Daylight Time
clock summer-time EDT recurring 2 Sun Mar 2:00 1 Sun Nov 2:00
Halifax, Canada# Atlantic Standard Time
clock timezone AST -4

# Atlantic Daylight Time
clock summer-time ADT recurring 2 Sun Mar 2:00 1 Sun Nov 2:00

Table 1. North America Cities and Cisco Timezone Configuration Commands

South America

CityCommand
Bogota, Colombia# Colombia Time
clock timezone COT -5
Lima, Peru# Peru Time
clock timezone PET -5
Santa Cruz, Bolivia# Bolivia Time
clock timezone BOT -4
Caracas, Venezuela# Venezuelan Standard Time
clock timezone VET -4
Buenos Aires, Argentina
Santa Fe, Argentina
# Argentina Time
clock timezone ART -3
Brasilia, Brazil
Rio de Janeiro, Brazil
Sao Paulo, Brazil
# Brasilia Time
clock timezone BRT -3
Asuncion, Paraguay# Paraguay Time
clock timezone PYT -4

# Paraguay Summer Time
clock summer-time PYST recurring 1 Sun Oct 0:00 last Sun Oct 0:00
Montevideo, Uruguay# Uruguay Time
clock timezone UYT -3

Table 2. South America Cities and Cisco Timezone Configuration Commands

Europe

CityCommand
Reykjavik, Iceland# Greenwich Mean Time
clock timezone GMT
Dublin, Ireland# Greenwich Mean Time
clock timezone GMT

# Irish Standard Time (Daylight saving)
clock summer-time IST recurring last Sun Mar 1:00 last Sun Oct 2:00
Lisbon, Portugal
Porto, Portugal
# Western European Time
clock timezone WET

# Western European Summer Time
clock summer-time WEST recurring last Sun Mar 1:00 last Sun Oct 2:00
Birmingham, UK
Bristol, UK
Leeds, UK
Liverpool, UK
London, UK
Manchester, UK
Belfast, UK
Edinburgh, UK
Glasgow, UK
# Greenwich Mean Time
clock timezone GMT

# British Summer Time
clock summer-time BST recurring last Sun Mar 1:00 last Sun Oct 2:00
Tirana, Albania
Salzburg, Austria
Vienna, Austria
Brussels, Belgium
Sarajevo, Bosnia-Herzegovina
Zagreb, Croatia
Prague, Czechia
Copenhagen, Denmark
Strasbourg, France
Paris, France
Versailles, France
Toulouse, France
Marseille, France
Stuttgart, Germany
Munich, Germany
Berlin, Germany
Hamburg, Germany
Frankfurt, Germany
Hannover, Germany
Dortmund, Germany
Leipzig, Germany
Gibraltar, Gibraltar
Budapest, Hungary
Naples, Italy
Turin, Italy
Venice, Italy
Amsterdam, Netherlands
The Hague, Netherlands
Oslo, Norway
Krakow, Poland
Warsaw, Poland
Belgrade, Serbia
Ljubljana, Slovenia
Barcelona, Spain
Ibiza, Spain
Madrid, Spain
Stockholm, Sweden
Bern, Switzerland
Geneva, Switzerland
Lugano, Switzerland
Vatican City, Vatican City State
# Central European Time
clock timezone CET +1

# Central European Summer Time
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
Plovdiv, Bulgaria
Sofia, Bulgaria
Tallinn, Estonia
Helsinki, Finland
Athens, Greece
Riga, Latvia
Vilnius, Lithuania
Bucharest, Romania
Kyiv, Ukraine
Odesa, Ukraine
# Eastern European Time
clock timezone EET +2

# Eastern European Summer Time
clock summer-time EEST recurring last Sun Mar 3:00 last Sun Oct 4:00
Kaliningrad, Russia# Eastern European Time
clock timezone EET +2
Minsk, Belarus
Bryansk, Russia
Sochi, Russia
Moscow, Russia
Saint-Petersburg, Russia
# Moscow Standard Time
clock timezone MSK +3

Table 3. Europe Cities and Cisco Timezone Configuration Commands

Asia

CityCommand
Jerusalem, Israel
Tel Aviv, Israel
# Israel Standard Time
clock timezone IST +2

# Israel Daylight Time
clock summer-time IDT recurring last Sun Mar 2:00 last Sun Oct 2:00
Beirut, Lebanon# Eastern European Time
clock timezone EET +2

# Eastern European Summer Time
clock summer-time EEST recurring last Sun Mar 0:00 last Sun Oct 0:00
Baghdad, Iraq
Kuwait City, Kuwait
Doha, Qatar
Riyadh, Saudi Arabia
# Arabia Standard Time
clock timezone AST +3
Istanbul, Turkey# Turkey Time
clock timezone TRT +3
Tbilisi, Georgia# Georgia Standard Time
clock timezone GET +4
Yerevan, Armenia# Armenia Time
clock timezone AMT +4
Baku, Azerbaijan# Azerbaijan Time
clock timezone AZT +4
Dubai, United Arab Emirates# Gulf Standard Time
clock timezone GST +4
Kabul, Afghanistan# Afghanistan Time
clock timezone AFT +4 30
Tehran, Iran# Iran Standard Time
clock timezone IRST +3 30

# Iran Daylight Time 2020
clock summer-time IRDT date 21 Mar 2020 0:00 21 Sep 2020 0:00
# Iran Daylight Time 2021-2023
clock summer-time IRDT date 22 Mar 2021 0:00 22 Sep 2021 0:00
clock summer-time IRDT date 22 Mar 2022 0:00 22 Sep 2022 0:00
clock summer-time IRDT date 22 Mar 2023 0:00 22 Sep 2023 0:00
Islamabad, Pakistan
Karachi, Pakistan
Lahore, Pakistan
# Pakistan Standard Time
clock timezone PKT +5
Ufa, Russia
Chelyabinsk, Russia
Yekaterinburg, Russia
# Yekaterinburg Time
clock timezone YEKT +5
Dushanbe, Tajikistan# Tajikistan Time
clock timezone TJT +5
Ashgabat, Turkmenistan# Turkmenistan Time
clock timezone TMT +5
Tashkent, Uzbekistan# Uzbekistan Time
clock timezone UZT +5
Delhi, India
New Delhi, India
Bangalore, India
Mumbai, India
Kolkata, India
Colombo, Sri Lanka
# India Standard Time
clock timezone IST +5 30
Kathmandu, Nepal# Nepal Time
clock timezone NPT +5 45
Dhaka, Bangladesh# Bangladesh Standard Time
clock timezone BST +6
Almaty, Kazakhstan
Nursultan, Kazakhstan
# Alma-Ata Time
clock timezone ALMT +6
Bishkek, Kyrgyzstan# Kyrgyzstan Time
clock timezone KGT +6
Omsk, Russia# Omsk Standard Time
clock timezone OST +6
Phnom Penh, Cambodia
Hanoi, Vietnam
Ho Chi Minh, Vietnam
# Indochina Time
clock timezone ICT +7
Jakarta, Indonesia# Western Indonesian Time
clock timezone WIB +7
Novosibirsk, Russia# Novosibirsk Time
clock timezone NOVT +7
Beijing, China
Guangzhou, China
Shenzhen, China
Harbin, China
Nanjing, China
Shanghai, China
Chengdu, China
Lhasa, China
Hangzhou, China
Taipei, Taiwan
# China Standard Time
clock timezone CST +7
Hong Kong, Hong Kong# Hong Kong Time
clock timezone HKT +7
Kuala Lumpur, Malaysia# Malaysia Time
clock timezone MYT +8
Manila, Philippines# Philippine Time
clock timezone PHT +8
Irkutsk, Russia# Irkutsk Time
clock timezone IRKT +8
Singapore, Singapore# Singapore Time
clock timezone SGT +8
Kyoto, Japan
Osaka, Japan
Sapporo, Japan
Tokyo, Japan
Yokohama, Japan
# Japan Standard Time
clock timezone JST +9
Chita, Russia
Yakutsk, Russia
# Yakutsk Time
clock timezone YAKT +9
Busan, South Korea
Daegu, South Korea
Incheon, South Korea
Seoul, South Korea
# Korea Standard Time
clock timezone KST +9
Vladivostok, Russia# Vladivostok Time
clock timezone VLAT +10

Table 4. Asia Cities and Cisco Timezone Configuration Commands

Africa

CityCommand
Bissau, Guinea-Bissau
Monrovia, Liberia
Timbuktu, Mali
Dakar, Senegal
# Greenwich Mean Time
clock timezone GMT
Algiers, Algeria
Constantine, Algeria
Tunis, Tunisia
# Central European Time
clock timezone CET +1
Kinshasa, Congo
Lagos, Nigeria
# West Africa Time
clock timezone WAT +1
Casablanca, Morocco
Marrakech, Morocco
Tangier, Morocco
# Western European Time
clock timezone WET

# Western European Summer Time 2020-21
clock summer-time WEST date 9 Jun 2019 2:00 19 Apr 2020 Apr 3:00
clock summer-time WEST date 24 May 2020 2:00 11 Apr 2021 Apr 3:00
Alexandria, Egypt
Cairo, Egypt
Tobruk, Libya
Tripoli, Libya
# Eastern European Time
clock timezone EET +2
Cape Town, South Africa
Johannesburg, South Africa
Pretoria, South Africa
# South Africa Standard Time
clock timezone SAST +2
Khartoum, Sudan
Port Sudan, Sudan
# Central Africa Time
clock timezone CAT +2
Addis Ababa, Ethiopia
Mombasa, Kenya
Mogadishu, Somalia
Zanzibar City, Tanzania
# Eastern Africa Time
clock timezone EAT +3

Table 5. Africa Cities and Cisco Timezone Configuration Commands

Australia/Pacific

CityCommand
Perth, Australia# Australian Western Standard Time
clock timezone AWST +8
Darwin, Australia# Australian Central Standard Time
clock timezone ACST +9 30

Brisbane, Australia
Cairns, Australia
# Australian Eastern Standard Time
clock timezone AEST +10
Adelaide, Australia# Australian Central Standard Time
clock timezone ACST +9 30

# Australian Central Daylight Time
clock summer-time ACDT recurring 1 Sun Oct 2:00 1 Sun Apr 3:00
Canberra, Australia
Sydney, Australia
Hobart, Australia
Melbourne, Australia
# Australian Eastern Standard Time
clock timezone AEST +10

# Australian Eastern Daylight Time
clock summer-time AEDT recurring 1 Sun Oct 2:00 1 Sun Apr 3:00
Noumea, New Caledonia# New Caledonia Time
clock timezone NCT +11
Port Vila, Vanuatu# Vanuatu Time
clock timezone VUT +11
Auckland, New Zealand
Christchurch, New Zealand
Wellington, New Zealand
# New Zealand Standard Time
clock timezone NZST +12

# New Zealand Daylight Time
clock summer-time NZDT recurring last Sun Sep 2:00 1 Sun Apr 3:00

Table 6. Australia/Pacific Cities and Cisco Timezone Configuration Commands

Reference Information

Alphabetically sorted list of time zone abbreviations:

https://www.timeanddate.com/time/zones/

IANA supports the time zone database (https://www.iana.org/time-zones) and at the time of this blog post writing the latest one is 2019c release. To receive updates on time zone database updates, you can subscribe to the IANA’s mailing list (https://mm.icann.org/mailman/listinfo/tz-announce).

Cisco SD-Access Components

I’ve posted earlier overview articles about Cisco’s WAN and Data Center software-defined technologies – Cisco Viptela SD-WAN (link) and ACI (link). Now it’s time to explore the solution for LAN. Cisco SD-Access is the evolutionary step in how campus networks are built and operated. In this blog post, we will discover components of Cisco SD-Access, namely control and data plane elements.

What are the main SD-Access benefits?

The key advantage of a software-defined solution is management centralization. DNA Center with SD-Access application simplifies campus network operation by providing a single point of management for multiple devices. DNA Center not only automates devices configuration but also exposes APIs, so it can be accessed programmatically.

With Cisco SD-Access administrators can create and apply common policies across the entire campus network. Operational expense savings is one of the main selling points of the Cisco SD-Access.

Network flow telemetry gives operators better visibility into what is happening in the network. Cisco ISE and TrustSec provide user and device identification and segmentation within the same virtual network boundary. SD-Access can also support fully isolated virtual networks, for example, between multiple tenants. As a result better security is achieved with less effort.

Components of Cisco SD-Access

SD-Access consists of 3 categories of components:

  • Network fabric – Switches, routers, wireless LAN controllers and access points. Routed access with VXLAN data plane and LISP control plane
  • Cisco DNA Center with SD-Access – one or multiple appliances
  • Cisco ISE – one or multiple appliances

Check this document for detailed information on supported component combinations and licensing requirements (external link).

This link is an official matrix listing compatibility between versions of different components.

SD-Access Fabric

Switches and Routers

Different roles that switches can perform will be covered in later sections of this article. However, for the purpose of right platform selection 2 main switch roles should be considered – Edge and Border/Control plane nodes.

Edge switches are similar to access switches, as they have end-user devices connected to them and platforms that currently recommended (Catalyst 9000) and supported (other platforms; check the release notes and licensing documentation for feature support) are listed below:

  • Catalyst 9000-series: 9200, 9300, 9400, 9500
  • Catalyst 3850 and 3650
  • Catalyst 4500E: Sup 8-E, 9-E

Border/Control plane switches perform Endpoint ID tracking and are responsible for running Layer 3 routing with networks outside of the fabric. Therefore, these switches have higher memory requirements. If only control plane operation to be implemented with no traffic transit routing virtual CSR 1000v can be used. And when border node functions without control plane operations are required Nexus 7700 is a supported option.

 Border/Control plane switches and routers to choose from are:

  • Catalyst 9000-series: 9300, 9400, 9500, 9600
  • Catalyst 3850
  • Catalyst 6500/6807-XL: Sup 2T, 6T
  • Catalyst 6840-X, 6880-X
  • Nexus 7700: Sup 2-E, 3-E, M3 line cards only – border functionality only
  • ISR 4300, 4400
  • ASR 1000-X, 1000-HX
  • CSR 1000v

Fabric Wireless Controllers and Access Points

SD-Access supports traditional WLCs and APs without integration with fabric and they communicate between each other in overlay over-the-top as any other data traffic. Fabric-integrated Wireless Controllers and Access Points participate in the control plane and data flow is changed in comparison with traditional WLCs and APs.

This integration provides additional benefits and better efficiency. For example, user traffic from a fabric access point is de-capsulated on the edge switch without tunneling it up to its WLC. This section lists supported fabric-integrated wireless components.

Supported WLCs are:

  • Catalyst 9800 Wireless Controller: 9800-40, 9800-80, 9800-CL and Embedded on C9300, C9400 and C9500
  • Cisco 3504, 5520 and 8540 WLC

Fabric mode APs must be directly connected to a fabric edge node. Supported models are:

  • WiFi 6 APs: Catalyst 9115AX, 9117AX and 9120AX
  • Wave 2 APs: Aironet 1800, 2800 and 3800
  • Wave 2 APs, outdoor models: Aironet 1540, 1560
  • Wave 1 APs: Aironet 1700, 2700 and 3700
  • Aironet 4800 APs

DNA Center

DNA Center is responsible for fabric management. The software must be installed on a physical DNA Center Appliance which is based on the Cisco UCS C-series Server. SD-Access is one of the applications of DNA Center.

Check this article dedicated to DNA Center role and functions.

If DNA Center appliance becomes unavailable fabric would continue to function, however, automatic provisioning will be impacted. For redundancy, a highly available cluster of 3 nodes of the same model is recommended.

DNA Center Appliances have 3 options to choose from:

  • Entry-level of up to 1,000 devices: DN2-HW-APL (C220 M5, 44 cores)
  • Mid-size of up to 2,000 devices: DN2-HW-APL-L (C220 M5, 56 cores)
  • Large of up to 5,000 devices: DN2-HW-APL-XL (C480 M5, 112 cores)

Identity Services Engine (ISE)

Cisco Identity Services Engine (ISE) provides identity services for the solution. Access control policies which are based on user and device identity are also ISE’s responsibility. With Cisco TrustSec edge device applies Security Group Tags (SGTs) on the traffic based on the identity. Then these tags can be used to perform filtering using SGT-based access-lists.

ISE is available as a virtual or a physical appliance. The following models of ISE appliances are available:

  • Small physical:  SNS-3515
  • Large physical: SNS-3595
  • Small virtual: R-ISE-VMS
  • Medium virtual: R-ISE-VMM
  • Large virtual: R-ISE-VML

ISE appliances can also be implemented in a high-availability setup with load balancing achieved by splitting functions between nodes.

Cisco ISE integrates with DNA Center using REST API and PXGrid. DNA uses REST API to automate policy configuration on ISE and PXGrid is used for endpoint information exchange.

Data Plane

Figure 1 shows a sample network. Fabric is shown in a blue rectangle. Fabric switches in SD-Access are connected to each other using Layer 3 links. These links establish underlay or transport networks.

Switch fabric physical topology can follow traditional access-distribution-core patterns. There is no requirement to connect switches in leaf-and-spine topology as in data center underlay. Campus networks usually don’t need to accommodate intensive east-west communication as data centers do.

Cisco SD-Access Fabric
Figure 1. SD-Access Fabric

On top of the underlay, virtual networks are created with the use of VXLAN encapsulation. This is similar to the way how modern data center switch fabrics are built, such as Cisco ACI or native Cisco NX-OS VXLAN fabrics.

Packets on inter-switch links will be encapsulated in UDP on the transport layer and have source and destination IP addresses of Edge device loopbacks called routing locators or RLOCs. Edge nodes are responsible for VXLAN encapsulation/decapsulation when sending and receiving traffic towards fabric.

For broadcast/unknown unicast/multicast or BUM traffic, underlay can either use headend replication or in newer versions of SD-Access multicast in underlay can be utilized.

End-user devices connected to downstream ports of edge switches don’t see any difference from traditional Ethernet networking. The only exception is fabric access points. They must be attached to fabric edge nodes and VXLAN encapsulation is extended down to access points.

To deliver a packet, edge nodes sends a query to the control node to determine the target edge’s node IP address (RLOC) using LISP. If a reply is received, the edge node encapsulates traffic into VXLAN datagram and sends it directly to the destination node. If the query cannot be resolved, for example, in the case when the destination is not fabric-attached then traffic is sent to the default border node which in turn performs normal route lookup.

Control Plane

Fabric runs multiple control-plane protocols which can be divided into several categories:

  • Underlay network protocols
  • Endpoint ID tracking protocol
  • External to fabric routing protocols
  • WLC-related protocols

Underlay Protocols

The main task of the underlay is to ensure that edge devices can reach each other via their RLOCs or IP addresses that are used in the VXLAN IP header. SD-Access supports automated provisioning with IS-IS and it is recommended for greenfield deployment. It can, however, be replaced with OSPF or EIGRP with manual configuration.

The other protocol that can be used in underlay is a multicast routing protocol to replace resource and bandwidth-intensive headend replication. PIM-SM is the supported protocol.

All switches in the fabric run underlay protocols. Intermediate routers are similar to P routers in MPLS in the way that they work only with outer IP packet headers. Therefore, they don’t need to run or understand any other protocols described in the next sections.

Endpoint ID tracking

Endpoint IDs are IP and MAC addresses of devices connected to edge nodes. The SD-Access control plane is based on the Locator ID Separation Protocol (LISP).

Each designated control plane node performs LISP Map-Server (MS) and Map-Resolver (MR) roles.

Edge nodes register endpoints by sending Map-Register message to a control plane node. Map-Server stores endpoint ID to edge device information in Host Tracking Database (HTDB).

When the edge node needs to find the address of the edge device behind which specific endpoint is located, it sends a query to Map-Resolver. After checking HTDB, MR sends back RLOC for the requested endpoint.

Control plane and border node functionality can coexist on the same device and each should be deployed on at least two devices for redundancy.

Cisco SD-Access Endpoint ID Tracking
Figure 2. SD-Access Endpoint ID Tracking

External to fabric routing protocols

Control nodes know all endpoints connected to a fabric using the process described above. If an endpoint is not in HTDB and cannot be resolved, the edge node will assume that it is outside of the fabric and forward such traffic to the default fabric border node.

Border nodes connect the fabric to external networks and BGP is the recommended protocol to run on the boundary. Border nodes are also responsible for SGT propagation outside of the fabric.

Cisco SD-Access External Connectivity via Border Nodes
Figure 3. SD-Access External Connectivity

There are 3 types of border nodes in SD-Access:

  • External. Default exit from fabric with no specific routes injection
  • Internal. Gateway only for a set of networks, such as shared services prefixes
  • Anywhere. Combination of external and internal functionality

With multiple virtual networks overlaid on top of the SD-Access fabric, isolation on the fabric border is achieved with the use of VRFs.

Access to shared services, such as Cisco DNA Center, WLC controllers, DNS and DHCP servers are required from both underlay and overlay. Such access can be provided by connecting fusion routers to border nodes with VRF-lite. Fusion routers perform route leaking between VRFs to provide reachability information to the shared services from the fabric.

WLC-related protocols

Fabric-integrated WLCs run traditional control plane protocols, such as CAPWAP tunneling from APs to the WLC. However, CAPWAP tunnels are not used for data traffic and WLC doesn’t participate in user traffic forwarding.

When a client connects to a fabric enabled access point, the LISP registration process is different from described above for wired clients. With fabric APs, registration is not performed by the access point or the edge switch. Instead, WLC performs proxy registration with the LISP Map-Server in HTDB. If a wireless client roams, WLC ensures that the LISP mapping is updated.