Network Interface Configuration Examples
This article provides examples of configuring interfaces on vEdge routers to allow the flow of data traffic across both public and private WAN transport networks.
Connect to a Public WAN
This example shows a basic configuration for two vEdge routers connected to the same public WAN network (such as the Internet). The vSmart controller and vBond orchestrator are also connected to the public WAN network, and the vSmart controller is able to reach all destinations on the public WAN.
For vEdge-1, the interface ge0/1 connects to the public WAN, so it is the interface that is configured as a tunnel interface. The tunnel has a color of biz-internet, and the encapsulation used for data traffic is IPsec. The Viptela software creates a single TLOC for this interface, comprising the interface's IP address, color, and encapsulation, and the TLOC is sent to the vSmart controller over the OMP session running on the tunnel. The configuration also includes a default route to ensure that the router can reach the vBond orchestrator and vSmart controller.
vpn 0
interface ge0/1
ip address 172.16.13.3/24
tunnel-interface
encapsulation ipsec
color biz-internet
allow-service dhcp
allow-service dns
allow-service icmp
no allow-service sshd
no allow-service ntp
no allow-service stun
!
no shutdown
!
ip route 0.0.0.0/0 172.16.13.1
!
The configuration for vEdge-2 is similar to that for vEdge-1:
vpn 0
interface ge0/1
ip address 172.16.15.5/24
tunnel-interface
encapsulation ipsec
color biz-internet
allow-service dhcp
allow-service dns
allow-service icmp
no allow-service sshd
no allow-service ntp
no allow-service stun
!
no shutdown
!
ip route 0.0.0.0/0 172.16.15.1
!
On the vSmart controller and vBond orchestrator, you configure a tunnel interface and default IP route to reach the WAN transport. For the tunnel, color has no meaning because these devices have no TLOCs.
vpn 0
interface eth1
ip address 172.16.8.9/24
tunnel-interface
!
no shutdown
!
ip route 0.0.0.0/0 172.16.8.1
!
vpn 0
interface ge0/1
ip address 172.16.16.6/24
tunnel-interface
!
no shutdown
!
ip route 0.0.0.0/0 172.16.16.1
!
Use the show interface command to check that the interfaces are operational and that the tunnel connections have been established. In the Port Type column, tunnel connections are marked as "transport."
vEdge-1# show interface vpn 0
IF IF TCP
ADMIN OPER ENCAP SPEED MSS RX TX
VPN INTERFACE IP ADDRESS STATUS STATUS TYPE PORT TYPE MTU HWADDR MBPS DUPLEX ADJUST UPTIME PACKETS PACKETS
--------------------------------------------------------------------------------------------------------------------------------------------------
0 ge0/0 172.16.13.3/24 Up Up null transport 1500 00:0c:29:7d:1e:fe 10 full 0 0:02:26:20 88358 88202
0 ge0/1 10.1.17.15/24 Up Up null service 1500 00:0c:29:7d:1e:08 10 full 0 0:02:26:20 217 1
0 ge0/2 - Down Up null service 1500 00:0c:29:7d:1e:12 10 full 0 0:02:26:20 217 0
0 ge0/3 10.0.20.15/24 Up Up null service 1500 00:0c:29:7d:1e:1c 10 full 0 0:02:26:20 218 1
0 ge0/6 57.0.1.15/24 Up Up null service 1500 00:0c:29:7d:1e:3a 10 full 0 0:02:26:20 217 1
0 ge0/7 10.0.100.15/24 Up Up null service 1500 00:0c:29:7d:1e:44 10 full 0 0:02:25:02 850 550
0 system 172.16.255.3/32 Up Up null loopback 1500 00:00:00:00:00:00 10 full 0 0:02:13:31 0 0
Use the show control connections command to check that the vEdge router has a DTLS or TLS session established to the vSmart controller.
vEdge-1# show control connections
PEER PEER
PEER PEER PEER SITE DOMAIN PEER PRIVATE PEER PUBLIC
TYPE PROTOCOL SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT LOCAL COLOR STATE UPTIME
--------------------------------------------------------------------------------------------------------------------------------------------------------------
vsmart dtls 172.16.255.19 100 1 10.0.5.19 12346 10.0.5.19 12346 biz-internet up 0:02:13:13
vsmart dtls 172.16.255.20 200 1 10.0.12.20 12346 10.0.12.20 12346 biz-internet up 0:02:13:13
Use the show bfd sessions command to display information about the BFD sessions that have been established between the local vEdge router and remote routers:
vEdge-1# show bfd sessions
SOURCE TLOC REMOTE TLOC DST PUBLIC DST PUBLIC DETECT TX
SYSTEM IP SITE ID STATE COLOR COLOR SOURCE IP IP PORT ENCAP MULTIPLIER INTERVAL(msec) UPTIME TRANSITIONS
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
172.16.255.11 100 up biz-internet biz-internet 10.1.15.15 10.0.5.11 12346 ipsec 20 1000 0:02:24:59 1
172.16.255.14 400 up biz-internet biz-internet 10.1.15.15 10.1.14.14 12360 ipsec 20 1000 0:02:24:59 1
172.16.255.16 600 up biz-internet biz-internet 10.1.15.15 10.1.16.16 12346 ipsec 20 1000 0:02:24:59 1
172.16.255.21 100 up biz-internet biz-internet 10.1.15.15 10.0.5.21 12346 ipsec 20 1000 0:02:24:59 1
Use the show omp tlocs command to list the TLOCs that the local router has learned from the vSmart controller:
vEdge-1# show omp tlocs
C -> chosen
I -> installed
Red -> redistributed
Rej -> rejected
L -> looped
R -> resolved
S -> stale
Ext -> extranet
Inv -> invalid
ADDRESS PUBLIC PRIVATE BFD
FAMILY TLOC IP COLOR ENCAP FROM PEER STATUS PUBLIC IP PORT PRIVATE IP PORT STATUS
----------------------------------------------------------------------------------------------------------------------------------------
ipv4 172.16.255.11 biz-internet ipsec 172.16.255.19 C,I,R 10.0.5.11 12346 10.0.5.11 12346 up
172.16.255.20 C,R 10.0.5.11 12346 10.0.5.11 12346 up
172.16.255.14 biz-internet ipsec 172.16.255.19 C,I,R 10.1.14.14 12360 10.1.14.14 12360 up
172.16.255.20 C,R 10.1.14.14 12360 10.1.14.14 12360 up
172.16.255.16 biz-internet ipsec 172.16.255.19 C,I,R 10.1.16.16 12346 10.1.16.16 12346 up
172.16.255.20 C,R 10.1.16.16 12346 10.1.16.16 12346 up
172.16.255.21 biz-internet ipsec 172.16.255.19 C,I,R 10.0.5.21 12346 10.0.5.21 12346 up
172.16.255.20 C,R 10.0.5.21 12346 10.0.5.21 12346 up
Connect to Two Public WANs
In this example, two vEdge routers at two different sites connect to two public WANs, and hence each router has two tunnel connections. To direct traffic to the two different WANs, each tunnel interface is assigned a different color (here, silver and gold). Because each router has two tunnels, each router has two TLOCs.
A third router at a third site, vEdge-3, connects only to one of the public WANs.
The vSmart controller and vBond orchestrator are connected to one of the public WAN networks. (In reality, it does not matter which of the two networks they are connected to, nor does it matter whether the two devices are connected to the same network.) The vSmart controller is able to reach all destinations on the public WAN. To ensure that the vBond orchestrator is accessible via each transport tunnel on the routers, a default route is configured for each interface. In our example, we configure a static default route, but you can also use DHCP.
The configurations for vEdge-1 and vEdge-2 are similar. We configure two tunnel interfaces, one with color silver and the other with color gold, and we configure static default routes for both tunnel interfaces. Here is the configuration for vEdge-1:
vpn 0
interface ge0/1
ip address 172.16.13.3/24
tunnel-interface
encapsulation ipsec
color silver
!
no shutdown
!
interface ge0/2
ip address 10.10.23.3/24
tunnel-interface
encapsulation ipsec
color gold
!
no shutdown
!
ip route 0.0.0.0/0 172.16.13.1
ip route 0.0.0.0/0 10.10.23.1
The configuration for vEdge-2 is similar:
vpn 0
interface ge0/1
ip address 172.16.15.5/24
tunnel-interface
encapsulation ipsec
color silver
!
no shutdown
!
interface ge0/2
ip address 10.10.25.3/24
tunnel-interface
encapsulation ipsec
color gold
!
no shutdown
!
ip route 0.0.0.0/0 172.16.15.1
ip route 0.0.0.0/0 10.10.25.1
The third router, vEdge-3, connects only to one of the public WAN networks, and its tunnel interface is assigned the color "gold":
vpn 0
interface ge0/1
ip address 172.16.8.4/24
tunnel-interface
encapsulation ipsec
color gold
!
no shutdown
!
ip route 0.0.0.0/0 172.16.8.1
On the vSmart controller and vBond orchestrator, you configure a tunnel interface and default IP route to reach the WAN transport. For the tunnel, color has no meaning because these devices have no TLOCs.
vpn 0
interface eth1
ip address 172.16.8.9/24
tunnel-interface
!
no shutdown
ip route 0.0.0.0/0 172.16.8.1
vpn 0
interface ge0/1
ip address 172.16.16.6/24
tunnel-interface
!
no shutdown
ip route 0.0.0.0/0 172.16.16.1
Connect to Public and Private WANs, with Separation of Network Traffic
In this example, two vEdge routers at two different sites each connect to the same public WAN (here, the Internet) and the same private WAN (here, an MPLS network). We want to separate the MPLS network completely so that it is not reachable by the Internet. The vSmart controller and vBond orchestrator are hosted in the provider's cloud, which is reachable only via the Internet. A third vEdge router at a third site connects only to the public WAN (Internet).
In this example topology, we need to ensure the following:
- Complete traffic separation exists between private-WAN (MPLS) traffic and public-WAN (Internet) traffic.
- Each site (that is, each vEdge router) must have a connection to the Internet, because this is the only way that the overlay network can come up.
To maintain complete separation between the public and private networks so that all MPLS traffic stays within the MPLS network, and so that only public traffic passes over the Internet, we create two overlays, one for the private MPLS WAN and the second for the public Internet. For the private overlay, we want to create data traffic tunnels (which run IPsec and BFD sessions) between private-WAN TLOCs, and for the public overlay we want to create these tunnel connections between Internet TLOCs. To make sure that no data traffic tunnels are established between private-WAN TLOCs and Internet TLOCs, or vice versa, we associate the restrict attribute with the color on the private-WAN TLOCs. When a TLOC is marked as restricted, a TLOC on the local router establishes tunnel connections with a remote TLOC only if the remote TLOC has the same color. Put another way, BFD sessions come up between two private-WAN TLOCs and they come up between two public-WAN TLOCs, but they do not come up between an MPLS TLOC and an Internet TLOC.
Each site must have a connection to the public (Internet) WAN so that the overlay network can come up. In this topology, the vSmart controller and vBond orchestrator are reachable only via the Internet, but the MPLS network is completely isolated from the Internet. This means that if a vEdge router were to connect just to the MPLS network, it would never be able to discover the vSmart and vBond devices and so would never be able to never establish control connections in the overlay network. In order for a vEdge router in the MPLS network to participate in overlay routing, it must have at least one tunnel connection, or more specifically, one TLOC, to the Internet WAN. (Up to seven TLOCs can be configured on each vEdge router.) The overlay network routes that the router router learns over the public-WAN tunnel connection populate the routing table on the vEdge router and allow the router and all its interfaces and TLOCs to participate in the overlay network.
By default, all tunnel connections attempt to establish control connections in the overlay network. Because the MPLS tunnel connections are never going to be able to establish these connections to the vSmart or vBond devices, we include the max-control-connections 0 command in the configuration. While there is no harm in having the MPLS tunnels attempt to establish control connections, these attempts will never succeed, so disabling them saves resources on the vEdge router. Note that max-control-connections 0 command works only when there is no NAT device between the vEdge router and the PE router in the private WAN.
Connectivity to sites in the private MPLS WAN is possible only by enabling service-side routing.
Here is the configuration for the tunnel interfaces on vEdge-1. This snippet does not include the service-side routing configuration.
vpn 0
interface ge0/1
ip address 172.16.13.3/24
tunnel-interface
encapsulation ipsec
color biz-internet
!
no shutdown
!
interface ge0/2
ip address 10.10.23.3/24
tunnel-interface
encapsulation ipsec
color mpls restrict
max-control-connections 0
!
no shutdown
!
ip route 0.0.0.0/0 172.16.13.1
The configuration on vEdge-2 is quite similar:
vpn 0
interface ge0/1
ip address 172.16.15.5/24
tunnel-interface
encapsulation ipsec
color biz-internet
!
no shutdown
!
interface ge0/2
ip address 10.10.25.3/24
tunnel-interface
encapsulation ipsec
color mpls restrict
max-control-connections 0
!
no shutdown
!
ip route 0.0.0.0/0 172.16.15.1
!
The vEdge-3 router connects only to the public Internet WAN:
vpn 0
interface ge0/1
ip address 172.16.8.4/24
tunnel-interface
encapsulation ipsec
color biz-internet
!
no shutdown
!
ip route 0.0.0.0/0 172.16.8.1
!
On the vSmart controller and vBond orchestrator, you configure a tunnel interface and default IP route to reach the WAN transport. For the tunnel, color has no meaning because these devices have no TLOCs.
vpn 0
interface eth1
ip address 172.16.8.9/24
tunnel-interface
!
no shutdown
!
ip route 0.0.0.0/0 172.16.8.1
!
vpn 0
interface ge0/1
ip address 172.16.16.6/24
tunnel-interface
!
no shutdown
!
ip route 0.0.0.0/0 172.16.16.1
!
Connect to Public and Private WANs, with Ubiquitous Connectivity to Both WANs
This example is a variant of the previous example. We still have two vEdge routers at two different sites each connect to the same public WAN (here, the Internet) and the same private WAN (here, an MPLS network). However, now we want sites on the MPLS network and the Internet to be able to exchange data traffic. This topology requires a single overlay over both the public and private WANs. Control connections are present over both transports, and we want IPsec tunnel connections running BFD sessions to exist from private-WAN TLOCs to private-WAN TLOCs, from Internet TLOCs to Internet TLOCs, from private-WAN TLOCs to Internet TLOCs, and from Internet TLOCs to private-WAN TLOCs. This full possibility of TLOCs allows the establishment of a ubiquitous data plane in the overlay network.
For this configuration to work, the vBond orchestrator must be reachable over both WAN transports. Because it is on the public WAN (that is, on the Internet), there needs to be connectivity from the private WAN to the Internet. This could be provided via a DMZ, as shown in the figure above. The vSmart controller can be either on the public or the private LAN. If there are multiple controllers, some can be on public LAN and others on private LAN.
On each vEdge router, you configure private-WAN TLOCs, assigning a private color (metro-ethernet, mpls, or private1 through private6) to the tunnel interface. You also configure public TLOCs, assigning any other color (or you can leave the color as default). Each vEdge router needs two routes to reach the vBond orchestrator, one via the private WAN and one via the public WAN.
With such a configuration:
- Control connections are established over each WAN transport.
- BFD/IPsec comes up between all TLOCs (if no policy is configured to change this).
- A given site can be dual-homed to both WAN transports or single-homed to either one.
Here is an example of the configuration on one of the vEdge routers, vEdge-1:
vpn 0
interface ge0/1
description "Connection to public WAN"
ip address 172.16.31.3/24
tunnel-interface
encapsulation ipsec
color biz-internet
!
no shutdown
!
interface ge0/2
description "Connection to private WAN"
ip address 10.10.23.3/24
tunnel-interface
encapsulation ipsec
color mpls
!
no shutdown
!
ip route 0.0.0.0/0 10.10.23.1
ip route 0.0.0.0/0 172.16.13.1
!
The show control connections command lists two DTLS sessions to the vSmart controller, one from the public tunnel (color of biz-internet) and one from the private tunnel (color of mpls):
vEdge-1# show control connections
PEER PEER
PEER PEER PEER SITE DOMAIN PEER PRIVATE PEER PUBLIC
TYPE PROTOCOL SYSTEM IP ID ID PRIVATE IP PORT PUBLIC IP PORT LOCAL COLOR STATE UPTIME
--------------------------------------------------------------------------------------------------------------------------------------------------------------
vsmart dtls 1.1.1.9 900 1 172.16.8.2 12346 172.16.8.2 12346 mpls up 0:01:41:17
vsmart dtls 1.1.1.9 900 1 172.16.8.2 12346 172.16.8.2 12346 biz-internet up 0:01:41:33
The show bfd sessions command output shows that vEdge-1 has separate tunnel connections that are running separate BFD sessions for each color:
vEdge-1# show bfd sessions
SOURCE TLOC REMOTE TLOC DST PUBLIC DST PUBLIC DETECT TX
SYSTEM IP SITE ID STATE COLOR COLOR SOURCE IP IP PORT ENCAP MULTIPLIER INTERVAL(msec) UPTIME TRANSITIONS
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1.1.1.5 500 up mpls biz-internet 10.10.23.3 172.16.51.5 12346 ipsec 3 1000 0:06:07:19 1
1.1.1.5 500 up biz-internet biz-internet 172.16.31.3 172.16.51.5 12360 ipsec 3 1000 0:06:07:19 1
1.1.1.6 600 up mpls biz-internet 10.10.23.3 172.16.16.6 12346 ipsec 3 1000 0:06:07:19 1
1.1.1.6 600 up biz-internet biz-internet 172.16.31.3 172.16.16.6 12346 ipsec 3 1000 0:06:07:19 1
Exchange Data Traffic within a Single Private WAN
When the vEdge router is connected is a private WAN network, such as an MPLS or a metro Ethernet network, and when the carrier hosting the private network does not advertise the router's IP address, remote vEdge routers on the same private network but at different sites can never learn how to reach that router and hence are not able to exchange data traffic with it by going only through the private network. Instead, the remote routers must route data traffic through a local NAT and over the Internet to a vBond orchestrator, which then provides routing information to direct the traffic to its destination. This process can add significant overhead to data traffic exchange, because the vBond orchestrator may physically be located at a different site or a long distance from the two vEdge routers and because it may be situated behind a DMZ.
To allow vEdge routers at different overlay network sites on the private network to exchange data traffic directly using their private IP addresses, you configure their WAN interfaces to have one of eight private colors, metro-ethernet, mpls, and private1 through private6. Of these four colors, the WAN interfaces on the vEdge routers must be marked with the same color so that they can exchange data traffic.
To illustrate the exchange of data traffic across private WANs, let's look at a simple topology in which two vEdge routers are both connected to the same private WAN. The following figure shows that these two vEdge routers are connected to the same private MPLS network. The vEdge-1 router is located at Site 1, and vEdge-2 is at Site 2. Both routers are directly connected to PE routers in the carrier's MPLS cloud, and you want both routers to be able to communicate using their private IP addresses.
This topology requires a special configuration to allow traffic exchange using private IP addresses because:
- The vEdge routers are in different sites; that is, they are configured with different site IDs.
- The vEdge routers are directly connected to the PE routers in the carrier's MPLS cloud.
- The MPLS carrier does not advertise the link between the vEdge router and its PE router.
To be clear, if the situation were one of the following, no special configuration would be required:
- vEdge-1 and vEdge-2 are configured with the same site ID.
- vEdge-1 and vEdge-2 are in different sites, and the vEdge router connects to a CE router that, in turn, connects to the MPLS cloud.
- vEdge-1 and vEdge-2 are in different sites, the vEdge router connects to the PE router in the MPLS cloud, and the private network carrier advertises the link between the vEdge router and the PE router in the MPLS cloud.
- vEdge-1 and vEdge-2 are in different sites, and you want them to communicate using their public IP addresses.
In this topology, because the MPLS carrier does not advertise the link between the vEdge router and the PE router, you use a loopback interface on the each vEdge router to handle the data traffic instead of using the physical interface that connects to the WAN. Even though the loopback interface is a virtual interface, when you configure it on the vEdge router, it is treated like a physical interface: the loopback interface is a terminus for both a DTLS tunnel connection and an IPsec tunnel connection, and a TLOC is created for it.
This loopback interface acts as a transport interface, so you must configure it in VPN 0.
For the vEdge-1 and vEdge-2 routers to be able to communicate using their private IP addresses over the MPLS cloud, you set the color of their loopback interfaces to be the same and to one of eight special colors—metro-ethernet, mpls, and private1 through private6.
Here is the configuration on vEdge-1:
vedge-1(config)# vpn 0 vedge-1(config-vpn-0)# interface loopback1 vedge-1(config-interface-loopback1)# ip address 172.16.255.25/32 vedge-1(config-interface-loopback1)# tunnel-interface vedge-1(config-tunnel-interface)# color mpls vedge-1(config-interface-tunnel-interface)# exit vedge-1(config-tunnel-interface)# no shutdown vedge-1(config-tunnel-interface)# commit and-quit vedge-1# show running-config vpn 0 ... interface loopback1 ip-address 172.16.255.25/32 tunnel-interface color mpls ! no shutdown !
On vEdge-2, you configure a loopback interface with the same tunnel interface color that you used for vEdge-1:
vedge-2# show running-config vpn 0 vpn 0 interface loopback2 ip address 172. 17.255.26/32 tunnel-interface color mpls no shutdown !
Use the show interface command to verify that the loopback interface is up and running. The output shows that the loopback interface is operating as a transport interface, so this is how you know that it is sending and receiving data traffic over the private network.
vedge-1# show interface
IF IF TCP
ADMIN OPER ENCAP SPEED MSS RX TX
VPN INTERFACE IP ADDRESS STATUS STATUS TYPE PORT TYPE MTU HWADDR MBPS DUPLEX ADJUST UPTIME PACKETS PACKETS
--------------------------------------------------------------------------------------------------------------------------------------------------
0 ge0/0 10.1.15.15/24 Up Up null transport 1500 00:0c:29:7d:1e:fe 10 full 0 0:07:38:49 213199 243908
0 ge0/1 10.1.17.15/24 Up Up null service 1500 00:0c:29:7d:1e:08 10 full 0 0:07:38:49 197 3
0 ge0/2 - Down Down null service 1500 00:0c:29:7d:1e:12 - - 0 - 1 1
0 ge0/3 10.0.20.15/24 Up Up null service 1500 00:0c:29:7d:1e:1c 10 full 0 0:07:38:49 221 27
0 ge0/6 57.0.1.15/24 Up Up null service 1500 00:0c:29:7d:1e:3a 10 full 0 0:07:38:49 196 3
0 ge0/7 10.0.100.15/24 Up Up null service 1500 00:0c:29:7d:1e:44 10 full 0 0:07:44:47 783 497
0 loopback1 172.16.255.25/32 Up Up null transport 1500 00:00:00:00:00:00 10 full 0 0:00:00:20 0 0
0 system 172.16.255.15/32 Up Up null loopback 1500 00:00:00:00:00:00 10 full 0 0:07:38:25 0 0
1 ge0/4 10.20.24.15/24 Up Up null service 1500 00:0c:29:7d:1e:26 10 full 0 0:07:38:46 27594 27405
1 ge0/5 56.0.1.15/24 Up Up null service 1500 00:0c:29:7d:1e:30 10 full 0 0:07:38:46 196 2
512 eth0 10.0.1.15/24 Up Up null service 1500 00:50:56:00:01:05 1000 full 0 0:07:45:55 15053 10333
To allow vEdge routers at different overlay network sites on the private network to exchange data traffic directly, you use a loopback interface on the each vEdge router to handle the data traffic instead of using the physical interface that connects to the WAN. You associate the same tag, called a carrier tag, with each loopback interface so that all the routers learn that they are on the same private WAN. Because the loopback interfaces are advertised across the overlay network, the vEdge routers are able to learn reachability information, and they can exchange data traffic over the private network. To allow the data traffic to actually be transmitted out the WAN interface, you bind the loopback interface to a physical WAN interface, specifically to the interface that connects to the private network. Remember that this is the interface that the private network does not advertise. However, it is still capable of transmitting data traffic.
Exchange Data Traffic between Two Private WANs
This example shows a topology with two different private networks, possibly the networks of two different network providers, and all the Viptela devices are located somewhere on one or both of the private networks. Two vEdge routers are located at two different sites, and they both connect to both private networks. A third vEdge router connects to only one of the private WANs. The vBond orchestrator and vSmart controller both sit in one of the private WANs, perhaps in a data center, and they are reachable over both private WANs. For the vEdge routers to be able to establish control connections, the subnetworks where the vBond and vSmart devices reside must be advertised into each private WAN. Each private WAN CPE router then advertises these subnets in its VRF, and each vEdge router learns those prefixes from each PE router that it is connected to.
Because both WANs are private, we need only a single overlay. In this overlay network, without policy, IPsec tunnels running BFD sessions exist from any TLOC connected to either transport network to any TLOC in the other transport as well as to any TLOC in the same WAN transport network.
As with the previous examples in this article, it is possible to configure the tunnel interfaces on the routers' physical interfaces. If you do this, you also need to configure a routing protocol between the vEdge router at its peer PE router, and you need to configure access lists on the vEdge router to advertise all the routes in both private networks.
A simpler configuration option that avoids the need for access lists is to use loopback interfaces as the tunnel interfaces, and then bind each loopback interface to the physical interface that connects to the private network. Here, the loopback interfaces become the end points of the tunnel, and the TLOC connections in the overlay network run between loopback interfaces, not between physical interfaces. So in the figure shown above, on router vEdge-1, the tunnel connections originate at the Loopback1 and Loopback2 interfaces. This router has two TLOCs: {1.1.1.1, private2, ipsec} and {1.1.1.2, private1, ipsec}.
The WAN interfaces on the vEdge routers must run a routing protocol with their peer PE routers. The routing protocol must advertise the vEdge router's loopback addresses to both PE routers so that all vEdge routers on the two private networks can learn routes to each other. A simple way to advertise the loopback addresses is to redistribute routes learned from other (connected) interfaces on the same router. (You do this instead of creating access lists.) If, for example, you are using OSPF, you can advertise the loopback addresses by including the redistribute connected command in the OSPF configuration. Looking at the figure above, the ge0/2 interface on vEdge-1 needs to advertise both the Loopback1 and Loopback2 interfaces to the blue private WAN, and ge0/1 must advertise also advertise both these loopback interfaces to the green private WAN.
With this configuration:
- The vEdge routers learn the routes to the vBond orchestrator and vSmart controller over each private WAN transport.
- The vEdge routers learn every other vEdge router's loopback address over each WAN transport network.
- The end points of the tunnel connections between each pair of vEdge routers are the loopback interfaces, not the physical (ge) interfaces.
- The overlay network has data plane connectivity between any TLOCs and has a control plane over both transport networks.
Here is the interface configuration for VPN 0 on vEdge-1. Highlighted are the commands that bind the loopback interfaces to their physical interfaces. Notice that the tunnel interfaces, and the basic tunnel interface properties (encapsulation and color), are configured on the loopback interfaces, not on the Gigabit Ethernet interfaces.
vpn 0
interface loopback1
ip address 1.1.1.2/32
tunnel-interface
encapsulation ipsec
color private1
bind ge0/1
!
no shutdown
!
interface loopback2
ip address 1.1.1.1/32
tunnel-interface
encapsulation ipsec
color private2
bind ge0/2
!
no shutdown
!
interface ge0/1
ip address 172.16.13.3/24
no shutdown
!
interface ge0/2
ip address 10.10.23.3/24
no shutdown
!
ip route 0.0.0.0/0 10.10.23.1
ip route 0.0.0.0/0 172.16.13.1
!
The configuration for vEdge-2 is similar:
vpn 0
interface loopback1
ip address 2.2.2.1/32
tunnel-interface
encapsulation ipsec
color private1
bind ge0/1
!
no shutdown
!
interface loopback2
ip address 2.2.2.2/32
tunnel-interface
encapsulation ipsec
color private2
bind ge0/2
!
no shutdown
!
interface ge0/1
ip address 172.16.15.5/24
no shutdown
!
interface ge0/2
ip address 10.10.25.3/24
no shutdown
!
ip route 0.0.0.0/0 10.10.25.1
ip route 0.0.0.0/0 172.16.15.1
!
The vEdge-3 router connects only to the green private WAN:
vpn 0
interface loopback1
ip address 3.3.3.3/32
tunnel-interface
encapsulation ipsec
color private1
bind ge0/1
!
no shutdown
!
interface ge0/1
ip address 172.16.8.4/24
no shutdown
!
ip route 0.0.0.0/0 172.16.8.1
!
On the vSmart controller and vBond orchestrator, you configure a tunnel interface and default IP route to reach the WAN transport. For the tunnel, color has no meaning because these devices have no TLOCs.
vpn 0
interface eth1
ip address 172.16.8.9/24
tunnel-interface
!
no shutdown
!
ip route 0.0.0.0/0 172.16.8.1
!
vpn 0
interface ge0/1
ip address 172.16.16.6/24
tunnel-interface
!
no shutdown
!
ip route 0.0.0.0/0 172.16.16.1
!
Connect to a WAN Using PPPoE
This example shows a vEdge router with a TLOC tunnel interface and an interface enabled for Point-to-Point Protocol over Ethernet (PPPoE). The PPP interface defines the authentication method and credentials and is linked to the PPPoE-enabled interface.
Here is the interface configuration for VPN 0:
vpn 0 interface ge0/1 no shutdown ! tunnel-interface encapsulation ipsec color biz-internet allow-service dhcp allow-service dns allow-service icmp no allow-service sshd no allow-service ntp no allow-service stun ! no shutdown ! interface ge0/3 pppoe-client ppp-interface ppp10 no shutdown ! interface ppp10 ppp authentication chap hostname branch100@corp.bank.myisp.net password $4$OHHjdmsC6M8zj4BgLEFXKw== ! tunnel-interface encapsulation ipsec color gold allow-service dhcp allow-service dns allow-service icmp no allow-service sshd no allow-service ntp no allow-service stun ! no shutdown !
Use the show ppp interface command to view existing PPP interfaces:
vEdge# show ppp interface
PPPOE INTERFACE PRIMARY SECONDARY
VPN IFNAME INTERFACE IP GATEWAY IP DNS DNS MTU
--------------------------------------------------------------------------
0 ppp10 ge0/3 11.1.1.1 115.0.1.100 8.8.8.8 8.8.4.4 1150
Use the show ppppoe session and show pppoe statistics commands to view information about PPPoE sessions:
vEdge# show pppoe session
SESSION PPP SERVICE
VPN IFNAME ID SERVER MAC LOCAL MAC INTERFACE AC NAME NAME
--------------------------------------------------------------------------------------------
0 ge0/1 1 00:0c:29:2e:20:1a 00:0c:29:be:27:f5 ppp1 branch100 -
0 ge0/3 1 00:0c:29:2e:20:24 00:0c:29:be:27:13 ppp2 branch100 -
vEdge# show pppoe statistics
pppoe_tx_pkts : 73
pppoe_rx_pkts : 39
pppoe_tx_session_drops : 0
pppoe_rx_session_drops : 0
pppoe_inv_discovery_pkts : 0
pppoe_ccp_pkts : 12
pppoe_ipcp_pkts : 16
pppoe_lcp_pkts : 35
pppoe_padi_pkts : 4
pppoe_pado_pkts : 2
pppoe_padr_pkts : 2
pppoe_pads_pkts : 2
pppoe_padt_pkts : 2