FTEL’S NEW METRO ACCESS NETWORK

PILOT PHASE TRAINING DOCUMENT

1
 Revision history
Name Date Reason For Changes Version

Doan Minh Tu 4/01/16 Initial draft 1.0

Doan Minh Tu 11/01/16 Detail for core 1.1

Doan Minh Tu 21/01/16 Update new use case 1.2

Doan Minh Tu 25/01/16 Finish L2VPN/VPLS use case 1.3

Doan Minh Tu 26/01/16 Add RSVP in the core & L3VPN adjustment 1.4

Doan MInh Tu 15/02/16 Add multihome case and mapping to configuration 1.5
checklist

2
TABLE OF CONTENT

3
 Table of Contents
1. Lab overview ....................................................................................................................................... 6
1.1. Virtual machine overview: ........................................................................................................... 6
1.2. Virtual machine connection setup: ............................................................................................... 6
1.3. Topology connection overview .................................................................................................... 9
1.3.1. Naming convention & Router role ........................................................................................ 9
1.3.2. Connection overview .......................................................................................................... 10
1.1.1. VLAN & IP planning overview .......................................................................................... 10
1.2. Connection configuration template ............................................................................................ 10
1.3. Grouping configuration .............................................................................................................. 12
2. Core deployment: .............................................................................................................................. 13
2.1. ISIS ............................................................................................................................................. 13
2.1.1. ISIS address planning ......................................................................................................... 13
2.1.2. ISIS zone overview & requirement..................................................................................... 13
2.1.3. ISIS adjacency template & check command ...................................................................... 14
2.1.4. ISIS routing policy requirement.......................................................................................... 16
2.1.5. ISIS routing policy config template & check command ..................................................... 17
2.2. LDP ............................................................................................................................................ 20
2.2.1. LDP overview ..................................................................................................................... 20
2.2.2. LDP configuration template ................................................................................................ 21
2.2.3. LDP basic verification ....................................................................................................... 22
2.3. BGP ............................................................................................................................................ 25
2.3.1. BGP planning & requirement ............................................................................................. 25
2.3.2. BGP configuration template and check command.............................................................. 26
2.3.3. BGP routing policy & requirement ..................................................................................... 27
2.3.4. BGP routing policy config template & check command .................................................... 29
2.3.5. BGP policy verification ...................................................................................................... 34
2.4. RSVP .......................................................................................................................................... 38
2.4.1. RSVP overview & clarification: ......................................................................................... 38
2.4.2. RSVP configuration template ............................................................................................. 39

4
 2.4.3. Tunneling verification ......................................................................................................... 42
3. Service deployment ........................................................................................................................... 48
3.1. L3VPN ....................................................................................................................................... 48
3.1.1. Planning & perquisite: ........................................................................................................ 48
3.1.2. Configuration example for Customer2 (quick method) ...................................................... 50
3.1.3. Common verification for L3VPN: ...................................................................................... 51
3.1.4. Configuration example for Customer1 (detailed method) .................................................. 55
3.1.5. BGP PE-CE link advertisement for L3VPN: ...................................................................... 56
3.2. L2VPN ....................................................................................................................................... 65
3.2.1. Planning & perquisite: ........................................................................................................ 65
3.2.2. Common configuration and verification method: ............................................................... 67
3.2.3. Case study 1: transparent L2VPN without vlan-tagging: ................................................... 76
3.2.4. Case study 2: tagged L2VPN .............................................................................................. 81
3.2.5. Case study 3: trunk with vlan-id-list ................................................................................... 86
3.3. VPLS .......................................................................................................................................... 89
3.3.1. Planning & perquisite: ........................................................................................................ 89
3.3.2. Common configuration and verification method: ............................................................... 91
3.3.3. Case study 1: transparent VPLS without vlan-tagging: .................................................... 100
3.3.4. Case study 2: VPLS with similar vlan-tagging on all side: .............................................. 102
3.3.5. Study 2: VPLS with different vlan-tag configuration on each side: ................................. 105

5
 1. Lab overview

1.1. Virtual machine overview:

To deploy all use case for provider’s L3VPN – L2VPN and VPLS service, SVTECH recommend use
virtual machine vMX version 14.1

After the core network has been deployed using vMX, an additional virtual machine running Olive
(version 12.1 or 8.4) shall be use to represent CE routers.

Recommended configuration for each virtual machines:

 Olive: 256MB RAM. Recommended running on VMware workstation and add all at least 4
virtual network adapter (NIC) supported by VMware station
 vMX: 1GB RAM and all real machine’s CPU core. Recommended running on VMware
workstation and add all 10 virtual network adapter (NIC) supported by VMware station (on a
weak machine, GNS3 is unable to handle all 13 vMX routers required for the core network)

Login information for Virtual Machine:

 user root/juniper
 password juniper@123

1.2. Virtual machine connection setup:

There is a different in how vMX virtual machine and Olive virtual machine handle virtual network
adapter provided by VMware:

 Olive: each NIC added by VMware will be added to Olive device under the name em0, em1,
em2, em3…. alternately

6
  On vMX, the first two NIC added by VMware will be unusable. The third NIC will be named ge-
0/0/0, the fourth one is ge-0/0/1 and so forth

In order to deploy the topologies required for this lab, on the vMX virtual machines we will use:

 One interface ge-0/0/0 for management connection – connect to real machine via VMnet1 and
VMnet1 network adapter on the host machine
 Four interface ge-0/0/1 to ge-0/0/4 will be used in the core network
 Three interface ge-0/0/5, ge-0/0/6 and ge-0/0/7 will be used as CE (Customer Edge router) facing
interface on PE (Provider Edge) routers.

Training participant can either use the provided virtual machine or setup a similar connection as
provided in the above images, which is:

 Connect NIC 3 on vMX to VMnet1

 Connect NIC 4 and 5 on vMX to the same VMnet
 Connect NIC 5 and 6 on vMX to another VMnet
 Connect NIC 7, 8 and 9 on VMx to 3 different VMnet
 Connect NIC 2, 3 and 4 on Olive to 3 different VMnet corresponding to NIC 7, 8 and 9 on vMX

7
Recommended additional setup

Adding a virtual Serial Port on each virtual machine and use the named pipe \\.\pipe\vMX on VMX,
\\.\pipe\Olive on Olive. Use the following software to connect to console port on each device:

8
1.3. Topology connection overview

1.3.1. Naming convention & Router role

- uPE router: stand for User Provider Edge router – more commonly refer as Site router which
handle connection to customer, most of service configuration is perform on uPE router
- nPE router: Act as aggregate router for a zone. Most of route advertising policy is configured on
nPE router
- Core routers: The actual FTEL’s Core consist of several core router and is outside the scope of
this document. In this lab we only use four router to represent the Core network.
- RR: Dedicated provider edge router
- CE: Customer Edge Router, represent customer (gateway) routers.

9
 1.3.2. Connection overview
All connection between provider routes will use two pair of interface

 Ge-0/0/1 and ge-0/0/2 connection is for up-down link connection ( from uPE to nPE and from
nPE to Core)
 Ge-0/0/3 and ge-0/0/4 is use to connect router of the same level (uPE-uPE, nPE-nPE and Core to
Core)

Each logical unit used on these four core interface (ge-0/0/1 to ge-0/0/4) will have unit number
corresponded with its associated IP. For example connection between HN-UPE1 to HN-NPE1 use vlan-
id 11 thus the connection between these two router will be from ge-0/0/2.11 to ge-0/0/1.11

Three interface ge-0/0/5, ge-0/0/6 and ge-0/0/7 will be reserved for CE connection use case as specified
in section 3.

1.1.1. VLAN & IP planning overview

Each pair of connection will require a VLAN ID to virtualize separation of traffic. IP for interconnect
between routers is specified in the image, with

 Range 1.0.0.X/31 for access zone HN (ID 1)

 Range 2.0.0.X/31 for access zone HCM (ID 2)
 Range 3.0.0.X/31 for Core zone (ID 3)
 VLAN number is planned with “Zone ID + Counter”

Loopback Interface is specified in the form 10.0.X.Y with

 X = Zone ID
 Y start with 1 for HN routers, start with 2 for HCM routers, following with counter for router
type.

1.2. Connection configuration template

Note that we need to enable vlan-tagging on all core interface

Encapsulation flexible-ethernet-services is also enable for more flexibilty (future use)

// Note that we need to enable vlan-tagging on all core interface //

// encapsulation flexible-ethernet-services is also enable for more flexibilty (future
use)//

// vlan-tagging must be enable at global level – not logical-system level //

[edit interfaces] juniper@vMX# show
ge-0/0/0 {

10
 unit 0 {
family inet {
address 192.168.1.1/24;
}
}
}
ge-0/0/1 {
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
}
ge-0/0/2 {
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
}
ge-0/0/3 {
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
}
ge-0/0/4 {
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
}

All basic configuration of router connection simply consist of the planning L3 IP address and vlan-id,
placed in the corresponding logical router//

// correct interface/logical unit should be placed in the corresponding logical-system

hierachy //

//unit number and vlan-id should match for better management

//Example for HN-CORE1 router
[edit logical-systems HN-CORE1 interfaces]
juniper@vMX# show
ge-0/0/1 {
unit 311 {
vlan-id 311;
family inet {
address 3.1.0.1/31;
}
}
}
ge-0/0/3 {
unit 31 {
vlan-id 31;
family inet {
address 3.0.0.0/31;
}
}
unit 32 {
vlan-id 32;

11
 family inet {
address 3.0.0.2/31;
}
}
unit 35 {
vlan-id 35;
family inet {
address 3.0.0.8/31;
}
}
}
lo0 {
unit 3011 {
family inet {
address 10.0.3.11/32;
}
}
}

1.3. Grouping configuration

A group of configuration is a set of configuration that serve the same purpose, placed in [edit groups
groupname] hierarchy

Those configuration will have no effect until we active the group configuration by using the command

set apply-groups groupname

To deactive the effect on the configuration we placed in a group, simply remove the apply operation

delete apply-groups groupname

In this lab, each section (ISIS, BGP, LDP, RSVP, L3VPN, L2VPN use cases…) should have its
configuration placed in a corresponding group. We only enable the necessary configuration in each
section

12
 2. Core deployment:

2.1. ISIS

2.1.1. ISIS address planning

Each router participating in ISIS need an ISO address ( or Network Service Access Point (NSAP)
addressing).

Start with 49 (49.XXXX….. )

 Area Address, comprise of the Authority and Format Identifier (AFI) start with 49 - stand for
locally administered (aka private addresses) and the area ID.– similar to OSPF area ID but with
difference length, in this lab we choose 1840.XXXX with
o XXXX = 0001 for HN access zone
o XXXX = 0002 of HCM access zone
o XXXX= 0003 for core zone

So we have three Area Address on this lab which is 49.1840.0001, 49.1840.0002 and 49.1840.0003

//Note that 1840 is taken from FTEL’s AS number, for more typical example we can use 49.0001

 System (Router) specific ID, typical constructed based on loopback IPv4 address in the
following way
o Fill in all octet of IPv4 address, eg 10.0.3.11 > 010.000.003.011
o Move the dot to construct three four-digit octet, eg 0100.0000.3011
 The NSEL, which must always be set to 0 for a router.

Thus we have the following address for HN-CORE1 : 49.1840.0003.0100.0000.3011.00

2.1.2. ISIS zone overview & requirement

The zone planning for ISIS in the core network follow these convention

 Core zone only consist of four core router which form L2 adjacency with each other
 Core routers also form L2 ISIS adjacency with its connected Route Reflector routers, however
the metric on the link RR-CORE must be set to maximum value to ensure traffic never pass
through Route Reflector router (explain later in BGP section)
 Core router form L2 adjacency with NPE routers which act as aggregate router for its respective
zone
 UPE router only form L1 adjacency with each other and with NPE routers

13
  NPE router form L2 AND L1 adjacency with each other to ensure all NPE routers have full
routing information

2.1.3. ISIS adjacency template & check command

For a router to participate in ISIS adjacency forming, we need to specify the planned ISO address and
enable family ISO on the interconnect interfaces:

// All configuration should be placed in the corresponding logical-system. These

configuration is placed on global level, not in group
// Example for HN-CORE1 router
[edit logical-systems HN-CORE1 interfaces]
ge-0/0/1 {
unit 311 {
family iso;
}
}
ge-0/0/3 {
// family ISO should be placed in the corresponding logical unit for each logical-system
unit 31 {
family iso;
}
unit 32 {
family iso;

14
 }
unit 35 {
family iso;
}
}
lo0 {

family iso {
address 49.1840.0003.0100.0000.3011.00;
}
}
}

ISIS adjacency is enabled on interface level.

// ISIS configuration is placed in a corresponding group for this lab.

// First note that we use wide-metric-only for all link, so it should be enable for all
ISIS level on all logical system using the wild card <*>
[edit groups ISIS logical-systems HN-CORE1]
logical-systems {
<*> {
protocols {
isis {
level 1 wide-metrics-only;
level 2 wide-metrics-only;
}
}
}
}

// Example interface configuration for HN-CORE1 router

[edit groups ISIS logical-systems HN-CORE1]
juniper@vMX# show
protocols {
isis {
interface ge-0/0/1.311 {
// all interconnect interface should be set to point-to-point to advoid DIS
election process (similar to OSPF DR-BDR election)
point-to-point;
// by default all ISIS interface on MX devices will run L1/L2 connection,
disable the undesired connecting level to match the design
level 1 disable;
}
interface lo0.3011 {
// loopback interface should always be set to passive to keep the router
from trying to send advertisement packet through loopback
passive;
}
interface ge-0/0/3.31 {
point-to-point;
level 1 disable;
}
interface ge-0/0/3.32 {
point-to-point;
level 1 disable;

15
 }
interface ge-0/0/3.35 {
point-to-point;
level 1 disable;
}
}
}

To check ISIS adjacency, first check the enabled interface on all participating router

//Note that on the L column, 2 mean that the interface is L2 link, 1 mean that it is a
L1 link and 3 mean that that interface is running both Level 1 and Level 2 ISIS
connection

[edit groups ISIS logical-systems HN-CORE1]

juniper@vMX# run show isis interface logical-system HN-CORE1
IS-IS interface database:
Interface L CirID Level 1 DR Level 2 DR L1/L2 Metric
ge-0/0/1.311 2 0x1 Disabled Point to Point 10/10
ge-0/0/3.31 2 0x1 Disabled Point to Point 10/10
ge-0/0/3.32 2 0x1 Disabled Point to Point 10/10
ge-0/0/3.35 2 0x1 Disabled Point to Point 10/10
lo0.3011 3 0x1 Passive Passive 0/0

[edit groups ISIS logical-systems HN-CORE1]

juniper@vMX# run show isis interface logical-system HN-CORE2
IS-IS interface database:
Interface L CirID Level 1 DR Level 2 DR L1/L2 Metric
ge-0/0/1.312 2 0x1 Disabled Point to Point 10/10
ge-0/0/3.33 2 0x1 Disabled Point to Point 10/10
ge-0/0/4.32 2 0x1 Disabled Point to Point 10/10
ge-0/0/4.36 2 0x1 Disabled Point to Point 10/10
lo0.3012 3 0x1 Passive Passive 0/0

The correct adjacency status is up

[edit groups ISIS logical-systems HN-CORE1]

juniper@vMX# run show isis adjacency logical-system HN-CORE1
Interface System L State Hold (secs) SNPA
ge-0/0/1.311 vMX-HN-NPE1 2 Up 20
ge-0/0/3.31 vMX-HCM-CORE1 2 Up 26
ge-0/0/3.32 vMX-HN-CORE2 2 Up 23
ge-0/0/3.35 vMX-HN-RR 2 Up 25

2.1.4. ISIS routing policy requirement

The route leaking policy between ISIS zones is as depicted in the diagram, which is

 From core zone to access zones, we advertise nothing but multicast sources address

16
  From access zone to core zones, we advertise nothing

This will ensure minimal route propagation between zones in the network but still keep flows going,
because all NPE route still have full routing information. Because:

 By default, all ISIS L1/L2 router that connect zones (NPE router in this lab) will send attached-
bit to L1 router in its respective zone. Those L1 router will then create a default route to the
L1/L2 router to reach other zone
 BGP Routes received from access zones will have its next-hop change to NPE routers (see BGP
section), so all traffic traverse the core will know to use NPE routers to reach access routes.

//Note that for this design, all route leaking policy must be configure on the NPE routers

2.1.5. ISIS routing policy config template & check command

ISIS routing policy can be apply at [protocol isis] level

[edit groups ISISpolicy logical-systems HN-NPE1]

juniper@vMX# show
protocols {
isis {
export [ ISIS-HN-TO-CORE ISIS-CORE-TO-HN ];
}
}
policy-options {
policy-statement ISIS-HN-TO-CORE {
term default {
from level 1;
to level 2;
then reject;
}
}
policy-statement ISIS-CORE-TO-HN {
term default {
from level 2;
to level 1;
then reject;
}
}
}

To add permission to advertise a specific route from Core to access zone HN using ISIS (not
recommended), we can insert the following term in the policy-statement ISIS-CORE-TO-HN

term example {
from {
level 2;
route-filter x.x.x.x/y orlonger;
route-filter PREFIXLIST-MULTICAST;
}
to level 1;
then accept;

17
}
term default {
from level 2;
to level 1;
then reject;
}

The result is checked by showing the inet.0 table on all router. On access UPE router should only have a
default route to NPE and intra-zone link. On Core router should not have any route from access zones.

juniper@vMX# run show route table inet.0 logical-system HN-UPE1

inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
// UPE have default route to NPE, generated by attached bit and nothing else from core

0.0.0.0/0 *[IS-IS/15] 04:06:17, metric 10

> to 1.0.0.1 via ge-0/0/2.11
1.0.0.4/31 *[IS-IS/15] 04:05:54, metric 20
> to 1.0.0.3 via ge-0/0/3.12
1.0.0.6/31 *[IS-IS/15] 04:05:31, metric 30
to 1.0.0.1 via ge-0/0/2.11
> to 1.0.0.3 via ge-0/0/3.12
1.0.0.8/31 *[IS-IS/15] 04:06:17, metric 20
> to 1.0.0.1 via ge-0/0/2.11
10.0.1.11/32 *[IS-IS/15] 04:06:17, metric 10
> to 1.0.0.1 via ge-0/0/2.11
10.0.1.12/32 *[IS-IS/15] 04:05:31, metric 20
> to 1.0.0.1 via ge-0/0/2.11
10.0.1.102/32 *[IS-IS/15] 04:05:54, metric 10
> to 1.0.0.3 via ge-0/0/3.12
10.0.1.103/32 *[IS-IS/15] 04:05:53, metric 20
> to 1.0.0.3 via ge-0/0/3.12

juniper@vMX# run show route table inet.0 logical-system HN-CORE1

