Skip to main content
Cisco SD-WAN
Support
Product Documentation
Viptela Documentation

Configuring Network Interfaces

In the Viptela overlay network, you configure network interfaces within individual VPNs. For each network interface, you can configure a number of interface-specific properties, such as DHCP clients and servers, VRRP, interface MTU and speed, and PPPoE

In the Viptela overlay network design, interfaces are associated with VPNs. The interfaces that participate in a VPN are configured and enabled in that VPN. Each interface can be present only in a single VPN.

At a high level, for an interface to be operational, you must configure an IP address for the interface and mark it as operational (no shutdown). In practice, you always configure additional parameters for each interface.

You can configure up to 512 interfaces on a Viptela device. This number includes physical interfaces, loopback interfaces, and subinterfaces.

 

Configure Interfaces in the WAN Transport VPN (VPN 0)

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 Viptela 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 vSmart controller or a vManage NMS, you create an interface in VPN 0, assign an IP address, and mark it as a tunnel interface. You can optionally associate a color with the tunnel.

vSmart(config)# vpn 0
vSmart(config-vpn-0)# interface interface-name
vSmart(config-interface)# ip address prefix/length
vSmart(config-interface)# no shutdown
vSmart(config-interface)# tunnel-interface
vSmart(config-tunnel-interface)# color color

vSmart(config-tunnel-interface)# [no] allow-service service

Tunnel interfaces on vEdge routers must have an IP address, a color, and an encapsulation type:

vEdge(config)# vpn 0
vEdge(config-vpn-0)# interface interface-name
vEdge(config-interface)# ip address prefix/length
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 vSmart controllers and vManage NMSs, interface-name can be either ethnumber or loopbacknumber. Because vSmart controllers and vManage NMSs participate only in the overlay network's control plane, the only VPN that you can configure on these devices is VPN 0, and hence all interfaces are present only in this VPN.

On vEdge routers, interface-name can be either geslot/port or loopbacknumber.

To enable the interface, include the no shutdown command.

For the tunnel interface, you can configure a static IPv4  address, or you can configure the interface to receive its address from a DHCP server.

Color is a Viptela 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 vEdge router 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 vEdge routers.

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 vSmart controller or vManage NMS, you can configure one tunnel interface. On a vEdge router, you can configure up to seven tunnel interfaces. This means that each vEdge router can have up to seven TLOCs.

On vEdge routers, 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 vEdge router, you must configure the same tunnel encapsulation type or types so that the two routers can exchange data traffic. Data transmitted out 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 Viptela software automatically selects the correct tunnel on the destination vEdge router.

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

Service

vEdge Router

vManage NMS

vSmart Controller

all (Overrides any commands that allow or disallow individual services)

X

X

X

bgp

X

dhcp

X

dns

X

https

X

icmp

X

X

X

netconf

X

ntp

X

ospf

X

sshd

X

X

X

On a vEdge router, services that you configure on a tunnel interface act as implicit access lists (ACLs). If you explicitly configure ACLs on a tunnel interface, with the policy access-list command, the handling of packets matching both implicit and explict ACLs depends on the exact configuration. For more information, see Configuring Localized Data Policy.

For each transport tunnel on a vEdge router and for each encapsulation type on a single transport tunnel, the Viptela software creates a TLOC, which consists of the router's system IP address, the color, and the encapsulation. The OMP session running on the tunnel sends the TLOC, as a TLOC route, to the 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 the configured interfaces in the WAN transport VPN, 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

In this 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".

Associate a Carrier Name with a Tunnel Interface

To associate a carrier name or private network identifier with a tunnel interface, use the carrier command. carrier-name can be default and carrier1 through carrier8:

Viptela(config)# vpn 0
Viptela(config-vpn-0)# interface interface-name
Viptela(config-interface)# tunnel-interface
Viptela(config-tunnel-interface)# carrier carrier-name

Limit Keepalive Traffic on a Tunnel Interface

By default, Viptela devices send a Hello packet once per second to determine whether the tunnel interface between two devices is still operational and to keep the tunnel alive. The combination of a hello interval and a hello tolerance determines how long to wait before declaring a DTLS or TLS tunnel to be down. The default hello interval is 1 second, and the default tolerance is 12 seconds. With these default values, if no Hello packet is received within 11 seconds, the tunnel is declared down at 12 seconds.

If the hello interval or the hello tolerance, or both, are different at the two ends of a DTLS or TLS tunnel, the tunnel chooses the interval and tolerance as follows:

  • For a tunnel connection between two controller devices, the tunnel uses the lower hello interval and the higher tolerance interval for the connection between the two devices. (Controller devices are vBond controllers, vManage NMSs, and vSmart controllers.) This choice is made in case one of the controllers has a slower WAN connection. The hello interval and tolerance times are chosen separately for each pair of controller devices.
  • For a tunnel connection between a vEdge router and any controller device, the tunnel uses the hello interval and tolerance times configured on the router. This choice is made to minimize the amount traffic sent over the tunnel, to allow for situations where the cost of a link is a function of the amount of traffic traversing the link. The hello interval and tolerance times are chosen separately for each tunnel between a vEdge router and a controller device.

To minimize the amount of keepalive traffic on a tunnel interface, increase the Hello packet interval and tolerance on the tunnel interface:

vEdge(config-tunnel-interface)# hello-interval milliseconds
vEdge(config-tunnel-interface)# hello-tolerance seconds

