Systems and Interfaces Configuration Guide, Cisco SD-WAN Release 20.x
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
In the Cisco SD-WAN overlay network design, interfaces are associated with VPNs. The interfaces that participate in a VPN are configured and
enabled in that VPN. Each interface can be present only in a single VPN.
At a high level, for an interface to be operational, you must configure an IP address for the interface and mark it as operational
(no shutdown). In practice, you always configure additional parameters for each interface.
You can configure up to 512 interfaces on a Cisco vEdge device. This number includes physical interfaces, loopback interfaces, and subinterfaces.
Note
To maximize the efficiency of the load-balancing among Cisco vSmart Controllers, use sequential numbers when assigning system IP addresses to the Cisco vEdge devices in the domain. Example of a sequential numbering schemes is 172.16.1.1, 172.16.1.2, 172.16.1.3, and so on.
Note
Ensure that any network interface configured on a device has a unique IP address. If the IP address of the interface conflicts with the system IP address of Cisco vManage instance, it can break the NETCONF session and lead Cisco vManage to read the device as offline.
Configure VPN
VPN
Use the VPN template for all Cisco SD-WAN devices running the Cisco SD-WAN software.
To configure VPNs using Cisco vManage templates, follow this general workflow:
Create VPN feature templates to configure VPN parameters. You create a separate VPN feature template for each VPN. For example,
create one feature template for VPN 0, a second for VPN 1, and a third for VPN 512.
For Cisco vManage Network Management Systems and Cisco vSmart Controllers, you can configure only VPNs 0 and 512. Create templates for these VPNs only if you want to modify the default settings
for the VPN. For Cisco vEdge devices, you can create templates for these two VPNs and for additional VPN feature templates to segment service-side user networks.
VPN 0—Transport VPN, which carries control traffic via the configured WAN transport interfaces. Initially, VPN 0 contains all of a device's interfaces
except for the management interface, and all interfaces are disabled.
VPN 512—Management VPN, which carries out-of-band network management traffic among the Cisco vEdge devices in the overlay network. The interface used for management traffic resides in VPN 512. By default, VPN 512 is configured
and enabled on all Cisco vEdge devices except for Cisco vEdge 100. For controller devices, by default, VPN 512 is not configured.
VPNs 1–511, 513–65530—Service VPNs, for service-side data traffic on Cisco vEdge devices.
Create interface feature templates to configure the interfaces in the VPN.
Create a VPN Template
Note
You can configure a static route through the VPN template.
Procedure
Step 1
From the Cisco vManage menu, choose Configuration > Templates.
Step 2
Click DeviceTemplates, and click Create Template.
Note
In Cisco vManage Release 20.7.x and earlier releases Device Templates is called Device.
Step 3
From the Create Template drop-down list, choose From Feature Template.
Step 4
From the Device Model drop-down list, choose the type of device for which you wish to create the template.
Step 5
To create a template for VPN 0 or VPN 512:
Click Transport & Management VPN, or scroll to the Transport & Management VPN section.
From the VPN 0 or VPN 512 drop-down list, click Create Template. The VPN template form appears.
The form contains fields for naming the template, and fields for defining VPN parameters.
Step 6
To create a template for VPNs 1 through 511, and 513 through 65530:
Click Service VPN, or scroll to the Service VPN section.
Click the Service VPN drop-down list.
From the VPN drop-down list, click Create Template. The VPN template form displays.
The form contains fields for naming the template, and fields for defining VPN parameters.
Step 7
In Template Name, enter a name for the template. The name can be up to 128 characters and can contain only alphanumeric characters.
Step 8
In Template Description, enter a description of the template. The description can be up to 2048 characters and can contain only alphanumeric characters.
Changing the Scope for a Parameter Value
When you first open a feature template, for each parameter that has a default value, the scope is set to Default (a ), 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:
Parameter Name
Description
Device Specific
Use a device-specific value for the parameter. For device-specific parameters, you cannot enter a value in the feature template.
You enter the value when you attach a device to a device template.
When you click Device Specific, the Enter Key box opens. This box displays a key, which is a unique string that identifies the parameter in a CSV file that you create.
This file is an Excel spreadsheet that contains one column for each key. The header row contains the key names (one key per
column), and each row after that corresponds to a device and defines the values of the keys for that device. You upload the
CSV file when you attach a device to a device template. For more information, see Create a Template Variables Spreadsheet
To change the default key, type a new string and move the cursor out of the Enter Key box.
Examples of device-specific parameters are system IP address, hostname, GPS location, and site ID.
Global
Enter a value for the parameter, and apply that value to all devices.
Examples of parameters that you might apply globally to a group of devices are DNS server, syslog server, and interface MTUs.
Once you have created and named the template, enter the following values. Parameters marked with an asterisk are required.
Configure Basic VPN Parameters
To configure basic VPN parameters, choose Basic Configuration and then configure the following parameters. Parameters marked with an asterisk are required to configure a VPN.
Parameter Name
Description
VPN
Enter the numeric identifier of the VPN.
Range for Cisco vEdge devices: 0 through 65530
Values for Cisco vSmart Controller and Cisco vManage devices: 0, 512
Name
Enter a name for the VPN.
Enhance ECMP keying
Click On to enable the use in the ECMP hash key of Layer 4 source and destination ports, in addition to the combination of the source
IP address, destination IP address, protocol, and DSCP field, as the ECMP hash key.
ECMP keying is Off by default.
Enable TCP Optimization
Cisco vEdge devices only
Click On to enable TCP optimization for a service-side VPN (a VPN other than VPN 0 and VPN 512). TCP optimization fine-tunes TCP to
decrease round-trip latency and improve throughput for TCP traffic.
Note
To complete the configuration of the transport VPN on a router, you must configure at least one interface in VPN 0.
To save the feature template, click Save.
Configure DNS and Static Hostname Mapping
To configure DNS addresses and static hostname mapping, click DNS and configure the following parameters:
Parameter Name
Options
Description
Primary DNS Address
Click either IPv4 or IPv6, and enter the IP address of the primary DNS server in this VPN.
New DNS Address
Click New DNS Address and enter the IP address of a secondary DNS server in this VPN. This field appears only if you have specified a primary DNS
address.
Mark as Optional Row
Check the Mark as Optional Row check box to mark this configuration as device-specific. To include this configuration for a device, enter the requested
variable values when you attach a device template to a device, or create a template variables spreadsheet to apply the variables.
Hostname
Enter the hostname of the DNS server. The name can be up to 128 characters.
List of IP Addresses
Enter up to eight IP addresses to associate with the hostname. Separate the entries with commas.
Configure Interfaces in the WAN Transport VPN (VPN 0)
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 vEdge 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 vSmart Controller or a Cisco vManage NMS, 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, that is, only in VPN 0.
Tunnel interfaces on Cisco vEdge 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 SD-WAN Release
20.3.2 , configure both address types.
To use dual stack with Cisco vEdge device
s from Cisco SD-WAN Release 20.3.2 , configure all controllers with both IPv4 and IPv6 addresses. In addition, configure DNS for the Cisco vBond Orchestrator interface to resolve IPv4 and IPv6 address types so that controllers can reach the Cisco vBond Orchestrator 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 vBond Orchestrator.
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 SD-WAN Release 20.3.2 , Cisco vEdge 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 vSmart Controllers and Cisco vSmart Controller NMSs, interface-name can be either ethnumber or loopbacknumber. Because Cisco vSmart Controllers and Cisco vSmart 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.
On Cisco vEdge devices, interface-name can be geslot/port, grenumber, ipsecnumber, loopbackstring, natpoolnumber, or pppnumber.
To enable the interface, include the no shutdown command.
Color is a Cisco 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 vEdge 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 vEdge 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.
On a Cisco vSmart Controller or Cisco vSmart Controller NMS, you can configure one tunnel interface. On a Cisco vEdge device, you can configure up to eight tunnel interfaces.
This means that each Cisco vEdge device can have up to eight TLOCs.
On Cisco vEdge 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 vEdge 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 SD-WAN software automatically selects the correct tunnel on the destination Cisco vEdge device.
A tunnel interface allows only DTLS, TLS, and, for Cisco vEdge 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:
Service
Cisco vEdge device
Cisco vSmart Controller
Cisco vSmart Controller
all (Overrides any commands that allow or disallow individual services)
X
X
X
bgp
X
—
—
dhcp (for DHCPv4 and DHCPv6)
X
—
—
dns
X
—
—
https
—
X
—
icmp
X
X
X
netconf
—
X
—
ntp
X
—
—
ospf
X
—
—
sshd
X
X
X
stun
X
X
X
The allow-service stun command pertains to allowing or disallowing a Cisco vEdge 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 vEdge device that is behind a NAT, you can also have tunnel interface to discover its public IP address and port number from the Cisco vBond Orchestrator.
With this configuration, the Cisco vEdge device uses the Cisco vBond Orchestrator 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 vBond Orchestrator 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 vBond Orchestrator as a STUN server, you must configure at least one other tunnel interface on the Cisco vEdge device so that it can exchange control traffic with the Cisco vSmart Controller and the Cisco vSmart 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.
vEdge(config)# policy implicit-acl-logging
When you enable implicit ACL logging, by default, the headers of all dropped packets are logged. It is recommended that you
configure a limit to the number of packets logged with the policy log-frequency configuration command.
On a Cisco vEdge device, services that you configure on a tunnel interface act as implicit access lists (ACLs). If you apply a localized data policy
on a tunnel interface by configuring an ACL with the policy access-list command, this ACL is an explicit ACL. For information about how packets packets matching both implicit and explict ACLs are
handled, see Configuring Localized Data Policy for IPv4 or Configuring Localized Data Policy for IPv6 .
For each transport tunnel on a vEdge router and for each encapsulation type on a single transport tunnel, the Cisco SD-WAN
software creates a TLOC, which consists of the router' system IP address, the color, and the encapsulation. The OMP session
running on the tunnel sends the TLOC, as a TLOC route, to the Cisco vSmart Controller, which uses it to determine the overlay network topology and to determine the best paths for data traffic across the overlay
network.
To display information about interfaces in the WAN transport VPN that are configured with IPv4 addresses, use the show interface command. For example:
vEdge# show interface vpn 0
IF IF TCP
ADMIN OPER ENCAP SPEED MSS RX TX
VPN INTERFACE IP ADDRESS STATUS STATUS TYPE PORT TYPE MTU HWADDR MBPS DUPLEX ADJUST UPTIME PACKETS PACKETS
--------------------------------------------------------------------------------------------------------------------------------------------------
0 ge0/1 10.0.5.21/24 Up Up null transport 1500 00:0c:29:6c:30:c1 10 full 0 0:04:03:41 260025 260145
0 ge0/2 - Down Up null service 1500 00:0c:29:6c:30:cb 10 full 0 0:04:03:41 3506 1
0 ge0/3 - Down Up null service 1500 00:0c:29:6c:30:d5 10 full 0 0:04:03:41 260 1
0 ge0/4 - Down Up null service 1500 00:0c:29:6c:30:df 10 full 0 0:04:03:41 260 1
0 ge0/5 - Down Up null service 1500 00:0c:29:6c:30:e9 10 full 0 0:04:03:41 260 1
0 ge0/6 10.0.7.21/24 Up Up null service 1500 00:0c:29:6c:30:f3 10 full 0 0:04:03:41 265 2
0 ge0/7 10.0.100.21/24 Up Up null service 1500 00:0c:29:6c:30:fd 10 full 0 0:04:03:41 278 2
0 system 172.16.255.21/32 Up Up null loopback 1500 00:00:00:00:00:00 10 full 0 0:04:03:37 0 0
To display information for interfaces configured with IPv6 addresses, use the show ipv6 interface command. For example:
vEdge# show ipv6 interface vpn 0
IF IF TCP
AF ADMIN OPER ENCAP SPEED MSS RX TX
VPN INTERFACE TYPE IPV6 ADDRESS STATUS STATUS TYPE PORT TYPE MTU HWADDR MBPS DUPLEX ADJUST UPTIME PACKETS PACKETS LINK LOCAL ADDRESS
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
0 ge0/1 ipv6 2001::a00:1a0b/120 Up Up null service 1500 00:0c:29:ab:b7:62 1000 full 1420 0:01:30:00 2 6 fe80::20c:29ff:feab:b762/64
0 ge0/2 ipv6 2001::a00:50b/120 Up Up null service 1500 00:0c:29:ab:b7:6c 1000 full 1420 0:01:30:00 21 5 fe80::20c:29ff:feab:b76c/64
0 ge0/3 ipv6 fd00:1234::/16 Up Up null service 1500 00:0c:29:ab:b7:76 1000 full 1420 0:01:08:33 0 8 fe80::20c:29ff:feab:b776/64
0 ge0/4 ipv6 - Up Up null service 1500 00:0c:29:ab:b7:80 1000 full 1420 0:01:30:00 18 5 fe80::20c:29ff:feab:b780/64
0 ge0/5 ipv6 - Down Up null service 1500 00:0c:29:ab:b7:8a 1000 full 1420 0:01:44:19 1 1 fe80::20c:29ff:feab:b78a/64
0 ge0/6 ipv6 - Down Up null service 1500 00:0c:29:ab:b7:94 1000 full 1420 0:01:44:19 0 1 fe80::20c:29ff:feab:b794/64
0 ge0/7 ipv6 - Up Up null service 1500 00:0c:29:ab:b7:9e 1000 full 1420 0:01:43:02 55 5 fe80::20c:29ff:feab:b79e/64
0 system ipv6 - Up Up null loopback 1500 00:00:00:00:00:00 10 full 1420 0:01:29:31 0 0 -
0 loopback1 ipv6 2001::a00:6501/128 Up Up null transport 1500 00:00:00:00:00:00 10 full 1420 0:03:49:09 0 0 -
0 loopback2 ipv6 2001::a00:6502/128 Up Up null transport 1500 00:00:00:00:00:00 10 full 1420 0:03:49:05 0 0 -
0 loopback3 ipv6 2001::a00:6503/128 Up Up null transport 1500 00:00:00:00:00:00 10 full 1420 0:03:49:01 0 0 -
0 loopback4 ipv6 2001::a00:6504/128 Up Up null transport 1500 00:00:00:00:00:00 10 full 1420 0:03:48:54 0 0 -
In the command output, a port type of "transport" indicates that the interface is configured as a tunnel interface, and a
port type of "service" indicates that the interface is not configured as a tunnel interface and can be used for data plane
traffic. The port type for the system IP address interface is "loopback".
Configure Other WAN Interface Properties
You can modify the distribution of data traffic across transport tunnels by applying a data policy in which the action sets
TLOC attributes (IP address, color, and encapsulation) to apply to matching data packets. For more information, see the Configuring
Centralized Data Policy.
Extend the WAN Transport VPN
When two Cisco vEdge devices are collocated at a physical site that has only one WAN circuit, you can configure the Cisco vEdge device that is not connected to the circuit to be able to establish WAN transport tunnels through the other router's TLOCs. In this
way, you extend the WAN transport VPN so that both routers can establish tunnel interfaces, and hence can establish independent
TLOCs, in the overlay network. (Note that you can configure the two routers themselves with different site identifiers).
The following figure illustrates a site with two Cisco vEdge devices. Cisco vEdge device-1 terminates one WAN circuit from the Internet and the second Cisco vEdge device-2 terminates the private MPLS network. Each router has one TLOC. You can configure Cisco vEdge device-2 to extend its WAN transport VPN to Cisco vEdge device1 so that Cisco vEdge device-1 can participate independently in the overlay network. You can also make a similar configuration for vEdge1 so that the
WAN transport can be extended from Cisco vEdge device1 to Cisco vEdge device2.
When you extend the WAN transport VPN, no BFD sessions are established between the two collocated vEdge routers.
You cannot configure TLOC extensions on cellular (LTE) interfaces.
To extend the WAN transport VPN, you configure the interface between the two routers:
For the router that is not connected to the circuit, you configure a standard tunnel interface in VPN 0.
For the router that is physically connected to the WAN or private transport, you associate the physical interface that connects
to the circuit, configuring this in VPN 0 but not in a tunnel interface.
To configure the non-connected router (Cisco vEdge device-1 in the figure above), create a tunnel interface in VPN 0 on the physical interface to the connected router.
vEdge-1(config-vpn-0)# interface geslot/port
vEdge-1(config-interface)# ip addressprefix/length
vEdge-1(config-interface)# no shutdown
vEdge-1(config-interface)# mtunumber
vEdge-1(config-interface)# tunnel-interface
vEdge-1(config-tunnel-interface)# colorcolor
For the router connected to the WAN or private transport (Cisco vEdge device-2 in the figure above), configure the interface that connects to the non-connected router, again in VPN 0:
vEdge-2(config-vpn-0)# interface ge slot/port
vEdge-2(config-interface)# ip addressprefix/length
vEdge-2(config-interface)# tloc-extensiongeslot/port
vEdge-2(config-interface)# no shutdown
vEdge-2(config-interface)# mtunumber
The physical interface in the interface command is the one that connects to the other router.
The tloc-extension command creates the binding between the non-connected router and the WAN or private network. In this command, you specify
the physical interface that connects to the WAN or private network circuit.
If the circuit connects to a public network:
Configure a NAT on the public-network-facing interface on the Cisco vEdge device. The NAT configuration is required because the two Cisco vEdge devices are sharing the same transport tunnel.
Configure a static route on the non-connected router to the TLOC-extended interface on the router connected to the public
network.
If the circuit connects to a private network, such as an MPLS network:
Enable routing on the non-connected router so that the interface on the non-connected router is advertised into the private
network.
Depending on the routing protocol you are using, enable either OSPF or BGP service on the non-connected router interface so
that routing between the non-connected and the connected routers comes up. To do this, use the allow-service command.
You cannot extend a TLOC configured on a loopback interface, that is, when you use a loopback interface to connect to the
public or private network. You can extend a TLOConly on a physical interface.
If one of the routers is connected to two WAN transports (such as the Internet and an MPLS network), create subinterfaces
between the two routers, creating the tunnel on the subinterface. The subinterfaces on the two routers must be in the same
subnet. Because you are using a subinterface, the interface's MTU must be at least 4 bytes less than the physical MTU.
Here is a sample configuration that corresponds to the figure shown above. Because the router Cisco vEdge device-2 connects to two transports, we create subinterfaces between the Cisco vEdge device-1 and Cisco vEdge device-2 routers. One subinterface binds to the Internet circuit, and the second one binds to the MPLS connection.
vEdge-1# show running-config vpn 0
interface ge0/2.101
ip address 192.168.19.15/24
mtu 1496
tunnel-interface
color lte
...
!
no shutdown
!
interface ge0/2.102
ip address 192.168.20.15/24
mtu 1496
tunnel-interface
color mpls
...
!
no shutdown
!
ip route 0.0.0.0/0 192.168.19.16
vEdge-2# show running-config vpn 0
interface ge0/0
ip address 172.16.255.2
tunnel-interface
color lte
...
!
no shutdown
!
interface ge0/3
ip address 172.16.255.16
tunnel-interface
color mpls
...
!
no shutdown
!
interface ge0/2.101
ip address 192.168.19.16/24
mtu 1496
tloc-extension ge0/0
no shutdown
!
interface ge0/2.102
ip address 192.168.20.16/24
mtu 1496
tloc-extension ge0/3
no shutdown
!
For this example configuration, Cisco vEdge device-1 establishes two control connections to each Cisco vSmart Controller in the overlay network—one connection for the LTE tunnel and the second for the MPLS tunnel. These control connections are
separate and independent from those established on Cisco vEdge device-2. The following output shows the control connections on vEdge-1 in a network with two Cisco vSmart Controllers:
vEdge-1# show control connections
PEER PEER CONTROLLER
PEER PEER PEER SITE DOMAIN PEER PRIVATE PEER PUBLIC GROUP
TYPE PROTOCOL SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT LOCAL COLOR STATE UPTIME NAME
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
vsmart dtls 172.16.255.19 100 1 10.0.5.19 12346 10.0.5.19 12346 lte up 0:00:18:43 default
vsmart dtls 172.16.255.19 100 1 10.0.5.19 12346 10.0.5.19 12346 mpls up 0:00:18:32 default
vsmart dtls 172.16.255.20 200 1 10.0.12.20 12346 10.0.12.20 12346 lte up 0:00:18:38 default
vsmart dtls 172.16.255.20 200 1 10.0.12.20 12346 10.0.12.20 12346 mpls up 0:00:18:27 default
You can verify that the two Cisco vEdge devices have established no BFD sessions between them. On Cisco vEdge device-1, we see no BFD sessions to Cisco vEdge device-2 (system IP address 172.16.255.16):
vEdge-1# show bfd sessions
SOURCE TLOC REMOTE TLOC DST PUBLIC DST PUBLIC DETECT TX TRANSI-
SYSTEM IP SITE ID STATE COLOR COLOR SOURCE IP IP PORT ENCAP MULTIPLIER INTERVAL(msec) UPTIME TIONS
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
172.16.255.11 100 up lte lte 192.168.19.15 10.0.101.1 12346 ipsec 20 1000 0:00:20:26 0
172.16.255.11 100 up lte 3g 192.168.19.15 10.0.101.2 12346 ipsec 20 1000 0:00:20:26 0
172.16.255.11 100 up lte gold 192.168.19.15 10.0.101.3 12346 ipsec 20 1000 0:00:20:26 0
172.16.255.11 100 up lte red 192.168.19.15 10.0.101.4 12346 ipsec 20 1000 0:00:20:26 0
172.16.255.11 100 up mpls lte 192.168.20.15 10.0.101.1 12346 ipsec 20 1000 0:00:20:26 0
172.16.255.11 100 up mpls 3g 192.168.20.15 10.0.101.2 12346 ipsec 20 1000 0:00:20:26 0
172.16.255.11 100 up mpls gold 192.168.20.15 10.0.101.3 12346 ipsec 20 1000 0:00:20:26 0
172.16.255.11 100 up mpls red 192.168.20.15 10.0.101.4 12346 ipsec 20 1000 0:00:20:26 0
172.16.255.14 400 up lte lte 192.168.19.15 10.1.14.14 12360 ipsec 20 1000 0:00:20:26 0
172.16.255.14 400 up mpls lte 192.168.20.15 10.1.14.14 12360 ipsec 20 1000 0:00:20:26 0
172.16.255.21 100 up lte lte 192.168.19.15 10.0.111.1 12346 ipsec 20 1000 0:00:20:26 0
172.16.255.21 100 up lte 3g 192.168.19.15 10.0.111.2 12346 ipsec 20 1000 0:00:20:26 0
172.16.255.21 100 up mpls lte 192.168.20.15 10.0.111.1 12346 ipsec 20 1000 0:00:20:26 0
172.16.255.21 100 up mpls 3g 192.168.20.15 10.0.111.2 12346 ipsec 20 1000 0:00:20:26 0
Configure GRE Interfaces and Advertise Services to Them
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 vEdge router to connect to the remote device.
You then advertise that the service is available via a GRE tunnel, and you direct the appropriate traffic to the tunnel either
by creating centralized data policy or by configuring GRE-specific static routes.
Create a GRE tunnel by configuring a GRE interface. GRE interfaces are logical interfaces, and you configure them just like
any other physical interface. A GRE interface is a logical interface, you must bind it to a physical interface or a PPPoE
interface, as described below.
To configure a GRE tunnel interface to a remote device that is reachable through a transport network, configure the tunnel
in VPN 0:
The GRE interface has a name in the format grenumber, where number can be from 1 through 255.
To configure the source of the GRE tunnel on the local device, you can specify either the IP address of the physical interface
or PPPoE interface (in the tunnel-source command) or the name of the physical interface or PPPoE interface (in the tunnel-source-interface command). Ensure that the physical interface is configured in the same VPN in which the GRE interface is located.
To configure the destination of the GRE tunnel, specify the IP address of the remote device in the tunnel-destination command.
The combination of a source address (or source interface name) and a destination address defines a single GRE tunnel. Only
one GRE tunnel can exist that uses a specific source address (or interface name) and destination address pair.
You can optionally configure an IP address for the GRE tunnel itself:
vEdge(config-interface-gre)# ip addressip-address
Because GRE tunnels are stateless, the only way for the local router to determine whether the remote end of the tunnel is
up, is to periodically send keepalive messages over the tunnel. The keepalive packets are looped back to the sender, and receipt
of these packets by the local router indicates that the remote GRE device is up. By default, the GRE interface sends keepalive
packets every 10 seconds, and if it receives no response, retries 3 times before declaring the remote device to be down. You
can modify these default values with the keepalive command:
The keepalive interval can be from 0 through 65535 seconds, and the number of retries can be from 0 through 255. If you configure
an IP address for the GRE interface, that IP address generates the keepalive messages.
If the vEdge router sits behind a NAT and you have configured GRE encapsulation, you must disable keepalives, with a keepalive 0 0 command. (Note that you cannot disable keepalives by issuing a no keepalive command. This command returns the keepalive to its default settings of sending a keepalive packet every 10 seconds and retrying
3 times before declaring the remote device down.)
For GRE interfaces, you can configure only the following additional interface properties:
GRE interfaces do not support cFlowd traffic monitoring.
You can configure one or two GRE interfaces per service. When you configure two, the first interface is the primary GRE tunnel,
and the second is the backup tunnel. All packets are sent only to the primary tunnel. If that tunnel fails, all packets are
then sent to the secondary tunnel. If the primary tunnel comes back up, all traffic is moved back to the primary GRE tunnel.
You direct data traffic from the service VPN to the GRE tunnel in one of two ways: either with a GRE-specific static route
or with a centralized data policy.
To create a GRE-specific static route in the service VPN (a VPN other than VPN 0 or VPN 512), use the ip gre-route command:
vEdge(config-vpn)# ip gre-routeprefixvpn 0 interfacegrenumber [grenumber2]
This GRE-specific static route directs traffic from the specified prefix to the primary GRE interface, and optionally to the
secondary GRE interface, in VPN 0. The OMP administrative distance of a GRE-specific static route is 5, and the admin distance
for a regular static route (configured with the ip route command) is 1. For more information, see Unicast Overlay Routing Overview .
To direct the data traffic to the GRE tunnel using a centralized data policy is a two-part process: you advertise the service
in the service VPN, and then you create a centralized data policy on the Cisco vSmart Controller to forward matching traffic to that service.
To advertise the service, include the service command in the service VPN (a VPN other than VPN 0 or VPN 512):
The service name can be FW, IDP, IDS, or TE, or a custom service name netsvc1 through netsvc4. For more information on service-names, see Service Chaining. The interface is the GRE interface in VPN 0 that is used to
reach the service. If you have configured a primary and a backup GRE tunnel, list the two GRE interfaces (grenumber1grenumber2) in the service command. Once you have configured a service as a reachable GRE interface, you cannot delete the GRE interface from the configuration.
To delete the GRE interface, you must first delete the service. You can, however, reconfigure the service itself, by modifying
the service command.
Then, create a data policy on the Cisco vSmart Controller that applies to the service VPN. In the action portion of the data policy, you must explicitly configure the policy to service
the packets destined for the GRE tunnel. To do this, include the local option in the set service command:
vSmart(config-policy-data-policy-vpn-list-vpn-sequence)# action accept
vSmart(config-action-accept)# set serviceservice-namelocal
If the GRE tunnel used to reach the service is down, packet routing falls back to using standard routing. To drop packets
when a GRE tunnel to the service is unreachable, add the restrict option:
vSmart(config-policy-data-policy-vpn-list-vpn-sequence)# action accept
vSmart(config-action-accept)# set serviceservice-namelocal restrict
To monitor GRE tunnels and their traffic, use the following commands:
show interface —List data traffic transmitted and received on GRE tunnels.
show tunnel gre-keepalives —List GRE keepalive traffic transmitted and received on GRE tunnels.
show tunnel statistics —List both data and keepalive traffic transmitted and received on GRE tunnels.
The following figure illustrates an example of configuring a GRE tunnel in VPN 0, to allow traffic to be redirected to a service
that is not located at the same site as the vEdge router. In this example, local traffic is directed to the GRE tunnel using
a centralized data policy, which is configured on the Cisco vSmart Controller.
The configuration looks like this:
vEdge# show running-config vpn 0
vpn 0
interface gre1
ip address 172.16.111.11/24
keepalive 60 10
tunnel-source 172.16.255.11
tunnel-destination 10.1.2.27
no shutdown
!
!
vEdge# show running-config vpn 1 service
vpn 1
service FW interface gre1
vSmart# show running-config policy
policy
lists
prefix-list for-firewall
ip-prefix 172.16.1.0/24
site-list my-site
site-id 100
vpn-list for-vpn-1
vpn 1
data-policy to-gre-tunnel
vpn-list for-vpn-1
sequence 10
match
source-data-prefix-list for-firewall
action accept
set service FW local
apply-policy site-list my-site
data-policy to-gre-tunnel from-service
Here is an example of the same configuring using a GRE-specific static route to direct data traffic from VPN 1 into the GRE
tunnels:
vEdge# show running-config
vpn 0
interface gre1
ip address 172.16.111.11/24
keepalive 60 10
tunnel-source 172.16.255.11
tunnel-destination 10.1.2.27
no shutdown
!
!
vpn 1
ip gre-route 172.16.1.0/24 vpn 0 interface gre1
The show interface command displays the GRE interface in VPN 0:
vEdge# show interface vpn 0
IF IF TCP
ADMIN OPER ENCAP SPEED MSS RX TX
VPN INTERFACE IP ADDRESS STATUS STATUS TYPE PORT TYPE MTU HWADDR MBPS DUPLEX ADJUST UPTIME PACKETS PACKETS
--------------------------------------------------------------------------------------------------------------------------------------------------
0 gre1 172.16.111.11/24 Up Down null service 1500 0a:00:05:0b:00:00 - - 1420 - 0 0
0 ge0/1 10.0.26.11/24 Up Up null service 1500 00:0c:29:ab:b7:62 10 full 1420 0:03:35:14 89 5
0 ge0/2 10.0.5.11/24 Up Up null transport 1500 00:0c:29:ab:b7:6c 10 full 1420 0:03:35:14 9353 18563
0 ge0/3 - Down Up null service 1500 00:0c:29:ab:b7:76 10 full 1420 0:03:57:52 99 0
0 ge0/4 10.0.7.11/24 Up Up null service 1500 00:0c:29:ab:b7:80 10 full 1420 0:03:35:14 89 5
0 ge0/5 - Down Up null service 1500 00:0c:29:ab:b7:8a 10 full 1420 0:03:57:52 97 0
0 ge0/6 - Down Up null service 1500 00:0c:29:ab:b7:94 10 full 1420 0:03:57:52 85 0
0 ge0/7 10.0.100.11/24 Up Up null service 1500 00:0c:29:ab:b7:9e 10 full 1420 0:03:56:30 3146 2402
0 system 172.16.255.11/32 Up Up null loopback 1500 00:00:00:00:00:00 10 full 1420 0:03:34:15 0 0
You can also view the GRE tunnel information:
vEdge# show tunnel gre-keepalives
REMOTE REMOTE
IF ADMIN OPER KA TX RX TX RX TX RX
VPN NAME SOURCE IP DEST IP STATE STATE ENABLED PACKETS PACKETS PACKETS PACKETS ERRORS ERRORS TRANSITIONS
---------------------------------------------------------------------------------------------------------------------------
0 gre1 10.0.5.11 10.1.2.27 up down true 0 0 442 0 0 0 0
vEdge# show tunnel statistics
tunnel statistics gre 10.0.5.11 10.1.2.27 0 0
tunnel-mtu 1460
tx_pkts 451
tx_octets 54120
rx_pkts 0
rx_octets 0
tcp-mss-adjust 1380
Configure the System Interface
For each Cisco vEdge 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 vEdge 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.
vEdge(config)# system system-ipipv4-address
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:
vEdge# show running-config system system-ip
system
system-ip 172.16.255.11
!
vEdge# show interface vpn 0
IF IF TCP
ADMIN OPER ENCAP SPEED MSS RX TX
VPN INTERFACE IP ADDRESS STATUS STATUS TYPE PORT TYPE MTU HWADDR MBPS DUPLEX ADJUST UPTIME PACKETS PACKETS
--------------------------------------------------------------------------------------------------------------------------------------------------
0 ge0/1 10.0.26.11/24 Up Up null service 1500 00:0c:29:ab:b7:62 1000 full 1420 0:10:32:16 1606 8
0 ge0/2 10.0.5.11/24 Up Up null transport 1500 00:0c:29:ab:b7:6c 1000 full 1420 0:10:32:16 307113 303457
0 ge0/3 - Down Up null service 1500 00:0c:29:ab:b7:76 1000 full 1420 0:10:47:49 1608 0
0 ge0/4 10.0.7.11/24 Up Up null service 1500 00:0c:29:ab:b7:80 1000 full 1420 0:10:32:16 1612 8
0 ge0/5 - Down Up null service 1500 00:0c:29:ab:b7:8a 1000 full 1420 0:10:47:49 1621 0
0 ge0/6 - Down Up null service 1500 00:0c:29:ab:b7:94 1000 full 1420 0:10:47:49 1600 0
0 ge0/7 10.0.100.11/24 Up Up null service 1500 00:0c:29:ab:b7:9e 1000 full 1420 0:10:47:31 3128 1165
0 system 172.16.255.11/32 Up Up null loopback 1500 00:00:00:00:00:00 10 full 1420 0:10:31:58 0 0
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.
Here is an example of configuring the system IP address on a loopback interface in VPN 1:
vEdge# config
Entering configuration mode terminal
vEdge(config)# vpn 1
vEdge(config-vpn-1)# interface loopback0 ip address 172.16.255.11/32
vEdge(config-vpn-1)# no shutdown
vEdge(config-interface-loopback0)# commit and-quit
Commit complete.
vEdge# show interface
IF IF TCP
ADMIN OPER ENCAP SPEED MSS RX TX
VPN INTERFACE IP ADDRESS STATUS STATUS TYPE PORT TYPE MTU HWADDR MBPS DUPLEX ADJUST UPTIME PACKETS PACKETS
--------------------------------------------------------------------------------------------------------------------------------------------------
0 ge0/1 10.0.26.11/24 Up Up null service 1500 00:0c:29:ab:b7:62 1000 full 1420 0:10:27:33 1597 8
0 ge0/2 10.0.5.11/24 Up Up null transport 1500 00:0c:29:ab:b7:6c 1000 full 1420 0:10:27:33 304819 301173
0 ge0/3 - Down Up null service 1500 00:0c:29:ab:b7:76 1000 full 1420 0:10:43:07 1599 0
0 ge0/4 10.0.7.11/24 Up Up null service 1500 00:0c:29:ab:b7:80 1000 full 1420 0:10:27:33 1603 8
0 ge0/5 - Down Up null service 1500 00:0c:29:ab:b7:8a 1000 full 1420 0:10:43:07 1612 0
0 ge0/6 - Down Up null service 1500 00:0c:29:ab:b7:94 1000 full 1420 0:10:43:07 1591 0
0 ge0/7 10.0.100.11/24 Up Up null service 1500 00:0c:29:ab:b7:9e 1000 full 1420 0:10:42:48 3118 1164
0 system 172.16.255.11/32 Up Up null loopback 1500 00:00:00:00:00:00 10 full 1420 0:10:27:15 0 0
1 ge0/0 10.2.2.11/24 Up Up null service 1500 00:0c:29:ab:b7:58 1000 full 1420 0:10:27:30 5734 4204
1 loopback0 172.16.255.11/32 Up Up null service 1500 00:00:00:00:00:00 10 full 1420 0:00:00:28 0 0
512 eth0 10.0.1.11/24 Up Up null service 1500 00:50:56:00:01:0b 1000 full 0 0:10:43:03 20801 14368
Configure Control Plane High Availability
A highly available Cisco SD-WAN network contains two or more Cisco vSmart Controllers in each domain. A Cisco SD-WAN domain can have up to eight Cisco vSmart Controllers, and each Cisco vEdge device, by default, connects to two of them. You change this value on a per-tunnel basis:
When the number of Cisco vSmart Controllers in a domain is greater than the maximum number of controllers that a domain's Cisco vEdge devices are allowed to connect to, the Cisco SD-WAN software load-balances the connections among the available Cisco vSmart Controllers.
Configure Other Interfaces
Configure Interfaces in the Management (VPN 512)
On all Cisco SD-WAN devices, VPN 512 is used for out-of-band management, by default as part of the factory-default configuration.
On Cisco vEdge devices the interface type for management interfaces is mgmt, and the initial address for the interface is 192.168.1.1.
vEdge# show running-config vpn 512
vpn 512
interface mgmt0
ip dhcp-client
no shutdown
!
!
To display information about the configured management interfaces, use the
show interface command. For example:
vEdge# show interface vpn 512
IF IF TCP
ADMIN OPER ENCAP PORT SPEED MSS RX TX
VPN INTERFACE IP ADDRESS STATUS STATUS TYPE TYPE MTU HWADDR MBPS DUPLEX ADJUST UPTIME PACKETS PACKETS
--------------------------------------------------------------------------------------------------------------------------------------------
512 mgmt0 192.168.1.1/24 Up Up null service 1500 00:50:56:00:01:1f 1000 full 0 0:04:08:01 1131 608
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.
Configure Service-Side Interfaces for Carrying Data Traffic
On Cisco vEdge devices, the VPNs other than 0 and 512 are service-side VPNs, and the interfaces in these VPNs connect the router to service-side
LANs and WLANs. These interfaces are the interfaces that carry data traffic between vEdge routers and sites across the overlay
network. At a minimum, for these interfaces, you must configure an IPv4 address, and you must enable the interface:
vEdge(config)# vpn vpn-id
vEdge(config-vpn)# interface geslot/port
vEdge(config-interface)# ip addressprefix/length
vEdge(config-interface)# no shutdown
For service-side interfaces, you can configure up to four secondary IP addresses.
vEdge(config)# vpnvpn-id
vEdge(config-vpn)# interface geslot/port
vEdge(config-interface)# ip secondary-addressipv4-address
To display information about the configured data traffic interfaces, use the show interface command.
vEdge# show interface vpn 1
IF IF TCP
ADMIN OPER ENCAP PORT SPEED MSS RX TX
VPN INTERFACE IP ADDRESS STATUS STATUS TYPE TYPE MTU HWADDR MBPS DUPLEX ADJUST UPTIME PACKETS PACKETS
---------------------------------------------------------------------------------------------------------------------------------------------
1 ge0/1 10.192.1.1/28 Up Up null service 1500 00:0c:bd:05:f0:84 100 full 0 1:05:44:07 399 331
1 loopback1 10.255.1.1/32 Up Up null service 1500 00:00:00:00:00:00 10 full 0 1:05:44:07 0 0
For some protocols, you specify an interface as part of the protocol's configuration. In these cases, the interface used by
the protocol must be the same as one of the interfaces configured in the VPN. As example is OSPF, where you place interfaces in OSPF areas. In this example, the interface ge0/0 is configured in VPN 1, and this interface is configured to be in the OSPF backbone area:
vEdge# show running-config vpn 1
vpn 1
router
ospf
router-id 172.16.255.21
timers spf 200 1000 10000
redistribute static
redistribute omp
area 0
interface ge0/0
exit
exit
!
!
interface ge0/0
ip address 10.2.3.21/24
no shutdown
!
!
Configure Loopback Interfaces
Use the interface name format loopbackstring, where string can be any alphanumeric value and can include underscores (_) and hyphens (–). The total interface name, including the string
"loopback", can be a maximum of 16 characters long. (Note that because of the flexibility of interface naming in the CLI,
the interfaces lo0 and loopback0 are parsed as different strings and as such are not interchangeable. For the CLI to recognize as interface as a loopback
interface, its name must start with the full string loopback.)
One special use of loopback interfaces is to configure data traffic exchange across private WANs, such as MPLS or metro Ethernet
networks. To allow a router that is behind a private network to communicate directly over the private WAN with other edge
routers, you direct data traffic to a loopback interface that is configured as a tunnel interface rather than to an actual
physical WAN interface.
Configure Interface Properties
Set the Interface Speed
When a Cisco vEdge device comes up, the Cisco 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:
vEdge# show hardware inventory
HW
DEV
HW TYPE INDEX VERSION PART NUMBER SERIAL NUMBER DESCRIPTION
-----------------------------------------------------------------------------------------------------------------------
Chassis 0 3.1 vEdge-1000 11OD145130001 vEdge-1000
CPU 0 None None None Quad-Core Octeon-II
DRAM 0 None None None 2048 MB DDR3
Flash 0 None None None nor Flash - 16.00 MB
eMMC 0 None None None eMMC - 7.31 GB
PIM 0 None ge-fixed-8 None 8x 1GE Fixed Module
Transceiver 0 A FCLF-8521-3 PQD3FHL Port 0/0, Type 0x8 (Copper), Vendor FINISAR CORP.
Transceiver 1 PB 1GBT-SFP05 0000000687 Port 0/1, Type 0x8 (Copper), Vendor BEL-FUSE
FanTray 0 None None None Fixed Fan Tray - 2 Fans
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.
vEdge# show interface
IF IF TCP
ADMIN OPER ENCAP SPEED MSS RX TX
VPN INTERFACE IP ADDRESS STATUS STATUS TYPE PORT TYPE MTU HWADDR MBPS DUPLEX ADJUST UPTIME PACKETS PACKETS
------------------------------------------------------------------------------------------------------------------------------------------------
0 ge0/0 192.168.1.4/24 Up Up null transport 1500 00:0c:bd:05:f0:83 1000 full 1300 0:06:10:59 2176305 2168760
0 ge0/2 - Down Down null service 1500 00:0c:bd:05:f0:81 - - 0 - 0 0
0 ge0/3 - Down Down null service 1500 00:0c:bd:05:f0:82 - - 0 - 0 0
0 ge0/4 - Down Down null service 1500 00:0c:bd:05:f0:87 - - 0 - 0 0
0 ge0/5 - Down Down null service 1500 00:0c:bd:05:f0:88 - - 0 - 0 0
0 ge0/6 - Down Down null service 1500 00:0c:bd:05:f0:85 - - 0 - 0 0
0 ge0/7 - Down Down null service 1500 00:0c:bd:05:f0:86 - - 0 - 0 0
0 system 10.255.1.1/32 Up Up null loopback 1500 00:00:00:00:00:00 10 full 0 0:06:11:15 0 0
1 ge0/1 10.192.1.1/28 Up Up null service 1500 00:0c:bd:05:f0:84 100 full 0 0:06:10:59 87 67
1 loopback1 10.255.1.1/32 Up Up null service 1500 00:00:00:00:00:00 10 full 0 0:06:10:59 0 0
2 loopback0 10.192.1.2/32 Up Up null service 1500 00:00:00:00:00:00 10 full 0 0:06:10:59 0 0
512 mgmt0 - Up Down null mgmt 1500 00:0c:bd:05:f0:80 - - 0 - 0 0
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 vSmart Controllers and Cisco vManage 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.
Set the Interface MTU
By default, all interfaces have an MTU of 1500 bytes. You can modify this on an interface:
To display an interface's MTU, use the show interface command.
For Cisco vBond Orchestrator, Cisco vManage, and Cisco vSmart 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:
vEdge(config-vpn)# interfaceinterface-namepmtu
On Cisco vEdge device, the Cisco 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(config-vpn)# interfaceinterface-namepmtu
BFD is a data plane protocol and so does not run on Cisco vBond Orchestrator, Cisco vManage, and Cisco vSmart Controller devices.
Note
If you set an MTU on Cisco vEdge hardware device, when a packet whose size is larger than the MTU is received, the vEdge interface
drops the packet. This is true, if the "Do Not Fragment" bit is set or not. However, this behavior is not true for vEdge Cloud
devices.
Note
From Cisco SD-WAN release 20.5 and later releases, PMTU discovery on Cisco vEdge devices is enabled for asymmetric networks. PMTU is calculated based on the egress path MTU.
Monitoring Bandwidth on a Transport Circuit
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 vManage 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 vEdge devices and on Cisco vManage 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 (232 / 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.
Enable DHCP Server using Cisco vManage
Use the DHCP-Server template for all Cisco SD-WANs.
You enable DHCP server functionality on a Cisco SD-WAN device interface so it can assign IP addresses to hosts in the service-side network.
To configure a Cisco SD-WAN device to act as a DHCP server using Cisco vManage templates:
Create a DHCP-Server feature template to configure DHCP server parameters, as described in this topic.
Create one or more interface feature templates, as described in the VPN-Interface-Ethernet and the VPN-Interface-PPP-Ethernet
help topics.
Create a VPN feature template to configure VPN parameters. See the VPN help topic.
To configure a Cisco vEdge 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
From the Cisco vManage menu, choose Configuration > Templates.
Click Device Templates, and then click Create Template.
Note
In Cisco vManage Release 20.7.x and earlier releases, Device Templates is titled Device.
From the Create Template drop-down list, choose From Feature Template.
From the Device Model drop-down list, select the type of device for which you are creating the template.
Click Service VPN or scroll to the Service VPN section.
Click Service VPN drop-down list.
From Additional VPN Templates, click VPN Interface.
From the Sub-Templates drop-down list, choose DHCP Server.
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.
In Template Name, enter a name for the template.
The name can be up to 128 characters and can contain only alphanumeric characters.
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.
Table 1.
Parameter Name
Description
Address Pool*
Enter the IPv4 prefix range, in the format prefix/length, for the pool of addresses in the service-side network for which the router interface acts as DHCP server.
Exclude Addresses
Enter one or more IP addresses to exclude from the DHCP address pool. To specify multiple individual addresses, list them
separated by a comma. To specify a range of addresses, separate them with a hyphen.
Maximum Leases
Specify the number of IP addresses that can be assigned on this interface.Range: 0 through 4294967295
Lease Time
Specify how long a DHCP-assigned IP address is valid.Range: 0 through 4294967295 seconds
Offer Time
Specify how long the IP address offered to a DHCP client is reserved for that client. By default, an offered IP address is
reserved indefinitely, until the DHCP server runs out of addresses. At that point, the address is offered to another client.Range: 0 through 4294967295 secondsDefault: 600 seconds
Administrative State
Select Up to enable or Down to disable the DHCP functionality on the interface. By default, DHCP server functionality is disabled
on an interface.
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:
Table 2.
Parameter Name
Description
MAC Address
Enter the MAC address of the client to which the static IP address is being assigned.
IP Address
Enter the static IP address to assign to the client.
To configure a advanced DHCP server options, click Advanced and then configure the following parameters:
Table 3.
Parameter Name
Description
Interface MTU
Specify the maximum MTU size of packets on the interface.Range: 68 to 65535 bytes
Domain Name
Specify the domain name that the DHCP client uses to resolve hostnames.
Default Gateway
Enter the IP address of a default gateway in the service-side network.
DNS Servers
Enter one or more IP address for a DNS server in the service-side network. Separate multiple entries with a comma. You can
specify up to eight addresses.
TFTP Servers
Enter the IP address of a TFTP server in the service-side network. You can specify one or two addresses. If two, separate
them with a comma.
When you configure a tunnel interface on a Cisco vEdge device, a number of services are enabled by default on that interface, including DHCP.
A Cisco vEdge device can act as a DHCP server for the service-side network to which it is connected, and it can also act as a DHCP helper, forwarding
requests for IP addresses from devices in the service-side network to a DHCP server that is in a different subnet on the service
side of the Cisco vEdge device.
Enable DHCP on the WAN Interface
On a Cisco vEdge device's WAN interface—the interface configured as a tunnel interface in VPN 0, the transport VPN—DHCP is enabled by default. You
can see this by using the details filter with the show running-config command. This command also shows that the DNS and ICMP services are enabled by default.
vm1# show running-config vpn 0 interface ge0/2 tunnel-interface | details
vpn 0
interface ge0/2
tunnel-interface
encapsulation ipsec weight 1
color lte
control-connections
carrier default
no allow-service all
no allow-service bgp
allow-service dhcp
allow-service dns
allow-service icmp
no allow-service ospf
no allow-service sshd
no allow-service ntp
no allow-service stun
!
!
!
Enabling DHCP on the router's WAN interface allows the device that actually connects the router to the transport network (such
as a DSL router) to dynamically assign a DHCP address to the Cisco vEdge device. The DHCP service in VPN 0 affects the transport-side network.
Configure Cisco vEdge Device as a DHCP Server
One or more service-side interfaces on Cisco vEdge device can act as a DHCP server, assigning IP addresses to hosts in the service-side network. To do this, configure this function
on the interface that connects the Cisco vEdge device to the local site's network. At a minimum, you must configure the pool of IP addresses available for assigning to hosts:
You can exclude IP addresses that fall within the range of the DHCP address pool:
vEdge(config-dhcp-server)#excludeip-address
To specify multiple individual addresses, list them in a single exclude command, separated by a space (for example, exclude 10.1.1.1 10.2.2.2 10.3.3.3). To specify a range of addresses, separate them with a hyphen (for example, exclude 10.255.1.1-10.255.1.10).
You can also statically assign IP addresses to a host:
By default, the DHCP server on a single interface can assign 254 DHCP leases, and each lease is valid for 24 hours. The offer
of an IP address is valid indefinitely, until that DHCP server runs out of addresses to offer. You can modify these values:
The Cisco SD-WAN software supports DHCP server options that allow you to configure the IP addresses of a default gateway, DNS server, and
TFTP server in the service-side network and the network mask of the service-side network:
One or more service-side interfaces on a Cisco vEdge device can be a DHCP helper. With this configuration, the interface forwards any broadcast BOOTP DHCP requests that it receives
from hosts on the service-side network to the DHCP server or servers specified by the configured IP helper address (or addresses)
and returns the assigned IP address to the requester.
When the DHCP server at the Cisco vEdge device's local site is on a different segment than the devices connected to the Cisco vEdge device or than the Cisco vEdge device itself. When configured as a DHCP helper, the Cisco vEdge device interface forwards any broadcast BOOTP DHCP requests that it receives to the DHCP server specified by the configured IP helper
address.
To configure an interface as a DHCP helper, configure the IP address of the DHCP server on the interface that connects to
the local site's network:
You can configure up to four IP addresses, and you must enter the addresses in a single dhcp-helper command.
In Releases 17.2.2 and later, you can configure up to eight IP address. You must enter all the addresses in a single dhcp-helper command.
Configuring PPPoE
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 SD-WAN overlay network, Cisco SD-WAN devices can run the PPPoE client. The PPPoE server component is not supported.
To configure PPPoE client on a Cisco SD-WAN device, you create a PPP logical interface and link it to a physical interface. The PPPoE connection comes up when the physical
interface comes up. You can link a PPP interface to only one physical interface on a Cisco SD-WAN device, and you can link a physical interface to only one PPP interface. To enable more than one PPPoE interfaces on a Cisco SD-WAN device, configure multiple PPP interfaces.
It is recommended that you configure quality of service (QoS) and shaping rate on a PPPoE-enabled physical interface, and
not on the PPP interface.
PPPoE-enabled physical interfaces do not support:
802.1Q
Subinterfaces
NAT, PMTU, and tunnel interfaces. These are configured on the PPP interface and therefore not available on PPPoE-enabled interfaces.
The Cisco SD-WAN implementation of PPPoE does not support the Compression Control Protocol (CCP) options, as defined in RFC 1962.
Configure PPPoE from vManage Templates
To use vManage templates to configure PPPoE on Cisco vEdge device, you create three feature templates and one device template:
Create a VPN-Interface-PPP feature template to configure PPP parameters for the PPP virtual interface.
Create a VPN-Interface-PPP-Ethernet feature template to configure a PPPoE-enabled interface.
Optionally, create a VPN feature template to modify the default configuration of VPN 0.
Create a device template that incorporates the VPN-Interface-PPP, VPN-Interface-PPP-Ethernet, and VPN feature templates.
Create a VPN-Interface-PPP feature template to configure PPP parameters for the PPP virtual interface:
From the Cisco vManage menu, choose Configuration > Templates.
Click Feature Templates, and click Add Template.
Note
In Cisco vManage Release 20.7.x and earlier releases, Feature Templates is titled Feature.
Choose Cisco vEdge device Cloud or a router model.
Choose the VPN-Interface-PPP template.
In the template, configure the following parameters:
Table 4.
Parameter Field
Procedure
Template Name
Enter a name for the template. It can be up to 128 alphanumeric characters.
Description
Enter a description for the template. It can be up to 2048 alphanumeric characters.
Shutdown
Click No to enable the PPP virtual interface.
Interface Name
Enter the number of the PPP interface. It can be from 1 through 31.
Description (optional)
Enter a description for the PPP virtual interface.
Authentication Protocol
Select either CHAP or PAP to configure one authentication protocol, or select PAP and CHAP to configure both. For CHAP, enter
the hostname and password provided by your ISP. For PAP, enter the username and password provided by your ISP. If you are
configuring both PAP and CHAP, to use the same username and password for both, click Same Credentials for PAP and CHAP.
AC Name (optional)
Select the PPP tab, and in the AC Name field, enter the name of the the name of the access concentrator used by PPPoE to route
connections to the Internet.
IP MTU
Click Advanced, and in the IP MTU field, ensure that the IP MTU is at least 8 bytes less than the MTU on the physical interface. The maximum
MTU for a PPP interface is 1492 bytes. If the PPPoE server does not specify a maximum receive unit (MRU), the MTU value for
the PPP interface is used as the MRU.
Starting from Cisco vManage Release 20.9.1, there is 8 bytes overheads deduced based on the specified IP MTU value when configuration is pushed to the device.
Save
To save the feature template, click Save.
To create a VPN-Interface-PPP-Ethernet feature template to enable the PPPoE client on the physical interfaces:
From the Cisco vManage menu, choose Configuration > Templates.
Click Feature Templates, and click Add Template.
Note
In Cisco vManage Release 20.7.x and earlier releases, Feature Templates is titled Feature.
Choose Cisco vEdge device Cloud or a router model.
Choose the VPN-Interface-PPP-Ethernet template.
In the template, configure the following parameters:
Parameter Field
Procedure
Template Name
Enter a name for the template. It can be up to 128 alphanumeric characters.
Description
Enter a description for the template. It can be up to 2048 alphanumeric characters.
Shutdown
Click No to enable the PPPoE-enabled interface.
Interface Name
Enter the name of the physical interface in VPN 0 to associate with the PPP interface.
Description (optional)
Enter a description for the PPPoE-enabled interface.
IP Confguration
Assign an IP address to the physical interface:
To use DHCP, select Dynamic. The default administrative distance of routes learned from DHCP is 1.
To configure the IP address directly, enter of the IPv4 address of the interface.
DHCP Helper (optional)
Enter up to four IP addresses for DHCP servers in the network.
Save
To save the feature template, click Save.
To create a VPN feature template to configure the PPPoE-enabled interface in VPN 0, the transport VPN:
From the Cisco vManage menu, choose Configuration > Templates.
Click Feature Templates, and click Add Template.
Note
In Cisco vManage Release 20.7.x and earlier releases, Feature Templates is titled Feature.
Choose Cisco vEdge device Cloud or a router model.
Choose the VPN template.
In the template, configure the following parameters:
Parameter Field
Procedure
Template Name
Enter a name for the template. It can be up to 128 alphanumeric characters.
Description
Enter a description for the template. It can be up to 2048 alphanumeric characters.
VPN Identifier
Enter VPN identifier 0.
Name
Enter aname for the VPN.
Other interface parameters
Configure the desired interface properties.
Save
To save the feature template, click Save.
To create a device template that incorporates the VPN-Interface-PPP, VPN-Interface-PPP-Ethernet, and VPN feature templates:
From the Cisco vManage menu, choose Configuration > Templates.
Click Device Templates, and then click Create Template.
Note
In Cisco vManage Release 20.7.x and earlier releases, Device Templates is titled Device.
From the Create Template drop-down list, choose From Feature Template.
From the Device Model drop-down list, choose the type of device for which you are creating the device template.
vManage NMS displays the feature templates for the device type you selected. Required templates are indicated with an asterisk
(*).
Enter a name and description for the device template. These fields are mandatory. The template name cannot contain special
characters.
In Transport & Management VPN, under VPN 0, from the drop-down list of available templates, select the desired feature template. The list of available templates are
the ones that you have previously created.
In Additional VPN 0 Templates, click the plus sign (+) next to VPN Interface PPP.
From VPN-Interface-PPP and VPN-Interface-PPP-Ethernet fields, select the feature templates to use.
To configure multiple PPPoE-enabled interfaces in VPN 0, click the plus sign (+) next to Sub-Templates.
To include additional feature templates in the device template, in the remaining sections, select the feature templates in
turn, and from the drop-down list of available templates, select the desired template. The list of available templates are
the ones that you have previously created. Ensure that you select templates for all mandatory feature templates and for any
desired optional feature templates.
To create the device template, click Create.
To attach a device template to a device:
From the Cisco vManage menu, choose Configuration > Templates.
Click Device Templates.
Note
In Cisco vManage Release 20.7.x and earlier releases, Device Templates is titled Device.
Choose a template.
Click …, and click Attach Device.
Search for a device or select a device from the Available Device(s) column to the left.
Click the arrow pointing right to move the device to the Selected Device(s) column on the right.
Click Attach.
Configure PPPoE from the CLI
Table 5. Feature History
Feature Name
Release Information
Feature Description
Assign Static IP Address to PPP Interface.
Cisco SD-WAN Release 20.4.1
Cisco vManage Release 20.4.1
This feature enables you to assign a static IP address to a PPP
interface and configure PPP interface echo requests.
To use the CLI to configure PPPoE on Cisco vEdge devices:
Create a PPP interface. The interface number can be from 1 through
31.
vEdge(config-vpn)# interface pppnumber
Configure an authentication method for PPPoE and authentication credentials.
You can configure both CHAP and PAP authentication on the same PPP
interface. The software tries both methods and uses the first one that
succeeds.
vEdge(config-interface-ppp)# ppp authenticationchaphostnamenamepasswordpassword
vEdge(config-interface-ppp)# ppp authentication pap passwordpasswordsent-usernameusername
Enable the PPP interface to be operationally
up:
vEdge(config-interface-ppp)# no shutdown
Configure the MTU of the PPP interface. The maximum MTU for a PPP interface
is 1492 bytes. If maximum receive unit (MRU) is not specified by the PPPoE
server, the MTU value for the PPP interface is used as the
MRU.
vEdge(config-interface-ppp)# mtubytes
Configure a tunnel interface for the PPP
interface:
vEdge# show running-config vpn 0
vpn 0
interface ge0/1
pppoe-client ppp-interface ppp10
no shutdown
!
interface ppp10
ppp authentication chap
hostname branch100@corp.bank.myisp.net
password $4$OHHjdmsC6M8zj4BgLEFXKw==
!
ppp ac-name ac_name
ppp local-ip 10.1.5.15
ppp lcp-echo-failure 5
ppp lcp-echo-interval 25
tunnel-interface
encapsulation ipsec
color gold
no allow-service all
no allow-service bgp
allow-service dhcp
allow-service dns
allow-service icmp
no allow-service ospf
no allow-service sshd
no allow-service ntp
no allow-service stun
!
mtu 1492
no shutdown
!
!
To view existing PPP interfaces, use the show ppp interface command.
vEdge# show ppp interface
PPPOE INTERFACE PRIMARY SECONDARY
VPN IFNAME INTERFACE IP GATEWAY IP DNS DNS MTU
-----------------------------------------------------------------------------
0 ppp10 ge0/1 10.0.0.11 10.255.255.254 10.8.8.8 10.8.4.4 1150
To view PPPoE session information, use the show pppoe session command.
vEdge# show pppoe session
SESSION PPP SERVICE
VPN IFNAME ID SERVER MAC LOCAL MAC INTERFACE AC NAME NAME
--------------------------------------------------------------------------------------------
0 ge0/1 1 00:0c:29:2e:20:1a 00:0c:29:be:27:f5 ppp1 branch100 -
0 ge0/3 1 00:0c:29:2e:20:24 00:0c:29:be:27:13 ppp2 branch100 -
Configure PPPoE Over ATM
Table 6. Feature History
Feature Name
Release Information
Description
Configure PPPoE over ATM
Cisco IOS XE Release 17.4.1a
Cisco vManage Release 20.4.1
This feature provides support for configuring PPPoEoA on Cisco IOS XE SD-WAN devices. PPPoEoA uses AAL5MUX encapsulation which delivers better efficiency compared to other encapsulation methods.
You can configure PPPoE over ATM interfaces (PPPoEoA) on Cisco IOS XE SD-WAN devices that support ADSL. PPPoEoA uses ATM Adaptation Layer 5 Multiplexed Encapsulation (AAL5MUX) encapsulation to carry PPPoE
over ATM permanent virtual circuits (PVCs), providing efficiency gain over AAL5 LLC/SNAP encapsulation.
PPPoEoA over AAL5MUX reduces Subnetwork Access Protocol (SNAP) encapsulation bandwidth usage, using multiplexed (MUX) encapsulation
to reduce the number of cells needed to carry voice packets. Deploying the PPPoEoA over ATM AAL5MUX feature in a VoIP environment
results in improved throughput and bandwidth usage.
Supported Platforms for PPPoE Over ATM
The following platforms support PPPoE over ATM:
Cisco 1100 4G/6G Series Integrated Services routers.
Cisco1100 Series Integrated Service routers.
Cisco1109 Series Integrated Service routers.
Cisco111x Series Integrated Service routers.
Cisco1111x Series Integrated Service routers.
Cisco1120 Series Integrated Service routers.
Cisco1160 Series Integrated Service routers.
Configure PPPoE Over ATM using Cisco vManage
You can configure PPPoE using in Cisco vManage using the device CLI template.
From the Cisco vManage menu, choose Configuration > Templates.
From Device Templates, click Create Template.
Note
In Cisco vManage Release 20.7.x and earlier releases, Device Templates is titled Device.
From the Create Template drop-down list, select CLI Template.
From the Device Model drop-down list, select the type of device for which you are creating the template.
In Template Name, enter a name for the template. The name can be up to 128 characters and can contain only alphanumeric characters.
In Template Description, enter a description of the template. The description can be up to 2048 characters and can contain only alphanumeric characters.
Choose Device configuration. Using this option, you can provide IOS-XE configuration commands that appear in the output of the show sdwan running-config command.
(Optional) To load the running config of a connected device, select it from the Load Running config from reachable device
list and click Search.
In CLI Configuration, enter the configuration either by typing it, cutting and pasting it, or uploading a file. The configuration for PPPoEoA
is available in the Configure PPPoEoA on the CLI section.
To convert an actual configuration value to a variable, select the value and click Create Variable. Enter the variable name, and click Create Variable. You can also type the variable name directly, in the format {{variable-name}}; for example, {{hostname}}.
Click Add. The new device template is displayed in the Device Template table. The Type column shows CLI to indicate that the device template was created from CLI text.
Configure PPPoE Over ATM on the CLI
This section provides example CLI configurations to configure PPoE over ATM on the CLI.
Configuration Example for Configuring PPPoE Over ATM Interfaces
This example shows configuring PPPoE over ATM interfaces.
Device(config)# interface ATM0/1/0
Device(config)# no ip address
Device(config)# no atm enable-ilmi-trap
!
Device(config)# interface ATM0/1/0.10 point-to-point
Device(config)# no atm enable-ilmi-trap
Device(config)# cdp enable
Device(config)# pvc 22/62
Device(config)# ubr 1045
Device(config-if)# encapsulation aal5mux pppoe-client
Device(config)# pppoe-client dial-pool-number 120
!
!
Device(config)# interface Dialer 120
Device(config)# mtu 1492
Device(config)# ip address negotiated
Device(config)# ip nat outside
Device(config-if)# encapsulation ppp
Device(config)# load-interval 30
Device(config)# dialer pool 120
Device(config)# dialer-group 1
Device(config)# ppp mtu adaptive
Device(config)# ppp chap hostname test@cisco.com
Device(config)# ppp chap password 0 cisco
Device(config)# ppp ipcp address required
Device(config)# ppp link reorders
!
Configuring VRRP
Table 7. Feature History
Feature Name
Release Information
Description
Support for Multiple VRRP Groups on the Same LAN Interface or Sub-interface
Cisco SD-WAN Release 20.3.1
Cisco vManage Release 20.3.1
This feature increases support from one VRRP group per interface to five VRRP groups per interface. Multiple VRRP groups are
useful for providing redundancy and for load balancing.
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 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.
vEdge(config-vpn-0)# interface ge-slot/port
vEdge(config-interface-ge)# no shutdown
For each VRRP interface (or subinterface), you assign an IP address and you place that interface in a VRRP group.
vEdge(config-vpn)# interface ge-slot/port.subinterface
vEdge(config-interface-ge)# ip addressprefix/length
vEdge(config-interface-ge)# vrrpgroup-number
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.
vEdge(config-vrrp)# ipv4ip-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.
vEdge(config-vrrp)# prioritynumber
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.
vEdge(config-vrrp)# timerseconds
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.
vEdge(config-vrrp)# track-omp
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 vSmart Controllers. Until the routers are learned, traffic is also dropped.
Track both the OMP session and a list of remote prefixes. list-name is the name of a prefix list configured with the policy lists prefix-list command on the Cisco vEdge device :
vEdge(config-vrrp)# track-prefix-listlist-name
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.
Here is an example of configuring VRRP on redundant physical interfaces. For subinterface 2, vEdge1 is configured to act as
the primary VRRP, and for subinterface 3, vEdge2 acts as the primary VRRP.
vEdge1# show running-config vpn 1
vpn 1
interface ge0/6.2
ip address 10.2.2.3/24
mtu 1496
no shutdown
vrrp 2
ipv4 10.2.2.1
track-prefix-list vrrp-prefix-list1
!
!
interface ge0/6.3
ip address 10.2.3.5/24
mtu 1496
shutdown
vrrp 3
ipv4 10.2.3.11
track-prefix-list vrrp-prefix-list1
!
!
!
vEdge2# show running-config vpn 1
vpn 1
interface ge0/1.2
ip address 10.2.2.4/24
mtu 1496
no shutdown
vrrp 2
ipv4 10.2.2.1
track-prefix-list vrrp-prefix-list2
!
!
interface ge0/1.3
ip address 10.2.3.6/24
mtu 1496
no shutdown
vrrp 3
ipv4 10.2.3.11
track-prefix-list vrrp-prefix-list2
!
!
!
vEdge1# show interface vpn 1
IF IF TCP
ADMIN OPER ENCAP PORT SPEED MSS RX TX
VPN INTERFACE IP ADDRESS STATUS STATUS TYPE TYPE MTU HWADDR MBPS DUPLEX ADJUST UPTIME PACKETS PACKETS
-------------------------------------------------------------------------------------------------------------------------------------------
1 ge0/6.2 10.2.2.3/24 Up Up vlan service 1496 00:0c:29:ab:b7:94 10 full 0 0:00:05:52 0 357
1 ge0/6.3 10.2.3.5/24 Down Down vlan service 1496 00:0c:29:ab:b7:94 - - 0 - 0 0
vEdge1# show vrrp interfaces
MASTER TRACK PREFIX
GROUP VIRTUAL VRRP OMP ADVERTISEMENT DOWN PREFIX LIST
VPN IF NAME ID IP VIRTUAL MAC PRIORITY STATE STATE TIMER TIMER LAST STATE CHANGE TIME LIST STATE
----------------------------------------------------------------------------------------------------------------------------------------------
1 ge0/6.2 2 10.2.2.1 00:0c:29:ab:b7:94 100 master down 1 3 2015-05-01T20:09:37+00:00 - -
ge0/6.3 3 10.2.3.11 00:00:00:00:00:00 100 init down 1 3 0000-00-00T00:00:00+00:00 - -
In the following example, Router-1 is the primary VRRP, because it has a higher priority value than Router 2:
Router-1# show running-config vpn 1
vpn 1
!
interface ge0/1.15
ip address 10.10.1.2/24
mtu 1496
no shutdown
vrrp 15
priority 110
track-omp
ipv4 10.20.23.1
!
!
!
Router-1# show vrrp vpn 1
MASTER TRACK PREFIX
GROUP VRRP OMP ADVERTISEMENT DOWN PREFIX LIST
VPN IF NAME ID VIRTUAL IP VIRTUAL MAC PRIORITY STATE STATE TIMER TIMER LAST STATE CHANGE TIME LIST STATE
---------------------------------------------------------------------------------------------------------------------------------------------------
1 ge0/1.1 1 10.20.22.1 00:0c:bd:08:79:a4 100 backup up 1 3 2016-01-13T03:10:55+00:00 - -
ge0/1.5 5 10.20.22.193 00:0c:bd:08:79:a4 100 backup up 1 3 2016-01-13T03:10:55+00:00 - -
ge0/1.10 10 10.20.22.225 00:0c:bd:08:79:a4 100 backup up 1 3 2016-01-13T03:10:55+00:00 - -
ge0/1.15 15 10.20.23.1 00:0c:bd:08:79:a4 110 master up 1 3 2016-01-13T03:10:56+00:00 - -
ge0/1.20 20 10.20.24.1 00:0c:bd:08:79:a4 100 backup up 1 3 2016-01-13T03:10:56+00:00 - -
ge0/1.25 25 10.20.25.1 00:0c:bd:08:79:a4 110 master up 1 3 2016-01-13T03:10:56+00:00 - -
ge0/1.30 30 10.20.25.129 00:0c:bd:08:79:a4 100 backup up 1 3 2016-01-13T03:10:56+00:00 - -
Router-1# show vrrp vpn 1 interfaces ge0/1.15 groups 15
MASTER TRACK PREFIX
GROUP VRRP OMP ADVERTISEMENT DOWN PREFIX LIST
ID VIRTUAL IP VIRTUAL MAC PRIORITY STATE STATE TIMER TIMER LAST STATE CHANGE TIME LIST STATE
----------------------------------------------------------------------------------------------------------------------------------
1 10.20.33.1 00:0c:bd:08:79:a4 110 master up 1 3 2016-01-13T03:10:56+00:00 - -
Router-2# show running-config vpn 1
vpn 1
!
interface ge0/1.15
ip address 10.10.1.3/24
mtu 1496
no shutdown
vrrp 15
track-omp
ipv4 10.20.23.1
!
!
!
Router-2# show vrrp vpn 1 interfaces groups
MASTER TRACK PREFIX
GROUP VRRP OMP ADVERTISEMENT DOWN PREFIX LIST
IF NAME ID VIRTUAL IP VIRTUAL MAC PRIORITY STATE STATE TIMER TIMER LAST STATE CHANGE TIME LIST STATE
----------------------------------------------------------------------------------------------------------------------------------------------
ge0/1.1 1 10.20.32.1 00:0c:bd:08:2b:a5 110 master up 1 3 2016-01-13T00:22:15+00:00 - -
ge0/1.5 5 10.20.32.193 00:0c:bd:08:2b:a5 110 master up 1 3 2016-01-13T00:22:15+00:00 - -
ge0/1.10 10 10.20.32.225 00:0c:bd:08:2b:a5 110 master up 1 3 2016-01-13T00:22:15+00:00 - -
ge0/1.15 15 10.20.33.1 00:0c:bd:08:2b:a5 100 backup up 1 3 2016-01-13T03:10:56+00:00 - -
ge0/1.20 20 10.20.34.1 00:0c:bd:08:2b:a5 110 master up 1 3 2016-01-13T00:22:16+00:00 - -
ge0/1.25 25 10.20.35.1 00:0c:bd:08:2b:a5 100 backup up 1 3 2016-01-13T03:10:56+00:00 - -
ge0/1.30 30 10.20.35.129 00:0c:bd:08:2b:a5 100 master up 1 3 2016-01-13T00:22:16+00:00 - -
Router-2# show vrrp vpn 100 interfaces groups 15
MASTER TRACK PREFIX
GROUP VRRP OMP ADVERTISEMENT DOWN PREFIX LIST
IF NAME ID VIRTUAL IP VIRTUAL MAC PRIORITY STATE STATE TIMER TIMER LAST STATE CHANGE TIME LIST STATE
--------------------------------------------------------------------------------------------------------------------------------------------
ge0/0.15 15 10.20.33.1 00:0c:bd:08:2b:a5 100 backup up 1 3 2016-01-13T03:10:56+00:00 - -
Multiple VRRP Groups on One Interface
Cisco SD-WAN supports configuring multiple VRRP groups on an interface. A use case for configuring this is where primary and
secondary IP addresses have been assigned to a single interface. On one interface, you can configure:
One primary IP address
Up to four secondary IP addresses
To support each of these IP addresses, you can configure up to 5 VRRP groups (each with a unique group ID) on an interface,
subinterface, or integrated routing and bridging (IRB) interface that supports VRRP groups.
The following is an example of configuring 5 VRRP groups on 1 interface.
vpn 2
interface ge0/4.2
ip address 10.0.1.10/24
ip secondary-address 10.0.2.10/24
ip secondary-address 10.0.3.10/24
ip secondary-address 10.0.4.10/24
mtu 1496
no shutdown
vrrp 1
priority 101
ipv4 10.0.1.1
!
vrrp 2
ipv4 10.0.1.2
!
vrrp 3
priority 101
ipv4 10.0.2.1
!
vrrp 4
ipv4 10.0.3.1
!
vrrp 5
ipv4 10.0.4.1
!
!
!
Network Interface Configuration Examples for Cisco vEdge Devices
This topic provides examples of configuring interfaces on Cisco vEdge devices to allow the flow of data traffic across both public and private WAN transport networks.
Connect to a Public WAN
This example shows a basic configuration for two connected to the same public WAN network (such as the Internet). The Cisco vSmart Controller and Cisco vBond Orchestrator are also connected to the public WAN network, and the Cisco vSmart Controller is able to reach all destinations on the public WAN.
For Cisco vEdge device-1, the interface ge0/1 connects to the public WAN, so it is the interface that is configured as a tunnel interface. The tunnel
has a color of biz-internet, and the encapsulation used for data traffic is IPsec. The Cisco SD-WAN software creates a single
TLOC for this interface, comprising the interface's IP address, color, and encapsulation, and the TLOC is sent to the Cisco vSmart Controller over the OMP session running on the tunnel. The configuration also includes a default route to ensure that the router can
reach the Cisco vBond Orchestrator and Cisco vSmart Controller.
vpn 0
interface ge0/1
ip address 172.16.13.3/24
tunnel-interface
encapsulation ipsec
color biz-internet
allow-service dhcp
allow-service dns
allow-service icmp
no allow-service sshd
no allow-service ntp
no allow-service stun
!
no shutdown
!
ip route 0.0.0.0/0 0.0.0.0
!
The configuration for Cisco vEdge device-2 is similar to that for Cisco vEdge device-1:
vpn 0
interface ge0/1
ip address 172.16.15.5/24
tunnel-interface
encapsulation ipsec
color biz-internet
allow-service dhcp
allow-service dns
allow-service icmp
no allow-service sshd
no allow-service ntp
no allow-service stun
!
no shutdown
!
ip route 0.0.0.0/0 0.0.0.0
!
On the Cisco vSmart Controller and Cisco vBond Orchestrator, you configure a tunnel interface and default IP route to reach the WAN transport. For the tunnel, color has no meaning because
these devices have no TLOCs.
vpn 0
interface eth1
ip address 172.16.8.9/24
tunnel-interface
!
no shutdown
!
ip route 0.0.0.0/0 0.0.0.0
!
vpn 0
interface ge0/1
ip address 172.16.16.6/24
tunnel-interface
!
no shutdown
!
ip route 0.0.0.0/0 0.0.0.0
!
Use the show interface command to check that the interfaces are operational and that the tunnel connections have been established. In the Port Type
column, tunnel connections are marked as "transport".
vEdge-1# show interface vpn 0
IF IF TCP
ADMIN OPER ENCAP SPEED MSS RX TX
VPN INTERFACE IP ADDRESS STATUS STATUS TYPE PORT TYPE MTU HWADDR MBPS DUPLEX ADJUST UPTIME PACKETS PACKETS
--------------------------------------------------------------------------------------------------------------------------------------------------
0 ge0/0 172.16.13.3/24 Up Up null transport 1500 00:0c:29:7d:1e:fe 10 full 0 0:02:26:20 88358 88202
0 ge0/1 10.1.17.15/24 Up Up null service 1500 00:0c:29:7d:1e:08 10 full 0 0:02:26:20 217 1
0 ge0/2 - Down Up null service 1500 00:0c:29:7d:1e:12 10 full 0 0:02:26:20 217 0
0 ge0/3 10.0.20.15/24 Up Up null service 1500 00:0c:29:7d:1e:1c 10 full 0 0:02:26:20 218 1
0 ge0/6 172.17.1.15/24 Up Up null service 1500 00:0c:29:7d:1e:3a 10 full 0 0:02:26:20 217 1
0 ge0/7 10.0.100.15/24 Up Up null service 1500 00:0c:29:7d:1e:44 10 full 0 0:02:25:02 850 550
0 system 172.16.255.3/32 Up Up null loopback 1500 00:00:00:00:00:00 10 full 0 0:02:13:31 0 0
Use the show control connections command to check that the Cisco vEdge device has a DTLS or TLS session established to the Cisco vSmart Controller.
vEdge-1# show control connections
PEER PEER
PEER PEER PEER SITE DOMAIN PEER PRIVATE PEER PUBLIC
TYPE PROTOCOL SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT LOCAL COLOR STATE UPTIME
--------------------------------------------------------------------------------------------------------------------------------------------------------------
vsmart dtls 172.16.255.19 100 1 10.0.5.19 12346 10.0.5.19 12346 biz-internet up 0:02:13:13
vsmart dtls 172.16.255.20 200 1 10.0.12.20 12346 10.0.12.20 12346 biz-internet up 0:02:13:13
Use the show bfd sessions command to display information about the BFD sessions that have been established between the local Cisco vEdge device and remote routers:
vEdge-1# show bfd sessions
SOURCE TLOC REMOTE TLOC DST PUBLIC DST PUBLIC DETECT TX
SYSTEM IP SITE ID STATE COLOR COLOR SOURCE IP IP PORT ENCAP MULTIPLIER INTERVAL(msec) UPTIME TRANSITIONS
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
172.16.255.11 100 up biz-internet biz-internet 10.1.15.15 10.0.5.11 12346 ipsec 20 1000 0:02:24:59 1
172.16.255.14 400 up biz-internet biz-internet 10.1.15.15 10.1.14.14 12360 ipsec 20 1000 0:02:24:59 1
172.16.255.16 600 up biz-internet biz-internet 10.1.15.15 10.1.16.16 12346 ipsec 20 1000 0:02:24:59 1
172.16.255.21 100 up biz-internet biz-internet 10.1.15.15 10.0.5.21 12346 ipsec 20 1000 0:02:24:59 1
Use the show omp tlocs command to list the TLOCs that the local router has learned from the Cisco vSmart Controller:
vEdge-1# show omp tlocs
C -> chosen
I -> installed
Red -> redistributed
Rej -> rejected
L -> looped
R -> resolved
S -> stale
Ext -> extranet
Inv -> invalid
ADDRESS PUBLIC PRIVATE BFD
FAMILY TLOC IP COLOR ENCAP FROM PEER STATUS PUBLIC IP PORT PRIVATE IP PORT STATUS
----------------------------------------------------------------------------------------------------------------------------------------
ipv4 172.16.255.11 biz-internet ipsec 172.16.255.19 C,I,R 10.0.5.11 12346 10.0.5.11 12346 up
172.16.255.20 C,R 10.0.5.11 12346 10.0.5.11 12346 up
172.16.255.14 biz-internet ipsec 172.16.255.19 C,I,R 10.1.14.14 12360 10.1.14.14 12360 up
172.16.255.20 C,R 10.1.14.14 12360 10.1.14.14 12360 up
172.16.255.16 biz-internet ipsec 172.16.255.19 C,I,R 10.1.16.16 12346 10.1.16.16 12346 up
172.16.255.20 C,R 10.1.16.16 12346 10.1.16.16 12346 up
172.16.255.21 biz-internet ipsec 172.16.255.19 C,I,R 10.0.5.21 12346 10.0.5.21 12346 up
172.16.255.20 C,R 10.0.5.21 12346 10.0.5.21 12346 up <
Connect to Two Public WANs
In this example, two Cisco vEdge devices at two different sites connect to two public WANs, and hence each router has two tunnel connections. To direct traffic to
the two different WANs, each tunnel interface is assigned a different color (here, silver and gold). Because each router has two tunnels, each router has two TLOCs.
A third router at a third site, vEdge-3, connects only to one of the public WANs.
The Cisco vSmart Controller and Cisco vBond Orchestrator are connected to one of the public WAN networks. (In reality, it does not matter which of the two networks they are connected
to, nor does it matter whether the two devices are connected to the same network). The Cisco vSmart Controller is able to reach all destinations on the public WAN. To ensure that the Cisco vBond Orchestrator is accessible via each transport tunnel on the routers, a default route is configured for each interface. In our example,
we configure a static default route, but you can also use DHCP.
The configurations for vEdge-1 and vEdge-2 are similar. We configure two tunnel interfaces, one with color silver and the other with color gold, and we configure static default routes for both tunnel interfaces. Here is the configuration for vEdge-1:
vpn 0
interface ge0/1
ip address 172.16.13.3/24
tunnel-interface
encapsulation ipsec
color silver
!
no shutdown
!
interface ge0/2
ip address 10.10.23.3/24
tunnel-interface
encapsulation ipsec
color gold
!
no shutdown
!
ip route 0.0.0.0/0 0.0.0.0
The configuration for vEdge-2 is similar:
vpn 0
interface ge0/1
ip address 172.16.15.5/24
tunnel-interface
encapsulation ipsec
color silver
!
no shutdown
!
interface ge0/2
ip address 10.10.25.3/24
tunnel-interface
encapsulation ipsec
color gold
!
no shutdown
!
ip route 0.0.0.0/0 0.0.0.0
The third router, vEdge-3, connects only to one of the public WAN networks, and its tunnel interface is assigned the color
"gold":
vpn 0
interface ge0/1
ip address 172.16.8.4/24
tunnel-interface
encapsulation ipsec
color gold
!
no shutdown
!
ip route 0.0.0.0/0 0.0.0.0
On the Cisco vSmart Controller and Cisco vBond Orchestrator, you configure a tunnel interface and default IP route to reach the WAN transport. For the tunnel, color has no meaning because
these devices have no TLOCs.
vpn 0
interface eth1
ip address 172.16.8.9/24
tunnel-interface
!
no shutdown
ip route 0.0.0.0/0 0.0.0.0
vpn 0
interface ge0/1
ip address 172.16.16.6/24
tunnel-interface
!
no shutdown
ip route 0.0.0.0/0 0.0.0.0
Connect to Public and Private WANs, with Separation of Network Traffic
In this example, two Cisco vEdge devices at two different sites each connect to the same public WAN (here, the Internet) and the same private WAN (here, an MPLS network).
We want to separate the MPLS network completely so that it is not reachable by the Internet. The Cisco vSmart Controller and Cisco vBond Orchestrator are hosted in the provider's cloud, which is reachable only via the Internet. A third Cisco vEdge device at a third site connects only to the public WAN (Internet).
In this example topology, we need to ensure the following:
Complete traffic separation exists between private-WAN (MPLS) traffic and public-WAN (Internet) traffic.
Each site (that is, each Cisco vEdge device) must have a connection to the Internet, because this is the only way that the overlay network can come up.
To maintain complete separation between the public and private networks so that all MPLS traffic stays within the MPLS network,
and so that only public traffic passes over the Internet, we create two overlays, one for the private MPLS WAN and the second
for the public Internet. For the private overlay, we want to create data traffic tunnels (which run IPsec and BFD sessions)
between private-WAN TLOCs, and for the public overlay we want to create these tunnel connections between Internet TLOCs. To
make sure that no data traffic tunnels are established between private-WAN TLOCs and Internet TLOCs, or vice versa, we associate
the restrict attribute with the color on the private-WAN TLOCs. 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. Put another way, BFD sessions come up between
two private-WAN TLOCs and they come up between two public-WAN TLOCs, but they do not come up between an MPLS TLOC and an Internet
TLOC.
Each site must have a connection to the public (Internet) WAN so that the overlay network can come up. In this topology, the
Cisco vSmart Controller and Cisco vBond Orchestrator are reachable only via the Internet, but the MPLS network is completely isolated from the Internet. This means that if a
Cisco vEdge device were to connect just to the MPLS network, it would never be able to discover the Cisco vSmart Controller and Cisco vBond Orchestrators and so would never be able to never establish control connections in the overlay network. In order for a Cisco vEdge device in the MPLS network to participate in overlay routing, it must have at least one tunnel connection, or more specifically,
one TLOC, to the Internet WAN. (Up to seven TLOCs can be configured on each Cisco vEdge device). The overlay network routes that the router router learns over the public-WAN tunnel connection populate the routing table
on the Cisco vEdge device and allow the router and all its interfaces and TLOCs to participate in the overlay network.
By default, all tunnel connections attempt to establish control connections in the overlay network. Because the MPLS tunnel
connections are never going to be able to establish these connections to the Cisco vSmart Controller or Cisco vBond Orchestrators, we include the max-control-connections 0 command in the configuration. While there is no harm in having the MPLS tunnels attempt to establish control connections,
these attempts will never succeed, so disabling them saves resources on the Cisco vEdge device. Note that max-control-connections 0 command works only when there is no NAT device between the Cisco vEdge device and the PE router in the private WAN.
Connectivity to sites in the private MPLS WAN is possible only by enabling service-side routing.
Here is the configuration for the tunnel interfaces on vEdge-1. This snippet does not include the service-side routing configuration.
vpn 0
interface ge0/1
ip address 172.16.13.3/24
tunnel-interface
encapsulation ipsec
color biz-internet
!
no shutdown
!
interface ge0/2
ip address 10.10.23.3/24
tunnel-interface
encapsulation ipsec
color mpls restrict
max-control-connections 0
!
no shutdown
!
ip route 0.0.0.0/0 0.0.0.0
The configuration on vEdge-2 is quite similar:
vpn 0
interface ge0/1
ip address 172.16.15.5/24
tunnel-interface
encapsulation ipsec
color biz-internet
!
no shutdown
!
interface ge0/2
ip address 10.10.25.3/24
tunnel-interface
encapsulation ipsec
color mpls restrict
max-control-connections 0
!
no shutdown
!
ip route 0.0.0.0/0 0.0.0.0
!
The vEdge-3 router connects only to the public Internet WAN:
vpn 0
interface ge0/1
ip address 172.16.8.4/24
tunnel-interface
encapsulation ipsec
color biz-internet
!
no shutdown
!
ip route 0.0.0.0/0 0.0.0.0
!
On the Cisco vSmart Controller and Cisco vBond Orchestrator, you configure a tunnel interface and default IP route to reach the WAN transport. For the tunnel, color has no meaning because
these devices have no TLOCs.
vpn 0
interface eth1
ip address 172.16.8.9/24
tunnel-interface
!
no shutdown
!
ip route 0.0.0.0/0 0.0.0.0
!
vpn 0
interface ge0/1
ip address 172.16.16.6/24
tunnel-interface
!
no shutdown
!
ip route 0.0.0.0/0 0.0.0.0
!
Connect to Public and Private WANs, with Ubiquitous Connectivity to Both WANs
This example is a variant of the previous example. We still have two Cisco vEdge devices at two different sites each connect to the same public WAN (here, the Internet) and the same private WAN (here, an MPLS network).
However, now we want sites on the MPLS network and the Internet to be able to exchange data traffic. This topology requires
a single overlay over both the public and private WANs. Control connections are present over both transports, and we want
IPsec tunnel connections running BFD sessions to exist from private-WAN TLOCs to private-WAN TLOCs, from Internet TLOCs to
Internet TLOCs, from private-WAN TLOCs to Internet TLOCs, and from Internet TLOCs to private-WAN TLOCs. This full possibility
of TLOCs allows the establishment of a ubiquitous data plane in the overlay network.
For this configuration to work, the Cisco vBond Orchestrator must be reachable over both WAN transports. Because it is on the public WAN (that is, on the Internet), there needs to be
connectivity from the private WAN to the Internet. This could be provided via a DMZ, as shown in the figure above. The Cisco vSmart Controller can be either on the public or the private LAN. If there are multiple controllers, some can be on public LAN and others on
private LAN.
On each Cisco vEdge device, you configure private-WAN TLOCs, assigning a private color (metro-ethernet, mpls, or private1 through private6) to the tunnel interface. You also configure public TLOCs, assigning any other color (or you can leave the color as default). Each Cisco vEdge device needs two routes to reach the Cisco vBond Orchestrator, one via the private WAN and one via the public WAN.
With such a configuration:
Control connections are established over each WAN transport.
BFD/IPsec comes up between all TLOCs (if no policy is configured to change this).
A given site can be dual-homed to both WAN transports or single-homed to either one.
Here is an example of the configuration on one of the Cisco vEdge devices, vEdge-1:
vpn 0
interface ge0/1
description "Connection to public WAN"
ip address 172.16.31.3/24
tunnel-interface
encapsulation ipsec
color biz-internet
!
no shutdown
!
interface ge0/2
description "Connection to private WAN"
ip address 10.10.23.3/24
tunnel-interface
encapsulation ipsec
color mpls
!
no shutdown
!
ip route 0.0.0.0/0 0.0.0.0
!
The show control connections command lists two DTLS sessions to theCisco vSmart Controller, one from the public tunnel (color of biz-internet) and one from the private tunnel (color of mpls):
vEdge-1# show control connections
PEER PEER
PEER PEER PEER SITE DOMAIN PEER PRIVATE PEER PUBLIC
TYPE PROTOCOL SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT LOCAL COLOR STATE UPTIME
--------------------------------------------------------------------------------------------------------------------------------------------------------------
vsmart dtls 10.255.1.9 900 1 172.16.8.2 12346 172.16.8.2 12346 mpls up 0:01:41:17
vsmart dtls 10.255.1.9 900 1 172.16.8.2 12346 172.16.8.2 12346 biz-internet up 0:01:41:33
The show bfd sessions command output shows that vEdge-1 has separate tunnel connections that are running separate BFD sessions for each color:
vEdge-1# show bfd sessions
SOURCE TLOC REMOTE TLOC DST PUBLIC DST PUBLIC DETECT TX
SYSTEM IP SITE ID STATE COLOR COLOR SOURCE IP IP PORT ENCAP MULTIPLIER INTERVAL(msec) UPTIME TRANSITIONS
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
10.255.1.5 500 up mpls biz-internet 10.10.23.3 172.16.51.5 12346 ipsec 3 1000 0:06:07:19 1
10.255.1.5 500 up biz-internet biz-internet 172.16.31.3 172.16.51.5 12360 ipsec 3 1000 0:06:07:19 1
10.255.1.6 600 up mpls biz-internet 10.10.23.3 172.16.16.6 12346 ipsec 3 1000 0:06:07:19 1
10.255.1.6 600 up biz-internet biz-internet 172.16.31.3 172.16.16.6 12346 ipsec 3 1000 0:06:07:19 1
Exchange Data Traffic within a Single Private WAN
When the Cisco vEdge device is connected is a private WAN network, such as an MPLS or a metro Ethernet network, and when the carrier hosting the private
network does not advertise the router's IP address, remote Cisco vEdge devices on the same private network but at different sites can never learn how to reach that router and hence are not able to exchange
data traffic with it by going only through the private network. Instead, the remote routers must route data traffic through
a local NAT and over the Internet to a Cisco vBond Orchestrator, which then provides routing information to direct the traffic to its destination. This process can add significant overhead
to data traffic exchange, because the Cisco vBond Orchestrator may physically be located at a different site or a long distance from the two Cisco vEdge devices and because it may be situated behind a DMZ.
To allow Cisco vEdge devices at different overlay network sites on the private network to exchange data traffic directly using their private IP addresses,
you configure their WAN interfaces to have one of eight private colors, metro-ethernet, mpls, and private1 through private6. Of these four colors, the WAN interfaces on the Cisco vEdge devices must be marked with the same color so that they can exchange data traffic.
To illustrate the exchange of data traffic across private WANs, let's look at a simple topology in which two Cisco vEdge devices are both connected to the same private WAN. The following figure shows that these two Cisco vEdge devices are connected to the same private MPLS network. The vEdge-1 router is located at Site 1, and vEdge-2 is at Site 2. Both routers
are directly connected to PE routers in the carrier's MPLS cloud, and you want both routers to be able to communicate using
their private IP addresses.
This topology requires a special configuration to allow traffic exchange using private IP addresses because:
The Cisco vEdge devices are in different sites; that is, they are configured with different site IDs.
The Cisco vEdge devices are directly connected to the PE routers in the carrier's MPLS cloud.
The MPLS carrier does not advertise the link between the Cisco vEdge device and its PE router.
To be clear, if the situation were one of the following, no special configuration would be required:
vEdge-1 and vEdge-2 are configured with the same site ID.
vEdge-1 and vEdge-2 are in different sites, and the Cisco vEdge device connects to a CE router that, in turn, connects to the MPLS cloud.
vEdge-1 and vEdge-2 are in different sites, the Cisco vEdge device connects to the PE router in the MPLS cloud, and the private network carrier advertises the link between the Cisco vEdge device and the PE router in the MPLS cloud.
vEdge-1 and vEdge-2 are in different sites, and you want them to communicate using their public IP addresses.
In this topology, because the MPLS carrier does not advertise the link between the Cisco vEdge device and the PE router, you use a loopback interface on the each Cisco vEdge device to handle the data traffic instead of using the physical interface that connects to the WAN. Even though the loopback interface
is a virtual interface, when you configure it on the Cisco vEdge device, it is treated like a physical interface: the loopback interface is a terminus for both a DTLS tunnel connection and an IPsec
tunnel connection, and a TLOC is created for it.
This loopback interface acts as a transport interface, so you must configure it in VPN 0.
For the vEdge-1 and vEdge-2 routers to be able to communicate using their private IP addresses over the MPLS cloud, you set
the color of their loopback interfaces to be the same and to one of eight special colors—metro-ethernet, mpls, and private1 through private6.
Here is the configuration on vEdge-1:
vedge-1(config)# vpn 0
vedge-1(config-vpn-0)# interface loopback1
vedge-1(config-interface-loopback1)# ip address 172.16.255.25/32
vedge-1(config-interface-loopback1)# tunnel-interface
vedge-1(config-tunnel-interface)# color mpls
vedge-1(config-interface-tunnel-interface)# exit
vedge-1(config-tunnel-interface)# no shutdown
vedge-1(config-tunnel-interface)# commit and-quit
vedge-1# show running-config vpn 0
...
interface loopback1
ip-address 172.16.255.25/32
tunnel-interface
color mpls
!
no shutdown
!
On vEdge-2, you configure a loopback interface with the same tunnel interface color that you used for vEdge-1:
vedge-2# show running-config vpn 0
vpn 0
interface loopback2
ip address 172.17.255.26/32
tunnel-interface
color mpls
no shutdown
!
Use the show interface command to verify that the loopback interface is up and running. The output shows that the loopback interface is operating
as a transport interface, so this is how you know that it is sending and receiving data traffic over the private network.
vedge-1# show interface
IF IF TCP
ADMIN OPER ENCAP SPEED MSS RX TX
VPN INTERFACE IP ADDRESS STATUS STATUS TYPE PORT TYPE MTU HWADDR MBPS DUPLEX ADJUST UPTIME PACKETS PACKETS
--------------------------------------------------------------------------------------------------------------------------------------------------
0 ge0/0 10.1.15.15/24 Up Up null transport 1500 00:0c:29:7d:1e:fe 10 full 0 0:07:38:49 213199 243908
0 ge0/1 10.1.17.15/24 Up Up null service 1500 00:0c:29:7d:1e:08 10 full 0 0:07:38:49 197 3
0 ge0/2 - Down Down null service 1500 00:0c:29:7d:1e:12 - - 0 - 1 1
0 ge0/3 10.0.20.15/24 Up Up null service 1500 00:0c:29:7d:1e:1c 10 full 0 0:07:38:49 221 27
0 ge0/6 172.17.1.15/24 Up Up null service 1500 00:0c:29:7d:1e:3a 10 full 0 0:07:38:49 196 3
0 ge0/7 10.0.100.15/24 Up Up null service 1500 00:0c:29:7d:1e:44 10 full 0 0:07:44:47 783 497
0 loopback1 172.16.255.25/32 Up Up null transport 1500 00:00:00:00:00:00 10 full 0 0:00:00:20 0 0
0 system 172.16.255.15/32 Up Up null loopback 1500 00:00:00:00:00:00 10 full 0 0:07:38:25 0 0
1 ge0/4 10.20.24.15/24 Up Up null service 1500 00:0c:29:7d:1e:26 10 full 0 0:07:38:46 27594 27405
1 ge0/5 172.16.1.15/24 Up Up null service 1500 00:0c:29:7d:1e:30 10 full 0 0:07:38:46 196 2
512 eth0 10.0.1.15/24 Up Up null service 1500 00:50:56:00:01:05 1000 full 0 0:07:45:55 15053 10333
To allow Cisco vEdge device at different overlay network sites on the private network to exchange data traffic directly, you use a loopback interface
on the each Cisco vEdge device to handle the data traffic instead of using the physical interface that connects to the WAN. You associate the same tag,
called a carrier tag, with each loopback interface so that all the routers learn that they are on the same private WAN. Because
the loopback interfaces are advertised across the overlay network, the vEdge routers are able to learn reachability information,
and they can exchange data traffic over the private network. To allow the data traffic to actually be transmitted out the
WAN interface, you bind the loopback interface to a physical WAN interface, specifically to the interface that connects to
the private network. Remember that this is the interface that the private network does not advertise. However, it is still
capable of transmitting data traffic.
Exchange Data Traffic between Two Private WANs
This example shows a topology with two different private networks, possibly the networks of two different network providers,
and all the Cisco SD-WAN devices are located somewhere on one or both of the private networks. Two Cisco vEdge devices are located at two different sites, and they both connect to both private networks. A third Cisco vEdge device connects to only one of the private WANs. The Cisco vBond Orchestrator and Cisco vSmart Controller both sit in one of the private WANs, perhaps in a data center, and they are reachable over both private WANs. For the Cisco vEdge devices to be able to establish control connections, the subnetworks where the Cisco vBond Orchestrator and Cisco vSmart Controller devices reside must be advertised into each private WAN. Each private WAN CPE router then advertises these subnets in its
VRF, and each Cisco vEdge device learns those prefixes from each PE router that it is connected to.
Because both WANs are private, we need only a single overlay. In this overlay network, without policy, IPsec tunnels running
BFD sessions exist from any TLOC connected to either transport network to any TLOC in the other transport as well as to any
TLOC in the same WAN transport network.
As with the previous examples in this topic, it is possible to configure the tunnel interfaces on the routers' physical interfaces.
If you do this, you also need to configure a routing protocol between the Cisco vEdge device at its peer PE router, and you need to configure access lists on the Cisco vEdge device to advertise all the routes in both private networks.
A simpler configuration option that avoids the need for access lists is to use loopback interfaces as the tunnel interfaces,
and then bind each loopback interface to the physical interface that connects to the private network. Here, the loopback interfaces
become the end points of the tunnel, and the TLOC connections in the overlay network run between loopback interfaces, not
between physical interfaces. So in the figure shown above, on router vEdge-1, the tunnel connections originate at the Loopback1
and Loopback2 interfaces. This router has two TLOCs: {10.255.1.1, private2, ipsec} and {10.255.1.2, private1, ipsec}.
The WAN interfaces on the Cisco vEdge devices must run a routing protocol with their peer PE routers. The routing protocol must advertise the Cisco vEdge device's loopback addresses to both PE routers so that all Cisco vEdge devices on the two private networks can learn routes to each other. A simple way to advertise the loopback addresses is to redistribute
routes learned from other (connected) interfaces on the same router. (You do this instead of creating access lists). If, for
example, you are using OSPF, you can advertise the loopback addresses by including the redistribute connected command in the OSPF configuration. Looking at the figure above, the ge0/2 interface on vEdge-1 needs to advertise both the Loopback1 and Loopback2 interfaces to the blue private WAN, and ge0/1 must advertise also advertise both these loopback interfaces to the green private WAN.
With this configuration:
The Cisco vEdge devices learn the routes to the Cisco vBond Orchestrator and Cisco vSmart Controller over each private WAN transport.
The Cisco vEdge devices learn every other Cisco vEdge device's loopback address over each WAN transport network.
The end points of the tunnel connections between each pair of Cisco vEdge devices are the loopback interfaces, not the physical (ge) interfaces.
The overlay network has data plane connectivity between any TLOCs and has a control plane over both transport networks.
Here is the interface configuration for VPN 0 on vEdge-1. Highlighted are the commands that bind the loopback interfaces to
their physical interfaces. Notice that the tunnel interfaces, and the basic tunnel interface properties (encapsulation and
color), are configured on the loopback interfaces, not on the Gigabit Ethernet interfaces.
vpn 0
interface loopback1
ip address 10.255.1.2/32
tunnel-interface
encapsulation ipsec
color private1
bind ge0/1
!
no shutdown
!
interface loopback2
ip address 10.255.1.1/32
tunnel-interface
encapsulation ipsec
color private2
bind ge0/2
!
no shutdown
!
interface ge0/1
ip address 172.16.13.3/24
no shutdown
!
interface ge0/2
ip address 10.10.23.3/24
no shutdown
!
ip route 0.0.0.0/0 0.0.0.0
The configuration for vEdge-2 is similar:
vpn 0
interface loopback1
ip address 172.16.2.1/32
tunnel-interface
encapsulation ipsec
color private1
bind ge0/1
!
no shutdown
!
interface loopback2
ip address 172.16.2.2/32
tunnel-interface
encapsulation ipsec
color private2
bind ge0/2
!
no shutdown
!
interface ge0/1
ip address 172.16.15.5/24
no shutdown
!
interface ge0/2
ip address 10.10.25.3/24
no shutdown
!
ip route 0.0.0.0/0 0.0.0.0
!
The vEdge-3 router connects only to the green private WAN:
vpn 0
interface loopback1
ip address 192.168.3.3/32
tunnel-interface
encapsulation ipsec
color private1
bind ge0/1
!
no shutdown
!
interface ge0/1
ip address 172.16.8.4/24
no shutdown
!
ip route 0.0.0.0/0 0.0.0.0
!
On the Cisco vSmart Controller and Cisco vBond Orchestrator, you configure a tunnel interface and default IP route to reach the WAN transport. For the tunnel, color has no meaning because
these devices have no TLOCs.
vpn 0
interface eth1
ip address 172.16.8.9/24
tunnel-interface
!
no shutdown
!
ip route 0.0.0.0/0 0.0.0.0
!
vpn 0
interface ge0/1
ip address 172.16.16.6/24
tunnel-interface
!
no shutdown
!
ip route 0.0.0.0/0 0.0.0.0
!
Connect to a WAN Using PPPoE
This example shows a Cisco vEdge device with a TLOC tunnel interface and an interface enabled for Point-to-Point Protocol over Ethernet (PPPoE). The PPP interface
defines the authentication method and credentials and is linked to the PPPoE-enabled interface.
Here is the interface configuration for VPN 0:
vpn 0
interface ge0/1
no shutdown
!
tunnel-interface
encapsulation ipsec
color biz-internet
allow-service dhcp
allow-service dns
allow-service icmp
no allow-service sshd
no allow-service ntp
no allow-service stun
!
no shutdown
!
interface ge0/3
pppoe-client ppp-interface ppp10
no shutdown
!
interface ppp10
ppp authentication chap
hostname branch100@corp.bank.myisp.net
password $4$OHHjdmsC6M8zj4BgLEFXKw==
!
tunnel-interface
encapsulation ipsec
color gold
allow-service dhcp
allow-service dns
allow-service icmp
no allow-service sshd
no allow-service ntp
no allow-service stun
!
no shutdown
!
Use the show ppp interface command to view existing PPP interfaces:
vEdge# show ppp interface
PPPOE INTERFACE PRIMARY SECONDARY
VPN IFNAME INTERFACE IP GATEWAY IP DNS DNS MTU
---------------------------------------------------------------------------------
0 ppp10 ge0/3 10.0.0.11 10.255.255.254 10.8.8.8 10.8.4.4 1150
Use the show ppppoe session and show pppoe statistics commands to view information about PPPoE sessions:
vEdge# show pppoe session
SESSION PPP SERVICE
VPN IFNAME ID SERVER MAC LOCAL MAC INTERFACE AC NAME NAME
--------------------------------------------------------------------------------------------
0 ge0/1 1 00:0c:29:2e:20:1a 00:0c:29:be:27:f5 ppp1 branch100 -
0 ge0/3 1 00:0c:29:2e:20:24 00:0c:29:be:27:13 ppp2 branch100 -
vEdge# show pppoe statistics
pppoe_tx_pkts : 73
pppoe_rx_pkts : 39
pppoe_tx_session_drops : 0
pppoe_rx_session_drops : 0
pppoe_inv_discovery_pkts : 0
pppoe_ccp_pkts : 12
pppoe_ipcp_pkts : 16
pppoe_lcp_pkts : 35
pppoe_padi_pkts : 4
pppoe_pado_pkts : 2
pppoe_padr_pkts : 2
pppoe_pads_pkts : 2
pppoe_padt_pkts : 2
Configure VPN Ethernet Interface
Procedure
Step 1
From the Cisco vManage menu, choose Configuration > Templates.
Step 2
Click Device Templates, and click Create Template.
Note
In Cisco vManage Release 20.7.x and earlier releases, Device Templates is titled Device.
Step 3
From the Create Template drop-down list, choose From Feature Template.
Step 4
From the Device Model drop-down list, choose the type of device for which you are creating the template.
Step 5
To create a template for VPN 0 or VPN 512:
Click Transport & Management VPN or scroll to the Transport & Management VPN section.
Under Additional VPN 0 Templates, click VPN Interface .
From the VPN Interface drop-down list, click Create Template. The VPN Interface Ethernet template form displays.
This form contains fields for naming the template, and fields for defining the VPN Interface Ethernet parameters.
Step 6
To create a template for VPNs 1 through 511, and 513 through 65530:
Click Service VPN, or scroll to the Service VPN section.
Click the Service VPN drop-down list.
Under Additional VPN templates, click VPN Interface.
From the VPN Interface drop-down list, click Create Template. The VPN Interface Ethernet template form displays.
This form contains fields for naming the template, and fields for defining the VPN Interface Ethernet parameters.
Step 7
In Template Name, enter a name for the template. The name can be up to 128 characters and can contain only alphanumeric characters.
Step 8
In Template Description, enter a description of the template. The description can be up to 2048 characters and can contain only alphanumeric characters.
Configure Basic Interface Functionality
To configure basic interface functionality in a VPN, choose Basic Configuration and configure the following parameters:
Note
Parameters marked with an asterisk are required to configure an interface.
Parameter Name
IPv4 or IPv6
Options
Description
Shutdown*
Click No to enable the interface.
Interface name*
Enter a name for the interface.
Description
Enter a description for the interface.
IPv4 / IPv6
Click IPv4 to configure an IPv4 VPN interface. Click IPv6 to configure an IPv6 interface.
Dynamic
Click Dynamic to set the interface as a Dynamic Host Configuration Protocol (DHCP) client, so that the interface receives its IP address
from a DHCP server.
Both
DHCP Distance
Optionally, enter an administrative distance value for routes learned from a DHCP server. Default is 1.
IPv6
DHCP Rapid Commit
Optionally, configure the DHCP IPv6 local server to support DHCP Rapid Commit, to enable faster client configuration and confirmation
in busy environments.
Click On to enable DHCP rapid commit.
Click Off to continue using the regular commit process.
Static
Click Static to enter an IP address that doesn't change.
IPv4
IPv4 Address
Enter a static IPv4 address.
IPv6
IPv6 Address
Enter a static IPv6 address.
Secondary IP Address
IPv4
Click Add to enter up to four secondary IPv4 addresses for a service-side interface.
IPv6 Address
IPv6
Click Add to enter up to two secondary IPv6 addresses for a service-side interface.
DHCP Helper
Both
To designate the interface as a DHCP helper on a router, enter up to eight IP addresses, separated by commas, for DHCP servers
in the network. A DHCP helper interface forwards BootP (broadcast) DHCP requests that it receives from the specified DHCP
servers.
Block Non-Source IP
Yes / No
Click Yes to have the interface forward traffic only if the source IP address of the traffic matches the interface's IP prefix range.
Click No to allow other traffic.
Bandwidth Upstream
For Cisco vEdge devices and vManage:
For transmitted traffic, set the bandwidth above which to generate notifications.
Range: 1 through (232 / 2) – 1 kbps
Bandwidth Downstream
For Cisco vEdge devices and vManage:
For received traffic, set the bandwidth above which to generate notifications.
On Cisco vEdge device
s, you can configure up to eight tunnel interfaces. This means that each Cisco vEdge device
router can have up to eight TLOCs. On Cisco vSmart Controllers and Cisco vManage, you can configure one tunnel interface.
For the control plane to establish itself so that the overlay network can function, you must configure WAN transport interfaces
in VPN 0. The WAN interface will enable the flow of tunnel traffic to the overlay. You can add other parameters shown in the
table below only after you configure the WAN interface as a tunnel interface.
To configure a tunnel interface, select Interface Tunnel and configure the following parameters:
To configure additional tunnel interface parameters, click Advanced Options:
Parameter Name
Cisco vEdge devices Only
Description
GRE
Yes
Use GRE encapsulation on the tunnel interface. By default, GRE is disabled.
If you select both IPsec and GRE encapsulations, two TLOCs are created for the tunnel interface that have the same IP addresses
and colors, but that differ by their encapsulation.
IPsec
Yes
Use IPsec encapsulation on the tunnel interface. By default, IPsec is enabled.
If you select both IPsec and GRE encapsulations, two TLOCs are created for the tunnel interface that have the same IP addresses
and colors, but that differ by their encapsulation.
IPsec Preference
Yes
Specify a preference value for directing traffic to the tunnel. A higher value is preferred over a lower value.
Range: 0 through 4294967295
Default: 0
IPsec Weight
Yes
Enter a weight to use to balance traffic across multiple TLOCs. A higher value sends more traffic to the tunnel.
Range: 1 through 255
Default: 1
Carrier
No
Select the carrier name or private network identifier to associate with the tunnel.
Enter the name of a physical interface to bind to a loopback interface.
Last-Resort Circuit
Yes
Select to use the tunnel interface as the circuit of last resort.
NAT Refresh Interval
No
Enter the interval between NAT refresh packets sent on a DTLS or TLS WAN transport connection.
Range: 1 through 60 seconds
Default: 5 seconds
Hello Interval
No
Enter the interval between Hello packets sent on a DTLS or TLS WAN transport connection.
Range: 100 through 10000 milliseconds
Default: 1000 milliseconds (1 second)
Hello Tolerance
No
Enter the time to wait for a Hello packet on a DTLS or TLS WAN transport connection before declaring that transport tunnel
to be down.
Range: 12 through 60 seconds
Default: 12 seconds
Configure Tunnel Interface CLI on vEdge Devices
vpn 0interfaceinterface-nametunnel-interfaceallow-serviceservice-namebindinterface-name (on vEdge routers only)
carriercarrier-name
colorcolorencapsulation (gre | ipsec) (on vEdge routers only)
preferencenumberweightnumberexclude-controller-group-listnumber (on vEdge routers only)
hello-intervalmillisecondshello-tolerancesecondslast-resort-circuit (on vEdge routers only)
low-bandwidth-linkmax-control-connectionsnumber (on vEdge routers only)
nat-refresh-intervalsecondsvbond-as-stun-servervmanage-connection-preferencenumber (on vEdge routers only)
Associate a Carrier Name with a Tunnel Interface
To associate a carrier name or private network identifier with a tunnel interface, use the carrier command. carrier-name can be default and carrier1 through carrier8:
By default, WAN Edge routers try to build tunnels with all other TLOCs in the network, regardless of color. When the restrict
option is used with the color designation under the tunnel configuration, the TLOC is restricted to only building tunnels
to TLOCs of the same color. For more information on the restrict option see, Configure Interfaces in the WAN Transport VPN(VPN0).
The tunnel group feature is similar to the restrict option but gives more flexibility because once a tunnel group ID is assigned
under a tunnel, only TLOCs with the same tunnel group IDs can form tunnels with each other irrespective of color.
If a TLOC is associated with a tunnel group ID, it continues to form tunnels with other TLOCs in the network that are not
associated with any tunnel group IDs.
Note
The restrict option can still be used in conjunction with this feature. If used, then an interface with a tunnel group ID
and restrict option defined on an interface will only form a tunnel with other interfaces with the same tunnel group ID and
color.
Configure Tunnel Groups on Cisco vEdge devices Using CLI
To configure tunnel groups on Cisco vEdge devices:
By default, Cisco vEdge devices send a Hello packet once per second to determine whether the tunnel interface between two devices is still operational and
to keep the tunnel alive. The combination of a hello interval and a hello tolerance determines how long to wait before declaring
a DTLS or TLS tunnel to be down. The default hello interval is 1 second, and the default tolerance is 12 seconds. With these
default values, if no Hello packet is received within 11 seconds, the tunnel is declared down at 12 seconds.
If the hello interval or the hello tolerance, or both, are different at the two ends of a DTLS or TLS tunnel, the tunnel chooses
the interval and tolerance as follows:
For a tunnel connection between two controller devices, the tunnel uses the lower hello interval and the higher tolerance
interval for the connection between the two devices. (Controller devices are vBond controllers, vManage NMSs, and vSmart controllers.)
This choice is made in case one of the controllers has a slower WAN connection. The hello interval and tolerance times are
chosen separately for each pair of controller devices.
For a tunnel connection between a Cisco vEdge device and any controller device, the tunnel uses the hello interval and tolerance times configured on the router. This choice is
made to minimize the amount traffic sent over the tunnel, to allow for situations where the cost of a link is a function of
the amount of traffic traversing the link. The hello interval and tolerance times are chosen separately for each tunnel between
a Cisco vEdge device and a controller device.
To minimize the amount of keepalive traffic on a tunnel interface, increase the Hello packet interval and tolerance on the
tunnel interface:
The default hello interval is 1000 milliseconds, and it can be a time in the range 100 through 600000 milliseconds (10 minutes).
The default hello tolerance is 12 seconds, and it can be a time in the range 12 through 600 seconds (10 minutes). The hello
tolerance interval must be at most one-half the OMP hold time. The default OMP hold time is 60 seconds, and you configure
it with the omp timers holdtime command.
Configure Multiple Tunnel Interfaces on a vEdge Router
On a Cisco vEdge device, you can configure up to eight tunnel interfaces in the transport interface (VPN 0). This means that each Cisco vEdge device can have up to eight TLOCs.
When a Cisco vEdge device has multiple TLOCs, each TLOC is preferred equally and traffic to each TLOC is weighted equally, resulting in ECMP routing.
ECMP routing is performed regardless of the encapsulation used on the transport tunnel, so if, for example, a router has one
IPsec and one GRE tunnel, with ECMP traffic is forwarded equally between the two tunnels. You can change the traffic distribution
by modifying the preference or the weight, or both, associated with a TLOC. (Note that you can also affect or change the traffic
distribution by applying a policy on the interface that affects traffic flow.)
The preference command controls the preference for directing inbound and outbound traffic to a tunnel. The preference can be a value from
0 through 4294967295 (232 – 1), and the default value is 0. A higher value is preferred over a lower value.
When a Cisco vEdge device has two or more tunnels, if all the TLOCs have the same preference and no policy is applied that affects traffic flow, all
the TLOCs are advertised into OMP. When the router transmits or receives traffic, it distributes traffic flows evenly among
the tunnels, using ECMP.
When a Cisco vEdge device has two or more tunnels, if the TLOCs have different
preferences and a policy is that affects traffic flow is not applied, all the TLOCs
are advertised to Cisco vSmart Controller via OMP for
further processing based on the control policy applied on Cisco vSmart Controller for the
corresponding vEdge site-id. When the router transmits or receives traffic, it sends
traffic to or receives traffic from only the TLOC with the highest preference. When
there are three or more tunnels and two of them have the same preference, traffic
flows are distributed evenly between these two tunnels.
A remote Cisco vEdge device trying to reach one of these prefixes selects which TLOC to use from the set of TLOCs that have been advertised. So, for
example, if a remote router selects a GRE TLOC on the local router, the remote router must have its own GRE TLOC to be able
to reach the prefix. If the remote router has no GRE TLOC, it is unable to reach the prefix. If the remote router has a single
GRE TLOC, it selects that tunnel even if there is an IPsec TLOC with a higher preference. If the remote router has multiple
GRE TLOCs, it selects from among them, choosing the one with the highest preference or using ECMP among GRE TLOCs with equal
preference, regardless of whether there is an IPsec TLOC with a higher preference.
The weight command controls how traffic is balanced across multiple TLOCs that have equal preferences values. The weight can be a value
from 1 through 255, and the default is 1. When the weight value is higher, the router sends more traffic to the TLOC. You
typically set the weight based on the bandwidth of the TLOC. When a router has two or more TLOCs, all with the highest equal
preference value, traffic distribution is weighted according to the configured weight value. For example, if TLOC A has weight
10, and TLOC B has weight 1, and both TLOCs have the same preference value, then roughly 10 flows are sent out TLOC A for
every 1 flow sent out TLOC B.
To create Network Address Translation (NAT) pools of IP addresses in VPNs, use the VPN Interface NAT Pool template for Cisco vEdge devices. To configure NAT pool interfaces in a VPN usingCisco vManage templates:
Create a VPN Interface NAT Pooltemplate for Cisco vEdge devices to configure Ethernet interface parameters, as described in this article.
Create a VPN feature template to configure parameters for a service-side VPN.
Optionally, create a data policy to direct data traffic to a service-side NAT.
Create a VPN Interface NAT Pool Template
You can open a new VPN Interface NATPool template for Cisco vEdge devices from the VPN section of a device template.
From the Cisco vManage menu, choose Configuration > Templates.
Click Feature Templates.
Note
In Cisco vManage Release 20.7.x and earlier releases, Feature Templates is titled Feature.
Click Add Template.
Select a device from the list.
From the VPN section, click VPN Interface NATPool.
The VPN Interface Ethernet template form displays. This form contains fields for naming the template, fields for defining
the VPN Interface NAT Pool parameters.
In the required Template Name field, enter a name for the template.
The name can be up to 128 characters and can contain only alphanumeric characters.
In the optional Template Description field, enter a description of the template.
The description can be up to 2048 characters and can contain only alphanumeric characters.
Parameter Menus and Options
Parameter Menus and Options
When you first open a feature template, for each parameter that has a default value, the scope is set to Default (indicated
by a ), 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 appropriate option.
Configure a NAT Pool Interface
To configure a NAT pool interface, configure the following parameters. Parameters marked with an asterisk are required to
configure the interface.
Basic Configuration
Enter the following basic configuration parameters:
Table 8.
Parameter Name
Description
Shutdown*
Yes
Click No to enable the interface.
No
Interface Name (1…31)*
Enter a number for the NAT pool interface to use for service-side NAT. For example, natpool22.
Range: 1-31
Description
Enter a description for the interface.
IPv4 Address*
Enter the IPv4 address of the interface. The address length determines the number of NAT addresses that the router use at
the same time. A Cisco vEdge device router can support a maximum of 250 NAT IP addresses.
Refresh Mode
Select how NAT mappings are refreshed:
bi-directional
Keep active the NAT mappings for inbound and outbound traffic.
outbound
Keep active the NAT mappings for outbound traffic. This is the default.
UDP Timeout
Enter the time when NAT translations over UDP sessions time out.Default: 1 minute
Range: 1-65536 minutes
TCP Timeout
Enter the time when NAT translations over TCP sessions time out.Default: 60 minutes (1 hour)
Range:1-65536 minutes
Block ICMP
Select whether a Cisco vEdge device that is acting as a NAT device should receive inbound ICMP error messages. By default, the router blocks these error messages.
Click Off to receive the ICMP error messages.
Direction
Select the direction in which the NAT interface performs address translation:
inside
Translate the source IP address of packets that are coming from the service side of the Cisco vEdge device and that are destined to transport side of the router. This is the default.
outside
Translate the source IP address of packets that are coming to the Cisco vEdge device from the transport side of the Cisco vEdge device and that are destined to a service-side device.
Overload
Click No to disable dynamic NAT. By default, dynamic NAT is enabled.
Configure a Tracker Interface
To create one or more tracker interfaces, click Tracker, and click New Tracker.
Select one or more interfaces to track the status of service interfaces.
To save the tracker interfaces, click Add.
To save the feature template, click Save.
NAT Pool Interface CLI Equivalent Commands on Cisco vEdge Devices
Use the following commands to configure NAT Pool interfaces on Cisco vEdge devices.
To create port-forwarding rules to allow requests from an external network to reach devices on the internal network:
Click Port Forward .
Click New Port Forwarding Rule, and configure the parameters. You can create up to 128 rules.
To save the rule, click Add.
To save the feature template, click Save.
Table 9.
Parameter Name
Values
Description
Port Start Range
Enter the starting port number. This number must be less than or equal to the ending port number.
Port End Range
Enter the ending port number. To apply port forwarding to a single port, specify the same port number for the starting and
ending numbers. When applying port forwarding to a range of ports, the range includes the two port numbers that you specify.
Protocol
TCP
UDP
Select the protocol to apply the port-forwarding rule to. To match the same ports for both TCP and UDP traffic, configure
two rules.
VPN
0-65535
Private VPN in which the internal server resides.
Private IP
Enter an IP address to use within the firewall. A best practice is to specify the IP address of a service-side VPN.
Port Forwarding CLI Equivalent for vEdge
vpn vpn-id
interface natpoolnumber
nat
port-forward port-start port-number1 port-end port-number2 proto (tcp | udp)
private-ip-address ip address private-vpn vpn-id
Static NAT CLI Equivalent Commands on Cisco vEdge Device
vpn vpn-id
interface natpoolnumber
nat
port-forward port-start port-number1 port-end port-number2 proto (tcp | udp)
private-ip-address ip address private-vpn vpn-id
Release Information
Introduced in Cisco vManage NMS Release 16.3. In Release 17.2.2, add support for tracker interface status. In Release
18.4, updated images; add support for multiple tracker interfaces.
Apply Access Lists and QoS Parameters
Quality of service (QoS) helps determine how a service will perform. By configuring QoS, enhance the performance of an application
on the WAN. To configure a shaping rate for an interface and to apply a QoS map, a rewrite rule, access lists, and policers
to a interface, click ACL/QoS, and configure the following parameters:
Parameter Name
Description
Shaping rate
Configure the aggregate traffic transmission rate on the interface to be less than line rate, in kilobits per second (kbps).
QoS Map
Specify the name of the QoS map to apply to packets being transmitted out the interface.
Rewrite Rule
Click On, and specify the name of the rewrite rule to apply on the interface.
Ingress ACL – IPv4
Click On, and specify the name of the access list to apply to IPv4 packets being received on the interface.
Egress ACL – IPv4
Click On, and specify the name of the access list to apply to IPv4 packets being transmitted on the interface.
Ingress ACL – IPv6
Click On, and specify the name of the access list to apply to IPv6 packets being received on the interface.
Egress ACL – IPv6
Click On, and specify the name of the access list to apply to IPv6 packets being transmitted on the interface.
Ingress Policer
Click On, and specify the name of the policer to apply to packets received on the interface.
Egress Policer
Click On, and specify the name of the policer to apply to packets being transmitted on the interface.
To save the feature template, click Save.
CLI Equivalent
vpnvpn-idinterfaceinterface-nameaccess-listacl-list (in | out)
policerpolicer-name (in |out)
qos-mapnamerewrite-rulenameshaping-ratename
Add ARP Table Entries
The Address Resolution Protocol (ARP) helps associate a link layer address (such as the MAC address of a device) to its assigned
internet layer address. Configure a static ARP address when dynamic mapping is not functional. To configure static ARP table
entries on the interface, select ARP. Then click Add New ARP and configure the following parameters:
Parameter Name
Description
IP Address
Enter the IP address for the ARP entry in dotted decimal notation or as a fully qualified host name.
MAC Address
Enter the MAC address in colon-separated hexadecimal notation.
To have an interface run the Virtual Router Redundancy Protocol (VRRP), which allows multiple routers to share a common virtual
IP address for default gateway redundancy, select the VRRP tab. Then click Add New VRRP and configure the following parameters:
Parameter Name
Description
Group ID
Enter the virtual router ID, which is a numeric identifier of the virtual router. You can configure a maximum of 24 groups.
Range: 1 through 255
Priority
Enter the priority level of the router. There router with the highest priority is elected as primary VRRP router. If two routers
have the same priority, the one with the higher IP address is elected as primary VRRP router.
Range: 1 through 254
Default: 100
Timer (milliseconds)
Specify how often the primary VRRP router sends VRRP advertisement messages. If subordinate routers miss three consecutive
VRRP advertisements, they elect a new primary VRRP routers.
Range: 100 through 40950 milliseconds
Default: 100 msecs
Note
When the timer is 100 ms for the VRRP feature template on Cisco IOS XE SD-WAN devices, the VRRP fails if the traffic is high on LAN interface.
Track OMP
Track Prefix List
By default, VRRP uses of the state of the service (LAN) interface on which it is running to determine which router is the
primary virtual router. 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,
configure one of the following:
Track OMP—Click On for VRRP to track the Overlay Management Protocol (OMP) session running on the WAN connection. If the primary VRRP router
loses all its OMP sessions, VRRP elects a new default gateway from those that have at least one active OMP session.
Track Prefix List—Track both the OMP session and a list of remote prefixes, which is defined in a prefix list configured on the local router.
If the primary VRRP router loses all its OMP sessions, VRRP failover occurs as described for the Track OMP option. In addition,
if reachability to all of 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 routers determine the primary VRRP
router.
IP Address
Enter the IP address of the virtual router. This address must be different from the configured interface IP addresses of both
the local router and the peer running VRRP.
You can configure prefix list tracking for VRRP using device and feature templates. To configure a prefix list, do the following:
From the Cisco vManage menu, choose Configuration > Policy.
Click Localized Policy.
From the Custom Options drop-down list, click Lists.
Click Prefix from the left pane, and click New Prefix List.
In Prefix List Name, enter a name for the prefix list.
Choose IPv4 as the Internet Protocol.
In Add Prefix, enter the prefix entries separated by commas.
Click Add.
Click Next and configure Forwarding Classes/QoS.
Click Next and configure Access Control Lists.
Click Next and in Route Policy pane, select a relevant route policy and click … , and click Edit to add the newly added prefix list.
From the Match pane, click AS Path List and in the Address, choose the newly added prefix list.
Click Save Match and Actions.
Click Next and enter the Policy Name and Policy Description in the Policy Overview screen.
Click Save Policy.
Configure a Prefix List for VRRP in the Device Template
To configure the Prefix List to the VRRP and the localized policy in the device template, do the following:
From the Cisco vManage menu, choose Configuration > Templates.
Click Device Templates.
Note
In Cisco vManage Release 20.7.x and earlier releases, Device Templates is titled Device.
Select a relevant device template and click … and click Edit to edit the template details.
From Policy, select the policy with the newly added prefix list.
Click Update.
Click Feature Templates.
Select a relevant device template and click … and click Edit to edit the template details.
Click VRRP.
Select a relevant group ID and click the pen icon to associate the new prefix-list to the VRRP details.
Click the Track Prefix List drop-down list and enter the newly added prefix-list name.
Click Save Changes.
Click Update to save the changes.
Click Device Templates and select the policy with the newly added prefix list.
Click … and click Attach Devices.
From Available Devices, double-click the relevant device to move it to Selected Devices, and then click Attach.
Configure Advanced Properties
To configure other interface properties, select the Advanced tab and configure the following parameters:
Parameter Name
Description
Duplex
Choose full or half to specify whether the interface runs in full-duplex or half-duplex mode.
Default: full
MAC Address
Specify a MAC address to associate with the interface, in colon-separated hexadecimal notation.
IP MTU
Specify the maximum MTU size of packets on the interface.
Range: 576 through 1804
Default: 1500 bytes
PMTU Discovery
Click On to enable path MTU discovery on the interface. PMTU determines the largest MTU size that the interface supports so that packet
fragmentation does not occur.
Flow Control
Select a setting for bidirectional flow control, which is a mechanism for temporarily stopping the transmission of data on
the interface.
Values: autonet, both, egress, ingress, none
Default: autoneg
TCP MSS
Specify the maximum segment size (MSS) of TPC SYN packets passing through the router. By default, the MSS is dynamically adjusted
based on the interface or tunnel MTU such that TCP SYN packets are never fragmented.
Range: 552 to 1460 bytes
Default: None
Speed
Specify the speed of the interface for use when the remote end of the connection does not support autonegotiation.
Values: 10, 100, 1000, or 10000 Mbps
Clear-Dont-Fragment
Click On to clear the Don't Fragment (DF) bit in the IPv4 packet header for packets being transmitted out the interface. When the
DF bit is cleared, packets larger than that interface's MTU are fragmented before being sent.
Note
Clear-Dont-Fragment clears the DF bit when there is fragmentation needed and the DF bit is set. For packets not requiring
fragmentation, the DF bit is not affected.
Static Ingress QoS
Specify a queue number to use for incoming traffic.
Range: 0 through 7
ARP Timeout
Specify how long it takes for a dynamically learned ARP entry to time out.
Range: 0 through 2678400 seconds (744 hours)
Default: 1200 (20 minutes)
Autonegotiation
Click Off to turn autonegotiation off. By default, an interface runs in autonegotiation mode.
TLOC Extension
Enter the name of a physical interface on the same router that connects to the WAN transport. This configuration then binds
this service-side interface to the WAN transport. A second router at the same site that itself has no direct connection to
the WAN (generally because the site has only a single WAN connection) and that connects to this service-side interface is
then provided with a connection to the WAN.
Note that TLOC extension over L3 is only supported for Cisco IOS XE routers. If configuring TLOC extension over L3 for a Cisco
IOS XE router, enter the IP address of the L3 interface.
Power over Ethernet
Click On to enable PoE on the interface.
ICMP Redirect
Click Disable to disable ICMP redirect messages on the interface. By default, an interface allows ICMP redirect messages.
To save the feature template, click Save.
CLI Equivalent
vpnvpn-idinterfaceinterface-namearp-timeoutseconds (on vEdge routers only)
[no] autonegotiateclear-dont-fragmentduplex (full | half)
flow-controlcontrolicmp-redirect-disable (on vEdge routers only)
mac-addressmac-addressmtubytespmtupppoe-client (on vEdge 100m and vEdge 100wm routers only)
ppp-interfacepppnumberspeedspeedstatic-ingress-qosnumber (on vEdge routers only)
tcp-mss-adjustbytestloc-extensioninterface-name (on vEdge routers only)
trackertracker-name (on vEdge routers only)
VPN Interface Bridge
Use the VPN Interface Bridge template for all Cisco vEdge device Cloud and Cisco vEdge devices.
Integrated routing and bridging (IRB) allows Cisco vEdge 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 vEdge device.
To configure a bridge interface using Cisco vManage templates:
Create a VPN Interface Bridge feature template to configure parameters for logical IRB interfaces, as described in this article.
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
From the Cisco vManage menu, choose Configuration > Templates.
Click Device Templates.
Note
In Cisco vManage Release 20.7.x and earlier releases, Device Templates is titled Device.
From the Create Template drop-down list, select From Feature Template.
From the Device Model drop-down list, select the type of device for which you are creating the template.
Click Service VPN or scroll to the Service VPN section.
Click the Service VPN drop-down list.
From Additional VPN Templates, click VPN Interface Bridge.
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.
In Template Name, enter a name for the template. The name can be up to 128 characters and can contain only alphanumeric characters.
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:
Table 10.
Parameter Scope
Scope Description
Device Specific (indicated by a host icon)
Use a device-specific value for the parameter. For device-specific parameters, you cannot enter a value in the feature template.
You enter the value when you attach a Viptela device to a device template .
When you click Device Specific, the Enter Key box opens. This box displays a key, which is a unique string that identifies
the parameter in a CSV file that you create. This file is an Excel spreadsheet that contains one column for each key. The
header row contains the key names (one key per column), and each row after that corresponds to a device and defines the values
of the keys for that device. You upload the CSV file when you attach a Viptela device to a device template. For more information,
see Create a Template Variables Spreadsheet .
To change the default key, type a new string and move the cursor out of the Enter Key box.
Examples of device-specific parameters are system IP address, hostname, GPS location, and site ID.
Global (indicated by a globe icon)
Enter a value for the parameter, and apply that value to all devices.
Examples of parameters that you might apply globally to a group of devices are DNS server, syslog server, and interface MTUs.
Release Information
Introduced in Cisco vManage NMS in Release 15.3. In Release 18.2, add support for disabling ICMP redirect messages.
Create a Bridging Interface
To configure an interface to use for bridging servers, select Basic Configuration and configure the following parameters. Parameters marked with an asterisk are required to configure bridging.
Table 11.
Parameter Name
Description
Shutdown*
Click No to enable the interface.
Interface name*
Enter the name of the interface, in the format irbnumber. The IRB interface number can be from 1 through 63, and must be the same as the VPN identifier configured in the Bridge feature
template for the bridging domain that the IRB is connected to.
Description
Enter a description for the interface.
IPv4 Address*
Enter the IPv4 address of the router.
DHCP Helper
Enter up to eight IP addresses for DHCP servers in the network, separated by commas, to have the interface be a DHCP helper.
A DHCP helper interface forwards BOOTP (Broadcast) DHCP requests that it receives from the specified DHCP servers.
Block Non-Source IP
Click Yes to have the interface forward traffic only if the source IP address of the traffic matches the interface's IP prefix range.
Secondary IP Address (on Cisco vEdge devices)
Click Add to configure up to four secondary IPv4 addresses for a service-side interface.
To apply access lists to IRB interfaces, select the ACL tab and configure the following parameters. The ACL filter determines
what is allowed in or out of a bridging domain:
Table 12.
Parameter Name
Description
Ingress ACL – IPv4
Click On, and specify the name of an IPv4 access list to packets being received on the interface.
Egress ACL– IPv4
Click On, and specify the name of an IPv4 access list to packets being transmitted on the interface.
To save the feature template, click Save.
CLI equivalent:
vpn vpn-id interface irbnumber access-list acl-name (in | out)
Configure VRRP
To have an interface run the Virtual Router Redundancy Protocol (VRRP), which allows multiple routers to share a common virtual
IP address for default gateway redundancy, choose VRRP. Then click Add New VRRP and configure the following parameters:
Table 13.
Parameter Name
Description
Group ID
Enter the virtual router ID, which is a numeric identifier of the virtual router. You can configure a maximum of 24 groups.
Range: 1 through 255
Priority
Enter the priority level of the router. There router with the highest priority is elected as primary VRRP router. If twoCisco vEdge devices have the same priority, the one with the higher IP address is elected as primary VRRP router. Range: 1 through 254Default: 100
Timer (milliseconds)
Specify how often the primary VRRP router sends VRRP advertisement messages. If subordinate routers miss three consecutive
VRRP advertisements, they elect a new primary VRRP router.
Range: 100 through 40950 milliseconds
Default: 100 msecs
Note
When the timer is 100 ms for the VRRP feature template on s, the VRRP fails if the traffic is high on LAN interface.
Track OMP Track Prefix List
By default, VRRP uses of the state of the service (LAN) interface on which it is running to determine which Cisco vEdge device is the primary virtual router. if a Cisco vEdge device 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, configure one of the following:
Track OMP—Click On for VRRP to track the Overlay Management Protocol (OMP) session running on the WAN connection. If the primary VRRP router
loses all its OMP sessions, VRRP elects a new default gateway from those that have at least one active OMP session.
Track Prefix List—Track both the OMP session and a list of remote prefixes, which is defined in a prefix list configured on
the local router. If the primary VRRP router loses all its OMP sessions, VRRP failover occurs as described for the Track OMP
option. In addition, if reachability to all of 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 Cisco vEdge devices determine the primary VRRP router.
IP Address
Enter the IP address of the virtual router. This address must be different from the configured interface IP addresses of both
the local Cisco vEdge device and the peer running VRRP.
To configure static Address Resolution Protocol (ARP) table entries on the interface, choose ARP. Then click Add New ARP and configure the following parameters:
Table 14.
Parameter Name
Description
IP Address
Enter the IP address for the ARP entry in dotted decimal notation or as a fully qualified host name.
MAC Address
Enter the MAC address in colon-separated hexadecimal notation.
To save the ARP configuration, click Add.
To save the feature template, click Save.
CLI equivalent:
vpn vpn-id interface irbnumber arp
ip address ip-address mac mac-address
Configure Advanced Properties
To configure other interface properties, click Advanced and configure the following parameters:
Table 15.
Parameter Name
Description
MAC Address
MAC addresses can be static or dynamic. A static MAC address is manually configured as opposed to a dynamic MAC address that
is one learned via an ARP request. You can configure a static MAC on a router's interface or indicate a static MAC that identifies
a router's interface.
Specify a MAC address to associate with the interface, in colon-separated hexadecimal notation.
IP MTU
Similar to MTU, IP MTU only affects IP packets. If an IP packet exceeds the IP MTU, then the packet will be fragmented.
Specify the maximum MTU size of packets on the interface.Range: 576 through 1804Default: 1500 bytes
TCP MSS
TCP MSS will affect any packet that contains an initial TCP header that flows through the router. When configured, TCP MSS
will be examined against the MSS exchanged in the three-way handshake. The MSS in the header will be lowered if the configured
setting is lower than what is in the header. If the header value is already lower, it will flow through unmodified. The end
hosts will use the lower setting of the two hosts. If the TCP MSS is to be configured, it should be set it at 40 bytes lower
than the minimum path MTU.
Specify the maximum segment size (MSS) of TPC SYN packets passing through the Cisco vEdge device. By default, the MSS is dynamically adjusted based on the interface or tunnel MTU such that TCP SYN packets are never fragmented.Range: 552 to 1460 bytesDefault: None
Clear-Dont-Fragment
Configure Clear-Dont-Fragment if there are packets arriving on an interface with the DF bit set. If these packets are larger
than the MTU will allow, they are dropped. If you clear the df-bit, the packets will be fragmented and sent.
Click On to clear the Dont Fragment (DF) bit in the IPv4 packet header for packets being transmitted out the interface. When the DF
bit is cleared, packets larger than that interface's MTU are fragmented before being sent.
Note
Clear-Dont-Fragment clears the DF bit when there is fragmentation needed and the DF bit is set. For packets not requiring
fragmentation, the DF bit is not affected.
ARP Timeout
ARP Timeout controls how long we maintain the ARP cache on a router.
Specify how long it takes for a dynamically learned ARP entry to time out.
Use the PPPoE template for Cisco IOS XE 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 vManage templates:
Create a VPN Interface Ethernet PPPoE feature template to configure Ethernet PPPoE interface parameters, as described in this
section.
Create a VPN feature template to configure VPN parameters. See VPN help topic.
Navigate to the Template Screen and Name the Template
From the Cisco vManage menu, choose Configuration > Templates.
Click Device Templates, and click Create Template.
Note
In Cisco vManage Release 20.7.x and earlier releases, Device Templates is titled Device.
From the Create Template drop-down list, choose From Feature Template.
From the Device Model drop-down list, select the type of device for which you are creating the template.
Click Transport & Management VPN or scroll to the Transport & Management VPN section.
Under Additional VPN 0 Templates, click VPN Interface Ethernet PPPoE.
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.
In Template Name, enter a name for the template.
The name can be up to 128 characters and can contain only alphanumeric characters.
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:
Table 16.
Parameter Scope
Scope Description
Device Specific (indicated by a host icon)
Use a device-specific value for the parameter. For device-specific parameters, you cannot enter a value in the feature template.
You enter the value when you attach a Cisco SD-WAN device to a device template .
When you click Device Specific, the Enter Key box opens. This box displays a key, which is a unique string that identifies the parameter in a CSV file that you create.
This file is an Excel spreadsheet that contains one column for each key. The header row contains the key names (one key per
column), and each row after that corresponds to a device and defines the values of the keys for that device. You upload the
CSV file when you attach a Cisco SD-WAN device to a device template. For more information, see Create a Template Variables Spreadsheet .
To change the default key, type a new string and move the cursor out of the Enter Key box.
Examples of device-specific parameters are system IP address, hostname, GPS location, and site ID.
Global (indicated by a globe icon)
Enter a value for the parameter, and apply that value to all devices.
Examples of parameters that you might apply globally to a group of devices are DNS server, syslog server, and interface MTUs.
Configure PPPoE Functionality
To configure basic PPPoE functionality, click Basic Configuration and configure the following parameters. Required parameters are indicated with an asterisk.
Table 17.
Parameter Name
Description
Shutdown*
Click No to enable the GigabitEthernet interface.
Ethernet Interface Name
Enter the name of a GigabitEthernet interface.
For IOS XE routers, you must spell out the interface names completely (for example, GigabitEthernet0/0/0).
VLAN ID
VLAN tag of the sub-interface.
Description
Enter a description of the Ethernet-PPPoE-enabled interface.
Dialer Pool Member
Enter the number of the dialer pool to which the interface belongs.
Range: 100 to 255.
PPP Maximum Payload
Enter the maximum receive unit (MRU) value to be negotiated during PPP Link Control Protocol (LCP) negotiation. Range: 64 through 1792 bytes
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.
Table 18.
Parameter Name
Description
PPP Authentication Protocol
Select the authentication protocol used by the MLP:
CHAP—Enter the hostname and password provided by your Internet Service Provider (ISP). hostname can be up to 255 characters.
PAP—Enter the username and password provided by your ISP. username can be up to 255 characters.
PAP and CHAP—Configure both authentication protocols. Enter the login credentials for each protocol. To use the same username and password
for both, click Same Credentials for PAP and CHAP.
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:
Table 19.
Parameter Name
Description
Tunnel Interface
Click On to create a tunnel interface.
Color
Select a color for the TLOC.
Control Connection
By default, Control Conection is set to On, which establishes a control connection for the TLOC. If the router has multiple TLOCs, click No to have the tunnel not establish control connection for the TLOC.
Note
We recommend a minimum of 650-700 Kbps bandwidth with default 1 sec hello-interval and 12 sec hello-tolerance parameters configured
to avoid any data/packet loss in connection traffic.
For each BFD session, an additional average sized BFD packet of 175 Bytes consumes 1.4 Kbps of bandwidth.
A sample calculation of the required bandwidth for bidirectional BFD packet flow is given below:
650 – 700 Kbps per device for control connections.
175 Bytes (or 1.4 Kbps) per BFD session on the device (request)
175 Bytes (or 1.4 Kbps) per BFD session on the device (response)
If the path MTU discovery (PMTUD) is enabled, bandwidth for send/receive BFD packets per tunnel for every 30 secs:
A 1500 Bytes BFD request packet is sent per tunnel every 30 secs:
Specify the maximum number of Cisco vSmart Controllers that the WAN tunnel interface can connect to. To have the tunnel establish no control connections, set the number to 0.
Range: 0 through 8 Default: 2
Cisco vBond Orchestrator As STUN Server
Click On to enable Session Traversal Utilities for NAT (STUN) to allow the tunnel interface to discover its public IP address and
port number when the router is located behind a NAT.
Exclude Controller Group List
Set the Cisco vSmart Controllers that the tunnel interface is not allowed to connect to. Range: 0 through 100
Cisco vManage Connection Preference
Set the preference for using a tunnel interface to exchange control traffic with the Cisco vManage NMS. Range: 0 through 8 Default: 5
Port Hop
Click On to enable port hopping, or click Off to disable it. When a router is behind a NAT, port hopping rotates through a pool of preselected OMP port numbers (called
base ports) to establish DTLS connections with other routers when a connection attempt is unsuccessful. The default base ports
are 12346, 12366, 12386, 12406, and 12426. To modify the base ports, set a port offset value. Default: Enabled
Low-Bandwidth Link
Select to characterize the tunnel interface as a low-bandwidth link.
Allow Service
Select On or Off for each service to allow or disallow the service on the interface.
To configure additional tunnel interface parameters, click Advanced Options and configure the following parameters:
Table 20.
Parameter Name
Description
GRE
Use GRE encapsulation on the tunnel interface. By default, GRE is disabled.
If you select both IPsec and GRE encapsulations, two TLOCs are created for the tunnel interface that have the same IP addresses
and colors, but that differ by their encapsulation.
IPsec
Use IPsec encapsulation on the tunnel interface. By default, IPsec is enabled.
If you select both IPsec and GRE encapsulations, two TLOCs are created for the tunnel interface that have the same IP addresses
and colors, but that differ by their encapsulation.
IPsec Preference
Specify a preference value for directing traffic to the tunnel. A higher value is preferred over a lower value.
Range: 0 through 4294967295. Default: 0
IPsec Weight
Enter a weight to use to balance traffic across multiple TLOCs. A higher value sends more traffic to the tunnel.
Range: 1 through 255. Default: 1
Carrier
Select the carrier name or private network identifier to associate with the tunnel.
Enter the name of a physical interface to bind to a loopback interface.
Last-Resort Circuit
Select to use the tunnel interface as the circuit of last resort.
Note
An interface configured as a circuit of last resort is expected to be down and is skipped while calculating the number of
control connections, the cellular modem becomes dormant, and no traffic is sent over the circuit.
When the configurations are activated on the edge device with cellular interfaces, then all the interfaces begin the process
of establishing control and BFD connections. When one or more of the primary interfaces establishes a BFD connection, the
circuit of last resort shuts itself down.
Only when all the primary interfaces lose their connections to remote edges, then the circuit of last resort activates itself
triggering a BFD TLOC Down alarm and a Control TLOC Down alarm on the edge device. The last resort interfaces are used as
backup circuit on edge device and are activated when all other transport links BFD sessions fail. In this mode the radio interface
is turned off, and no control or data connections exist over the cellular interface.
Note
Configuring administrative distance values on primary interface routes is not supported.
NAT Refresh Interval
Enter the interval between NAT refresh packets sent on a DTLS or TLS WAN transport connection. Range: 1 through 60 seconds. Default: 5 seconds
Hello Interval
Enter the interval between Hello packets sent on a DTLS or TLS WAN transport connection. Range: 100 through 10000 milliseconds. Default: 1000 milliseconds (1 second)
Hello Tolerance
Enter the time to wait for a Hello packet on a DTLS or TLS WAN transport connection before declaring that transport tunnel
to be down.
Range: 12 through 60 seconds. Default: 12 seconds
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:
Table 21.
Parameter Name
Description
NAT
Click On to have the interface act as a NAT device.
Refresh Mode
Select how NAT mappings are refreshed, either outbound or bidirectional (outbound and inbound). Default: Outbound
UDP Timeout
Specify when NAT translations over UDP sessions time out. Range: 1 through 65536 minutes. Default: 1 minutes
TCP Timeout
Specify when NAT translations over TCP sessions time out. Range: 1 through 65536 minutes. Default: 60 minutes (1 hour)
Block ICMP
Select On to block inbound ICMP error messages. By default, a router acting as a NAT device receives these error messages. Default: Off
Respond to Ping
Select On to have the router respond to ping requests to the NAT interface's IP address that are received from the public side of the
connection.
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.
Table 22.
Parameter Name
Description
Port Start Range
Enter a port number to define the port or first port in the range of interest. Range: 0 through 65535
Port End Range
Enter the same port number to apply port forwarding to a single port, or enter a larger number to apply it to a range of ports.
Range: 0 through 65535
Protocol
Select the protocol to which to apply the port-forwarding rule, either TCP or UDP. To match the same ports for both TCP and
UDP traffic, configure two rules.
VPN
Specify the private VPN in which the internal server resides. This VPN is one of the VPN identifiers in the overlay network.
Range: 0 through 65530
Private IP
Specify the IP address of the internal server to which to direct traffic that matches the port-forwarding rule.
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:
Table 23.
Parameter Name
Description
Shaping rate
Configure the aggreate traffic transmission rate on the interface to be less than line rate, in kilobits per second (kbps).
QoS map
Specify the name of the QoS map to apply to packets being transmitted out the interface.
Rewrite Rule
Click On, and specify the name of the rewrite rule to apply on the interface.
Ingress ACL – IPv4
Click On, and specify the name of the access list to apply to IPv4 packets being received on the interface.
Egress ACL – IPv4
Click On, and specify the name of the access list to apply to IPv4 packets being transmitted on the interface.
Ingress ACL – IPv6
Click On, and specify the name of the access list to apply to IPv6 packets being received on the interface.
Egress ACL – IPv6
Click On, and specify the name of the access list to apply to IPv6 packets being transmitted on the interface.
Ingress Policer
Click On, and specify the name of the policer to apply to packets being received on the interface.
Egress Policer
Click On, and specify the name of the policer to apply to packets being transmitted on the interface.
To save the feature template, click Save.
Configure Other Interface Properties
To configure other interface properties, click Advanced and configure the following properties:
Table 24.
Parameter Name
Description
Bandwidth Upstream
For transmitted traffic, set the bandwidth above which to generate notifications. Range: 1 through (232 / 2) – 1 kbps
Bandwidth Downstream
For received traffic, set the bandwidth above which to generate notifications. Range: 1 through (232 / 2) – 1 kbps
IP MTU
Specify the maximum MTU size of packets on the interface. Range: 576 through 1804. Default: 1500 bytes
TCP MSS
Specify the maximum segment size (MSS) of TPC SYN packets passing through the router. By default, the MSS is dynamically adjusted
based on the interface or tunnel MTU such that TCP SYN packets are never fragmented. Range: 552 to 1460 bytes. Default: None
TLOC Extension
Enter the name of the physical interface on the same router that connects to the WAN transport circuit. This configuration
then binds this service-side interface to the WAN transport. A second router at the same site that itself has no direct connection
to the WAN (generally because the site has only a single WAN connection) and that connects to this service-side interface
is then provided with a connection to the WAN.
Tracker
Enter the name of a tracker to track the status of transport interfaces that connect to the internet.
IP Directed-Broadcast
Enables translation of a directed broadcast to physical broadcasts. An IP directed broadcast is an IP packet whose destination
address is a valid broadcast address for some IP subnet but which originates from a node that is not itself part of that destination
subnet.
To save the feature template, click Save.
Release Information
Introduced in Cisco vManage NMS in Release 18.4.1.
VPN Interface GRE
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 vManage templates:
Create a VPN Interface GRE feature template to configure a GRE interface.
Create a 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.
Create a data policy on the Cisco vSmart Controller that applies to the service VPN, including a set-serviceservice-namelocal command.
Navigate to the Template Screen and Name the Template
From the Cisco vManage menu, choose Configuration > Templates .
Click Device Templates, and click Create Template.
Note
In Cisco vManage Release 20.7.x and earlier releases, Device Templates is titled Device.
From the Create Template drop-down list, select From Feature Template.
From the Device Model drop-down list, select the type of device for which you are creating the template.
To create a template for VPN 0 or VPN 512:
Click Transport & Management VPN or scroll to the Transport & Management VPN section.
Under Additional VPN 0 Templates, click VPN Interface GRE.
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.
To create a template for VPNs 1 through 511, and 513 through 65530:
Click Service VPN or scroll to the Service VPN section.
Click the Service VPN drop-down list.
Under Additional VPN templates, click VPN Interface GRE.
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.
In Template Name, enter a name for the template. The name can be up to 128 characters and can contain only alphanumeric characters.
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.
Table 25.
Parameter Name
Description
Shutdown*
Click Off to enable the interface.
Interface Name*
Enter the name of the GRE interface, in the format grenumber. number can be from 1 through 255.
Description
Enter a description of the GRE interface.
Source*
Enter the source of the GRE interface:
GRE Source IP Address—Enter the source IP address of the GRE tunnel interface. This address is on the local router.
Tunnel Source Interface—Enter the physical interface that is the source of the GRE tunnel.
Destination*
Enter the destination IP address of the GRE tunnel interface. This address is on a remote device.
GRE Destination IP Address*
Enter the destination IP address of the GRE tunnel interface. This address is on a remote device
IPv4 Address
Enter an IPv4 address for the GRE tunnel.
IP MTU
Specify the maximum MTU size of packets on the interface. Range: 576 through 1804 Default: 1500 bytes
Clear-Dont-Fragment
Click On to clear the Don't Fragment bit in the IPv4 packet header for packets being transmitted out the interface.
TCP MSS
Specify the maximum segment size (MSS) of TPC SYN packets passing through the Cisco vEdge device. By default, the MSS is dynamically adjusted based on the interface or tunnel MTU such that TCP SYN packets are never fragmented.
Range: 552 to 1460 bytes Default: None
To save the feature template, click Save.
CLI equivalent:
vpn vpn-id interface grenumber clear-dont-fragment description text
ip address ipv4-prefix/length keepalive seconds retries mtu bytes
policer policer-name (in |out)
qos-map name rewrite-rule name shaping-rate name
[no] shutdown tcp-mss-adjust bytes tunnel-destination ip-address
( tunnel-source ip-address | tunnel-source-interface interface-name)
Configure Interface Access Lists
To configure access lists on a GRE interface, click ACL and configure the following parameters:
Table 26.
Parameter Name
Description
Rewrite Rule
Click On, and specify the name of the rewrite rule to apply on the interface.
Ingress ACL – IPv4
Click On, and specify the name of the access list to apply to IPv4 packets being received on the interface.
Egress ACL – IPv4
Click On, and specify the name of the access list to apply to IPv4 packets being transmitted on the interface.
Ingress Policer
Click On, and specify the name of the policer to apply to packets being received on the interface.
Egress Policer
Click On, and specify the name of the policer to apply to packets being transmitted on the interface.
CLI equivalent:
vpn vpn-id interface grenumber access-list acl-list (in | out)
policer policer-name (in |out)
qos-map name rewrite-rule name shaping-rate name
Configure Tracker Interface
To configure a tracker interface to track the status of a GRE interface, select Advanced and configure the following parameter:
Table 27.
Parameter Name
Description
Tracker
Enter the name of a tracker to track the status of GRE interfaces
that connect to the Internet.
Release Information
Introduced in Cisco vManage NMS Release 15.4.1.
VPN Interface IPsec (for Cisco vEdge Devices)
Use the VPN Interface IPsec feature template to configure IPsec tunnels on Cisco vEdge devices that
are being used for Internet Key Exchange (IKE) sessions. You can configure IPsec on
tunnels in the transport VPN (VPN 0) and in service VPNs (VPN 1 through 65530,
except for 512).
Navigate to the Template Screen and Name the Template
From the Cisco vManage menu, choose Configuration > Templates.
Click Device Templates, and from the Create Template drop-down list, select From Feature Template.
Note
In Cisco vManage Release 20.7.x and earlier releases, Device Templates is titled Device.
From the Device Model drop-down list, select the vEdge device for which you are creating the template.
Click Transport and Management VPN and the page scrolls to the Transport and Management VPN section.
Under Additional VPN 0 Templates, click VPN Interface IPsec.
From the VPN Interface IPsec drop-down list, click Create Template. The VPN Interface IPsec template form is displayed.
This form contains fields for naming the template, and fields for defining the VPN Interface IPsec parameters.
In Template Name, enter a name for the template. The name can be up to 128 characters and can contain only alphanumeric characters.
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:
Table 28.
Parameter Scope
Scope Description
Device Specific (indicated by a host icon)
Use a device-specific value for the parameter. For device-specific parameters, you cannot enter a value in the feature template.
You enter the value when you attach a Viptela device to a device template .
When you click Device Specific, the Enter Key box opens. This box displays a key, which is a unique string that identifies the parameter in a CSV file that you create.
This file is an Excel spreadsheet that contains one column for each key. The header row contains the key names (one key per
column), and each row after that corresponds to a device and defines the values of the keys for that device. You upload the
CSV file when you attach a Viptela device to a device template. For more information, see Create a Template Variables Spreadsheet
.
To change the default key, type a new string and move the cursor out of the Enter Key box.
Examples of device-specific parameters are system IP address, hostname, GPS location, and site ID.
Global (indicated by a globe icon)
Enter a value for the parameter, and apply that value to all devices.
Examples of parameters that you might apply globally to a group of devices are DNS server, syslog server, and interface MTUs.
Configure a Basic IPsec Tunnel Interface
To configure an IPsec tunnel to use for IKE sessions, select the Basic Configuration tab and configure the following parameters.
Parameters marked with an asterisk are required to configure an IPsec tunnel.
Table 29.
Parameter Name
Description
Shutdown*
Click No to enable the interface.
Interface Name*
Enter the name of the IPsec interface, in the format ipsecnumber. number can be from 1 through 256.
Description
Enter a description of the IPsec interface.
IPv4 Address*
Enter the IPv4 address of the IPsec interface, in the format ipv4-prefix/length. The address must be a /30.
Source*
Set the source of the IPsec tunnel that is being used for IKE key exchange:
Click IP Address—Enter the IPv4 address that is the source tunnel interface. This address must be configured in VPN 0.
Click Interface—Enter the name of the physical interface that is the source of the IPsec tunnel. This interface must be configured in VPN
0.
Destination: IPsec Destination IP Address/FQDN*
Set the destination of the IPsec tunnel that is being used for IKE key exchange. Enter either an IPv4 address or the fully
qualified DNS name that points to the destination.
TCP MSS
Specify the maximum segment size (MSS) of TPC SYN packets passing
through the Cisco vEdge device. By default, the MSS is dynamically adjusted based on the
interface or tunnel MTU such that TCP SYN packets are never
fragmented.Range: 552 to 1460 bytesDefault:
None
IP MTU
Specify the maximum MTU size of packets on the interface.Range: 576 through 1804Default: 1500 bytes
To save the feature template, click Save.
CLI equivalent:
vpn vpn-id
interface ipsec number ip address ipv4-prefix/length mtu bytes
no shutdown
tcp-mss-adjust bytes tunnel-destination ipv4-address
( tunnel-source ip-address | tunnel-source-interface interface-name)
Configure Dead-Peer Detection
To configure IKE dead-peer detection to determine whether the connection to an IKE peer is functional and reachable, click
DPD and the page scrolls to the section. Configure the following parameters:
Table 30.
Parameter Name
Description
DPD Interval
Specify the interval for IKE to send Hello packets on the connection.
Range: 0 to 30 seconds. Default: 10 seconds
DPD Retries
Specify how many unacknowledged packets to accept before declaring an IKE peer to be dead and then tearing down the tunnel
to the peer. Range: 0 to 255. Default: 3
To save the feature template, click Save.
CLI equivalent:
vpn vpn-id interface ipsec number dead-peer-detection seconds retries number
Configure IKE
To configure IKE, click IKE and configure the parameters discussed below.
When you create an IPsec tunnel on a Cisco vEdge device, IKE
Version 1 is enabled by default on the tunnel interface. The following properties
are also enabled by default for IKEv1:
Authentication and encryption: AES-256 advanced encryption standard CBC encryption with the HMAC-SHA1 keyed-hash message authentication
code algorithm for integrity
Diffie-Hellman group number: 16
Rekeying time interval: 4 hours
SA establishment mode: Main
To modify IKEv1 parameters, configure the following:
Table 31.
Parameter Name
Description
IKE Version
Enter 1 to select IKEv1.
IKE Mode
Specify the IKE SA establishment mode. Values: Aggressive mode, Main modeDefault: Main mode
IPsec Rekey Interval
Specify the interval for refreshing IKE keys. Range: 3600 through 1209600 seconds (1 hour through 14 days). Default: 14400 seconds (4 hours)
IKE Cipher Suite
Specify the type of authentication and encryption to use during IKE key exchange. Values: aes128-cbc-sha1, aes256-cbc-sha1. Default: aes256-cbc-sha1
IKE Diffie-Hellman Group
Specify the Diffie-Hellman group to use in IKE key exchange. Values: 1024-bit modulus, 2048-bit modulus, 3072-bit modulus, 4096-bit modulus. Default: 4096-bit modulus
IKE Authentication: Preshared Key
To use preshared key (PSK) authentication, enter the password to use with the preshared key.
IKE ID for Local End Point
If the remote IKE peer requires a local end point identifier, specify it. Range:Default: Tunnel's source IP address
IKE ID for Remote End Point
If the remote IKE peer requires a remote end point identifier, specify it. Range: 1 through 64 characters. Default: Tunnel's destination IP address
To save the feature template, click Save.
CLI equivalent:
vpn vpn-id interface ipsec number ike authentication-type type
local-id id
pre-shared-secret password
remote-id id cipher-suite suite group number mode mode rekey-interval seconds
version 1
To configure IKEv2, configure the following parameters:
Table 32.
Parameter Name
Description
IKE Version
Enter 2 to select IKEv2.
IPsec Rekey Interval
Specify the interval for refreshing IKE keys. Range: 3600 through 1209600 seconds (1 hour through 14 days). Default: 14400 seconds (4 hours)
IKE Cipher Suite
Specify the type of authentication and encryption to use during IKE key exchange. Values: aes128-cbc-sha1, aes256-cbc-sha1. Default: aes256-cbc-sha1
IKE Diffie-Hellman Group
Specify the Diffie-Hellman group to use in IKE key exchange. Values: 1024-bit modulus, 2048-bit modulus, 3072-bit modulus, 4096-bit modulus. Default: 4096-bit modulus
IKE Authentication: Preshared Key
To use preshared key (PSK) authentication, enter the password to use with the preshared key.
IKE ID for Local End Point
If the remote IKE peer requires a local end point identifier, specify it. Range:Default: Tunnel's source IP address
IKE ID for Remote End Point
If the remote IKE peer requires a remote end point identifier, specify it. Range: 1 through 64 characters. Default: Tunnel's destination IP address
To save the feature template, click Save.
CLI equivalent:
vpn vpn-id interface ipsec number ike authentication-type type
local-id id
pre-shared-secret password
remote-id id cipher-suite suite group number rekey-interval seconds
version 2
Configure IPsec Tunnel Parameters
To configure the IPsec tunnel that carries IKE traffic, click IPsec and configure the following parameters:
Table 33.
Parameter Name
Description
IPsec Rekey Interval
Specify the interval for refreshing IKE keys. Range: 3600 through 1209600 seconds (1 hour through 14 days). Default: 14400 seconds (4 hours)
IKE Replay Window
Specify the replay window size for the IPsec tunnel. Values: 64, 128, 256, 512, 1024, 2048, 4096, 8192 bytes. Default: 32 bytes
IPsec Cipher Suite
Specify the authentication and encryption to use on the IPsec tunnel. Values:aes256-cbc-sha1, aes256-gcm, null-sha1. Default:aes256-gcm
Perfect Forward Secrecy
Specify the PFS settings to use on the IPsec tunnel. Values: • group-2: Use the 1024-bit Diffie-Hellman prime modulus group. • group-14: Use the 2048-bit Diffie-Hellman prime modulus group. • group-15: Use the 3072-bit Diffie-Hellman prime modulus group. • group-16: Use the 4096-bit Diffie-Hellman prime modulus group. • none: Disable PFS. Default:group-16
To save the feature template, click Save.
CLI equivalent:
vpn vpn-id interface ipsec number ipsec cipher-suite suite perfect-forward-secrecy
pfs-setting rekey-interval seconds replay-window number
Release Information
Introduced in Cisco vManage Release 17.2. In Release 17.2.3, add support for PFS. In Release 18.2, support for IPsec tunnels in VPN 0. In Release 18.4,
standard IPsec support for IOS XE routers.
VPN Interface PPP
Point-to-Point Protocol (PPP) is a data link protocol used to establish a direct connection between two nodes. PPP properties
are associated with a PPPoE-enabled interface on Cisco SD-WAN devices to connect multiple users over an Ethernet link.
To configure PPPoE on Cisco vEdge devices using Cisco vManage templates:
Create a VPN Interface PPP feature template to configure PPP parameters for the PPP virtual interface, as described in this
section.
Create a VPN Interface PPP Ethernet feature template to configure a PPPoE-enabled interface. See VPN Interface PPP Ethernet.
Optionally, create a VPN feature template to modify the default configuration of VPN 0. See the VPN help topic.
Navigate to the Template Screen and Name the Template
From the Cisco vManage menu, choose Configuration > Templates.
Click Device Templates, and click Create Template.
Note
In Cisco vManage Release 20.7.x and earlier releases, Device Templates is titled Device.
From the Create Template drop-down list, choose From Feature Template.
From the Device Model drop-down list, select the type of device for which you are creating the template.
Click Transport & Management VPN or scroll to the Transport & Management VPN section.
Under Additional VPN 0 Templates, click VPN Interface PPP.
From the VPN Interface PPP drop-down list, click Create Template. The VPN Interface PPP template form is displayed.
This form contains fields for naming the template, and fields for defining the VPN Interface PPP parameters.
In the Template Name field, enter a name for the template. The name can be up to 128 characters and can contain only alphanumeric characters.
In the Template Description field, 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:
Table 34.
Parameter Scope
Scope Description
Device Specific (indicated by a host icon)
Use a device-specific value for the parameter. For device-specific parameters, you cannot enter a value in the feature template.
You enter the value when you attach a Cisco vEdge device to a device template .
When you click Device Specific, the Enter Key box opens. This box displays a key, which is a unique string that identifies the parameter in a CSV file that you create.
This file is an Excel spreadsheet that contains one column for each key. The header row contains the key names (one key per
column), and each row after that corresponds to a device and defines the values of the keys for that device. You upload the
CSV file when you attach a Viptela device to a device template. For more information, see Create a Template Variables Spreadsheet
.
To change the default key, type a new string and move the cursor out of the Enter Key box.
Examples of device-specific parameters are system IP address, hostname, GPS location, and site ID.
Global (indicated by a globe icon)
Enter a value for the parameter, and apply that value to all devices.
Examples of parameters that you might apply globally to a group of devices are DNS server, syslog server, and interface MTUs.
Configure a PPP Virtual Interface
To configure a PPP virtual interface, click Basic Configuration and configure the following parameters. Parameters marked with an asterisk are required to configure the interface. You must
also configure an authentication protocol and a tunnel interface for the PPP interface, and you must ensure that the maximum
MTU for the PPP interface is 1492 bytes.
Table 35.
Parameter Name
Description
Shutdown*
Click No to enable the PPP virtual interface.
PPP Interface Name*
Enter the number of the PPP interface. It can be a number from 1 through 31.
Description
Enter a description for the PPP virtual interface.
Bandwidth Upstream
For transmitted traffic, set the bandwidth above which to generate notifications. Range: 1 through (232 / 2) – 1 kbps
Bandwidth Downstream
For received traffic, set the bandwidth above which to generate notifications. Range: 1 through (232 / 2) – 1 kbps
Block Non-Source IP
Click Yes to have the interface forward traffic only if the source IP address of the traffic matches the interface's IP prefix range.
Configure the Access Concentrator Name and Authentication Protocol
To configure the access concentrator name, click PPP and configure the following parameters:
Table 36.
Parameter Name
Description
AC Name
Name of the access concentrator used by PPPoE to route connections to the Internet.
Authentication Protocol
Select the authentication protocol used by PPPoE:
CHAP—Enter the hostname and password provided by your Internet Service Provider (ISP). hostname can be up to 255 characters.
PAP—Enter the username and password provided by your ISP. username can be up to 255 characters.
PAP and CHAP—Configure both authentication protocols. Enter the login credentials for each protocol. To use the same username
and password for both, click Same Credentials for PAP and CHAP.
To save the feature template, click Save.
CLI equivalent:
vpn 0
interface pppnumber ppp
ac-name name
authentication
chap hostname name password password
pap password password sent-username name
Create a Tunnel Interface
On Cisco vEdge devices, you can configure up to four tunnel interfaces. This means that eachCisco vEdge device can have up to four 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 PPP interface, select the Tunnel Interface tab and configure the following parameters:
Table 37.
Parameter Name
Description
Tunnel Interface
Click On to create a tunnel interface.
Color
Select a color for the TLOC.
Control Connection
By default, Control Conection is set to On, which establishes a control connection for the TLOC. If the router has multiple TLOCs, click No to have the tunnel not establish control connection for the TLOC.
Note
We recommend a minimum of 650-700 Kbps bandwidth with default 1 sec hello-interval and 12 sec hello-tolerance parameters configured
to avoid any data/packet loss in connection traffic.
For each BFD session, an additional average sized BFD packet of 175 Bytes consumes 1.4 Kbps of bandwidth.
A sample calculation of the required bandwidth for bidirectional BFD packet flow is given below:
650 – 700 Kbps per device for control connections.
175 Bytes (or 1.4 Kbps) per BFD session on the device (request)
175 Bytes (or 1.4 Kbps) per BFD session on the device (response)
If the path MTU discovery (PMTUD) is enabled, bandwidth for send/receive BFD packets per tunnel for every 30 secs:
A 1500 Bytes BFD request packet is sent per tunnel every 30 secs:
Specify the maximum number of Cisco vSmart Controller that the WAN tunnel interface can connect to. To have the tunnel establish no control connections, set the number to 0.
Range: 0 through 8 Default: 2
vBond As STUN Server
Click On to enable Session Traversal Utilities for NAT (STUN) to allow the tunnel interface to discover its public IP address and
port number when the Cisco vEdge device is located behind a NAT.
Exclude Controller Group List
Set the Cisco vSmart Controller that the tunnel interface is not allowed to connect to. Range: 0 through 100
vManage Connection Preference
Set the preference for using a tunnel interface to exchange control traffic with the vManage NMS. Range: 0 through 8 Default: 5
Low-Bandwidth Link
Select to characterize the tunnel interface as a low-bandwidth link.
Allow Service
Select On or Off for each service to allow or disallow the service on the interface.
To configure additional tunnel interface parameters, click Advanced Options and configure the following parameters:
Table 38.
Parameter Name
Description
GRE
Use GRE encapsulation on the tunnel interface. By default, GRE is disabled.
If you select both IPsec and GRE encapsulations, two TLOCs are created for the tunnel interface that have the same IP addresses
and colors, but that differ by their encapsulation.
IPsec
Use IPSec encapsulation on the tunnel interface. By default, IPsec is enabled.
If you select both IPsec and GRE encapsulations, two TLOCs are created for the tunnel interface that have the same IP addresses
and colors, but that differ by their encapsulation.
IPsec Preference
Specify a preference value for directing traffic to the tunnel. A higher value is preferred over a lower value.
Range: 0 through 4294967295 Default: 0
IPsec Weight
Enter a weight to use to balance traffic across multiple TLOCs. A higher value sends more traffic to the tunnel.
Range: 1 through 255 Default: 1
Carrier
Select the carrier name or private network identifier to associate with the tunnel.
Enter the name of a physical interface to bind to a loopback interface.
Last-Resort Circuit
Select to use the tunnel interface as the circuit of last resort.
NAT Refresh Interval
Enter the interval between NAT refresh packets sent on a DTLS or TLS WAN transport connection. Range: 1 through 60 seconds Default: 5 seconds
Hello Interval
Enter the interval between Hello packets sent on a DTLS or TLS WAN transport connection. Range: 100 through 10000 milliseconds Default: 1000 milliseconds (1 second)
Hello Tolerance
Enter the time to wait for a Hello packet on a DTLS or TLS WAN transport connection before declaring that transport tunnel
to be down.
Range: 12 through 60 seconds Default: 12 seconds
CLI equivalent:
vpn 0
interface interface-name tunnel-interface allow-service service-name
bind interface-name
carrier carrier-name
color color encapsulation (gre | ipsec)
preference number
weight number hello-interval milliseconds hello-tolerance seconds
last-resort-circuit max-control-connections number nat-refresh-interval seconds
vbond-as-stun-server
Configure the Interface as a NAT Device
To configure an interface to act as a NAT device, click NAT and configure the following parameters:
Table 39.
Parameter Name
Description
NAT
Click On to have the interface act as a NAT device.
Refresh Mode
Select how NAT mappings are refreshed, either outbound or bidirectional (outbound and inbound).
Default: Outbound
UDP Timeout
Specify when NAT translations over UDP sessions time out.
Range: 1 through 65536 minutes
Default: 1 minutes
TCP Timeout
Specify when NAT translations over TCP sessions time out.
Range: 1 through 65536 minutes
Default: 60 minutes (1 hour)
Block ICMP
Select On to block inbound ICMP error messages. By default, a Cisco vEdge devicer acting as a NAT device receives these error messages.
Default: Off
Respond to Ping
Select On to have the Cisco vEdge device respond to ping requests to the NAT interface's IP address that are received from the public side of the connection.
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.
Table 40.
Parameter Name
Description
Port Start Range
Enter a port number to define the port or first port in the range of interest.
Range: 0 through 65535
Port End Range
Enter the same port number to apply port forwarding to a single port, or enter the larger number to apply it to a range or
ports. Range: 0 through 65535
Protocol
Select the protocol to whcih to apply the port-forwarding rule, either TCP or UDP. To match the same ports for both TCP and
UDP traffic, configure two rules.
VPN
Specify the private VPN in which the internal server resides. This VPN is one of the VPN identifiers in the overlay network.
Range: 0 through 65535
Private IP
Specify the IP address of the internal server to which to direct traffic that matches the port-forwarding rule.
To apply a rewrite rule, access lists, and policers to a router interface, select the ACL tab and configure the following parameters:
Table 41.
Parameter Name
Description
Rewrite Rule
Click On, and specify the name of the rewrite rule to apply on the interface.
Ingress ACL – IPv4
Click On, and specify the name of the access list to apply to IPv4 packets being received on the interface.
Egress ACL – IPv4
Click On, and specify the name of the access list to apply to IPv4 packets being transmitted on the interface.
Ingress ACL – IPv6
Click On, and specify the name of the access list to apply to IPv6 packets being received on the interface.
Egress ACL – IPv6
Click On, and specify the name of the access list to apply to IPv6 packets being transmitted on the interface.
Ingress Policer
Click On, and specify the name of the policer to apply to packets being received on the interface.
Egress Policer
Click On, and specify the name of the policer to apply to packets being transmitted on the interface.
To save the feature template, click Save.
CLI equivalent:
vpn 0
interface pppnumber access-list acl-name (in | out)
ipv6 access-list acl-name (in | out)
policer policer-name (in |out)
rewrite-rule name
Configure Other Interface Properties
To configure other interface properties, click Advanced and configure the following properties:
Table 42.
Parameter Name
Description
MAC Address
Specify a MAC address to associate with the interface, in colon-separated hexadecimal notation.
IP MTU
Specify the maximum MTU size of packets on the interface. Range: 576 through 1804 Default: 1500 bytes
TCP MSS
Specify the maximum segment size (MSS) of TPC SYN packets passing through the Cisco vEdge device. By default, the MSS is dynamically adjusted based on the interface or tunnel MTU such that TCP SYN packets are never fragmented.
Range: 552 to 1460 bytes Default: None
Clear Dont Fragment
Click On to clear the Don't Fragment bit in the IPv4 packet header for packets being transmitted out the interface. When the DF bit
is cleared, packets larger than that interface's MTU are fragmented before being sent.
TLOC Extension
Enter the name of the physical interface on the same router that connects to the WAN transport circuit. This configuration
then binds this service-side interface to the WAN transport. A secondCisco vEdge device at the same site that itself has no direct connection to the WAN (generally because the site has only a single WAN connection)
and that connects to this service-side interface is then provided with a connection to the WAN.
Tracker
Enter the name of a tracker to track the status of transport interfaces that connect to the internet.
ICMP Redirect
Click Disable to disable ICMP redirect messages on the interface. By default, an interface allows ICMP redirect messages.
Introduced in vManage NMS in Release 15.3.
In Release 16.3, add support for IPv6.
In Release 17.1, support ability to configure both CHAP and PAP authentication on a PPP interface.
In Release 17.2.2, add support for interface status tracking.
In Release 18.2, add support for disabling ICMP redirect messages.
VPN Interface PPP Ethernet
Use the VPN Interface PPP Ethernet template for Cisco vEdge devices.
Point-to-Point Protocol (PPP) is a data link protocol used to establish a direct connection between two nodes. PPP properties
are associated with a PPPoE-enabled interface on Cisco vEdge devices to connect multiple users over an Ethernet link.
To configure PPPoE on Cisco vEdge device using Cisco vManage templates:
Create a VPN Interface PPP Ethernet feature template to configure a PPPoE-enabled interface as described in this article.
Create a VPN Interface PPP feature template to configure PPP parameters for the PPP virtual interface. See the VPN Interface
PPP help topic
Optionally, create a VPN feature template to modify the default configuration of VPN 0. See the VPN help topic.
Navigate to the Template Screen and Name the Template
From the Cisco vManage menu, choose Configuration > Templates.
Click Device Templates, and click Create Template.
Note
In Cisco vManage Release 20.7.x and earlier releases, Device Templates is titled Device.
From the Create Template drop-down list, select From Feature Template.
From the Device Model drop-down list, select the type of device for which you are creating the template.
Click Transport & Management VPN or scroll to the Transport & Management VPN section.
Under Additional VPN 0 Templates, click VPN Interface PPP.
From the VPN Interface PPP Ethernet drop-down list, click Create Template. The VPN Interface PPP Ethernet template form is displayed.
This form contains fields for naming the template, and fields for defining the VPN Interface PPP parameters.
In the Template Name field, enter a name for the template. The name can be up to 128 characters and can contain only alphanumeric characters.
In the Template Description field, 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:
Table 43.
Parameter Scope
Scope Description
Device Specific (indicated by a host icon)
Use a device-specific value for the parameter. For device-specific parameters, you cannot enter a value in the feature template.
You enter the value when you attach a Viptela device to a device template .
When you click Device Specific, the Enter Key box opens. This box displays a key, which is a unique string that identifies
the parameter in a CSV file that you create. This file is an Excel spreadsheet that contains one column for each key. The
header row contains the key names (one key per column), and each row after that corresponds to a device and defines the values
of the keys for that device. You upload the CSV file when you attach a Viptela device to a device template. For more information,
see Create a Template Variables Spreadsheet.
To change the default key, type a new string and move the cursor out of the Enter Key box.
Examples of device-specific parameters are system IP address, hostname, GPS location, and site ID.
Global (indicated by a globe icon)
Enter a value for the parameter, and apply that value to all devices.
Examples of parameters that you might apply globally to a group of devices are DNS server, syslog server, and interface MTUs.
Configure a Basic PPPoE-Enabled Interface
To create a PPPoE-enabled interface on a Cisco vEdge device, select the Basic Configuration tab and configure the following parameters. Parameters marked with an asterisk are required to configure the interface.
Table 44.
Parameter Name
Description
Shutdown*
Click No to enable the PPPoE-enabled interface.
Interface Name*
Enter the name of the physical interface in VPN 0 to associate with the PPP interface.
For Cisco IOS XE SD-WAN devices, you must spell out the interface names completely (for example, GigabitEthernet0/0/0), and you must configure all the router's interfaces 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.
Description
Enter a description of the PPPoE-enabled interface.
IPv4 Configuration*
To configure a static address, click Static and enter an IPv4 address.
To set the interface as a DHCP client so that the interface to receive its IP address from a DHCP server, click Dynamic. You
can optionally set the DHCP distance to specify the administrative distance of routes learned from a DHCP server. The default
DHCP distance is 1.
IPv6 Configuration*
To configure a static address for an interface in VPN 0, click Static and enter an IPv6 address.
To set the interface as a DHCP client so that the interface to receive its IP address from a DHCP server, click Dynamic. You
can optionally set the DHCP distance to specify the administrative distance of routes learned from a DHCP server. The default
DHCP distance is 1. You can optionally enable DHCP rapid commit, to speed up the assignment of IP addresses.
DHCP Helper
Enter up to eight IP addresses for DHCP servers in the network, separated by commas, to have the interface be a DHCP helper.
A DHCP helper interface forwards BOOTP (Broadcast) DHCP requests that it receives from the specified DHCP servers.
Bandwidth Upstream
For transmitted traffic, set the bandwidth above which to generate notifications. Range: 1 through (232 / 2) – 1 kbps
Bandwidth Downstream
For received traffic, set the bandwidth above which to generate notifications. Range: 1 through (232 / 2) – 1 kbps
To configure a shaping rate to a PPPoE-enabled interface and to apply a QoS map, a rewrite rule, access lists, and policers
to the interface, click ACL/QOS and configure the following parameters:
Table 45.
Parameter Name
Description
Shaping Rate
Configure the aggregate traffic transmission rate on the interface to be less than line rate, in kilobits per second (kbps).
QoS Map
Specify the name of the QoS map to apply to packets being transmitted out the interface.
Rewrite Rule
Click On, and specify the name of the rewrite rule to apply on the interface.
Ingress ACL – IPv4
Click On, and specify the name of the access list to apply to IPv4 packets being received on the interface.
Egress ACL – IPv4
Click On, and specify the name of the access list to apply to IPv4 packets being transmitted on the interface.
Ingress ACL – IPv6
Egress ACL – IPv6
Egress ACL – IPv6
Egress ACL – IPv6
Ingress Policer
Click On and specify the name of the policer to apply to packets being received on the interface.
Egress Policer
Click On, and specify the name of the policer to apply to packets being transmitted on the interface.
To save the feature temp
CLI equivalent:
vpn 0
interface pppnumber access-list acl-list (in | out)
policer policer-name (in |out)
qos-map name rewrite-rule name shaping-rate name
Configure Other Interface Properties
To configure other interface properties, click Advanced and configure the following properties:
Table 46.
Parameter Name
Description
Duplex
Choose full or half to specify whether the interface runs in full-duplex or half-duplex mode.Default: Full
MAC Address
Specify a MAC address to associate with the interface, in colon-separated hexadecimal notation.
IP MTU
Specify the maximum MTU size of packets on the interface. Range: 576 through 1804 Default: 1500 bytes
PMTU Discovery
Click On to enable path MTU discovery on the interface. PMTU determines the largest MTU size that the interface supports so that packet
fragmentation does not occur.
Flow Control
Select a setting for bidirectional flow control, which is a mechanism for temporarily stopping the transmission of data on
the interface.Values: autonet, both, egress, ingress, noneDefault: autoneg
TCP MSS
Specify the maximum segment size (MSS) of TPC SYN packets passing through the Cisco vEdge device. By default, the MSS is dynamically adjusted based on the interface or tunnel MTU such that TCP SYN packets are never fragmented.
Range: 552 to 1460 bytes Default: None
Speed
Specify the speed of the interface, for use when the remote end of the connection does not support autonegotiation. Values: 10, 100, or 1000 Mbps Default: Autonegotiate (10/100/1000 Mbps)
Static Ingress QoS
Specify a queue number to use for incoming traffic. Range: 0 through 7
ARP Timeout
Specify how long it takes for a dynamically learned ARP entry to time out. Range: 0 through 2678400 seconds (744 hours) Default: 1200 seconds (20 minutes)
Autonegotiation
Click Off to turn off autonegotiation. By default, an interface runs in autonegotiation mode.
TLOC Extension
Enter the name of a physical interface on the same router that connects to the WAN transport. This configuration then binds
this service-side interface to the WAN transport. A second Cisco vEdge device at the same site that itself has no direct connection to the WAN (generally because the site has only a single WAN connection)
and that connects to this service-side interface is then provided with a connection to the WAN.
Power over Ethernet (on Cisco vEdge 100m and Cisco vEdge 100wm routers)
Click On to enable PoE on the interface.
ICMP Redirect
Click Disable to disable ICMP redirect messages on the interface. By default, an interface allows ICMP redirect messages.
Introduced in vManage NMS Release 15.3.
In Release 16.3, add support for IPv6.
In Release 18.2, add support for disabling ICMP redirect messages.
Cellular Interfaces
To enable LTE connectivity, configure cellular interfaces on a router that has a cellular module. The cellular module provides
wireless connectivity over a service provider's cellular network. One use case is to provide wireless connectivity for branch
offices.
A cellular network is commonly used as a backup WAN link, to provide network connectivity if all the wired WAN tunnel interfaces
on the router become unavailable. You can also use a cellular network as the primary WAN link for a branch office, depending
on usage patterns within the branch office and the data rates supported by the core of the service provider's cellular network.
When you configure a cellular interface on a device, you can connect the device to the Internet or another WAN by plugging
in the power cable of the device. The device then automatically begins the process of joining the overlay network, by contacting
and authenticating with Cisco vBond Orchestrators, Cisco vSmart Controllers, and Cisco vManage systems.
vEdge routers support LTE and CDMA radio access technology (RAT) types.
Configure Cellular Interfaces Using Cisco vManage
To configure cellular interfaces using Cisco vManage templates:
Create a VPN Interface Cellular feature template to configure cellular module parameters, as described in this section.
Create a Cellular Profile template to configure the profiles used by the cellular modem.
Create a VPN feature template to configure VPN parameters.
Create VPN Interface Cellular
From the Cisco vManage menu, choose Configuration > Templates.
Click Device Templates.
Note
In Cisco vManage Release 20.7.x and earlier releases, Device Templates is titled Device.
From the Create Template drop-down list, choose From Feature Template.
From the Device Model drop-down list, select the type of device for which you are creating the template.
Click Transport & Management VPN or scroll to the Transport & Management VPN section.
Under Additional Cisco VPN 0 Templates, click VPN Interface Cellular.
From the VPN Interface Cellular drop-down list, click Create Template. The VPN Interface Cellular template form is displayed.
This form contains fields for naming the template, and fields for defining the VPN Interface Cellular parameters.
In Template Name, enter a name for the template. The name can be up to 128 characters and can contain only alphanumeric characters.
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.
Configure Basic Cellular Interface Functionality
To configure basic cellular interface functionality, click Basic Configuration and configure the following parameters. Parameters marked with an asterisk are required to configure an interface. You must
also configure a tunnel interface for the cellular interface.
Table 47.
Parameter Name
Description
Shutdown*
Click No to enable the interface.
Technology
Cellular technology. The default is lte. Other values are auto and cdma. For ZTP to work, the technology must be auto.
For Cisco ISR 1100 and ISR 1100X Series Routers operating with an LTE cellular module (LTE dongle), configure the value as lte.
Interface Name*
Enter the name of the interface. It must be cellular0.
Profile ID*
Enter the identification number of the cellular profile. This is the profile identifier that you configure in the Cellular-Profile
template. Range: 1 through 15.
Description
Enter a description of the cellular interface.
IPv4 Configuration
To configure a static address, click Static and enter an IPv4 address.
To set the interface as a DHCP client so that the interface to receive its IP address from a DHCP server, click Dynamic. You can optionally set the DHCP distance to specify the administrative distance of routes learned from a DHCP server. The
default DHCP distance is 1.
IPv6 Configuration
To configure a static address for an interface in VPN 0, click Static and enter an IPv6 address.
To set the interface as a DHCP client so that the interface to receive its IP address from a DHCP server, click Dynamic.You
can optionally set the DHCP distance to specify the administrative distance of routes learned from a DHCP server. The default
DHCP distance is 1. You can optionally enable DHCP rapid commit, to speed up the assignment of IP addresses.
DHCP Helper
Enter up to four IP addresses for DHCP servers in the network, separated by commas, to have the interface be a DHCP helper.
A DHCP helper interface forwards BOOTP (Broadcast) DHCP requests that it receives from the specified DHCP servers.
Block Non-Source IP
Click Yes to have the interface forward traffic only if the source IP address of the traffic matches the interface's IP prefix range.
Bandwidth Upstream
For transmitted traffic, set the bandwidth above which to generate notifications. Range: 1 through (232 / 2) – 1 kbps
Bandwidth Downstream
For received traffic, set the bandwidth above which to generate notifications. Range: 1 through (232 / 2) – 1 kbps
IP MTU*
Enter 1428 to set the MTU size, in bytes. This value must be 1428. You cannot use a different value.
To save the feature template, click Save.
CLI equivalent:
vpn 0
interface cellular0
bandwidth-downstream kbps bandwidth-upstream kbps block-non-source-ip ( ip address ip-address/length | ip dhcp-client [dhcp-distance number])
( ipv6 address ipv6-prefix/length | ipv6 dhcp-client [dhcp-distance number] [dhcp-rapid-comit])
mtu 1428
profile number
no shutdown
Create a Tunnel Interface
To configure an interface in VPN 0 to be a WAN transport connection, you must configure a tunnel interface on the cellular
interface. The tunnel, which provides security from attacks, is used to send the phone number. At a minimum, select On and select a color for the interface, as described in the previous section. You can generally accept the system defaults
for the reminder of the tunnel interface settings.
To configure a tunnel interface, click Tunnel, and configure the following parameters. Parameters marked with an asterisk (*) are required to configure a cellular interface.
Parameter Name
Description
Tunnel Interface*
From the drop-down, select Global. Click On to create a tunnel interface.