inet.0: 32 destinations, 32 routes (32 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

// Core router still see some link directly connected to NPE routers. However UPE
loopbacks should not present on core router’s routing table
1.0.0.0/31 *[IS-IS/18] 04:06:18, metric 20
> to 3.1.0.0 via ge-0/0/1.311
1.0.0.6/31 *[IS-IS/18] 04:05:33, metric 30
to 3.1.0.0 via ge-0/0/1.311
> to 3.0.0.3 via ge-0/0/3.32
1.0.0.8/31 *[IS-IS/18] 04:06:18, metric 20
> to 3.1.0.0 via ge-0/0/1.311
2.0.0.0/31 *[IS-IS/18] 04:06:23, metric 30
> to 3.0.0.1 via ge-0/0/3.31
2.0.0.4/31 *[IS-IS/18] 04:06:24, metric 40
to 3.0.0.1 via ge-0/0/3.31
> to 3.0.0.3 via ge-0/0/3.32
2.0.0.6/31 *[IS-IS/18] 04:06:23, metric 30
> to 3.0.0.1 via ge-0/0/3.31

18
3.0.0.4/31 *[IS-IS/18] 04:09:57, metric 20
> to 3.0.0.3 via ge-0/0/3.32
3.0.0.6/31 *[IS-IS/18] 04:10:04, metric 20
> to 3.0.0.1 via ge-0/0/3.31
3.0.0.10/31 *[IS-IS/18] 01:29:25, metric 20
> to 3.0.0.3 via ge-0/0/3.32
to 3.0.0.9 via ge-0/0/3.35
3.0.0.12/31 *[IS-IS/18] 01:30:37, metric 20
> to 3.0.0.1 via ge-0/0/3.31
3.0.0.14/31 *[IS-IS/18] 01:30:10, metric 30
> to 3.0.0.1 via ge-0/0/3.31
to 3.0.0.3 via ge-0/0/3.32
3.1.0.2/31 *[IS-IS/18] 04:09:57, metric 20
> to 3.0.0.3 via ge-0/0/3.32
3.2.0.0/31 *[IS-IS/18] 04:10:04, metric 20
> to 3.0.0.1 via ge-0/0/3.31
3.2.0.2/31 *[IS-IS/18] 01:30:10, metric 30
> to 3.0.0.1 via ge-0/0/3.31
to 3.0.0.3 via ge-0/0/3.32
10.0.1.11/32 *[IS-IS/18] 04:06:18, metric 10
> to 3.1.0.0 via ge-0/0/1.311
10.0.1.12/32 *[IS-IS/18] 04:05:33, metric 20
> to 3.1.0.0 via ge-0/0/1.311
to 3.0.0.3 via ge-0/0/3.32
10.0.2.11/32 *[IS-IS/18] 04:06:23, metric 20
> to 3.0.0.1 via ge-0/0/3.31
10.0.2.12/32 *[IS-IS/18] 04:06:24, metric 30
to 3.0.0.1 via ge-0/0/3.31
> to 3.0.0.3 via ge-0/0/3.32
10.0.3.12/32 *[IS-IS/18] 04:09:57, metric 10
> to 3.0.0.3 via ge-0/0/3.32
10.0.3.13/32 *[IS-IS/18] 01:29:25, metric 10
> to 3.0.0.9 via ge-0/0/3.35
10.0.3.21/32 *[IS-IS/18] 04:10:04, metric 10
> to 3.0.0.1 via ge-0/0/3.31
10.0.3.22/32 *[IS-IS/18] 01:30:10, metric 20
to 3.0.0.1 via ge-0/0/3.31
> to 3.0.0.3 via ge-0/0/3.32
10.0.3.23/32 *[IS-IS/18] 01:30:01, metric 20
> to 3.0.0.1 via ge-0/0/3.31

19
 2.2. LDP

2.2.1. LDP overview

The LDP is one of MPLS signaling protocols used in the access network. The main purpose of enabling
LDP is to allow routers to signal a LDP LSP between any routers of an ISIS area to create the necessary
transport LSP for overlay VPN services.

LDP will be enable on all interface of all CORE, RR and NPE routers and also all core facing interface
of UPE routers. Which include:

 Enable family mpls on all interface planned to run LDP

 Enable interfaces in protocol mpls
 Enable interfaces in protocol ldp, also always remember to include the loopback interface

The following additional step is necessary

 Enable track-idp-metric and disaggregate for protocol ldp in all routers

 Enable ldp-synchronization for all ISIS link in all routers

//Note that when we first enable LDP on all those interface, each router will only have LDP route to
loopback of other routers in the same area, since we have disable all inter-area route advertisement in
ISIS. Inter-area LDP route is still necessary, but will be advertise via BGP in the next section.

20
 2.2.2. LDP configuration template
First we enable track-igp-metric and deaggregate for LDP universally on all routers.

// the following configuration include a wildcard and must be specified in a group

// the wildcard <*> will apply these configuration to all logical-systems once the group
is applied
[edit groups LDP]
logical-systems {
<*> {
protocols {
ldp {
// make LDP use IGP metric for LDP routes in inet.3 – instead of using default LDP
metric which is 1.
track-igp-metric;
// configure LDP FEC deaggregation to bind each prefix on the router to a separate
label:
deaggregate;
}
}
}
}

We also enable ldp-synchronization on all ISIS link

// the following configuration include a wildcard and must be specified in a group

[edit groups LDP]

logical-systems {
<*> {
protocols {
isis {
// the wildcard <ge-*> will apply these configuration to all isis ge interface in all
logical-systems once the group is applied
interface <ge-*> {
// enabling synchronization will make ISIS advertise maximum cost metric for this link
until LDP is up and operational on it.
ldp-synchronization;
}
}
}
}
}

For LDP interface configuration, first we need to enable family mpls on all logical interface to be run
LDP on a router, example on HN-CORE1

[edit logical-systems HN-CORE1 interfaces]

ge-0/0/1 {
// enabling family mpls only allow this interface to understand mpls label on a packet –
it do not yet enable signaling protocol like LDP or RSVP
unit 311 {
family mpls;
}

21
}
ge-0/0/3 {
unit 31 {
family mpls;
}
unit 32 {
family mpls;
}
unit 35 {
family mpls;
}
}

Although LDP neighbor can still be up without enabling interface in protocol mlps, doing so will result
in label allocation failure when we advertise VPN routes across the network – so this operation is still a
must (trainee can try remove interface from protocol mpls and use show route advertising protocol
bgp to see the error message)

Example for HN-CORE1

[edit groups LDP logical-systems HN-CORE1]

protocols {
mpls {
// specify all interface to be run LDP (or RSVP) in protocol mpls for proper label
allocation for that interface
interface ge-0/0/1.311;
interface ge-0/0/3.31;
interface ge-0/0/3.32;
interface ge-0/0/3.35;
}
ldp {
// specify interface in protocol ldp will enable this protocol and allow neighbor
forming in this interface
interface ge-0/0/1.311;
interface ge-0/0/3.31;
interface ge-0/0/3.32;
// inclusion of loopback interface in protocol ldp is mandatory
interface lo0.3011;
interface ge-0/0/3.35;
}
}

2.2.3. LDP basic verification

Once interface is enable, all LDP neighboring state should appear with its associated interface and label
space ID. Example on HN-CORE1

// First check that all neccesary interface is enabled, and the loopback interface is
include
[edit]
juniper@vMX# run show ldp interface logical-system HN-CORE1

22
Interface Label space ID Nbr count Next hello
lo0.3011 10.0.3.11:0 0 0
ge-0/0/1.311 10.0.3.11:0 1 1
ge-0/0/3.31 10.0.3.11:0 1 0
ge-0/0/3.32 10.0.3.11:0 1 1
ge-0/0/3.35 10.0.3.11:0 1 1

// Notice the neighbor count on all ge interface is 1, confirm by display the neighbor
state
[edit]
juniper@vMX# run show ldp neighbor logical-system HN-CORE1
Address Interface Label space ID Hold time
3.1.0.0 ge-0/0/1.311 10.0.1.11:0 14
3.0.0.1 ge-0/0/3.31 10.0.3.21:0 11
3.0.0.3 ge-0/0/3.32 10.0.3.12:0 12
3.0.0.9 ge-0/0/3.35 10.0.3.13:0 12

// Note that for LDP, if the neighbor forming process failed, the neighbor will simply
dissapear
juniper@vMX# run show ldp neighbor logical-system HN-CORE1
Address Interface Label space ID Hold time
3.1.0.0 ge-0/0/1.311 10.0.1.11:0 14

//we can confirm the neighbor forming failure by looking the neighbor cound column on
LDP-enabled interfaces. If this happened, double check the configuration on the neighbor
juniper@vMX# run show ldp interface logical-system HN-CORE1
Interface Label space ID Nbr count Next hello
lo0.3011 10.0.3.11:0 0 0
ge-0/0/1.311 10.0.3.11:0 1 1
ge-0/0/3.31 10.0.3.11:0 0 1
ge-0/0/3.32 10.0.3.11:0 0 2
ge-0/0/3.35 10.0.3.11:0 0 1

//As explained above, when LDP is first enabled, the number of inter-area LDP route is limited until we
deploy BGP policy, this is the state of inet.3 table without BGP deployed

//UPE routers only have LDP routes to access routers in the same zone
[edit]
juniper@vMX# run show route table inet.3 logical-system HN-UPE1

inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

10.0.1.11/32 *[LDP/9] 00:04:20, metric 10

> to 1.0.0.1 via ge-0/0/2.11
10.0.1.12/32 *[LDP/9] 00:00:04, metric 16777224
> to 1.0.0.1 via ge-0/0/2.11, Push 300176
10.0.1.102/32 *[LDP/9] 00:00:04, metric 16777214
> to 1.0.0.3 via ge-0/0/3.12
10.0.1.103/32 *[LDP/9] 00:00:04, metric 16777234
> to 1.0.0.1 via ge-0/0/2.11, Push 300192

//Core routers only have LDP routes to core routers and RR and NPE
juniper@vMX# run show route table inet.3 logical-system HN-CORE1

inet.3: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)

23
+ = Active Route, - = Last Active, * = Both

10.0.1.11/32 *[LDP/9] 00:05:18, metric 10

> to 3.1.0.0 via ge-0/0/1.311
10.0.1.12/32 *[LDP/9] 00:01:01, metric 20
to 3.1.0.0 via ge-0/0/1.311, Push 300176
> to 3.0.0.3 via ge-0/0/3.32, Push 299792
10.0.2.11/32 *[LDP/9] 00:01:01, metric 20
> to 3.0.0.1 via ge-0/0/3.31, Push 299776
10.0.2.12/32 *[LDP/9] 00:01:01, metric 30
> to 3.0.0.1 via ge-0/0/3.31, Push 300112
to 3.0.0.3 via ge-0/0/3.32, Push 300144
10.0.3.12/32 *[LDP/9] 00:01:01, metric 10
> to 3.0.0.3 via ge-0/0/3.32
10.0.3.13/32 *[LDP/9] 00:01:01, metric 10
> to 3.0.0.9 via ge-0/0/3.35
10.0.3.21/32 *[LDP/9] 00:01:01, metric 10
> to 3.0.0.1 via ge-0/0/3.31
10.0.3.22/32 *[LDP/9] 00:01:01, metric 20
> to 3.0.0.1 via ge-0/0/3.31, Push 300096
to 3.0.0.3 via ge-0/0/3.32, Push 300128
10.0.3.23/32 *[LDP/9] 00:01:01, metric 20
> to 3.0.0.1 via ge-0/0/3.31, Push 300048

//NPE routers only have LDP routes to core,the other NPEs and its respective access zone
juniper@vMX# run show route table inet.3 logical-system HN-NPE1

inet.3: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

10.0.1.12/32 *[LDP/9] 00:02:12, metric 10

> to 1.0.0.8 via ge-0/0/3.15
10.0.1.101/32 *[LDP/9] 00:06:29, metric 10
> to 1.0.0.0 via ge-0/0/1.11
10.0.1.102/32 *[LDP/9] 00:02:12, metric 20
> to 1.0.0.0 via ge-0/0/1.11, Push 299888
10.0.1.103/32 *[LDP/9] 00:02:12, metric 20
> to 1.0.0.8 via ge-0/0/3.15, Push 299792
10.0.2.11/32 *[LDP/9] 00:02:12, metric 30
> to 3.1.0.1 via ge-0/0/2.311, Push 300064
10.0.2.12/32 *[LDP/9] 00:02:12, metric 40
> to 3.1.0.1 via ge-0/0/2.311, Push 300160
to 1.0.0.8 via ge-0/0/3.15, Push 300288
10.0.3.11/32 *[LDP/9] 00:06:29, metric 10
> to 3.1.0.1 via ge-0/0/2.311
10.0.3.12/32 *[LDP/9] 00:02:12, metric 20
to 3.1.0.1 via ge-0/0/2.311, Push 300112
> to 1.0.0.8 via ge-0/0/3.15, Push 299808
10.0.3.13/32 *[LDP/9] 00:02:12, metric 20
> to 3.1.0.1 via ge-0/0/2.311, Push 300096
10.0.3.21/32 *[LDP/9] 00:02:12, metric 20
> to 3.1.0.1 via ge-0/0/2.311, Push 300048
10.0.3.22/32 *[LDP/9] 00:02:12, metric 30
to 3.1.0.1 via ge-0/0/2.311, Push 300144
> to 1.0.0.8 via ge-0/0/3.15, Push 300272
10.0.3.23/32 *[LDP/9] 00:02:12, metric 30
> to 3.1.0.1 via ge-0/0/2.311, Push 300080

24
 2.3. BGP
BGP will be the main signaling method for all service routes (L2VPN, VPLS, L3VPN), as well as signal
reachability for loopback in inet.0 and inet.3

2.3.1. BGP planning & requirement

BGP peering is form mostly based on route reflector method, with the following convention

 All NPE routers act as route reflector for all UPE router in their respective region
 HN-RR act as route reflector for all NPE router in all access area of HN
 HCM-RR act as route reflector for all NPE router in all access area of HCM
 HN-RR and HCM-RR form normal IBGP peering session

The cluster ID planning is as follow

 1.1.1.1 reserved for a core-level RR of HN (from HN-RR to HN-NPEs)

 1.1.1.x reserved for a NPE RR on HN access zones
 2.2.2.2 reserved for core-level RR of HCM (from HCM-RR to HCM-NPEs)
 2.2.2.x reserved for NPE RR on HCM access zones
 Both (or all) NPE of the same zones should use the same cluster ID when form route reflecting
session with UPE on that zone

25
 2.3.2. BGP configuration template and check command
BGP configuration is different between UPE, NPE and RR. However all devices should have
autonomous system set to 18403 in routing-options first

set logical-systems HCM-CORE1 routing-options autonomous-system 18403

set logical-systems HCM-CORE2 routing-options autonomous-system 18403
set logical-systems HCM-NPE1 routing-options autonomous-system 18403
set logical-systems HCM-NPE2 routing-options autonomous-system 18403
set logical-systems HCM-RR routing-options autonomous-system 18403
set logical-systems HCM-UPE1 routing-options autonomous-system 18403
set logical-systems HCM-UPE2 routing-options autonomous-system 18403
set logical-systems HN-CORE1 routing-options autonomous-system 18403
set logical-systems HN-CORE2 routing-options autonomous-system 18403
set logical-systems HN-NPE1 routing-options autonomous-system 18403
set logical-systems HN-NPE2 routing-options autonomous-system 18403
set logical-systems HN-RR routing-options autonomous-system 18403
set logical-systems HN-UPE1 routing-options autonomous-system 18403
set logical-systems HN-UPE2 routing-options autonomous-system 18403
set logical-systems HN-UPE3 routing-options autonomous-system 18403

First is template for UPE routers, HN-UPE1 for example

// BGP configuration is placed in a corresponding group for this lab.

[edit groups BGP logical-systems HN-UPE1]
protocols {
bgp {
// use loopback for local address.
local-address 10.0.1.101;
group NPE {
type internal;
// authentication key must match betwene UPE and NPE
authentication-key "$9$OfE/1cyevWx-V"; ## SECRET-DATA
// all zone’s NPE loopback address, must be reachable via ISIS first
neighbor 10.0.1.11;
neighbor 10.0.1.12;
}
}
}

For NPE router, use two different group for access and core BGP neighbor

// BGP configuration is placed in a corresponding group for this lab.

[edit groups BGP logical-systems HN-NPE1]
protocols {
bgp {
// use loopback for local address.
local-address 10.0.1.11;
group NPEtoACCESS {
type internal;
// authentication key must match betwene UPE and NPE

26
 authentication-key "$9$IaeEreM8X-bs"; ## SECRET-DATA
// specify a cluster ID to make this router a route reflector, use the same ID for both
NPE
cluster 1.1.1.10;
// NPE must form BGP session with ALL UPE router in its zone
neighbor 10.0.1.101;
neighbor 10.0.1.102;
neighbor 10.0.1.103;
}
group NPEtoCORE {
type internal;
// authentication key must match betwene RR and NPE
authentication-key "$9$luZKLx-VwgaZ"; ## SECRET-DATA
// HN-RR loopback address to receive route from core
neighbor 10.0.3.13;
}
}
}

RR router act as route reflector for all NPE router in its region and form normal IBGP session with the
other RR. Example on HN-RR