The default hello interval is 1000 milliseconds, and it can be a time in the range 100 through 600000 milliseconds (10 minutes). The default hello tolerance is 12 seconds, and it can be a time in the range 12 through 600 seconds (10 minutes). The hello tolerance interval must be at most one-half the OMP hold time. The default OMP hold time is 60 seconds, and you configure it with the omp timers holdtime command.

Limit the HTTPS Connections to a vManage Server

By default, a vManage application server accepts a maximum of 50 HTTPS connections from users in the overlay network. To modify the maximum number of HTTPS connections that can be established:

vManage(config)# vpn 0 interface interface-name tunnel-interface control-connections number

The number can be from 1 through 512.

Configure Multiple Tunnel Interfaces on a vEdge Router

On a vEdge router, you can configure up to eight tunnel interfaces in the transport interface (VPN 0). This means that each vEdge router can have up to eight TLOCs.

When a vEdge router has multiple TLOCs, each TLOC is preferred equally and traffic to each TLOC is weighted equally, resulting in ECMP routing. ECMP routing is performed regardless of the encapsulation used on the transport tunnel, so if, for example, a router has one IPsec and one GRE tunnel, with ECMP traffic is forwarded equally between the two tunnels. You can change the traffic distribution by modifying the preference or the weight, or both, associated with a TLOC. (Note that you can also affect or change the traffic distribution by applying a policy on the interface that affects traffic flow.)

vEdge(config)# vpn 0
vEdge(config-vpn-0)# interface interface-name
vEdge(config-tunnel-interface) encapsulation (gre | ipsec)
vEdge(config-encapsulation)# preference number
vEdge(config-encapsulation)# weight number

The preference command controls the preference for directing traffic to a tunnel. The preference can be a value from 0 through 4294967295 (232 – 1), and the default value is 0. A higher value is preferred over a lower value.

When a vEdge router has two or more tunnels, if all the TLOCs have the same preference and no policy is applied that affects traffic flow, all the TLOCs are advertised into OMP. When the router transmits or receives traffic, it distributes traffic flows evenly among the tunnels, using ECMP.

When a vEdge router has two or more tunnels, if the TLOCs all have different preferences and no policy is applied that affects traffic flow, only the TLOC with the highest preference is advertised into OMP. When the router transmits or receives traffic, it sends the traffic only to the TLOC with the highest preference. When there are three or more tunnels and two of them have the same preference, traffic flows are distributed evenly between these two tunnels.

A remote vEdge router trying to reach one of these prefixes selects which TLOC to use from the set of TLOCs that have been advertised. So, for example, if a remote router selects a GRE TLOC on the local router, the remote router must have its own GRE TLOC to be able to reach the prefix. If the remote router has no GRE TLOC, it is unable to reach the prefix. If the remote router has a single GRE TLOC, it selects that tunnel even if there is an IPsec TLOC with a higher preference. If the remote router has multiple GRE TLOCs, it selects from among them, choosing the one with the highest preference or using ECMP among GRE TLOCs with equal preference, regardless of whether there is an IPsec TLOC with a higher preference.

The weight command controls how traffic is balanced across multiple TLOCs that have equal preferences values. The weight can be a value from 1 through 255, and the default is 1. When the weight value is higher, the router sends more traffic to the TLOC. You typically set the weight based on the bandwidth of the TLOC. When a router has two or more TLOCs, all with the highest equal preference value, traffic distribution is weighted according to the configured weight value. For example, if TLOC A has weight 10, and TLOC B has weight 1, and both TLOCs have the same preference value, then roughly 10 flows are sent out TLOC A for every 1 flow sent out TLOC B.

Configure Control Plane High Availability

A highly available Viptela network contains two or more vSmart controllers in each domain. A Viptela domain can have up to eight vSmart controllers, and each vEdge router, 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 vSmart controllers in a domain is greater than the maximum number of controllers that a domain's vEdge routers are allowed to connect to, the Viptela software load-balances the connections among the available vSmart controllers.

icon-tip.png Tip: To maximize the efficiency of the load-balancing among vSmart controllers, use sequential numbers when assigning system IP addresses to the vEdge routers in the domain. One example of a sequential numbering scheme is 172.1.1.1, 172.1.1.2, 172.1.1.3, and so forth. Another is 172.1.1.1, 172.1.2.1, 172.1.3.1, and so forth.

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 Configuring Centralized Data Policy.

Configure the System Interface

For each Viptela 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 Viptela 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.

