For Cisco IOS XE devices:

Cisco IOS XE SD-WAN device support all the following SD-WAN software features. For more information, see Software Installation and Upgrade for Cisco IOS XE SD-WAN device.

• Cisco SD-WAN security features

  • Enterprise Firewall with Application Awareness

  • Intrusion Prevention System

  • URL Filtering

  • DNS/Web-Layer Security

  • Umbrella auto-registration

  • Cloud: Local domain bypass for umbrella

• Onsite bootstrap process for SD-WAN edge routers.

• Template improvements: Network Design Builder, Device Profile Builder.

• vManage common template for multiple C1100 wireless SKUs.

• IPv6 on the service side + dual-stack

  • Dual-stack interfaces (Gig, sub-Interface, SVI, and loopback) on service side.

  • v6 routing protocols on service side: Static, BGP, route maps, inbound filtering, outbound filtering, v4 and v6 OMP redistribute, v4 and v6 redistribute between service VPN's.

  • IPv6 services features on service side: QOS, QOS policer on service side, QOS dscp re-write rule for inbound and outbound, ip name-server, ICMP redirects, VRRP, ACL, DHCP relay agent, SSH, traceroute, SNMP, logging server, MIB.

  • IPv6 addressing: Unicast (link-local, unique-local, and global), Anycast.

• Device life cycle (Monitoring Security Policies by Device).

For Cisco vEdge device:

• Adaptive FEC for optimizing TCP retransmits.

• ALG support for FTP client side with NAT— FTP ALG support with network address translation – SERVICE NAT, and Zone-Based Firewall (ZBFW).

• Template improvements: Network Design Builder, Device Profile Builder.

• Packet duplication for loss correction.

• SR-IOV vEdgeCloud support.

SD-WAN Features Not Supported on IOS XE Devices

• Cloud Express service

• Cloud onRamp service

• Standard IPsec with IKE version 1 or IKE version 2 for service-side connections

• IPsec/GRE cloud proxy

• IPv6 on transport connections

• NAT pools on service-side connections

• Nat pools for DIA

• Service side NAT

• Reverse proxy

• Interface level policer (however, policer is supported through the interface ACL)

• Policy actions: local-tloc, local-tloc-list, remote-tloc (CSCvn67980), remote-tloc-list , mirror, log, service

For compatibility information and server recommendations, see Cisco SD-WAN Compatibility Matrix and Server Recommendations.

The following are known behaviors of the hardware:

• On vEdge 1000 routers, support for USB controllers is disabled by default. To attach an LTE USB dongle to a vEdge 1000 router, first attach the dongle, and then enable support for USB controllers on the vEdge router by adding the system usb-controller command to the configuration. When you enter this command in the configuration, the router immediately reboots. Then, when the router comes back up, continue with the router configuration. Also for vEdge 1000 routers, if you plug in an LTE USB dongle after you enable the USB controller, or if you hot swap an LTE USB dongle after you enable the USB controller, you must reboot the router in order for the USB dongle to be recognized. For information about enabling the USB controller, see USB Dongle for Cellular Connection.

• For vEdge 2000 routers, if you change the PIM type from a 1-Gigabit Ethernet to a 10-Gigabit Ethernet PIM, or vice versa, possibly as part of an RMA process, follow these steps:

  1. Delete the configuration for the old PIM (the PIM you are returning as part of the RMA process).

  2. Remove the old PIM, and return it as part of the RMA process.

  3. Insert the new PIM (the PIM you received as part of the RMA process).

  4. Reboot the vEdge 2000 router.

  5. Configure the interfaces for the new PIM.

• On a vEdge 5000 router, you cannot enable TCP optimization by configuring the tcp-optimization-enabled command.

• Cisco IOS XE SD-WAN device with the SFP-10G-SR module do not support online insertion and removal (OIR) of this module.

• Use of port-channels on the Service Side VPN is not supported on Cisco IOS XE SD-WAN devices.

• Bridge Domain Interface (BDI) is not supported on the Cisco ASR1000.

