Configure Load-Balancing Algorithm Using the CLI

Note	Starting from Cisco IOS XE Catalyst SD-WAN Release 17.8.1a, you need CLI template to configure the src-only load-sharing algorithm for IPv4 and IPv6 Cisco Catalyst SD-WAN and non Cisco Catalyst SD-WAN traffic. For complete details on the load-sharing algorithm CLI, see IP Commands list.

This following provides CLI configurations for selecting a Cisco Express Forwarding load-balancing algorithm for non Cisco Catalyst SD-WAN IPv4 and IPv6 traffic. You can enable ECMP keying to send the configurations for both IPv4 and IPv6.

Device# config-transaction
Device(config)# ip cef load-sharing algorithm {universal [id] | include-ports [ source [id] | destination [id]] |
src-only [id]}

Device# config-transaction
Device(config)# ipv6 cef load-sharing algorithm {universal [id] | include-ports [ source [id] | destination [id]] |
src-only [id]}

This following provides CLI configurations for enabling load balancing algorithm on an interface for Cisco Catalyst SD-WAN IPv4 and IPv6 traffic. You can enable ECMP keying to send the configurations for both IPv4 and IPv6.

Device# config-transaction
Device(config)# sdwan
Device(config-sdwan)# ip load-sharing algorithm {ip-and-ports | src-dst-ip | src-ip-only}

Device# config-transaction
Device(config)# sdwan
Device(config-sdwan)# ipv6 load-sharing algorithm {ip-and-ports | src-dst-ip | src-ip-only}

Mapping Host Names to IP Addresses

! IP DNS-based host name-to-address translation is enabled
  ip domain lookup
! Specifies hosts 192.168.1.111 and 192.168.1.2 as name servers
  ip name-server 192.168.1.111 192.168.1.2
! Defines cisco.com as the default domain name the device uses to complete
! Set the name for unqualified host names  
  ip domain name cisco.com

This topic describes how to configure the general properties of WAN transport and service-side network interfaces. For information about how to configure specific interface types and properties—including cellular interfaces, DHCP, PPPoE, VRRP, and WLAN interfaces.

VPN 0 is the WAN transport VPN. This VPN handles all control plane traffic, which is carried over OMP sessions, in the overlay network. For a Cisco IOS XE Catalyst SD-WAN device device to participate in the overlay network, at least one interface must be configured in VPN 0, and at least one interface must connect to a WAN transport network, such as the Internet or an MPLS or a metro Ethernet network. This WAN transport interface is referred to as a tunnel interface. At a minimum, for this interface, you must configure an IP address, enable the interface, and set it to be a tunnel interface.

To configure a tunnel interface on a Cisco Catalyst SD-WAN Controller or a Cisco SD-WAN Manager, you create an interface in VPN 0, assign an IP address or configure the interface to receive an IP address from DHCP, and mark it as a tunnel interface. The IP address can be either an IPv4 or IPv6 address. To enable dual stack, configure both address types. You can optionally associate a color with the tunnel.

Note	You can configure IPv6 addresses only on transport interfaces in VPN 0 and but not supported in VPN 512.

Tunnel interfaces on Cisco IOS XE Catalyst SD-WAN devices must have an IP address, a color, and an encapsulation type. The IP address can be either an IPv4 or IPv6 address. To enable dual stack in releases before Cisco IOS XE Catalyst SD-WAN Release 17.3.2, configure both address types.

To use dual stack with Cisco IOS XE Catalyst SD-WAN devices from Cisco IOS XE Catalyst SD-WAN Release 17.3.2, configure all controllers with both IPv4 and IPv6 addresses. In addition, configure DNS for the Cisco Catalyst SD-WAN Validator interface to resolve IPv4 and IPv6 address types so that controllers can reach the Cisco Catalyst SD-WAN Validator through either IP address type.

Note	Starting from Cisco vManage Release 20.6.1, in case of a dual-stack configuration, if an IPv4 address or the fully qualified domain name (FQDN) is not available, but an IPv6 address is available, then the IPv6 address is used to connect to the Cisco Catalyst SD-WAN Validator.

For the tunnel interface, you can configure a static IPv4 or IPv6 address, or you can configure the interface to receive its address from a DHCP server. To enable dual stack, configure both an IPv4 and an IPv6 address on the tunnel interface.

From Cisco IOS XE Catalyst SD-WAN Release 17.3.2, Cisco IOS XE Catalyst SD-WAN devices do not support dual stack on the same TLOC or interface. Only one address type can be provisioned for a TLOC or interface. Using a second address type requires a second TLOC or interface on which it can be provisioned.

On Cisco Catalyst SD-WAN Controllers and Cisco Catalyst SD-WAN Controller NMSs, interface-name can be either eth number or loopback number. Because Cisco Catalyst SD-WAN Controllers and Cisco Catalyst SD-WAN Controller NMSs participate only in the overlay network's control plane, the VPNs that you can configure on these devices are VPN 0 and VPN 512. Hence, all interfaces are present only on these VPNs.

To enable the interface, include the no shutdown command.

Color is a Cisco Catalyst SD-WAN software construct that identifies the transport tunnel. It can be 3g, biz-internet, blue, bronze, custom1, custom2, custom3, default, gold, green, lte, metro-ethernet, mpls, private1 through private6, public-internet, red, and silver. The colors metro-ethernet, mpls, and private1 through private6 are referred to as private colors, because they use private addresses to connect to the remote side Cisco IOS XE Catalyst SD-WAN device in a private network. You can use these colors in a public network provided that there is no NAT device between the local and remote Cisco IOS XE Catalyst SD-WAN devices.

To limit the remote TLOCs that the local TLOC can establish BFD sessions with, mark the TLOC with the restrict option. When a TLOC is marked as restricted, a TLOC on the local router establishes tunnel connections with a remote TLOC only if the remote TLOC has the same color.

Note

When a WAN edge device is configured with two IPv6 TLOCs, one with static default route and the other one with IPv6 address autoconfig default which is the IPv6 neighbor discovery default route, the IPv6 neighbor discovery default route is not installed in the routing table. In this case, the IPv6 TLOC with IPv6 neighbor discovery default route does not work. For IPv6 TLOC with IPv6 neighbor discovery default route to work, you can configure the static route for TLOC with IPv6 neighbor discovery to overwrite the IPv6 neighbor discovery default route and ensure that both the static routes are installed into the routing table. You can also use the IPv6 neighbor discovery default route on all interfaces.

On a Cisco Catalyst SD-WAN Controller or Cisco Catalyst SD-WAN Controller NMS, you can configure one tunnel interface. On a Cisco IOS XE Catalyst SD-WAN device, you can configure up to eight tunnel interfaces.

On Cisco IOS XE Catalyst SD-WAN devices, you must configure the tunnel encapsulation. The encapsulation can be either IPsec or GRE. For IPsec encapsulation, the default MTU is 1442 bytes, and for GRE it is 1468 bytes, These values are a function of overhead required for BFD path MTU discovery, which is enabled by default on all TLOCs. (For more information, see Configuring Control Plane and Data Plane High Availability Parameters.) You can configure both IPsec and GRE encapsulation by including two encapsulation commands under the same tunnel-interface command. On the remote Cisco IOS XE Catalyst SD-WAN device, you must configure the same tunnel encapsulation type or types so that the two routers can exchange data traffic. Data transmitted out of an IPsec tunnel can be received only by an IPsec tunnel, and data sent on a GRE tunnel can be received only by a GRE tunnel. The Cisco Catalyst SD-WAN software automatically selects the correct tunnel on the destination Cisco IOS XE Catalyst SD-WAN device.