group NPEtoCORE {
[edit groups BGP logical-systems HN-RR]
juniper@vMX# show
protocols {
bgp {
local-address 10.0.3.13;
group COREto-HN-NPE {
type internal;
// authentication key must match betwene RR and NPE
authentication-key "$9$9auYAO1EcyKWL"; ## SECRET-DATA
// Specify cluster ID dedicated for RR-NPE session to make HN-RR act as RR for all HN-
NPE routers
cluster 1.1.1.1;
neighbor 10.0.1.11;
neighbor 10.0.1.12;
}
// In this lab we only have one RR router for each region, however in practice several
RR routers in core may all have BGP session with each other – hence the name FullMesh
group CORE-FullMesh {
type internal;
neighbor 10.0.3.23;
}
}
}

2.3.3. BGP routing policy & requirement

Here is the target for traffic flow between 2 access network when crossing the core:

 UPE will pickup the nearest NPE as exit point

 NPE will pickup the nearest remote NPE as entering point for destination UPE

27
  the remote NPE will pickup the shortest path for destination UPE

Determining the shortest path is perform by ISIS.

However since according to this design ISIS do NOT provide reachability from core to access loopback,
NPE router must perform next-hop-self operation on two direction:

 Route with UPE as BGP protocol-next-hop will have its protocol-next-hop (BGP next-hop)
changed to NPE when exiting an access zone. Because routers in the core and NPE in other zone
do NOT know any routes in that access zone except for the corresponding NPE’s address
 Route with remote NPE (NPE on another access zone) as BGP protocol-next-hop will have its
protocol-next-hop (BGP next-hop) changed (again) to local NPE when entering an access zone

This is an example diagram for route advertisement from HCM access zone to HN access zone ( the
opposite direction operation is completely similar)

Note that all these policy is configured in the outbound direction of a BGP session of NPE routers
using export policy.

28
  Export policy from HCM-NPE to HCM-RR
 Export policy from HN-NPE to HN-UPE

For the opposite direction, we need next-hop-self policy as

 Export policy from HN-NPE to HN-RR

 Export policy from HCM-NPE to HCM-UPE

The above mentioned policy will be applied to the following routes:

 LDP and BGP route received in inet.3 table

 Aggregate route represent multicast source and loopback ip range address of a access zones (for
access > core direction only)
 BGP route represent aggregated loopback ip range from other access zone (for core > access
direction only)

For these policy to work, we need to enable BGP’s support of advertisement of labeled route in inet.3 in
all BGP enabled router

[edit groups BGPpolicy]

logical-systems {
<*> {
protocols {
bgp {
family inet {
unicast;
labeled-unicast {
rib {
inet.3;
}
}
}
}
}
}

2.3.4. BGP routing policy config template & check command

Again, note that all the policy from this point on is applied on NPE router.

First of all, on all NPE routers we will create prefix-list that match each area loopback range for more
flexibility

29
[edit groups BGPpolicy logical-systems HN-NPE1]
policy-options {
prefix-list HN-LOOPBACK-RANGE {
10.0.1.0/24;
}
prefix-list HCM-LOOPBACK-RANGE {
10.0.2.0/24;
}
// For multicast source range or other zone, create prefix-list for each
prefix-list XXX-LOOPBACK-RANGE {
10.0.X.0/24;
}
}

Also, on all NPE routers we create aggregate route for loopback range of respective access zone

[edit groups BGPpolicy logical-systems HN-NPE1]

routing-options {
aggregate {
// HN loopback range aggretated into one /24 on HN-NPE
route 10.0.1.0/24;
}
}
[edit groups BGPpolicy logical-systems HN-NPE2]
routing-options {
aggregate {
// HN loopback range aggretated into one /24 on HN-NPE
route 10.0.1.0/24;
}
}
[edit groups BGPpolicy logical-systems HCM-NPE1]
routing-options {
aggregate {
// HCM loopback range aggretated into one /24 on HCM-NPE
route 10.0.2.0/24;
}
}
[edit groups BGPpolicy logical-systems HCM-NPE2]
routing-options {
aggregate {
// HCM loopback range aggretated into one /24 on HCM-NPE
route 10.0.2.0/24;
}
}

The configuration example/template here has been divided into two part represent two direction for
easier understanding. The actual provided to trainee will be all group into the configuration group
BGPpolicy

30
 a. Direction 1 : from access to core
On NPE routers, to apply export policy when exporting route from access zone to core zone. We apply it
in BGP group NPEtoCORE – the BGP group in which the BGP peer in core zone is configured.

Example on HN-NPE1

[edit groups BGPpolicy logical-systems HN-NPE1]

protocols {
bgp {
group NPEtoCORE {
export BGP-HN-TO-CORE;
}
}
}

The configuration of the policy named BGP-HN-TO-CORE consist of two main part, the first two term
handle route from inet.3 table

[edit groups BGPpolicy logical-systems HN-NPE1]

policy-options {
policy-statement BGP-HN-TO-CORE {
// This term allow all LDP/BGP route with length /32 from inet.3 tablet on HN-NPE1 to be
advertise to its BGP peer on the core zone (HN-RR in particular)
//Which mean all LDP/BGP route to access router’s loopback will be advertise to HN-RR
term INET3-LOOPBACK {
from {
protocol [ bgp ldp ];
rib inet.3;

// 0.0.0.0/0 mean everything-every routes will be advertised, but the net mask length is
limited to /32 only (/32 mean loopback address – allow for next-hop reachability
resolution)
route-filter 0.0.0.0/0 prefix-length-range /32-/32;
}
then {
//NPE will change the BGP next-hop of these routes to itself (HN-NPE1 in this example)
before advertising them into the core
next-hop self;
accept;
}
}
term INET3-NOTLOOPBACK {
from {
rib inet.3;
//All other routes which do not have net mask length /32 is not loopback address and
should be suspended from advertising into the core
route-filter 0.0.0.0/0 prefix-length-range /0-/31;
}
then reject;
}

31
 }
}

Additionally, we have two term that help advertising the aggregated/summed loopback address of
access zone – but in inet.0 table :

[edit groups BGPpolicy logical-systems HN-NPE1]

policy-options {
//Note that by default, BGP export policy is applied for route in inet.0 , so we do not
have to specify a table (rib) here.
term INET0 {
from {
//Aggreate route must be created as mentioned above
protocol aggregate;
//We have created prefix-list name HN-LOOPBACK-RANGE which mapped to 10.0.1.0/24.
Alternately, trainee can specify route-filter 10.0.1.0/24 exact here
prefix-list-filter HN-LOOPBACK-RANGE exact;
}
then {
//This loopback range will also have their BGP next-hop changed to NPE’s loopback,
because routers in the core and other zone only know about NPE’s address
next-hop self;
accept;
}
}
//All other route from access zone should not be populated into the core
term INET0-DEFAULT {
from family inet;
then reject;
}
}
}

b. Direction 2 : from core to access

On NPE routers, to apply export policy when exporting route from core zone to access zone. We apply it
in BGP group NPEtoACCES– the BGP group in which the BGP peer in access zone is configured.

[edit groups BGPpolicy logical-systems HN-NPE1]

protocols {
bgp {
group NPEtoACCESS {
export BGP-CORE-TO-HN;
}
}
}

The configuration of the policy named BGP-CORE-TO-HN consist of two main part, the first two term
handle route from inet.3 table

32
[edit groups BGPpolicy logical-systems HN-NPE1]
policy-options {
policy-statement BGP-CORE-TO-HN {
// This term allow all LDP/BGP route with length /32 from inet.3 tablet on HN-NPE1 to be
advertise to its BGP peer on the access zone (HN-UPEx in particular)
//Which mean all LDP/BGP route to core router’s loopback will be advertise to HN-UPEx
term INET3-LOOPBACK {
from {
protocol [ bgp ldp ];
rib inet.3;
// 0.0.0.0/0 mean everything-every routes will be advertised, but the net mask length is
limited to /32 only (/32 mean loopback address – allow for next-hop reachability
resolution)
route-filter 0.0.0.0/0 prefix-length-range /32-/32;
}
then {
//NPE will change the BGP next-hop of these routes to itself (HN-NPE1 in this example)
before advertising them to access routers
next-hop self;
accept;
}
}
term INET3-NOTLOOPBACK {
from {
//All other routes which do not have net mask length /32 is not loopback address and
should not be advertised to UPE routers
rib inet.3;
route-filter 0.0.0.0/0 prefix-length-range /0-/31;
}
then reject;
}
}

Additionally, we have two term that help advertising the aggregated/summed loopback address of the
core and other remote access zones into the access zone of that particular NPE

edit groups BGPpolicy logical-systems HN-NPE1]

policy-options {
policy-statement BGP-HN-TO-CORE {
// This term allow all LDP/BGP route with length /32 from inet.3 tablet on HN-NPE1 to be
advertise to its BGP peer on the core zone (HN-RR in particular)
//Which mean all LDP/BGP route to access router’s loopback will be advertise to HN-RR
term INET3-LOOPBACK {

[edit groups BGPpolicy logical-systems HN-NPE1]

policy-options {
policy-statement BGP-CORE-TO-HN {
term INET0 {
from {

33
// This term should look in inet.0 table for routes to reach other access area – which
NPE received from HN-RR so the protocol must be BGP instead of aggregate
protocol bgp;
// On this router we already created prefix-list name HCM-LOOPBACK-RANGE which mapped to
10.0.2.0/24. Alternately, trainee can specify route-filter 10.0.2.0/24 exact here
prefix-list-filter HCM-LOOPBACK-RANGE exact;
}
then {
//This loopback range will also have their BGP next-hop changed to local NPE’s loopback
(HN-NPE1 in this example) because UPE routers in the HN access zone do not know anything
about the core or other zone’s NPE address
next-hop self;
accept;
}
}
//Everything else that is not loopback summed range should be rejected
term INET0-DEFAULT {
from family inet;
then reject;
}
}
}

2.3.5. BGP policy verification

a. INET.0
First of all, two RR router should have the summed loopback range of all access area

juniper@vMX# run show route protocol bgp logical-system HN-RR table inet.0
inet.0: 32 destinations, 33 routes (32 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
//Carefully check that HN-RR should receive TWO route to HN access zone summed address,
with two different next-hop, because both HN-NPE router should be advertising them with
itself as the next-hop

10.0.1.0/24 *[BGP/170] 00:41:50, localpref 100, from 10.0.1.11

AS path: I, validation-state: unverified
> to 3.0.0.8 via ge-0/0/4.35, Push 299872
[BGP/170] 00:00:19, localpref 100, from 10.0.1.12
AS path: I, validation-state: unverified
> to 3.0.0.10 via ge-0/0/3.36, Push 299792
10.0.2.0/24 *[BGP/170] 00:41:43, localpref 100, from 10.0.3.23
AS path: I, validation-state: unverified
> to 3.0.0.8 via ge-0/0/4.35, Push 300064

juniper@vMX# run show route protocol bgp logical-system HCM-RR table inet.0

inet.0: 32 destinations, 33 routes (32 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both
//Carefully check that HCM-RR should receive TWO route to HCM access zone summed
address, with two different next-hop, because both HCM-NPE router should be advertising
them with itself as the next-hop

34
10.0.1.0/24 *[BGP/170] 00:45:03, localpref 100, from 10.0.3.13
AS path: I, validation-state: unverified
> to 3.0.0.12 via ge-0/0/4.37, Push 300080
10.0.2.0/24 *[BGP/170] 00:45:11, localpref 100, from 10.0.2.11
AS path: I, validation-state: unverified
> to 3.0.0.12 via ge-0/0/4.37, Push 299776
[BGP/170] 00:45:07, localpref 100, from 10.0.2.12
AS path: I, validation-state: unverified
> to 3.0.0.14 via ge-0/0/3.38, Push 299776

Any UPE routers should have – (but not mandatory for most service to function) - a inet.0 route to all
other access area summed loopback

juniper@vMX# run show route protocol bgp logical-system HCM-UPE1 table inet.0

inet.0: 12 destinations, 13 routes (12 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both
//Each UPE should received two route from two NPE routers to reach remote access zones,
if only one or none is present – double check the configuration on all NPE and RR

10.0.1.0/24 *[BGP/170] 00:47:10, localpref 100, from 10.0.2.11

AS path: I, validation-state: unverified
> to 2.0.0.0 via ge-0/0/2.21
[BGP/170] 00:47:10, localpref 100, from 10.0.2.12
AS path: I, validation-state: unverified
to 2.0.0.0 via ge-0/0/2.21, Push 300144
> to 2.0.0.3 via ge-0/0/3.22, Push 299776

juniper@vMX# run show route protocol bgp logical-system HN-UPE2 table inet.0

inet.0: 14 destinations, 15 routes (14 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both
//Each UPE should received two route from two NPE routers to reach remote access zones,
if only one or none is present – double check the configuration on all NPE and RR

10.0.2.0/24 *[BGP/170] 00:49:17, localpref 100, from 10.0.1.11

AS path: I, validation-state: unverified
> to 1.0.0.2 via ge-0/0/4.12, Push 299824
[BGP/170] 00:07:54, localpref 100, from 10.0.1.12
AS path: I, validation-state: unverified
> to 1.0.0.5 via ge-0/0/3.13, Push 299792

//Also, the next-hop for these route on UPE routers should be the local NPE router
juniper@vMX# run show route protocol bgp logical-system HN-UPE2 table inet.0 detail
inet.0: 14 destinations, 15 routes (14 active, 0 holddown, 0 hidden)
10.0.2.0/24 (2 entries, 1 announced)
*BGP Preference: 170/-101
Next hop type: Indirect
Address: 0x97a797c
Next-hop reference count: 3
Source: 10.0.1.11
Next hop type: Router, Next hop index: 1955
Next hop: 1.0.0.2 via ge-0/0/4.12, selected
Label operation: Push 299824
Label TTL action: prop-ttl
Load balance label: Label 299824: None;

35
 Session Id: 0x700004
Protocol next hop: 10.0.1.11
Indirect next hop: 0x95c5ed0 1048620 INH Session ID: 0x700007
State: <Active Int Ext>
Local AS: 18403 Peer AS: 18403
Age: 51:09 Metric2: 20
Validation State: unverified
Task: BGP_18403.10.0.1.11+179
Announcement bits (2): 1-KRT 5-Resolve tree 4
AS path: I (Originator)
Aggregator: 18403 10.0.2.11
Cluster list: 1.1.1.10 1.1.1.1 2.2.2.2
Originator ID: 10.0.2.11
Accepted
Localpref: 100
Router ID: 10.0.1.11
BGP Preference: 170/-101
Next hop type: Indirect
Address: 0x968025c
Next-hop reference count: 1
Source: 10.0.1.12
Next hop type: Router
Next hop: 1.0.0.5 via ge-0/0/3.13, selected
Label operation: Push 299792
Label TTL action: prop-ttl
Load balance label: Label 299792: None;
Session Id: 0x0
Protocol next hop: 10.0.1.12
Indirect next hop: 0x95c6530 - INH Session ID: 0x0
State: <NotBest Int Ext>
Inactive reason: Not Best in its group - Update source
Local AS: 18403 Peer AS: 18403
Age: 9:46 Metric2: 20
Validation State: unverified
Task: BGP_18403.10.0.1.12+52656
AS path: I (Originator)
Aggregator: 18403 10.0.2.11
Cluster list: 1.1.1.10 1.1.1.1 2.2.2.2
Originator ID: 10.0.2.11
Accepted
Localpref: 100
Router ID: 10.0.1.12

b. INET.3
INET.3 table on all BGP participated router should reach complete synchronization – that is – every
BGP-enabled router should have LDP route to other BGP-enabled router regardless of area/zones. This
ensure reachability for all VPN next-hop resolution

juniper@vMX> show route table inet.3 logical-system HN-UPE1 | match /32 | count
Count: 15 lines

36
juniper@vMX> show route table inet.3 logical-system HN-UPE2 | match /32 | count
Count: 15 lines

juniper@vMX> show route table inet.3 logical-system HN-NPE1 | match /32 | count
Count: 15 lines

juniper@vMX> show route table inet.3 logical-system HN-NPE2 | match /32 | count
Count: 15 lines

juniper@vMX> show route table inet.3 logical-system HN-RR | match /32 | count
Count: 15 lines

juniper@vMX> show route table inet.3 logical-system HCM-UPE1 | match /32 | count
Count: 15 lines

juniper@vMX> show route table inet.3 logical-system HCM-UPE2 | match /32 | count
Count: 15 lines

juniper@vMX> show route table inet.3 logical-system HCM-NPE1 | match /32 | count
Count: 15 lines

juniper@vMX> show route table inet.3 logical-system HCM-NPE2 | match /32 | count
Count: 15 lines

juniper@vMX> show route table inet.3 logical-system HCM-RR | match /32 | count
Count: 15 lines

juniper@vMX> show route table inet.3 logical-system HCM-RR | match /32

10.0.1.11/32 *[LDP/9] 01:40:49, metric 20
10.0.1.12/32 *[LDP/9] 01:40:49, metric 20
10.0.1.101/32 *[BGP/170] 00:59:24, MED 10, localpref 100, from 10.0.1.11
10.0.1.102/32 *[BGP/170] 00:59:24, MED 20, localpref 100, from 10.0.1.11
10.0.1.103/32 *[BGP/170] 00:59:20, MED 10, localpref 100, from 10.0.1.12
10.0.2.11/32 *[LDP/9] 01:40:49, metric 30
10.0.2.12/32 *[LDP/9] 01:40:49, metric 30
10.0.2.101/32 *[BGP/170] 00:59:17, MED 10, localpref 100, from 10.0.3.23
10.0.2.102/32 *[BGP/170] 00:59:17, MED 10, localpref 100, from 10.0.3.23
10.0.3.11/32 *[LDP/9] 01:40:49, metric 10
10.0.3.12/32 *[LDP/9] 01:40:49, metric 10
10.0.3.13/32 *[BGP/170] 00:59:24, MED 20, localpref 100, from 10.0.1.11
10.0.3.21/32 *[LDP/9] 01:40:49, metric 20
10.0.3.22/32 *[LDP/9] 01:40:49, metric 20
10.0.3.23/32 *[LDP/9] 01:40:49, metric 30

37
 2.4. RSVP Case study1: 1-hop RSVP on access network

2.4.1. RSVP overview & clarification:

Clarification: The core network simulated in this lab is a simplified one – which only represent a
small part of the real core network. LDP is sufficient for this core to provide MPLS transport
service for the access areas, so on this case study RSVP configuration is only perform on the
access network - according to the scope of this project.

After completing section 2.1, 2.2, 2.3 and 2.4 – trainee can already proceed to service configuration
because LDP has provided sufficed infrastructure for these service to run.

However, In order to give mpls protection for LDP protocol, according to HLD and LLD we will deploy
LDP tunneling over one-hop rsvp-lsp:

 one-hop rsvp-lsp between any routers in access ring, with link-protection

 LDP tunneling over rsvp LSP

But please note that example for traffic-engineering capability of RSVP will be limited due to this
design and the configuration perform here is very minimal.

38
 2.4.2. RSVP configuration template
RSVP configuration preparation is also similar to LDP, which include:

 Enable family mpls on all interface planned to run LDP

 Enable interfaces in protocol mpls

We already perform these two step with LDP – so we can go straight to creating label switched path
(LSP) for RSVP. Two step are needed:

 Enable interfaces in protocol rsvp with necessary authentication and protection parameter
 Creating one-hop LSP on protocol mpls hierarchy.

a. Interface configuration
RSVP interface will be created with the following parameter

[edit groups RSVP logical-systems HN-UPE1]

protocols {
rsvp {
interface ge-0/0/2.11 {
// Authentication key must match on both side of the link
authentication-key "$9$k.Tzn/CuBI"; ## SECRET-DATA
// “aggregate” and “reliable” are for RSVP refresh message reduction
aggregate;
reliable;
// allow rsvp to use this interface for link-protection to benefit from this feature of
rsvp
link-protection;
}
interface ge-0/0/3.12 {
authentication-key "$9$YUgZUik.5z3"; ## SECRET-DATA
aggregate;
reliable;
link-protection;
}
}
}

Note that RSVP neighbor will NOT come up after we enable rsvp on all interface of all participating
routers. These neighbor only come up once we have create an RSVP-signaled LSP that use the link

[edit]
juniper@vMX# run show rsvp neighbor logical-system HN-UPE1
RSVP neighbor: 0 learned

[edit]
juniper@vMX# run show rsvp neighbor logical-system HN-UPE2
RSVP neighbor: 0 learned

[edit]
juniper@vMX# run show rsvp neighbor logical-system HN-NPE1
RSVP neighbor: 0 learned

39
[edit]
juniper@vMX# run show rsvp neighbor logical-system HN-NPE1
RSVP neighbor: 0 learned

// Although neighbor is not coming up – we can verify the interface stateto see if they
are recognized by rsvp protocol
[edit]
juniper@vMX# run show rsvp interface logical-system HN-UPE1
RSVP interface: 2 active
Active Subscr- Static Available Reserved Highwater
Interface State resv iption BW BW BW mark
ge-0/0/2.11 Up 0 100% 1000Mbps 1000Mbps 0bps 0bps
ge-0/0/3.12 Up 0 100% 1000Mbps 1000Mbps 0bps 0bps

[edit]
juniper@vMX# run show rsvp interface logical-system HN-UPE2
RSVP interface: 2 active
Active Subscr- Static Available Reserved Highwater
Interface State resv iption BW BW BW mark
ge-0/0/3.13 Up 0 100% 1000Mbps 1000Mbps 0bps 0bps
ge-0/0/4.12 Up 0 100% 1000Mbps 1000Mbps 0bps 0bps

[edit]
juniper@vMX# run show rsvp interface logical-system HN-NPE1
RSVP interface: 3 active
Active Subscr- Static Available Reserved Highwater
Interface State resv iption BW BW BW mark
ge-0/0/1.11 Up 0 100% 1000Mbps 1000Mbps 0bps 0bps
ge-0/0/2.311Up 0 100% 1000Mbps 1000Mbps 0bps 0bps
ge-0/0/3.15 Up 0 100% 1000Mbps 1000Mbps 0bps 0bps

b. One-hop RSVP LSP

One-hop mean that on each router of an access zone we will only create RSVP LSP to its immediate
neighbor router. Such restriction is not belong to RSVP – but rather according to design.

RSVP LSP is created in [edit protocol mpls] hierarchy of each logical-system. Example on HN-UPE2

[edit groups RSVP logical-systems HN-UPE2]

protocols {
mpls {
// allow ICMP diagnostic packets to be forwarded inside LSP tunnel
icmp-tunneling;
label-switched-path HN-UPE2_to_HN-UPE1 {
// The egress router for this LSP will be HN-UPE2 – use loobback address which must be
reachable via IGP
to 10.0.1.101;
// Enables LSP tunnelling on the LSP
ldp-tunneling;
// Enables link-protection feature for this LSP
link-protection;
}
label-switched-path HN-UPE2_to_HN-UPE3 {
to 10.0.1.103;
ldp-tunneling;

40
 link-protection;
}
}
}
After the LSP has been created, on HN-UPE2 we will see RSVP neighbor come up. We can also check
the LSP that use HN-UPE2 as ingress point

[edit groups RSVP logical-systems HN-UPE2]

juniper@vMX# run show rsvp neighbor logical-system HN-UPE2
RSVP neighbor: 2 learned
Address Idle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd
1.0.0.5 0 0/0 4 9 0/0 2
1.0.0.2 0 0/0 4 9 0/0 2

[edit groups RSVP logical-systems HN-UPE2]

juniper@vMX# run show mpls lsp logical-system HN-UPE2
Ingress LSP: 2 sessions
To From State Rt P ActivePath LSPname
10.0.1.101 10.0.1.102 Up 0 * HN-UPE2_to_HN-UPE1
10.0.1.103 10.0.1.102 Up 0 * HN-UPE2_to_HN-UPE3
Total 2 displayed, Up 2, Down 0

Egress LSP: 0 sessions

Total 0 displayed, Up 0, Down 0

Transit LSP: 0 sessions

Total 0 displayed, Up 0, Down 0

After full configuration, carefully verify LSP state in all three category (Ingress/Egress/Transit) on each
router, make sure no LSP is marked as down. If any LSP Ingress/Egress LSP is down, double check the
interface and LSP configuration on both Ingress/Egress router

[edit]
juniper@vMX# run show mpls lsp logical-system HN-UPE1
Ingress LSP: 2 sessions
To From State Rt P ActivePath LSPname
10.0.1.11 10.0.1.101 Up 0 * HN-UPE1_to_HN-NPE1
10.0.1.102 10.0.1.101 Up 0 * HN-UPE1_to_HN-UPE2
Total 2 displayed, Up 2, Down 0

Egress LSP: 4 sessions

To From State Rt Style Labelin Labelout LSPname
10.0.1.101 10.0.1.102 Up 0 1 SE 3 - HN-UPE2_to_HN-UPE1
10.0.1.101 10.0.1.102 Up 0 1 SE 3 - Bypass->1.0.0.2
10.0.1.101 10.0.1.11 Up 0 1 SE 3 - HN-NPE1_to_HN-UPE1
10.0.1.101 10.0.1.11 Up 0 1 SE 3 - Bypass->1.0.0.0
Total 4 displayed, Up 4, Down 0

Transit LSP: 4 sessions

To From State Rt Style Labelin Labelout LSPname
10.0.1.12 10.0.1.103 Up 0 1 SE 300064 301376 Bypass->1.0.0.7
10.0.1.102 10.0.1.103 Up 0 1 SE 300048 3 Bypass->1.0.0.4
10.0.1.103 10.0.1.102 Up 0 1 SE 299952 300544 Bypass->1.0.0.5
10.0.1.103 10.0.1.12 Up 0 1 SE 300080 300096 Bypass->1.0.0.6

41
Total 4 displayed, Up 4, Down 0
^
syntax error.
juniper@vMX# run show mpls lsp logical-system HN-NPE1
Ingress LSP: 2 sessions
To From State Rt P ActivePath LSPname
10.0.1.12 10.0.1.11 Up 0 * HN-NPE1_to_HN-NPE2
10.0.1.101 10.0.1.11 Up 0 * HN-NPE1_to_HN-UPE1
Total 2 displayed, Up 2, Down 0

Egress LSP: 3 sessions

To From State Rt Style Labelin Labelout LSPname
10.0.1.11 10.0.1.101 Up 0 1 SE 3 - HN-UPE1_to_HN-NPE1
10.0.1.11 10.0.1.101 Up 0 1 SE 3 - Bypass->1.0.0.1
10.0.1.11 10.0.1.12 Up 0 1 SE 3 - HN-NPE2_to_HN-NPE1
Total 3 displayed, Up 3, Down 0

Transit LSP: 6 sessions

To From State Rt Style Labelin Labelout LSPname
10.0.1.12 10.0.1.103 Up 0 1 SE 301376 3 Bypass->1.0.0.7
10.0.1.101 10.0.1.102 Up 0 1 SE 300528 3 Bypass->1.0.0.2
10.0.1.102 10.0.1.103 Up 0 1 SE 301392 300048 Bypass->1.0.0.4
10.0.1.102 10.0.1.101 Up 0 1 SE 301424 301488 Bypass->1.0.0.3
10.0.1.103 10.0.1.102 Up 0 1 SE 300544 300560 Bypass->1.0.0.5
10.0.1.103 10.0.1.12 Up 0 1 SE 301408 300080 Bypass->1.0.0.6
Total 6 displayed, Up 6, Down 0

2.4.3. Tunneling verification

As mentioned above, LDP will still work without RSVP configuration in section 2.4. Before enabling
RSVP configuration, we can verify this with traceroute mpls ldp command

// Either remove application of RSVP group of perform the check before commit RSVP
configuration
[edit]
juniper@vMX delete apply-groups RSVP

[edit]
juniper@vMX# commit
commit complete

// It’s best to verify by tracing between hops that are not directly connected

[edit]
juniper@vMX# run traceroute mpls ldp 10.0.1.12 logical-system HN-UPE2
Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16

ttl Label Protocol Address Previous Hop Probe Status

1 300112 LDP 1.0.0.5 (null) Success
2 3 LDP 1.0.0.7 1.0.0.5 Egress

Path 1 via ge-0/0/3.13 destination 127.0.0.64

42
[edit]
juniper@vMX# run traceroute mpls ldp 10.0.1.103 logical-system HN-UPE1
Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16

ttl Label Protocol Address Previous Hop Probe Status

1 300192 LDP 1.0.0.3 (null) Success
2 3 LDP 1.0.0.5 1.0.0.3 Egress

Path 1 via ge-0/0/3.12 destination 127.0.0.64

// However note that tracing to other access area will not work because their presence
in inet.3 table is under the form of BGP routes

After one-hop RSVP-LSP tunneling has been completed, we can verify the tunneling state with the same
command

// Now we apply RSVP configuration and perform the same command

[edit]
juniper@vMX# set apply-groups RSVP

[edit]
juniper@vMX# commit
commit complete

// Note that the only the first tranport link on the path use LDP, after that they use
RSVP-TE rather than LDP as before
[edit]
juniper@vMX# run traceroute mpls ldp 10.0.1.103 logical-system HN-UPE1
Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16

ttl Label Protocol Address Previous Hop Probe Status

1 300304 LDP 1.0.0.3 (null) Success
2 3 RSVP-TE 1.0.0.5 1.0.0.3 Egress

Path 1 via ge-0/0/3.12 destination 127.0.0.64

[edit]
juniper@vMX# run traceroute mpls ldp 10.0.1.12 logical-system HN-UPE2
Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16

ttl Label Protocol Address Previous Hop Probe Status

1 300192 LDP 1.0.0.5 (null) Success
2 3 RSVP-TE 1.0.0.7 1.0.0.5 Egress

Path 1 via ge-0/0/3.13 destination 127.0.0.64

// For further verification, trainnee can try deactive the link between HN-UPE1 and HN-
NPE1 and observe that all path from HN-UPE1 to HN-NPE2 use RSVP-TE – except for the
first link when traffic leave ingress router
[edit]
juniper@vMX# set logical-systems HN-UPE1 interfaces ge-0/0/2.11 disable

43
[edit]
juniper@vMX# commit
commit complete

[edit]
juniper@vMX# run traceroute mpls ldp 10.0.1.12 logical-system HN-UPE1
Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16

ttl Label Protocol Address Previous Hop Probe Status

1 300336 LDP 1.0.0.3 (null) Success
2 3 RSVP-TE 1.0.0.5 1.0.0.3 Success
3 3 RSVP-TE 1.0.0.7 1.0.0.5 Egress

Path 1 via ge-0/0/3.12 destination 127.0.0.64

44
 2.5. RSVP Case study2: RSVP across the core network

For a more detailed illustration of LDP tunnel over RSVP, we can setup RSVP signaled LSP in the core
network according to the following diagram

2.5.1. RSVP in the core configuration template

a. Interface configuration
RSVP interface configuration is similar to Case study 1- with the same parameter.

Note that RR-CORE router connection do not always need a RSVP sessions enabled

b. One-hop RSVP LSP

In this case – RSVP signaled LSP will be created from NPEs to remote and peering NPE.

Note that LSP is unidirectional and thus each NPE router would require three LSP to the other three
NPE router. The parameter is similar to the previous case

[edit groups RSVP-Core logical-systems HN-NPE1]

juniper@vMX# show
protocols {
mpls {
icmp-tunneling;
label-switched-path HN-NPE1_to_HCM-NPE1 {
to 10.0.2.11;

45
 ldp-tunneling;
link-protection;
}
label-switched-path HN-NPE1_to_HCM-NPE2 {
to 10.0.2.12;
ldp-tunneling;
link-protection;
}
label-switched-path HN-NPE1_to_HN-NPE2 {
to 10.0.1.12;
ldp-tunneling;
link-protection;
}
}
}

2.5.2. Tunneling verification

First, verify that each NPE router has been correctly set up with three ingress LSP to the correct
destination

juniper@vMX# run show mpls lsp ingress logical-system HN-NPE1

Ingress LSP: 3 sessions
To From State Rt P ActivePath LSPname
10.0.1.12 10.0.1.11 Up 0 * HN-NPE1_to_HN-NPE2
10.0.2.11 10.0.1.11 Up 0 * HN-NPE1_to_HCM-NPE1
10.0.2.12 10.0.1.11 Up 0 * HN-NPE1_to_HCM-NPE2
Total 3 displayed, Up 3, Down 0

As depicted in case study 1, the core do not require RSVP to work properly. Before enabling RSVP in
the core – LDP tracing work from HN-NPE to HCM-NPE with pure LDP

juniper@vMX# run traceroute mpls ldp 10.0.2.11 logical-system HN-NPE1

Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16

ttl Label Protocol Address Previous Hop Probe Status

1 299968 LDP 3.1.0.1 (null) Success
2 299776 LDP 3.0.0.1 3.1.0.1 Success
3 3 LDP 3.2.0.1 3.0.0.1 Egress

Path 1 via ge-0/0/2.311 destination 127.0.0.64

After enabling RSVP with ldp-tunneling – LDP will make use of RSVP signaled LSP when traversing
from NPE to NPE

juniper@vMX# run traceroute mpls ldp 10.0.2.11 logical-system HN-NPE1

Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16

46
ttl Label Protocol Address Previous Hop Probe Status
1 300128 LDP 3.1.0.1 (null) Success
2 300096 RSVP-TE 3.0.0.1 3.1.0.1 Success
3 3 RSVP-TE 3.2.0.1 3.0.0.1 Egress

Path 1 via ge-0/0/2.311 destination 127.0.0.64

47
 3. Service deployment

//For simplicity – Both RR router will be removed from the illustrations in this section – since they only
service in advertising the VPN route (all case as illustrated in section 2.3.4) – but do not participate in
the forwarding of traffic.

//If trainee use different virtual machine setup from section 1 – please make sure that ALL CE facing
interface must be dedicated – that is they are not used in the core and do not connect to the same
VMware VMnet with the core interface, to ensure they can only reach each other via traversing the
MPLS core.

3.1. L3VPN

3.1.1. Planning & perquisite:

Each L3VPN customer will belong to a specific routing-instance with instance-type set to vrf. To
determine a customer and that customer’s site, we have two most important parameter

 Route target: (RT) is in essence a BGP community tag attached to a VPN route to determine that
route belong to which customer/L3VPN channel. In this lab, all Route target will take the form
target:18403:XX in which XX is a VPN identifier assign to a customer (10 for Customer1 and
20 for Customer2). There are two way to specify a route target for a routing-instance
o First is to use route-target target:18403:XX statement placed inside routing-instance
configuration. That VPN/routing-instance will only accept/advertise route with the
specified RT
o Second is to use vrf-export policy to specify how communities field is attached to a
route when that route is being advertised from PE to other routers, then use vrf-import
policy to specify how PE accept route into routing-instance. Detail will be provided in the
next section.
 Route distinguisher: Another field attached to a route to determine which site of the customer
that route is coming from. In this Lab we will be using RD in the form RouterID:L3vpnID with
o RouterID being the 4 last digit in the UPE router’s ISO address’s system ID,
o L3vpnID being 10 for Customer 1, 20 for customer 2
o For example routing instance for Customer 2 on HN-UPE1 will have RD 1101:20.

Aside from RD and RT, we will specify the CE facing interface on UPE router with vlan-tagging
(thought not mandatory) and place them into the routing instance according to the following
diagram.

48
[edit groups L3VPN]
interfaces {
ge-0/0/5 {
flexible-vlan-tagging;
}
ge-0/0/6 {
flexible-vlan-tagging;
}
}

In this lab two Customer will be deployed for illustration

 Customer1 will be configure with vrf-import and vrf-export method

 Customer2 will be configure via route-target statement

As specified on the diagram, on two CE router will be configured. On HN-UPE1 and HN-UPE3 instead
of connecting a CE we will create a static route in received mode in routing instance to simulate a route
to customer’s network.

For L3VPN - mandatory configuration on all BGP-enabled router is to enable BGP’s support for
advertisement of inet-vpn routes (or in other word enable MP-BGP – multiprotocol BGP)

49
[edit groups L3VPN]
logical-systems {
<*> {
protocols {
bgp {
family inet-vpn {
unicast;
}
}
}
}
}

3.1.2. Configuration example for Customer2 (quick method)

On HN-UPE1 and HN-UPE3, we specified the planned parameter for routing-instance L3VPN-
CUSTOMER2. The static received route and loopback address are optional and for illustration purpose
only.

[edit groups L3VPN logical-systems HN-UPE3]

interfaces {
lo0 {
unit 123 {
family inet {
address 6.0.0.129/32;
}
}
}
}
routing-instances {
L3VPN-CUSTOMER2 {
// Instance-type must be vrf for L3VPN configuration
instance-type vrf;
// Interface configuration for this customer is for observation purpose only – omitting
cause no problem
interface lo0.123;
// Instance-type must be vrf for L3VPN configuration

route-distinguisher 1103:20;
// vrf-target statement is equivalent to the automatic creation of both vrf-import and
vrf-export with matching community target:18403

vrf-target target:18403:20;
// vrf-table-label statement will let PE router automatically assign a VPN label for
each VRF – detail in section 3.1.5
vrf-table-label;
routing-options {
static {
// static route creation is for observation on remote PE only.
route 6.0.0.128/25 receive;
}
}
}
}

50
[edit groups L3VPN logical-systems HN-UPE1]
interfaces {
lo0 {
unit 122 {
family inet {
address 6.0.0.1/32;
}
}
}
}
routing-instances {
L3VPN-CUSTOMER2 {
instance-type vrf;
interface lo0.122;
route-distinguisher 1102:20;
vrf-target target:18403:20;
vrf-table-label;
routing-options {
static {
route 6.0.0.0/25 receive;
}
auto-export;
}
}
}

3.1.3. Common verification for L3VPN:

To verify the routes currently active in a routing instance –remember to include the table + instance-
name statement.

juniper@vMX> show route logical-system HN-UPE3 table L3VPN-CUSTOMER2

L3VPN-CUSTOMER2.inet.0: 4 destinations, 6 routes (4 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both
//we can see that the route belong to CUSTOMER2 located on router HN-UPE1 is reachable
from the L3VPN-CUSTOMER2 routing instance located on HN-UPE3

6.0.0.0/25 *[BGP/170] 00:07:20, localpref 100, from 10.0.1.11

AS path: I, validation-state: unverified
> to 1.0.0.4 via ge-0/0/4.13, label-switched-path HN-UPE3_to_HN-UPE2
to 1.0.0.7 via ge-0/0/2.14, label-switched-path HN-UPE3_to_HN-UPE2
[BGP/170] 00:07:20, localpref 100, from 10.0.1.12
AS path: I, validation-state: unverified
> to 1.0.0.4 via ge-0/0/4.13, label-switched-path HN-UPE3_to_HN-UPE2
to 1.0.0.7 via ge-0/0/2.14, label-switched-path HN-UPE3_to_HN-UPE2
//note that for each route/prefix to HN-UPE1, HN-UPE2 should receive two advertisement –
one from NPE1 and another from NPE2 as highlighted below
6.0.0.1/32 *[BGP/170] 00:07:19, localpref 100, from 10.0.1.11
AS path: I, validation-state: unverified
> to 1.0.0.4 via ge-0/0/4.13, label-switched-path HN-UPE3_to_HN-UPE2
to 1.0.0.7 via ge-0/0/2.14, label-switched-path HN-UPE3_to_HN-UPE2
[BGP/170] 00:07:20, localpref 100, from 10.0.1.12

51
 AS path: I, validation-state: unverified
> to 1.0.0.4 via ge-0/0/4.13, label-switched-path HN-UPE3_to_HN-UPE2
to 1.0.0.7 via ge-0/0/2.14, label-switched-path HN-UPE3_to_HN-UPE2
6.0.0.128/25 *[Static/5] 00:07:25
Receive
6.0.0.129/32 *[Direct/0] 00:07:21
> via lo0.123

//Observe the same result on HN-UPE1 to ensure bidirectional reachability

juniper@vMX> show route logical-system HN-UPE1 table L3VPN-CUSTOMER2

L3VPN-CUSTOMER2.inet.0: 4 destinations, 6 routes (4 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

6.0.0.0/25 *[Static/5] 00:11:33

Receive
6.0.0.1/32 *[Direct/0] 00:11:30
> via lo0.122
//Also observe that forwarding resolution is provide via RSVP LSP HN-UPE1_to_HN-UPE2
6.0.0.128/25 *[BGP/170] 00:11:29, localpref 100, from 10.0.1.11
AS path: I, validation-state: unverified
> to 1.0.0.3 via ge-0/0/3.12, label-switched-path HN-UPE1_to_HN-UPE2
to 1.0.0.1 via ge-0/0/2.11, label-switched-path HN-UPE1_to_HN-UPE2
[BGP/170] 00:11:29, localpref 100, from 10.0.1.12
AS path: I, validation-state: unverified
> to 1.0.0.3 via ge-0/0/3.12, label-switched-path HN-UPE1_to_HN-UPE2
to 1.0.0.1 via ge-0/0/2.11, label-switched-path HN-UPE1_to_HN-UPE2
6.0.0.129/32 *[BGP/170] 00:11:29, localpref 100, from 10.0.1.11
AS path: I, validation-state: unverified
> to 1.0.0.3 via ge-0/0/3.12, label-switched-path HN-UPE1_to_HN-UPE2
to 1.0.0.1 via ge-0/0/2.11, label-switched-path HN-UPE1_to_HN-UPE2
[BGP/170] 00:11:29, localpref 100, from 10.0.1.12
AS path: I, validation-state: unverified
> to 1.0.0.3 via ge-0/0/3.12, label-switched-path HN-UPE1_to_HN-UPE2
to 1.0.0.1 via ge-0/0/2.11, label-switched-path HN-UPE1_to_HN-UPE2

If the route is not present in either router, verify if they are being advertise from HN-UPE1/3 to HN-
NPE1/2 ( The route reflector for HN access zone) – and if the vrf-target associated with them is correct

//To verify route advertisement from Site HN-UPE1 to site HN-UPE3 – first check if HN-
UPE1 is advertising the route to HN-NPEx
juniper@vMX> show route advertising-protocol bgp 10.0.1.11 logical-system HN-UPE1
extensive

L3VPN-CUSTOMER2.inet.0: 4 destinations, 6 routes (4 active, 0 holddown, 0 hidden)

* 6.0.0.0/25 (1 entry, 1 announced)

BGP group NPE type Internal
Route Distinguisher: 1102:20
VPN Label: 17
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [18403] I

52
 Communities: target:18403:20

* 6.0.0.1/32 (1 entry, 1 announced)

BGP group NPE type Internal
Route Distinguisher: 1102:20
VPN Label: 17
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [18403] I
Communities: target:18403:20

//Then verify if HN-NPEx has accept the route ( please note that if NPE cannot reach the
BGP next-hop appeared on the above two route – it will hide the route – check and ensure
that not route is hidden

juniper@vMX> show route table bgp.l3vpn logical-system HN-NPE1

//NPE do not have routing instance that have RT match target:18403:20, it only act as
the route reflectr/helper here, so we have to look at bgp.l3vpn table
bgp.l3vpn.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1102:20:6.0.0.0/25
*[BGP/170] 00:18:25, localpref 100, from 10.0.1.101
AS path: I, validation-state: unverified
> to 1.0.0.8 via ge-0/0/3.15, label-switched-path HN-NPE1_to_HN-UPE1
1102:20:6.0.0.1/32
*[BGP/170] 00:18:24, localpref 100, from 10.0.1.101
AS path: I, validation-state: unverified
> to 1.0.0.8 via ge-0/0/3.15, label-switched-path HN-NPE1_to_HN-UPE1

//If NPE has received the route from HN-UPE1 – we then check if they are being
advertised to HN-UPE3
juniper@vMX> show route advertising-protocol bgp 10.0.1.103 logical-system HN-NPE1
extensive
bgp.l3vpn.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)

* 1102:20:6.0.0.0/25 (1 entry, 1 announced)

BGP group NPEtoACCESS type Internal
Route Distinguisher: 1102:20
VPN Label: 17
Nexthop: 10.0.1.101
Localpref: 100
AS path: [18403] I
Communities: target:18403:20
//The cluster presence mean that they are being advertised from a RR
Cluster ID: 1.1.1.10
Originator ID: 10.0.1.101

* 1102:20:6.0.0.1/32 (1 entry, 1 announced)

BGP group NPEtoACCESS type Internal
Route Distinguisher: 1102:20
VPN Label: 17
Nexthop: 10.0.1.101
Localpref: 100
AS path: [18403] I
Communities: target:18403:20

53
//The cluster presence mean that they are being advertised from a RR
Cluster ID: 1.1.1.10
Originator ID: 10.0.1.101

//HN-UPE3 should be accepting these route into its bgp.l3vpn table, then the matched
community will help HN-UPE3 to import them into L3VPN-CUSTOMER2 table

juniper@vMX> show route receive-protocol bgp 10.0.1.11 logical-system HN-UPE1 extensive

bgp.l3vpn.0: 9 destinations, 18 routes (9 active, 0 holddown, 0 hidden)

* 1103:20:6.0.0.128/25 (2 entries, 0 announced)
Import Accepted
Route Distinguisher: 1103:20
//Note that from now on HN-UPE1 will use this VPN label to send packet to this prefix on
this routing instance
VPN Label: 16
Nexthop: 10.0.1.103
Localpref: 100
AS path: I (Originator)
Cluster list: 1.1.1.10
Originator ID: 10.0.1.103
Communities: target:18403:20

* 1103:20:6.0.0.129/32 (2 entries, 0 announced)

Import Accepted
Route Distinguisher: 1103:20
//Note that from now on HN-UPE1 will use this VPN label to send packet to this prefix on
this routing instance
VPN Label: 16
Nexthop: 10.0.1.103
Localpref: 100
AS path: I (Originator)
Cluster list: 1.1.1.10
Originator ID: 10.0.1.103
Communities: target:18403:20
Notice that in this case – the use of vrf-table-label has allow VPN Label 16 to be associated with the
routes for Customer 2 from HN-UPE3. So when HN-UPE1 send packet to 1103:20:6.0.0.129/32 ,
packets will be first associated with VPN label 16 – then the MPLS labels stack used to reach next-hop
10.0.1.103

When we check how HN-UPE3 handle coming in packet with VPN Label 16 – we see that the router
send it to table L3VPN-CUSTOMER2.inet0 for further processing

juniper@vMX> show route table mpls.0 logical-system HN-UPE3 label 16

mpls.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

16 *[VPN/0] 00:33:22
to table L3VPN-CUSTOMER2.inet.0, Pop
// Troubleshooting route advertisement through the core network will be provided in section 3.2.2

54
 3.1.4. Configuration example for Customer1 (detailed method)
To use VRF-IMPORT and VRF-EXPORT for L3VPN routing instance, Perform the following step:

 Chose a community name for Customer1 – map it with the planned RT value
 Configure the import and export policy for L3VPN routing instance
 Configure the routing instance – replace vrf-target configuration with VRF-IMPORT and
VRF-EXPORT mapped with the corresponding policy.

First we must specify the community name to be associated with a customer and their value in [policy-
opitons] hierarchy in all UPE router connect to that customer.

[edit groups L3VPN logical-systems HN-UPE1 policy-options]

community L3VPN-C1 members target:18403:10;

Then we specify how community will be checked or added when a route is import/export from that
L3VPN routing instance

[edit groups L3VPN logical-systems HN-UPE1]

policy-options {
policy-statement L3VPN-C1-Import {
// this term ensure that all BGP route HN-UPE1 received in bgp.l3vpn of HN-UPE1 that
have community field similar to L3VPN-C1 will be accepted via this policy into routing
instance
term Customer1 {
from {
protocol bgp;
community L3VPN-C1;
}
then accept;
}
// reject all other route that do not have a matched community field
term default {
then reject;
}
}
policy-statement L3VPN-C1-Export {
term Customer1 {
then {
// When advertiseing routes from Customer1’s L3VPN routing instance 1 to other routers–
this term ensure a community field match L3VPN-1 will be added to those routes
community add L3VPN-C1;
accept;
}
}
// This term is a place holder – not mandatory (because all route from Customer1 L3VPN
routing instance is exported due to term Customer1)
term default {
then reject;
}
}

55
}

Then configure the routing instance using the specified policy

[edit groups L3VPN logical-systems HN-UPE1]

routing-instances {
L3VPN-CUSTOMER1 {
instance-type vrf;
route-distinguisher 1101:10;
vrf-import L3VPN-C1-Import;
vrf-export L3VPN-C1-Export;
vrf-table-label;
routing-options {
static {
route 18.0.0.0/24 receive;
}
}
}
}

The verification for this configuration method is totally similar to section 3.1.3

3.1.5. BGP PE-CE link advertisement for L3VPN:

In a VRF, when the directly connected interface towards the CE is a broadcast-type interface, BGP will
not advertise the directly connected network to the remote PE router in L3VPN without vrf-table-label
or some other route to advertise.

Trainee can verify this by configure L3VPN routing-instance for Customer1 according to the diagram

// Configure L3VPN on HN-UPE2 according to the diagram

[edit groups L3VPN logical-systems HN-UPE2]
interfaces {
ge-0/0/5 {
unit 170 {
vlan-id 170;
family inet {
address 17.0.0.1/24;
}
}
}
}
policy-options {
policy-statement L3VPN-C1-Import {
term Customer1 {
from {
protocol bgp;
community L3VPN-C1;
}
then accept;
}
term default {
then reject;

56
 }
}
policy-statement L3VPN-C1-Export {
term Customer1 {
then {
community add L3VPN-C1;
accept;
}
}
term default {
then reject;
}
}
community L3VPN-C1 members target:18403:10;
}
routing-instances {
L3VPN-CUSTOMER1 {
instance-type vrf;
// Remember to put the CE facing interface into routing-instance
interface ge-0/0/5.170;
route-distinguisher 1102:10;
vrf-import L3VPN-C1-Import;
vrf-export L3VPN-C1-Export;
}
}

After this step we can see the router state that the direct link on ge-0/0/5.170 is not being advertise via
MP-BGP

juniper@vMX> show route advertising-protocol bgp 10.0.1.11 logical-system HN-UPE2

L3VPN-CUSTOMER1.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)

Prefix Nexthop MED Lclpref AS path
* 17.0.0.0/24 Not advertised 100 I

// Further detail show that BGP do not see any next-hop on the LAN segment connected to
that CE

juniper@vMX> show route advertising-protocol bgp 10.0.1.11 logical-system HN-UPE2

extensive

L3VPN-CUSTOMER1.inet.0: 8 destinations, 14 routes (8 active, 0 holddown, 0 hidden)

* 17.0.0.0/24 (1 entry, 1 announced)
BGP group NPE type Internal
Route Distinguisher: 1102:10
BGP label allocation failure: Need a nexthop address on LAN
Nexthop: Not advertised
Flags: Nexthop Change
Localpref: 100
AS path: [18403] I
Communities: target:18403:10

There are three method to overcome this

57
 a. vrf-table-label configuration
As mentioned in 3.1.3 – using vrf-table-label allow a specific label to be associated with a route in
L3VPN routing-instance. The router will create a special LSI interface to handle incoming that VPN
label and those route will then be forwarded to the matching table for further processing.

Compare the route above with section 3.1.3 to see the difference.

Trainee can also use the following on HN-UPE1 for Customer1 to observe the desired output

[edit groups L3VPN logical-systems HN-UPE1]

routing-instances {
L3VPN-CUSTOMER1 {
instance-type vrf;
route-distinguisher 1101:10;
vrf-import L3VPN-C1-Import;
vrf-export L3VPN-C1-Export;
vrf-table-label;
routing-options {
static {
route 18.0.0.0/24 receive;
}
}
}
}

On HN-UPE1 - the static route 18.0.0.0/24 will have a VPN label associated, and that label is then
mapped to L3VPN-CUSTOMER1.inet.0 for further processing

juniper@vMX# run show route advertising-protocol bgp 10.0.1.11 logical-system HN-UPE1

extensive

L3VPN-CUSTOMER1.inet.0: 8 destinations, 15 routes (8 active, 0 holddown, 0 hidden)

* 18.0.0.0/24 (1 entry, 1 announced)
BGP group NPE type Internal
Route Distinguisher: 1101:10
VPN Label: 16
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [18403] I
Communities: target:18403:10

juniper@vMX# run show route table mpls.0 logical-system HN-UPE1

mpls.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

0 *[MPLS/0] 07:05:36, metric 1

Receive
1 *[MPLS/0] 07:05:36, metric 1
Receive
2 *[MPLS/0] 07:05:36, metric 1

58
 Receive
13 *[MPLS/0] 07:05:36, metric 1
Receive
16 *[VPN/0] 00:08:46
to table L3VPN-CUSTOMER1.inet.0, Pop
17 *[VPN/0] 00:08:46
to table L3VPN-CUSTOMER2.inet.0, Pop

b. static next-hop configuration

The second method is to configure a static route with a proper next-hop in that routing instace –
typically a static route point to CE’s IP address.

It does not matter which destination we use, the only mandatory is that the next-hop located on CE’s
interface must be reachable

mpls.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)

[edit groups L3VPN logical-systems HN-UPE2]
routing-instances {
routing-options {
static {
// This configuration may seem odds but work normally without any error, since we only
need a contributing static route with a valid next-hop
route 17.0.0.2/32 next-hop 17.0.0.2;
// However in practive we might perfer using something like
route “CE’s looopback” next-hop 17.0.0.2;
}
}
}
}
This method require minimal configuration on CE

// ALL CE CONFIGURATION IS PLACED ON OLIVE VIRTUAL MACHINE

[edit groups L3VPN logical-systems L3CUSTOMER1-CE1]
interfaces {
em1 {
unit 170 {
vlan-id 170;
family inet {
address 17.0.0.2/24;
}
}
}
lo0 {
unit 170 {
family inet {
address 10.0.17.2/32;
}
}
}
}

// In this case, Customer’s CE will have a default route toward provider’s PE

routing-options {

59
 static {
route 0.0.0.0/0 next-hop 17.0.0.1;
}
}

This method will map the VPN label directly to the interface in which the specified next-hop is found

juniper@vMX> show route advertising-protocol bgp 10.0.1.11 logical-system HN-UPE2

extensive

L3VPN-CUSTOMER1.inet.0: 9 destinations, 15 routes (9 active, 0 holddown, 0 hidden)

* 10.0.17.2/32 (1 entry, 1 announced)
BGP group NPE type Internal
Route Distinguisher: 1102:10
VPN Label: 299936
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [18403] I
Communities: target:18403:10

* 17.0.0.0/24 (1 entry, 1 announced)

BGP group NPE type Internal
Route Distinguisher: 1102:10
VPN Label: 299936
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [18403] I
Communities: target:18403:10

juniper@vMX> show route table mpls.0 logical-system HN-UPE2

mpls.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

0 *[MPLS/0] 00:05:08, metric 1

Receive
1 *[MPLS/0] 00:05:08, metric 1
Receive
2 *[MPLS/0] 00:05:08, metric 1
Receive
13 *[MPLS/0] 00:05:08, metric 1
Receive
299936 *[VPN/170] 00:01:53
> to 17.0.0.2 via ge-0/0/5.170, Pop

c. IGP configuration
The last method is for UPE routers to receive at least one IGP route from CE router

60
//Note that all the interface-VMnet mapping must follow section 1 instruction
[edit groups L3VPN logical-systems HCM-UPE1]
interfaces {
ge-0/0/6 {
unit 191 {
vlan-id 191;
family inet {
address 19.0.0.1/29 ;
}
}
}
lo0 {
unit 191 {
family inet {
address 10.0.19.1/32;
}
}
}
}
policy-options {
policy-statement L3VPN-C1-Import {
term Customer1 {
from {
protocol bgp;
community L3VPN-C1;
}
then accept;
}
term default {
then reject;
}
}
policy-statement L3VPN-C1-Export {
term Customer1 {
then {
community add L3VPN-C1;
accept;
}
}
term default {
then reject;
}
}
//This is a simple term created specifically to advertise routes from remote L3VPN sites
to CUSTOMER1’s CE2 via IGP
policy-statement L3VPN-C1-Export-to-CE {
term default {
from protocol bgp;
then accept;
}
}
community L3VPN-C1 members target:18403:10;
}
routing-instances {
L3VPN-CUSTOMER1 {
instance-type vrf;
//Loopback interface and CE facing interface (to be run IGP) must be put inside routing
instance

61
 interface ge-0/0/6.191;
interface lo0.191;
route-distinguisher 2101:10;
vrf-import L3VPN-C1-Import;
vrf-export L3VPN-C1-Export;
//Set the same AS on PE’s routing instance and customer’s CE for IGP to work
routing-options {
autonomous-system 18000;
}
//Running IGP between UPE and CE router require that the protocol configuration is
placed inside routing instance
protocols {
ospf {
area 0.0.0.0 {
export L3VPN-C1-Export-to-CE;
interface lo0.191;
interface ge-0/0/6.191;
}
}
}
}
}

OSPF will require a loopback to be planned and configured on both UPE’s routing instance and CE
router

//Note that these configuration is placed on the Olive virtual machine

[edit groups L3VPN logical-systems L3CUSTOMER1-CE2]
interfaces {
em2 {
unit 191 {
vlan-id 191;
family inet {
address 19.0.0.2/30;
}
}
}

lo0 {
unit 192 {
family inet {
address 10.0.19.2/32;
}
}
}
}
protocols {
ospf {
export C1-OSPF-EXPORT;
area 0.0.0.0 {
//loopback is mandatory
interface lo0.192;
interface em2.191;
}
}
}

62
//This policy help advertise the created static route into PE, then to other site of
Customer 1
policy-options {
policy-statement C1-OSPF-EXPORT {
term static {
from protocol static;
then accept;
}
}
}
routing-options {
static {
route 19.0.0.128/25 receive;
//Set the same AS on PE’s routing instance and customer’s CE for IGP to work
autonomous-system 18000;
}
}

This method will also map the VPN label directly to the interface in which the its associated route’s
next-hop is found

juniper@vMX> show route advertising-protocol bgp 10.0.2.11 logical-system HCM-UPE1

extensive

L3VPN-CUSTOMER1.inet.0: 9 destinations, 12 routes (9 active, 0 holddown, 0 hidden)

* 10.0.19.1/32 (1 entry, 1 announced)
BGP group NPE type Internal
Route Distinguisher: 2101:10
VPN Label: 299808
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [18403] I
Communities: target:18403:10

* 10.0.19.2/32 (1 entry, 1 announced)

BGP group NPE type Internal
Route Distinguisher: 2101:10
VPN Label: 299824
Nexthop: Self
Flags: Nexthop Change
MED: 1
Localpref: 100
AS path: [18403] I
Communities: target:18403:10 rte-type:0.0.0.0:1:0

* 19.0.0.0/30 (1 entry, 1 announced)

BGP group NPE type Internal
Route Distinguisher: 2101:10
VPN Label: 299824
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [18403] I
Communities: target:18403:10

63
* 19.0.0.128/25 (1 entry, 1 announced)
BGP group NPE type Internal
Route Distinguisher: 2101:10
VPN Label: 299824
Nexthop: Self
Flags: Nexthop Change
MED: 0
Localpref: 100
AS path: [18403] I
Communities: target:18403:10 rte-type:0.0.0.0:5:1

//Notice that there is two VPN label associated with routes in L3VPN-CUSTOMER1 table
juniper@vMX> show route table mpls.0 logical-system HCM-UPE1

mpls.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

0 *[MPLS/0] 00:11:15, metric 1

Receive
1 *[MPLS/0] 00:11:15, metric 1
Receive
2 *[MPLS/0] 00:11:15, metric 1
Receive
13 *[MPLS/0] 00:11:15, metric 1
Receive
//299808 label is associated with route 10.0.19.1 which is located on CE’s local
interface – so traffic with this label is forwarded to the routing instance that own
that interface
299808 *[VPN/170] 00:08:54
receive table L3VPN-CUSTOMER1.inet.0, Pop
//Other routes in this routing instance is forward toward CE facing interface
299824 *[VPN/170] 00:08:54
> to 19.0.0.2 via ge-0/0/6.191, Pop

64
 3.2. L2VPN

3.2.1. Planning & perquisite:

Each L2VPN customer connect to a UPE will belong to a specific routing-instance with instance-type
set to l2vpn. To determine a customer and that customer’s site, we also use RT and RD similar to
L3VPN

 Route-target planning will be similar to section 3.1. However for L2VPN we only have 1
customer with VPN identifier 100.
 Route-distinguisher planning is also similar to section 3.1, with Customer1 VPN identifier
change to 100 to avoid conflict with L3VPN.

There are several use case for L2VPN – each require different tagging and encapsulation configuration
on CE facing interface. These configuration will be provided in each case.

All use case require a site-id for each customer CE (or more precisely each customer’s site). We will be
using the follow ID for all use case:

 Site ID 17 for customer1’s CE1 (connected to HN-UPE2)

 Site ID 19 for customer1’s CE2 (connected to HCM-UPE1 )

The following diagram illustrated how site are planned

65
For L2VPN, the common mandatory configuration on all BGP-enabled router is to configure MP-BGP
support for signaling of L2VPN circuit:

//The UseCase name will change according for each case- Each case will require a different group
configuration due to different physical parameter needed to be specified on interface

[edit groups L2VPN-UseCase]

logical-systems {
<*> {
protocols {
bgp {
family l2vpn {
signaling;
}
}
}

66
 3.2.2. Common configuration and verification method:
Each use case only differ in interface configuration – the L2VPN channel verification and customer
service verification shall be the same for all of them. Which include

 Verify L2VPN is up on each UPE router

 Verify reachability from a customer CE to the remote CE

a. Common configuration for L2VPN

The following parts of the configuration can be applied for all case study

//The UseCase name will change according for each case

[edit groups L2VPN-UseCase logical-systems HN-UPE2]
interfaces {
ge-0/0/5 {
unit xx {
description "TO L2VPN CUSTOMER1 - CE1";
//ethernet-ccc for untagged case
//vlan-ccc for tagged case
encapsulation ethernet-ccc/vlan-ccc;
}
}
}
//The policy here is similar to L3VPN case
policy-options {
//However once applied, these import term will take effect when the router import route
to xxx.l2vpn.0 table
policy-statement L2VPN-C1-Import {
term Customer1 {
from {
protocol bgp;
community L2VPN-C1;
}
then accept;
}
term default {
then reject;
}
}

//these export term will take effect when the router export route to bgp.l2vpn table of
other router
policy-statement L2VPN-C1-Export {
term Customer1 {
then {
community add L2VPN-C1;
accept;
}
}
term default {
then reject;
}
}
community L2VPN-C1 members target:18403:100;

67
}
routing-instances {
L2VPN-CUSTOMER1 {
//Instance type is always l2vpn
instance-type l2vpn;
//Unit number is subject to change according to each case study
interface ge-0/0/5.XX;
//RT and RD configuration according to plan
route-distinguisher 1102:100;
vrf-import L2VPN-C1-Import;
vrf-export L2VPN-C1-Export;
//All L2VPN configuration is placed inside protocol l2vpn of a l2vpn instance
protocols {
l2vpn {
//Encapsulation-type will change according to interface encapsulation (which mean it
change for each case study) – the example here is for a non-tagged case
encapsulation-type ethernet;
//Site name can be changed to whatever suite the customer’s description
site local1 {
//Site identifier must always be specified according to plan
site-identifier 17;
// Allow a L2VPN to be established even though the
encapsulation configured on the CE device interface does not match the encapsulation
configured
ignore-encapsulation-mismatch;
//The preference of the site in case of multi-homing
site-preference 200;
//Ignore the MTU configuration set for the physical interface associated
with the local switching interface or with the remote PE router
ignore-mtu-mismatch;

// Specified the CE facing interface in which L2VPN will be enable

interface ge-0/0/5.xx {
//remote-site-id is the site-identifier configured on the remote UPE router of the l2vpn
channel
remote-site-id 19;
}
}
}
}
}
}

// In general, except for interface configuration, L2VPN routing instance is similar on

both side of the L2VPN channel
//The UseCase name will change according for each case
[edit groups L2VPN-UseCase logical-systems HCM-UPE1]
interfaces {
ge-0/0/6 {
unit xx {
description "TO L2VPN CUSTOMER1 - CE1";
//ethernet-ccc for untagged case
//vlan-ccc for tagged case
encapsulation ethernet-ccc/vlan-ccc;
}
}

68
}

policy-options {
policy-statement L2VPN-C1-Import {
term Customer1 {
from {
protocol bgp;
community L2VPN-C1;
}
then accept;
}
term default {
then reject;
}
}
policy-statement L2VPN-C1-Export {
term Customer1 {
then {
community add L2VPN-C1;
accept;
}
}
term default {
then reject;
}
}
community L2VPN-C1 members target:18403:100;
}
routing-instances {
L2VPN-CUSTOMER1 {
instance-type l2vpn;
interface ge-0/0/6.xx;
route-distinguisher 2101:100;
vrf-import L2VPN-C1-Import;
vrf-export L2VPN-C1-Export;
protocols {
l2vpn {
encapsulation-type ethernet;
site local1 {
site-identifier 19;
ignore-encapsulation-mismatch;
ignore-mtu-mismatch;
interface ge-0/0/6.xx {
remote-site-id 17;
}
}
}
}
}
}

b. Common error code for L2VPN

An operation L2VPN will present UP status on both side of the pseudowire, anything other than UP
indicate an error state (some output has been omitted for shorter illustration)

69
juniper@vMX> show l2vpn connections logical-system HN-UPE2

Instance: L2VPN-CUSTOMER1
Local site: local1 (17)
connection-site Type St Time last up # Up trans
19 rmt Up Jan 24 20:19:08 2016 1
Remote PE: 10.0.2.101, Negotiated control-word: Yes (Null)
Incoming label: 800000, Outgoing label: 800000
Local interface: ge-0/0/5.0, Status: Up, Encapsulation: ETHERNET

juniper@vMX> show l2vpn connections logical-system HCM-UPE1

Legend for interface status

Up -- operational
Dn -- down

Instance: L2VPN-CUSTOMER1
Local site: local1 (19)
connection-site Type St Time last up # Up trans
17 rmt Up Jan 24 20:19:08 2016 1
Remote PE: 10.0.1.102, Negotiated control-word: Yes (Null)
Incoming label: 800000, Outgoing label: 800000
Local interface: ge-0/0/6.0, Status: Up, Encapsulation: ETHERNET

The most common error code is:

 OL (OL -- no outgoing label) :This flag indicates that no there is no outgoing label available
for use by this L2VPN. Either check the configuration on the remote site or all core facing
interface of this router.
o The most common cause is remote site configure a mismatched site-identifier. Double
check the remote site L2VPN configuration
o protocol mpls was not configured properly on the links connect this UPE router to the
core. Double check all LSP state and mpls.0 table of UPE and NPE
 LD (LD -- local site signaled down ): This flag indicates that all of the CE facing interfaces to
the local site are down. Therefore, the connection to the local site is signaled as down to the other
PE routers. This is cause by
o Actual link down (physically down or disabled)
o Misplaced interface in L2VPN routing instance ( for example the connection is on ge-
0/0/5.0 but on routing instance we placed ge-0/0/5.10)
 RD (RD -- remote site signaled down): indicate that all CE facing interface to the remote site a
down. Perform the above check – but on the remote router of the L2VPN.
 EM -- encapsulation mismatch: encapsulation-type specified in protocol l2vpn is not the same
between 2 site
 WE -- interface and instance encaps not same: typically happened when interface is tagged
but protocol encapsulation-type is only Ethernet (or reverse)

Once the L2VPN is up and running , we are not yet completed. Since there is different encapsulation
case from CE – we need to check reachability between CE to ensure proper operation.

70
 c. L2VPN route advertisement verification:
If the L2VPN route is not up and operational, aside from checking the error code – we also check the
advertisement status from UPE router

For example to verify the advertisement of L2VPN from HN-UPE2 to HCM-UPE1, first we check the
advertisement from HCM-UPE1 to HCM-NPEx (Follow the advertisement illustration in section 2.3.4)

juniper@vMX> show route advertising-protocol bgp 10.0.2.11 logical-system HCM-UPE1

extensive
//the route is being advertised from a l2vpn.0 table
L2VPN-CUSTOMER1.l2vpn.0: 2 destinations, 3 routes (2 active, 0 holddown, 0 hidden)
//the format for BGP-signaled L2VPN routes is RD:localsiteID:remotesiteID
* 2101:100:19:17/96 (1 entry, 1 announced)
BGP group NPE type Internal
Route Distinguisher: 2101:100
Label-base: 800000, range: 2, status-vector: 0x0
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [18403] I
Communities: target:18403:100 Layer2-info: encaps: ETHERNET, control flags:[0x2]
Control-Word, mtu: 0, site preference: 100

//Verify if NPE is accepting that L2VPN

juniper@vMX> show route receive-protocol bgp 10.0.2.101 logical-system HCM-NPE1

extensive
//On NPE,it is being received into bgp.l2vpn
bgp.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
* 2101:100:19:17/96 (1 entry, 1 announced)
//Accepted since the next-hop is resolvable
Accepted
Route Distinguisher: 2101:100
Label-base: 800000, range: 2, status-vector: 0x0
Nexthop: 10.0.2.101
Localpref: 100
AS path: I
//the encapsulation is either ETHERNET or ETHERNET-VLAN depending on protocol l2vpn
configuration

Communities: target:18403:100 Layer2-info: encaps: ETHERNET, control flags:[0x2]

Control-Word, mtu: 0, site preference: 100

//Verify if HCM-RR is accepting that L2VPN from HCM-NPEs

juniper@vMX> show route receive-protocol bgp 10.0.2.11 logical-system HCM-RR extensive
bgp.l2vpn.0: 2 destinations, 3 routes (2 active, 0 holddown, 0 hidden)

2101:100:19:17/96 (2 entries, 1 announced)

Accepted
Route Distinguisher: 2101:100
Label-base: 800000, range: 2, status-vector: 0x0
//Notice that the next-hop did NOT change when exiting the access into the core –
because this is an MP-BGP VPN route, not a BGP route in inet.3
//Core router’s reachability to 10.0.2.101 (using inet.3 route) is provided by BGP
policy in section 2.3.4

71
 Nexthop: 10.0.2.101
Localpref: 100
AS path: I (Originator)
Cluster list: 2.2.2.10
Originator ID: 10.0.2.101
Communities: target:18403:100 Layer2-info: encaps: ETHERNET, control flags:[0x2]
Control-Word, mtu: 0, site preference: 100

//Verify if HN-RR is accepting that L2VPN from HCM-RR

juniper@vMX> show route receive-protocol bgp 10.0.3.23 logical-system HN-RR extensive

bgp.l2vpn.0: 2 destinations, 3 routes (2 active, 0 holddown, 0 hidden)

* 2101:100:19:17/96 (1 entry, 1 announced)

Accepted
Route Distinguisher: 2101:100
Label-base: 800000, range: 2, status-vector: 0x0
Nexthop: 10.0.2.101
Localpref: 100
AS path: I (Originator)
Cluster list: 2.2.2.2 2.2.2.10
Originator ID: 10.0.2.101
Communities: target:18403:100 Layer2-info: encaps: ETHERNET, control flags:[0x2]
Control-Word, mtu: 0, site preference: 100

//Verify if HN-NPE is accepting that L2VPN from HN-RR

juniper@vMX> show route receive-protocol bgp 10.0.3.13 logical-system HN-NPE1 extensive

bgp.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)

* 2101:100:19:17/96 (1 entry, 1 announced)

Accepted
Route Distinguisher: 2101:100
Label-base: 800000, range: 2, status-vector: 0x0
Nexthop: 10.0.2.101
Localpref: 100
AS path: I (Originator)
//Cluster list has been updated to display the advertisement flow
Cluster list: 1.1.1.1 2.2.2.2 2.2.2.10
Originator ID: 10.0.2.101
Communities: target:18403:100 Layer2-info: encaps: ETHERNET, control flags:[0x2]
Control-Word, mtu: 0, site preference: 100

//Verify if HN-UPE2 is accepting that L2VPN from HN-NPE

juniper@vMX> show route receive-protocol bgp 10.0.1.11 logical-system HN-UPE2 extensive

bgp.l2vpn.0: 1 destinations, 2 routes (1 active, 0 holddown, 0 hidden)

* 2101:100:19:17/96 (2 entries, 0 announced)

Import Accepted
Route Distinguisher: 2101:100
Label-base: 800000, range: 2, status-vector: 0x0
Nexthop: 10.0.2.101
Localpref: 100
AS path: I (Originator)
//Cluster list has been updated to display the advertisement flow
Cluster list: 1.1.1.10 1.1.1.1 2.2.2.2 2.2.2.10

72
 Originator ID: 10.0.2.101
Communities: target:18403:100 Layer2-info: encaps: ETHERNET, control flags:[0x2]
Control-Word, mtu: 0, site preference: 100

L2VPN-CUSTOMER1.l2vpn.0: 2 destinations, 3 routes (2 active, 0 holddown, 0 hidden)

//After being import to bgp.l2vpn, the matching site-identifier help HN-UPE2 decide to
import this circuit into L2VPN-CUSTOMER1.l2vpn.0 –
- * 2101:100:19:17/96 (2 entries, 1 announced)
Import Accepted
Route Distinguisher: 2101:100
Label-base: 800000, range: 2, status-vector: 0x0
Nexthop: 10.0.2.101
Localpref: 100
AS path: I (Originator)
Cluster list: 1.1.1.10 1.1.1.1 2.2.2.2 2.2.2.10
Originator ID: 10.0.2.101
Communities: target:18403:100 Layer2-info: encaps: ETHERNET, control flags:[0x2]
Control-Word, mtu: 0, site preference: 100

//L2VPN connection will then present on HN-UPE2’s L2VPN-CUSTOMER1.l2vpn.0 table.

bidirectional present of circuit to remote site and matching encapsulation will allow
the L2VPN connection to come up

d. Common configuration and verification on CE

CE configuration is similar in all case except for the vlan-tag parameter on interface.

//Remember that CE’s configuration is placed on Olive virtual machine

//The UseCase name will change according for each case

[edit groups L2VPN-UseCase]

logical-systems {
L2CUSTOMER-CE1 {
interfaces {
em1 {
unit 0 {
family inet {
address 20.0.0.1/29;
}
}
}
lo0 {
unit 200 {
family inet {
address 10.0.20.1/32;
}
}
}
}
protocols {
ospf {
export C1-OSPF-EXPORT;
area 0.0.0.0 {

73
 interface lo0.200;
interface em1.0 {
interface-type p2p;
}
}
}
}
policy-options {
policy-statement C1-OSPF-EXPORT {
term static {
from protocol static;
then accept;
}
}
}
routing-options {
static {
route 17.0.0.128/25 receive;
}
autonomous-system 18400;
}
}
L2CUSTOMER-CE2 {
interfaces {
em2 {
unit 0 {
family inet {
address 20.0.0.2/29;
}
}
}
lo0 {
unit 210 {
family inet {
address 10.0.20.2/32;
}
}
}
}
protocols {
ospf {
export C1-OSPF-EXPORT; ## 'C1-OSPF-EXPORT' is not defined
area 0.0.0.0 {
interface lo0.210;
interface em2.0 {
interface-type p2p;
}
}
}
}
policy-options {
policy-statement C1-OSPF-EXPORT {
term static {
from protocol static;
then accept;
}
}
}

74
 routing-options {
static {
route 19.0.0.128/25 receive;
}
autonomous-system 18400;
}
}
}

CE verification is straight forward , first ping from each CE to the remote site

juniper@Olive# run ping 20.0.0.2 logical-system L2CUSTOMER-CE1

PING 20.0.0.2 (20.0.0.2): 56 data bytes
64 bytes from 20.0.0.2: icmp_seq=0 ttl=64 time=8.223 ms
64 bytes from 20.0.0.2: icmp_seq=1 ttl=64 time=50.811 ms
^C
--- 20.0.0.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 8.223/29.517/50.811/21.294 ms

[edit]
juniper@Olive# run ping 20.0.0.1 logical-system L2CUSTOMER-CE2
PING 20.0.0.1 (20.0.0.1): 56 data bytes
64 bytes from 20.0.0.1: icmp_seq=0 ttl=64 time=5.269 ms
64 bytes from 20.0.0.1: icmp_seq=1 ttl=64 time=3.528 ms
64 bytes from 20.0.0.1: icmp_seq=2 ttl=64 time=3.712 ms
^C
--- 20.0.0.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.528/4.170/5.269/0.781 ms

CE should also be configured with OSPF on all case study to better verification

[edit]
juniper@Olive# run show ospf neighbor logical-system L2CUSTOMER-CE2
Address Interface State ID Pri Dead
20.0.0.1 em2.0 Full 10.0.20.1 128 39

[edit]
juniper@Olive# run show ospf neighbor logical-system L2CUSTOMER-CE1
Address Interface State ID Pri Dead
20.0.0.2 em1.0 Full 10.0.20.2 128 37

75
 3.2.3. Case study 1: transparent L2VPN without vlan-tagging:

a. Configuration on UPE
Pure Ethernet L2VPN configuration require encapsulation Ethernet-ccc on the physical interface of
PE(do not enable vlan-tagging any elsewhere on these interface).

[edit groups L2VPN-transparent]

interfaces {
ge-0/0/5 {
encapsulation ethernet-ccc;
}
ge-0/0/6 {
encapsulation ethernet-ccc;
}
This also require encapsulation-type ethernet on protocol l2vpn configuration and family ccc to be
enabled on the logical unit 0 of that interface

[edit groups L2VPN-transparent]

logical-systems {
HCM-UPE1 {
interfaces {
ge-0/0/6 {
unit 0 {
description "TO L2VPN CUSTOMER1 - CE2";
family ccc;
}
}
}

routing-instances {

76
 L2VPN-CUSTOMER1 {
protocols {
l2vpn {
encapsulation-type ethernet;
}
}
}
}
}
HN-UPE2 {
interfaces {
ge-0/0/5 {
unit 0 {
description "TO L2VPN CUSTOMER1 - CE1";
family ccc;
}
}
}
}
routing-instances {
L2VPN-CUSTOMER1 {
protocols {
l2vpn {
encapsulation-type ethernet;
}
}
}
}
}
}

b. Transparency verification – untagged CE

This case study is transparent because it work regardless of vlan-tagging state from CE. Whether the
two CE is configured with L3 untagged or multiple L3 tagged logical unit – they will still reach each
other.

First we test it with untagged configuration on CE

// ALL CE CONFIGURATION IS PLACED ON OLIVE VIRTUAL MACHINE

[edit groups L2VPN-transparent]
logical-systems {
L2CUSTOMER-CE1 {
interfaces {
em1 {
unit 0 {
family inet {
address 20.0.0.1/29;
}
}
}
}

}
L2CUSTOMER-CE2 {
interfaces {

77
 em2 {
unit 0 {
family inet {
address 20.0.0.2/29;
}
}
}

}
}
}

Verify the CE1-CE2 reachability according to section 3.2.2.c

[edit groups L2VPN-transparent]

juniper@Olive# run show ospf neighbor logical-system L2CUSTOMER-CE1
Address Interface State ID Pri Dead
20.0.0.2 em1.0 Full 10.0.20.2 128 33

[edit groups L2VPN-transparent]

juniper@Olive# run show ospf neighbor logical-system L2CUSTOMER-CE2
Address Interface State ID Pri Dead
20.0.0.1 em2.0 Full 10.0.20.1 128 33

c. Transparency verification – tagged CE

Add the following configuration to CE

[edit groups L2VPN-transparent]

interfaces {
em1 {
vlan-tagging;
}
em2 {
vlan-tagging;
}
}
logical-systems {
L2CUSTOMER-CE1 {
interfaces {
em1 {
unit 0 {
vlan-id 1000;
}
}
}
}
L2CUSTOMER-CE2 {
interfaces {
em2 {
unit 0 {
vlan-id 1000;
}
}
}

78
 }
}

We can see that the OSPF neighbor is still up and operational – with VLAN-ID added to the OSPF hello
packet

[edit]
juniper@Olive# run show ospf neighbor logical-system L2CUSTOMER-CE1
Address Interface State ID Pri Dead
20.0.0.2 em1.0 Full 10.0.20.2 128 36

[edit]
juniper@Olive# run show ospf neighbor logical-system L2CUSTOMER-CE2
Address Interface State ID Pri Dead
20.0.0.1 em2.0 Full 10.0.20.1 128 33

juniper@Olive# run monitor traffic interface em1 layer2-headers

verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay.
Address resolution timeout is 4s.
Listening on em1, capture size 96 bytes

Reverse lookup for 224.0.0.5 failed (check DNS reachability).

Other reverse lookup failures will not be reported.
Use <no-resolve> to avoid reverse lookups on IP addresses.

06:31:27.268086 In 00:0c:29:36:1e:d3 > 01:00:5e:00:00:05, ethertype 802.1Q (0x8100),

length 74: vlan 1000, p 0, ethertype IPv4, truncated-ip - 24 bytes missing! 20.0.0.2 >
224.0.0.5: OSPFv2, Hello, length 60
06:31:28.285311 Out 00:0c:29:36:1e:c9 > 01:00:5e:00:00:05, ethertype 802.1Q (0x8100),
length 74: vlan 1000, p 0, ethertype IPv4, truncated-ip - 24 bytes missing! 20.0.0.1 >
224.0.0.5: OSPFv2, Hello, length 60
06:31:36.802226 In 00:0c:29:36:1e:d3 > 01:00:5e:00:00:05, ethertype 802.1Q (0x8100),
length 74: vlan 1000, p 0, ethertype IPv4, truncated-ip - 24 bytes missing! 20.0.0.2 >
224.0.0.5: OSPFv2, Hello, length 60
06:31:38.003304 Out 00:0c:29:36:1e:c9 > 01:00:5e:00:00:05, ethertype 802.1Q (0x8100),
length 74: vlan 1000, p 0, ethertype IPv4, truncated-ip - 24 bytes missing! 20.0.0.1 >
224.0.0.5: OSPFv2, Hello, length 60
^C
4 packets received by filter
0 packets dropped by kernel

d. Transparency verification – trunk CE interface

With vlan-tagging still enable on the physical interface, try adding other unit with other vlan-id on CE

All connection is still up and operational

79
juniper@Olive# run show ospf neighbor logical-system L2CUSTOMER-CE1
Address Interface State ID Pri Dead
20.0.0.2 em1.0 Full 10.0.20.2 128 33

[edit]
juniper@Olive# run show ospf neighbor logical-system L2CUSTOMER-CE2
Address Interface State ID Pri Dead
20.0.0.1 em2.0 Full 10.0.20.1 128 29

juniper@Olive# run ping 21.0.0.2 logical-system L2CUSTOMER-CE1

PING 21.0.0.2 (21.0.0.2): 56 data bytes
64 bytes from 21.0.0.2: icmp_seq=0 ttl=64 time=6.646 ms
64 bytes from 21.0.0.2: icmp_seq=1 ttl=64 time=5.513 ms
64 bytes from 21.0.0.2: icmp_seq=2 ttl=64 time=3.285 ms
64 bytes from 21.0.0.2: icmp_seq=3 ttl=64 time=3.497 ms
64 bytes from 21.0.0.2: icmp_seq=4 ttl=64 time=4.306 ms
^C
--- 21.0.0.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.285/4.649/6.646/1.268 ms

80
 3.2.4. Case study 2: tagged L2VPN
In practice, customer will often attached to a switch and tagged to a VLAN as in the following scenario

If CE facing interface is tagged with a vlan, we need to enable vlan-tagging on PE with the following
steps:

 Enable vlan-tagging support on physical interface, along with encapsulation vlan-ccc (or the
recommended flexible-vlan-tagging and encapsulation flexible-ethernet-services feature)
o the vlan-id must be >512 if physical interface encapsulation is vlan-cc
o vlan-id can be <512 if physical interface encapsulation is flexible-ethernet-service
 Enable encapsulation vlan-ccc in logical interface
 Specified the mapped vlan-id in the CE facing interface
 Change protocol l2vpn to have encapsulation-type ethernet-vlan

//Note that the vlan-id tagged by the switch can be a single-tag encapsulate the packet. Or it can be an
S-VLAN ID tagged on top of customer’s VLAN-ID. In either case, we only need to care about the
vlan tagged by the switch and leave customer’s VLAN alone.

81
 a. Same VLAN-ID

Here is the changed configuration if Customer1 is mapped to the same vlan 800 on both site:

[edit groups L2VPN-sameVLAN]

logical-systems {
HCM-UPE1 {
interfaces {
ge-0/0/6 {
unit 810 {
description "TO L2VPN CUSTOMER1 - CE2";
encapsulation vlan-ccc;
//Note that the vlan-id must be >512 if physical interface encapsulation is vlan-cc
//vlan-id can be <512 if physical interface encapsulation is flexible-ethernet-service

vlan-id 800;
}
}
}
routing-instances {
L2VPN-CUSTOMER1 {
protocols {
l2vpn {
//protocol l2vpn encapsulation must match logical interface encapsultion
encapsulation-type ethernet-vlan;
}
}
}
}
}
}
HN-UPE2 {
interfaces {
ge-0/0/5 {
unit 800 {
description "TO L2VPN CUSTOMER1 - CE1";
encapsulation vlan-ccc;

82
 vlan-id 800;
}
}
}
routing-instances {
L2VPN-CUSTOMER1 {
protocols {
l2vpn {
encapsulation-type ethernet-vlan;
}
}
}
}
}

}
interfaces {
ge-0/0/5 {
vlan-tagging;
encapsulation vlan-ccc;
}
ge-0/0/6 {
vlan-tagging;
encapsulation vlan-ccc;
}
}

Since we do not have a switch in the lab – the vlan-tag can be simulate by directly tagging packet on
virtual CE router located on Olive virtual machine. As explain above, we do not make any change to the
underlying customer’s vlan-id even in dual-tagged cases.

CE’s configuration is completely similar to section 3.2.3.c ( but change the vlan-id to 800 to match
UPE’s configuration)

83
 b. Different VLAN-ID

In practice – on each site the same customer could be associated with a different VLAN on the
provider’s switch.

To overcome this difficulty we have two methods:

 Use input-vlan-map swap so that when PE receive a packet from Provider’s switch, it swap the
local-link VLAN-ID with the VLAN-ID used for that same customer on the remote site. This
method require the local’s administrator to know of the remote VLAN-ID used for that same
customer and specify that VLAN-ID in the [input-vlan-map] hierarchy under logical interface.
 Or use ouput-vlan-map swap so that when PE send a packet of that L2VPN circuit to
Provider’s switch, it swap whatever VLAN-ID currently in the packet with the local-link
VLAN-ID. This method do not require the knowledge of remote vlan-id

//Note that we must use the SAME method for both site of the L2VPN channel. For example using input-
vlan-map on HN-UPE2 and then output-vlan-map on HCM-UPE1 achieve the same result of changing
packet from CE1 > CE2 to vlan-id 810. However it will not change packet from CE2 > CE1 to vlan-id
800 when these packet exit from HN-UPE2 and so the connect will failed

Configuration example for input-vlan-map is as follow

[edit groups L2VPN-sameVLAN]

logical-systems {
HCM-UPE1 {
interfaces {
ge-0/0/6 {
unit 810 {
description "TO L2VPN CUSTOMER1 - CE2";
encapsulation vlan-ccc;

84
 vlan-id 810;
input-vlan-map {
swap;
//Specify the vlan-id used to connect HN-UPE2 and CUSOMTER1-CE1
vlan-id 800;
}

}
}
}
routing-instances {
L2VPN-CUSTOMER1 {
protocols {
l2vpn {
//protocol l2vpn encapsulation must still be ethernet-vlan to support vlan-tagged
circuit
encapsulation-type ethernet-vlan;
}
}
}
}
}
}
HN-UPE2 {
interfaces {
ge-0/0/5 {
unit 800 {
description "TO L2VPN CUSTOMER1 - CE1";
encapsulation vlan-ccc;
vlan-id 800;
input-vlan-map {
swap;
//Specify the vlan-id used to connect HCM-UPE1 and CUSOMTER1-CE2
vlan-id 810;
}

}
}
}
routing-instances {
L2VPN-CUSTOMER1 {
protocols {
l2vpn {
encapsulation-type ethernet-vlan;
}
}
}
}
}

}
interfaces {
ge-0/0/5 {
vlan-tagging;
encapsulation vlan-ccc;
}
ge-0/0/6 {

85
 vlan-tagging;
encapsulation vlan-ccc;
}
}

For the output-vlan-map method. Change the configuration as follow

[edit groups L2VPN-sameVLAN]

logical-systems {
HCM-UPE1 {
interfaces {
ge-0/0/6 {
unit 810 {
description "TO L2VPN CUSTOMER1 - CE2";
encapsulation vlan-ccc;
vlan-id 810;
//output-vlan-map swap operation will use the local vlan-id 810 without require the
knowledge of remote site’s vlan-id

output-vlan-map swap;
}
}
}
}
HN-UPE2 {
interfaces {
ge-0/0/5 {
unit 800 {
description "TO L2VPN CUSTOMER1 - CE1";
encapsulation vlan-ccc;
vlan-id 800;
//output-vlan-map swap operation will use the local vlan-id 810 without require the
knowledge of remote site’s vlan-id

output-vlan-map swap;
}
}
}
}

3.2.5. Case study 3: trunk with vlan-id-list

In some case the same CE facing interface might require the allowance of several vlan-id for the same
customer – whether through Provider’s switch or directly connected:

86
This case only require the replacement of vlan-id statement with vlan-id-list in the logical unit
configuration. No further change in protocol L2VPN stanza.

[edit groups L2VPN-trunk]

logical-systems {
HCM-UPE1 {
interfaces {
ge-0/0/6 {
unit 810 {
description "TO L2VPN CUSTOMER1 - CE2";
encapsulation vlan-ccc;
//this unit should be dedicated to one customer
//hence the vlan-id-list is the range of VLAN-ID used for that customer (either
specified by CE or the Provider’s switch
vlan-id-list 800-802;
}
}
}
}
HN-UPE2 {
interfaces {
ge-0/0/5 {
unit 800 {
description "TO L2VPN CUSTOMER1 - CE1";
encapsulation vlan-ccc;
vlan-id-list 800-802;
}
}
}
}

87
//Special note : the case provided in this confirmation is different from the following common case

In this common case each customer still have their own L2VPN configuration, put in different logical
interface as specified in section 3.2.4 – no vlan-id-list is required.

88
 3.3. VPLS

3.3.1. Planning & perquisite:

Each VPLS customer connect to a UPE will belong to a specific routing-instance with instance-type
set to vpls. To determine a customer and that customer’s site, we also use RT and RD similar to L3VPN
and L2VPN

 Route-target planning will be similar to section 3.2. However for VPLS we only have 1
customer with VPN identifier 1000.
 Route-distinguisher planning is also similar to section 3.2, with Customer1 VPN identifier
change to 1000 to avoid conflict with L3VPN and L2VPN

Similar to L2VPN– each VPLS use case require different tagging and encapsulation configuration on
CE facing interface. These configuration will be provided in each case.

All use case require a site-id for each customer CE (or more precisely each customer’s site). We will be
using the follow ID for all use case:

 Site ID 17 for customer1’s CE1 (connected to HN-UPE1)

 Site ID 19 for customer1’s CE2 (connected to HCM-UPE1 )
 Site ID 18 for customer1’s CE2 (connected to HN-UPE3 )

The following diagram illustrate how site are planned

89
As is the case with l2vpn, VPLS requires BGP to have the family l2vpn with signaling in order to
advertise the VPLS NLRI information::

//The UseCase name will change according for each case- Each case will require a different group
configuration due to different physical parameter needed to be specified on interface

[edit groups L2VPN-UseCase]

logical-systems {
<*> {
protocols {
bgp {
family l2vpn {
signaling;
}
}
}

90
 3.3.2. Common configuration and verification method:
Each use case only differ in interface configuration – the VPLS connection verification and customer
service verification shall be the same for all of them and very similar to L2VPN, which include

 Verify VPLS is up on each UPE router

 Verify reachability from a customer CE to all the remote CE

a. Common configuration for VPLS

The following configuration can be applied to all case study

//The UseCase name will change according for each case

[edit groups VPLS-UseCase logical-systems HN-UPE1]
juniper@vMX# show
interfaces {
ge-0/0/5 {
unit xx {
description "TO VPLS CUSTOMER1 - CE1";
//ethernet-vpls for untagged case
//vlan-vpls for tagged case
encapsulation ethernet-vpls/vlan-vpls;
}
}
}
//The policy here is similar to L3VPN case
policy-options {
policy-statement VPLS-C1-Import {
//once applied, these import term will take effect when the router import connections to
xxx.l2vpn.0 table
term Customer1 {
from {
protocol bgp;
community VPLS-C1;
}
then accept;
}
term default {
then reject;
}
}
//these export term will take effect when the router export route to bgp.l2vpn.0 table
of other router
policy-statement VPLS-C1-Export {
term Customer1 {
then {
community add VPLS-C1;
accept;
}
}
term default {
then reject;
}
}
community VPLS-C1 members target:18403:1000;
}
routing-instances {

91
 VPLS-CUSTOMER1 {
//Instance type is always l2vpn
instance-type vpls;
//Unit number is subject to change according to each case study
interface ge-0/0/5.xx;
route-distinguisher 1101:1000;
vrf-import VPLS-C1-Import;
vrf-export VPLS-C1-Export;
//All VPLS configuration is placed inside protocol vpls of a vpls instance

protocols {
vpls {
//Site-range configuration Specify an upper limit on the maximum site identifier that
can be accepted to allow a pseudowire to be brought up. Pseudowires cannot be
established to sites with site identifiers greater than the configured site range
site-range 20;
// Must be use if there is no tunnel service card on the device – further exaplaination
in section /c
no-tunnel-services;
site C1-1 {
// Remember that site-identifier for VPLS must not be greater than site-range
site-identifier 17;
// No need to specify remote site id for VPLS
interface ge-0/0/5.xx;
}
}
}
}
}

// In general, except for interface configuration, L2VPN routing instance is similar on

all side of a VPLS connection
[edit groups VPLS-UseCase logical-systems HN-UPE3]
juniper@vMX# show
interfaces {
ge-0/0/7 {
unit xx {
description "TO VPLS CUSTOMER1 - CE2";
//ethernet-vpls for untagged case
//vlan-vpls for tagged case
encapsulation ethernet-vpls/vlan-vpls;
}
}
}
policy-options {
policy-statement VPLS-C1-Import {
term Customer1 {
from {
protocol bgp;
community VPLS-C1;
}
then accept;
}
term default {
then reject;
}
}

92
 policy-statement VPLS-C1-Export {
term Customer1 {
then {
community add VPLS-C1;
accept;
}
}
term default {
then reject;
}
}
community VPLS-C1 members target:18403:1000;
}
routing-instances {
VPLS-CUSTOMER1 {
instance-type vpls;
interface ge-0/0/7.xx;
route-distinguisher 1103:1000;
vrf-import VPLS-C1-Import;
vrf-export VPLS-C1-Export;
protocols {
vpls {
site-range 20;
no-tunnel-services;
site C1-3 {
site-identifier 18;
interface ge-0/0/7.xx;
}
}
}
}
}

[edit groups VPLS-UseCase logical-systems HCM-UPE1]

interfaces {
ge-0/0/6 {
unit xx {
description "TO VPLS CUSTOMER1 - CE2";
//ethernet-vpls for untagged case
//vlan-vpls for tagged case
encapsulation ethernet-vpls/vlan-vpls;
}
}
}
policy-options {
policy-statement VPLS-C1-Import {
term Customer1 {
from {
protocol bgp;
community VPLS-C1;
}
then accept;
}
term default {
then reject;
}
}
policy-statement VPLS-C1-Export {

93
 term Customer1 {
then {
community add VPLS-C1;
accept;
}
}
term default {
then reject;
}
}
community VPLS-C1 members target:18403:1000;
}
routing-instances {
VPLS-CUSTOMER1 {
instance-type vpls;
interface ge-0/0/6.xx;
route-distinguisher 2101:1000;
vrf-import VPLS-C1-Import;
vrf-export VPLS-C1-Export;
protocols {
vpls {
site-range 20;
no-tunnel-services;
site C1-2 {
site-identifier 19;
interface ge-0/0/6.xx;
}
}
}
}

b. Common error code for VPLS

An operation L2VPN will present UP status on all site of the pseudowire (with one connection to each
remote site), anything other than UP indicate an error state:

juniper@vMX# run show vpls connections logical-system HN-UPE1

Layer-2 VPN connections:

Instance: VPLS-CUSTOMER1
Local site: C1-1 (17)
connection-site Type St Time last up # Up trans
18 rmt Up Jan 25 00:48:50 2016 1
Remote PE: 10.0.1.103, Negotiated control-word: No
Incoming label: 262146, Outgoing label: 262145
Local interface: lsi.202375681, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPLS-CUSTOMER1 local site 17 remote site 18
19 rmt Up Jan 25 00:48:50 2016 1
Remote PE: 10.0.2.101, Negotiated control-word: No
Incoming label: 262147, Outgoing label: 262145
Local interface: lsi.202375680, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPLS-CUSTOMER1 local site 17 remote site 19

94
[edit]
juniper@vMX# run show vpls connections logical-system HN-UPE3
Layer-2 VPN connections:

Instance: VPLS-CUSTOMER1
Local site: C1-3 (18)
connection-site Type St Time last up # Up trans
17 rmt Up Jan 25 02:05:01 2016 1
Remote PE: 10.0.1.101, Negotiated control-word: No
Incoming label: 262145, Outgoing label: 262146
Local interface: lsi.235930114, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPLS-CUSTOMER1 local site 18 remote site 17
19 rmt Up Jan 25 02:05:01 2016 1
Remote PE: 10.0.2.101, Negotiated control-word: No
Incoming label: 262147, Outgoing label: 262146
Local interface: lsi.235930115, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPLS-CUSTOMER1 local site 18 remote site 19

juniper@vMX# run show vpls connections logical-system HCM-UPE1

Layer-2 VPN connections:

Instance: VPLS-CUSTOMER1
Local site: C1-2 (19)
connection-site Type St Time last up # Up trans
17 rmt Up Jan 25 02:05:02 2016 1
Remote PE: 10.0.1.101, Negotiated control-word: No
Incoming label: 262145, Outgoing label: 262147
Local interface: lsi.152044036, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPLS-CUSTOMER1 local site 19 remote site 17
18 rmt Up Jan 25 02:05:01 2016 1
Remote PE: 10.0.1.103, Negotiated control-word: No
Incoming label: 262146, Outgoing label: 262147
Local interface: lsi.152044035, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPLS-CUSTOMER1 local site 19 remote site 18

The common error code include

 OL (OL -- no outgoing label) :similar to L2VPN

 LD (LD -- local site signaled down ): similar to L2VPN
 RD (RD -- remote site signaled down): similar to L2VPN
 OR (OR -- out of range): This flag indicates that the label associated with the Virtual Circuit
(pseudowire) is out of range. If any one side of the pseudowire has a site ID which greater than
the site-range config, the status will be OR.
 NP (NP -- interface hardware not present): Tunnel interface is necessary in VPLS to bind
and de-encapsulate traffic from remote sites on the core facing side of the local PE router. By
default, the Junos OS automatically selects one of the virtual tunnel (VT) interfaces available to
the router. If no such hardware is present, no-tunnel-services must be configured so that the
router use the virtual LSI interface instead.

95
 c. VPLS route advertisement verification:
Advertisement of VPLS connection is completely similar to L2VPN .

Note that there is no such bgp.vpls.0 or customer.vpls.0 table on any router.

All VPLS connection is stored in the same two table bgp.l2vpn.0 and CustomerName.l2vpn.0 on
MPBGP-enabled routers.

The following example also shown that the format for VPLS pseudowires is similar to that of L2VPN,
which is RD:RemoteSiteID:LocalSiteID

juniper@vMX# run show route logical-system HN-UPE1 table VPLS-CUSTOMER1

VPLS-CUSTOMER1.l2vpn.0: 3 destinations, 5 routes (3 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

2101:1000:19:17/96
*[BGP/170] 00:31:16, localpref 100, from 10.0.1.11
AS path: I, validation-state: unverified
> to 1.0.0.1 via ge-0/0/2.11, label-switched-path HN-UPE1_to_HN-NPE1
to 1.0.0.3 via ge-0/0/3.12, label-switched-path Bypass->1.0.0.1
[BGP/170] 00:31:16, localpref 100, from 10.0.1.12
AS path: I, validation-state: unverified
> to 1.0.0.1 via ge-0/0/2.11, label-switched-path HN-UPE1_to_HN-NPE1
to 1.0.0.3 via ge-0/0/3.12, label-switched-path Bypass->1.0.0.1
1101:1000:17:17/96
*[L2VPN/170/-101] 00:31:17, metric2 1
Indirect
1103:1000:18:17/96
*[BGP/170] 00:31:16, localpref 100, from 10.0.1.12
AS path: I, validation-state: unverified
> to 1.0.0.3 via ge-0/0/3.12, label-switched-path HN-UPE1_to_HN-UPE2
to 1.0.0.1 via ge-0/0/2.11, label-switched-path HN-UPE1_to_HN-UPE2
[BGP/170] 00:31:16, localpref 100, from 10.0.1.11
AS path: I, validation-state: unverified
> to 1.0.0.3 via ge-0/0/3.12, label-switched-path HN-UPE1_to_HN-UPE2
to 1.0.0.1 via ge-0/0/2.11, label-switched-path HN-UPE1_to_HN-UPE2

juniper@vMX# run show route logical-system HN-NPE1 table bgp.l2vpn.0

bgp.l2vpn.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

2101:1000:19:17/96
*[BGP/170] 00:32:20, localpref 100, from 10.0.3.13
AS path: I, validation-state: unverified
> to 1.0.0.8 via ge-0/0/3.15, label-switched-path HN-NPE1_to_HN-NPE2
to 1.0.0.0 via ge-0/0/1.11, label-switched-path HN-NPE1_to_HN-NPE2
1101:1000:17:17/96
*[BGP/170] 00:32:20, localpref 100, from 10.0.1.101
AS path: I, validation-state: unverified
> to 1.0.0.0 via ge-0/0/1.11, label-switched-path HN-NPE1_to_HN-UPE1
to 1.0.0.8 via ge-0/0/3.15, label-switched-path Bypass->1.0.0.0
1103:1000:18:17/96
*[BGP/170] 00:32:20, localpref 100, from 10.0.1.103

96
 AS path: I, validation-state: unverified
> to 1.0.0.8 via ge-0/0/3.15, label-switched-path HN-NPE1_to_HN-NPE2
to 1.0.0.0 via ge-0/0/1.11, label-switched-path HN-NPE1_to_HN-NPE2

// All NPE routers will receive VPLS connection into bgp.l2vpn.0 table, but the
encapsulation this time will be VPLS
[edit]
juniper@vMX# run show route receive-protocol bgp 10.0.1.101 logical-system HN-NPE

bgp.l2vpn.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)

* 1101:1000:17:17/96 (1 entry, 1 announced)
Accepted
Route Distinguisher: 1101:1000
Label-base: 262145, range: 8
Nexthop: 10.0.1.101
Localpref: 100
AS path: I
Communities: target:18403:1000 Layer2-info: encaps: VPLS, control flags:[0x0] ,
mtu: 0, site preference: 100

d. Common verification on CE
CE configuration is similar in all case except for the vlan-tag parameter on interface

//The UseCase name will change according for each case

[edit groups VPLS-UseCase]
logical-systems {
L2CUSTOMER1-CE1 {
interfaces {
em1 {
unit 0 {
family inet {
address 20.0.0.1/29;
}
}
}
lo0 {
unit 200 {
family inet {
address 10.0.20.1/32;
}
}
}
}
protocols {
ospf {
export C1-OSPF-EXPORT;
area 0.0.0.0 {
interface lo0.200;
interface em1.0;
}
}
}
policy-options {
policy-statement C1-OSPF-EXPORT {
term static {

97
 from protocol static;
then accept;
}
}
}
routing-options {
static {
route 17.0.0.128/25 receive;
}
router-id 10.0.20.1;
}
}
L2CUSTOMER1-CE2 {
interfaces {
em2 {
unit 0 {
family inet {
address 20.0.0.2/29;
}
}
}
lo0 {
unit 202 {
family inet {
address 10.0.20.2/32;
}
}
}
}
protocols {
ospf {
export C1-OSPF-EXPORT;
area 0.0.0.0 {
interface lo0.202;
interface em2.0;
}
}
}
policy-options {
policy-statement C1-OSPF-EXPORT {
term static {
from protocol static;
then accept;
}
}
}
routing-options {
static {
route 19.0.0.128/25 receive;
}
router-id 10.0.20.2;
}
}
L2CUSTOMER1-CE3 {
interfaces {
em3 {
unit 0 {
family inet {

98
 address 20.0.0.3/29;
}
}
}
lo0 {
unit 203 {
family inet {
address 10.0.20.3/32;
}
}
}
}
protocols {
ospf {
export C1-OSPF-EXPORT;
area 0.0.0.0 {
interface lo0.203;
interface em3.0;
}
}
}
policy-options {
policy-statement C1-OSPF-EXPORT {
term static {
from protocol static;
then accept;
}
}
}
routing-options {
static {
route 18.0.0.128/25 receive;
}
router-id 10.0.20.3;
}
}
}
CE verification is completely similar to L2VPN, only that we have three different router participating in
OSPF this time

juniper@Olive# run show ospf neighbor logical-system all

logical-system: L2CUSTOMER1-CE1
Address Interface State ID Pri Dead
20.0.0.3 em1.0 Full 10.0.20.3 128 35
20.0.0.2 em1.0 Full 10.0.20.2 128 35
-----

logical-system: L2CUSTOMER1-CE2
20.0.0.1 em2.0 Full 10.0.20.1 128 31
20.0.0.3 em2.0 Full 10.0.20.3 128 35
-----

logical-system: L2CUSTOMER1-CE3
20.0.0.1 em3.0 Full 10.0.20.1 128 31
20.0.0.2 em3.0 Full 10.0.20.2 128 35

99
 3.3.3. Case study 1: transparent VPLS without vlan-tagging:

a. Configuration on UPE
Pure Ethernet VPLS configuration require encapsulation ethernet-vpls on the physical interface of PE
– without vlan-tagging being enable.

[edit groups VPLS-transparent]

interfaces {
ge-0/0/5 {
encapsulation ethernet-vpls;
}
ge-0/0/6 {
encapsulation ethernet-vpls;
}
ge-0/0/7 {
encapsulation ethernet-vpls;
}
}
Also ennable family vpls on the logical interface (family ccc is not required). No changes to the VPLS
routing-instance is require.

[edit groups VPLS-transparent]

logical-systems {
HCM-UPE1 {
interfaces {
ge-0/0/6 {
unit 0 {
description "TO L2VPN CUSTOMER1 - CE2";
family vpls;
}
}
}

}
HN-UPE1 {

100
 interfaces {
ge-0/0/5 {
unit 0 {
description "TO L2VPN CUSTOMER1 - CE1";
family vpls;
}
}
}
}
HN-UPE3 {
interfaces {
ge-0/0/7 {
unit 0 {
description "TO L2VPN CUSTOMER1 - CE1";
family vpls;
}
}
}
}

b. Transparency verification – all case

Similar to L2VPN – this VPLS configuration is transparent because it work regardless of CE’s tagging
state.

Trainee can three different verification step as in section 3.2.3 to verify the transparency. Note that the
vlan-id must match on all CE’s configuration

101
 3.3.4. Case study 2: VPLS with similar vlan-tagging on all side:
In reality, one switch can be used to handle all L3VPN-L2VPN and VPLS customer of a region – which
lead to the encapsulation of customer’s packet inside a S-VLAN tag. A simple case is that all site of a
customer will have the same S-VLAN tag

a. UPE configuration
This scenario only require a change of encapsulation method on physical and logical interface on all site

Here is the changed configuration if Customer1 is mapped to the same vlan 1000 on all site:

[edit groups VPLS-sameVLAN]

logical-systems {
HCM-UPE1 {
interfaces {
ge-0/0/6 {
unit 1000 {
description "TO VPLS CUSTOMER1 - CE2";
encapsulation vlan-vpls;
//Note that the vlan-id must be >512 if physical interface encapsulation is vlan-vpls
//vlan-id can be <512 if physical interface encapsulation is flexible-ethernet-service

vlan-id 1000;
}
}
}
}
HN-UPE1 {
interfaces {
ge-0/0/5 {
unit 1000 {
description "TO VPLS CUSTOMER1 - CE1";
encapsulation vlan-vpls;
vlan-id 1000;

102
 }
}
}
}
HN-UPE3 {
interfaces {
ge-0/0/7 {
unit 1000 {
description "TO VPLS CUSTOMER1 - CE2";
encapsulation vlan-vpls;
vlan-id 1000;
}
}
}
}
}
interfaces {
ge-0/0/5 {
vlan-tagging;
encapsulation vlan-vpls;
}
ge-0/0/6 {
vlan-tagging;
encapsulation vlan-vpls;
}
ge-0/0/7 {
vlan-tagging;
encapsulation vlan-vpls;
}
}

b. CE configuration
Change the CE configuration to match vlan-id 1000 on all site (added the vlan-tagging statement and
vlan-id only)

//The following configuration is applied on Olive virtual machine

[edit groups VPLS-sameVLAN]
logical-systems {
L2CUSTOMER1-CE1 {
interfaces {
em1 {
unit 1000 {
vlan-id 1000;
}
}
}
protocols {
ospf {
area 0.0.0.0 {
interface em1.1000;
}
}
}
}
L2CUSTOMER1-CE2 {

103
 interfaces {
em2 {
unit 1000 {
vlan-id 1000;
}
}
protocols {
ospf {
area 0.0.0.0 {
interface em2.1000;
}
}
}
}
L2CUSTOMER1-CE3 {
interfaces {
em3 {
unit 1000 {
vlan-id 1000;
}
}

}
protocols {
ospf {
area 0.0.0.0 {
interface em3.1000;
}
}
}

}
}
interfaces {
em1 {
vlan-tagging;
}
em2 {
vlan-tagging;
}
em3 {
vlan-tagging;
}
}

c. Verification
Use the same verification steps in section 3.3.2

We can observe that all OSPF neighboring state on all CE is up and operational. All packet is being
received with vlan-id 1000

104
juniper@Olive# run show ospf neighbor logical-system all

logical-system: L2CUSTOMER1-CE1
Address Interface State ID Pri Dead
20.0.0.3 em1.1000 Full 10.0.20.3 128 38
20.0.0.2 em1.1000 Full 10.0.20.2 128 34
-----

logical-system: L2CUSTOMER1-CE2
20.0.0.3 em2.1000 Full 10.0.20.3 128 38
20.0.0.1 em2.1000 Full 10.0.20.1 128 35
-----

logical-system: L2CUSTOMER1-CE3
20.0.0.2 em3.1000 Full 10.0.20.2 128 33
20.0.0.1 em3.1000 Full 10.0.20.1 128 35

[edit groups VPLS-sameVLAN]

juniper@Olive# run monitor traffic interface em1 layer2-headers
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay.
Address resolution timeout is 4s.
Listening on em1, capture size 96 bytes

Reverse lookup for 224.0.0.5 failed (check DNS reachability).

Other reverse lookup failures will not be reported.
Use <no-resolve> to avoid reverse lookups on IP addresses.

10:46:58.454710 Out 00:0c:29:36:1e:c9 > 01:00:5e:00:00:05, ethertype 802.1Q (0x8100),

length 68: vlan 1000, p 0, ethertype IPv4, truncated-ip - 34 bytes missing! 20.0.0.1 >
224.0.0.5: OSPFv2, Hello, length 64
10:47:00.147143 In 00:0c:29:36:1e:dd > 01:00:5e:00:00:05, ethertype 802.1Q (0x8100),
length 68: vlan 1000, p 0, ethertype IPv4, truncated-ip - 34 bytes missing! 20.0.0.3 >
224.0.0.5: OSPFv2, Hello, length 64
10:47:01.866668 In 00:0c:29:36:1e:d3 > 01:00:5e:00:00:05, ethertype 802.1Q (0x8100),
length 68: vlan 1000, p 0, ethertype IPv4, truncated-ip - 34 bytes missing! 20.0.0.2 >
224.0.0.5: OSPFv2, Hello, length 64
10:47:06.010064 Out 00:0c:29:36:1e:c9 > 01:00:5e:00:00:05, ethertype 802.1Q (0x8100),
length 68: vlan 1000, p 0, ethertype IPv4, truncated-ip - 34 bytes missing! 20.0.0.1 >
224.0.0.5: OSPFv2, Hello, length 64
10:47:08.314812 In 00:0c:29:36:1e:dd > 01:00:5e:00:00:05, ethertype 802.1Q (0x8100),
length 68: vlan 1000, p 0, ethertype IPv4, truncated-ip - 34 bytes missing! 20.0.0.3 >
224.0.0.5: OSPFv2, Hello, length 64
10:47:11.722658 In 00:0c:29:36:1e:d3 > 01:00:5e:00:00:05, ethertype 802.1Q (0x8100),
length 68: vlan 1000, p 0, ethertype IPv4, truncated-ip - 34 bytes missing! 20.0.0.2 >
224.0.0.5: OSPFv2, Hello, length 64
^C

3.3.5. Case study 3: VPLS with different vlan-tag configuration on each side:

a. VPLS site combination overview

105
If not properly planned, each site will have a different VLAN configuration for the same customer. The
cases include

 Non-tagged
 Single-tagged by Provider’s switch
 Single-tagged by CE
 Dual-tagged by Provider’s switch and CE

This combination is complex depend on number of site. However in most dual-tagged case – similar to
L2VPN – we only perform operation on. So except for rare cases – dual-tagged site can be handle in the
similar sense with sites that was single-tagged by Provider’s switch.

We will study the method to handle the combination in the following diagram.

\\The study of other combination which involve (handling both inner + outer vlan-tag) or involve
(handling VPLS combination which have multi-homing sites) is unfortunately outside the capability
of the virtual platform deployed for this course.

To handle different vlan combination of different VPLS’s site, we use a method called normalizing
vlan. This is achieve by either one of the following two method

 Perform poping of vlan-id when UPE receive packet on local vlan-tagged interface and pushing
of local vlan-id when UPE transmitting packet from remote site to local CE
 Specify a vlan-id or a vlan-tag (require an inner and outer id) inside the VPLS instance – All
vlan-tag on local-link will be normalize to this id or tag when traversing the MPLS core.

106
 b. CE configuration
Change the CE configuration according to the provided diagram (Or use the provided group VPLS-
normalize on Olive virtual machine)

c. Normalize with push and pop

This method is achieve by two configuration

 Input-vlan-map pop (or pop/pop) on CE facing interface of HN-UPE1 and HN-UPE3 (tagging
VPLS site from the diagram). This will remove the local vlan-id before the packet enter VPLS
pseudowire. The VLAN stack for that packet when traversing the VPLS pseudowire will be n-1
or n-2 (n being the stack height when packet leave the Provider’s switch).
 Output-vlan-map push (or push/push) on the same interface of HN-UPE1 and HN-UPE3. This
will make the router push the local vlan-id on top of the packet before sending it to CE (or
Provider’s switch).
 This method rely on the agreement/planning of VLAN stack height (either 0 or 1) when letting
a packet into the VPLS pseudowire – which let to configuration of input-vlan-map. After leaving
the VPLS pseudowire, further change to match each site’s stack height is perform on output-
vlan-map

The following configuration is a simple pop/push combination for the scenario illustrated above

[edit groups VPLS-normalize logical-systems]

HCM-UPE1 {
interfaces {
ge-0/0/6 {
unit 0 {
description "TO VPLS CUSTOMER1 - CE2";
//Untagged site do not require any additional push/pop operation using this method (vlan
stack height inside the vpls pseudowire is already 0 in this case)
family vpls;
}
}
}

}
HN-UPE3 {
interfaces {
ge-0/0/7 {
unit 1010 {
description "TO VPLS CUSTOMER1 - CE2";
encapsulation vlan-vpls;
vlan-id 1010;
input-vlan-map pop;
output-vlan-map push;
}
}
}
}
HN-UPE1 {
interfaces {

107
 ge-0/0/5 {
unit 1000 {
description "TO VPLS CUSTOMER1 - CE1";
encapsulation vlan-vpls;
vlan-id 1000;
input-vlan-map pop;
output-vlan-map push;
}
}
}
interfaces {
ge-0/0/5 {
vlan-tagging;
encapsulation vlan-vpls;
}
ge-0/0/7 {
vlan-tagging;
encapsulation vlan-vpls;
}
ge-0/0/6 {
encapsulation ethernet-vpls;
}
}

This manual normalization method do not provide any information on the vpls connection, so we
have to verify the result on the CE’s interface – see if the receiving packet have the expected vlan

juniper@Olive# run show ospf neighbor logical-system all

logical-system: L2CUSTOMER1-CE1
Address Interface State ID Pri Dead
20.0.0.2 em1.1000 Full 10.0.20.2 128 31
20.0.0.3 em1.1000 Full 10.0.20.3 128 32
-----

logical-system: L2CUSTOMER1-CE2
20.0.0.3 em2.0 Full 10.0.20.3 128 32
20.0.0.1 em2.0 Full 10.0.20.1 128 32
-----

logical-system: L2CUSTOMER1-CE3
20.0.0.2 em3.1000 Full 10.0.20.2 128 31
20.0.0.1 em3.1000 Full 10.0.20.1 128 32
-----

logical-system: default
OSPF instance is not running

[edit]
juniper@Olive# run monitor traffic interface em2 layer2-headers
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay.
Address resolution timeout is 4s.
Listening on em2, capture size 96 bytes

108
Reverse lookup for 224.0.0.5 failed (check DNS reachability).
Other reverse lookup failures will not be reported.
Use <no-resolve> to avoid reverse lookups on IP addresses.

11:47:15.112146 Out 00:0c:29:36:1e:d3 > 01:00:5e:00:00:05, ethertype IPv4 (0x0800),

length 74: truncated-ip - 24 bytes missing! 20.0.0.2 > 224.0.0.5: OSPFv2, Hello, length
64
11:47:15.465618 In 00:0c:29:36:1e:dd > 01:00:5e:00:00:05, ethertype IPv4 (0x0800),
length 74: truncated-ip - 24 bytes missing! 20.0.0.3 > 224.0.0.5: OSPFv2, Hello, length
64
11:47:15.966967 In 00:0c:29:36:1e:c9 > 01:00:5e:00:00:05, ethertype IPv4 (0x0800),
length 74: truncated-ip - 24 bytes missing! 20.0.0.1 > 224.0.0.5: OSPFv2, Hello, length
64
^C
3 packets received by filter
0 packets dropped by kernel

juniper@Olive# run monitor traffic interface em1 layer2-headers

verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay.
Address resolution timeout is 4s.
Listening on em1, capture size 96 bytes

Reverse lookup for 224.0.0.5 failed (check DNS reachability).

Other reverse lookup failures will not be reported.
Use <no-resolve> to avoid reverse lookups on IP addresses.

11:47:24.554513 In 00:0c:29:36:1e:d3 > 01:00:5e:00:00:05, ethertype 802.1Q (0x8100),

length 68: vlan 1000, p 0, ethertype IPv4, truncated-ip - 34 bytes missing! 20.0.0.2 >
224.0.0.5: OSPFv2, Hello, length 64
11:47:25.353051 In 00:0c:29:36:1e:dd > 01:00:5e:00:00:05, ethertype 802.1Q (0x8100),
length 68: vlan 1000, p 0, ethertype IPv4, truncated-ip - 34 bytes missing! 20.0.0.3 >
224.0.0.5: OSPFv2, Hello, length 64
11:47:25.579807 Out 00:0c:29:36:1e:c9 > 01:00:5e:00:00:05, ethertype 802.1Q (0x8100),
length 68: vlan 1000, p 0, ethertype IPv4, truncated-ip - 34 bytes missing! 20.0.0.1 >
224.0.0.5: OSPFv2, Hello, length 64
^C
3 packets received by filter
0 packets dropped by kernel

juniper@Olive# run monitor traffic interface em3 layer2-headers

verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay.
Address resolution timeout is 4s.
Listening on em3, capture size 96 bytes

Reverse lookup for 224.0.0.5 failed (check DNS reachability).

Other reverse lookup failures will not be reported.
Use <no-resolve> to avoid reverse lookups on IP addresses.

11:47:33.626708 Out 00:0c:29:36:1e:dd > 01:00:5e:00:00:05, ethertype 802.1Q (0x8100),

length 68: vlan 1010, p 0, ethertype IPv4, truncated-ip - 34 bytes missing! 20.0.0.3 >
224.0.0.5: OSPFv2, Hello, length 64
11:47:33.965906 In 00:0c:29:36:1e:c9 > 01:00:5e:00:00:05, ethertype 802.1Q (0x8100),
length 68: vlan 1010, p 0, ethertype IPv4, truncated-ip - 34 bytes missing! 20.0.0.1 >
224.0.0.5: OSPFv2, Hello, length 64

109
11:47:34.292258 In 00:0c:29:36:1e:d3 > 01:00:5e:00:00:05, ethertype 802.1Q (0x8100),
length 68: vlan 1010, p 0, ethertype IPv4, truncated-ip - 34 bytes missing! 20.0.0.2 >
224.0.0.5: OSPFv2, Hello, length 64
^C
3 packets received by filter
0 packets dropped by kernel

d. Normalize with VPLS instance VLAN-ID

In practice, the MX Series is capable of automatically normalizing the vlan-stack height for the packets
traversing the core by using the vlan-id/vlan-tag configuration in the VPLS instance. With this
configuration, the MX Series routers are will automatically calculate the required vlan-tagging operation
for a given packet’s ingress/egress interface.

 Setting the vlan-id in VPLS instance will normalize the VLAN stack height to 1
 Setting the vlan-tag in VPLS instance will normalize the VLAN stack height to 2 (include
one inner tag and one outer tag)

The following diagram is a simple illustration of how VPLS’s vlan-id work

The configuration is straight-forward, simple specify the same VLAN-ID or VLAN-TAG on all VPLS
instance of the same customer on all site

110
[edit groups VPLS-normalize-InstanceID]
logical-systems {
HCM-UPE1 {
interfaces {
ge-0/0/6 {
unit 0 {
description "TO VPLS CUSTOMER1 - CE2";
family vpls;
}
}
routing-instances {
VPLS-CUSTOMER1 {
//Instead of vlan-id, specify vlan-tags inner XX outer YY will normalize the stack
height to 2
vlan-id 800;
}
}
}
HN-UPE3 {
interfaces {
ge-0/0/7 {
unit 1010 {
description "TO VPLS CUSTOMER1 - CE2";
encapsulation vlan-vpls;
//All push/pop/swap opeartion is perform automatically – so we only need to specify the
correct local vlan-id for each site
vlan-id 1010;
}
}
}
routing-instances {
VPLS-CUSTOMER1 {
vlan-id 800;
}
}
}
HN-UPE1 {
interfaces {
ge-0/0/5 {
unit 1000 {
description "TO VPLS CUSTOMER1 - CE1";
encapsulation vlan-vpls;
vlan-id 1000;
}
}
}
routing-instances {
VPLS-CUSTOMER1 {
vlan-id 800;
}
}
}
}

111
 3.4. Multihome cases:

3.4.1. L3VPN multihome – normal case:

L3VPN multihome without VRRP is basically no different from normal L3VPN case. CE will have two
separate connection to ISP and which connection is used as the gateway is entirely depend on static
route/IGP metric and configuration.

3.4.2. L3VPN multihome with VRRP

a. Overview
If customer connect to 2 UPE router via the same L2 infrastructure, VRRP can be utilized to provide
redundancy. CE will use one of the two UPE router as the default gateway – depend on VRRP’s priority.

This case will require an /29 IP block.

b. Configuration
CE2 configuration is totally the same as normal L3VPN case

CE1 configuration only require one default static route to the two UPE’s VIP address

112
[edit groups L3VPN-multihome logical-systems]
L3CUSTOMER1-CE1 {
interfaces {
em1 {
unit 0 {
family inet {
address 17.0.0.2/29;
}
}
}
lo0 {
unit 172 {
family inet {
address 10.0.47.2/32;
}
}
}
}
routing-options {
static {
//Default route to UPE’s VIP (VRRP virtual address shared between two UPE router)
route 0.0.0.0/0 next-hop 17.0.0.4;
}
autonomous-system 18000;
}
}

Configuration on two UPE routers is completely similar except the dedicated IP address

//route to UPE’s VIP (VRRP virtual address shared between two UPE router)
HN-UPE1 {
interfaces {
ge-0/0/5 {
unit 0 {
family inet {
// The dedicated L3 IP for that L3VPN must be different on each UPE router
address 17.0.0.1/29 {
vrrp-group 1 {
// Virtual address is the same
virtual-address 17.0.0.4;
// Priority to chose VRRP master
priority 200;
// Enable preemption to restore master role when an error
link goes up again
preempt;
// Track the down link to CE to switch VRRP master role
when neccesary.
track {
interface ge-0/0/5 {
priority-cost 100;
}
}

113
 }
}
}
}
}
lo0 {
unit 171 {
family inet {
address 10.0.17.1/32;
}
}
}
}
policy-options {
policy-statement L3VPN-C1-Import {
term Customer1 {
from {
protocol bgp;
community L3VPN-C1;
}
then accept;
}
term default {
then reject;
}
}
policy-statement L3VPN-C1-Export {
term Customer1 {
then {
community add L3VPN-C1;
accept;
}
}
term default {
then reject;
}
}
community L3VPN-C1 members target:18403:10;
}

// There is no change in L3VPN instance configuration

routing-instances {
L3VPN-CUSTOMER1 {
instance-type vrf;
interface ge-0/0/5.0;
interface lo0.171;
route-distinguisher 1101:10;
vrf-import L3VPN-C1-Import;
vrf-export L3VPN-C1-Export;
routing-options {
static {
// Both router should have IGP or a static route to CE
route 10.0.17.2/32 next-hop 17.0.0.2;
}
autonomous-system 18000;
}
}
}

114
}

HN-UPE3 {
interfaces {
ge-0/0/7 {
unit 0 {
family inet {
// The dedicated L3 IP for that L3VPN must be different on each UPE router
address 17.0.0.3/29 {
vrrp-group 1 {
virtual-address 17.0.0.4;
// Lower priority indicated VRRP backup role
priority 150;
// Enable preemption on both router, note that backup VRRP
router do not need to track down link.
preempt;
}
}
}
}
}
lo0 {
unit 173 {
family inet {
address 10.0.17.3/32;
}
}
}
}
policy-options {
policy-statement L3VPN-C1-Import {
term Customer1 {
from {
protocol bgp;
community L3VPN-C1;
}
then accept;
}
term default {
then reject;
}
}
policy-statement L3VPN-C1-Export {
term Customer1 {
then {
community add L3VPN-C1;
accept;
}
}
term default {
then reject;
}
}
community L3VPN-C1 members target:18403:10;
}
routing-instances {
L3VPN-CUSTOMER1 {

115
 instance-type vrf;
interface ge-0/0/7.0;
interface lo0.173;
route-distinguisher 1101:10;
vrf-import L3VPN-C1-Import;
vrf-export L3VPN-C1-Export;
routing-options {
static {
// Both router should have IGP or a static route to CE
route 10.0.17.2/32 next-hop 17.0.0.2;
}
autonomous-system 18000;
}
}
}
}

3.4.3. L2VPN multihome:

a. Overview

L2VPN multihome provide redundancy for L2VPN connection without additional IP configuration. One
UPE router will have its L2VPN connection in backup state while the other UPE handle primary
connection

116
 b. Configuration
 CE router’s configuration shall stay the same as case 3.2.3 (transparent L2VPN), no change is
required. Only note that if customer decided to use two physical connection directly to two UPE
router – these two connection must be in L2 mode (customer should place their L3 IP on a vlan
interface or something similar in that case).
 PE configuration is also the same with case 3.2.3 (transparent L2VPN), except the additional
site-preference statement on L2VPN configuration of each UPE

//Note that L2VPN multihome case illustrated here only utilize transparent configuration – in which we
do not perform vlan-tagging from provider’s SW to UPE router, so all CE facing interface on UPE
router is in untagged mode with encapsulation ethernet-ccc.

The configuration for L2VPN multihome case with single or multiple vlan tag is the same as other case
in 3.2.4 and 3.2.5 –with the addition of site-preference statement

[edit groups L2VPN-multihome]

logical-systems {
HN-UPE3 {
interfaces {
ge-0/0/7 {
unit 0 {
//Interface configuration is transparent in this case study
//Interface configuration should change according to L2 infrastructure requirement
description "TO L2VPN CUSTOMER1 - CE1";
family ccc;
}
}
}
policy-options {
policy-statement L2VPN-C1-Import {
term Customer1 {
from {
protocol bgp;
community L2VPN-C1;
}
then accept;
}
term default {
then reject;
}
}
policy-statement L2VPN-C1-Export {
term Customer1 {
then {
community add L2VPN-C1;
accept;
}
}
term default {

117
 then reject;
}
}
community L2VPN-C1 members target:18403:100;
}
routing-instances {
L2VPN-CUSTOMER1 {
instance-type l2vpn;
interface ge-0/0/7.0;
route-distinguisher 1103:100;
vrf-import L2VPN-C1-Import;
vrf-export L2VPN-C1-Export;
protocols {
l2vpn {
//All configuration is the same except the additional site-preference

encapsulation-type ethernet;
site local1 {
//Note that site-identifier must be THE SAME on both primary and backup UPE of this
L2VPN connection
site-identifier 17;
ignore-encapsulation-mismatch;
//Lower preference will make L2VPN connection on this router stay in idle state.
site-preference 100;
ignore-mtu-mismatch;
interface ge-0/0/7.0 {
//Note that remote-site-id must also be THE SAME on both primary and backup UPE of this
L2VPN connection
remote-site-id 19;
}
}
}
}
}
}
}
HN-UPE1 {
interfaces {
ge-0/0/5 {
unit 0 {
//Interface configuration is transparent in this case study
//Interface configuration should change according to L2 infrastructure requirement
description "TO L2VPN CUSTOMER1 - CE1";
family ccc;
}
}
}
policy-options {
policy-statement L2VPN-C1-Import {
term Customer1 {
from {
protocol bgp;
community L2VPN-C1;
}
then accept;
}
term default {
then reject;

118
 }
}
policy-statement L2VPN-C1-Export {
term Customer1 {
then {
community add L2VPN-C1;
accept;
}
}
term default {
then reject;
}
}
community L2VPN-C1 members target:18403:100;
}
routing-instances {
L2VPN-CUSTOMER1 {
instance-type l2vpn;
interface ge-0/0/5.0;
route-distinguisher 1101:100;
vrf-import L2VPN-C1-Import;
vrf-export L2VPN-C1-Export;
protocols {
l2vpn {
encapsulation-type ethernet;
//All configuration is the same except the additional site-preference
site local1 {
//Note that site-identifier must be THE SAME on both primary and backup UPE of this
L2VPN connection
site-identifier 17;
ignore-encapsulation-mismatch;
//Higher preference will make L2VPN connection on this router become the primary
connection and handle all traffic between customer’s site
site-preference 200;
ignore-mtu-mismatch;
interface ge-0/0/5.0 {
//Note that remote-site-id must be THE SAME on both primary and backup UPE of this L2VPN
connection
remote-site-id 19;
}
}
}
}
}
}
}
}
interfaces {
ge-0/0/5 {
encapsulation ethernet-ccc;
}
ge-0/0/6 {
encapsulation ethernet-ccc;
}
ge-0/0/7 {
encapsulation ethernet-ccc;
}
}

119
 c. Verification
The L2VPN connection on backup UPE router will be in waiting state, but the primary UPE router
should still be aware of the backup’s existence

[edit]
juniper@vMX# run show l2vpn connections logical-system HN-UPE1
Layer-2 VPN connections:

Instance: L2VPN-CUSTOMER1
Local site: local1 (17)
connection-site Type St Time last up # Up trans
//On the primary router – the backup VPLS connection is displayed with status RN –
Remote site not designated, with the same site ID
17 rmt RN
19 rmt Up Feb 16 14:37:46 2016 1
Remote PE: 10.0.2.101, Negotiated control-word: Yes (Null)
Incoming label: 800002, Outgoing label: 800002
Local interface: ge-0/0/5.0, Status: Up, Encapsulation: ETHERNET

[edit]
juniper@vMX# run show l2vpn connections logical-system HN-UPE3
Layer-2 VPN connections:

Instance: L2VPN-CUSTOMER1
Local site: local1 (17)
connection-site Type St Time last up # Up trans
//On the backup router – the backup VPLS connection is displayed with status LN – Local
site not designated¸with two connection: to remote site and to local primary site.
17 rmt LN
19 rmt LN

[edit]
juniper@vMX# run show l2vpn connections logical-system HCM-UPE1
Layer-2 VPN connections:

Instance: L2VPN-CUSTOMER1
Local site: local1 (19)
connection-site Type St Time last up # Up trans
//The remote site only see one connection to the primary site.
17 rmt Up Feb 16 14:37:46 2016 1
Remote PE: 10.0.1.101, Negotiated control-word: Yes (Null)
Incoming label: 800002, Outgoing label: 800002
Local interface: ge-0/0/6.0, Status: Up, Encapsulation: ETHERNET\

//However, further inspection should show that the remote site still see 2 different
L2VPN route to both primary and backup L2VPN router (with different RD – Route
distinguisher)

120
[edit]
juniper@vMX# run show route table bgp.l2vpn.0 logical-system HCM-UPE1

bgp.l2vpn.0: 2 destinations, 4 routes (2 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

//L2VPN route to primary site

1101:100:17:19/96
*[BGP/170] 00:05:46, localpref 200, from 10.0.2.12
AS path: I, validation-state: unverified
> to 2.0.0.0 via ge-0/0/2.21, Push 301808
[BGP/170] 00:05:47, localpref 200, from 10.0.2.11
AS path: I, validation-state: unverified
> to 2.0.0.0 via ge-0/0/2.21, Push 301808
//L2VPN route to backup site
1103:100:17:19/96
*[BGP/170] 00:05:46, localpref 100, from 10.0.2.12
AS path: I, validation-state: unverified
> to 2.0.0.0 via ge-0/0/2.21, Push 301776
[BGP/170] 00:05:47, localpref 100, from 10.0.2.11
AS path: I, validation-state: unverified
> to 2.0.0.0 via ge-0/0/2.21, Push 301776

We can also verify the communication between backup and remote site by looking at bgp.l2vpn.0 table

[edit]
juniper@vMX# run show route table bgp.l2vpn.0 logical-system HN-UPE1

bgp.l2vpn.0: 2 destinations, 4 routes (2 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both
//L2VPN circuit to remote site
2101:100:19:17/96
*[BGP/170] 00:10:01, localpref 100, from 10.0.1.12
AS path: I, validation-state: unverified
> to 1.0.0.1 via ge-0/0/2.11, Push 302112
[BGP/170] 00:10:01, localpref 100, from 10.0.1.11
AS path: I, validation-state: unverified
> to 1.0.0.1 via ge-0/0/2.11, Push 302112
//Primary router should also be aware of L2VPN circuit from backup site to remote site
1103:100:17:19/96
*[BGP/170] 00:10:10, localpref 100, from 10.0.1.12
AS path: I, validation-state: unverified
> to 1.0.0.3 via ge-0/0/3.12, Push 299984
[BGP/170] 00:10:56, localpref 100, from 10.0.1.11
AS path: I, validation-state: unverified
> to 1.0.0.3 via ge-0/0/3.12, Push 299984

[edit]
juniper@vMX# run show route table bgp.l2vpn.0 logical-system HN-UPE3

bgp.l2vpn.0: 2 destinations, 4 routes (2 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both
//L2VPN circuit to remote site

121
2101:100:19:17/96
*[BGP/170] 00:10:07, localpref 100, from 10.0.1.11
AS path: I, validation-state: unverified
> to 1.0.0.7 via ge-0/0/2.14, Push 301904
[BGP/170] 00:10:07, localpref 100, from 10.0.1.12
AS path: I, validation-state: unverified
> to 1.0.0.7 via ge-0/0/2.14, Push 301904
//Backup router should also be aware of L2VPN circuit from primary site to remote site
1101:100:17:19/96
*[BGP/170] 00:10:16, localpref 200, from 10.0.1.12
AS path: I, validation-state: unverified
> to 1.0.0.4 via ge-0/0/4.13, Push 299968
[BGP/170] 00:11:02, localpref 200, from 10.0.1.11
AS path: I, validation-state: unverified
> to 1.0.0.4 via ge-0/0/4.13, Push 299968

3.4.4. VPLS multihome:

a. Overview
VPLS multihome case is very similar to L2VPN multihome case. One customer’s CE shall have two
connection to two different CE but only one UPE router will have its VPLS connection in UP state to
connect CE to the VPLS virtual circuit.

122
 b. Configuration
 CE router’s configuration shall stay the same as case 3.3.4 (tagged VPLS), no change is
required. Only note that if customer decided to use two physical connection directly from one CE
to two UPE router – these two connection must be in L2 mode (customer should place their L3
IP on a vlan interface or something similar in that case).
 UPE configuration is also the same with case 3.3.4 (tagged VPLS), except the additional site-
preference statement and multi-homing on VPLS configuration of each UPE

//Note that VPLS multihome case illustrated here only utilize same vlan configuration – in which we
have CE belong to the same vlan on all sites.

The configuration for VP;S transparent multihome case or multiple vlan tag is the same as other case in
3.3.3 and 3.3.5 –with the addition of site-preference and multi-homing statement

[edit groups VPLS-multihome]

logical-systems {
HN-UPE1 {
interfaces {
ge-0/0/5 {
unit 1000 {
//Interface configuration is using the same vlan 1000 for customer 1 on all site in this
case study.
//Interface configuration should change according to L2 infrastructure requirement

description "TO VPLS CUSTOMER1 - CE1";

encapsulation vlan-vpls;
vlan-id 1000;
}
}
}
policy-options {
policy-statement VPLS-C1-Import {
term Customer1 {
from {
protocol bgp;
community VPLS-C1;
}
then accept;
}
term default {
then reject;
}
}
policy-statement VPLS-C1-Export {
term Customer1 {
then {
community add VPLS-C1;
accept;
}
}
term default {
then reject;

123
 }
}
community VPLS-C1 members target:18403:1000;
}
routing-instances {
VPLS-CUSTOMER1 {
instance-type vpls;
interface ge-0/0/5.1000;
route-distinguisher 1101:1000;
vrf-import VPLS-C1-Import;
vrf-export VPLS-C1-Export;
protocols {
vpls {
site-range 20;
no-tunnel-services;
site C1-1 {
//Note that site-identifier must be THE SAME on both primary and backup UPE of this VPLS
connection

site-identifier 17;
//Enable multi-homing and set site-preference to specify which router will handle
primary connection
multi-homing;
site-preference 200;
interface ge-0/0/5.1000;
}
ignore-encapsulation-mismatch;
}
}
}
}
}
HN-UPE3 {
interfaces {
ge-0/0/7 {
unit 1000 {
//Interface configuration is using the same vlan 1000 for customer 1 on all site in this
case study.
//Interface configuration should change according to L2 infrastructure requirement
description "TO VPLS CUSTOMER1 - CE2";
encapsulation vlan-vpls;
vlan-id 1000;
}
}
}
policy-options {
policy-statement VPLS-C1-Import {
term Customer1 {
from {
protocol bgp;
community VPLS-C1;
}
then accept;
}
term default {
then reject;
}
}

124
 policy-statement VPLS-C1-Export {
term Customer1 {
then {
community add VPLS-C1;
accept;
}
}
term default {
then reject;
}
}
community VPLS-C1 members target:18403:1000;
}
routing-instances {
VPLS-CUSTOMER1 {
instance-type vpls;
interface ge-0/0/7.1000;
route-distinguisher 1103:1000;
vrf-import VPLS-C1-Import;
vrf-export VPLS-C1-Export;
protocols {
vpls {
site-range 20;
no-tunnel-services;
site C1-3 {
//Note that site-identifier must be THE SAME on both primary and backup UPE of this VPLS
connection
site-identifier 17;
//Enable multi-homing and set site-preference to specify which router will handle
primary connection
multi-homing;
site-preference 100;
interface ge-0/0/7.1000;
}
ignore-encapsulation-mismatch;
}
}
}
}
}
}
interfaces {
ge-0/0/5 {
vlan-tagging;
encapsulation vlan-vpls;
}
ge-0/0/7 {
vlan-tagging;
encapsulation vlan-vpls;
}
}

c. Verification
The VPLS connection on backup UPE router will be in waiting state, but the primary UPE router should
still be aware of the backup’s existence

125
[edit groups VPLS-multihome]
juniper@vMX# run show vpls connections logical-system HN-UPE1
Layer-2 VPN connections:

Instance: VPLS-CUSTOMER1
Local site: C1-1 (17)
connection-site Type St Time last up # Up trans
//On the primary router – the backup VPLS connection is displayed with status RN –
Remote site not designated, with the same site ID
17 rmt RN
19 rmt Up Feb 16 11:37:44 2016 1
Remote PE: 10.0.2.101, Negotiated control-word: No
Incoming label: 262147, Outgoing label: 262145
Local interface: lsi.51380224, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPLS-CUSTOMER1 local site 17 remote site 19

[edit groups VPLS-multihome]

juniper@vMX# run show vpls connections logical-system HN-UPE3
Layer-2 VPN connections:

Instance: VPLS-CUSTOMER1
Local site: C1-3 (17)
connection-site Type St Time last up # Up trans
//On the backup router – the backup VPLS connection is displayed with status LN – Local
site not designated¸with two connection: to remote site and to local primary site.
17 rmt LN
19 rmt LN

[edit groups VPLS-multihome]

juniper@vMX# run show vpls connections logical-system HCM-UPE1
Layer-2 VPN connections:

Instance: VPLS-CUSTOMER1
Local site: C1-2 (19)
//The remote site only see one connection to the primary site.
connection-site Type St Time last up # Up trans
17 rmt Up Feb 16 11:37:44 2016 1
Remote PE: 10.0.1.101, Negotiated control-word: No
Incoming label: 262145, Outgoing label: 262147
Local interface: lsi.219152384, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPLS-CUSTOMER1 local site 19 remote site 17

We can also verify the communication between backup and remote site by looking at bgp.l2vpn.0 table.
Similar to L2VPN multihome case (3.4.3.c)

126