Skip to content

IP VPN simulation

This chapter describes the capabilities of ENP tool for the simulation of Virtual Private Networks (VPN) in IP networks. The user will be able to define VPNs of different types and configure their interconnection topology. Then ENP will help to observe and analyze the performances and SLA fulfillment in the VPNs, under different network conditions, and design the network so that their requirements are satisfied.

VPN properties

Virtual Private Networks are characterized by the following information:

  • Name. A user-defined name, specified by the user.
  • Type. The VPN type can be one of the built-in types (VPWS, VPLS, or L3VPN), or a user-defined descriptive string.
  • Qos class. This is the QoS of the IP demands carrying the traffic of the VPN.
  • VPN nodes. The connection points in the VPN exchange data among them. A VPN node is hosted in an internal or external IP node. A VPN cannot have more than one VPN node associated with the same IP node.

  • Connectivity type. Two VPN nodes can be connected or not by a virtual adjacency, meaning that two nodes can exchange traffic. If a virtual adjacency exists from a VPN node A to a VPN node B in the same VPN, the associated traffic would be carried using the VPN-matching IP demands. These are the IP demands that:

    • Start in the IP node associated with A and end in the IP node associated with B
    • Have the same QoS as the QoS of the VPN.

Note

Note that an IP demand associated with a VPN is supposed to carry traffic of many types (e.g. other VPNs, regular traffic...), not only the one of the VPN.

There are two options for defining the topology of virtual adjacencies that are allowed in the VPN:

  • Full-mesh. In this case, there is a virtual adjacency between each pair of VPN nodes.

  • Manual (RT-based). In this case, the user can manually choose the VPN node pairs for which a virtual adjacency is defined. This is done by specifying, for each VPN node:

    • The set of importing Route Target (RT) identifiers. An import RT defines the nodes from which announced destinations are learned, and thus to which the node can send traffic. Each RT identifier is a user-defined string.
    • The set of exporting Route Target (RT) identifiers. An export RT defines the nodes to which destinations are announced, and thus from which the node could receive traffic. Each RT identifier is a user-defined string.

    A virtual adjacency is considered to exist from VPN node A to VPN node B, if an RT exists that is both imported by A and exported by B.

Note

Note that having a virtual adjacency between two nodes does not mean that the traffic can flow between them: at least one VPN-matching IP demand should also exist. When more than one VPN-matching IP demand exists, its associated traffic is assumed to be uniformly split among them.

VPN properties, manipulation, and several statistics can be visualized in the VPN table, and in the VPN Node table.

VPN nodes

A VPN node represents the end node of the traffic of a VPN associated with a particular IP node. They are characterized by:

  • Name. A user-defined name, specified by the user.
  • Associated VPN. The VPN that this VPN node is associated with.
  • Importing Route-Target. The imported Route Targets, of application if the VPN is not of full-mesh connectivity.
  • Exporting Route-Target. The exported Route Targets, of application if the VPN is not of full-mesh connectivity.

VPN node properties, manipulation, and several statistics can be visualized in the VPN Node table.

VPN simulation

The simulation of VPN performances is conducted as follows:

  • For each VPN a virtual adjacency, the VPN-matching IP demands are calculated. The VPN traffic of that adjacency is assumed to be uniformly split among the VPN-matching demands.
  • The latency, QoS oversubscription, and blocking information for each virtual adjacency is computed as the one suffered by the VPN-matching demands.

Per-VPN, per VPN-adjacency, and per VPN-node statistics are computed and shown to the user. In addition, when the user runs a worst-case simulation failure analysis, the worst-case performances are collected and shown to the user in the tables.