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

Segmentation (VPN) Configuration Examples

Some straightforward examples of creating and configuring VPNs to help you understand the configuration procedure for segmenting networks.

Create Basic VPNs

Creating the basic VPNs required by Viptela devices is a simple, straightforward process, consisting of these steps:

  1. On the vEdge router:
    —​ Create a VPN instance for the transport VPN. VPN 0 is reserved for the transport VPN.
    — Create a VPN instance for the management VPN. VPN 512 is reserved for the management VPN.
     Create a VPN instance to use for routing.
  2. On the vSmart controller:
    — Create a VPN instance for the transport VPN. VPN 0 is reserved for the transport VPN.
    — Create a VPN instance for the management VPN. VPN 512 is reserved for the management VPN.​
     Optionally, create policies to influence routing and access control within the VPN.

Configuration on the vEdge Router

To create the basic VPNs on a vEdge router, you configure VPN 0 for transport, VPN 512 for management, and a third VPN (here, VPN 1) for carrying data traffic:

  1. First, configure general system parameters:
    vEdge(config)# system host-name host-name
    vEdge(config-system)# system-ip ip-address
    vEdge(config-system)# domain-id domain-id
    vEdge(config-system)# site-id site-id
    vEdge(config-system)# vbond (dns-name ip-address)
  2. In VPN 0, which is the transport VPN, configure the interface to the WAN transport cloud, to establish reachability between the vEdge router and the vSmart controller, and between vEdge routers:
    1. Configure an IP address for the interface:
      vEdge(config)# vpn 0 interface interface-name ip address prefix/length
    2. Enable the interface:
      vEdge(config-interface)# no shutdown
    3. Enable a transport tunnel interface to carry control and data traffic, and configure the color and encapsulation for the tunnel:
      vEdge(config-interface)# tunnel-interface
      vEdge(config-tunnel-interface)# encapsulation (gre | ipsec)
      vEdge(config-tunnel-interface)# color color
    4. Configure a default route for the VPN:
      vEdge(config-vpn-0)# ip route 0.0.0.0/0 ip-address
  3. Configure a VPN for data traffic:
    1. Create the VPN and assign it a identifier number. The identifier can be any number except 0 and 512.
      vEdge(config)# vpn vpn-id
    2. Add an interface to the VPN:
      vEdge(config-vpn-number)# interface interface-name ip address ip-address
    3. Enable the interface:
      vEdge(config-vpn-number)# no shutdown
  4. Configure unixAR routing in the VPN. See Configuring Basic Unicast Overlay Routing for more information.
  5. Activate the configuration:
    vEdge(config)# commit

Here is the full configuration on the vEdge router:

system                             # Configure general system parameters           
 host-name vedge
 system-ip 1.0.0.2   
 domain-id 1
 site-id   20
 vbond 10.2.6.1
!
vpn 0                              # Create the tunnel interface and allow            
  interface ge 0/0                   reachability to vSmart in transport VPN
    ip address 10.2.6.11/24
    tunnel-interface
      color default
      encapsulation ipsec
   !
   no shutdown
   !
 ip route 0.0.0.0/0 10.2.6.12
!
vpn 1                              # Create new VPN, add interfaces and routing
 interface ge 0/1
  ip address 10.100.1.1/24
  no shutdown
 !
!
router
  bgp 20
   neighbor 10.100.1.2
    no shutdown
    remote-as 20
    address-family ipv4_unicast
    !
   !
  !
 !
vpn 512
  interface mgmt0
    ip dhcp-client
    no shutdown
  !
!

Configuration on the vSmart Controller

On the vSmart controller, you configure general system parameters and the two VPNs—​VPN 0 for WAN transport and VPN 512 for network management—​as you did for the vEdge router. Also, you generally create a centralized control policy that controls how the VPN traffic is propagated through the rest of the network. In this particular example, we create a central policy, shown below, to drop unwanted prefixes from propagating through the rest of the network. You can use a single vSmart policy to enforce policies throughout the network.

Here are the steps for creating the control policy on the vSmart controller:

  1. Create a list of sites IDs for the sites where you want to drop unwanted prefixes:
    vSmart(config)# policy lists site-list 20-30 site-id 20
    vSmart(config-site-list-20-30)# site-id 30
  2. Create a prefix list for the prefixes that you do not want to propagate:
    vSmart(config)# policy lists prefix-list drop-list ip-prefix 10.200.1.0/24
  3. Create the control policy:
    vSmart(config)# policy control-policy drop-unwanted-routes sequence 10 match route prefix-list drop-list
    vSmart(config-match)# top
    vSmart(config)# policy control-policy drop-unwanted-routes sequence 10 action reject
    vSmart(config-action)# top
    vSmart(config)# policy control-policy drop-unwanted-routes sequence 10 default-action accept
    vSmart(config-default-action)# top
  4. Apply the policy to prefixes inbound to the vSmart controller:
    vSmart(config)# apply-policy site-list 20-30 control-policy drop-unwanted-routes in 

Here is the full policy configuration on the vSmart controller:

apply-policy
 site-list 20-30
  control-policy drop-unwanted-routes in
 !
!
policy
 lists
  site-list 20-30
   site-id 20
   site-id 30
  !
  prefix-list drop-list
   ip-prefix 10.200.1.0/24
  !
 !
 control-policy drop-unwanted-routes
  sequence 10
   match route
    prefix-list drop-list
   !
   action reject
   !
  !
  default-action accept
 !
