README

== MPLS Layer3 VPN Example

=== Example Overview

This example illustrates Layer3 VPNs in a service provider MPLS
network. 

Caution! Please be advised that this example contains example NED's
and should not be used for production use.

The QOS part of the service implementation is not yet implemented for 
the Alcatel Lucent PE routers used in the example. 

==== Example Network

The example network consists of Cisco ASR 9k and Juniper core
routers (P and PE) and Cisco IOS based CE routers.

image:network.jpg[]

The Layer3 VPN service configures the CE/PE routers for all endpoints
in the VPN with BGP as the CE/PE routing protocol. Layer2 connectivity
between CE and PE routers are expected to be done through a Layer2
ethernet access network, which is out of scope for this example.

The Layer3 VPN service includes VPN connectivity as well as bandwidth
and QOS parameters.

=== External Policies

This example makes use of two different external policies. The
external policies in this example are modelled in YANG and
stored in NCS but not as a part of the actual service data model.

Having policy information that can be referenced by many service
instances can be very powerful. Changes in the network topology or in
a QOS policy could now be done in one place. NCS can then redeploy all
affected service instances and reconfigure the network. This will be
shown later in this example.


==== Topology

The service configuration only has references to CE devices for the
end-points in the VPN. The service mapping logic reads from a simple
topology model that is configuration data in NCS, outside the
actual service model, and derives what other network devices to
configure.

The topology information has two parts. The first part lists
connections in the network and is used by the service mapping logic to
find out which PE router to configure for an endpoint.

The snippets below show the configuration output in the Cisco style
NCS CLI.

----
topology connection c0
 endpoint-1 device ce0 interface GigabitEthernet0/8 ip-address 192.168.1.1/30
 endpoint-2 device pe0 interface GigabitEthernet0/0/0/3 ip-address 192.168.1.2/30
 link-vlan 88
!
topology connection c1
 endpoint-1 device ce1 interface GigabitEthernet0/1 ip-address 192.168.1.5/30
 endpoint-2 device pe1 interface GigabitEthernet0/0/0/3 ip-address 192.168.1.6/30
 link-vlan 77
!
----

The second part lists devices for each role in the network and is in
this example only used to dynamically render a network map in the
Web UI.

----
topology role ce
 device [ ce0 ce1 ce2 ce3 ce4 ce5 ]
!
topology role pe
 device [ pe0 pe1 pe2 pe3 ]
!
----

==== QOS
QOS configuration in service provider networks is complex, and often
require a lot of different variations. It is also often desirable to be
able to deliver different levels of QOS. This example shows how a QOS
policy configuration can be stored in NCS and be referenced from VPN
service instances.

Three different levels of QOS policies are defined; GOLD, SILVER and
BRONZE with different queueing parameters.

----
qos qos-policy GOLD
 class BUSINESS-CRITICAL
  bandwidth-percentage 20
 !
 class MISSION-CRITICAL
  bandwidth-percentage 20
 !
 class REALTIME
  bandwidth-percentage 20
  priority
 !
!
qos qos-policy SILVER
 class BUSINESS-CRITICAL
  bandwidth-percentage 25
 !
 class MISSION-CRITICAL
  bandwidth-percentage 25
 !
 class REALTIME
  bandwidth-percentage 10
 !
----

Three different traffic classes are also defined with a DSCP value
that will be used inside the MPLS core network as well as default
rules that will match traffic to a class.

----
qos qos-class BUSINESS-CRITICAL
 dscp-value af21
 match-traffic ssh
  source-ip      any
  destination-ip any
  port-start     22
  port-end       22
  protocol       tcp
 !
!
qos qos-class MISSION-CRITICAL
 dscp-value af31
 match-traffic call-signaling
  source-ip      any
  destination-ip any
  port-start     5060
  port-end       5061
  protocol       tcp
 !
!
----

=== Running The Example in the CLI

Make sure you start clean, i.e. no old configuration data is present.
If you have been running this or some other example before, make sure
to stop any NCS or simulated network nodes (ncs-netsim) that you may have
running.  Output like 'connection refused (stop)' means no previous
NCS was running and 'DEVICE ce0 connection refused (stop)...' no
simulated network was running, which is good.

----
make stop clean all start
ncs_cli -u admin -C
----

This will setup the environment and start the simulated network.

==== VPN Service Configuration in the CLI

Before creating a new L3VPN service we must sync the configuration
from all network devices and then enter config mode.

----
devices sync-from
----

Lets start by configuring a VPN network.

----
config
top
!
vpn l3vpn volvo
route-distinguisher 999
endpoint main-office
ce-device    ce6
ce-interface GigabitEthernet0/11
ip-network   10.10.1.0/24
as-number    65101
bandwidth    12000000
!
endpoint branch-office1
ce-device    ce1
ce-interface GigabitEthernet0/11
ip-network   10.7.7.0/24
as-number    65102
bandwidth    6000000
!
endpoint branch-office2
ce-device    ce4
ce-interface GigabitEthernet0/18
ip-network   10.8.8.0/24
as-number    65103
bandwidth    300000
!
----

Before we send anything to the network, lets see what would be sent if
we committed.
----
commit dry-run outformat native
----

The output is too large to include here but as you can see each CE
device and the PE router it is connected to will be configured.

You can give the CLI pipe flag 'debug template' to get detailed
information on what configuration the output will effect, and how, the
result of XPath evaluations etc. A good way to figure out if the
template is doing something wrong:

----
commit dry-run | debug template
----