A tunnel interface allows only DTLS, TLS, and, for Cisco IOS XE Catalyst SD-WAN devices, IPsec traffic to pass through the tunnel. To allow additional traffic to pass without having to create explicit policies or access lists, enable them by including one allow-service command for each service. You can also explicitly disallow services by including the no allow-service command. Note that services affect only physical interfaces. You can allow or disallow these services on a tunnel interface:

The allow-service stun command pertains to allowing or disallowing a Cisco IOS XE Catalyst SD-WAN device to generate requests to a generic STUN server so that the device can determine whether it is behind a NAT and, if so, what kind of NAT it is and what the device's public IP address and public port number are. On a Cisco IOS XE Catalyst SD-WAN device that is behind a NAT, you can also have tunnel interface to discover its public IP address and port number from the Cisco Catalyst SD-WAN Validator.

With this configuration, the Cisco IOS XE Catalyst SD-WAN device uses the Cisco Catalyst SD-WAN Validator as a STUN server, so the router can determine its public IP address and public port number. (With this configuration, the router cannot learn the type of NAT that it is behind.) No overlay network control traffic is sent and no keys are exchanged over tunnel interface configured to the the Cisco Catalyst SD-WAN Validator as a STUN server. However, BFD does come up on the tunnel, and data traffic can be sent on it. Because no control traffic is sent over a tunnel interface that is configured to use the Cisco Catalyst SD-WAN Validator as a STUN server, you must configure at least one other tunnel interface on the Cisco IOS XE Catalyst SD-WAN device so that it can exchange control traffic with the Cisco Catalyst SD-WAN Controller and the Cisco Catalyst SD-WAN Controller NMS.

You can log the headers of all packets that are dropped because they do not match a service configured with an allow-service command. You can use these logs for security purposes, for example, to monitor the flows that are being directed to a WAN interface and to determine, in the case of a DDoS attack, which IP addresses to block.

For each Cisco IOS XE Catalyst SD-WAN device, you configure a system interface with the system system-ip command. The system interface's IP address is a persistent address that identifies the Cisco IOS XE Catalyst SD-WAN device. It is similar to a router ID on a regular router, which is the address used to identify the router from which packets originated.

Specify the system IP address as an IPv4 address in decimal four-part dotted notation. Specify just the address; the prefix length (/32) is implicit.

The system IP address can be any IPv4 address except for 0.0.0.0/8, 127.0.0.0/8, and 224.0.0.0/4, and 240.0.0.0/4 and later. Each device in the overlay network must have a unique system IP address. You cannot use this same address for another interface in VPN 0.

The system interface is placed in VPN 0, as a loopback interface named system. Note that this is not the same as a loopback address that you configure for an interface.

To display information about the system interface, use the show interface command. For example:

The system IP address is used as one of the attributes of the OMP TLOC. Each TLOC is uniquely identified by a 3-tuple comprising the system IP address, a color, and an encapsulation. To display TLOC information, use the show omp tlocs command.

For device management purposes, it is recommended as a best practice that you also configure the same system IP address on a loopback interface that is located in a service-side VPN that is an appropriate VPN for management purposes. You use a loopback interface because it is always reachable when the router is operational and when the overlay network is up. If you were to configure the system IP address on a physical interface, both the router and the interface would have to be up for the router to be reachable. You use a service-side VPN because it is reachable from the data center. Service-side VPNs are VPNs other than VPN 0 (the WAN transport VPN) and VPN 512 (the management VPN), and they are used to route data traffic.

A highly available Cisco Catalyst SD-WAN network contains two or more Cisco Catalyst SD-WAN Controllers in each domain. A Cisco Catalyst SD-WAN domain can have up to eight Cisco Catalyst SD-WAN Controllers, and each Cisco IOS XE Catalyst SD-WAN device, by default, connects to two of them. You change this value on a per-tunnel basis:

Configure Interfaces in the Management (VRF mgmt-intf)

On all Cisco Catalyst SD-WAN devices, VPN 512 is used for out-of-band management, by default as part of the factory-default configuration. On Cisco IOS XE Catalyst SD-WAN devices the management VPN is converted to VRF Mgmt-Intf.

Cisco XE SD-WAN devices use VRFs in place of VPNs.

Device# show sdwan running-config | sec vrf definition Mgmt-intf

vrf definition Mgmt-intf
 address-family ipv4
  exit-address-family
 !
 address-family ipv6
  exit-address-family
 !
============
interface GigabitEthernet0
 no shutdown
 vrf forwarding Mgmt-intf
 negotiation auto
exit
============
config-t
ip route vrf Mgmt-intf 0.0.0.0 0.0.0.0

vrf definition Mgmt-intf
 rd 1:512
 !
 address-family ipv4
  route-target export 1:512
  route-target import 1:512
 exit-address-family
 !
 address-family ipv6
 exit-address-family
!
!
interface GigabitEthernet1
 vrf forwarding Mgmt-intf
 ip address 192.168.20.11 255.255.255.0
!
ip route vrf Mgmt-intf 0.0.0.0 0.0.0.0 
! 

To display information about the configured management interfaces, use the show interface command. For example:

Device# show interface gigabitEthernet0 
GigabitEthernet0 is up, line protocol is up 
  Hardware is RP management port, address is d478.9bfe.9f7f (bia d478.9bfe.9f7f)
  Internet address is 10.34.9.177/16
  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full Duplex, 1000Mbps, link type is auto, media type is RJ45
  output flow-control is unsupported, input flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 8000 bits/sec, 12 packets/sec
  5 minute output rate 1000 bits/sec, 2 packets/sec
     4839793 packets input, 415574814 bytes, 0 no buffer
     Received 3060073 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles 
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 0 multicast, 0 pause input
     82246 packets output, 41970224 bytes, 0 underruns
     Output 0 broadcasts (0 IP multicasts)
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 pause output
     0 output buffer failures, 0 output buffers swapped out

Note	VPN 512 is not advertised in the overlay. It is local to the device. If you need a management VPN that is reachable through the overlay, create a VPN with a number other than 512.

When a Cisco IOS XE Catalyst SD-WAN device comes up, the Cisco Catalyst SD-WAN software autodetects the SFPs present in the router and sets the interface speed accordingly. The software then negotiates the interface speed with the device at the remote end of the connection to establish the actual speed of the interface. To display the hardware present in the router, use the show hardware inventory command:

To display the actual speed of each interface, use the show interface command. Here, interface ge0/0, which connects to the WAN cloud, is running at 1000 Mbps (1Gbps; it is the 1GE PIM highlighted in the output above), and interface ge0/1, which connects to a device at the local site, has negotiated a speed of 100 Mbps.

For non-physical interfaces, such as those for the system IP address and loopback interfaces, the interface speed is set by default to 10 Mbps.

To override the speed negotiated by the two devices on the interface, disable autonegotiation and configure the desired speed:

For Cisco Catalyst SD-WAN Controllers and Cisco SD-WAN Manager systems, the initial interface speeds are 1000 Mbps, and the operating speed is negotiated with the device at the remote end of the interface. The controller interface speed may vary depending upon the virtualization platform, the NIC used, and the drivers that are present in the software.

By default, all interfaces have an MTU of 1500 bytes. You can modify this on an interface:

For releases earlier than Cisco IOS XE Catalyst SD-WAN Release 17.4.1a the MTU can range from 576 through 2000 bytes.

Starting from release Cisco IOS XE Catalyst SD-WAN Release 17.4.1a the MTU can range from 576 through 9216 bytes on 1 GE interfaces. This MTU range is also supported on 10 GE and 100 GE interfaces starting from Cisco IOS XE Catalyst SD-WAN Release 17.5.1a.

