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 either geslot/port or loopbacknumber.
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 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 |
| 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.
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 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 routers 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 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.
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 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. 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.
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:
- show interface—List data traffic transmitted and received on GRE tunnels.
- show tunnel gre-keepalives—List GRE keepalive traffic transmitted and received on GRE tunnels.
- show tunnel statistics—List both data and keepalive traffic transmitted and received on GRE tunnels.
The following figure illustrates an example of configuring a GRE tunnel in VPN 0, to allow traffic to be redirected to a service that is not located at the same site as the vEdge router. In this example, local traffic is directed to the GRE tunnel using a centralized data policy, which is configured on the vSmart controller.
The configuration looks like this:
vEdge# show running-config vpn 0
vpn 0
interface gre1
ip address 172.16.111.11/24
keepalive 60 10
tunnel-source 172.16.255.11
tunnel-destination 10.1.2.27
no shutdown
!
!
vEdge# show running-config vpn 1 service
vpn 1
service FW interface gre1
vSmart# show running-config policy
policy
lists
prefix-list for-firewall
ip-prefix 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.