Lets commit the configuration to the network

----
commit
----

Lets add a second VPN.

----
top
!
vpn l3vpn ford
route-distinguisher 777
endpoint main-office
ce-device    ce2
ce-interface GigabitEthernet0/5
ip-network   192.168.1.0/24
as-number    65201
bandwidth    10000000
!
endpoint branch-office1
ce-device    ce3
ce-interface GigabitEthernet0/5
ip-network   192.168.2.0/24
as-number    65202
bandwidth    5500000
!
endpoint branch-office2
ce-device    ce5
ce-interface GigabitEthernet0/5
ip-network   192.168.7.0/24
as-number    65203
bandwidth    1500000
!
----

And commit the configuration to the network

----
commit
----

==== Adding New Devices

A common use-case is of course to add a new CE device and add that as an
end-point to an existing VPN. Below follows the sequence to add two new CE
devices and add them to the VPN's.

First we add them to the topology.

----
top
!
topology connection c7
endpoint-1 device ce7 interface GigabitEthernet0/1 ip-address 192.168.1.25/30
endpoint-2 device pe1 interface GigabitEthernet0/0/0/5 ip-address 192.168.1.26/30
link-vlan 103
!
topology connection c8
endpoint-1 device ce8 interface GigabitEthernet0/1 ip-address 192.168.1.29/30
endpoint-2 device pe1 interface GigabitEthernet0/0/0/5 ip-address 192.168.1.30/30
link-vlan 104
!
commit
----

Then we add them to the VPN's

----
top
!
vpn l3vpn ford
endpoint new-branch-office
ce-device    ce7
ce-interface GigabitEthernet0/5
ip-network   192.168.9.0/24
as-number    65204
bandwidth    4500000
!
vpn l3vpn volvo
endpoint new-branch-office
ce-device    ce8
ce-interface GigabitEthernet0/5
ip-network   10.8.9.0/24
as-number    65104
bandwidth    4500000
!
----

Before we send anything to the network, lets see look at
the device configuration using dry-run. As you can see, both
new CE devices are connected to the same PE router, but for
different VPN customers.

----
commit dry-run outformat native
----

And commit the configuration to the network

----
commit
----




==== Topology Changes

Service provider networks constantly change and migrating or changing
hard-ware can be a very time consuming task.

In this section we will show how we can change the external topology
information to tell NCS that the new CE devices we added (CE7 and CE8)
are now connected to PE1 instead of PE3.

Lets start by changing the topology configuration and commit it.
Remember that this is configuration in NCS that isn't connected to any
service, so nothing will be sent to the network now.

----
top
!
topology connection c7 endpoint-2 device pe0
topology connection c8 endpoint-2 device pe0
----

----
commit
----

NCS has a very powerful tool that lets you re-deploy services. Lets
try it and see what would be sent to the network.

----
top
!
vpn l3vpn * re-deploy dry-run { outformat native }
----

As you can see from the output the configuration on PE3 will be
cleaned up and PE1 will now be configured with the VPN configuration.

Lets send the configuration to the network.

----
vpn l3vpn * re-deploy
----

==== QOS

So far we have only setup basic VPN connectivity in our network.
Lets add QOS to our VPN customers. We will do that by adding a
reference to one of the globally defined QOS policies.

----
top
!
vpn l3vpn volvo
qos qos-policy SILVER
!
vpn l3vpn ford
qos qos-policy BRONZE
----

Lets see what would be sent to the network.

----
commit dry-run outformat native
----

As you can see quite a lot of configuration is sent to the network.
Both CE and PE devices are configured with the QOS policies and
information on how to classify traffic.

And commit the configuration to the network

----
commit
----

==== Advanced QOS Configuration

The steps above will install the globally defined QOS policies for our VPN
customers, however perhaps they want to add custom rules to classify
traffic into the service provider defined traffic classes.  For
example DNS traffic and SSH traffic towards a specific server.

----
top
!
vpn l3vpn volvo
qos custom-qos-match dns
qos-class      MISSION-CRITICAL
source-ip      any
destination-ip 170.110.10.1/32
port-start     53
port-end       53
protocol       tcp
!
exit
!
qos custom-qos-match ssh
qos-class      BUSINESS-CRITICAL
source-ip      any
destination-ip 10.10.10.1/32
port-start     22
port-end       22
protocol       tcp
!
-----

Lets see what would be sent to the network.

----
commit dry-run outformat native
----

As you can see rules for matching traffic will be added and the
class-maps for MISSION-CRITICAL and BUSINESS-CRITICAL traffic will be
updated on CE routers in the VPN.

==== External QOS Policy Changes

Lets look at the power of NCS together with external policy
information again.
In the external QOS information we have defined a DSCP value for each
traffic class. The DSCP values for each class will be set on all CE
routers and matched against the PE router and used within the MPLS
cloud.

----
top
!
qos qos-class MISSION-CRITICAL dscp-value af32
commit
----

Now lets see what effect that has on the network.

----
vpn l3vpn * re-deploy dry-run { outformat native }
----

As you can see NCS will calculate the minimal diff to be sent to the
network.


=== Decommissioning VPNs

An important aspect in a service provider network is of course to be
able to decommission a VPN, and be sure that all configured associated
with that VPN is cleaned up from the network.

----
top
no vpn l3vpn volvo
----

Lets test this with one of our VPNs and see what would happen to the
network.

----
commit it dry-run out
----

All is good and our VPN configuration is removed from the network.
Lets commit the changes.

----
commit
----