!

Control VPN Membership

You can create VPNs just at the sites of interest and can then keep them hidden so that the rest of the network does not even know about them and the routes from them. Such a network design provides a great deal of traffic isolation and flexibility. However, there might be cases where the network administrator might want to explicitly disallow the creation of VPNs on the vEdge router. An example is in a B2B partnership, when the vEdge router is not located at the customer premise. For these situations, the network administrator can choose to allow only certain VPNs on these vEdge routers. Effectively, you are controlling membership in the VPN.

You control VPN membership policy at the vSmart controller. In the example here, you create a policy that explicitly disallows VPN 1 at sites 20 and 30:

apply-policy
 site-list 20-30
  vpn-membership disallow-vpn1
 !
!
policy
 lists
  site-list 20-30
   site-id 20
   site-id 30
  !
 !
 vpn-membership disallow-vpn1
  sequence 10
   match vpn-id 1
   action reject
   !
  !
  default-action accept
 !
!

Leak Routes across VPNs

In some situations it is desirable to leak routes from one VPN into another. Some examples include extranets, where you are making a portion of your intranet available to users outside your organization, B2B partnerships, and the network transition that occurs during a merger or acquisition. To leak routes across VPNs, you create a leaking control policy on the vSmart controller, a design that allows you to control route leaking from a central point in the network.

In this example, we create a control policy that allows an enterprise’s VPN to import routes from a VPN list. Specifically, we:

  • Create a control policy to match routes from a list of VPNs. Here, sequence 10 of the policy matches all routes from the VPNs of all business partners (BPs). The business partner VPN IDs are listed in the All-BPs list.
  • Accept routes that match this policy, and import the prefixes into a new VPN called Enterprise-BP.
  • Apply this policy towards the BP sites on vRoutes inbound to the vSmart controller.
policy
  lists
    site-list BP-Sites
      site-id 10
      site-id 20
    vpn-list All-BPs
      vpn 100
      vpn 101
    vpn-list Enterprise-BP
      vpn 200
  control-policy import-BPs-to-Enterprise
    sequence 10
     match route
      vpn-list All-BPs
     !
     action accept
      export-to vpn-list Enterprise-BP
      !
     !
    !
    default-action accept
   !
!
apply-policy
 site-list BP-Sites
  control-policy import-BPs-to-Enterprise in
 !

This policy matches all routes from all VPNs in the All-BPs VPN lists and populates these prefixes into the VPNs in the Enterprise-BP list. The routing table of the Enterprise-BP VPN will now contain all the prefixes of the BPs.

One advantage of importing routes in this way is access control. Keeping each BP in a separate VPN and creating an extranet policy ensures that the BPs cannot talk to each other. 

Allow Data Traffic Exchange across Private WANs

When the WAN network to which a vEdge router is connected is a private 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 the private colors, metro-ethernetmpls, and private1 through private6. Of these private colors, the WAN interfaces on the vEdge routers must be marked with the same color so that they can exchange data traffic.

Exchange Data Traffic within a Single Private WAN

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.

s00098.png

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 private 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

A variant of the topology illustrated above is the case in which a single vEdge router connects to two different private WANs, such as two different MPLS clouds provided by two different network carriers, or two different types of private WANs, as illustrated below. In this figure, the vEdge-1 router connects to one MPLS private WAN and one metro-Ethernet private WAN.

s00099.png

As in the previous example, you create loopback interfaces on the three routers. For vEdge-1, which connects to both of the private WANs, you create two loopback interfaces. For each one, you assign a color, as in the previous example. But you configure two more things: you assign a tag to identify the carrier, and you "bind" the loopback interface to the physical interface that connects to the private WAN. So, vEdge-1 has two loopback interfaces with these properties:

  • Loopback1 has the color mpls​, the carrier carrier2, and binds to physical interface ge0/1.  
  • Loopback 2 has the color metro-ethernet and the carrier carrier1​, and binds to physical interface ge0/0. 

The vEdge-2 router has a single loopback interface that connects to the MPLS private WAN. Its color is mpls, and its carrier is carrier2​. Both these properties match those on the loopback1 interface on vEdge-1. However, because vEdge-2 connects to only one private WAN, there is no need to bind its loopback interface to a physical interface.

Finally, vEdge-3 has a single loopback interface with color metro-ethernet and carrier carrier1, matching the properties configured on the vEdge-1 loopback2 interface.

On vEdge-1, the configuration in VPN 0 looks like this:

vpn 0
 interface ge0/0
  ip address 10.1.15.15/24
  no shutdown
 !
 interface loopback2
  ip address 172.16.15.15/24
  tunnel-interface
   color   metro-ethernet
   carrier carrier1
   bind    ge0/0
  !
  no shutdown
 !
 
 interface ge0/1
  ip address 10.1.17.15/24
  no shutdown
 !
 interface loopback1
  ip address 172.16.17.15/24
  tunnel-interface
   color   mpls
   carrier carrier2
   bind    ge0/1
  !
  no shutdown
!

If you need to apply control policy to a particular private network, use the match carrier option when creating the control policy.

Share a Common Service across Different VPNs

When services such as firewalls or load balances are spread across multiple VPNs, you can create a policy that forces traffic from one VPN to use the services in another VPN. See the service control examples in Service Chaining Configuration Examples.

  • Was this article helpful?