To display an interface's MTU, use the show interface command.

For Cisco Catalyst SD-WAN Validator, Cisco SD-WAN Manager, and Cisco Catalyst SD-WAN Controller devices, you can configure interfaces to use ICMP to perform path MTU (PMTU) discovery. When PMTU discovery is enabled, the device to automatically negotiates the largest MTU size that the interface supports in an attempt to minimize or eliminate packet fragmentation:

On Cisco IOS XE Catalyst SD-WAN device, the Cisco Catalyst SD-WAN BFD software automatically performs PMTU discovery on each transport connection (that is, for each TLOC, or color). BFD PMTU discovery is enabled by default, and it is recommended that you use it and not disable it. To explicitly configure BFD to perform PMTU discovery, use the bfd color pmtu-discovery configuration command. However, you can choose to instead use ICMP to perform PMTU discovery:vEdge Cloud router

BFD is a data plane protocol and so does not run on Cisco Catalyst SD-WAN Validator, Cisco SD-WAN Manager, and Cisco Catalyst SD-WAN Controller devices.

Enable Boost Mode Using a CLI Template

For more information about using CLI templates, see CLI Add-On Feature Templates and CLI Templates.

Note	By default, CLI templates execute commands in global config mode.

This section provides example CLI configurations to enable the boost mode.

1. Enable the boost mode:

   platform ipreass boost-mode

Here is the complete configuration example to enable the boost mode:

platform ipreass boost-mode

Enable VFR for IPv4 packets on Inbound Interface Traffic

1. Configure an interface type and enter interface configuration mode:

   interface interface-type interface-number

2. Enable VFR on the interface and specify the maximum threshold values:

   ip virtual-reassembly [max-reassemblies number ] [max-fragments number ] [timeout seconds ] [mode modes][drop-fragments ]

Here is the complete configuration example to enable VFR for IPv4 packets:

interface GigabitEthernet5
ip virtual-reassembly max-reassemblies 64 max-fragments 16 mode default timeout 5

Enable VFR for IPv4 packets on Outbound Interface Traffic

1. Configure an interface type and enter interface configuration mode:

   interface interface-type interface-number

2. Enable VFR for outbound interface traffic on the interface and specify the maximum threshold values:

   ip virtual-reassembly-out [max-reassemblies number ] [max-fragments number ] [timeout seconds ] [mode modes][drop-fragments ]

Here is the complete configuration example to enable VFR for IPv4 packets:

interface GigabitEthernet 5
ip virtual-reassembly-out mode default max-fragments 64

Enable VFR for IPv6 packets on Inbound Interface Traffic

1. Configure an interface type and enter interface configuration mode:

   interface interface-type interface-number

2. Enable VFR for IPv6 packets on inbound interface traffic

   ipv6 virtual-reassembly [in | out][max-reassemblies number ] [max-fragments number ] [timeout seconds ] [mode modes][drop-fragments ]

Here is the complete configuration example to enable VFR for IPv6 packets:

interface GigabitEthernet 5
ipv6 virtual-reassembly in mode default max-fragments 25
max-reassemblies 1024

Enable VFR for IPv6 packets on Outbound Interface Traffic

1. Configure an interface type and enter interface configuration mode:

   interface interface-type interface-number

2. Enable VFR for IPv6 packets on outbound interface traffic

   ipv6 virtual-reassembly [in | out][max-reassemblies number ] [max-fragments number ] [timeout seconds ] [mode modes][drop-fragments ]

Here is the complete configuration example to enable VFR for IPv6 packets:

interface GigabitEthernet 5
ipv6 virtual-reassembly out mode default max-fragments 25

Monitor VFR for IPv4 packets

The following is a sample output from the show ip virtual-reassembly command:

Device# show ip virtual-reassembly GigabitEthernet 5
GigabitEthernet5:                                                                                                              
   Virtual Fragment Reassembly (VFR) is ENABLED [out]                                                                          
   Concurrent reassemblies (max-reassemblies): 16                                                                              
   Fragments per reassembly (max-fragments): 32                                                                                
   Reassembly timeout (timeout): 3 seconds                                                                                     
   Drop fragments: OFF                                                                                                         
                                                                                                                               
   Current reassembly count:0                                                                                                  
   Current fragment count:0                                                                                                    
   Total reassembly count:12                                                                                                  
   Total reassembly timeout

The example shows if VFR for IPv4 is enabled or not. Virtual Fragment Reassembly (VFR) is ENABLED [out] signifies that VFR is enabled. The total packets that underwent reassembly are also displayed.

Monitor VFR for IPv6 packets

The following is a sample output from the show ipv6 virtual-reassembly command:

Device# show ipv6 virtual-reassembly GigabitEthernet 5
GigabitEthernet5:                                                                                                              
   IPv6 Virtual Fragment Reassembly (IPV6VFR) is ENABLED [out]                                                                 
   IPv6 configured concurrent reassemblies (max-reassemblies): 64                                                              
   IPv6 configured fragments per reassembly (max-fragments): 16                                                                
   IPv6 configured reassembly timeout (timeout): 3 seconds                                                                     
   IPv6 configured drop fragments: OFF                                                                                         
                                                                                                                               
   IPv6 current reassembly count:0                                                                                             
   IPv6 current fragment count:0                                                                                               
   IPv6 total reassembly count:12                                                                                               
   IPv6 total reassembly timeout count:0

The example shows if VFR for IPv6 is enabled or not. Virtual Fragment Reassembly (VFR) is ENABLED [out] signifies that VFR is enabled. The total packets that underwent reassembly are also displayed.

Monitor Underlay Fragmentation

The following is a sample output from the show ip traffic interface GigabitEthernet 1 command:

Device# show ip traffic interface GigabitEthernet 1
GigabitEthernet 1 statistics :                                                                                                    
  Rcvd:  11048818 total, 749458331 total_bytes                                                                                 
         0 format errors, 0 hop count exceeded                                                                                 
         0 bad header, 0 no route                                                                                              
         0 bad destination, 0 not a router                                                                                     
         0 no protocol, 0 truncated                                                                                            
         0 forwarded                                                                                                           
         0 fragments, 0 total reassembled                                                                                      
         0 reassembly timeouts, 0 reassembly failures                                                                          
         0 discards, 0 delivers                                                                                                
  Sent:  0 total, 0 total_bytes 0 discards                                                                                     
         0 generated, 0 forwarded                                                                                              
         0 fragmented into, 0 fragments, 0 failed                                                                              
  Mcast: 0 received, 0 received bytes                                                                                          
         0 sent, 0 sent bytes                                                                                                  
  Bcast: 0 received, 1256 sent

The example shows the number of packets that were sent and received, including the total number of packets. A change from the previous number of packet tranfer indicates that underlay fragmentation is enabled.

The following is a sample output from show sdwan ftm tloc-list command:

Device# show sdwan ftm tloc-list

--- LOCAL  TLOC LIST ---                                                                                                       
                                                                                                                               
                                                                                                                               
Id: 32775 (binosId=0xf808007f), Tenant Id: 0      LocalTLOC, num-nhops: 0   ,hash: 0, ref: 1    SLA 0x0:0x0 Inner-fragmentation
-disable: No                                                                                                                   
                                                                                                                               
[TOTAL-LOCAL-TLOC:1]                                                                                                           
                                                                                                                               
                                                                                                                               
--- REMOTE TLOC LIST ---                                                                                                       
                                                                                                                               
                                                                                                                               
Id: 32768 (binosId=0xf808000f), Tenant Id: 0       SLAClass, num-nhops: 0   ,hash: 0, ref: 1    SLA 0x0:0x0                    
 num-active-nhops: 0                                                                                                           
                                                                                                                               
