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

Configuring Network Interfaces

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.

This article describes how to configure the general properties of WAN transport and service-side network interfaces. For information about how to configure specific interface types and properties—including cellular interfaces, DHCP, PPPoE, VRRP, and WLAN interfaces—see the links in the Additional Information section at the end of this article.

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 or configure the interface to receive an IP address from DHCP, and mark it as a tunnel interface. The IP address can be either an IPv4 or IPv6 address. To enable dual stack, configure both address types. You can optionally associate a color with the tunnel.

Note: You can configure IPv6 addresses only on transport interfaces, that is, only in VPN 0.

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

Tunnel interfaces on vEdge routers must have an IP address, a color, and an encapsulation type. The IP address can be either an IPv4 or IPv6 address. To enable dual stack, configure both address types.

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

On 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 geslot/port, grenumber, ipsecnumber, loopbackstring, natpoolnumber, or pppnumber.

To enable the interface, include the no shutdown command.

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

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 eight tunnel interfaces. This means that each vEdge router can have up to eight 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 (for DHCPv4 and DHCPv6)

X

dns

X

https

X

icmp

X

X

X

netconf

X

ntp

X

ospf

X

sshd

X

X

X

stun X X X

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

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

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

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

vEdge(config)# policy implicit-acl-logging

When you enable implicit ACL logging, by default, the headers of all dropped packets are logged. It is recommended that you configure a limit to the number of packets logged with the policy log-frequency configuration command.

On a vEdge router, services that you configure on a tunnel interface act as implicit access lists (ACLs). If you apply a localized data policy on a tunnel interface by configuring an ACL with the policy access-list command, this ACL is an explicit ACL. For information about how packets packets matching both implicit and explict ACLs are handled, see Configuring Localized Data Policy for IPv4 or Configuring Localized Data Policy for IPv6.

For each transport tunnel on a vEdge router and for each encapsulation type on a single transport tunnel, the Viptela software creates a TLOC, which consists of the router' system IP address, the color, and the encapsulation. The OMP session running on the tunnel sends the TLOC, as a TLOC route, to the vSmart controller, which uses it to determine the overlay network topology and to determine the best paths for data traffic across the overlay network.

To display information about interfaces in the WAN transport VPN that are configured with IPv4 addresses, use the show interface command. For example:

vEdge# show interface vpn 0 
                                  IF      IF                                                                TCP                                   
                                  ADMIN   OPER    ENCAP                                      SPEED          MSS                 RX       TX       
VPN  INTERFACE  IP ADDRESS        STATUS  STATUS  TYPE   PORT TYPE  MTU   HWADDR             MBPS   DUPLEX  ADJUST  UPTIME      PACKETS  PACKETS  
--------------------------------------------------------------------------------------------------------------------------------------------------
0    ge0/1      10.0.5.21/24      Up      Up      null   transport  1500  00:0c:29:6c:30:c1  10     full    0       0:04:03:41  260025   260145   
0    ge0/2      -                 Down    Up      null   service    1500  00:0c:29:6c:30:cb  10     full    0       0:04:03:41  3506     1        
0    ge0/3      -                 Down    Up      null   service    1500  00:0c:29:6c:30:d5  10     full    0       0:04:03:41  260      1        
0    ge0/4      -                 Down    Up      null   service    1500  00:0c:29:6c:30:df  10     full    0       0:04:03:41  260      1        
0    ge0/5      -                 Down    Up      null   service    1500  00:0c:29:6c:30:e9  10     full    0       0:04:03:41  260      1        
0    ge0/6      10.0.7.21/24      Up      Up      null   service    1500  00:0c:29:6c:30:f3  10     full    0       0:04:03:41  265      2        
0    ge0/7      10.0.100.21/24    Up      Up      null   service    1500  00:0c:29:6c:30:fd  10     full    0       0:04:03:41  278      2        
0    system     172.16.255.21/32  Up      Up      null   loopback   1500  00:00:00:00:00:00  10     full    0       0:04:03:37  0        0

To display information for interfaces configured with IPv6 addresses, use the show ipv6 interface command. For example:

vEdge# show ipv6 interface vpn 0

                                         IF      IF                                                               TCP                                                                
                AF                       ADMIN   OPER    ENCAP                                     SPEED          MSS                 RX       TX                                    