The following are known behaviors of the software:

Cellular Interfaces

• On a vEdge 100m-NA and 100m-GB routers, when you configure profile 1 for a wireless WAN, you might see the error "Aborted: 'vpn 0 interface cellular0 profile': Invalid profile 1 : APN missing". [VIP-31721].

• When configuring cellular attach-profile and data-profile on Cisco IOS XE routers running the XE SD-WAN software, you must use the default profile ID.

• The vEdge 100wm router United States certification allows operation only on non-DFS channels.

• When you are configuring primary and last-resort cellular interfaces with high control hello interval and tolerance values, note the following caveats:

  • When you configure two interfaces, one as the primary interface and the other as the last-resort interface, and when you configure a high control hello interval or tolerance values on the last-resort interface (using the hello-interval and hello-tolerance commands, respectively, the OMP state indicates init-in-gr even though it shows that the control connections and BFD are both Up. This issue was resolved in Release 16.2.3. However, the following caveats exist:

    — You can configure only one interface with a high hello interval and tolerance value. This interface can be either the primary or the last-resort interface.

    — In certain cases, such as when you reboot the router or when you issue shutdown and no shutdown commands on the interfaces, the control connections might take longer than expected to establish. In this case, it is recommended that you issue the request port-hop command for the desired color. You can also choose to wait for the vEdge router to initiate an implicit port-hop operation. The request port-hop command or the implicit port hop initiates the control connection on a new port. When the new connection is established, the stale entry is flushed from the vSmart controllers.

  • If the primary interface is Up, as indicated by the presence of a control connection and a BFD session, and if you configure a last-resort interface with higher values of hello interval and tolerance than the primary interface, if you issue a shutdown command, followed by a no shutdown command on the last-resort interface, the last-resort interface comes up and continuously tries to establish control connections. Several minutes can elapse before the operational status of the last-resort interfaces changes to Down. If this situation occurs, it is recommended that you issue a request port-hop command for the desired color.

  • If you have configured a primary interface and a last-resort interface that has higher hello interval and tolerance values than the primary interface, and if the last-resort interface has control connections to two vSmart controllers, if you issue a shutdown command, followed by a no shutdown command on the last-resort interface, a control connection comes up within a reasonable amount of time with only one of the vSmart controllers. The control connection with the second vSmart controller might not come up until the timer value configured in the hello tolerance has passed. If this situation occurs, it is recommended that you issue a request port-hop command for the desired color.

• When you activate the configuration on a router with cellular interfaces, the primary interfaces (that is, those interfaces not configured as circuits of last resort) and the circuit of last resort come up. In this process, all the interfaces begin the process of establishing control and BFD connections. When one or more of the primary interfaces establishes a TLOC connection, the circuit of last resort shuts itself down because it is not needed. During this shutdown process, the circuit of last resort triggers a BFD TLOC Down alarm and a Control TLOC Down alarm on the vEdge router. These two alarms are cleared only when all the primary interfaces lose their BFD connections to remote nodes and the circuit of last resort activates itself. This generation and clearing of alarms is expected behavior.

• For cellular interface profile, the profile number can be 0 through 15. Profile number 16 is reserved, and you cannot modify it.

Configuration and Command-line Interface

• When you upgrade to Release 17.2 from any prior Cisco SD-WAN release, the CLI history on the Cisco vEdge device is lost. The CLI history is the list of commands previously entered at the CLI prompt. You typically access the history using the up and down arrows on the keyboard or by typing Ctrl-P and Ctrl-N. When you upgrade from Release 17.2 to a later software release, the CLI history is maintained.

• When you issue the request reset configuration command on a vEdge Cloud router, a vManage NMS, or a vSmart controller, the software pointer to the device's certificate might be cleared even though the certificate itself is not deleted. When the device reboots and comes back up, installation of a new certificate fails, because the certificate is already present. To recover from this situation, issue the request software reset command.

Control and BFD Connections

• When a vBond orchestrator, vManage NMS, or vSmart controller goes down for any reason and the vEdge routers remain up, when the controller device comes back up, the connection between it and the vEdge router might shut down and restart, and in some cases the BFD sessions on the vEdge router might shut down and restart. This behavior occurs because of port hopping: when one device loses its control connection to another device, it port hops to another port in an attempt to reestablish the connection. For more information, see the Firewall Ports for Cisco SD-WAN Deployments article. Two examples illustrate when this might occur:

  • When a vBond orchestrator goes down for any reason, the vManage NMS might take down all connections to the vEdge routers. The sequence of events that occurs is as follows: when the vBond orchestrator crashes, the vManage NMS might lose or close all its control connections. The vManage NMS then port hops, to try to establish connections to the vSmart controllers on a different port. This port hopping on the vManage NMS shuts down and then restarts all its control connections, including those to the vEdge routers.

  • All control sessions on all vSmart controllers go down, and BFD sessions on the vEdge routers remain up. When any one of the vSmart controllers comes back up, the BFD sessions on the routers go down and then come back up because the vEdge routers have port hopped to a different port in an attempt to reconnect to the vSmart controllers.

• When a vEdge router running Release 16.2 or later is behind a symmetric NAT device, it can establish BFD sessions with remote vEdge routers only if the remote routers are running Release 16.2 or later. These routers cannot establish BFD sessions with a remote vEdge router that is running a software release earlier than Release 16.2.0.

• When you add or remove an IPv4 address on a tunnel interface (TLOC) that already has an IPv6 address, or when you add or remove an IPv6 address on a TLOC that already has an IPv4 address, the control and data plane connections for that interface go down and then come back up.

• Release 16.3 introduces a feature that you can use to configure the preferred tunnel interface to use to exchange traffic with the vManage NMS. In the vManage NMS, you configure this on cellular, Ethernet, and PPP Interface feature templates, in the vManage Connection Preference field under Tunnel Interface. In the CLI, you configure this with the vmanage-connection-preference command. The preference value can be from 0 through 8, with a lower number more preferable. The default value is 5. If you set the preference value to 0, that tunnel interface is never used to exchange traffic with the vManage NMS, and it is never able to send or receive any overlay network control traffic.

  With this configuration option, there is one situation in which you can accidentally configure a device such that it loses all its control connections to all Cisco vSmart Controller devices (the vManage NMSs and the vSmart controllers). If you create feature templates and then consolidate them into a device template for the first time, the NMS software checks whether each device has at least one tunnel interface. If not, a software error is displayed. However, when a device template is already attached to a device, if you modify one of its feature templates such that the connection preference on all tunnel interfaces is 0, when you update the device with the changes, no software check is performed, because only the configuration changes are pushed to the device, not the entire device template. As a result, these devices lose all their control connections. To avoid this issue, ensure that the vManage connection preference on at least one tunnel interface is set either to the default or to a non-0 preference value.

Interfaces

• On virtual interfaces, such as IRB, loopback, and system interfaces, the duplex and speed attributes do not apply, and you cannot configure these properties on the interfaces.

• When a vEdge router has two or more NAT interfaces, and hence two or more DIA connections to the internet, by default, data traffic is forwarding on the NAT interfaces using ECMP. To direct data traffic to a specific DIA interface, configure a centralized data policy on the vSmart controller that sets two actions—nat and local-tloc color. In the local-tloc color action, specify the color of the TLOC that connects to the desired DIA connection.

• When configuring interfaces for an IOS XE router using one of the VPN Interface feature configuration templates, you must spell out the interface names completely. For example, you must type GigabitEthernet0/0/0. Also, you must define all the interfaces in the router even if you are not using them so that they are configured in the shutdown state and so that all default values for them are configured.

• For IOS XE routers that have a DSLAM module plugged in, you must include the VPN Interface DSL PPPoA or the VPN Interface DSL PPPoE feature configuration template in the device configuration template to successfully configure the routers from vManage NMS.

IPv6

• You can configure IPv6 only on physical interfaces (ge and eth interfaces), loopback interfaces (loopback0, loopback1, and so on), and on subinterfaces (such as ge0/1.1).

• For IPv6 WAN interfaces in VPN 0, you cannot configure more than two TLOCs on the vEdge router. If you configure more than two, control connections between the router and the Cisco vSmart Controller might not come up.

• IPv6 transport is supported over IPsec encapsulation. GRE encapsulation is not supported.

• You cannot configure NAT and TLOC extensions on IPv6 interfaces.

• HMAC failure due to incorrect stale nat fixup entry for the ipsec session after symnat session flap.

• DHCPv6 returns only an IPv6 address. No default information is accepted. IPv6 router solicitation and router advertisement messages are not processed.

IRB

• On integrated routing and bridging (IRB) interfaces, you cannot configure autonegotiation.

NAT

• When you reboot a vSmart controller, the BFD sessions for all symmetric NAT devices go down and come back up. This is expected behavior.

Policy

• In policy definitions, any application list or application family list that you define with an app-list option cannot have more than 10 items per list.

• NAT DIA with matching app-list is not supported offically. All Cisco vEdge devices and Cisco IOS XE SD-WAN devices share the same limitation. Please evaluate other options like the Cloud Express feature for SAAS DCA capabilities.

Routing Protocols

• When a vEdge router transport interface is using an old IPv6 SLAAC address for control connections or BFD sessions, or both, the IP address used for control connections and BFD might become out of sync with the actual IPv6 address. This situation can happen when the IPv6 address that SLAAC advertises from the gateway router changes suddenly and the old IPv6 address has not first been invalidated. As a workaround, if the router has no mechanism to invalidate older prefixes when the IPv6 prefix changes, first remove the router-advertisement configuration on the default gateway router and then change the IPv6 address. To resolve this problem when it occurs on a vEdge router, shut down the interface and then restart it; that is, issue a shutdown command, followed by a no shutdown command.

• When you configure OSPF using a vManage NMS device configuration template, the configuration of an NSSA area or a stub area and the configuration of an area range are not pushed to the router when you attach the device configuration template to the router. As a workaround, configure these parameters in CLI mode on the router, from the vManage Tools ► SSH Terminal screen, using the OSPF area and range configuration commands.

Security

• It is recommended that you use IKE Version 2 only with Palo Alto Networks and Ubuntu strongSwan systems. Cisco SD-WAN has not tested IKE Version 2 with other systems.

SNMP

• When you configure an SNMP trap target address, you must use an IPv4 address.

• The Cisco SD-WAN interface MIB supports both 32-bit and 64-bit counters, and by default sends 64-bit counters. If you are using an SNMP monitoring tool that does not recognize 64-bit counters, configure it to read 32-bit MIB counters.

• On a vEdge router, if you perform an snmpwalk getnext request for an OID for which there is no information, the response that is returned is the next available instance of that OID. This is the expected behavior.

T1/E1

• If you wish to change the card and controller type on the device, you must first remove the previously configured card and controller and reboot the device.

• You cannot configure rollback or load override features on a multilink interface.

• PPP multilink QoS is currently not supported in the VPN Interface Multilink template.

• PPP multilink NAT is currently not supported in the VPN Interface Multilink template.

• For a vEdge Cloud VM instance on the KVM hypervisor, for Cisco SD-WAN Releases 16.2.2 and later, it is recommended that you use virtio interfaces. For software versions earlier than Release 16.2.2, if you are using the Ubuntu 14.04 or 16.04 LTS operating system, you can use IDE, virtio, or virtio-scsi interfaces.

vManage NMS

• On a Cisco vEdge device that is being managed by a vManage NMS system, if you edit the device's configuration from the CLI, when you issue the commit command, you are prompted to confirm the commit operation. For example:

  vEdge(config-banner)# commit

  The following warnings were generated:

  'system is-vmanaged': This device is being managed by the vManage. Any configuration changes to this device will be overwritten by the vManage. Proceed? [yes,no]

  You must enter either yes or no in response to this prompt.

  During the period of time between when you type commit and when you type either yes or no, the device's configuration database is locked. When the configuration database on a device is locked, the vManage NMS is not able to push a configuration to the device, and from the vManage NMS, you are not able to switch the device to CLI mode.

• The members of a vManage cluster rely on timestamps to synchronize data and to track device uptime. For this time-dependent data to remain accurate, do not change the clock time on any one of the vManage servers of the cluster after you create the cluster.

• When you use the vManage Maintenance ► Software Upgrade screen to set the default software version for a network device, that device must be running Release 16.1 or later at the time you set the default software version. If the network device is running Release 15.4 or earlier, use the CLI request software set-default command to set the default software version for that device.

• When you are using a vManage cluster, when you are bring up a new vManage NMS in the cluster, use an existing vManage NMS to install the certificate on the new vManage NMS.

• In vManage feature configuration templates, for the passwords listed below, you cannot enter a cleartext password that starts with $6 or $8. You can, however, use such passwords when you are configuring from the CLI.

  • Neighbor password, in the BGP feature configuration template.

  • User password, in the Cellular Profile feature configuration template.

  • Authentication type password and privacy type password, in the SNMP feature configuration template.

  • RADIUS secret key and TACACS+ secret key, in the System feature configuration template.

  • IEEE 802.1X secret key, in the VPN Interface Ethernet feature configuration template.

  • IPsec IKE authentication preshared key, in the VPN Interface IPsec feature configuration template.

  • CHAP and PAP passwords, in the VPN Interface PPP Ethernet feature configuration template.

  • Wireless LAN WPA key, in the WiFi SSID feature configuration template.

• PPP CHAP is currently not supported in the VPN Interface Multilink template.

• PPP multilink fragmentation is currently not supported in the VPN Interface Multilink template.

• If a serial interface is bundled into a multilink interface, you cannot remove it from the vManage NMS.

• After you attach the VPN Interface Multilink template to a device, you cannot detach it from the device.

Licensing

• The maximum aggregated cyrpto throughput for the ISR 1000 series routers is 250 Mbps. HSECK9 license is required to achieve IPSec tunnel scale greater than 100 on ISR1000 series routers.

• Base licensing package of AX needs to be enabled for IOS-XE SDWAN ISRv during VM deployment on the ENCS portal.

To upgrade your Cisco vEdge device to Cisco SD-WAN Release 18.4:

1. In vManage NMS, select the Maintenance > Software Upgrade screen.

2. Upgrade the controller devices to Release 18.4 in the following order:

   1. Upgrade the vManage NMSs in the overlay network.

   2. Upgrade the vBond orchestrators.

   3. Upgrade the vSmart controllers.

3. Select the Monitor > Network screen.

4. Select the devices you just upgraded, click the Control Connections tab, and verify that control connections have been established.

5. Select the Maintenance > Software Upgrade screen, and upgrade the vEdge routers.

Because of software changes in Release 16.3, you must modify the router configuration as follows before you upgrade from Release 16.2 or earlier to Release 18.3:

• Use max-control-connections 0 instead of the no control-connections command in tunnel-interface configuration mode. The no control-connections command has been deprecated and has no effect on releases 17.2 and later.

• You can no longer configure RED drops on low-latency queuing (LLQ; queue 0). That is, if you include the policy qos-scheduler scheduling llq command in the configuration, you cannot configure drops red-drop in the same QoS scheduler. If your vEdge router has this configuration, remove it before upgrading to Release 17.2. If you do not remove the RED drop configuration, the configuration process (confd) fails after you perform the software upgrade, and the Cisco vEdge device roll back to their previous configuration.

• For vEdge 2000 routers, you can no longer configure interfaces that are not present in the router. That is, the interface names in the configuration must match the type of PIM installed in the router. For example, if the PIM module in slot 1 is a 10-Gigabit Ethernet PIM, the configuration must refer to the proper interface name, for example,10ge1/0, and not ge1/0. If the interface name does not match the PIM type, the software upgrade fails. Before you upgrade from Release 16.2 or earlier to Release 17.2, ensure that the interface names in the router configurations are correct.