CLI Equivalent

vpn vpn-id
  dns ip-address (primary | secondary)
  ​host hostname ip ip-address

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.

vSmart/vManage(config)# vpn 0
vSmart/vManage(config-vpn-0)#  interface interface-name
vSmart/vManage(config-interface)# [ip address prefix / length | ip dhcp-client [dhcp-distance  number]
vSmart/vManage(config-interface)# [ipv6 address prefix / length | ipv6 dhcp-client [dhcp-distance number] [dhcp-rapid-commit]
vSmart/vManage(config-interface)# no shutdown
vSmart/vManage(config-interface)# tunnel-interface
vSmart/vManage(config-tunnel-interface)#  color color
vSmart/vManage(config-tunnel-interface)# [no] allow-service service

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.

vEdge(config)# vpn 0
vEdge(config-vpn-0)#  interface interface-name
vEdge(config-interface)# [ip address prefix / length | ip dhcp-client [dhcp-distance number]
vEdge(config-interface)# [ipv6 address prefix / length | ipv6 dhcp-client [dhcp-distance number] [dhcp-rapid-commit]
vEdge(config-interface)# no shutdown
vEdge(config-interface)# tunnel-interface
vEdge(config-tunnel-interface)#  color color [restrict]
vEdge(config-tunnel-interface)#  encapsulation  (gre | ipsec)
vEdge(config-tunnel-interface)# [no] allow-service service
            

On Cisco vSmart Controllers and Cisco vSmart Controller NMSs, interface-name can be either eth number or loopback number. 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 ge slot/port, gre number, ipsec number, loopback string, natpool number, or ppp number.

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:

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.

vEdge(config-tunnel-interface)#  vbond-as-stun-server 

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.

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  ge slot/  port
vEdge-1(config-interface)# ip address prefix / length
vEdge-1(config-interface)# no shutdown
vEdge-1(config-interface)# mtu number
vEdge-1(config-interface)# tunnel-interface
vEdge-1(config-tunnel-interface)# color color

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 address prefix /length
vEdge-2(config-interface)# tloc-extension geslot / port
vEdge-2(config-interface)# no shutdown
vEdge-2(config-interface)# mtu number

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

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:

vEdge(config)# vpn 0 interface  gre number
vEdge(config-interface-gre)# (tunnel-source ip-address | tunnel-source-interface interface-name)
vEdge(config-interface-gre)# tunnel-destination ip-address
vEdge(config-interface-gre)# no shutdown 

The GRE interface has a name in the format gre number, 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 address ip-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:

vEdge(config-interface-gre)# keepalive seconds retries

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:

vEdge(config-interface-gre)# access-list acl-name
vEdge(config-interface-gre)# block-non-source-ip 
vEdge(config-interface-gre)# clear-dont-fragment ​
vEdge(config-interface-gre)# description text
vEdge(config-interface-gre)# mtu bytes
vEdge(config-interface-gre)# policer policer-name
vEdge(config-interface-gre)# rewrite-rule rule-name
vEdge(config-interface-gre)# tcp-mss-adjust 

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-route prefix vpn 0 interface gre number [gre number2]

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):

vEdge(config-vpn)# service service-name interface gre number [gre number2]

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 (gre number1 gre number2) 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 service service-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 service service-name local 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

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-ip ipv4-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 

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:

vEdge(config-tunnel-interface)# max-controllers number

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 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  ge slot / port
vEdge(config-interface)#  ip address prefix/length
vEdge(config-interface)# no shutdown

For service-side interfaces, you can configure up to four secondary IP addresses.

vEdge(config)# vpn vpn-id
vEdge(config-vpn)# interface  ge slot/port
vEdge(config-interface)# ip secondary-address ipv4-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
 !
!

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:

vEdge(config-vpn)# interface interface-name no autonegotiate ​
vEdge(config-vpn)# interface interface-name speed (10 | 100)

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.

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

vEdge(config-vpn)# interface interface-name mtu bytes

The MTU can range from 576 through 2000 bytes.

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)# interface interface-name pmtu 

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)# interface interface-name pmtu 

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.

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:

vEdge/vManage(config)# vpn vpn-id interface interface-name bandwidth-downstream kbps

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

vEdge/vManage(config)# vpn vpn-id interface interface-name bandwidth-upstream kbps

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

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

Use the DHCP-Server template for all Cisco 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:

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

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

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

To configure a Cisco 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

1. From the Cisco vManage menu, choose Configuration > Templates.

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

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

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

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

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

6. Click Service VPN drop-down list.

7. From Additional VPN Templates, click VPN Interface.

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

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

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

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

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

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

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

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

Minimum DHCP Server Configuration

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

To save the feature template, click Save.

 vpn vpn-id
 interface  geslot/port
 dhcp-server  address-pool prefix/length admin-state  (down | up)
       exclude ip-address
       lease-time seconds
       max-leases number
       offer-time minutes
            

Configure Static Leases

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

To edit a static lease, click pencil icon.

To remove a static lease, click trash icon.

To save the feature template, click Save.

CLI equivalent:

 vpn vpn-id
 interface  geslot/port
 dhcp-server  static-lease  mac-address ip ip-address host-name hostname
            

Configure Advanced Options

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

To save the feature template, click Save.

CLI equivalent:

 vpn vpn-id
 interface  geslot/port
 dhcp-server  options
         default-gateway ip-address
        dns-servers ip-address
        domain-name domain-name
        interface-mtu mtu
        tftp-servers ip-address
            

Release Information

Introduced in Cisco vManage in Release 15.2.