Viptela(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    

Extend the WAN Transport VPN

When two vEdge routers are collocated at a site that has only one WAN circuit, you can configure the vEdge router 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.

The following figure illustrates a site with two vEdge routers. vEdge-2 has two WAN circuits, one to the Internet and a second to a private MPLS network, and so has two TLOCs. By itself, vEdge1 has no TLOCs. You can configure vEdge-2 to extend its WAN transport VPN to vEdge1 so that vEdge-1 can participate independently in the overlay network.

s00173.png

When you extend the WAN transport VPN, no BFD sessions are established between the two collated vEdge routers.

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 (vEdge-1 in the figure above), create a tunnel interface in VPN 0 on the physical interface to the connected router:

vEdge-1(config-vpn-0)# interface geslot/port
vEdge-1(config-interface)# ip 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 (vEdge-2 in the figure above), configure the interface that connects to the unconnected router, again in VPN 0:

vEdge-2(config-vpn-0)# interface geslot/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 vEdge router. The NAT configuration is required because the two vEdge routers 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 TLOC only 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.

By default, routers at one site form BFD tunnels only with routers at remote sites. If you want the routers at the same site to form BFD tunnels between them, enable the formation of these tunnels:

vEdge(config)# system allow-same-site-tunnels

Here is a sample configuration that corresponds to the figure shown above. Because the router vEdge-2 connects to two transports, we create subinterfaces between the vEdge-1 and vEdge-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 101.1.19.15/24
  mtu 1496
  tunnel-interface
    color lte
    ...
  !
  no shutdown
!
interface ge0/2.102
  ip address 102.1.19.15/24
  mtu 1496
  tunnel-interface
    color mpls
    ...
  !
  no shutdown
!
ip route 0.0.0.0/0 101.1.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 101.1.19.16/24
  mtu 1496
  tloc-extension ge0/0
  no shutdown
!
interface ge0/2.102
  ip address 102.1.19.16/24
  mtu 1496
  tloc-extension ge0/3
  no shutdown
!

For this example configuration, vEdge-1 establishes two control connections to each 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 vEdge-2. The following output shows the control connections on vEdge-1 in a network with two 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 vEdge routers have established no BFD sessions between them. On vEdge-1, we see no BFD sessions to vEdge-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              101.1.19.15      10.0.101.1       12346       ipsec  20          1000           0:00:20:26   0
172.16.255.11    100      up      lte           3g               101.1.19.15      10.0.101.2       12346       ipsec  20          1000           0:00:20:26   0
172.16.255.11    100      up      lte           gold             101.1.19.15      10.0.101.3       12346       ipsec  20          1000           0:00:20:26   0
172.16.255.11    100      up      lte           red              101.1.19.15      10.0.101.4       12346       ipsec  20          1000           0:00:20:26   0
172.16.255.11    100      up      mpls          lte              102.1.19.15      10.0.101.1       12346       ipsec  20          1000           0:00:20:26   0
172.16.255.11    100      up      mpls          3g               102.1.19.15      10.0.101.2       12346       ipsec  20          1000           0:00:20:26   0
172.16.255.11    100      up      mpls          gold             102.1.19.15      10.0.101.3       12346       ipsec  20          1000           0:00:20:26   0
172.16.255.11    100      up      mpls          red              102.1.19.15      10.0.101.4       12346       ipsec  20          1000           0:00:20:26   0
172.16.255.14    400      up      lte           lte              101.1.19.15      10.1.14.14       12360       ipsec  20          1000           0:00:20:26   0
172.16.255.14    400      up      mpls          lte              102.1.19.15      10.1.14.14       12360       ipsec  20          1000           0:00:20:26   0
172.16.255.21    100      up      lte           lte              101.1.19.15      10.0.111.1       12346       ipsec  20          1000           0:00:20:26   0
172.16.255.21    100      up      lte           3g               101.1.19.15      10.0.111.2       12346       ipsec  20          1000           0:00:20:26   0
172.16.255.21    100      up      mpls          lte              102.1.19.15      10.0.111.1       12346       ipsec  20          1000           0:00:20:26   0
172.16.255.21    100      up      mpls          3g               102.1.19.15      10.0.111.2       12346       ipsec  20          1000           0:00:20:26   0

Configure Interfaces in the Management VPN (VPN 512)

On all Viptela devices, VPN 512 is used, by default, for out-of-band management, and its configuration is part of the factory-default configuration. The interface type for management interfaces is mgmt, and the initial address for the interface is 192.168.1.1.

Viptela# 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 that VPN 512 is not a routable VPN. If you need a routable management VPN, create a VPN with a number other than 512.

Configure Interfaces for Carrying Data Traffic

On vEdge routers, in VPNs other than 0 and 512, you configure 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 IP address, and you must enable it:

Viptela(config)# vpn number
Viptela(config-vpn-number)# interface geslot/port
Viptela(config-interface)# ip address prefix/length
Viptela(config-interface)# no shutdown

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

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  1.1.1.1/32     Up      Up      null   service  1500  00:00:00:00:00:00  10     full    0       1:05:44:07  0        0

For some protocols, you specify an interface as part of the protocol's configuration. In these cases, the interface used by the protocol must be the same as one of the interfaces configured in the VPN. As example is OSPF, where you place interfaces in OSPF areas. In this example, the interface ge0/0 is configured in VPN 1, and this interface is configured to be in the OSPF backbone area:

vEdge# show running-config vpn 1 
vpn 1
 router
  ospf
   router-id 172.16.255.21
   timers spf 200 1000 10000
   redistribute static
   redistribute omp
   area 0
    interface ge0/0
    exit
   exit
  !
 !
 interface ge0/0
  ip address 10.2.3.21/24
  no shutdown
 !
!

Configure Subinterfaces and VLANs

You can configure IEEE 802.1Q VLANs on vEdge routers. In such VLANs, physical interfaces are divided into subinterfaces. When you configure a subinterface, the interface name has the format geslot/port.vlan-number. The VLAN number, vlan-number, can be in the range 1 through 4094.

As with all interfaces, the subinterface must be activated, by configuring it with the no shutdown command.

To accommodate the 32-bit field added to packets by the 802.1Q protocol, you must also configure the MTU for VLAN subinterfaces to be at least 4 bytes smaller than the MTU of the physical interface. You do this using the mtu command. The default MTU on a physical interface is 1500 bytes by default, so the subinterface's MTU here can be no larger than 1496 bytes.

For subinterfaces to work, you must configure the physical interface in VPN 0 and activate it with a no shutdown command. If the physical interface goes down for any reason, all its subinterfaces also go down.

You can place the VLANs associated with a single physical interface into multiple VPNs. Each individual subinterface can be present only in a single VPN.

​Here is an example of a minimal VLAN configuration. The VLANs are configured on subinterfaces ge0/6.2 and ge0/6.3 in VPN 1, and they are associated with the physical interface ge0/6 in VPN 0.

vEdge# show running-config vpn 1
vpn 1
 interface ge0/6.2
  mtu      1496
  no shutdown
 !
interface ge0/6.3
  mtu      1496
  no shutdown
 !
!
vEdge# show running-config vpn 0
vpn 0
 interface ge0/0
  ip dhcp-client
  tunnel-interface
   encapsulation ipsec
   no allow-service all
   no allow-service bgp
   allow-service dhcp
   allow-service dns
   allow-service icmp
   no allow-serivce ospf
   no allow-service sshd
   no allow-service ntp
   no allow-service stun
  !
  no shutdown
 !
 interface ge0/6
  ip address 57.0.1.15/24
  no shutdown
 !
!

The output of the show interface command shows the physical interface and the subinterfaces. The Encap Type column shows that the subinterfaces are VLAN interfaces, and the MTU column shows that the physical interface has an MTU size of 1500 bytes, while the MTU of the subinterfaces is 1496 bytes, so 4 bytes less.

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      10.1.15.15/24     Up      Up      null   transport  1500  00:0c:29:7d:1e:fe  10     full    0       0:04:32:28  289584   289589   
0    ge0/1      10.1.17.15/24     Up      Up      null   service    1500  00:0c:29:7d:1e:08  10     full    0       0:04:32:28  290      2        
0    ge0/2      -                 Down    Up      null   service    1500  00:0c:29:7d:1e:12  10     full    0       0:04:32:28  290      1        
0    ge0/3      10.0.20.15/24     Up      Up      null   service    1500  00:0c:29:7d:1e:1c  10     full    0       0:04:32:28  290      2        
0    ge0/6      57.0.1.15/24      Up      Up      null   service    1500  00:0c:29:7d:1e:3a  10     full    0       0:04:32:28  290      2        
0    ge0/7      10.0.100.15/24    Up      Up      null   service    1500  00:0c:29:7d:1e:44  10     full    0       0:04:32:28  300      2        
0    system     172.16.255.15/32  Up      Up      null   loopback   1500  00:00:00:00:00:00  10     full    0       0:04:32:27  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:04:32:18  2015     1731     
1    ge0/5      56.0.1.15/24      Up      Up      null   service    1500  00:0c:29:7d:1e:30  10     full    0       0:04:32:18  290      3        
1    ge0/6.2    10.2.2.3/24       Up      Up      vlan   service    1490  00:0c:29:7d:1e:3a  10     full    0       0:04:32:18  0        16335    
1    ge0/6.3    10.2.3.5/24       Up      Up      vlan   service    1496  00:0c:29:7d:1e:3a  10     full    0       0:04:32:18  0        16335    
512  eth0       10.0.1.15/24      Up      Up      null   service    1500  00:50:56:00:01:0f  1000   full    0       0:04:32:21  3224     1950 

Configure Loopback Interfaces

You can configure loopback interfaces in any VPN. Use the interface name format loopbackstring, where string can be any alphanumeric value and can include underscores (_) and hyphens (–). The total interface name, including the string "loopback", can be a maximum of 16 characters long. (Note that because of the flexibility of interface naming in the CLI, the interfaces lo0 and loopback0 are parsed as different strings and as such are not interchangeable. For the CLI to recognize as interface as a loopback interface, its name must start with the full string loopback.)

One special use of loopback interfaces is to configure data traffic exchange across private WANs, such as MPLS or metro Ethernet networks. To allow a vEdge router that is behind a private network to communicate directly over the private WAN with other vEdge routers, you direct data traffic to a loopback interface that is configured as a tunnel interface rather than to an actual physical WAN interface. For more information, see Configure Data Traffic Exchange across Private WANs in the Configuring Segmentation (VPNs) article.

Configure GRE Interfaces and Advertise Services To Them

When a service, such as a firewall, is available on a device that supports only GRE tunnels, you can configure a GRE tunnel on the vEdge router to connect to the remote device. You then advertise that the service is available via a GRE tunnel, and you direct the appropriate traffic to the tunnel either by creating centralized data policy or by configuring GRE-specific static routes.

GRE interfaces are logical interfaces, and you configure them just like any other physical interface. Because a GRE interface is a logical interface, you must bind it to a physical 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 grenumber
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 grenumber, where number can be from 1 through 255.

To configure the source of the GRE tunnel on the local device, you can specify either the IP address of the physical interface (in the tunnel-source command or the name of the physical 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 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 router 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 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)# clear-dont-fragment
​vEdge(config-interface-gre)# description text
vEdge(config-interface-gre)# mtu bytes
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 grenumber [grenumber2]

This GRE-specific static route directs traffic from the specified prefix to the primary GRE interface, and optionally to the secondary GRE interface, in VPN 0. The OMP administrative distance of a GRE-specific static route is 5, and that for a regular static route (configured with the ip route command) is 0. 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 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 grenumber [grenumber2]

The service name can be FW, IDP, or IDS, or a custom service name netsvc1 through netsvc4. 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 (grenumber1 grenumber2) in the service command. Once you have configured a service as reachable a the 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 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-name local

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 track GRE tunnels and their traffic, use the following commands:

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

s00183.png

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

Set the Interface Speed

When a vEdge router comes up, the Viptela 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     1.1.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  1.1.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 vSmart controllers and vManage NMS systems, the initial interface speeds are 1000 Mbps, and the operating speed is negotiated with the device at the remote end of the interface.

Set the Interface MTU

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

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

The MTU can range from 576 through 1804 bytes.

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

For vBond, vManage, and vSmart 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:

Viptela(config-vpn)# interface interface-name pmtu 

On vEdge routers, the Viptela 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 vBond, vManage, and vSmart devices.

Configure Static ARP Table Entries

By default, vEdge routers respond to ARP requests only if the destination address of the request is on the local network. You can configure static ARP entries on a Gigabit Ethernet interface in any VPN to allow the router to respond to ARP requests even if the destination address of the request is not local to the incoming interface. The ARP entry maps an IP address to a MAC address.

Viptela(config-vpn)# interface interface-name arp ip ip-address mac mac-address

Configure DHCP

​When you configure a tunnel interface on a vEdge router, a number of services are enabled by default on that interface, including DHCP.

A vEdge router can act as a DHCP server for the service-side network to which it is connected, and it can also act as a DHCP helper, forwarding requests for IP addresses from devices in the service-side network to a DHCP server that is in a different subnet on the service side of the vEdge router.

Enable DHCP on the WAN Interface

On a vEdge router's WAN interface—the interface configured as a tunnel interface in VPN 0, the transport VPN—DHCP is enabled by default. You can see this by using the details filter with the show running-config command. This command also shows that the DNS and ICMP services are enabled by default.

vm1# show running-config vpn 0 interface ge0/2 tunnel-interface | details
vpn 0
 interface ge0/2
  tunnel-interface
   encapsulation ipsec weight 1
   color lte
   control-connections
   carrier             default
   no allow-service all
   no allow-service bgp
   allow-service dhcp
   allow-service dns
   allow-service icmp
   no allow-service ospf
   no allow-service sshd
   no allow-service ntp
   no allow-service stun
  !
 !
!

Enabling DHCP on the router's WAN interface allows the device that actually connects the router to the transport network (such as a DSL router) to dynamically assign a DHCP address to the vEdge router. The DHCP service in VPN 0 affects the transport-side network.

Have a vEdge Router Be a DHCP Server

One or more service-side interfaces on vEdge router can act as a DHCP server, assigning IP addresses to hosts in the service-side network. To do this, configure this function on the interface that connects the vEdge router to the local site's network. At a minimum, you must configure the pool of IP addresses available for assigning to hosts:

vEdge(config-vpn)# interface geslot/port dhcp-server address-pool ip-address/prefix
vEdge(config-dhcp-server)#

You can exclude IP addresses that fall within the range of the DHCP address pool:

vEdge(config-dhcp-server)# exclude ip-address

To specify multiple individual addresses, list them in a single exclude command, separated by a space (for example, exclude 1.1.1.1 2.2.2.2 3.3.3.3). To specify a range of addresses, separate them with a hyphen (for example, exclude 1.1.1.1-1.1.1.10).

You can also statically assign IP addresses to a host:

vEdge(config-dhcp-server)# static-lease mac-address ip ip-address

By default, the DHCP server on a single interface can assign 254 DHCP leases, and each lease is valid for 24 hours. The offer of an IP address is valid indefinitely, until that DHCP server runs out of addresses to offer. You can modify these values:

vEdge(config-dhcp-server)# max-leases number
vEdge(config-dhcp-server)# lease-time seconds
vEdge(config-dhcp-server)# offer-time minutes

These values can range from 0 through (232 – 1).

The Viptela software supports DHCP server options that allow you to configure the IP addresses of a default gateway, DNS server, and TFTP server in the service-side network and the network mask of the service-side network:

vEdge(config-dhcp-server)# options default-gateway ip-address
vEdge(config-dhcp-server)# options dns-servers ip-address
vEdge(config-dhcp-server)# options domain-name domain-name
vEdge(config-dhcp-server)# options interface-mtu mtu
vEdge(config-dhcp-server)# options tftp-servers ip-address

Have a vEdge Router Be a DHCP Helper

One or more service-side interfaces on a vEdge router can be a DHCP helper. With this configuration, the interface forwards any broadcast BOOTP DHCP requests that it receives from hosts on the service-side network to the DHCP server or servers specified by the configured IP helper address (or addresses) and returns the assigned IP address to the requester.

When the DHCP server at the vEdge router's local site is on a different segment than the devices connected to the vEdge router or than the vEdge router itself. When configured as a DHCP helper, the vEdge interface forwards any broadcast BOOTP DHCP requests that it receives to the DHCP server specified by the configured IP helper address.

To configure an interface as a DHCP helper, configure the IP address of the DHCP server on the interface that connects to the local site's network:

vEdge(config-vpn)# interface geslot/port dhcp-helper ip-address

You can configure up to four IP addresses, and the addresses must be entered in a single dhcp-helper command.

Configure VRRP

The Virtual Router Redundancy Protocol (VRRP) provides redundant gateway service for switches and other IP end stations. In the Viptela software, you configure VRRP on an interface, and typically on a subinterface, within a VPN.

For a VRRP interface to operate, its 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. 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 vEdge router with the higher priority value is elected as master. By default, each virtual router IP address has a default master election priority of 100, so the router with the higher IP address is elected master. You can modify the priority value, setting it to a value from 1 through 254:

vEdge(config-vrrp)# priority number

The VRRP master periodically sends advertisement messages, indicating that it is still operating. If slave routers miss three consecutive VRRP advertisements, they assume that the master is down and elect a new master. 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 of the state of the interface on which it is running to determine which vEdge router is the master virtual router. This interface is on the service (LAN) side of the vEdge router. When the interface for the master goes down, a new VRRP master virtual router is elected based on the VRRP priority value. Because VRRP runs on a LAN interface, if a vEdge 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 VRRP master virtual router:

    vEdge(config-vrrp)# track-omp

    If all OMP sessions are lost on the master 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 master. 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 VRRP master is elected, all overlay traffic is dropped. When the OMP session recovers, the local VRRP interface claims itself as master even before it learns and installs OMP routes from the 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 vEdge router:

    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 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 vEdge routers determine the VRRP master.

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. See the example configuration output below.

Here is an example of configuring VRRP on redundant physical interfaces. For subinterface 2, vEdge1 is configured to act as the master, and for subinterface 3, vEdge2 acts as the master.

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.2
   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.12
   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 VRRP master, 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  -       -

Configure PPPoE

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

To configure PPPoE client on a vEdge router, 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 vEdge router, and you can link a physical interface to only one PPP interface. To enable more than one PPPoE interface on a vEdge router, configure multiple PPP interfaces.

You configure quality of service (QoS) and shaping rate on a PPPoE-enabled physical interface, rather than 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 Viptela implementation of PPPoE does not support the Compression Control Protocol (CCP) options, as defined in RFC 1962.

Configure PPPoE from vManage Templates

To use vManage templates to configure PPPoE on vEdge routers, you create three feature templates and one device template:

  • Create a VPN-Interface-PPP feature template to configure PPP parameters for the PPP virtual interface.
  • Create a VPN-Interface-PPP-Ethernet feature template to configure a PPPoE-enabled interface.
  • Optionally, create a VPN feature template to modify the default configuration of VPN 0.
  • Create a device template that incorporates the VPN-Interface-PPP, VPN-Interface-PPP-Ethernet, and VPN feature templates.

To create a VPN-Interface-PPP feature template to configure PPP parameters for the PPP virtual interface:

  1. In vManage NMS, select the Configuration ► Templates screen.
  2. From the Templates title bar, select Feature.
  3. Click Add Template.
  4. In the left pane, select vEdge Cloud or a router model.
  5. In the right pane, select the VPN-Interface-PPP template.
  6. In the template, configure the following parameters:
    Parameter Field Procedure
    Template Name Enter a name for the template. It can be up to 128 alphanumeric characters.
    Description Enter a description for the template. It can be up to 2048 alphanumeric characters.
    Shutdown Click No to enable the PPP virtual interface.
    Interface Name Enter the number of the PPP interface. It can be from 1 through 31.
    Description (optional)

    Enter a description for the PPP virtual interface.

    Authentication Protocol Select either CHAP or PAP. For CHAP, enter the hostname and password provided by your ISP. For PAP, enter the username and password provided by your ISP.
    AC Name (optional) Select the PPP tab, and in the AC Name field, enter the name of the the name of the access concentrator used by PPPoE to route connections to the Internet.
    IP MTU Click the Advanced tab, and In the IP MTU field, ensure that the IP MTU is at least 8 bytes less than the MTU on the physical interface. The maximum MTU for a PPP interface is 1492 bytes. If the PPPoE server does not specify a maximum receive unit (MRU), the MTU value for the PPP interface is used as the MRU.
    Save Click Save to save the feature template.

To create a VPN-Interface-PPP-Ethernet feature template to enable the PPPoE client on the physical interfaces:

  1. In the vManage NMS, select the Configuration ► Templates screen.
  2. From the Templates title bar, select Feature.
  3. Click Add Template.
  4. In the left pane, select vEdge Cloud or a router model.
  5. In the right pane, select the VPN-Interface-PPP-Ethernet template.
  6. In the template, configure the following parameters:
    Parameter Field Procedure
    Template Name Enter a name for the template. It can be up to 128 alphanumeric characters.
    Description Enter a description for the template. It can be up to 2048 alphanumeric characters.
    Shutdown Click No to enable the PPPoE-enabled interface.
    Interface Name Enter the name of the physical interface in VPN 0 to associate with the PPP interface.
    Description (optional)

    Enter a description for the PPPoE-enabled interface.

    IP Confguration

    Assign an IP address to the physical interface:

    • To use DHCP, select Dynamic. The default administrative distance of routes learned from DHCP is 1.
    • To configure the IP address directly, enter of the IPv4 address of the interface.
    DHCP Helper (optional) Enter up to four IP addresses for DHCP servers in the network.
    Save Click Save to save the feature template.

To create a VPN feature template to configure the PPPoE-enabled interface in VPN 0, the transport VPN:

  1. In the vManage NMS, select the Configuration ► Templates screen.
  2. From the Templates title bar, select Feature.
  3. Click Add Template.
  4. In the left pane, select vEdge Cloud or a router model.
  5. In the right pane, select the VPN template.
  6. In the template, configure the following parameters:
    Parameter Field Procedure
    Template Name Enter a name for the template. It can be up to 128 alphanumeric characters.
    Description Enter a description for the template. It can be up to 2048 alphanumeric characters.
    VPN Identifier Enter VPN identifier 0.
    Name Enter aname for the VPN.
    Other interface parameters Configure the desired interface properties.
    Save Click Save to save the feature template.

To create a device template that incorporates the VPN-Interface-PPP, VPN-Interface-PPP-Ethernet, and VPN feature templates:

  1. In the vManage NMS, select the Configuration ► Templates screen.
  2. From the Templates title bar, select Device.
  3. Click Create Template, and from the drop-down list select From Feature Template.
  4. From the Device Model drop-down, select the type of device for which you are creating the device template. vManage NMS displays the feature templates for the device type you selected. Required templates are indicated with an asterisk (*).
  5. Enter a name and description for the device template. These fields are mandatory. The template name cannot contain special characters.
  6. In the Transport & Management VPN section, under VPN 0, from the drop-down list of available templates, select the desired feature template. The list of available templates are the ones that you have previously created.
  7. In the Additional VPN 0 Templates section to the right of VPN 0, click the plus sign (+) next to VPN Interface PPP.
  8. In the VPN-Interface-PPP and VPN-Interface-PPP-Ethernet fields, select the feature templates to use.
  9. To configure multiple PPPoE-enabled interfaces in VPN 0, click the plus sign (+) next to Sub-Templates.
  10. To include additional feature templates in the device template, in the remaining sections, select the feature templates in turn, and from the drop-down list of available templates, select the desired template. The list of available templates are the ones that you have previously created. Ensure that you select templates for all mandatory feature templates and for any desired optional feature templates.
  11. Click Create to create the device template.

To attach a device template to a device:

  1. In the vManage NMS, select the Configuration ► Templates screen.
  2. From the Templates title bar, select Device.
  3. Select a template.
  4. Click the More Actions icon to the right of the row and click Attach Device.
  5. In the Attach Device window, either search for a device or select a device from the Available Device(s) column to the left.
  6. Click the arrow pointing right to move the device to the Selected Device(s) column on the right.
  7. Click Attach.

Configure PPPoE from the CLI

To use the CLI to configure the PPPoE on vEdge routers:

  1. Create a PPP interface. The interface number can be from 1 through 31.
    vEdge(config-vpn-0)# interface pppnumber
  2. Configure an authentication method for PPPoE and authentication credentials:
    vEdge(config-interface-ppp)# ppp authentication chap hostname name password password
    vEdge(config-interface-ppp)# ppp authentication pap password password sent-username username
  3. Enable the PPP interface to be operationally up:
    vEdge(config-interface-ppp)# no shutdown
  4. Configure the MTU of the PPP interface. The maximum MTU for a PPP interface is 1492 bytes. If maximum receive unit (MRU) is not specified by the PPPoE server, the MTU value for the PPP interface is used as the MRU.
    vEdge(config-interface-ppp)# mtu bytes
  5. Configure a tunnel interface for the PPP interface:
    vEdge(config-interface-ppp)# tunnel-interface color color
  6. Optionally configure the name of the access concentrator used by PPPoE to route connections to the internet:
    vEdge(config-interface-ppp)# ac-name name
  7. Link a physical Gigabit Ethernet interface in VPN 0 to the PPP interface:
    vEdge(config-interface-ge)# pppoe-client ppp-interface pppnumber
  8. Enable the physical Gigabit Ethernet interface to be operationally up:
    viptela(config-vpn-interface-ge)# no shutdown

Here is an example of a PPPoE configuration:

vEdge# show running-config vpn 0
vpn 0
 interface ge0/1
  pppoe-client ppp-interface ppp10
  no shutdown
 !
 interface ppp10
  ppp authentication chap
   hostname branch100@corp.bank.myisp.net
   password $4$OHHjdmsC6M8zj4BgLEFXKw==
  !
  tunnel-interface
   encapsulation ipsec
   color gold
   no allow-service all
   no allow-service bgp
   allow-service dhcp
   allow-service dns
   allow-service icmp
   no allow-service ospf
   no allow-service sshd
   no allow-service ntp
   no allow-service stun
  !
  mtu      1492
  no shutdown
 !
!

To view existing PPP interfaces, use the show ppp interface command. For example:

vEdge# show ppp interface

             PPPOE      INTERFACE               PRIMARY  SECONDARY        
VPN  IFNAME  INTERFACE  IP         GATEWAY IP   DNS      DNS        MTU   
--------------------------------------------------------------------------
0    ppp10   ge0/1      11.1.1.1   115.0.1.100  8.8.8.8  8.8.4.4    1150  

To view PPPoE session information, use the show pppoe session command. For example:

vEdge# show pppoe session
 
             SESSION                                        PPP                    SERVICE  
VPN  IFNAME  ID       SERVER MAC         LOCAL MAC          INTERFACE  AC NAME     NAME     
--------------------------------------------------------------------------------------------
0    ge0/1   1        00:0c:29:2e:20:1a  00:0c:29:be:27:f5  ppp1       branch100  -        
0    ge0/3   1        00:0c:29:2e:20:24  00:0c:29:be:27:13  ppp2       branch100  -        

Configure Cellular Interfaces

To enable LTE connectivity, you configure cellular interfaces on vEdge routers that have 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.

When you configure a cellular interface on a vEdge router, you can connect the router to the Internet or other WAN simply by plugging in the router's power cable. The vEdge router then automatically begins the process of joining the overlay network, by contacting and authenticating with vBond orchestrators, vSmart controllers, and vManage NMSs.

In Releases 16.2.0 through 16.2.9, vEdge routers support only one radio access technology (RAT) type, which is LTE. In Releases 16.2.10 and later, vEdge routers support both LTE and CDMA RAT types.

To use the CLI to configure a cellular interface on a vEdge router that has a cellular module:

  1. Create a cellular profile:
    vEdge(config)# cellular cellularnumber
    vEdge(config-cellular)# profile profile-id

    Each router has only one LTE module, so number must be 0. The profile identifier can be a value from 1 through 15.
  2. If your ISP requires that you configure profile properties, configure one or more of the following:
    vEdge(config-profile)# apn name
    vEdge(config-profile)# auth auth-method
    vEdge(config-profile)# ip-addr ip-address
    vEdge(config-profile)# name name
    vEdge(config-profile)# pdn-type type
    vEdge(config-profile)# primary-dns ip-address
    vEdge(config-profile)# secondary-dns ip-address
    vEdge(config-profile)# user-name username
    vEdge(config-profile)# user-pass password
  3. Create the cellular interface:
    vEdge(config)# vpn 0 interface cellular0
  4. Enable the cellular interface:
    vEdge(confg-interface)# no shutdown
  5. For cellular interfaces, you must use a DHCP client to dynamically configure the IP address. This is the default option To explicitly configure this:
    vEdge(config-interface)# ip dhcp-client [dhcp-distance number]
    number is the administrative distance of routes learned from a DHCP server. You can configure it to a value from 1 through 255.
  6. Associate the cellular profile with the cellular interface:
    vEdge(config-interface)# profile profile-id
    The profile identifier is the number you configured in Step 1.
  7. Set the interface MTU to 1428 bytes:
    vEdge(config-interface)# mtu 1428
  8. By default, the radio access technology (RAT) type is LTE. For 2G/3G networks, change it to CDMA:
    vEdge(config-interface)# technology cdma
    If you are using the interface for ZTP, change the technology to auto:
    vEdge(config-interface)# technology auto
  9. Configure any other desired interface properties.
  10. Create a tunnel interface on the cellular interface:
    vEdge(config-interface)# tunnel-interface
    vEdge(config-tunnel-interface)# color color
    vEdge(config-tunnel-interface)# encapsulation (gre | ipsec)
  11. By default, the tunnel interface associated with a cellular interface is not considered to be the circuit of last resort. To allow the tunnel to be the circuit of last resort:
    vEdge(config-tunnel-interface)# last-resort-circuit
    When the interface is configured as a circuit of last resort, the cellular modem becomes dormant and no traffic is sent over the circuit. However, the cellular modem is kept in online mode so that the modem radio can be monitored at all times and to allow for faster switchover in the case the tunnel interface needs to be used as the last resort.
    By default, there is a delay of 7 seconds before switching back to the primary tunnel interface from a circuit of last resort. This delay is to ensure that the primary interface is once again fully operational and is not still flapping.
  12. To minimize the amount of control plane keepalive traffic on the cellular interface, increase the Hello packet interval and tolerance on the tunnel interface:
    vEdge(config-tunnel-interface)# hello-interval milliseconds
    vEdge(config-tunnel-interface)# hello-tolerance seconds

    The default hello interval is 1000 milliseconds, and it can be a time in the range 100 through 600000 milliseconds (10 minutes). The default hello tolerance is 12 seconds, and it can be a time in the range 12 through 600 seconds (10 minutes). To reduce outgoing control packets on a TLOC, it is recommended that on the tunnel interface you set the hello interface to 60000 milliseconds (10 minutes) and the hello tolerance to 600 seconds (10 minutes) and include the no track-transport disable regular checking of the DTLS connection between the router and the vBond orchestrator.
    For a tunnel connection between a vEdge router and any controller device, the tunnel uses the hello interval and tolerance times configured on the router. This choice is made to minimize the amount traffic sent over the tunnel, to allow for situations where the cost of a link is a function of the amount of traffic traversing the link. The hello interval and tolerance times are chosen separately for each tunnel between a vEdge router and a controller device.
    Another step taken to minimize the amount of control plane traffic is to not send or receive OMP control traffic over a cellular interface when other interfaces are available. This behavior is inherent in the software and is not configurable.
  13. Configure any other desired tunnel interface properties.
  14. To minimize the amount of extraneous traffic on a cellular interface that is a circuit of last resort, increase the BFD Hello packet interval and disable PMTU discovery.
    To minimize the amount of data plane keepalive traffic on the cellular interface, increase the BFD Hello packet interval. By default, BFD packets are send every 1000 milliseconds (1 second). You can increase this interval to a maximum of 300000 milliseconds (5 minutes):
    vEdge(bfd-color-lte)# hello-interval milliseconds
    By default, path MTU (PMTU) discovery is enabled on BFD tunnel connections. For PMTU, BFD periodically sends packets over the tunnel to check the PMTU size, about once per second. BFD does this checking regardless of the Hello packet interval. To suppress the sending of these packets, disable PMTU discovery:
    vEdge(bfd-color-lte)# no pmtu-discovery
    When PMTU discovery is disabled, the expected tunnel MTU is 1472 bytes, and the effective tunnel MTU is 1468 bytes.

To determine the status of the cellular hardware, use the show cellular status command.

To determine whether a vEdge has a cellular module, use the show hardware inventory command.

To determine whether a cellular interface is configure as a last-resort circuit, use the show control affinity config and show control local-properties commands.

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

Monitoring Bandwidth on a Transport Circuit

You can monitor the bandwidth usage on a transport circuit, to determine how the bandwidth usage is trending. If the bandwidth usage starts approaching a maximum value, you can configure the software to send a notification. Notifications are sent as Netconf notifications, which are sent to the 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 vEdge routers and on 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 (232 / 2) – 1 kbps.

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

  • Was this article helpful?