Id: 32774 (binosId=0xf808006f), Tenant Id: 0       SLAClass, num-nhops: 1   ,hash: 0, ref: 1    SLA 0x1:0x0                    
 [nhop1] nhop-Id: 19   , Type: IPsec     , Encap: IPSEC SLA 0x1:0x0hw_record_index:   5 198.100.1.5/12366->198.100.1.6/12346 pr
oto 0x800 hash 0x13 wan-if 3 tloc 32774 R-color mpls local-tloc 32775 L-color mpls BFD UP tloc-capability 0 SLA 0x1:0x0 weight 
1   pref 0                                                                                                                     
 num-active-nhops: 1                                                                                                           
                                                                                                                               
[TOTAL-REMOTE-TLOC:2]                                                                                                          
                                                                                                                               
--- PENDING TLOC LIST (is_pending_updates:FALSE)---                                                                            
                                                                                                                               
                                                                                                                               
[TOTAL-PENDING-TLOC:0]                                                                                                         
                                                                                                                               
                                                                                                                               
--- UNMATCHED TLOC LIST (is_pending_updates:FALSE)---                                                                          
                                                                                                                               
                                                                                                                               
[TOTAL-UNMATCHED-TLOC:0]                                                                                                       
                                                                                                                               

--- TENANT LOCAL  TLOC LIST --- 

The example displays all the local TLOCs in the network.

The following is a sample output from show platform software sdwan R0 next-hop overlay all command:

Device# show platform software sdwan R0 next-hop overlay all

Show sdwan next-hop oce all :                                                                                                  
                                                                                                                               
OCE ID: 0xf800013f, OCE Type: SDWAN_NH_OVERLAY                                                                                 
Overlay: client_handle (nil), ppe addr (nil)                                                                                   
  overlay encap: ipsec                                                                                                         
  src-ip: 198.100.1.5, src-port: 12366                                                                                         
  dst-ip: 198.100.1.6, dst-port: 12346                                                                                         
  flags: 0x0, linktype: MCP_LINK_IP, ifhandle: 15, encap type: MCP_ET_NULL                                                     
  encap rewrite: 00                                                                                                            
  mtu: 1446, fixup: 0x0, fixup_flags_2: 0x0, color: mpls, phy_oce_handle: 31, nh_overlay_h: 0xf800013f                         
    Overlay_CFG:                                                                                                               
    encap type: ipsec                                                                                                          
    src-ip: 198.100.1.5, src-port: 12366                                                                                       
    dst-ip: 198.100.1.6, dst-port: 12346                                                                                       
    local_system_ip: 1.1.1.1                                                                                                   
    remote_system_ip: 2.2.2.2                                                                                                  
    local_color: 2 [mpls], remote_color: 2 [mpls]                                                                              
    wan_ifindex: 8 [GigabitEthernet2], tun_ifindex: 15 [Tunnel0]                                                               
    tun_adj_id: 0, l2_adj_id: 0x1f, tunnel_qos_dpidx: 0x0                                                                      
    bfd-ld: 20005, ipsec_flow_id: 603979786, session_id: 5                                                                     
    Inner-fragmentation-disable: yes

The example demonstrates whether the inner fragmentation is disabled or enabled in a particular next-hop overlay.

The following is a sample output from show platform software sdwan F0 next-hop overlay all command:

Device# show platform software sdwan F0 next-hop overlay all

OCE ID: 0xf800013f, OCE Type: SDWAN_NH_OVERLAY                                                                                 
Overlay: client_handle 0x63d321350ba0, ppe addr db910710                                                                       
  overlay encap: ipsec                                                                                                         
  src-ip: 198.100.1.5, src-port: 12366                                                                                         
  dst-ip: 198.100.1.6, dst-port: 12346                                                                                         
  flags: 0x0, linktype: MCP_LINK_SDWAN, ifhandle: 15, encap type: MCP_ET_ARPA                                                  
  encap rewrite: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00                                                   
  mtu: 1446, fixup: 0x0, fixup_flags_2: 0x800000, color: mpls, phy_oce_handle: 31, nh_overlay_h: 0xf800013f                    
    Overlay_CFG:                                                                                                               
    encap type: ipsec                                                                                                          
    src-ip: 198.100.1.5, src-port: 12366                                                                                       
    dst-ip: 198.100.1.6, dst-port: 12346                                                                                       
    local_system_ip: 1.1.1.1                                                                                                   
    remote_system_ip: 2.2.2.2                                                                                                  
    local_color: 2 [mpls], remote_color: 2 [mpls]                                                                              
    wan_ifindex: 8 [GigabitEthernet2], tun_ifindex: 15 [Tunnel0]                                                               
    tun_adj_id: 0, l2_adj_id: 0x1f, tunnel_qos_dpidx: 0x0                                                                      
    bfd-ld: 20005, ipsec_flow_id: 603979786, session_id: 5                                                                     
    Inner-fragmentation-disable: yes

The example demonstrates whether the inner fragmentation is disabled or enabled in all the available overlays.

Limitations

• TCP MSS values can be adjusted for Cisco Catalyst SD-WAN tunnel interfaces only.

  Note

  Beginning with Cisco IOS XE Catalyst SD-WAN Release 17.9.1a and Cisco vManage Release 20.9.1, you can adjust the TCP MSS value for a service VPN or for Network Address Translation (NAT) Direct Internet Access (DIA) use cases. Adjusting the TCP MSS value helps prevent TCP sessions from being dropped. For more information on NAT DIA, see the Cisco Catalyst SD-WAN NAT Configuration Guide, Cisco IOS XE Catalyst SD-WAN Release 17.x.

• The option Clear Dont Fragment is available for Cisco Catalyst SD-WAN tunnel interfaces only.

You can monitor the bandwidth usage on a transport circuit, to determine how the bandwidth usage is trending. If the bandwidth usage starts approaching a maximum value, you can configure the software to send a notification. Notifications are sent as Netconf notifications, which are sent to the Cisco SD-WAN Manager NMS, SNMP traps, and syslog messages. You might want to enable this feature for bandwidth monitoring, such as when you are doing capacity planning for a circuit or when you are gathering trending information about bandwidth utilization. You might also enable this feature to receive alerts regarding bandwidth usage, such as if you need to determine when a transport interface is becoming so saturated with traffic that a customer's traffic is impacted, or when customers have a pay-per-use plan, as might be the case with LTE transport.

To monitor interface bandwidth, you configure the maximum bandwidth for traffic received and transmitted on a transport circuit. The maximum bandwidth is typically the bandwidth that has been negotiated with the circuit provider. When bandwidth usage exceeds 85 percent of the configured value for either received or transmitted traffic, a notification, in the form of an SNMP trap, is generated. Specifically, interface traffic is sampled every 10 seconds. If the received or transmitted bandwidth exceeds 85 percent of the configured value in 85 percent of the sampled intervals in a continuous 5-minute period, an SNMP trap is generated. After the first trap is generated, sampling continues at the same frequency, but notifications are rate-limited to once per hour. A second trap is sent (and subsequent traps are sent) if the bandwidth exceeds 85 percent of the value in 85 percent of the 10-second sampling intervals over the next 1-hour period. If, after 1 hour, another trap is not sent, the notification interval reverts to 5 minutes.

You can monitor transport circuit bandwidth on Cisco IOS XE Catalyst SD-WAN devices and on Cisco SD-WAN Manager NMSs.

To generate notifications when the bandwidth of traffic received on a physical interface exceeds 85 percent of a specific bandwidth, configure the downstream bandwidth:

To generate notifications when the bandwidth of traffic transmitted on a physical interface exceeds 85 percent of a specific bandwidth, configure the upstream bandwidth:

In both configuration commands, the bandwidth can be from 1 through 2147483647 (2³² / 2) – 1 kbps.

To display the configured bandwidths, look at the bandwidth-downstream and bandwidth-upstream fields in the output of the show interface detail command. The rx-kbps and tx-kbps fields in this command shows the current bandwidth usage on the interface.

Use the DHCP-Server template for all Cisco Catalyst SD-WANs.

You enable DHCP server functionality on a Cisco Catalyst SD-WAN device interface so it can assign IP addresses to hosts in the service-side network.

To configure a Cisco Catalyst SD-WAN device to act as a DHCP server using Cisco SD-WAN Manager templates:

1. Create a DHCP-Server feature template to configure DHCP server parameters, as described in this topic.

2. Create one or more interface feature templates, as described in the VPN-Interface-Ethernet and the VPN-Interface-PPP-Ethernet help topics.

3. Create a VPN feature template to configure VPN parameters. See the VPN help topic.

To configure a Cisco IOS XE Catalyst SD-WAN device interface to be a DHCP helper so that it forwards broadcast DHCP requests that it receives from DHCP servers, in the DHCP Helper field of the applicable interfaces template, enter the addresses of the DHCP servers.​

Navigate to the Template Screen and Name the Template

1. From the Cisco SD-WAN Manager menu, choose Configuration > Templates.

2. Click Device Templates, and then click Create Template.

   Note	In Cisco vManage Release 20.7.x and earlier releases, Device Templates is titled Device.

3. From the Create Template drop-down list, choose From Feature Template.

4. From the Device Model drop-down list, select the type of device for which you are creating the template.

5. Click Service VPN or scroll to the Service VPN section.

6. Click Service VPN drop-down list.

7. From Additional VPN Templates, click VPN Interface.

8. From the Sub-Templates drop-down list, choose DHCP Server.

9. From the DHCP Server drop-down list, click Create Template. The DHCP-Server template form is displayed.

   This form contains fields for naming the template, and fields for defining the DHCP Server parameters.

10. In Template Name, enter a name for the template.

    The name can be up to 128 characters and can contain only alphanumeric characters.

11. In Template Description, enter a description of the template.

    The description can be up to 2048 characters and can contain only alphanumeric characters.

When you first open a feature template, for each parameter that has a default value, the scope is set to Default (indicated by a check mark), and the default setting or value is shown. To change the default or to enter a value, click the Scope drop-down list.

Minimum DHCP Server Configuration

To configure DHCP server functionality, select Basic Configuration and configure the following parameters. Parameters marked with an asterisk as required to configure DHCP servers.

To save the feature template, click Save.

Configure Static Leases

To configure a static lease to assign a static IP address to a client device on the service-side network, click Static Lease, and click Add New Static Lease and configure the following parameters:

To edit a static lease, click pencil icon.

To remove a static lease, click trash icon.

To save the feature template, click Save.

Configure Advanced Options

To configure a advanced DHCP server options, click Advanced and then configure the following parameters:

To save the feature template, click Save.

Configure DHCP server using CLI

