Configuring Network Interfaces
In the Viptela overlay network, you configure network interfaces within individual VPNs. For each network interface, you can configure a number of interface-specific properties, such as DHCP clients and servers, VRRP, interface MTU and speed, and PPPoE
In the Viptela overlay network design, interfaces are associated with VPNs. The interfaces that participate in a VPN are configured and enabled in that VPN. Each interface can be present only in a single VPN.
At a high level, for an interface to be operational, you must configure an IP address for the interface and mark it as operational (no shutdown). In practice, you always configure additional parameters for each interface.
You can configure up to 512 interfaces on a Viptela device. This number includes physical interfaces, loopback interfaces, and subinterfaces.
Configure Interfaces in the WAN Transport VPN (VPN 0)
VPN 0 is the WAN transport VPN. This VPN handles all control plane traffic, which is carried over OMP sessions, in the overlay network. For a Viptela device to participate in the overlay network, at least one interface must be configured in VPN 0, and at least one interface must connect to a WAN transport network, such as the Internet or an MPLS or a metro Ethernet network. This WAN transport interface is referred to as a tunnel interface. At a minimum, for this interface, you must configure an IP address, enable the interface, and set it to be a tunnel interface.
To configure a tunnel interface on a vSmart controller or a vManage NMS, you create an interface in VPN 0, assign an IP address, and mark it as a tunnel interface. You can optionally associate a color with the tunnel.
vSmart(config)# vpn 0
vSmart(config-vpn-0)# interface interface-name
vSmart(config-interface)# ip address prefix/length
vSmart(config-interface)# no shutdown
vSmart(config-interface)# tunnel-interface
vSmart(config-tunnel-interface)# color color
vSmart(config-tunnel-interface)# [no] allow-service service
Tunnel interfaces on vEdge routers must have an IP address, a color, and an encapsulation type:
vEdge(config)# vpn 0
vEdge(config-vpn-0)# interface interface-name
vEdge(config-interface)# ip address prefix/length
vEdge(config-interface)# no shutdown
vEdge(config-interface)# tunnel-interface
vEdge(config-tunnel-interface)# color color [restrict]
vEdge(config-tunnel-interface) encapsulation (gre | ipsec)
vEdge(config-tunnel-interface)# [no] allow-service service
On vSmart controllers and vManage NMSs, interface-name can be either ethnumber or loopbacknumber. Because vSmart controllers and vManage NMSs participate only in the overlay network's control plane, the only VPN that you can configure on these devices is VPN 0, and hence all interfaces are present only in this VPN.
On vEdge routers, interface-name can be either geslot/port or loopbacknumber.
To enable the interface, include the no shutdown command.
For the tunnel interface, you can configure a static IPv4 address, or you can configure the interface to receive its address from a DHCP server.
Color is a Viptela software construct that identifies the transport tunnel. It can be 3g, biz-internet, blue, bronze, custom1, custom2, custom3, default, gold, green, lte, metro-ethernet, mpls, private1 through private6, public-internet, red, and silver. The colors metro-ethernet, mpls, and private1 through private6 are referred to as private colors, because they use private addresses to connect to the remote side vEdge router in a private network. You can use these colors in a public network provided that there is no NAT device between the local and remote vEdge routers.
To limit the remote TLOCs that the local TLOC can establish BFD sessions with, mark the TLOC with the restrict option. When a TLOC is marked as restricted, a TLOC on the local router establishes tunnel connections with a remote TLOC only if the remote TLOC has the same color.
On a vSmart controller or vManage NMS, you can configure one tunnel interface. On a vEdge router, you can configure up to seven tunnel interfaces. This means that each vEdge router can have up to seven TLOCs.
On vEdge routers, you must configure the tunnel encapsulation. The encapsulation can be either IPsec or GRE. For IPsec encapsulation, the default MTU is 1442 bytes, and for GRE it is 1468 bytes, These values are a function of overhead required for BFD path MTU discovery, which is enabled by default on all TLOCs. (For more information, see Configuring Control Plane and Data Plane High Availability Parameters.) You can configure both IPsec and GRE encapsulation by including two encapsulation commands under the same tunnel-interface command. On the remote vEdge router, you must configure the same tunnel encapsulation type or types so that the two routers can exchange data traffic. Data transmitted out an IPsec tunnel can be received only by an IPsec tunnel, and data sent on a GRE tunnel can be received only by a GRE tunnel. The Viptela software automatically selects the correct tunnel on the destination vEdge router.
A tunnel interface allows only DTLS, TLS, and, for vEdge routers, IPsec traffic to pass through the tunnel. To allow additional traffic to pass without having to create explicit policies or access lists, enable them by including one allow-service command for each service. You can also explicitly disallow services by including the no allow-service command. Note that services affect only physical interfaces. You can allow or disallow these services on a tunnel interface:
|
Service |
vEdge Router |
vManage NMS |
vSmart Controller |
|---|---|---|---|
|
all (Overrides any commands that allow or disallow individual services) |
X |
X |
X |
|
bgp |
X |
— |
— |
|
dhcp |
X |
— |
— |
|
dns |
X |
— |
— |
|
https |
— |
X |
— |
|
icmp |
X |
X |
X |
|
netconf |
— |
X |
— |
|
ntp |
X |
— |
— |
|
ospf |
X |
— |
— |
|
sshd |
X |
X |
X |
On a vEdge router, services that you configure on a tunnel interface act as implicit access lists (ACLs). If you explicitly configure ACLs on a tunnel interface, with the policy access-list command, the handling of packets matching both implicit and explict ACLs depends on the exact configuration. For more information, see Configuring Localized Data Policy.
For each transport tunnel on a vEdge router and for each encapsulation type on a single transport tunnel, the Viptela software creates a TLOC, which consists of the router's system IP address, the color, and the encapsulation. The OMP session running on the tunnel sends the TLOC, as a TLOC route, to the vSmart controller, which uses it to determine the overlay network topology and to determine the best paths for data traffic across the overlay network.
To display information about the configured interfaces in the WAN transport VPN, use the show interface command. For example:
vEdge# show interface vpn 0 IF IF TCP ADMIN OPER ENCAP SPEED MSS RX TX VPN INTERFACE IP ADDRESS STATUS STATUS TYPE PORT TYPE MTU HWADDR MBPS DUPLEX ADJUST UPTIME PACKETS PACKETS -------------------------------------------------------------------------------------------------------------------------------------------------- 0 ge0/1 10.0.5.21/24 Up Up null transport 1500 00:0c:29:6c:30:c1 10 full 0 0:04:03:41 260025 260145 0 ge0/2 - Down Up null service 1500 00:0c:29:6c:30:cb 10 full 0 0:04:03:41 3506 1 0 ge0/3 - Down Up null service 1500 00:0c:29:6c:30:d5 10 full 0 0:04:03:41 260 1 0 ge0/4 - Down Up null service 1500 00:0c:29:6c:30:df 10 full 0 0:04:03:41 260 1 0 ge0/5 - Down Up null service 1500 00:0c:29:6c:30:e9 10 full 0 0:04:03:41 260 1 0 ge0/6 10.0.7.21/24 Up Up null service 1500 00:0c:29:6c:30:f3 10 full 0 0:04:03:41 265 2 0 ge0/7 10.0.100.21/24 Up Up null service 1500 00:0c:29:6c:30:fd 10 full 0 0:04:03:41 278 2 0 system 172.16.255.21/32 Up Up null loopback 1500 00:00:00:00:00:00 10 full 0 0:04:03:37 0 0
In this output, a port type of "transport" indicates that the interface is configured as a tunnel interface, and a port type of "service" indicates that the interface is not configured as a tunnel interface and can be used for data plane traffic. The port type for the system IP address interface is "loopback".
Associate a Carrier Name with a Tunnel Interface
To associate a carrier name or private network identifier with a tunnel interface, use the carrier command. carrier-name can be default and carrier1 through carrier8:
Viptela(config)# vpn 0
Viptela(config-vpn-0)# interface interface-name
Viptela(config-interface)# tunnel-interface
Viptela(config-tunnel-interface)# carrier carrier-name
Limit Keepalive Traffic on a Tunnel Interface
By default, Viptela devices send a Hello packet once per second to determine whether the tunnel interface between two devices is still operational and to keep the tunnel alive. The combination of a hello interval and a hello tolerance determines how long to wait before declaring a DTLS or TLS tunnel to be down. The default hello interval is 1 second, and the default tolerance is 12 seconds. With these default values, if no Hello packet is received within 11 seconds, the tunnel is declared down at 12 seconds.
If the hello interval or the hello tolerance, or both, are different at the two ends of a DTLS or TLS tunnel, the tunnel chooses the interval and tolerance as follows:
- For a tunnel connection between two controller devices, the tunnel uses the lower hello interval and the higher tolerance interval for the connection between the two devices. (Controller devices are vBond controllers, vManage NMSs, and vSmart controllers.) This choice is made in case one of the controllers has a slower WAN connection. The hello interval and tolerance times are chosen separately for each pair of controller devices.
- For a tunnel connection between a vEdge router and any controller device, the tunnel uses the hello interval and tolerance times configured on the router. This choice is made to minimize the amount traffic sent over the tunnel, to allow for situations where the cost of a link is a function of the amount of traffic traversing the link. The hello interval and tolerance times are chosen separately for each tunnel between a vEdge router and a controller device.
To minimize the amount of keepalive traffic on a tunnel interface, increase the Hello packet interval and tolerance on the tunnel interface:
vEdge(config-tunnel-interface)# hello-interval milliseconds
vEdge(config-tunnel-interface)# hello-tolerance seconds
The default hello interval is 1000 milliseconds, and it can be a time in the range 100 through 600000 milliseconds (10 minutes). The default hello tolerance is 12 seconds, and it can be a time in the range 12 through 600 seconds (10 minutes). The hello tolerance interval must be at most one-half the OMP hold time. The default OMP hold time is 60 seconds, and you configure it with the omp timers holdtime command.
Limit the HTTPS Connections to a vManage Server
By default, a vManage application server accepts a maximum of 50 HTTPS connections from users in the overlay network. To modify the maximum number of HTTPS connections that can be established:
vManage(config)# vpn 0 interface interface-name tunnel-interface control-connections number
The number can be from 1 through 512.
Configure Multiple Tunnel Interfaces on a vEdge Router
On a vEdge router, you can configure up to eight tunnel interfaces in the transport interface (VPN 0). This means that each vEdge router can have up to eight TLOCs.
When a vEdge router has multiple TLOCs, each TLOC is preferred equally and traffic to each TLOC is weighted equally, resulting in ECMP routing. ECMP routing is performed regardless of the encapsulation used on the transport tunnel, so if, for example, a router has one IPsec and one GRE tunnel, with ECMP traffic is forwarded equally between the two tunnels. You can change the traffic distribution by modifying the preference or the weight, or both, associated with a TLOC. (Note that you can also affect or change the traffic distribution by applying a policy on the interface that affects traffic flow.)
vEdge(config)# vpn 0 vEdge(config-vpn-0)# interface interface-name vEdge(config-tunnel-interface) encapsulation (gre | ipsec) vEdge(config-encapsulation)# preference number vEdge(config-encapsulation)# weight number
The preference command controls the preference for directing traffic to a tunnel. The preference can be a value from 0 through 4294967295 (232 – 1), and the default value is 0. A higher value is preferred over a lower value.
When a vEdge router has two or more tunnels, if all the TLOCs have the same preference and no policy is applied that affects traffic flow, all the TLOCs are advertised into OMP. When the router transmits or receives traffic, it distributes traffic flows evenly among the tunnels, using ECMP.
When a vEdge router has two or more tunnels, if the TLOCs all have different preferences and no policy is applied that affects traffic flow, only the TLOC with the highest preference is advertised into OMP. When the router transmits or receives traffic, it sends the traffic only to the TLOC with the highest preference. When there are three or more tunnels and two of them have the same preference, traffic flows are distributed evenly between these two tunnels.
A remote vEdge router trying to reach one of these prefixes selects which TLOC to use from the set of TLOCs that have been advertised. So, for example, if a remote router selects a GRE TLOC on the local router, the remote router must have its own GRE TLOC to be able to reach the prefix. If the remote router has no GRE TLOC, it is unable to reach the prefix. If the remote router has a single GRE TLOC, it selects that tunnel even if there is an IPsec TLOC with a higher preference. If the remote router has multiple GRE TLOCs, it selects from among them, choosing the one with the highest preference or using ECMP among GRE TLOCs with equal preference, regardless of whether there is an IPsec TLOC with a higher preference.
The weight command controls how traffic is balanced across multiple TLOCs that have equal preferences values. The weight can be a value from 1 through 255, and the default is 1. When the weight value is higher, the router sends more traffic to the TLOC. You typically set the weight based on the bandwidth of the TLOC. When a router has two or more TLOCs, all with the highest equal preference value, traffic distribution is weighted according to the configured weight value. For example, if TLOC A has weight 10, and TLOC B has weight 1, and both TLOCs have the same preference value, then roughly 10 flows are sent out TLOC A for every 1 flow sent out TLOC B.
Configure Control Plane High Availability
A highly available Viptela network contains two or more vSmart controllers in each domain. A Viptela domain can have up to eight vSmart controllers, and each vEdge router, by default, connects to two of them. You change this value on a per-tunnel basis:
vEdge(config-tunnel-interface)# max-controllers number
When the number of vSmart controllers in a domain is greater than the maximum number of controllers that a domain's vEdge routers are allowed to connect to, the Viptela software load-balances the connections among the available vSmart controllers.
 |