The Point-to-Point Protocol over Ethernet (PPPoE) connects multiple users over an Ethernet local area network to a remote site through common customer premises equipment. PPPoE is commonly used in a broadband aggregation, such as by digital subscriber line (DSL). PPPoE provides authentication with the CHAP or PAP protocol. In the Cisco 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.

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 address prefix / length
vEdge(config-interface-ge)#  vrrp group-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)# ipv4 ip-address

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

vEdge(config-vrrp)# priority number

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)# timer seconds

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

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

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-list list-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
  !
 !
!

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 

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:

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

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

Navigate to the Template Screen and Name the Template

1. From the Cisco vManage menu, choose Configuration > Templates.

2. Click Device Templates.

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

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

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

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

6. Click the Service VPN drop-down list.

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

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

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

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

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

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

Release Information

Introduced in Cisco vManage NMS in Release 15.3. In Release 18.2, add support for disabling ICMP redirect messages.

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:

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

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

Navigate to the Template Screen and Name the Template

1. From the Cisco vManage menu, choose Configuration > Templates.

2. Click Device Templates, and click Create Template.

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

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

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

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

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

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

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

   

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

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

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

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

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

Configure PPPoE Functionality

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

To save the feature template, click Save.

Configure the PPP Authentication Protocol

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

To save the feature template, click Save.

​Create a Tunnel Interface

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

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

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

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

Configure the Interface as a NAT Device

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

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

To save a port forwarding rule, click Add.

To save the feature template, click Save.

Apply Access Lists

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

To save the feature template, click Save.

Configure Other Interface Properties​

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

To save the feature template, click Save.

Release Information

Introduced in Cisco vManage NMS in Release 18.4.1.

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

To configure GRE interfaces using Cisco vManage templates:

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

2. 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.

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

Navigate to the Template Screen and Name the Template

1. From the Cisco vManage menu, choose Configuration > Templates .

2. Click Device Templates, and click Create Template.

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

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

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

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

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

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

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

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

6. To create a template for VPNs 1 through 511, and 513 through 65530:

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

   2. Click the Service VPN drop-down list.

   3. Under Additional VPN templates, click VPN Interface GRE.

   4. 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.

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

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

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

Configuring a Basic GRE Interface

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

To save the feature template, click Save.

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:

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:

Release Information

Introduced in Cisco vManage NMS Release 15.4.1.

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

1. From the Cisco vManage menu, choose Configuration > Templates.

2. 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.

3. From the Device Model drop-down list, select the vEdge device for which you are creating the template.

4. Click Transport and Management VPN and the page scrolls to the Transport and Management VPN section.

5. Under Additional VPN 0 Templates, click VPN Interface IPsec.

6. 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.

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

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

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

Configure 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.

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:

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:

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:

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:

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.

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:

1. Create a VPN Interface PPP feature template to configure PPP parameters for the PPP virtual interface, as described in this section.

2. Create a VPN Interface PPP Ethernet feature template to configure a PPPoE-enabled interface. See VPN Interface PPP Ethernet.

3. 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

1. From the Cisco vManage menu, choose Configuration > Templates.

2. Click Device Templates, and click Create Template.

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

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

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

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

6. Under Additional VPN 0 Templates, click VPN Interface PPP.

7. 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.

8. 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.

9. 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:

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.

To save the feature template, click Save.

CLI equivalent:

 vpn  0
   interface  pppnumber banddwidth-downstream kbps bandwidth-upstream kbps block-non-source-ip  ppp 
      no  shutdown 

​Configure the Access Concentrator Name and Authentication Protocol

To configure the access concentrator name, click PPP and configure the following parameters:

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:

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

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:

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

To save a port forwarding rule, click Add.

To save the feature template, click Save.

CLI equivalent:

 vpn vpn-id
 interface interface-name nat  block-icmp-error  port-forward  port-start port-number1 
port-end port-number2 proto (tcp | udp) 
        private-ip-address ip-address private-vpn vpn-id refresh  (bi-directional | outbound)
       respond-to-ping  tcp-timeout minutes
 udp-timeout minutes
            

Apply Access Lists

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

To save the feature template, click Save.

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:

To save the feature template, click Save.

CLI equivalent:

 vpn vpn-id interface interface-name clear-dont-fragment  icmp-redirect-disable  
mac-address mac-address mtu bytes tcp-mss-adjust bytes tloc-extension 
interface-name tracker tracker-name

Release Information

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.

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:

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

2. Create a VPN Interface PPP feature template to configure PPP parameters for the PPP virtual interface. See the VPN Interface PPP help topic

3. 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

1. From the Cisco vManage menu, choose Configuration > Templates.

2. Click Device Templates, and click Create Template.

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

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

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

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

6. Under Additional VPN 0 Templates, click VPN Interface PPP.

7. 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.

8. 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.

9. 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:

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.

To save the feature template, click Save.

CLI equivalent:

 vpn  0
   interface  pppnumber bandwidth-downstream kbps bandwidth-upstream kbps description text dhcp-helper ip-address
    ( ip address ipv4-prefix/length |  ip-dhcp-client  [dhcp-distance number])
    ( ipv6 address ipv6-prefix/length |  ipv6 dhcp-client  [dhcp-distance number] [ dhcp-rapid-commit]
     pppoe-client  ppp-interface pppnumber
    [no]  shutdown 

Apply Access Lists

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:

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:

To save the feature template, click Save.

CLI equivalent:

vpn  0
  interface pppnumber arp-timeout seconds
    [no]  autonegotiate  duplex  (full | half)
     flow-control control icmp-redirect-disable  mac-address mac-address mtu bytes pmtu  pppoe-client 
      ppp-interface pppnumber speed speed
     static-ingress-qos number  tcp-mss-adjust bytes tloc-extension interface-name 
            

Release Information

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.

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.