VPN  INTERFACE  TYPE  IPV6 ADDRESS       STATUS  STATUS  TYPE   PORT TYPE  MTU  HWADDR             MBPS   DUPLEX  ADJUST  UPTIME      PACKETS  PACKETS  LINK LOCAL ADDRESS           
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
0    ge0/1      ipv6  2001::a00:1a0b/120 Up      Up      null   service    1500 00:0c:29:ab:b7:62  1000   full    1420    0:01:30:00  2        6        fe80::20c:29ff:feab:b762/64  
0    ge0/2      ipv6  2001::a00:50b/120  Up      Up      null   service    1500 00:0c:29:ab:b7:6c  1000   full    1420    0:01:30:00  21       5        fe80::20c:29ff:feab:b76c/64  
0    ge0/3      ipv6  fd00:1234::/16     Up      Up      null   service    1500 00:0c:29:ab:b7:76  1000   full    1420    0:01:08:33  0        8        fe80::20c:29ff:feab:b776/64  
0    ge0/4      ipv6  -                  Up      Up      null   service    1500 00:0c:29:ab:b7:80  1000   full    1420    0:01:30:00  18       5        fe80::20c:29ff:feab:b780/64  
0    ge0/5      ipv6  -                  Down    Up      null   service    1500 00:0c:29:ab:b7:8a  1000   full    1420    0:01:44:19  1        1        fe80::20c:29ff:feab:b78a/64  
0    ge0/6      ipv6  -                  Down    Up      null   service    1500 00:0c:29:ab:b7:94  1000   full    1420    0:01:44:19  0        1        fe80::20c:29ff:feab:b794/64  
0    ge0/7      ipv6  -                  Up      Up      null   service    1500 00:0c:29:ab:b7:9e  1000   full    1420    0:01:43:02  55       5        fe80::20c:29ff:feab:b79e/64  
0    system     ipv6  -                  Up      Up      null   loopback   1500 00:00:00:00:00:00  10     full    1420    0:01:29:31  0        0        -
0    loopback1  ipv6  2001::a00:6501/128 Up      Up      null   transport  1500 00:00:00:00:00:00  10     full    1420    0:03:49:09  0        0        -
0    loopback2  ipv6  2001::a00:6502/128 Up      Up      null   transport  1500 00:00:00:00:00:00  10     full    1420    0:03:49:05  0        0        -
0    loopback3  ipv6  2001::a00:6503/128 Up      Up      null   transport  1500 00:00:00:00:00:00  10     full    1420    0:03:49:01  0        0        -
0    loopback4  ipv6  2001::a00:6504/128 Up      Up      null   transport  1500 00:00:00:00:00:00  10     full    1420    0:03:48:54  0        0        -     

In the command output, a port type of "transport" indicates that the interface is configured as a tunnel interface, and a port type of "service" indicates that the interface is not configured as a tunnel interface and can be used for data plane traffic. The port type for the system IP address interface is "loopback".

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.

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 schemes 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 physical 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. (Note that you can configure the two routers themselves with different site identifiers.)

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 collocated 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 non-connected 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 TLOConly on a physical interface.

If one of the routers is connected to two WAN transports (such as the Internet and an MPLS network), create subinterfaces between the two routers, creating the tunnel on the subinterface. The subinterfaces on the two routers must be in the same subnet. Because you are using a subinterface, the interface's MTU must be at least 4 bytes less than the physical MTU.

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 Service-Side Interfaces for Carrying Data Traffic

On vEdge routers, the VPNs other than 0 and 512 are service-side VPNs, and the interfaces in these VPNs connect the router to service-side LANs and WLANs. These interfaces are the interfaces that carry data traffic between vEdge routers and sites across the overlay network. At a minimum, for these interfaces, you must configure an IPv4 address, and you must enable the interface:

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

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

vEdge(config)# vpn vpn-id
vEdge(config-vpn)# interface geslot/port
vEdge(config-interface)# ip secondary-address ipv4-address

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. If you shut down the subinterface with a shutdown command, the operational status remains up as long as the physical interface is up.

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.

You create a GRE tunnel by configuring a GRE interface. 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 (or source interface name) and a destination address defines a single GRE tunnel. Only one GRE tunnel can exist that uses a specific source address (or interface name) and destination address pair.

You can optionally configure an IP address for the GRE tunnel itself:

vEdge(config-interface-gre)# ip address ip-address

Because GRE tunnels are stateless, the only way for the local router to determine whether the remote end of the tunnel is up, is to periodically send keepalive messages over the tunnel. The keepalive packets are looped back to the sender, and receipt of these packets by the local router indicates that the remote GRE device is up. By default, the GRE interface sends keepalive packets every 10 seconds, and if it receives no response, retries 3 times before declaring the remote device to be down. You can modify these default values with the keepalive command:

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

The keepalive interval can be from 0 through 65535 seconds, and the number of retries can be from 0 through 255. If you configure an IP address for the GRE interface, that IP address generates the keepalive messages.

If the vEdge router sits behind a NAT and you have configured GRE encapsulation, you must disable keepalives, with a keepalive 0 0 command. (Note that you cannot disable keepalives by issuing a no keepalive command. This command returns the keepalive to its default settings of sending a keepalive packet every 10 seconds and retrying 3 times before declaring the remote device down.)

For GRE interfaces, you can configure only the following additional interface properties:

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

GRE interfaces do not support cFlowd traffic monitoring.

You can configure one or two GRE interfaces per service. When you configure two, the first interface is the primary GRE tunnel, and the second is the backup tunnel. All packets are sent only to the primary tunnel. If that tunnel fails, all packets are then sent to the secondary tunnel. If the primary tunnel comes back up, all traffic is moved back to the primary GRE tunnel.

You direct data traffic from the service VPN to the GRE tunnel in one of two ways: either with a GRE-specific static route or with a centralized data policy.

To create a GRE-specific static route in the service VPN (a VPN other than VPN 0 or VPN 512), use the ip gre-route command:

vEdge(config-vpn)# ip gre-route prefix vpn 0 interface 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, IDS, or TE, 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 2000 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

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?