Tip: To maximize the efficiency of the load-balancing among vSmart controllers, use sequential numbers when assigning system IP addresses to the vEdge routers in the domain. One example of a sequential numbering scheme is 172.1.1.1, 172.1.1.2, 172.1.1.3, and so forth. Another is 172.1.1.1, 172.1.2.1, 172.1.3.1, and so forth. |
Configure Other WAN Interface Properties
You can modify the distribution of data traffic across transport tunnels by applying a data policy in which the action sets TLOC attributes (IP address, color, and encapsulation) to apply to matching data packets. For more information, see Configuring Centralized Data Policy.
Configure the System Interface
For each Viptela device, you configure a system interface with the system system-ip command. The system interface's IP address is a persistent address that identifies the Viptela device. It is similar to a router ID on a regular router, which is the address used to identify the router from which packets originated.
Viptela(config)# system system-ip ipv4-address
Specify the system IP address as an IPv4 address in decimal four-part dotted notation. Specify just the address; the prefix length (/32) is implicit.
The system IP address can be any IPv4 address except for 0.0.0.0/8, 127.0.0.0/8, and 224.0.0.0/4, and 240.0.0.0/4 and later. Each device in the overlay network must have a unique system IP address. You cannot use this same address for another interface in VPN 0.
The system interface is placed in VPN 0, as a loopback interface named system. Note that this is not the same as a loopback address that you configure for an interface.
To display information about the system interface, use the show interface command. For example:
vEdge# show running-config system system-ip
system
system-ip 172.16.255.11
!
vEdge# show interface vpn 0
IF IF TCP
ADMIN OPER ENCAP SPEED MSS RX TX
VPN INTERFACE IP ADDRESS STATUS STATUS TYPE PORT TYPE MTU HWADDR MBPS DUPLEX ADJUST UPTIME PACKETS PACKETS
-----------------------------------------------------------------------------------------------------------------------------------------------
0 ge0/1 10.0.26.11/24 Up Up null service 1500 00:0c:29:ab:b7:62 1000 full 1420 0:10:32:16 1606 8
0 ge0/2 10.0.5.11/24 Up Up null transport 1500 00:0c:29:ab:b7:6c 1000 full 1420 0:10:32:16 307113 303457
0 ge0/3 - Down Up null service 1500 00:0c:29:ab:b7:76 1000 full 1420 0:10:47:49 1608 0
0 ge0/4 10.0.7.11/24 Up Up null service 1500 00:0c:29:ab:b7:80 1000 full 1420 0:10:32:16 1612 8
0 ge0/5 - Down Up null service 1500 00:0c:29:ab:b7:8a 1000 full 1420 0:10:47:49 1621 0
0 ge0/6 - Down Up null service 1500 00:0c:29:ab:b7:94 1000 full 1420 0:10:47:49 1600 0
0 ge0/7 10.0.100.11/24 Up Up null service 1500 00:0c:29:ab:b7:9e 1000 full 1420 0:10:47:31 3128 1165
0 system 172.16.255.11/32 Up Up null loopback 1500 00:00:00:00:00:00 10 full 1420 0:10:31:58 0 0
The system IP address is used as one of the attributes of the OMP TLOC. Each TLOC is uniquely identified by a 3-tuple comprising the system IP address, a color, and an encapsulation. To display TLOC information, use the show omp tlocs command.
For device management purposes, it is recommended as a best practice that you also configure the same system IP address on a loopback interface that is located in a service-side VPN that is an appropriate VPN for management purposes. You use a loopback interface because it is always reachable when the router is operational and when the overlay network is up. If you were to configure the system IP address on a physical interface, both the router and the interface would have to be up for the router to be reachable. You use a service-side VPN because it is reachable from the data center. Service-side VPNs are VPNs other than VPN 0 (the WAN transport VPN) and VPN 512 (the management VPN), and they are used to route data traffic.
Here is an example of configuring the system IP address on a loopback interface in VPN 1:
vEdge# config
Entering configuration mode terminal
vEdge(config)# vpn 1
vEdge(config-vpn-1)# interface loopback0 ip address 172.16.255.11/32
vEdge(config-vpn-1)# no shutdown
vEdge(config-interface-loopback0)# commit and-quit
Commit complete.
vEdge# show interface
IF IF TCP
ADMIN OPER ENCAP SPEED MSS RX TX
VPN INTERFACE IP ADDRESS STATUS STATUS TYPE PORT TYPE MTU HWADDR MBPS DUPLEX ADJUST UPTIME PACKETS PACKETS
--------------------------------------------------------------------------------------------------------------------------------------------------
0 ge0/1 10.0.26.11/24 Up Up null service 1500 00:0c:29:ab:b7:62 1000 full 1420 0:10:27:33 1597 8
0 ge0/2 10.0.5.11/24 Up Up null transport 1500 00:0c:29:ab:b7:6c 1000 full 1420 0:10:27:33 304819 301173
0 ge0/3 - Down Up null service 1500 00:0c:29:ab:b7:76 1000 full 1420 0:10:43:07 1599 0
0 ge0/4 10.0.7.11/24 Up Up null service 1500 00:0c:29:ab:b7:80 1000 full 1420 0:10:27:33 1603 8
0 ge0/5 - Down Up null service 1500 00:0c:29:ab:b7:8a 1000 full 1420 0:10:43:07 1612 0
0 ge0/6 - Down Up null service 1500 00:0c:29:ab:b7:94 1000 full 1420 0:10:43:07 1591 0
0 ge0/7 10.0.100.11/24 Up Up null service 1500 00:0c:29:ab:b7:9e 1000 full 1420 0:10:42:48 3118 1164
0 system 172.16.255.11/32 Up Up null loopback 1500 00:00:00:00:00:00 10 full 1420 0:10:27:15 0 0
1 ge0/0 10.2.2.11/24 Up Up null service 1500 00:0c:29:ab:b7:58 1000 full 1420 0:10:27:30 5734 4204
1 loopback0 172.16.255.11/32 Up Up null service 1500 00:00:00:00:00:00 10 full 1420 0:00:00:28 0 0
512 eth0 10.0.1.11/24 Up Up null service 1500 00:50:56:00:01:0b 1000 full 0 0:10:43:03 20801 14368
Extend the WAN Transport VPN
When two vEdge routers are collocated at a site that has only one WAN circuit, you can configure the vEdge router that is not connected to the circuit to be able to establish WAN transport tunnels through the other router's TLOCs. In this way, you extend the WAN transport VPN so that both routers can establish tunnel interfaces, and hence can establish independent TLOCs, in the overlay network.
The following figure illustrates a site with two vEdge routers. vEdge-2 has two WAN circuits, one to the Internet and a second to a private MPLS network, and so has two TLOCs. By itself, vEdge1 has no TLOCs. You can configure vEdge-2 to extend its WAN transport VPN to vEdge1 so that vEdge-1 can participate independently in the overlay network.
When you extend the WAN transport VPN, no BFD sessions are established between the two collated vEdge routers.
To extend the WAN transport VPN, you configure the interface between the two routers:
- For the router that is not connected to the circuit, you configure a standard tunnel interface in VPN 0.
- For the router that is physically connected to the WAN or private transport, you associate the physical interface that connects to the circuit, configuring this in VPN 0 but not in a tunnel interface.
To configure the non-connected router (vEdge-1 in the figure above), create a tunnel interface in VPN 0 on the physical interface to the connected router:
vEdge-1(config-vpn-0)# interface geslot/port
vEdge-1(config-interface)# ip address prefix/length
vEdge-1(config-interface)# no shutdown
vEdge-1(config-interface)# mtu number
vEdge-1(config-interface)# tunnel-interface
vEdge-1(config-tunnel-interface)# color color
For the router connected to the WAN or private transport (vEdge-2 in the figure above), configure the interface that connects to the unconnected router, again in VPN 0:
vEdge-2(config-vpn-0)# interface geslot/port
vEdge-2(config-interface)# ip address prefix/length
vEdge-2(config-interface)# tloc-extension geslot/port
vEdge-2(config-interface)# no shutdown
vEdge-2(config-interface)# mtu number
The physical interface in the interface command is the one that connects to the other router.
The tloc-extension command creates the binding between the non-connected router and the WAN or private network. In this command, you specify the physical interface that connects to the WAN or private network circuit.
If the circuit connects to a public network:
- Configure a NAT on the public-network-facing interface on the vEdge router. The NAT configuration is required because the two vEdge routers are sharing the same transport tunnel.
- Configure a static route on the non-connected router to the TLOC-extended interface on the router connected to the public network.
If the circuit connects to a private network, such as an MPLS network:
- Enable routing on the non-connected router so that the interface on the non-connected router is advertised into the private network.
- Depending on the routing protocol you are using, enable either OSPF or BGP service on the non-connected router interface so that routing between the non-connected and the connected routers comes up. To do this, use the allow-service command.
You cannot extend a TLOC configured on a loopback interface, that is, when you use a loopback interface to connect to the public or private network. You can extend a TLOC only on a physical interface.
If one of the routers is connected to two WAN transports (such as the Internet and an MPLS network), create subinterfaces between the two routers, creating the tunnel on the subinterface. The subinterfaces on the two routers must be in the same subnet. Because you are using a subinterface, the interface's MTU must be at least 4 bytes less than the physical MTU.
By default, routers at one site form BFD tunnels only with routers at remote sites. If you want the routers at the same site to form BFD tunnels between them, enable the formation of these tunnels:
vEdge(config)# system allow-same-site-tunnels
Here is a sample configuration that corresponds to the figure shown above. Because the router vEdge-2 connects to two transports, we create subinterfaces between the vEdge-1 and vEdge-2 routers. One subinterface binds to the Internet circuit, and the second one binds to the MPLS connection.
vEdge-1# show running-config vpn 0
interface ge0/2.101
ip address 101.1.19.15/24
mtu 1496
tunnel-interface
color lte
...
!
no shutdown
!
interface ge0/2.102
ip address 102.1.19.15/24
mtu 1496
tunnel-interface
color mpls
...
!
no shutdown
!
ip route 0.0.0.0/0 101.1.19.16
vEdge-2# show running-config vpn 0
interface ge0/0
ip address 172.16.255.2
tunnel-interface
color lte
...
!
no shutdown
!
interface ge0/3
ip address 172.16.255.16
tunnel-interface
color mpls
...
!
no shutdown
!
interface ge0/2.101
ip address 101.1.19.16/24
mtu 1496
tloc-extension ge0/0
no shutdown
!
interface ge0/2.102
ip address 102.1.19.16/24
mtu 1496
tloc-extension ge0/3
no shutdown
! For this example configuration, vEdge-1 establishes two control connections to each vSmart controller in the overlay network—one connection for the LTE tunnel and the second for the MPLS tunnel. These control connections are separate and independent from those established on vEdge-2. The following output shows the control connections on vEdge-1 in a network with two vSmart controllers:
vEdge-1# show control connections
PEER PEER CONTROLLER
PEER PEER PEER SITE DOMAIN PEER PRIVATE PEER PUBLIC GROUP
TYPE PROTOCOL SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT LOCAL COLOR STATE UPTIME NAME
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
vsmart dtls 172.16.255.19 100 1 10.0.5.19 12346 10.0.5.19 12346 lte up 0:00:18:43 default
vsmart dtls 172.16.255.19 100 1 10.0.5.19 12346 10.0.5.19 12346 mpls up 0:00:18:32 default
vsmart dtls 172.16.255.20 200 1 10.0.12.20 12346 10.0.12.20 12346 lte up 0:00:18:38 default
vsmart dtls 172.16.255.20 200 1 10.0.12.20 12346 10.0.12.20 12346 mpls up 0:00:18:27 default
You can verify that the two vEdge routers have established no BFD sessions between them. On vEdge-1, we see no BFD sessions to vEdge-2 (system IP address 172.16.255.16):
vEdge-1# show bfd sessions
SOURCE TLOC REMOTE TLOC DST PUBLIC DST PUBLIC DETECT TX TRANSI-
SYSTEM IP SITE ID STATE COLOR COLOR SOURCE IP IP PORT ENCAP MULTIPLIER INTERVAL(msec) UPTIME TIONS
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
172.16.255.11 100 up lte lte 101.1.19.15 10.0.101.1 12346 ipsec 20 1000 0:00:20:26 0
172.16.255.11 100 up lte 3g 101.1.19.15 10.0.101.2 12346 ipsec 20 1000 0:00:20:26 0
172.16.255.11 100 up lte gold 101.1.19.15 10.0.101.3 12346 ipsec 20 1000 0:00:20:26 0
172.16.255.11 100 up lte red 101.1.19.15 10.0.101.4 12346 ipsec 20 1000 0:00:20:26 0
172.16.255.11 100 up mpls lte 102.1.19.15 10.0.101.1 12346 ipsec 20 1000 0:00:20:26 0
172.16.255.11 100 up mpls 3g 102.1.19.15 10.0.101.2 12346 ipsec 20 1000 0:00:20:26 0
172.16.255.11 100 up mpls gold 102.1.19.15 10.0.101.3 12346 ipsec 20 1000 0:00:20:26 0
172.16.255.11 100 up mpls red 102.1.19.15 10.0.101.4 12346 ipsec 20 1000 0:00:20:26 0
172.16.255.14 400 up lte lte 101.1.19.15 10.1.14.14 12360 ipsec 20 1000 0:00:20:26 0
172.16.255.14 400 up mpls lte 102.1.19.15 10.1.14.14 12360 ipsec 20 1000 0:00:20:26 0
172.16.255.21 100 up lte lte 101.1.19.15 10.0.111.1 12346 ipsec 20 1000 0:00:20:26 0
172.16.255.21 100 up lte 3g 101.1.19.15 10.0.111.2 12346 ipsec 20 1000 0:00:20:26 0
172.16.255.21 100 up mpls lte 102.1.19.15 10.0.111.1 12346 ipsec 20 1000 0:00:20:26 0
172.16.255.21 100 up mpls 3g 102.1.19.15 10.0.111.2 12346 ipsec 20 1000 0:00:20:26 0
Configure Interfaces in the Management VPN (VPN 512)
On all Viptela devices, VPN 512 is used, by default, for out-of-band management, and its configuration is part of the factory-default configuration. The interface type for management interfaces is mgmt, and the initial address for the interface is 192.168.1.1.
Viptela# show running-config vpn 512 vpn 512 interface mgmt0 ip dhcp-client no shutdown ! !
To display information about the configured management interfaces, use the show interface command. For example:
vEdge# show interface vpn 512
IF IF TCP
ADMIN OPER ENCAP PORT SPEED MSS RX TX
VPN INTERFACE IP ADDRESS STATUS STATUS TYPE TYPE MTU HWADDR MBPS DUPLEX ADJUST UPTIME PACKETS PACKETS
--------------------------------------------------------------------------------------------------------------------------------------------
512 mgmt0 192.168.1.1/24 Up Up null service 1500 00:50:56:00:01:1f 1000 full 0 0:04:08:01 1131 608
Note that VPN 512 is not a routable VPN. If you need a routable management VPN, create a VPN with a number other than 512.
Configure Interfaces for Carrying Data Traffic
On vEdge routers, in VPNs other than 0 and 512, you configure the interfaces that carry data traffic between vEdge routers and sites across the overlay network. At a minimum, for these interfaces, you must configure an IP address, and you must enable it:
Viptela(config)# vpn number
Viptela(config-vpn-number)# interface geslot/port
Viptela(config-interface)# ip address prefix/length
Viptela(config-interface)# no shutdown
To display information about the configured data traffic interfaces, use the show interface command. For example:
vEdge# show interface vpn 1
IF IF TCP
ADMIN OPER ENCAP PORT SPEED MSS RX TX
VPN INTERFACE IP ADDRESS STATUS STATUS TYPE TYPE MTU HWADDR MBPS DUPLEX ADJUST UPTIME PACKETS PACKETS
---------------------------------------------------------------------------------------------------------------------------------------------
1 ge0/1 10.192.1.1/28 Up Up null service 1500 00:0c:bd:05:f0:84 100 full 0 1:05:44:07 399 331
1 loopback1 1.1.1.1/32 Up Up null service 1500 00:00:00:00:00:00 10 full 0 1:05:44:07 0 0
For some protocols, you specify an interface as part of the protocol's configuration. In these cases, the interface used by the protocol must be the same as one of the interfaces configured in the VPN. As example is OSPF, where you place interfaces in OSPF areas. In this example, the interface ge0/0 is configured in VPN 1, and this interface is configured to be in the OSPF backbone area:
vEdge# show running-config vpn 1
vpn 1
router
ospf
router-id 172.16.255.21
timers spf 200 1000 10000
redistribute static
redistribute omp
area 0
interface ge0/0
exit
exit
!
!
interface ge0/0
ip address 10.2.3.21/24
no shutdown
!
!
Configure Subinterfaces and VLANs
You can configure IEEE 802.1Q VLANs on vEdge routers. In such VLANs, physical interfaces are divided into subinterfaces. When you configure a subinterface, the interface name has the format geslot/port.vlan-number. The VLAN number, vlan-number, can be in the range 1 through 4094.
As with all interfaces, the subinterface must be activated, by configuring it with the no shutdown command.
To accommodate the 32-bit field added to packets by the 802.1Q protocol, you must also configure the MTU for VLAN subinterfaces to be at least 4 bytes smaller than the MTU of the physical interface. You do this using the mtu command. The default MTU on a physical interface is 1500 bytes by default, so the subinterface's MTU here can be no larger than 1496 bytes.
For subinterfaces to work, you must configure the physical interface in VPN 0 and activate it with a no shutdown command. If the physical interface goes down for any reason, all its subinterfaces also go down.
You can place the VLANs associated with a single physical interface into multiple VPNs. Each individual subinterface can be present only in a single VPN.
Here is an example of a minimal VLAN configuration. The VLANs are configured on subinterfaces ge0/6.2 and ge0/6.3 in VPN 1, and they are associated with the physical interface ge0/6 in VPN 0.
vEdge# show running-config vpn 1 vpn 1 interface ge0/6.2 mtu 1496 no shutdown ! interface ge0/6.3 mtu 1496 no shutdown ! ! vEdge# show running-config vpn 0 vpn 0 interface ge0/0 ip dhcp-client tunnel-interface encapsulation ipsec no allow-service all no allow-service bgp allow-service dhcp allow-service dns allow-service icmp no allow-serivce ospf no allow-service sshd no allow-service ntp no allow-service stun ! no shutdown ! interface ge0/6 ip address 57.0.1.15/24 no shutdown ! !
The output of the show interface command shows the physical interface and the subinterfaces. The Encap Type column shows that the subinterfaces are VLAN interfaces, and the MTU column shows that the physical interface has an MTU size of 1500 bytes, while the MTU of the subinterfaces is 1496 bytes, so 4 bytes less.
vEdge# show interface IF IF TCP ADMIN OPER ENCAP SPEED MSS RX TX VPN INTERFACE IP ADDRESS STATUS STATUS TYPE PORT TYPE MTU HWADDR MBPS DUPLEX ADJUST UPTIME PACKETS PACKETS -------------------------------------------------------------------------------------------------------------------------------------------------- 0 ge0/0 10.1.15.15/24 Up Up null transport 1500 00:0c:29:7d:1e:fe 10 full 0 0:04:32:28 289584 289589 0 ge0/1 10.1.17.15/24 Up Up null service 1500 00:0c:29:7d:1e:08 10 full 0 0:04:32:28 290 2 0 ge0/2 - Down Up null service 1500 00:0c:29:7d:1e:12 10 full 0 0:04:32:28 290 1 0 ge0/3 10.0.20.15/24 Up Up null service 1500 00:0c:29:7d:1e:1c 10 full 0 0:04:32:28 290 2 0 ge0/6 57.0.1.15/24 Up Up null service 1500 00:0c:29:7d:1e:3a 10 full 0 0:04:32:28 290 2 0 ge0/7 10.0.100.15/24 Up Up null service 1500 00:0c:29:7d:1e:44 10 full 0 0:04:32:28 300 2 0 system 172.16.255.15/32 Up Up null loopback 1500 00:00:00:00:00:00 10 full 0 0:04:32:27 0 0 1 ge0/4 10.20.24.15/24 Up Up null service 1500 00:0c:29:7d:1e:26 10 full 0 0:04:32:18 2015 1731 1 ge0/5 56.0.1.15/24 Up Up null service 1500 00:0c:29:7d:1e:30 10 full 0 0:04:32:18 290 3 1 ge0/6.2 10.2.2.3/24 Up Up vlan service 1490 00:0c:29:7d:1e:3a 10 full 0 0:04:32:18 0 16335 1 ge0/6.3 10.2.3.5/24 Up Up vlan service 1496 00:0c:29:7d:1e:3a 10 full 0 0:04:32:18 0 16335 512 eth0 10.0.1.15/24 Up Up null service 1500 00:50:56:00:01:0f 1000 full 0 0:04:32:21 3224 1950
Configure Loopback Interfaces
You can configure loopback interfaces in any VPN. Use the interface name format loopbackstring, where string can be any alphanumeric value and can include underscores (_) and hyphens (–). The total interface name, including the string "loopback", can be a maximum of 16 characters long. (Note that because of the flexibility of interface naming in the CLI, the interfaces lo0 and loopback0 are parsed as different strings and as such are not interchangeable. For the CLI to recognize as interface as a loopback interface, its name must start with the full string loopback.)
One special use of loopback interfaces is to configure data traffic exchange across private WANs, such as MPLS or metro Ethernet networks. To allow a vEdge router that is behind a private network to communicate directly over the private WAN with other vEdge routers, you direct data traffic to a loopback interface that is configured as a tunnel interface rather than to an actual physical WAN interface. For more information, see Configure Data Traffic Exchange across Private WANs in the Configuring Segmentation (VPNs) article.
Configure GRE Interfaces and Advertise Services To Them
When a service, such as a firewall, is available on a device that supports only GRE tunnels, you can configure a GRE tunnel on the vEdge router to connect to the remote device. You then advertise that the service is available via a GRE tunnel, and you direct the appropriate traffic to the tunnel either by creating centralized data policy or by configuring GRE-specific static routes.
GRE interfaces are logical interfaces, and you configure them just like any other physical interface. Because a GRE interface is a logical interface, you must bind it to a physical interface, as described below.
To configure a GRE tunnel interface to a remote device that is reachable through a transport network, configure the tunnel in VPN 0:
vEdge(config)# vpn 0 interface grenumber
vEdge(config-interface-gre)# (tunnel-source ip-address | tunnel-source-interface interface-name)
vEdge(config-interface-gre)# tunnel-destination ip-address
vEdge(config-interface-gre)# no shutdown
The GRE interface has a name in the format grenumber, where number can be from 1 through 255.
To configure the source of the GRE tunnel on the local device, you can specify either the IP address of the physical interface (in the tunnel-source command or the name of the physical interface (in the tunnel-source-interface command). Ensure that the physical interface is configured in the same VPN in which the GRE interface is located.
To configure the destination of the GRE tunnel, specify the IP address of the remote device in the tunnel-destination command.
The combination of a source address and a destination address defines a single GRE tunnel. Only one GRE tunnel can exist that uses a specific source address (or interface name) and destination address pair.
You can optionally configure an IP address for the GRE tunnel itself:
vEdge(config-interface-gre)# ip address ip-address
Because GRE tunnels are stateless, the only way for the local router to determine whether the remote end of the tunnel is up, is to periodically send keepalive messages over the tunnel. The keepalive packets are looped back to the sender, and receipt of these packets by the local router indicates that the remote GRE device is up. By default, the router sends keepalive packets every 10 seconds, and if it receives no response, retries 3 times before declaring the remote device to be down. You can modify these default values with the keepalive command:
vEdge(config-interface-gre)# keepalive seconds retries
The keepalive interval can be from 0 through 65535 seconds, and the number of retries can be from 0 through 255. If the vEdge router sits behind a NAT and you have configured GRE encapsulation, you must disable keepalives, with a keepalive 0 0 command. (Note that you cannot disable keepalives by issuing a no keepalive command. This command returns the keepalive to its default settings of sending a keepalive packet every 10 seconds and retrying 3 times before declaring the remote device down.)
For GRE interfaces, you can configure only the following additional interface properties:
vEdge(config-interface-gre)# clear-dont-fragment
vEdge(config-interface-gre)# description text
vEdge(config-interface-gre)# mtu bytes
vEdge(config-interface-gre)# tcp-mss-adjust
GRE interfaces do not support cFlowd traffic monitoring.
You can configure one or two GRE interfaces per service. When you configure two, the first interface is the primary GRE tunnel, and the second is the backup tunnel. All packets are sent only to the primary tunnel. If that tunnel fails, all packets are then sent to the secondary tunnel. If the primary tunnel comes back up, all traffic is moved back to the primary GRE tunnel.
You direct data traffic from the service VPN to the GRE tunnel in one of two ways: either with a GRE-specific static route or with a centralized data policy.
To create a GRE-specific static route in the service VPN (a VPN other than VPN 0 or VPN 512), use the ip gre-route command:
vEdge(config-vpn)# ip gre-route prefix vpn 0 interface grenumber [grenumber2]
This GRE-specific static route directs traffic from the specified prefix to the primary GRE interface, and optionally to the secondary GRE interface, in VPN 0. The OMP administrative distance of a GRE-specific static route is 5, and that for a regular static route (configured with the ip route command) is 0. For more information, see Unicast Overlay Routing Overview.
To direct the data traffic to the GRE tunnel using a centralized data policy is a two-part process: you advertise the service in the service VPN, and then you create a centralized data policy on the vSmart controller to forward matching traffic to that service.
To advertise the service, include the service command in the service VPN (a VPN other than VPN 0 or VPN 512):
vEdge(config-vpn)# service service-name interface grenumber [grenumber2]
The service name can be FW, IDP, or IDS, or a custom service name netsvc1 through netsvc4. The interface is the GRE interface in VPN 0 that is used to reach the service. If you have configured a primary and a backup GRE tunnel, list the two GRE interfaces (grenumber1 grenumber2) in the service command. Once you have configured a service as reachable a the GRE interface, you cannot delete the GRE interface from the configuration. To delete the GRE interface, you must first delete the service. You can, however, reconfigure the service itself, by modifying the service command.
Then, create a data policy on the vSmart controller that applies to the service VPN. In the action portion of the data policy, you must explicitly configure the policy to service the packets destined for the GRE tunnel. To do this, include the local option in the set service command:
vSmart(config-policy-data-policy-vpn-list-vpn-sequence)# action accept
vSmart(config-action-accept)# set service service-name local
If the GRE tunnel used to reach the service is down, packet routing falls back to using standard routing. To drop packets when a GRE tunnel to the service is unreachable, add the restrict option:
vSmart(config-policy-data-policy-vpn-list-vpn-sequence)# action accept
vSmart(config-action-accept)# set service service-name local restrict
To track GRE tunnels and their traffic, use the following commands:
- 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 1804 bytes.
To display an interface's MTU, use the show interface command.
For vBond, vManage, and vSmart devices, you can configure interfaces to use ICMP to perform path MTU (PMTU) discovery. When PMTU discovery is enabled, the device to automatically negotiates the largest MTU size that the interface supports in an attempt to minimize or eliminate packet fragmentation:
Viptela(config-vpn)# interface interface-name pmtu
On vEdge routers, the Viptela BFD software automatically performs PMTU discovery on each transport connection (that is, for each TLOC, or color). BFD PMTU discovery is enabled by default, and it is recommended that you use it and not disable it. To explicitly configure BFD to perform PMTU discovery, use the bfd color pmtu-discovery configuration command. However, you can choose to instead use ICMP to perform PMTU discovery:
vEdge(config-vpn)# interface interface-name pmtu
BFD is a data plane protocol and so does not run on vBond, vManage, and vSmart devices.
Configure Static ARP Table Entries
By default, vEdge routers respond to ARP requests only if the destination address of the request is on the local network. You can configure static ARP entries on a Gigabit Ethernet interface in any VPN to allow the router to respond to ARP requests even if the destination address of the request is not local to the incoming interface. The ARP entry maps an IP address to a MAC address.
Viptela(config-vpn)# interface interface-name arp ip ip-address mac mac-address
Configure DHCP
When you configure a tunnel interface on a vEdge router, a number of services are enabled by default on that interface, including DHCP.
A vEdge router can act as a DHCP server for the service-side network to which it is connected, and it can also act as a DHCP helper, forwarding requests for IP addresses from devices in the service-side network to a DHCP server that is in a different subnet on the service side of the vEdge router.
Enable DHCP on the WAN Interface
On a vEdge router's WAN interface—the interface configured as a tunnel interface in VPN 0, the transport VPN—DHCP is enabled by default. You can see this by using the details filter with the show running-config command. This command also shows that the DNS and ICMP services are enabled by default.
vm1# show running-config vpn 0 interface ge0/2 tunnel-interface | details vpn 0 interface ge0/2 tunnel-interface encapsulation ipsec weight 1 color lte control-connections carrier default no allow-service all no allow-service bgp allow-service dhcp allow-service dns allow-service icmp no allow-service ospf no allow-service sshd no allow-service ntp no allow-service stun ! ! !
Enabling DHCP on the router's WAN interface allows the device that actually connects the router to the transport network (such as a DSL router) to dynamically assign a DHCP address to the vEdge router. The DHCP service in VPN 0 affects the transport-side network.
Have a vEdge Router Be a DHCP Server
One or more service-side interfaces on vEdge router can act as a DHCP server, assigning IP addresses to hosts in the service-side network. To do this, configure this function on the interface that connects the vEdge router to the local site's network. At a minimum, you must configure the pool of IP addresses available for assigning to hosts:
vEdge(config-vpn)# interface geslot/port dhcp-server address-pool ip-address/prefix
vEdge(config-dhcp-server)#
You can exclude IP addresses that fall within the range of the DHCP address pool:
vEdge(config-dhcp-server)# exclude ip-address
To specify multiple individual addresses, list them in a single exclude command, separated by a space (for example, exclude 1.1.1.1 2.2.2.2 3.3.3.3). To specify a range of addresses, separate them with a hyphen (for example, exclude 1.1.1.1-1.1.1.10).
You can also statically assign IP addresses to a host:
vEdge(config-dhcp-server)# static-lease mac-address ip ip-address
By default, the DHCP server on a single interface can assign 254 DHCP leases, and each lease is valid for 24 hours. The offer of an IP address is valid indefinitely, until that DHCP server runs out of addresses to offer. You can modify these values:
vEdge(config-dhcp-server)# max-leases number
vEdge(config-dhcp-server)# lease-time seconds
vEdge(config-dhcp-server)# offer-time minutes
These values can range from 0 through (232 – 1).
The Viptela software supports DHCP server options that allow you to configure the IP addresses of a default gateway, DNS server, and TFTP server in the service-side network and the network mask of the service-side network:
vEdge(config-dhcp-server)# options default-gateway ip-address
vEdge(config-dhcp-server)# options dns-servers ip-address
vEdge(config-dhcp-server)# options domain-name domain-name
vEdge(config-dhcp-server)# options interface-mtu mtu
vEdge(config-dhcp-server)# options tftp-servers ip-address
Have a vEdge Router Be a DHCP Helper
One or more service-side interfaces on a vEdge router can be a DHCP helper. With this configuration, the interface forwards any broadcast BOOTP DHCP requests that it receives from hosts on the service-side network to the DHCP server or servers specified by the configured IP helper address (or addresses) and returns the assigned IP address to the requester.
When the DHCP server at the vEdge router's local site is on a different segment than the devices connected to the vEdge router or than the vEdge router itself. When configured as a DHCP helper, the vEdge interface forwards any broadcast BOOTP DHCP requests that it receives to the DHCP server specified by the configured IP helper address.
To configure an interface as a DHCP helper, configure the IP address of the DHCP server on the interface that connects to the local site's network:
vEdge(config-vpn)# interface geslot/port dhcp-helper ip-address
You can configure up to four IP addresses, and the addresses must be entered in a single dhcp-helper command.
Configure VRRP
The Virtual Router Redundancy Protocol (VRRP) provides redundant gateway service for switches and other IP end stations. In the Viptela software, you configure VRRP on an interface, and typically on a subinterface, within a VPN.
For a VRRP interface to operate, its physical interface must be configured in VPN 0:
vEdge(config-vpn-0)# interface ge-slot/port
vEdge(config-interface-ge)# no shutdown
For each VRRP interface (or subinterface), you assign an IP address and you place that interface in a VRRP group.
vEdge(config-vpn)# interface ge-slot/port.subinterface
vEdge(config-interface-ge)# ip address prefix/length
vEdge(config-interface-ge)# vrrp group-number
The group number identifies the virtual router. In a typical VRRP topology, two physical routers are configured to act as a single virtual router, so you configure the same group number on interfaces on both these routers.
For each virtual router ID, you must configure an IP address:
vEdge(config-vrrp)# ipv4 ip-address
Within each VRRP group, the vEdge router with the higher priority value is elected as master. By default, each virtual router IP address has a default master election priority of 100, so the router with the higher IP address is elected master. You can modify the priority value, setting it to a value from 1 through 254:
vEdge(config-vrrp)# priority number
The VRRP master periodically sends advertisement messages, indicating that it is still operating. If slave routers miss three consecutive VRRP advertisements, they assume that the master is down and elect a new master. By default, these messages are sent every second. You can change the VRRP advertisement time to be a value from 1 through 3600 seconds:
vEdge(config-vrrp)# timer seconds
By default, VRRP uses of the state of the interface on which it is running to determine which vEdge router is the master virtual router. This interface is on the service (LAN) side of the vEdge router. When the interface for the master goes down, a new VRRP master virtual router is elected based on the VRRP priority value. Because VRRP runs on a LAN interface, if a vEdge router loses all its WAN control connections, the LAN interface still indicates that it is up even though the router is functionally unable to participate in VRRP. To take WAN side connectivity into account for VRRP, you can configure one of the following:
- Track the Overlay Management Protocol (OMP) session running on the WAN connection when determining the VRRP master virtual router:
vEdge(config-vrrp)# track-omp
If all OMP sessions are lost on the master VRRP router, VRRP elects a new default gateway from among all the gateways that have one or more active OMP sessions even if the gateway chosen has a lower VRRP priority than the current master. With this option, VRRP failover occurs once the OMP state changes from up to down, which occurs when the OMP hold timer expires. (The default OMP hold timer interval is 60 seconds.) Until the hold timer expires and a new VRRP master is elected, all overlay traffic is dropped. When the OMP session recovers, the local VRRP interface claims itself as master even before it learns and installs OMP routes from the vSmart controllers. Until the routers are learned, traffic is also dropped. - Track both the OMP session and a list of remote prefixes. list-name is the name of a prefix list configured with the policy lists prefix-list command on the vEdge router:
vEdge(config-vrrp)# track-prefix-list list-name
If all OMP sessions are lost, VRRP failover occurs as described for the track-omp option. In addition, if reachability to all prefixes in the list is lost, VRRP failover occurs immediately, without waiting for the OMP hold timer to expire, thus minimizing the amount of overlay traffic is dropped while the vEdge routers determine the VRRP master.
As discussed above, the IEEE 802.1Q protocol adds 4 bytes to each packet's length. Hence, for packets to be transmitted, either increase the MTU size on the physical interface in VPN 0 (the default MTU is 1500 bytes) or decrease the MTU size on the VRRP interface. See the example configuration output below.
Here is an example of configuring VRRP on redundant physical interfaces. For subinterface 2, vEdge1 is configured to act as the master, and for subinterface 3, vEdge2 acts as the master.
vEdge1# show running-config vpn 1
vpn 1
interface ge0/6.2
ip address 10.2.2.3/24
mtu 1496
no shutdown
vrrp 2
ipv4 10.2.2.1
track-prefix-list vrrp-prefix-list1
!
!
interface ge0/6.3
ip address 10.2.3.5/24
mtu 1496
shutdown
vrrp 3
ipv4 10.2.3.11
track-prefix-list vrrp-prefix-list1
!
!
!
vEdge2# show running-config vpn 1
vpn 1
interface ge0/1.2
ip address 10.2.2.4/24
mtu 1496
no shutdown
vrrp 2
ipv4 10.2.2.2
track-prefix-list vrrp-prefix-list2
!
!
interface ge0/1.3
ip address 10.2.3.6/24
mtu 1496
no shutdown
vrrp 3
ipv4 10.2.3.12
track-prefix-list vrrp-prefix-list2
!
!
!
vEdge1# show interface vpn 1
IF IF TCP
ADMIN OPER ENCAP PORT SPEED MSS RX TX
VPN INTERFACE IP ADDRESS STATUS STATUS TYPE TYPE MTU HWADDR MBPS DUPLEX ADJUST UPTIME PACKETS PACKETS
-------------------------------------------------------------------------------------------------------------------------------------------
1 ge0/6.2 10.2.2.3/24 Up Up vlan service 1496 00:0c:29:ab:b7:94 10 full 0 0:00:05:52 0 357
1 ge0/6.3 10.2.3.5/24 Down Down vlan service 1496 00:0c:29:ab:b7:94 - - 0 - 0 0
vEdge1# show vrrp interfaces
MASTER TRACK PREFIX
GROUP VIRTUAL VRRP OMP ADVERTISEMENT DOWN PREFIX LIST
VPN IF NAME ID IP VIRTUAL MAC PRIORITY STATE STATE TIMER TIMER LAST STATE CHANGE TIME LIST STATE
----------------------------------------------------------------------------------------------------------------------------------------------
1 ge0/6.2 2 10.2.2.1 00:0c:29:ab:b7:94 100 master down 1 3 2015-05-01T20:09:37+00:00 - -
ge0/6.3 3 10.2.3.11 00:00:00:00:00:00 100 init down 1 3 0000-00-00T00:00:00+00:00 - -
In the following example, Router-1 is the VRRP master, because it has a higher priority value than Router 2:
Router-1# show running-config vpn 1
vpn 1
!
interface ge0/1.15
ip address 10.10.1.2/24
mtu 1496
no shutdown
vrrp 15
priority 110
track-omp
ipv4 10.20.23.1
!
!
!
Router-1# show vrrp vpn 1
MASTER TRACK PREFIX
GROUP VRRP OMP ADVERTISEMENT DOWN PREFIX LIST
VPN IF NAME ID VIRTUAL IP VIRTUAL MAC PRIORITY STATE STATE TIMER TIMER LAST STATE CHANGE TIME LIST STATE
---------------------------------------------------------------------------------------------------------------------------------------------------
1 ge0/1.1 1 10.20.22.1 00:0c:bd:08:79:a4 100 backup up 1 3 2016-01-13T03:10:55+00:00 - -
ge0/1.5 5 10.20.22.193 00:0c:bd:08:79:a4 100 backup up 1 3 2016-01-13T03:10:55+00:00 - -
ge0/1.10 10 10.20.22.225 00:0c:bd:08:79:a4 100 backup up 1 3 2016-01-13T03:10:55+00:00 - -
ge0/1.15 15 10.20.23.1 00:0c:bd:08:79:a4 110 master up 1 3 2016-01-13T03:10:56+00:00 - -
ge0/1.20 20 10.20.24.1 00:0c:bd:08:79:a4 100 backup up 1 3 2016-01-13T03:10:56+00:00 - -
ge0/1.25 25 10.20.25.1 00:0c:bd:08:79:a4 110 master up 1 3 2016-01-13T03:10:56+00:00 - -
ge0/1.30 30 10.20.25.129 00:0c:bd:08:79:a4 100 backup up 1 3 2016-01-13T03:10:56+00:00 - -
Router-1# show vrrp vpn 1 interfaces ge0/1.15 groups 15
MASTER TRACK PREFIX
GROUP VRRP OMP ADVERTISEMENT DOWN PREFIX LIST
ID VIRTUAL IP VIRTUAL MAC PRIORITY STATE STATE TIMER TIMER LAST STATE CHANGE TIME LIST STATE
----------------------------------------------------------------------------------------------------------------------------------
1 10.20.33.1 00:0c:bd:08:79:a4 110 master up 1 3 2016-01-13T03:10:56+00:00 - -
Router-2# show running-config vpn 1
vpn 1
!
interface ge0/1.15
ip address 10.10.1.3/24
mtu 1496
no shutdown
vrrp 15
track-omp
ipv4 10.20.23.1
!
!
!
Router-2# show vrrp vpn 1 interfaces groups
MASTER TRACK PREFIX
GROUP VRRP OMP ADVERTISEMENT DOWN PREFIX LIST
IF NAME ID VIRTUAL IP VIRTUAL MAC PRIORITY STATE STATE TIMER TIMER LAST STATE CHANGE TIME LIST STATE
----------------------------------------------------------------------------------------------------------------------------------------------
ge0/1.1 1 10.20.32.1 00:0c:bd:08:2b:a5 110 master up 1 3 2016-01-13T00:22:15+00:00 - -
ge0/1.5 5 10.20.32.193 00:0c:bd:08:2b:a5 110 master up 1 3 2016-01-13T00:22:15+00:00 - -
ge0/1.10 10 10.20.32.225 00:0c:bd:08:2b:a5 110 master up 1 3 2016-01-13T00:22:15+00:00 - -
ge0/1.15 15 10.20.33.1 00:0c:bd:08:2b:a5 100 backup up 1 3 2016-01-13T03:10:56+00:00 - -
ge0/1.20 20 10.20.34.1 00:0c:bd:08:2b:a5 110 master up 1 3 2016-01-13T00:22:16+00:00 - -
ge0/1.25 25 10.20.35.1 00:0c:bd:08:2b:a5 100 backup up 1 3 2016-01-13T03:10:56+00:00 - -
ge0/1.30 30 10.20.35.129 00:0c:bd:08:2b:a5 100 master up 1 3 2016-01-13T00:22:16+00:00 - -
Router-2# show vrrp vpn 100 interfaces groups 15
MASTER TRACK PREFIX
GROUP VRRP OMP ADVERTISEMENT DOWN PREFIX LIST
IF NAME ID VIRTUAL IP VIRTUAL MAC PRIORITY STATE STATE TIMER TIMER LAST STATE CHANGE TIME LIST STATE
--------------------------------------------------------------------------------------------------------------------------------------------
ge0/0.15 15 10.20.33.1 00:0c:bd:08:2b:a5 100 backup up 1 3 2016-01-13T03:10:56+00:00 - -
Configure PPPoE
The Point-to-Point Protocol over Ethernet (PPPoE) connects multiple users over an Ethernet local area network to a remote site through common customer premises equipment. PPPoE is commonly used in a broadband aggregation, such as by digital subscriber line (DSL). PPPoE provides authentication with the CHAP or PAP protocol. In the Viptela overlay network, vEdge routers can run the PPPoE client. The PPPoE server component is not supported.
To configure PPPoE client on a vEdge router, you create a PPP logical interface and link it to a physical interface. The PPPoE connection comes up when the physical interface comes up. You can link a PPP interface to only one physical interface on a vEdge router, and you can link a physical interface to only one PPP interface. To enable more than one PPPoE interface on a vEdge router, configure multiple PPP interfaces.
You configure quality of service (QoS) and shaping rate on a PPPoE-enabled physical interface, rather than on the PPP interface.
PPPoE-enabled physical interfaces do not support:
- 802.1Q
- Subinterfaces
- NAT, PMTU, and tunnel interfaces. These are configured on the PPP interface and therefore not available on PPPoE-enabled interfaces.
The Viptela implementation of PPPoE does not support the Compression Control Protocol (CCP) options, as defined in RFC 1962.
Configure PPPoE from vManage Templates
To use vManage templates to configure PPPoE on vEdge routers, you create three feature templates and one device template:
- Create a VPN-Interface-PPP feature template to configure PPP parameters for the PPP virtual interface.
- Create a VPN-Interface-PPP-Ethernet feature template to configure a PPPoE-enabled interface.
- Optionally, create a VPN feature template to modify the default configuration of VPN 0.
- Create a device template that incorporates the VPN-Interface-PPP, VPN-Interface-PPP-Ethernet, and VPN feature templates.
To create a VPN-Interface-PPP feature template to configure PPP parameters for the PPP virtual interface:
- In vManage NMS, select the Configuration ► Templates screen.
- From the Templates title bar, select Feature.
- Click Add Template.
- In the left pane, select vEdge Cloud or a router model.
- In the right pane, select the VPN-Interface-PPP template.
- In the template, configure the following parameters:
Parameter Field Procedure Template Name Enter a name for the template. It can be up to 128 alphanumeric characters. Description Enter a description for the template. It can be up to 2048 alphanumeric characters. Shutdown Click No to enable the PPP virtual interface. Interface Name Enter the number of the PPP interface. It can be from 1 through 31. Description (optional) Enter a description for the PPP virtual interface.
Authentication Protocol Select either CHAP or PAP. For CHAP, enter the hostname and password provided by your ISP. For PAP, enter the username and password provided by your ISP. AC Name (optional) Select the PPP tab, and in the AC Name field, enter the name of the the name of the access concentrator used by PPPoE to route connections to the Internet. IP MTU Click the Advanced tab, and In the IP MTU field, ensure that the IP MTU is at least 8 bytes less than the MTU on the physical interface. The maximum MTU for a PPP interface is 1492 bytes. If the PPPoE server does not specify a maximum receive unit (MRU), the MTU value for the PPP interface is used as the MRU. Save Click Save to save the feature template.
To create a VPN-Interface-PPP-Ethernet feature template to enable the PPPoE client on the physical interfaces:
- In the vManage NMS, select the Configuration ► Templates screen.
- From the Templates title bar, select Feature.
- Click Add Template.
- In the left pane, select vEdge Cloud or a router model.
- In the right pane, select the VPN-Interface-PPP-Ethernet template.
- In the template, configure the following parameters:
Parameter Field Procedure Template Name Enter a name for the template. It can be up to 128 alphanumeric characters. Description Enter a description for the template. It can be up to 2048 alphanumeric characters. Shutdown Click No to enable the PPPoE-enabled interface. Interface Name Enter the name of the physical interface in VPN 0 to associate with the PPP interface. Description (optional) Enter a description for the PPPoE-enabled interface.
IP Confguration Assign an IP address to the physical interface:
- To use DHCP, select Dynamic. The default administrative distance of routes learned from DHCP is 1.
- To configure the IP address directly, enter of the IPv4 address of the interface.
DHCP Helper (optional) Enter up to four IP addresses for DHCP servers in the network. Save Click Save to save the feature template.
To create a VPN feature template to configure the PPPoE-enabled interface in VPN 0, the transport VPN:
- In the vManage NMS, select the Configuration ► Templates screen.
- From the Templates title bar, select Feature.
- Click Add Template.
- In the left pane, select vEdge Cloud or a router model.
- In the right pane, select the VPN template.
- In the template, configure the following parameters:
Parameter Field Procedure Template Name Enter a name for the template. It can be up to 128 alphanumeric characters. Description Enter a description for the template. It can be up to 2048 alphanumeric characters. VPN Identifier Enter VPN identifier 0. Name Enter aname for the VPN. Other interface parameters Configure the desired interface properties. Save Click Save to save the feature template.
To create a device template that incorporates the VPN-Interface-PPP, VPN-Interface-PPP-Ethernet, and VPN feature templates:
- In the vManage NMS, select the Configuration ► Templates screen.
- From the Templates title bar, select Device.
- Click Create Template, and from the drop-down list select From Feature Template.
- From the Device Model drop-down, select the type of device for which you are creating the device template. vManage NMS displays the feature templates for the device type you selected. Required templates are indicated with an asterisk (*).
- Enter a name and description for the device template. These fields are mandatory. The template name cannot contain special characters.
- In the Transport & Management VPN section, under VPN 0, from the drop-down list of available templates, select the desired feature template. The list of available templates are the ones that you have previously created.
- In the Additional VPN 0 Templates section to the right of VPN 0, click the plus sign (+) next to VPN Interface PPP.
- In the VPN-Interface-PPP and VPN-Interface-PPP-Ethernet fields, select the feature templates to use.
- To configure multiple PPPoE-enabled interfaces in VPN 0, click the plus sign (+) next to Sub-Templates.
- To include additional feature templates in the device template, in the remaining sections, select the feature templates in turn, and from the drop-down list of available templates, select the desired template. The list of available templates are the ones that you have previously created. Ensure that you select templates for all mandatory feature templates and for any desired optional feature templates.
- Click Create to create the device template.
To attach a device template to a device:
- In the vManage NMS, select the Configuration ► Templates screen.
- From the Templates title bar, select Device.
- Select a template.
- Click the More Actions icon to the right of the row and click Attach Device.
- In the Attach Device window, either search for a device or select a device from the Available Device(s) column to the left.
- Click the arrow pointing right to move the device to the Selected Device(s) column on the right.
- Click Attach.
Configure PPPoE from the CLI
To use the CLI to configure the PPPoE on vEdge routers:
- Create a PPP interface. The interface number can be from 1 through 31.
vEdge(config-vpn-0)# interface pppnumber - Configure an authentication method for PPPoE and authentication credentials:
vEdge(config-interface-ppp)# ppp authentication chap hostname name password password
vEdge(config-interface-ppp)# ppp authentication pap password password sent-username username - Enable the PPP interface to be operationally up:
vEdge(config-interface-ppp)# no shutdown - Configure the MTU of the PPP interface. The maximum MTU for a PPP interface is 1492 bytes. If maximum receive unit (MRU) is not specified by the PPPoE server, the MTU value for the PPP interface is used as the MRU.
vEdge(config-interface-ppp)# mtu bytes - Configure a tunnel interface for the PPP interface:
vEdge(config-interface-ppp)# tunnel-interface color color - Optionally configure the name of the access concentrator used by PPPoE to route connections to the internet:
vEdge(config-interface-ppp)# ac-name name - Link a physical Gigabit Ethernet interface in VPN 0 to the PPP interface:
vEdge(config-interface-ge)# pppoe-client ppp-interface pppnumber - Enable the physical Gigabit Ethernet interface to be operationally up:
viptela(config-vpn-interface-ge)# no shutdown
Here is an example of a PPPoE configuration:
vEdge# show running-config vpn 0 vpn 0 interface ge0/1 pppoe-client ppp-interface ppp10 no shutdown ! interface ppp10 ppp authentication chap hostname branch100@corp.bank.myisp.net password $4$OHHjdmsC6M8zj4BgLEFXKw== ! tunnel-interface encapsulation ipsec color gold no allow-service all no allow-service bgp allow-service dhcp allow-service dns allow-service icmp no allow-service ospf no allow-service sshd no allow-service ntp no allow-service stun ! mtu 1492 no shutdown ! !
To view existing PPP interfaces, use the show ppp interface command. For example:
vEdge# show ppp interface
PPPOE INTERFACE PRIMARY SECONDARY
VPN IFNAME INTERFACE IP GATEWAY IP DNS DNS MTU
--------------------------------------------------------------------------
0 ppp10 ge0/1 11.1.1.1 115.0.1.100 8.8.8.8 8.8.4.4 1150
To view PPPoE session information, use the show pppoe session command. For example:
vEdge# show pppoe session
SESSION PPP SERVICE
VPN IFNAME ID SERVER MAC LOCAL MAC INTERFACE AC NAME NAME
--------------------------------------------------------------------------------------------
0 ge0/1 1 00:0c:29:2e:20:1a 00:0c:29:be:27:f5 ppp1 branch100 -
0 ge0/3 1 00:0c:29:2e:20:24 00:0c:29:be:27:13 ppp2 branch100 -
Configure Cellular Interfaces
To enable LTE connectivity, you configure cellular interfaces on vEdge routers that have a cellular module. The cellular module provides wireless connectivity over a service provider's cellular network. One use case is to provide wireless connectivity for branch offices.
When you configure a cellular interface on a vEdge router, you can connect the router to the Internet or other WAN simply by plugging in the router's power cable. The vEdge router then automatically begins the process of joining the overlay network, by contacting and authenticating with vBond orchestrators, vSmart controllers, and vManage NMSs.
In Releases 16.2.0 through 16.2.9, vEdge routers support only one radio access technology (RAT) type, which is LTE. In Releases 16.2.10 and later, vEdge routers support both LTE and CDMA RAT types.
To use the CLI to configure a cellular interface on a vEdge router that has a cellular module:
- Create a cellular profile:
vEdge(config)# cellular cellularnumber
vEdge(config-cellular)# profile profile-id
Each router has only one LTE module, so number must be 0. The profile identifier can be a value from 1 through 15. - If your ISP requires that you configure profile properties, configure one or more of the following:
vEdge(config-profile)# apn name
vEdge(config-profile)# auth auth-method
vEdge(config-profile)# ip-addr ip-address
vEdge(config-profile)# name name
vEdge(config-profile)# pdn-type type
vEdge(config-profile)# primary-dns ip-address
vEdge(config-profile)# secondary-dns ip-address
vEdge(config-profile)# user-name username
vEdge(config-profile)# user-pass password - Create the cellular interface:
vEdge(config)# vpn 0 interface cellular0 - Enable the cellular interface:
vEdge(confg-interface)# no shutdown - For cellular interfaces, you must use a DHCP client to dynamically configure the IP address. This is the default option To explicitly configure this:
vEdge(config-interface)# ip dhcp-client [dhcp-distance number]
number is the administrative distance of routes learned from a DHCP server. You can configure it to a value from 1 through 255. - Associate the cellular profile with the cellular interface:
vEdge(config-interface)# profile profile-id
The profile identifier is the number you configured in Step 1. - Set the interface MTU to 1428 bytes:
vEdge(config-interface)# mtu 1428 - By default, the radio access technology (RAT) type is LTE. For 2G/3G networks, change it to CDMA:
vEdge(config-interface)# technology cdma
If you are using the interface for ZTP, change the technology to auto:
vEdge(config-interface)# technology auto - Configure any other desired interface properties.
- Create a tunnel interface on the cellular interface:
vEdge(config-interface)# tunnel-interface
vEdge(config-tunnel-interface)# color color
vEdge(config-tunnel-interface)# encapsulation (gre | ipsec) - By default, the tunnel interface associated with a cellular interface is not considered to be the circuit of last resort. To allow the tunnel to be the circuit of last resort:
vEdge(config-tunnel-interface)# last-resort-circuit
When the interface is configured as a circuit of last resort, the cellular modem becomes dormant and no traffic is sent over the circuit. However, the cellular modem is kept in online mode so that the modem radio can be monitored at all times and to allow for faster switchover in the case the tunnel interface needs to be used as the last resort.
By default, there is a delay of 7 seconds before switching back to the primary tunnel interface from a circuit of last resort. This delay is to ensure that the primary interface is once again fully operational and is not still flapping. - To minimize the amount of control plane keepalive traffic on the cellular interface, increase the Hello packet interval and tolerance on the tunnel interface:
vEdge(config-tunnel-interface)# hello-interval milliseconds
vEdge(config-tunnel-interface)# hello-tolerance seconds
The default hello interval is 1000 milliseconds, and it can be a time in the range 100 through 600000 milliseconds (10 minutes). The default hello tolerance is 12 seconds, and it can be a time in the range 12 through 600 seconds (10 minutes). To reduce outgoing control packets on a TLOC, it is recommended that on the tunnel interface you set the hello interface to 60000 milliseconds (10 minutes) and the hello tolerance to 600 seconds (10 minutes) and include the no track-transport disable regular checking of the DTLS connection between the router and the vBond orchestrator.
For a tunnel connection between a vEdge router and any controller device, the tunnel uses the hello interval and tolerance times configured on the router. This choice is made to minimize the amount traffic sent over the tunnel, to allow for situations where the cost of a link is a function of the amount of traffic traversing the link. The hello interval and tolerance times are chosen separately for each tunnel between a vEdge router and a controller device.
Another step taken to minimize the amount of control plane traffic is to not send or receive OMP control traffic over a cellular interface when other interfaces are available. This behavior is inherent in the software and is not configurable. - Configure any other desired tunnel interface properties.
- To minimize the amount of extraneous traffic on a cellular interface that is a circuit of last resort, increase the BFD Hello packet interval and disable PMTU discovery.
To minimize the amount of data plane keepalive traffic on the cellular interface, increase the BFD Hello packet interval. By default, BFD packets are send every 1000 milliseconds (1 second). You can increase this interval to a maximum of 300000 milliseconds (5 minutes):
vEdge(bfd-color-lte)# hello-interval milliseconds
By default, path MTU (PMTU) discovery is enabled on BFD tunnel connections. For PMTU, BFD periodically sends packets over the tunnel to check the PMTU size, about once per second. BFD does this checking regardless of the Hello packet interval. To suppress the sending of these packets, disable PMTU discovery:
vEdge(bfd-color-lte)# no pmtu-discovery
When PMTU discovery is disabled, the expected tunnel MTU is 1472 bytes, and the effective tunnel MTU is 1468 bytes.
To determine the status of the cellular hardware, use the show cellular status command.
To determine whether a vEdge has a cellular module, use the show hardware inventory command.
To determine whether a cellular interface is configure as a last-resort circuit, use the show control affinity config and show control local-properties commands.
Note: When you activate the configuration on a router with cellular interfaces, the primary interfaces (that is, those interfaces not configured as circuits of last resort) and the circuit of last resort come up. In this process, all the interfaces begin the process of establishing control and BFD connections. When one or more of the primary interfaces establishes a TLOC connection, the circuit of last resort shuts itself down because it is not needed. During this shutdown process, the circuit of last resort triggers a BFD TLOC Down alarm and a Control TLOC Down alarm on the vEdge router. These two alarms are cleared only when all the primary interfaces lose their BFD connections to remote nodes and the circuit of last resort activates itself. This generation and clearing of alarms is expected behavior.
Monitoring Bandwidth on a Transport Circuit
You can monitor the bandwidth usage on a transport circuit, to determine how the bandwidth usage is trending. If the bandwidth usage starts approaching a maximum value, you can configure the software to send a notification. Notifications are sent as Netconf notifications, which are sent to the vManage NMS, SNMP traps, and syslog messages. You might want to enable this feature for bandwidth monitoring, such as when you are doing capacity planning for a circuit or when you are gathering trending information about bandwidth utilization. You might also enable this feature to receive alerts regarding bandwidth usage, such as if you need to determine when a transport interface is becoming so saturated with traffic that a customer's traffic is impacted, or when customers have a pay-per-use plan, as might be the case with LTE transport.
To monitor interface bandwidth, you configure the maximum bandwidth for traffic received and transmitted on a transport circuit. The maximum bandwidth is typically the bandwidth that has been negotiated with the circuit provider. When bandwidth usage exceeds 85 percent of the configured value for either received or transmitted traffic, a notification, in the form of an SNMP trap, is generated. Specifically, interface traffic is sampled every 10 seconds. If the received or transmitted bandwidth exceeds 85 percent of the configured value in 85 percent of the sampled intervals in a continuous 5-minute period, an SNMP trap is generated. After the first trap is generated, sampling continues at the same frequency, but notifications are rate-limited to once per hour. A second trap is sent (and subsequent traps are sent) if the bandwidth exceeds 85 percent of the value in 85 percent of the 10-second sampling intervals over the next 1-hour period. If, after 1 hour, another trap is not sent, the notification interval reverts to 5 minutes.
You can monitor transport circuit bandwidth on vEdge routers and on vManage NMSs.
To generate notifications when the bandwidth of traffic received on a physical interface exceeds 85 percent of a specific bandwidth, configure the downstream bandwidth:
vEdge/vManage(config)# vpn vpn-id interface interface-name bandwidth-downstream kbps
To generate notifications when the bandwidth of traffic transmitted on a physical interface exceeds 85 percent of a specific bandwidth, configure the upstream bandwidth:
vEdge/vManage(config)# vpn vpn-id interface interface-name bandwidth-upstream kbps
In both configuration commands, the bandwidth can be from 1 through 2147483647 (232 / 2) – 1 kbps.
To display the configured bandwidths, look at the bandwidth-downstream and bandwidth-upstream fields in the output of the show interface detail command. The rx-kbps and tx-kbps fields in this command shows the current bandwidth usage on the interface.