Device# config-transaction
Device(dhcp-config)# ip dhcp pool DHCP-POOL
Device(dhcp-config)# network 10.1.1.1 255.255.255.0
Device(dhcp-config)# default-router 10.1.1.2
Device(dhcp-config)# dns-server 172.16.0.1
Device(dhcp-config)# domain-name DHCP-DOMAIN
Device(dhcp-config)# exit
Device(config)ip dhcp excluded-address 10.1.1.2 10.1.1.10
Device(

Release Information

Introduced in Cisco SD-WAN Manager in Release 15.2.

The Point-to-Point Protocol over Ethernet (PPPoE) connects multiple users over an Ethernet local area network to a remote site through common customer premises equipment. PPPoE is commonly used in a broadband aggregation, such as by digital subscriber line (DSL). PPPoE provides authentication with the CHAP or PAP protocol. In the Cisco Catalyst SD-WAN overlay network, Cisco Catalyst SD-WAN devices can run the PPPoE client. The PPPoE server component is not supported.

It is recommended that you configure quality of service (QoS) and shaping rate on a PPPoE Dialer interface. Queuing based QoS policies on both Dialer interface and PPPoE-enabled physical interface at the same time, is not supported.

PPPoE-enabled physical interfaces are supported on ATM PVCs and Ethernet interfaces. A dialer interface must be used for cloning virtual access. Multiple PPPoE client sessions can be configured on an Ethernet interface, but each session must use a separate dialer interface and a separate dialer pool.

The Cisco Catalyst SD-WAN implementation of PPPoE does not support the Compression Control Protocol (CCP) options, as defined in RFC 1962.

This example shows configuring PPPoE server on IPv4 interfaces:

!
interface Dialer100
 mtu 1492
 ip address negotiated
 encapsulation ppp
 ip tcp adjust-mss 1460
 dialer pool 100
 dialer down-with-vInterface
 ppp authentication chap callin
 ppp chap hostname cisco
 ppp chap password 7 1511021F07257A767B
 ppp ipcp route default

Note	The x710 NIC must have the t->system-> vrrp-advt-with-phymac command configured, for VRRP to function.

The Virtual Router Redundancy Protocol (VRRP) is a LAN-side protocol that provides redundant gateway service for switches and other IP end stations. In the Cisco Catalyst SD-WAN software, you configure VRRP on an interface, and typically on a subinterface, within a VPN.

VRRP is only supported with service-side VPNs (VPN 0 and 512 reserved) and if sub-interfaces are used, then the VRRP physical interface must be configured in VPN 0.

For each VRRP interface (or subinterface), you assign an IP address and you place that interface in a VRRP group.

The group number identifies the virtual router. You can configure a maximum of 512 groups on a router. In a typical VRRP topology, two physical routers are configured to act as a single virtual router, so you configure the same group number on interfaces on both these routers.

For each virtual router ID, you must configure an IP address.

Within each VRRP group, the router with the higher priority value is elected as primary VRRP. By default, each virtual router IP address has a default primary election priority of 100, so the router with the higher IP address is elected as primary. You can modify the priority value, setting it to a value from 1 through 254.

The primary VRRP periodically sends advertisement messages, indicating that it is still operating. If backup routers miss three consecutive VRRP advertisements, they assume that the primary VRRP is down and elect a new primary VRRP. By default, these messages are sent every second. You can change the VRRP advertisement time to be a value from 1 through 3600 seconds.

By default, VRRP uses the state of the interface on which it is running, to determine which router is the primary virtual router. This interface is on the service (LAN) side of the router. When the interface for the primary VRRP goes down, a new primary VRRP virtual router is elected based on the VRRP priority value. Because VRRP runs on a LAN interface, if a router loses all its WAN control connections, the LAN interface still indicates that it is up even though the router is functionally unable to participate in VRRP. To take WAN side connectivity into account for VRRP, you can configure one of the following:

• Track the Overlay Management Protocol (OMP) session running on the WAN connection when determining the primary VRRP virtual router.

If all OMP sessions are lost on the primary VRRP router, VRRP elects a new default gateway from among all the gateways that have one or more active OMP sessions even if the gateway chosen has a lower VRRP priority than the current primary VRRP router. With this option, VRRP failover occurs once the OMP state changes from up to down, which occurs when the OMP hold timer expires. (The default OMP hold timer interval is 60 seconds.) Until the hold timer expires and a new primary VRRP is elected, all overlay traffic is dropped. When the OMP session recovers, the local VRRP interface claims itself as primary VRRP even before it learns and installs OMP routes from the Cisco Catalyst SD-WAN Controllers. Until the routers are learned, traffic is also dropped.

• Track both the OMP session and a list of remote prefixes.

If all OMP sessions are lost, VRRP failover occurs as described for the track-omp option. In addition, if reachability to all the prefixes in the list is lost, VRRP failover occurs immediately, without waiting for the OMP hold timer to expire, thus minimizing the amount of overlay traffic is dropped while the router determines the primary VRRP.

As discussed above, the IEEE 802.1Q protocol adds 4 bytes to each packet's length. Hence, for packets to be transmitted, either increase the MTU size on the physical interface in VPN 0 (the default MTU is 1500 bytes) or decrease the MTU size on the VRRP interface.

For devices running on Cisco IOS XE Catalyst SD-WAN Release 17.4.1a and later, adjusting the MTU size is not required, both the physical interface and sub interface can have the same MTU size.

You can configure dynamic interfaces for supported devices. A dynamic interface allows a device to select optimum paths in real-time.

Configuring dynamic interfaces consists of these general steps:

1. Create a dynamic interface mode feature template. As part of this step, you define modes for the bays in a device.

2. Configure an Interface for Control Connections.

3. Associate the dynamic interface mode feature template with a device template.

Create a Dynamic Interface Mode Feature Template

When you create a dynamic interface mode feature template, you create a template that defines the modes for the bays in a device.

You can configure the mode for bay 1, bay 2, or both.

The mode for bay 0 is configured automatically and cannot be changed. If you configure the mode for bay 1 as 100G, bay 0 is disabled because the 10G interfaces on bay 0 do not apply in this case.

1. From the Cisco SD-WAN Manager menu, choose Configuration > Templates.

2. Click Device Templates.

   Note	In Cisco vManage Release 20.7.x and earlier releases, Device Templates is titled Device.

3. Click the Create Template drop-down list and choose Feature Template.

4. From the Device Model drop-down list, choose the device for which you wish to create the template.

5. In Template Name, enter a name for the template.

   This field may contain uppercase and lowercase letters, digits 0 through 9, hyphens (-), and underscores (_).

6. In Description, enter a description of the template.

   This field can contain any characters and spaces.

7. From Additional Templates, choose the Dynamic Interface Mode drop-down list and click Create Template.

8. In Template Name, enter a name for the template.

   This field may contain uppercase and lowercase letters, digits 0 through 9, hyphens (-), and underscores (_).

9. In Description, enter a description of the template.

   This field can contain any characters and spaces.

10. Configure the mode for bay 1, bay 2, or both bays by choosing the desired value in the Bay 1, Bay 2, or both fields.

    You cannot change the default value for bay 0.

11. Click Save.

Note	Open a TAC case when there is a mismatch between confd and iosd configurations while changing the bay subslot mode on 8500-12X4QC.

Configure an Interface for Control Connections

This section describes how to configure a new VPN 0 interface for an existing control connection to operate with the bays that you configured in “Create a Dynamic Interface Mode Feature Template.” It also describes how to configure an IPv4 route for the interface.

1. From the Cisco SD-WAN Manager menu, choose Configuration > Templates.

2. Click Device Templates.

   Note	In Cisco vManage Release 20.7.x and earlier releases, Device Templates is titled Device.

3. Click ... of the template for which you want to configure the interface, and then choose Edit.

4. Click Transport & Management VPN and perform these actions to create interfaces for the bays:

   1. Click VPN Interface in the Additional VPN 0 Template.

   2. Choose the new VPN Interface Ethernet menu that displays, and then click Create Template.

   3. In Template Name, enter a name for the template.

      This field may contain uppercase and lowercase letters, digits 0 through 9, hyphens (-), and underscores (_).

   4. In Description, enter a description of the template.

      This field can contain any characters and spaces.

   5. Add control connections to the bays that you configured as described in “Create a Dynamic Interface Mode Feature Template.”

5. Choose Basic Configuration and perform these actions:

   1. In Interface Name, enter a name for the interface.

      Enter a name in the format that this example shows: “FortyGigabitEthernet0/1/0.”

   2. Configure other options on this tab as needed.

6. From Tunnel, set Tunnel Interface to On.

7. Click Save.

8. Choose IPv4 Route and perform these actions to configure an IPv4 route for the VPN0 template:

   1. Click New IPv4 Route.

   2. In Prefix, enter a prefix for the IPv4 route.

   3. In Gateway, choose Next Hop.

   4. Configure items as needed in Next Hop, and then click Add.

   5. Click Save.

9. Click Update.

Associate the Dynamic Interface Mode Feature Template with a Device Template

After you create the dynamic interface mode feature template, associate it with a device template and attach the device template to a device. For instructions, see Create a Device Template from Feature Templates.

Use the VPN Interface Bridge template for all Cisco IOS XE Catalyst SD-WAN device Cloud and Cisco IOS XE Catalyst SD-WAN devices.

Integrated routing and bridging (IRB) allows Cisco IOS XE Catalyst SD-WAN devices in different bridge domains to communicate with each other. To enable IRB, create logical IRB interfaces to connect a bridge domain to a VPN. The VPN provides the Layer 3 routing services necessary so that traffic can be exchanged between different VLANs. Each bridge domain can have a single IRB interface and can connect to a single VPN, and a single VPN can connect to multiple bridge domains on a Cisco IOS XE Catalyst SD-WAN device.

To configure a bridge interface using Cisco SD-WAN Manager templates:

1. Create a VPN Interface Bridge feature template to configure parameters for logical IRB interfaces, as described in this article.

2. Create a Bridge feature template for each bridging domain, to configure the bridging domain parameters. See the Bridge help topic.

Navigate to the Template Screen and Name the Template

1. From the Cisco SD-WAN Manager menu, choose Configuration > Templates.

2. Click Device Templates.

   Note	In Cisco vManage Release 20.7.x and earlier releases, Device Templates is titled Device.

3. From the Create Template drop-down list, select From Feature Template.

4. From the Device Model drop-down list, select the type of device for which you are creating the template.

5. Click Service VPN or scroll to the Service VPN section.

6. Click the Service VPN drop-down list.

7. From Additional VPN Templates, click VPN Interface Bridge.

8. From the VPN Interface Bridge drop-down list, click Create Template.

   The VPN Interface Bridge template form is displayed. The top of the form contains fields for naming the template, and the bottom contains fields for defining VPN Interface Bridge parameters.

9. In Template Name, enter a name for the template. The name can be up to 128 characters and can contain only alphanumeric characters.

10. In Template Description, enter a description of the template. The description can be up to 2048 characters and can contain only alphanumeric characters.

When you first open a feature template, for each parameter that has a default value, the scope is set to Default (indicated by a check mark), and the default setting or value is shown. To change the default or to enter a value, click the scope drop-down to the left of the parameter field and select one of the following:

Release Information

Introduced in Cisco SD-WAN Manager NMS in Release 15.3. In Release 18.2, add support for disabling ICMP redirect messages.

Use the IPoE template for Cisco IOS XE Catalyst SD-WAN devices.

You configure IPoE on routers with DSL interfaces, to provide support for service provider digital subscriber line (DSL) functionality.

To configure DSL interfaces on Cisco IOS XE Catalyst SD-WAN devices using Cisco SD-WAN Manager templates:

1. Create a VPN Interface DSL IPoE feature template to configure IP-over-Ethernet interface parameters, as described in this article.

2. Create a VPN feature template to configure VPN parameters. See the VPN help topic.

Navigate to the Template Screen and Name the Template

1. From the Cisco SD-WAN Manager menu, choose Configuration > Templates.

2. Click Device Templates, and click Create Template.

   Note	In Cisco vManage Release 20.7.x and earlier releases, Device Templates is titled Device.

3. From the Create Template drop-down list, choose From Feature Template.

4. From the Device Model drop-down list, select the type of device for which you are creating the template.

5. Click Transport & Management VPN or scroll to the Transport & Management VPN section.

6. Under Additional VPN 0 Templates, click VPN Interface DSL IPoE.

7. From the VPN Interface DSL IPoE drop-down list, choose Create Template. The VPN Interface DSL IPoE template form is displayed.

   This form contains fields for naming the template, fields for defining the IPoE Interface parameters.

8. In Template Name, enter a name for the template. The name can be up to 128 characters and can contain only alphanumeric characters.

9. In Template Description, enter a description of the template. The description can be up to 2048 characters and can contain only alphanumeric characters.

When you first open a feature template, for each parameter that has a default value, the scope is set to Default (indicated by a check mark), and the default setting or value is shown. To change the default or to enter a value, click the Scope drop-down list and choose one of the following:

Configure IPoE Functionality

To configure basic IPoE functionality, click Basic Configuration and configure the following parameters. Required parameters are indicated with an asterisk.

To save the feature template, click Save.

Configure the Ethernet Interface

Configuring an Ethernet interface with PPPoE allows multiple users on a LAN to be connected to a remote site. To configure an Ethernet interface on the VDSL controller, click Ethernet and configure the following parameters. You must configure all parameters.

To save the feature template, click Save.

​Create a Tunnel Interface

On IOS XE routers, you can configure up to eight tunnel interfaces. This means that each router can have up to eight TLOCs.

For the control plane to establish itself so that the overlay network can function, you must configure WAN transport interfaces in VPN 0.

To configure a tunnel interface for the multilink interface, select the Tunnel Interface tab and configure the following parameters:

To configure additional tunnel interface parameters, click Advanced Options and configure the following parameters:

Configure the Interface as a NAT Device

To configure an interface to act as a NAT device for applications such as port forwarding, click NAT, click On, and configure the following parameters:

To create a port forwarding rule, click Add New Port Forwarding Rule and configure the following parameters. You can define up to 128 port-forwarding rules to allow requests from an external network to reach devices on the internal network.

To save a port forwarding rule, click Add.

To save the feature template, click Save.

Apply Access Lists

Configure ACLs to selectively indicate what traffic will enjoy the benefits of QoS. To apply a rewrite rule, access lists, and policers to a router interface, select the ACL tab and configure the following parameters:

To save the feature template, click Save.

Configure Other Interface Properties​

To configure other interface properties, select the Advanced tab and configure the following properties:

To save the feature template, click Save.

Release Information

Introduced in Cisco SD-WAN Manager NMS in Release 18.4.1.

To provide support for service provider digital subscriber line (DSL) functionality, configure PPP-over-ATM interfaces on routers with DSL NIM modules.

Use the VPN Interface DSL PPPoA template for Cisco IOS XE Catalyst SD-WAN devices.

You configure PPP-over-ATM interfaces on routers with DSL NIM modules, to provide support for service provider digital subscriber line (DSL) functionality.

To configure DSL interfaces on Cisco routers using Cisco SD-WAN Manager templates:

1. Create a VPN Interface DSL PPPoA feature template to configure ATM interface parameters, as described in this article.

2. Create a VPN feature template to configure VPN parameters. See the VPN help topic.

Navigate to the Template Screen and Name the Template

1. From the Cisco SD-WAN Manager menu, choose Configuration > Templates.

2. Click Device Templates.

   Note	In Cisco vManage Release 20.7.x and earlier releases, Device Templates is titled Device.

3. From the Create Template drop-down list, select From Feature Template.

4. From the Device Model drop-down list, select the type of device for which you are creating the template.

5. Click Transport & Management VPN or scroll to the Transport & Management VPN section.

6. Under Additional VPN 0 Templates, click VPN Interface DSL PPPoA.

7. From the VPN Interface DSL PPPoA drop-down list, click Create Template. The VPN Interface DSL PPPoA template form is displayed. This form contains fields for naming the template, and fields for defining VPN Interface PPP parameters.

8. In Template Name, enter a name for the template. The name can be up to 128 characters and can contain only alphanumeric characters.

9. In Template Description, enter a description of the template. The description can be up to 2048 characters and can contain only alphanumeric characters.

When you first open a feature template, for each parameter that has a default value, the scope is set to Default (indicated by a check mark), and the default setting or value is shown. To change the default or to enter a value, click the scope drop-down to the left of the parameter field and select one of the following:

Configure VDSL Controller Functionality

To configure basic VDSL controller functionality in a VPN, select Basic Configuration and configure the following parameters. Required parameters are indicated with an asterisk.

To save the feature template, click Save.

Configure the ATM Interface

To configure an ATM interface on the VDSL controller, select ATM and configure the following parameters. You must configure all parameters.

To save the feature template, click Save.

​Configure the PPP Authentication Protocol

To configure the PPP authentication protocol, select PPP and configure the following parameters:

To save the feature template, click Save.

Create a Tunnel Interface

On Cisco IOS XE Catalyst SD-WAN devices, you can configure up to eight tunnel interfaces. This means that each Cisco IOS XE Catalyst SD-WAN device can have up to eight TLOCs.

For the control plane to establish itself so that the overlay network can function, you must configure WAN transport interfaces in VPN 0.

To configure a tunnel interface for the multilink interface, select Tunnel Interface and configure the following parameters:

To configure additional tunnel interface parameters, click Advanced Options and configure the following parameters:

Apply Access Lists

To apply a rewrite rule, access lists, and policers to a router interface, select ACL and configure the following parameters:

To save the feature template, click Save.

Configure Other Interface Properties​

To configure other interface properties, select Advanced and configure the following properties:

To save the feature template, click Save.

Release Information

Introduced in Cisco SD-WAN Manager NMS in Release 18.3.

Use the VPN Interface DSL PPPoE template for Cisco IOS XE Catalyst SD-WAN devices.

You configure PPP-over-Ethernet interfaces on routers with DSL NIM modules, to provide support for service provider digital subscriber line (DSL) functionality.

To configure DSL interfaces on Cisco routers using Cisco SD-WAN Manager templates:

1. Create a VPN Interface DSL PPPoE feature template to configure PPP-over-Ethernet interface parameters, as described in this article.

2. Create a VPN feature template to configure VPN parameters. See the VPN help topic.

Navigate to the Template Screen and Name the Template

1. From the Cisco SD-WAN Manager menu, choose Configuration > Templates.

2. Click Device Templates.

   Note	In Cisco vManage Release 20.7.x and earlier releases, Device Templates is titled Device.

3. From the Create Template drop-down list, select From Feature Template.

4. From the Device Model drop-down list, select the type of device for which you are creating the template.

5. Click Transport & Management VPN or scroll to the Transport & Management VPN section.

6. Under Additional VPN 0 Templates, click VPN Interface DSL PPPoE.

7. From the VPN Interface DSL PPPoE drop-down list, click Create Template. The VPN Interface DSL PPPoE template form is displayed. This form contains fields for naming the template, and fields for defining PPPoE Interface parameters.

8. In Template Name, enter a name for the template. The name can be up to 128 characters and can contain only alphanumeric characters.

9. In Template Description, enter a description of the template. The description can be up to 2048 characters and can contain only alphanumeric characters.

When you first open a feature template, for each parameter that has a default value, the scope is set to Default (indicated by a check mark), and the default setting or value is shown. To change the default or to enter a value, click the scope drop-down to the left of the parameter field and select one of the following:

Configure VDSL Controller Functionality

To configure basic VDSL controller functionality in a VPN, select Basic Configuration and configure the following parameters. Required parameters are indicated with an asterisk.

Note	If your deployment includes devices with DSL, you must include DSL interface templates in Cisco SD-WAN Manager, even if these templates are not used.

To save the feature template, click Save.

Configure the Ethernet Interface on VDSL Controller

To configure an Ethernet interface on the VDSL controller, select Ethernet and configure the following parameters. You must configure all parameters.

To save the feature template, click Save.

​Configure the PPP Authentication Protocol

To configure the PPP authentication protocol, select PPP and configure the following parameters:

To save the feature template, click Save.

Create a Tunnel Interface

On IOS XE routers, you can configure up to eight tunnel interfaces. This means that each router can have up to eight TLOCs.

For the control plane to establish itself so that the overlay network can function, you must configure WAN transport interfaces in VPN 0.

To configure a tunnel interface for the multilink interface, select the Tunnel Interface tab and configure the following parameters:

To configure additional tunnel interface parameters, click Advanced Options and configure the following parameters:

Configure the Interface as a NAT Device

To configure an interface to act as a NAT device for applications such as port forwarding, select NAT, click On and configure the following parameters:

To create a port forwarding rule, click Add New Port Forwarding Rule and configure the following parameters. You can define up to 128 port-forwarding rules to allow requests from an external network to reach devices on the internal network.

To save a port forwarding rule, click Add.

To save the feature template, click Save.

Apply Access Lists

To apply a rewrite rule, access lists, and policers to a router interface, select ACL and configure the following parameters:

To save the feature template, click Save.

Configure Other Interface Properties​

To configure other interface properties, select the Advanced tab and configure the following properties:

To save the feature template, click Save.

Release Information

Introduced in Cisco SD-WAN Manager NMS in Release 18.3.

Use the PPPoE template for Cisco IOS XE Catalyst SD-WAN devices.

You configure PPPoE over GigabitEthernet interfaces on Cisco IOS XE routers, to provide PPPoE client support.

To configure interfaces on Cisco routers using Cisco SD-WAN Manager templates:

1. Create a VPN Interface Ethernet PPPoE feature template to configure Ethernet PPPoE interface parameters, as described in this section.

2. Create a VPN feature template to configure VPN parameters. See VPN help topic.

Navigate to the Template Screen and Name the Template

1. From the Cisco SD-WAN Manager menu, choose Configuration > Templates.

2. Click Device Templates, and click Create Template.

   Note	In Cisco vManage Release 20.7.x and earlier releases, Device Templates is titled Device.

3. From the Create Template drop-down list, choose From Feature Template.

4. From the Device Model drop-down list, select the type of device for which you are creating the template.

5. Click Transport & Management VPN or scroll to the Transport & Management VPN section.

6. Under Additional VPN 0 Templates, click VPN Interface Ethernet PPPoE.

7. From the VPN Interface Ethernet PPPoE drop-down list, click Create Template. The VPN Interface Ethernet PPPoE template form is displayed.

   This form contains fields for naming the template, and fields for defining the Ethernet PPPoE parameters.

   

8. In Template Name, enter a name for the template.

   The name can be up to 128 characters and can contain only alphanumeric characters.

9. In Template Description, enter a description of the template.

   The description can be up to 2048 characters and can contain only alphanumeric characters.

When you first open a feature template, for each parameter that has a default value, the scope is set to Default (indicated by a check mark), and the default setting or value is shown. To change the default or to enter a value, click the Scope drop-down list and select one of the following:

Configure PPPoE Functionality

To configure basic PPPoE functionality, click Basic Configuration and configure the following parameters. Required parameters are indicated with an asterisk.

To save the feature template, click Save.

Configure the PPP Authentication Protocol

To configure the PPP Authentication Protocol, click PPP and configure the following parameters. Required parameters are indicated with an asterisk.

To save the feature template, click Save.

​Create a Tunnel Interface

On IOS XE routers, you can configure up to eight tunnel interfaces. This means that each router can have up to eight TLOCs.

For the control plane to establish itself so that the overlay network can function, you must configure WAN transport interfaces in VPN 0.

To configure a tunnel interface for the multilink interface, select Tunnel Interface and configure the following parameters:

To configure additional tunnel interface parameters, click Advanced Options and configure the following parameters:

Configure the Interface as a NAT Device

To configure an interface to act as a NAT device for applications such as port forwarding, select NAT, click On and configure the following parameters:

To create a port forwarding rule, click Add New Port Forwarding Rule and configure the following parameters. You can define up to 128 port-forwarding rules to allow requests from an external network to reach devices on the internal network.

To save a port forwarding rule, click Add.

To save the feature template, click Save.

Apply Access Lists

To apply a rewrite rule, access lists, and policers to a router interface, click ACL and configure the following parameters:

To save the feature template, click Save.

Configure Other Interface Properties​

To configure other interface properties, click Advanced and configure the following properties:

To save the feature template, click Save.

Release Information

Introduced in Cisco SD-WAN Manager NMS in Release 18.4.1.

When a service, such as a firewall, is available on a device that supports only GRE tunnels, you can configure a GRE tunnel on the device to connect to the remote device by configuring a logical GRE interface. You then advertise that the service is available via a GRE tunnel, and you can create data policies to direct the appropriate traffic to the tunnel. GRE interfaces come up as soon as they are configured, and they stay up as long as the physical tunnel interface is up.

To configure GRE interfaces using Cisco SD-WAN Manager templates:

1. Create a Cisco VPN Interface GRE feature template to configure a GRE interface.

2. Create a Cisco VPN feature template to advertise a service that is reachable via a GRE tunnel, to configure GRE-specific static routes, and to configure other VPN parameters.

3. Create a data policy on the Cisco Catalyst SD-WAN Controller that applies to the service VPN, including a set-service service-name local command.

Navigate to the Template Screen and Name the Template

1. From the Cisco SD-WAN Manager menu, choose Configuration > Templates .

2. Click Device Templates, and click Create Template.

   Note	In Cisco vManage Release 20.7.x and earlier releases, Device Templates is titled Device.

3. From the Create Template drop-down list, select From Feature Template.

4. From the Device Model drop-down list, select the type of device for which you are creating the template.

5. To create a template for VPN 0 or VPN 512:

   1. Click Transport & Management VPN or scroll to the Transport & Management VPN section.

   2. Under Additional VPN 0 Templates, click VPN Interface GRE.

   3. From the VPN Interface GRE drop-down list, click Create Template. The VPN Interface GRE template form is displayed.

      This form contains fields for naming the template, and fields for defining the VPN Interface GRE parameters.

6. In Template Name, enter a name for the template. The name can be up to 128 characters and can contain only alphanumeric characters.

7. In Template Description, enter a description of the template. The description can be up to 2048 characters and can contain only alphanumeric characters.

When you first open a feature template, for each parameter that has a default value, the scope is set to Default (indicated by a check mark), and the default setting or value is shown. To change the default or to enter a value, click the scope drop-down to the left of the parameter field and select the paramater scope.

Configuring a Basic GRE Interface

To configure a basic GRE interface, click Basic Configuration and then configure the following parameters. Parameters marked with an asterisk are required to configure a GRE interface.

To save the feature template, click Save.

Configure Interface Access Lists

To configure access lists on a GRE interface, click ACL and configure the following parameters:

Configure Tracker Interface

To configure a tracker interface to track the status of a GRE interface, select Advanced and configure the following parameter: