100% found this document useful (1 vote)

79 views

Iz JNCIE SP FSL1v1.0

Uploaded by

marcelo zapata

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

100% found this document useful (1 vote)

79 views

Iz JNCIE SP FSL1v1.0

Uploaded by

marcelo zapata

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 357

iNET ZERO - JNCIE-SP

Full-Scale Labs, Volume 1

V1.0 (2017)

For Juniper Networks ® - JNCIE-SP 2017 Lab exam

2 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Table of Contents
Table of Contents ......................................................................................................................................... 2
Introduction ................................................................................................................................................. 6
About The Author ..................................................................................................................................... 6
Reviewer................................................................................................................................................... 6
Copyright and licensing information ........................................................................................................ 7
Disclaimer ................................................................................................................................................. 7
How To Use This Book .............................................................................................................................. 8
Physical Diagrams ..................................................................................................................................... 9
Practice Lab 1 ............................................................................................................................................. 11
Logical Diagrams..................................................................................................................................... 11
Addressing Scheme ................................................................................................................................ 12
Topic 1: Device Infrastructure ................................................................................................................ 14
Topic 2: IGP ............................................................................................................................................ 14
Topic 3: MPLS ......................................................................................................................................... 16
Topic 4: BGP ........................................................................................................................................... 17
Topic 5: VPN ........................................................................................................................................... 19
Topic 6: CoS ............................................................................................................................................ 19
Practice Lab 2 ............................................................................................................................................. 20
Logical Diagrams..................................................................................................................................... 20
Addressing Scheme ................................................................................................................................ 21
Topic 1: Device Infrastructure ................................................................................................................ 23
Topic 2: IGP ............................................................................................................................................ 24
Topic 3: MPLS ......................................................................................................................................... 25
JNCIE-SP Full-Scale Labs, Volume 1 : Table of Contents
Topic 4: BGP ........................................................................................................................................... 26
Topic 5: VPN ........................................................................................................................................... 27
Topic 6: CoS ............................................................................................................................................ 28
Practice Lab 3 ............................................................................................................................................. 29
Logical Diagrams..................................................................................................................................... 29
Addressing Scheme ................................................................................................................................ 30
Topic 1: Device Infrastructure ................................................................................................................ 32
Topic 2: IGP ............................................................................................................................................ 33
Topic 3: MPLS ......................................................................................................................................... 34
Topic 4: BGP ........................................................................................................................................... 35

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
2
3 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 5: VPN ........................................................................................................................................... 37

Topic 6: CoS ............................................................................................................................................ 37
Practice Lab 4 ............................................................................................................................................. 38
Logical Diagrams..................................................................................................................................... 38
Addressing Scheme ................................................................................................................................ 39
Topic 1: Device Infrastructure ................................................................................................................ 41
Topic 2: IGP ............................................................................................................................................ 42
Topic 3: MPLS ......................................................................................................................................... 43
Topic 4: BGP ........................................................................................................................................... 44
Topic 5: VPN ........................................................................................................................................... 46
Topic 6: Multicast ................................................................................................................................... 47
Practice Lab 5 ............................................................................................................................................. 47
Logical Diagrams..................................................................................................................................... 48
Addressing Scheme ................................................................................................................................ 49
Topic 1: Device Infrastructure ................................................................................................................ 50
Topic 2: IGP ............................................................................................................................................ 51
Topic 3: MPLS ......................................................................................................................................... 52
Topic 4: BGP ........................................................................................................................................... 53
Topic 5: VPN ........................................................................................................................................... 55
Topic 6: Multicast ................................................................................................................................... 57
Practice Lab 1 Solutions ............................................................................................................................. 58
Topic 1: Device Infrastructure ................................................................................................................ 58
Verification ......................................................................................................................................... 60
Topic 2: IGP ............................................................................................................................................ 65
JNCIE-SP Full-Scale Labs, Volume 1 : Table of Contents
Verification ......................................................................................................................................... 69
Topic 3: MPLS ......................................................................................................................................... 79
Verification ......................................................................................................................................... 81
Topic 4: BGP ........................................................................................................................................... 90
Verification ......................................................................................................................................... 94
Topic 5: VPN ......................................................................................................................................... 103
Verification ....................................................................................................................................... 107
Topic 6: CoS .......................................................................................................................................... 114
Verification ....................................................................................................................................... 115
Practice Lab 2 Solutions ........................................................................................................................... 119

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
3
4 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 1: Device Infrastructure .............................................................................................................. 119

Verification ....................................................................................................................................... 121
Topic 2: IGP .......................................................................................................................................... 123
Verification ....................................................................................................................................... 125
Topic 3: MPLS ....................................................................................................................................... 128
Verification ....................................................................................................................................... 131
Topic 4: BGP ......................................................................................................................................... 138
Verification ....................................................................................................................................... 145
Topic 5: VPN ......................................................................................................................................... 153
Verification ....................................................................................................................................... 158
Topic 6: CoS .......................................................................................................................................... 163
Verification ....................................................................................................................................... 164
Practice Lab 3 Solutions ........................................................................................................................... 167
Topic 1: Device Infrastructure .............................................................................................................. 167
Verification ....................................................................................................................................... 171
Topic 2: IGP .......................................................................................................................................... 174
Verification ....................................................................................................................................... 176
Topic 3: MPLS ....................................................................................................................................... 180
Verification ....................................................................................................................................... 182
Topic 4: BGP ......................................................................................................................................... 189
Verification ....................................................................................................................................... 198
Topic 5: VPN ......................................................................................................................................... 208
Verification ....................................................................................................................................... 214
Topic 6: CoS .......................................................................................................................................... 220
JNCIE-SP Full-Scale Labs, Volume 1 : Table of Contents
Verification ....................................................................................................................................... 221
Practice Lab 4 Solutions ........................................................................................................................... 222
Topic 1: Device Infrastructure .............................................................................................................. 222
Verification ....................................................................................................................................... 224
Topic 2: IGP .......................................................................................................................................... 227
Verification ....................................................................................................................................... 231
Topic 3: MPLS ....................................................................................................................................... 237
Verification ....................................................................................................................................... 239
Topic 4: BGP ......................................................................................................................................... 247
Verification ....................................................................................................................................... 254

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
4
5 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 5: VPN ......................................................................................................................................... 262

Verification ....................................................................................................................................... 266
Topic 6: Multicast ................................................................................................................................. 279
Verification ....................................................................................................................................... 280
Practice Lab 5 Solutions ........................................................................................................................... 286
Topic 1: Device Infrastructure .............................................................................................................. 286
Verification ....................................................................................................................................... 287
Topic 2: IGP .......................................................................................................................................... 291
Verification ....................................................................................................................................... 293
Topic 3: MPLS ....................................................................................................................................... 299
Verification ....................................................................................................................................... 302
Topic 4: BGP ......................................................................................................................................... 309
Verification ....................................................................................................................................... 315
Topic 5: VPN ......................................................................................................................................... 325
Verification ....................................................................................................................................... 333
Topic 6: Multicast ................................................................................................................................. 348
Verification ....................................................................................................................................... 351

JNCIE-SP Full-Scale Labs, Volume 1 : Table of Contents

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
5
6 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Introduction

About The Author

Tony Tuan Nguyen

JNCIE-SP #2509, 3xCCIE #26930 (Routing/Switching, Security, Service Provider)

Tony is a Senior Network Engineer based in Sydney Australia. He has nearly 10 years’ intensive
experiences in operating, designing and optimising network infrastructure for carrier-class ISPs/MSPs
and mega-scale data centers. Throughout the years, Tony has worked for system integrators, large ISPs,
cloud services providers and networking vendors in APAC area in the roles of Network Consulting
Engineer, Network Development Engineer, Solution Architect.

Reviewer
Jörg Buesink

Jörg lives in the Netherlands near Amsterdam and brings more than 15 years of experience in the IT and
networking industry. He has worked for several large ISPs / service providers in the role of technical
consultant, designer and network architect. He has extensive experience in network implementation,
design and architecture. Jörg is quadruple JNCIE certified (JNCIE-DC#7, JNCIE-ENT#21, JNCIE-SP#284 and
JNCIE-SEC#30). He is also triple CCIE#15032 (Routing/ Switching, Service provider and Security), Cisco
JNCIE-SP Full-Scale Labs, Volume 1 : Introduction
CCDE#20110002 and Huawei HCIE#2188 Routing and Switching certified.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
6
7 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Copyright and licensing information

All rights reserved. No part of this publication may be reproduced or distributed in any form or by any
means without the prior written permission of iNET ZERO a registered company in the Netherlands. This
product cannot be used by or transferred to any other person. You are not allowed to rent, lease, loan
or sell iNET ZERO training products including this workbook and its configurations.

You are not allowed to modify, copy, upload, email, share, distribute this workbook and supporting
materials in any way. This product may only be used and printed for your own personal use and may not
be used in any commercial way.

Warning: Besides standard anti piracy techniques like document watermarks and password protection
this workbook also contains a steganographyID making this workbook unique and always traceable to
the original buyer.

Juniper (c), Juniper Networks inc, JNCIE, JNCIP, JNCIS, JNCIA, Juniper Networks Certified Internet Expert,
are registered trademarks of Juniper Networks, Inc.

Disclaimer
This workbook is designed to assist candidates in the preparation for Juniper Networks’ JNCIE Service
Provider Practical Lab Exam. Any similarities between material presented in this workbook and the
actual JNCIE-SP lab exam authorised by Juniper Networks or actual settings in any production networks
in real life are completely coincidental, unexpected and absolutely unintended by the author. While a lot
of efforts have been put in order to ensure that all material is as complete and accurate as possible, the
enclosed material is presented on an “as is” basis. The author and iNETZERO do not assume any liability
or responsibility to any person or entity with respect to loss or damages incurred from the information
or solution contained/presented in/by this workbook.

JNCIE-SP Full-Scale Labs, Volume 1 : Introduction

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
7
8 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

How To Use This Book

The JNCIE-SP Full-Scale Lab volume 1 and volume 2 workbooks are specifically designed for candidates
to practice technologies in the public blueprint of Juniper Networks’ JNCIE-SP Lab Exam. It also helps
candidates practice skills relating to time management, task prioritisation, dependencies and
correlations.
Each volume consists of 5 full-scale labs with questions falling under the following topics. Volume 1
focuses on building foundations of core technologies, volume 2 introduces troubleshooting tasks for
core topics.

• Topic 1: Device Infrastructure.

• Topic 2: IGP.
• Topic 3: MPLS.
• Topic 4: BGP.
• Topic 5: VPN.
• Topic 6: CoS or Multicast.

This JNCIE-SP Full-Scale Lab Workbook bases on the JNCIE-SP Lab Topology of iNET ZERO which consists
of 9 physical/virtual MX-series routers running JUNOS version 14.2 and above. In each lab, you are
required to configure 8 routers (R1 through R8). The remaining router is called VR which simulates
C,T,P,DC,CE routers through routing-instances. You can book for the labs of this workbook from
iNETZERO Rack Rental Services via URL http://www.inetzero.com/rack-reservation/. Two other options
are to deploy your own virtual lab environment based on vMX instances, and use Junosphere. However
we recommend you to use iNETZERO Rack Rental Services for full compatibility and consistency.

JNCIE-SP Full-Scale Labs, Volume 1 : Introduction

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
8
9 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Physical Diagrams
The diagrams below depict connectivity of the management network and the service provider core
network that all labs of this workbook base on.

• In each lab, there are 8x routers (R1 to R8) which candidate is asked to configure on.
• There is 1x router (VR) that is preconfigured with multiple virtual routing-instances simultating
CE, C, T, P routers representing customer, transit and peer routers. Candidate is not required to
configure the VR.
• For management connectivity, port fxp0 of all routers connect to a LAN segment which is used
as an out-of-band management network (10.10.1.0/24). Candidate can Telnet/SSH directly into
each router to access it.
• All labs will base on the diagram of the service provider network but please note that not all
connections will be used. This depends on the logical topology of each lab.

JNCIE-SP Full-Scale Labs, Volume 1 : Introduction

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
9
10 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

The diagram below depicts connectivity between any router amongst R1 through R8 acting as PE device
and CE, C, T or P routers. One each router from R1 to R8, most labs would use ports ge-0/0/4 and ge-
0/0/5 for L3VPN, mVPN and/or general Internet PE-C/T/P connections while port ge-0/0/3 is used for
L2VPN/VPLS.

JNCIE-SP Full-Scale Labs, Volume 1 : Introduction

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
10
11 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Practice Lab 1
Initial Configs: lab1-ini.rx.conf, Time: 7.5 hours, Passing Score: 65/100, Difficulty Level: 7/10
Topic Name Points Features at a glance
1 Device 15 LACP, LLDP, COPP ACL, ECMP, ECMP Hashing
Infrastructure
2 IGP 20 Multi-area OSPFv2, OSPFv3, IS-IS, Mutual Redistribution, LSDB
Protection
3 MPLS 15 RSVP-signalled LSPs, Auto-Bandwidth, Link-Protection, ERO, 6PE
4 BGP 25 Route Reflection, Multipath, Route Advertisement, RTBH
5 VPN 20 BGP Hub-Spoke L3VPN, BGP-signalled VPLS, Inter-AS L3VPN CsC
model
6 CoS 5 4-class CoS Queueing, CoS Scheduling, CoS Drop Profile/RED

Logical Diagrams

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
11
12 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1

Addressing Scheme
All necessary IPv4 and IPv6 addresses are preconfigured in the initial configurations of this lab. The
addressing scheme described here is informational only. Please discover initial configurations of the lab
prior to commencement.

• Service Provider Network 1 (SP1):

o Routers: R1, R2, R3, R4, R5 and R6
o Autonomous System: 123456, supernets are 150.1.0.0/16 and 2016:150::/48.
o OSPF area 0.0.0.0; IS-IS area 49.0016.
o Loopback0: 150.1.1.X/32, 2016:150:1:1::X/128 where X is router number.
o Core Interfaces: 150.1.Z.X/24, 2016:150:1:Z::X/64 where X is router number, Z is the
number that represents both routers, e.g. Z=12 for link between R1 and R2.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
12
13 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

o PE-T Interfaces: TTT.1.Y.1/30, 2016:TTT:1:Y::1/126 where Y is the VLAN number or

interface unit number and T is the transit number.
o PE-C/P/DC1 Interfaces: 150.1.Y.1/30, 2016:150:1:Y::1/126 where Y is the VLAN number
or interface unit number. The exception is for VLANs 110 and 111 where IPv4 addresses
are 169.254.Y.1/30 and there is no IPv6 address assigned.
o PE-CE Interfaces: 172.16.Y.1/30 where Y is the VLAN number or interface unit number.
• Service Provider Network 2 (SP2):
o Routers: R7 and R8
o Autonomous System: 78.
o Loopback0: 151.1.1.X/32, 2016:151:1:1::X/128 where X is router number.
o PE-CE Interfaces: 172.16.Y.1/30 where Y is the VLAN number or interface unit number.
This does not apply to PE’s interface that serves L2VPN CE routers.
• Inter-Service Provider Networks:
o CSC Interfaces (ge-0/0/6): 150.1.Z.X/24 where X is router number, Z is the number that
represents both routers, e.g. Z=57 for link between R5 and R7.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
13
14 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 1: Device Infrastructure

Total Points: 15

Task 1 (1 point). Annotate the configuration of all routers from R1 to R8 with a comment above the
‘system’ configuration stanza, specifying your full name and current date. For example:
/* Config made by Tony Tuan Nguyen, 2017-01-16 */
system {
...
}

Task 4 (4 points). Configure R1 with v4 COPP ACL to protect it from infrastructure attacks. Allow only
Telnet, SSH, FTP, SNMP, Syslog, RADIUS and NTP from management network 10.10.1.0/24; allow ping
and UDP-based traceroute from any source/destination but rate-limit them at 1Mbps; allow necessary
routing/signalling protocols needed for the next tasks, for BGP ensure that the COPP ACL does not need
to be updated any time a new BGP peer is added. Count the discarded packets with a counter named
DISCARDED-CP-PACKETS.

Task 5 (4 points). Configure all routers so that they can utilise equal-cost paths on the data plane and
can achieve the best granularity when hashing packets across ECMP paths for IP/MPLS traffic, for
simplicity, the assumption is that this Service Provider Networks 1 and 2 use MX-series routers with only
DPC linecards. Ensure that the nexthop structure is a function of both hashing scheme and low-order
bits of IP address.

Task 6 (2 points). Configure all routers so that the SP Core Networks can handle jumbo Ethernet frames
as well as variable packets of MPLS L3/L2 VPN, MPLS TE and FRR services without fragmentation.

Topic 2: IGP
Total Points: 20
JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1
Task 1 (4 points). Configure OSPFv2 area 0.0.0.0 for IPv4 routing and IS-IS Level 2 area 49.0016 for IPv6
routing of Service Provider Network 1 which consists of routers R1, R2, R3, R4, R5 and R6.

Task 2 (4 points). Ensure that OSPF/IS-IS neighbourship can get established over the links as fast as
possible and OSPF can detect link failure events less than 1 second. All routers should not attempt to
establish any neighbourship over loopback interfaces.

Task 3 (4 points). Ensure OSPF and IS-IS reflect the exact bandwidth capacity of the links; ensure that
routing information propagated is authenticated with MD5 hashing at interface level.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
14
15 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

either R1 or R3, the remaining router should take responsibility for both IPv4 and IPv6 from DC1. There
should be no routing loop or suboptimal routing path. Note: you are allowed to use one static route on
R1 and R3 temporarily if topic BGP is not completed yet.

At the end of this topic, all routers in Service Provider Network 1 should have full IPv4/IPv6 reachability
with each other.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
15
16 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 3: MPLS
Total Points: 15

Task 2 (4 points). Configure full-mesh RSVP-signaled LSPs between all routers of Service Provider
Network 1; ensure that each of them requests a minimum of 100Mbps except the ones between R1 and
R6; all LSPs should be re-routed within tens of milliseconds upon failure of any link within the core
networks; all LSPs should be monitored and optimised for better path every 1 hour and ensure that the
newly optimised path is established before old path is torn down for reoptimisation activities. For this
task, please use the most efficient configuration mechanism to group common attributes of LSPs.

Task 3 (3 points). Configure the LSPs between routers R1 and R6 such that their bandwidth utilisation is
monitored and adjusted every 1 hour, the adjustment should be contained within range of 50Mbps and
150Mbps. Also the statistics of bandwidth utilisation should be recorded every 10 minutes into files
called autobw.log for diagnostic purpose. The biggest file size should be 1MB and the routers should
store up to 10 files. Please do not record statistics of transit LSPs.

Task 4 (3 points). Configure the LSPs between R5 and R6 such that they primarily travel across router R2
and their backup paths traverse router R4, ensuring that the backup path is pre-signaled but its
bandwidth reservation is not counted while the primary path is still up.

Task 5 (3 points). Allow for customers or peers to see MPLS hops of Service Provider Networks 1 when
performing ICMP ping and traceroute; also NOC team should be able to perform ping test for all LSPs;
Enable RSVP to signal MTU value along the path of all LSPs.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
16
17 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 4: BGP
Total Points: 25

Task 1 (5 points). Configure R3 and R4 as iBGP route reflectors for Service Provider Network 1 serving
R1, R2, R5 and R6 as their clients. R3 and R4 should always advertise BGP best paths regardless of
whether they are active in the RIB or not. Enable necessary AFI for iBGP sessions that are needed for the
whole lab. Ensure iBGP sessions are enabled with MD5 authentication and their liveness is monitored
through BFD.

Task 2 (8 points). Configure eBGP sessions between Service Provider Network 1 and customers, transits
and peers in accordance with the table below, ensure full IPv4/IPv6 reachability between customers,
transits and peers.

Local Router Peer Router ASN of Peer IPv4 of Peer IPv6 of Peer
Router Router Router
R1 C1 65001 150.1.119.2 2016:150:1:119::2
P1 100 150.1.100.2 2016:150:1:100::2
T1 111 111.1.120.2 2016:111:1:120::2
R2 C2 65002 150.1.102.2 2016:150:1::102::2
P2 200 150.1.101.2 2016:150:1::101::2
T2 222 222.1.123.2 2016:222:1:123::2
R3 P1 100 150.1.113.2 2016:150:1:113::2
R5 C3 65003 170.1.230.1 NIL
R6 C4 65004 150.1.107.2 ::ffff:150.1.107.2
T1 111 111.1.105.2 2016:111:1:105::2
T2 222 222.1.106.2 2016:111:1:106::2

Some test IPv4/IPv6 addresses are below. You can launch ping tests from any C/T/P routing-instance on
VR device.

• C1: 170.1.210.1, 2016:170:1:210::1

• C2: 170.1.220.1, 2016:170:1:220::1
• C3: 170.1.230.1
• C4: 170.1.240.1, 2016:170:1:240::1
JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1
• P1: 100.0.0.1, 2016:100::1
• P2: 200.0.0.1, 2016:200::1
• T1: 111.0.0.1, 2016:111::1, 12.0.0.1, 2016:12::1
• T2: 222.0.0.1, 2016:222::1, 12.0.0.2, 2016:12::2
• T3 (behind T1, T2): 123.0.0.1, 2016:123::1

Task 3 (3 points). Ensure that R6 can load balance traffic across T1 and T2, you can use IPv4 prefix
12.0.0.0/24 or 2016:12::/64 to test this task.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
17
18 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
18
19 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 5: VPN
Total Points: 20

Task 1 (6 points). Provide MPLS L3VPN service for VPN1 customer, including site CE1-1 as hub and sites
CE1-2, CE1-3 as spokes. The CE routers belong to AS 65501 and run BGP with Service Provider Network
1. You can launch ping tests from any participating CE routing-instance on VRF device with some test
IPv4 addresses below. Ensure that traffic from CE1-2 to CE1-3 gets across CE1-1 .

• CE1-1: 172.30.1[0-9].1
• CE1-2: 172.30.2[0-9].1
• CE1-3: 172.30.3[0-9].1

Task 2 (6 points). Provide VPLS service for VPN2 customer, including sites CE2-1, CE2-2, CE2-3, using BGP
as the signalling protocol. CE2-2 is dual-homed to R2 and R4 but ensure that R2 is the primary
connection. You can launch ping tests from any participating CE routing-instance on VRF device with
some test IPv4 addresses below. Note that CE2-2 uses VLAN 114 while CE2-1 and CE2-2 use VLAN 104.

• CE2-1: 172.30.40.1
• CE2-2: 172.30.40.2
• CE2-3: 172.30.40.3

Task 3 (8 points). Provide MPLS L3VPN service for VPN3 customer in Service Provider Network 2,
including sites CE3-1 and CE3-2 using OSPF as routing protocol. Provide MPLS CSC service for Service
Provider Network 2 in Service Provider Network 1. You can launch ping tests from any participating CE
routing-instance on VRF device with some test IPv4 addresses below.

• CE3-1: 172.30.70.1
• CE3-2: 172.30.80.1

Topic 6: CoS
Total Points: 5

Task 1 (5 points). Configure a 4-class CoS system within core network of Service Provider Network 1 in
accordance with the following table.
JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1
Class Queue Priority Allocated Bandwidth Drop Probability
NC 3 High 10% Low, Interpolated
EF 2 Medium-High 20% Low, Interpolated
AF 1 Medium-Low 20% Low, Interpolated
BE 0 Low 50% High, Interpolated

End of Practice Lab 1!

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
19
20 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Practice Lab 2
Initial Configs: lab2-ini.rx.conf, Time: 7.5 hours, Passing Score: 70/100, Difficulty Level: 7/10
Topic Name Points Features at a glance
1 Device 16 LACP, Syslog, System Services, Infrastructure ACLs, ECMP
Infrastructure
2 IGP 10 Multi-area OSPFv2, BFD, LFA, Authentication, LSDB Protection
3 MPLS 20 RSVP-signalled LSPs, Optimisation, Node-Link Protection, RSVP
Packaging
4 BGP 25 Route Reflection, Route Filtering, Community-based Policies
5 VPN 24 OSPF Hub-Spoke L3VPN, 6VPE, Inter-AS L3VPN Option B for
IPv4/v6 NLRIs
6 CoS 5 Route-to-LSP Mapping

Logical Diagrams

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
20
21 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2

• Service Provider Network 1 (SP1):

o Routers: R1, R2, R3, R4, R5 and R6.
o Autonomous System: 123456, supernets are 150.1.0.0/16 and 2016:150::/48.
o OSPFv3 area 0.0.0.0, area 0.0.0.1, area 0.0.0.6, area 0.0.0.22.
o Loopback0: 150.1.1.X/32, 2016:150:1:1::X/128 where X is router number.
o Core Interfaces: 150.1.Z.X/24, 2016:150:1:Z::X/64 where X is router number, Z is the
number that represents both routers, e.g. Z=12 for link between R1 and R2.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
21
22 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

o PE-T Interfaces: TTT.1.Y.1/30, 2016:TTT:1:Y::1/126 where Y is the VLAN number or

interface unit number and T is the transit number.
o PE-C/P Interfaces: 150.1.Y.1/30, 2016:150:1:Y::1/126 where Y is the VLAN number or
interface unit number.
o PE-DC1 Interfaces: 150.1.Y.X/24, 2016:150:1:Y::X/126 where Y is the VLAN number or
interface unit number and X is router number.
o PE-CE Interfaces: 172.16.Y.1/30 where Y is the VLAN number or interface unit number.
This does not apply to PE’s interface that serves L2VPN CE routers.
o PE-CE4 Interfaces: 2016:172:16:Y::1/126 where Y is the VLAN number or interface unit
number.
• Service Provider Network 2 (SP2):
o Routers: R7 and R8.
o Autonomous System: 78.
o Loopback0: 151.1.1.X/32, 2016:151:1:1::X/128 where X is router number.
o Core Interfaces: 151.1.Z.X/24, 2016:151:1:Z::X/64 where X is router number, Z is the
number that represents both routers, e.g. Z=78 for link between R7 and R8.
o PE-CE Interfaces: 172.16.Y.1/30 where Y is the VLAN number or interface unit number.
• Inter-Service Provider Networks:
o Inter-AS Interfaces (ge-0/0/6): 150.1.Z.X/24 where X is router number, Z is the number
that represents both routers, e.g. Z=57 for link between R5 and R7. IPv4-mapped IPv6
addresses may be needed on these interfaces to facilitate certain routing propagation.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
22
23 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 1: Device Infrastructure

Total Points: 16

Task 1 (1 point). Annotate the configuration of all routers from R1 to R8 with a comment above the
‘system’ configuration stanza, specifying your full name and current date.

Task 5 (6 points). For every link of Service Provider Network 1 connecting to external ASNs or networks
(excluding DC2 and CE routers), configure an IPv4 ingress access-list called ACL-OUTSIDE-IN that governs
the following access.

Task 6 (1 point). Configure all routers so that they can utilise equal-cost paths on the data plane.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
23
24 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 2: IGP
Total Points: 10

Task 1 (3 points). Configure OSPFv2 for IPv4 routing in Service Provider Network 1 in accordance with
the provided routing protocols diagram. Ensure that external prefixes cannot enter area 0.0.0.22 from
the backbone area 0.0.0.0. However external prefixes (if any) can still be redistributed from area
0.0.0.22 in the opposite direction. All routers should not attempt to establish any neighbourship over
loopback interfaces.

• Area 0.0.0.0 is between R2 and R3, R3 and R5, R2 and R4, R4 and R5
• Area 0.0.0.1 is between R1 and R2, R1 and R3
• Area 0.0.0.6 is between R6 and R4, R6 and R5
• Area 0.0.0.22 is between DC2 and R2, DC2 and R4. DC2 is redistributing 10 external prefixes into
this area, being 150.1.9[0-9].0/24.

Task 3 (5 points). Ensure OSPFv2 neighbourship can get established over the links as fast as possible and
the protocol can detect link failure events less than 1 second. Taking a further step, OSPFv2 should pre-
build free loop alternate paths to achieve sub-second re-convergence. Also ensure OSPFv2 reflect the
exact bandwidth capacity of the links; and that routing information propagated (except for DC2) is
authenticated with MD5 hashing. Please use the most efficient configuration method to enable the
features.

Task 4 (2 points). Ensure that OSPFv2 LSDB is protected such that there would be no more than 200
external prefixes redistributed into OSPFv2. At the same time, ensure that every OSPFv2 router is up
and running normally for 30 minutes before it can pass any traffic. Record OSPF neighbour state changes
into a local file called ospf.log.

At the end of this topic, all routers should have full IPv4 reachability with each other within their
respective Service Provider Networks.
JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
24
25 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 3: MPLS
Total Points: 20

Task 3 (4 points). Configure all LSPs that their bandwidth utilisation is monitored and adjusted every 1
hour, the adjustment should be contained within range of 100Mbps and 500Mbps. The statistics of
bandwidth utilisation should be recorded every 10 minutes into files called autobw.log for diagnostic
purpose. Please do not record statistics of transit LSPs. Also ensure that the path that each LSP chooses
is the one that concurrently has lowest bandwidth reserved by RSVP.

Task 4 (4 points). Configure all routers such that they concatenate RSVP messages and explicitly require
acknowledgement for them. Allow only up to 80% of link bandwidth to be reservable. Moreover, they
should trigger an immediate reservation update via OSPF LSA Type 10 when the current reported usage
of LSA is different from the actual RSVP reservation by at least 5 percent.

Task 5 (2 points). When customers or peers perform ping/traceroute, mask MPLS topology of Service
Provider Networks 1 so that they cannot see internal network paths of the SP1. On the other hand,
ensure that when NOC team performs ping/traceroute test within SP1 IGP domain, the test traffic uses
IGP paths rather than any LSP paths.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
25
26 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 4: BGP
Total Points: 25

Task 1 (5 points). Configure R3 and R4 as iBGP route reflectors for Service Provider Network 1 serving
R1, R2, R5 and R6 as their clients. R3 and R4 should always advertise BGP best paths regardless of
whether they are active in the RIB or not. Enable necessary AFI for iBGP sessions that are needed for the
whole lab. Ensure iBGP sessions are enabled with MD5 authentication and their bidirectional forwarding
capability is monitored through BFD.

Local Router Peer Router ASN of Peer IPv4 of Peer IPv6 of Peer
Router Router Router
R1 C1 65001 150.1.119.2 2016:150:1:119::2
P1 100 150.1.100.2 2016:150:1:100::2
T1 111 111.1.120.2 2016:111:1:120::2
R2 P2 200 150.1.101.2 2016:150:1::101::2
T2 222 222.1.123.2 2016:222:1:123::2
R4 111 111.1.105.2 2016:111:1:105::2
R5 100 150.1.113.2 2016:150:1:113::2
R6 C4 65004 150.1.131.2 ::150.1.131.2
T2 222 222.1.106.2 2016:111:1:106::2

You can launch ping tests from any C/T/P routing-instance on VRF device with some test IPv4/IPv6
addresses below.

• C1: 170.1.210.1, 2016:170:1:210::1

• C4: 170.1.240.1, 2016:170:1:240::1
• P1: 100.0.0.1, 2016:100::1
• P2: 200.0.0.1, 2016:200::1
• T1: 111.0.0.1, 2016:111::1, 12.0.0.1, 2016:12::1
• T2: 222.0.0.1, 2016:222::1, 12.0.0.2, 2016:12::2
JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2
• T3 (behind T1, T2): 123.0.0.1, 2016:123::1

Task 4 (5 points). Implement routing policies with a community system that allows for customers of SP1
to signal SP1 that it should prepend a certain amount of ASNs towards either other customers or peers.
Customers of SP1 do not have to manually engage SP1 to perform the prepending. Ensure only
customers can perform such routing trigger.

Community Description
16:1611 Prepend 1x ASN outbound to other customers
16:1612 Prepend 2x ASN outbound to other customers

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
26
27 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

16:1613 Prepend 3x ASN outbound to other customers

16:1621 Prepend 1x ASN outbound to other peers
16:1622 Prepend 2x ASN outbound to other peers
16:1623 Prepend 3x ASN outbound to other peers

Topic 5: VPN
Total Points: 24

Task 1 (6 points). Provide MPLS L3VPN service for VPN1 customer, including site CE1-1 as hub and sites
CE1-2, CE1-3 as spokes. The CE routers run OSPFv2 with Service Provider Network 1. Ensure that traffic
from CE1-2 to CE1-3 traverses CE1-1. You can launch ping tests from any participating CE routing-
instance on VRF device with some test IPv4 addresses below.

• CE1-1: 172.30.1[0-9].1
• CE1-2: 172.30.2[0-9].1
• CE1-3: 172.30.3[0-9].1

Task 2 (6 points). Provide MPLS L3VPN service for VPN4 customer, including sites CE4-1 and CE4-2. The
CE routers run BGP IPv6 NLRI with Service Provider Network 1. You can launch ping tests from any
participating CE routing-instance on VRF device with some test IPv6 addresses below.

• CE4-1: 2016:172:30:9[0-9]::1
• CE4-2: 2016:172:30:10[0-9]::1

Task 3 (6 points). Provide Inter-AS MPLS L3 VPN Option B for VPN1 customer in co-operation with
Service Provider Network 2, including site CE1-5 using OSPF as routing protocol. You can launch ping
tests from any participating CE routing-instance on VRF device with some test IPv4 addresses below. You
are not allowed to use the same route-target value in two Servicer Provider networks 1 and 2.

• CE1-5: 172.30.11[0-9].1
JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2
Task 4 (6 points). Provide Inter-AS MPLS L3 VPN Option B, for VPN4 customer in co-operation with
Service Provider Network 2, including site CE4-3 using BGP as routing protocol. You can launch ping tests
from any participating CE routing-instance on VRF device with some test IPv4 addresses below. You are
not allowed to use the same route-target value in two Servicer Provider networks 1 and 2. You are also
not allowed to use native IPv6 peering between the two Service Provider networks.

• CE4-3: 2016:172:30:12[0-9]::1

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
27
28 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 6: CoS
Total Points: 5

Task 1 (5 points). Ensure that IPv4 and IPv6 between customers C1 and C4 traverse different LSPs across
the network of SP1.

End of Practice Lab 2!

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
28
29 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Practice Lab 3
Initial Configs: lab3-ini.rx.conf, Time: 7.5 hours, Passing Score: 65/100, Difficulty Level: 8/10
Topic Name Points Features at a glance
1 Device 14 LACP, Syslog, Sampling, NetFlow, VRRP
Infrastructure
2 IGP 12 Multilevel IS-IS, BFD, LFA, Authentication, LSDB Protection, SPF
Timers
3 MPLS 18 RSVP-signalled LSPs, Optimisation, Link Protection, SRLG, 6PE
4 BGP 30 Route Reflection with Add-Path, UECMP, Transport Optimisation,
Route Filtering
5 VPN 20 BGP Hub-Spoke L3VPN with dual uplinks, SoO, OSPF Sham-Link,
Inter-AS L3VPN Option C
6 CoS 6 1-rate 2-colour Policing

Logical Diagrams

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
29
30 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3

• Service Provider Network 1 (SP1):

o Routers: R1, R2, R3, R4, R5 and R6.
o Autonomous System: 123456, supernets are 150.1.0.0/16 and 2016:150::/48.
o IS-IS area 49.0016.
o Loopback0: 150.1.1.X/32, 2016:150:1:1::X/128 where X is router number.
o Core Interfaces: 150.1.Z.X/24, 2016:150:1:Z::X/64 where X is router number, Z is the
number that represents both routers, e.g. Z=12 for link between R1 and R2.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
30
31 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

o PE-T Interfaces: TTT.1.Y.1/30, 2016:TTT:1:Y::1/126 where Y is the VLAN number or

interface unit number and T is the transit number.
o PE-C/P Interfaces: 150.1.Y.1/30, 2016:150:1:Y::1/126 where Y is the VLAN number or
interface unit number.
o PE-DC2 Interfaces: 150.1.Y.X/24, 2016:150:1:Y::X/64 where Y is the VLAN number or
interface unit number and X is router number.
o PE-CE Interfaces: 172.16.Y.1/30 where Y is the VLAN number or interface unit number.
This does not apply to PE’s interface that serves L2VPN CE routers.
• Service Provider Network 2 (SP2):
o Routers: R7 and R8.
o Autonomous System: 78.
o Loopback0: 151.1.1.X/32, 2016:151:1:1::X/128 where X is router number.
o Core Interfaces: 151.1.Z.X/24, 2016:151:1:Z::X/64 where X is router number, Z is the
number that represents both routers, e.g. Z=78 for link between R7 and R8.
o PE-CE Interfaces: 172.16.Y.1/30 where Y is the VLAN number or interface unit number.
• Inter-Service Provider Networks:
o Inter-AS interfaces (ge-0/0/6): 150.1.Z.X/24 where X is router number, Z is the number
that represents both routers, e.g. Z=57 for link between R5 and R7. IPv4-mapped IPv6
addresses may be needed on these interfaces to facilitate certain routing propagation.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
31
32 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 1: Device Infrastructure

Total Points: 14

Task 1 (1 point). Annotate the configuration of all routers from R1 to R8 with a comment above the
‘system’ configuration stanza, specifying your full name and current date.

Task 2 (3 points). Configure LAG interfaces on each of routers R1, R2, R3, R4, R5, R6, R7 and R8 as the
following along with their IP addresses; ensure all routers proactively monitor status of member links.

Task 3 (3 points). Configure all routers in Service Provider Networks 1 and 2 to store logs into multiple
local files in accordance with the following classification. Ensure that priority and facility are included.

• File syslog for any warning messages, any information from daemons, any interactive command.
• File messages for any warning messages but not any firewall-related or interactive command
messages.
• File firewall for any firewall-related messages.
• File mpls for any MPLS/RSVP-related messages from RPD plus any warning from daemons.

Task 4 (4 points). Configure VRRP on routers R3 and R5 to provide gateway redundancy for DC2 on VLAN
136. The VRRP implementation should be secured with MD5 authentication and while supporting both
IPv4 and IPv6, it should achieve load-balancing so that both links can be utilised. Any new DC router
connecting to VLAN 136 networks should be able to obtain IPv6 address automatically.

Task 5 (3 points). Configure all routers in Service Provider Network 1 to sample 1 out of 1000 transiting
IPv4 packets coming in/out via interfaces connecting to external networks (except for MPLS L3/L2VPN
links). There should be no more than 5000 sampled packets per second. All routers should store
sampling data in series of file sampling.log and send to remote server 10.10.1.77 on port 9996. The
number of local files should not exceed 10 with 5MB per file.
JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3
Task 6 (1 point). Configure all routers so that the SP Core Networks can handle jumbo Ethernet frames
as well as variable packets of MPLS L3/L2 VPN, MPLS TE and FRR services without fragmentation.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
32
33 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 2: IGP
Total Points: 12

Task 1 (3 points). Configure IS-IS area 49.0016 for IPv4/IPv6 routing in Service Provider Network 1 in
accordance with the provided routing protocols diagram. A static route may be used to accommodate
IS-IS Level 1 routing. All routers should not attempt to establish any neighbourship over loopback
interfaces. Ensure DC2 can be reached by all IS-IS routers.

Task 3 (3 points). Ensure IS-IS neighbourship can get established over the links as fast as possible and
the protocol can detect link failure events less than 1 second. Taking a further step, IS-IS should pre-
build free loop alternate paths to achieve sub-second re-convergence. Also ensure IS-IS reflect the exact
bandwidth capacity of the links; and that routing information propagated is authenticated with MD5
hashing. Please use the most efficient configuration method to enable the features.

Task 4 (4 points). Configure the following IS-IS features. At the end of this topic, all routers should have
full IPv4 reachability with each other within their respective Service Provider Networks.

• Allow IS-IS path metric to scale over the value of 1023.

• Reduce the amount of control traffic generated by IS-IS, but also tune SPF calculation of IS-IS to
react quicker to the change of topology.
• Ensure that IS-IS LSDB is protected such that there would be no more than 200 external prefixes
redistributed into IS-IS.
• Ensure that every IS-IS router boots up and runs normally for at least 30 minutes before it can
pass any transit traffic.
• Record IS-IS neighbour state changes into a local file called isis.log.
JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
33
34 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 3: MPLS
Total Points: 18

Task 1 (2 points). Configure IS-IS to build TE database for Service Provider Network 1; ensure the tailend
router is the one who removes MPLS stack instead of the penultimate router. For Service Provider
Network 2, enable LDP as the signalling protocol between R7 and R8.

Task 2 (10 points). Configure full-mesh RSVP-signaled LSPs between all routers of Service Provider
Network 1 with the following characteristics.

• All LSPs should have setup/holding priorities of 5. There could be other LSPs with higher
priorities being configured in upcoming projects so please ensure that when a LSP is to be
moved due to pre-emption, the system gives it at least 30sec to find an alternative path before
tearing it down.
• All LSPs should be re-routed within tens of milliseconds upon failure of any link within the core
network.
• All LSPs should be monitored and optimised for better path every 1 hour and ensure that the
newly optimised path is established before old path is torn down for reoptimisation activities.
• Ensure that the old path is kept for at least 60 second after the newly optimised path is in use to
prevent stale MPLS label due to big churn of re-convergence that could drop traffic.
• Any link can be taken out of services easily without reconfiguring all LSPs on all routers.
• When equal cost paths exist, all LSPs should randomly select the best one to follow.
• Please use the most efficient configuration method to group common attributes of LSPs.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
34
35 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 4: BGP
Total Points: 30

Task 1 (5 points). Configure R3 and R4 as iBGP route reflectors for Service Provider Network 1 serving
R1, R2, R5 and R6 as their clients. R3 and R4 should always advertise BGP best paths regardless of
whether they are active in the RIB or not. Ensure iBGP sessions are enabled with MD5 authentication.
Configure R8 as iBGP route reflector for Service Provider Network 2 serving R7 as its only client;
replicate all features of SP1 above. Additionally for Service Provider Network 2: ensure iBGP session’s
bidirectional forwarding capability is verified; optimise BGP transport for routing updates and re-
convergence; enable GR/NSF functionality such that BGP routers help each other re-converge under
reboot/maintenance/OS upgrade situations while minimising the radius of the impact.

Task 2 (8 points). Configure eBGP sessions between Service Provider Network 1 and customers, transits
and peers in accordance with the table below (in the next page), ensure full IPv4/IPv6 reachability
between customers, transits and peers.

Local Link Peer ASN of Peer IPv4 of Peer IPv6 of Peer

Router Bandwidth Router Router Router Router
R1 N/A C1 65001 150.1.119.2 2016:150:1:119::2
5Gbps P1 100 150.1.100.2 2016:150:1:100::2
1Gbps T1 111 111.1.120.2 2016:111:1:120::2
2Gbps T2 222 222.1.106.2 2016:111:1:106::2
R2 N/A C2 65002 150.1.102.2 2016:150:1:102::2
1Gbps P1 100 150.1.113.2 2016:150:1:113::2
6Gbps P2 200 150.1.101.2 2016:150:1::101::2
1Gbps T2 222 222.1.123.2 2016:222:1:123::2
R3 2Gbps P2 200 150.1.137.2 2016:150:1:137::2
R4 2.5Gbps T1 111 111.1.105.2 2016:111:1:105::2
R6 N/A C4 65004 150.1.131.2 ::150.1.131.2

You can launch ping tests from any C/T/P routing-instance on VRF device with some test IPv4/IPv6
JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3
addresses below.

• C1: 170.1.210.1, 2016:170:1:210::1

Task 3 (5 points). Implement the following features/policies for Service Provider Network 1:

• Display the true 4-byte ASN form.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
35
36 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

• Any private ASN in the AS_PATH of prefixes should be removed before advertising out to
Internet.
• Protect BGP routing table by accepting only up to 1000 prefixes via peers to avoid mistaken
route-leak of Internet routes. Any violated session should be kept in Idle for 15 minutes and
automatically attempt to recover.

Task 4 (5 points). Implement the following features/policies for Service Provider Network 1:

• Protect BGP routing table by not accepting IPv4 prefixes documented in RFCs 1918, 3330, 5735,
and 6598.
• Protect BGP routing table by accepting only IPv4 prefixes with subnet mask length between /8
and /24, and IPv6 prefixes with subnet mask length between /32 and /64.
• Do not advertise Internet prefixes learnt via transits to peers and vice versa, also do not
advertise prefixes via one transit to another.

Task 5 (5 points). Implement the following features/policies for Service Provider Network 1:

• The route reflectors should be able to send up to 4 parallel best paths in iBGP updates for IPv4
NLRI.
• Enable BGP multipath and signal the bandwidth capacity of each external link to the internal
BGP network in order to achieve proportional traffic load-sharing for eligible prefixes.
• You can use the following commands to test this task:
lab@VMX-R1> show route 123.0.0.1 active-path extensive | match balance
Next hop: 222.1.106.2 via ge-0/0/4.106 balance 67%, selected
Next hop: 111.1.120.2 via ge-0/0/4.120 balance 33%

lab@VMX-R5> show route 100.0.0.0/24 active-path extensive | match balance

Protocol next hop: 150.1.1.1 Balance: 83%
Protocol next hop: 150.1.1.2 Balance: 17%

Task 6 (2 points). Announce the IPv4/IPv6 supernets of Service Provider Network 1 on R3 and R4 (2
static routes are allowed on each router).

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
36
37 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 5: VPN
Total Points: 20

Task 1 (10 points). Provide MPLS L3VPN service for VPN1 customer, including site CE1-1 as hub and sites
CE1-2, CE1-3 as spokes. The CE routers belong to AS 65501 and run BGP with Service Provider Network
1. You can launch ping tests from any participating CE routing-instance on VRF device with some test
IPv4 addresses below. Ensure that traffic from CE1-2 to CE1-3 gets across CE1-1. CE1-1 and CE1-2 are
dual-homed to the PE routers, ensure that there is no loop.

• CE1-1: 172.30.1[0-9].1
• CE1-2: 172.30.2[0-9].1
• CE1-3: 172.30.3[0-9].1

Task 2 (5 points). Provide MPLS L3VPN service in Service Provider Network 2 for VPN1 customer,
including sites CE1-4 and CE1-5. The CE routers run OSPF with Service Provider Network 2. Between CE1-
4 and CE1-5, there is a backdoor connection running OSPF as well. Please ensure that this connection is
used as a backup path only between the two sites. You can launch ping tests from any participating CE
routing-instance on VRF device.

• CE1-4: 172.30.13[0-9].1
• CE1-5: 172.30.11[0-9].1

Task 3 (5 points). Provide Inter-AS MPLS L3 VPN Option C for VPN1 customer in co-operation with
Service Provider Network 2, including sites CE1-4, CE1-5 using OSPF as spokes. Ensure that
communications between SP1 spokes and SP2 spokes are across the hub site being CE1-1. You are not
allowed to use the same route-target value in two Servicer Provider networks 1 and 2.

Topic 6: CoS
Total Points: 6

Task 1 (6 points). Configure 1-rate 2-colour policing filters to rate-limit customers in accordance with
policies below (in the next page). Please note that for each customer, the policing policy should apply to
both IPv4 and IPv6 protocol families as the whole.
JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3
Customer Bandwidth Limit Burst Allowance Violation Policy
C1 100Mbps 5msec Medium-High Loss Priority
C2 200Mbps 10msec High Loss Priority
C4 500Mbps 20msec Drop

End of Practice Lab 3!

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
37
38 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Practice Lab 4
Initial Configs: lab4-ini.rx.conf, Time: 7.5 hours, Passing Score: 75/100, Difficulty Level: 8.5/10
Topic Name Points Features at a glance
1 Device 12 SSH, User/Class Login, NTP, SNMPv3, Real-time Performance
Infrastructure Monitoring
2 IGP 14 Multi-area OSPFv2, OSPFv3, IPSec SA, BFD, Inter-VRF Routing
3 MPLS 21 RSVP-signalled LSPs, Optimisation, FRR, Fate-Sharing, LDP
Tunneling, 6PE
4 BGP 20 Route Reflection, Route Manipulation, Route Damping
5 VPN 24 OSPF Hub-Spoke L3VPN with Internet Access, 6VPE, LDP-signalled
VPLS, Inter-AS L3VPN Option A
6 Multicast 9 NG-MVPN with P2MP LDP

Logical Diagrams

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
38
39 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Addressing Scheme
All necessary IPv4 and IPv6 addresses are preconfigured in the initial configurations of this lab. The JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4
addressing scheme described here is informational only. Please discover initial configurations of the lab
prior to commencement.

• Service Provider Network:

o Routers: R1, R2, R3, R4, R5, R6, R7, R8.
o Autonomous System: 1.57920, supernets are 150.1.0.0/16 and 2016:150::/48.
o Loopback0: 150.1.1.X/32, 2016:150:1:1::X/128 where X is router number.
o Core Interfaces: 150.1.Z.X/24, 2016:150:1:Z::X/64 where X is router number, Z is the
number that represents both routers, e.g. Z=12 for link between R1 and R2.
o PE-T Interfaces: TTT.1.Y.1/30, 2016:TTT:1:Y::1/126 where Y is the VLAN number or
interface unit number and T is the transit number.
o PE-C/P Interfaces: 150.1.Y.1/30, 2016:150:1:Y::1/126 where Y is the VLAN number or
interface unit number.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
39
40 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

o PE-DC1 Interfaces: 150.1.Y.X/24, 2016:150:1:Y::X/64 where Y is the VLAN number or

interface unit number and X is router number.
o PE-CE Interfaces: 172.16.Y.1/30 where Y is the VLAN number or interface unit number.
This does not apply to PE’s interface that serves L2VPN CE routers.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
40
41 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 1: Device Infrastructure

Total Points: 12

Task 1 (1 point). Annotate the configuration of all routers from R1 to R8 with a comment above the
‘system’ configuration stanza, specifying your full name and current date.

Task 3 (3 points). Configure the following RADIUS, NTP and SNMPv3 configurations:

• Use NTP server at address 172.16.1.77, password: juniper77.

• Use RADIUS server at address 172.16.1.66, password: juniper66.
• Use SNMPv3 security model USM with view parameters below:
o Username: juniper
o Authentication method: MD5
o Authentication password: juniper55
o Encryption method: 3DES
o Encryption password: juniper55@
o Security level: privacy
o Root OID: 1.3.6.1.4.1.2636
• Use SNMPv3 notification parameters below:
o Server at address 172.16.1.55
o Security model: USM
o Security level: privacy
o Notification Type: Trap
o Notification OIDs: snmpTraps, jnxTraps

Task 4 (3 points). Configure the following combinations of user and permission. The authentication
priority should be via RADIUS first and then local password database. JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4

User Password Class Permissions

eng Eng123 super-user all
ops Ops123 operator clear, network, reset, trace, view
tac TAC123 TAC all except: clear, configure, edit, commit, start shell

Task 5 (6 points). On R6, generate multiple synthetic traffic flows towards Internet destinations via
different transit links with the intention of continuous monitoring for connectivity that represents
customer experiences. The destinations are 123.0.1.1, 123.0.2.1, 123.0.3.1, 123.0.4.1, they accept ICMP
ping packets. Each transit link should have its own synthetic traffic flow that is independent of regular
routing calculation. For example, if a probe on R6 destined to 123.0.1.1 is used for testing transit link via
provider T1 out of R1, packets destined to 123.0.0.1 should always use that transit link even if it is not
the best path from R6’s perspectives. This task may need to be designed and implemented in
conjunction with iBGP routing policies.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
41
42 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 2: IGP
Total Points: 14

Task 1 (4 points). Configure OSPFv2 for IPv4 routing and OSPFv3 for IPv6 routing in accordance with the
provided routing protocols diagram. Ensure that external prefixes cannot enter area 0.0.0.1 from the
backbone area 0.0.0.0. However external prefixes (if any) can still be redistributed from area 0.0.0.1 in
the opposite direction. All routers should not attempt to establish any neighbourship over loopback
interfaces.

• Area 0.0.0.0 is between R2, R3, R4, R5, R6 and R7.

• Area 0.0.0.1 is between R1 and R2, R1 and R3.
• Area 0.0.0.8 is between R8 and R6, R8 and R7.

Task 2 (4 points). Ensure OSPFv2/v3 neighbourship can get established over the links as fast as possible
and the protocol can detect link failure events less than 1 second. Also ensure OSPFv2/v3 reflect the
exact bandwidth capacity of the links; and that routing information propagated by OSPFv2/v3 (except
for DC1) is protected by IPSec. Please use the most efficient configuration method.

Task 3. (6 points). Configure OSPFv3 area 0.0.0.0 for IPv4/IPv6 routing with DC1 in an instance that is
separate from the OSPFv3 instance of the core networks; advertise an IPv4 supernet prefix representing
Service Provider Network as well as an IPv4 default route into DC1; mutually redistribute IPv6 prefixes
between OSPFv3 instances and ensure that IPv4 traffic from DC1 to core networks prefer R1’s link while
IPv6 traffic from DC1 to core networks prefer R3’s link. Upon the failure of either R1 or R3, the
remaining router should take responsibility for both IPv4 and IPv6 from DC1. There should be no routing
loop or suboptimal routing path. Note: you are allowed to use one static route on R1 and R3.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
42
43 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 3: MPLS
Total Points: 21

Task 1 (2 points). Configure OSPFv2 to build TE database for Service Provider Network; ensure the
tailend router is the one who removes MPLS stack instead of the penultimate router.

Task 2 (8 points). Configure full-mesh RSVP-signaled LSPs between R2, R3, R4, R5, R6, R7 of the Service
Provider Network with the following characteristics.

• All LSPs should be bridged into detour LSPs within tens of milliseconds upon failure of any link
within the core network at the node that detects the failure.
• All LSPs should be monitored and optimised for better path every 1 hour and ensure that the
newly optimised path is established before old path is torn down for reoptimisation activities.
• All routers should wait for at least 30 seconds before using that newly optimised path and at the
same time: ensure that the old path is kept for at least 60 seconds after the newly optimised
path is in use to prevent stale MPLS label due to big churn of re-convergence that could drop
traffic.
• Bidirectional forwarding capability of each LSP should be verified and signalled within 1 second.
• When equal cost paths exist, all LSPs should select the one that has got bandwidth filled most.
• Please use the most efficient configuration method to group common attributes of LSPs.

Task 3 (5 points). Implement LDP on the links between R1 and R2, R1 and R3, R8 and R6, R8 and R7.
Ensure that the LDP islands are interconnected across the RSVP-based core network and can sustain
failure of either R2, R3, R6 or R7. You cannot implement LDP on R4, R5 and these routers should not
have loopback0 addresses of R1 and R8 in their inet.3 table.

Task 5 (1 point). Allow for customers or peers to see MPLS hops of the Service Provider Network when
performing ICMP ping and traceroute; Enable RSVP to signal MTU value along the path of all LSPs.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
43
44 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 4: BGP
Total Points: 20

Task 2 (5 points). Configure eBGP sessions between Service Provider Network and customers, transits
and peers in accordance with the table below, ensure full IPv4/IPv6 reachability between customers,
transits and peers.

Local Peer Router ASN of Peer Router IPv4 of Peer Router IPv6 of Peer Router
Router
R1 C1 65001 150.1.119.2 2016:150:1:119::2
P1 100 150.1.100.2 2016:150:1:100::2
T1 111 111.1.120.2 2016:111:1:120::2
T2 222 222.1.106.2 2016:111:1:106::2
R2 C2 65002 150.1.102.2 2016:150:1:102::2
P1 100 150.1.113.2 2016:150:1:113::2
P2 200 150.1.101.2 2016:150:1::101::2
T2 222 222.1.123.2 2016:222:1:123::2
R6 C4 65004 150.1.107.2 ::ffff:150.1.107.2
R7 T1 111 111.1.105.2 2016:111:1:105::2

You can launch ping tests from any C/T/P routing-instance on VRF device with some test IPv4/IPv6
addresses below.

• C1: 170.1.210.1, 2016:170:1:210::1

• C4: 170.1.240.1, 2016:170:1:240::1
• P1: 100.0.0.1, 2016:100::1
• P2: 200.0.0.1, 2016:200::1
• T1: 111.0.0.1, 2016:111::1, 12.0.0.1, 2016:12::1
• T2: 222.0.0.1, 2016:222::1, 12.0.0.2, 2016:12::2 JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4
• T3 (behind T1, T2): 123.0.0.1, 2016:123::1

Task 3 (8 points). Implement the following features/policies for the Service Provider Network:

• Ingress routing:
o Primary inbound locations of prefixes 150.1.0.0/18, 150.1.64.0/18 should be R7-T1 and
R1-T2
o Primary inbound locations of prefixes 150.1.128.0/18, 150.1.192.0/18 should be R1-T1
and R2-T2
• Egress routing:
o Primary outbound locations for all prefixes should be in order of customers, peers, and
transits.
o Primary outbound locations for prefixes of ASNs 301, 303 should be T1

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
44
45 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

o Primary outbound locations for prefixes of ASNs 302, 304 should be T2.
• Protect BGP routing table from T2’s advertisements by accepting only IPv4 and IPv6 prefixes
with AS-PATH length of less than or equal 10.
• Protect BGP routing table and stability of the routing domain, configure a method that suppress
unstable prefixes from P1 and P2 until they become stable, perform suppression for P2’s
prefixes more aggressive than by default.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
45
46 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 5: VPN
Total Points: 24

Task 1 (6 points). Provide MPLS L3VPN service for VPN1 customer, including site CE1-1 as hub and sites
CE1-2, CE1-3, CE1-6 as spokes. Site CE1-6 is connected via an external provider P3 which agrees on
deploying Inter-AS MPLS L3VPN Option A with AS 1.57920. All CE routers run OSPFv2 with Service
Provider Network 1. Ensure that traffic from CE1-2 to CE1-3 or CE1-6 traverses CE1-1 and vice versa. You
can launch ping tests from any participating CE routing-instance on VRF device with some test IPv4
addresses below. You are NOT allowed to use any static route for this task.

• CE1-1: 172.30.1[0-9].1
• CE1-2: 172.30.2[0-9].1
• CE1-3: 172.30.3[0-9].1
• CE1-6: 172.30.15[0-9].1

Task 2 (6 points). Provide VPLS service for VPN2 customer, including sites CE2-2, CE2-3, CE2-4 using LDP
as the signalling protocol. CE2-2 is dual-homed to R6 and R8 but ensure that R8 is the primary
connection. You can launch ping tests from any participating CE routing-instance on VRF device with
some test IPv4 addresses below.

• CE2-2: 172.30.40.2
• CE2-3: 172.30.40.31
• CE2-4: 172.30.40.4

Task 3 (6 points). Provide MPLS L3VPN service for VPN4 customer, including sites CE4-1, CE4-2 and CE4-
3. Site CE4-3 is connected via an external provider P3 which agrees on deploying Inter-AS MPLS L3VPN
Option A with AS 1.57920. The CE routers run BGP IPv6 NLRI with Service Provider Networks. You can
launch ping tests from any participating CE routing-instance on VRF device with some test IPv6
addresses below.

• CE4-1: 2016:172:30:9[0-9]::1
• CE4-2: 2016:172:30:10[0-9]::1
• CE4-3: 2016:172:30:11[0-9]::1
JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4
Task 4 (6 points). Provide Internet Access for VPN1 customer. You are not allowed to use any other
interface between R1 and CE1-1. Ensure that traffic from CE1-2 and CE1-3 to Internet traverse the hub
CE1-1. You can launch ping tests from any participating CE routing-instance on VRF device towards an
Internet address being 123.0.0.1.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
46
47 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 6: Multicast
Total Points: 9

Task 1 (9 points). Configure a multicast solution for customer VPN1 with the following characteristics:

• There should not be any native multicast routing protocol such as PIM or GRE encapsulation
inside service provider core networks. Multicast streams should be carried over point-to-
multipoint MPLS LSPs.
• The service provider core networks should take responsibility for providing RP functionality for
customer VPN1. You are allowed to use IP address 150.1.1.253 on multiple PE devices for this
purpose.
• Multicast sources locate at the hub site CE1-1 while receivers locate at the spoke sites CE1-2 and
CE1-3.
• If traffic rate of multicast group 232.0.0.2 from source 172.30.10.1 is equal or higher than
15Mbps, R1 should switch from I-PMSI tunnel to a S-PMSI tunnel.
• If traffic rate of multicast group 232.0.0.3 from source 172.30.10.1 is equal or higher than
30Mbps, R1 should switch from I-PMSI tunnel to a S-PMSI tunnel.
• There should not be more than 10 S-PMSI tunnels created.
• Testbed:
o CE1-2 is preconfigured to join multicast groups 232.0.0.1, 232.0.0.2 with source
172.30.10.1 via IGMPv3 protocol.
o CE1-3 is preconfigured to join multicast groups 232.0.0.1, 232.0.0.3 with source
172.30.10.1 via IGMPv3 protocol.

End of Practice Lab 4!

Practice Lab 5
Initial Configs: lab5-ini.rx.conf, Time: 7.5 hours, Passing Score: 75/100, Difficulty Level: 9/10
Topic Name Points Features at a glance
1 Device 7 SLAX Scripting
Infrastructure
2 IGP 10 Multi-level IS-IS, Multi-topology IS-IS, BFD, Advanced Tuning
3 MPLS 14 Multi-tiered RSVP-signalled LSPs, Optimisation, Node-Link JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5
Protection
4 BGP 21 BGP Confederation, Flowspec, 6PE RTBH
5 VPN 38 Hub-Spoke L3VPN, non-VRF Internet Access, Egress Protection,
Route Leaking, mixed BGP/LDP-signalled VPLS, Advanced Tuning
6 Multicast 6 ASM Draft-Rosen MVPN, Multicast Scoping, MSDP for RP
Redundancy

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
47
48 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Logical Diagrams

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
48
49 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Addressing Scheme JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5

All necessary IPv4 and IPv6 addresses are preconfigured in the initial configurations of this lab. The
addressing scheme described here is informational only. Please discover initial configurations of the lab
prior to commencement.

• Service Provider Network:

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
49
50 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

o PE-C/P Interfaces: 150.1.Y.1/30, 2016:150:1:Y::1/126 where Y is the VLAN number or

interface unit number.
o PE-DC1 Interfaces: 150.1.Y.X/24, 2016:150:1:Y::X/64 where Y is the VLAN number or
interface unit number and X is router number.
o PE-CE Interfaces: 172.16.Y.1/30 where Y is the VLAN number or interface unit number.
This does not apply to PE’s interface that serves L2VPN CE routers.

Topic 1: Device Infrastructure

Total Points: 7

Task 1 (1 point). Annotate the configuration of all routers from R1 to R8 with a comment above the
‘system’ configuration stanza, specifying your full name and current date.

Task 3 (3 points). Create a SLAX script that provides RSVP information of MPLS LSPs that are currently
traversing a given interface in the core network. Output of the SLAX script should look similar to below:
lab@VMX-R5> op lsp-info interface ge-0/0/6.0
LSP Name LSP Type LSP State RESV BW Path Status
R5-TO-R7 Ingress Up 100kbps Link protected LSP
R5-TO-R8 Ingress Up 100kbps Node/Link protected LSP
Bypass->150.1.78.7 Transit Up 0bps
Bypass->150.1.68.8->150.1.78.7 Transit Up 0bps
Bypass->150.1.68.8 Transit Up 0bps

Some additional information that may assist you in creating the script:

• Use the following environment variables for the boilerplate:

version 1.0;
ns junos = "http://xml.juniper.net/junos/*/junos";
ns xnm = "http://xml.juniper.net/xnm/1.1/xnm";
ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0";

• The script should load all the code from the /var/db/scripts/ import/junos.xsl script file which
contains default templates and parameters. JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5
• The script should obtain RSVP-signalled LSP information via API element equivalent to the CLI
command show rsvp session detailed.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
50
51 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 2: IGP
Total Points: 10

Task 1 (3 points). Configure IS-IS area 49.0018 for IPv4/IPv6 routing in Service Provider Network 1 in
accordance with the provided routing protocols diagram, for every router embed IPv4 loopback address
into the IS-IS NET address. Any static route is NOT allowed to to accommodate IS-IS Level 1 routing. All
routers should not attempt to establish any neighbourship over loopback interfaces.

Task 2 (3 points). Ensure IS-IS neighbourship can get established over the links as fast as possible and
the protocol can detect link failure events less than 1 second. Taking a further step, IS-IS should pre-
build free loop alternate paths to achieve sub-second re-convergence. Also ensure IS-IS reflect the exact
bandwidth capacity of the links; and that routing information propagated is authenticated with MD5
hashing. Please use the most efficient configuration method to enable the features.

Task 3 (4 points). Configure the following IS-IS features:

• Allow IS-IS path metric to scale over the value of 1023.

• Ensure that every IS-IS router boots up and runs normally for at least 30 minutes before it can
pass any transit traffic.
• The Service Provider traditionally used IS-IS overload bit in the procedure that takes routers out
of services. Change that procedure in a way that overload bit is not set but the router being
worked on will still be the last-resort device for traffic. Ensure that L1-L2 routing will still work
across the device.
• The Service Provider strictly controls MTU value across its core links, ensure that after
initialisation of IS-IS adjacency, IIH messages produced by IS-IS routers do not negatively strain
routers’ buffers.
• Maximally reduce the amount of control traffic generated by IS-IS.
• Create separate topologies for IPv4 and IPv6 routing information.

At the end of this topic, all routers should have full IPv4 and IPv6 reachability with each other’s
loopback0 networks.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
51
52 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 3: MPLS
Total Points: 14

Task 1 (2 points). Configure IS-IS to build TE database for the Service Provider Network; ensure the
tailend router is the one who removes MPLS stack instead of the penultimate router.

Task 2 (10 points). Configure two tiers of RSVP-signaled LSPs between routers of the Service Provider
Network with the following characteristics.

• Tier-1 LSP: full-mesh between R3, R4, R5, R6.

• Tier-2 LSP group 1: full-mesh between R1, R2, R3, R4.
• Tier-2 LSP group 2: full-mesh between R5, R6, R7, R8.
• All tier-1 LSPs should have setup/holding priorities of 5 while the value for priorities of tier-2
LSPs are 6. There could be other LSPs with higher priorities being configured in upcoming
projects so please ensure that when a LSP is to be moved due to pre-emption, the system gives
it at least 30sec to find an alternative path before tearing it down.
• All LSPs’ bandwidth usage should be monitored and adjusted for better path every 1 hour and
ensure that the newly optimised path is established before old path is torn down for
reoptimisation activities.
o Bandwidth range is from 100Kbps to 10Gbps.
o Only update bandwidth usage only if the new figure is higher than the old one by 20%.
o Trigger an early bandwidth update if there are more than 2 consecutive overflow
samples.
o Trigger an early bandwidth update if there are more than 2 consecutive underflow
samples.
o Statistics of bandwidth usage should be recorded every 10 minutes into files called
autobw.log for diagnostic purpose. The biggest file size should be 1MB and the routers
should store up to 10 files. Please do not record statistics of transit LSPs.
• All LSPs should be re-routed within tens of milliseconds upon failure of any node within the core
network.
• Bidirectional forwarding capability of each LSP should be verified and signalled within 1 second.
• When equal cost paths exist, all LSPs should randomly select the best one to follow.
• Please use the most efficient configuration method to group common attributes of LSPs. JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5
• Ensure that all MPLS-based services such as L3VPN, L2VPN, 6PE can function across the two tiers
of LSP.

Task 3 (2 points). Configure the following MPLS features for the Service Provider Network:

• All routers can handle jumbo Ethernet frames as well as variable packets of MPLS L3/L2 VPN,
MPLS TE and FRR services without fragmentation.
• The Service Provider Network can support CSC services with Fast Reroute, the customer carrier
can run LDP with the provider carrier running RSVP.
• Also allow for customers or peers to see MPLS hops of Service Provider Networks 1 and 2 when
performing ICMP ping and traceroute; Enable RSVP to signal MTU value along the path of all
LSPs. In order to facilitate diagnostics and detecting loops, each LSP should actively record its
routes.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
52
53 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 4: BGP
Total Points: 21

Task 1 (6 points). Configure BGP confederation for the Service Provider Network with the following
characteristics:

Local Peer Router ASN of Peer Router IPv4 of Peer Router IPv6 of Peer Router
Router
R1 C1 65001 150.1.119.2 2016:150:1:119::2
P1 100 150.1.100.2 2016:150:1:100::2
T1 111 111.1.120.2 2016:111:1:120::2
R2 P1 100 150.1.113.2 2016:150:1:113::2
P2 200 150.1.101.2 2016:150:1::101::2
T2 222 222.1.123.2 2016:222:1:123::2
R5 P2 200 150.1.137.2 2016:150:1:137::2
C2 65002 150.1.102.2 2016:150:1:102::2
R6 C4 65004 150.1.107.2 ::ffff:150.1.107.2
T1 111 111.1.105.2 2016:111:1:105::2
R7 T2 222 222.1.106.2 2016:111:1:106::2

You can launch ping tests from any C/T/P routing-instance on VRF device with some test IPv4/IPv6 JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5
addresses below.

• C1: 170.1.210.1, 2016:170:1:210::1

• C2: 170.1.220.1, 2016:170:1:220::1
• C4: 170.1.240.1, 2016:170:1:240::1
• P1: 100.0.0.1, 2016:100::1
• P2: 200.0.0.1, 2016:200::1
• T1: 111.0.0.1, 2016:111::1, 12.0.0.1, 2016:12::1
• T2: 222.0.0.1, 2016:222::1, 12.0.0.2, 2016:12::2
• T3 (behind T1, T2): 123.0.0.1, 2016:123::1

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
53
54 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

the near future, please allow for such systems to define flows and update the network with community
57920:6661. For testing BGP Flowspec, locally define two flows on R3 with the following characteristics.
Ensure they are blocked on an AS-wide basis as expected. Limit the maximum number of flows to be
5,000 and a warning will trigger once 80% of that limit is reached.

• Flow 1:
o Source: 123.0.0.1/32
o Destination: 150.1.1.30/32
o Protocol: ICMP
• Flow 2:
o Source: 123.0.1.1/32
o Destination: 150.1.1.60/32
o Protocol: ICMP

Task 4 (4 points). Create a BGP community system on the PE routers R1 and R2 such that it will allow P1
to automatically signal the preferred inbound PE-CE link for traffic from AS 1.57920 destined to AS 100.
The peer P1 does not need to contact AS 1.57920 anytime they want to change the inbound preference.
The less-preferred PE-CE link should still be used as the backup path. P1 has already tagged its prefixes
with certain BGP community values. Optimise the routing domain inside the Service Provider Network
such that the switchover to the backup link is faster than regular iBGP convergence.

Task 5 (3 points). C4 should not have full Internet routing table, instead it should only have specific
routes whose AS_PATH length should not be longer than 2. For the remaining of Internet destinations, a
default route on R6 should be advertised to C4 on condition that R6 has got an active route towards
prefix 123.0.0.0/24 in its inet.0 table.

Task 6 (2 points). Announce the IPv4/IPv6 supernets of Service Provider Network 1 on R3 and R4 (2
static routes are allowed on each router).

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
54
55 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 5: VPN
Total Points: 38

Task 1 (6 points). Provide MPLS L3VPN service for VPN1 customer (AS 65501), including site CE1-1 as
hub and sites CE1-2, CE1-3 as spokes. All CE routers run BGP with Service Provider Network. Ensure that
traffic from CE1-2 to CE1-3 traverses CE1-1 and vice versa. You can launch ping tests from any
participating CE routing-instance on VRF device with some test IPv4 addresses below. You are NOT
allowed to use any static route for this task. Ensure that there is no routing loop for CE1-1 which multi-
homes to the PE routers R1 and R3. More over, contain the loop tolerance to only L3VPN prefixes.

• CE1-1: 172.30.1[0-9].1
• CE1-2: 172.30.2[0-9].1
• CE1-3: 172.30.3[0-9].1

Task 2 (3 points). Create a BGP community system on the PE routers R1 and R3 such that it will allow
CE1-1 to automatically signal the Service Provider Network the preferred inbound PE-CE link for traffic
from spoke sites CE1-2 and CE1-3 towards certain prefixes advertised by hub site CE1-1. Customer VPN1
does not need to contact the Service Provider Network anytime they want to change the inbound
preference. CE1-1 has already signalled preferred link for its prefixes. Additionally once the load-
balancing scheme between PE routers R1 and R3 is defined, for example hub prefix 172.30.10.0/24 is
preferred via link between R1 and CE1-1 (signalled by CE1-1), the link between R3 and CE1-1 can still be
used as the backup path.

Task 4 (6 points). Provide MPLS L3VPN service for VPN3 customer, including sites CE3-1 and CE3-2 using
OSPF as routing protocol. You can launch ping tests from any participating CE routing-instance on VRF
device with some test IPv4 addresses below. Additionally VPN routes of VPN1 and VPN3 customers must
be locally shared across. Ensure that this sharing scheme is not automatically propagated to other sites
of both VPN1 and VPN3. JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5

• CE3-1: 172.30.70.1
• CE3-2: 172.30.80.1
• CE3-3: 172.30.170.1

Task 5 (6 points). Provide VPLS service for VPN2 customer, including sites CE2-2, CE2-5 using BGP as the
signalling protocol, and site CE2-4 using LDP as the signalling protocol. CE2-2 is dual-homed to R6 and R8
but ensure that R6 is the primary connection. You can launch ping tests from any participating CE
routing-instance on VRF device with some test IPv4 addresses below.

• CE2-2: 172.30.40.2
• CE2-4: 172.30.40.4
• CE2-5: 172.30.40.5

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
55
56 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Task 6 (6 points). Provide point-to-point MPLS L2VPN service for VPN5 customer, including sites CE5-1
and CE5-2 using BGP as the signalling protocol. You can launch ping tests from any participating CE
routing-instance on VRF device with some test IPv4 addresses CE5-1: 172.30.160.51 and CE5-2:
172.30.160.52. Configure R1 and R5 to achieve the following output.
lab@VMX-VR> ping rapid routing-instance CE5-1 source 172.30.160.51 172.30.160.52 size
1401 do-not-fragment
PING 172.30.160.52 (172.30.160.52): 1401 data bytes
!!!!!
--- 172.30.160.52 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 138.005/152.876/203.459/25.337 ms

lab@VMX-VR> ping rapid routing-instance CE5-1 source 172.30.160.51 172.30.160.52 size

1402 do-not-fragment
PING 172.30.160.52 (172.30.160.52): 1402 data bytes
.....
--- 172.30.160.52 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

Bonus/homework question (not required): In the opposite way, think about a solution where CE5-1 and
CE5-2 need to send packets with per-packet size of 1501 bytes without any fragmentation.

Task 7 (6 points). Improve the scalability for L3VPN services and optimise routers’ resouces such that:

• All PE routers should only receive VPN prefixes that they need.
• All PE routers should store L3VPN routes at necessary PFE linecards only.
• Limit L3VPN routes of customer VPN1 to 5000 routes only; a warning message should be issued
when 80% of that threshold is reached.
• Limit broadcast, unknown-unicast, multicast traffic of customer VPN2 to protect the VPLS core
network from floods or denial of services attacks.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
56
57 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 6: Multicast
Total Points: 6

Task 1 (3 points). Implement multicast routing in the Service Provider Network with the following
characteristics:

• Configure BSR to disseminate rendezvous point (RP) information with R4 and R6 being BSR/RP
candidates for IPv4 multicast with priorities in that order respectively, using loopback interfaces
as update-sources.
• RP information should not leak across AS boundaries with transit or peering.
• R4, R6 are Anycast RPs with address 150.1.1.250. Ensure the redundancy of the RPs through
MSDP.
• Strictly control multicast traffic over the core network of the Service Provider such that there
should be only internal group 239.0.0.0/24 that can deliver traffic. You are allowed to add any
multicast group that is necessary for the basic multicast function of the Service Provider
Network.

Task 2 (3 points). Implement Draft-Rosen MVPN for customer VPN3 with the following characteristics:

• Multicast sources stand behind CE3-1 and multicast receivers locate at site CE3-2 and CE3-3. The
receivers are preconfigured with IGMP static join to multicast groups 239.1.1.31 and 239.1.1.32.
• Customer VPN3 uses with CE3-1 functioning as RP candidate and mapping agent at the same
time for multicast group range of 239.1.1.0/24.
• Customer VPN3 is assigned with group 239.0.0.3 for the Default MDT tunnel. Set the threshold
for Data MDT tunnels to be spun up for groups 239.1.1.31 and 239.1.1.32 from any source once
traffic rate of either of them is equal of higher than 50Mbps.
• Ensure that there is no more than 10 Data MDT tunnels created for customer VPN3.
• You are allowed to configure additional IP addresses on R1, R2, R6 if needed.

End of Practice Lab 5!

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
57
58 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Practice Lab 1 Solutions

Topic 1: Device Infrastructure

Total Points: 15

Task 1 (1 point). Annotate the configuration of all routers from R1 to R8 with a comment above the
‘system’ configuration stanza, specifying your full name and current date.
R1,R2,R3,R4,R5,R6,R7,R8
!
annotate system "Config made by Tony Tuan Nguyen, 2017-01-16"

Task 2 (2 points). Configure LAG interface ae0 on each of routers R1, R2, R3, R4, R5 and R6 such that it
consists of ports ge-0/0/1 and ge-0/0/2, ensure that each LAG stays up only if all member interfaces in
the LAG are up, and all routers proactively monitor status of member links.
R1,R2,R3,R4,R5,R6
!
set interfaces ge-0/0/1 apply-groups-except ALL-INTERFACES
set interfaces ge-0/0/1 gigether-options 802.3ad ae0
set interfaces ge-0/0/2 apply-groups-except ALL-INTERFACES
set interfaces ge-0/0/2 gigether-options 802.3ad ae0
set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 aggregated-ether-options minimum-links 2

Task 3 (2 points). Configure protocol LLDP on all interfaces except interface ge-0/0/0 of all routers from
R1 to R8, ensure Port ID TLV is generated from the name of interface instead of SNMP index by default.
R1,R2,R3,R4,R5,R6,R7,R8
!
set protocols lldp interface all
set protocols lldp interface ge-0/0/0 disable
set protocols lldp port-id-subtype interface-name

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

to be updated any time a new BGP peer is added. Count the discarded packets with a counter named
DISCARDED-CP-PACKETS.
R1
!
edit firewall filter COPP
set term TELNET-SSH from protocol tcp
set term TELNET-SSH from destination-port [telnet ssh]
set term TELNET-SSH from source-address 10.10.1.0/24
set term TELNET-SSH from source-address 10.233.0.0/16
set term TELNET-SSH then accept
set term FTP from protocol tcp
set term FTP from port [ftp ftp-data]
set term FTP from source-address 10.10.1.0/24
set term FTP from source-address 10.233.0.0/16
set term FTP then accept
set term SNMP from protocol udp
set term SNMP from destination-port snmp
set term SNMP from source-address 10.10.1.0/24
set term SNMP from source-address 10.233.0.0/16
set term SNMP then accept
set term SYSLOG from protocol [tcp udp]
set term SYSLOG from port syslog
set term SYSLOG from source-address 10.10.1.0/24
set term SYSLOG from source-address 10.233.0.0/16
set term SYSLOG then accept

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
58
59 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set term RADIUS from protocol tcp

set term RADIUS from source-port radius
set term RADIUS from source-address 10.10.1.0/24
set term RADIUS from source-address 10.233.0.0/16
set term RADIUS then accept
set term NTP from protocol udp
set term NTP from port ntp
set term NTP from source-address 10.10.1.0/24
set term NTP then accept
set term PING from protocol icmp
set term PING from icmp-type [echo-request echo-reply]
set term PING then police 1M
set term PING then accept
set term TRACEROUTE-REQ from protocol udp
set term TRACEROUTE-REQ from port 33434-33534
set term TRACEROUTE-REQ then police 1M
set term TRACEROUTE-REQ then accept
set term TRACEROUTE-RESP from protocol icmp
set term TRACEROUTE-RESP from icmp-type [time-exceed unreachable]
set term TRACEROUTE-RESP then police 1M
set term TRACEROUTE-RESP then accept
set term OSPF from protocol ospf
set term OSPF then accept
set term RSVP from protocol rsvp
set term RSVP then accept
set term BGP from protocol tcp
set term BGP from port bgp
set term BGP from source-prefix-list BGP-NEIGHBOURS
set term BGP then accept
set term BFD from protocol [tcp udp]
set term BFD from port [3784 4784]
set term MPLS-OAM from protocol udp
set term MPLS-OAM from port 3503
set term MPLS-OAM then accept
set term DENY-ALL then count DISCARDED-CP-PACKETS
set term DENY-ALL then discard
exit
edit firewall policer 1M
set if-exceeding bandwidth-limit 1m burst 64k
set then discard
exit
edit policy-options prefix-list BGP-NEIGHBOURS
set apply-path "protocols bgp group <*> neighbor <*>"
exit
set interfaces lo0.0 family inet filter input COPP

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

simplicity, the assumption is that this Service Provider Networks 1 and 2 use MX-series routers with only
DPC linecards. Ensure that the nexthop structure is a function of both hashing scheme and low-order
bits of IP address.
R1,R2,R3,R4,R5,R6,R7,R8
!
edit forwarding-options
set hash-key family inet layer-3
set hash-key family inet layer-4
set hash-key family mpls label-1
set hash-key family mpls label-2
set hash-key family mpls label-3
set hash-key family mpls payload ether-pseudowire
set hash-key family mpls payload ip port-data
set load-balance indexed-load-balance
exit
set policy-options policy-statement ECMP term ECMP then load-balance per-packet
set routing-options forwarding-table export ECMP

Task 6 (2 points). Configure all routers so that the Service Provider Networks 1 and 2 can handle jumbo
Ethernet frames as well as variable packets of MPLS L3/L2 VPN, MPLS TE and FRR services without
fragmentation.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
59
60 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

R1,R2
!
set interfaces ae0 mtu 9000
set interfaces ge-0/0/6 mtu 9000

R3,R4
!
set interfaces ae0 mtu 9000
set interfaces ge-0/0/6 mtu 9000
set interfaces ge-0/0/7 mtu 9000

R5,R6
!
set interfaces ae0 mtu 9000
set interfaces ge-0/0/7 mtu 9000

R7,R8
!
set interfaces ge-0/0/6 mtu 9000

Verification
Task 1. System configuration should be annotated as below. Perform the same command on all routers
R1->R8 to ensure annotation is put in all routers’ configuration.
lab@VMX-R1> show configuration | find "Config made"
/* Config made by Tony Tuan Nguyen, 2017-01-16 */
system {
<snip-for-brevity>
}

Task 2. LACP port bundling should come up as below, i.e. both ports show ‘distributing’ state and
‘Active’ participation. Perform the same command on all routers R1->R6 to check LACP operations
across all LAGs.
lab@VMX-R1> show lacp interfaces
Aggregated interface: ae0
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
ge-0/0/1 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/1 Partner No No Yes Yes Yes Yes Fast Active
ge-0/0/2 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/2 Partner No No Yes Yes Yes Yes Fast Active
LACP protocol: Receive State Transmit State Mux State
ge-0/0/1 Current Fast periodic Collecting distributing

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

ge-0/0/2 Current Fast periodic Collecting distributing

lab@VMX-R3> show lacp interfaces

Aggregated interface: ae0
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
ge-0/0/1 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/1 Partner No No Yes Yes Yes Yes Fast Active
ge-0/0/2 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/2 Partner No No Yes Yes Yes Yes Fast Active
LACP protocol: Receive State Transmit State Mux State
ge-0/0/1 Current Fast periodic Collecting distributing
ge-0/0/2 Current Fast periodic Collecting distributing

lab@VMX-R5> show lacp interfaces

Task 3. LLDP neighbourship should be formed across the interfaces as below. Perform the same
command on all routers R1->R6 to check LLDP operations.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
60
61 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

lab@VMX-R2> show lldp neighbors

Local Interface Parent Interface Chassis Id Port info System Name
ge-0/0/1 ae0 00:05:86:71:50:c0 ge-0/0/1 VMX-R1
ge-0/0/2 ae0 00:05:86:71:50:c0 ge-0/0/2 VMX-R1
ge-0/0/4 - 00:05:86:71:50:c0 ge-0/0/4 VMX-R1
ge-0/0/4 - 00:05:86:71:71:c0 ge-0/0/4 VMX-R4
ge-0/0/6 - 00:05:86:71:71:c0 ge-0/0/6 VMX-R4
ge-0/0/4 - 00:05:86:71:c8:c0 ge-0/0/4 VMX-R5
ge-0/0/4 - 00:05:86:71:e7:c0 ge-0/0/4 VMX-R7
ge-0/0/4 - 00:05:86:71:ec:c0 ge-0/0/4 VMX-R8
ge-0/0/4 - 00:05:86:71:f1:c0 ge-0/0/4 VMX-R6

lab@VMX-R4> show lldp neighbors

Local Interface Parent Interface Chassis Id Port info System Name
ge-0/0/4 - 00:05:86:71:50:c0 ge-0/0/4 VMX-R1
ge-0/0/4 - 00:05:86:71:c8:c0 ge-0/0/4 VMX-R5
ge-0/0/4 - 00:05:86:71:db:c0 ge-0/0/4 VMX-R2
ge-0/0/6 - 00:05:86:71:db:c0 ge-0/0/6 VMX-R2
ge-0/0/4 - 00:05:86:71:e7:c0 ge-0/0/4 VMX-R7
ge-0/0/4 - 00:05:86:71:ec:c0 ge-0/0/4 VMX-R8
ge-0/0/1 ae0 00:05:86:71:f1:c0 ge-0/0/1 VMX-R3
ge-0/0/2 ae0 00:05:86:71:f1:c0 ge-0/0/2 VMX-R3
ge-0/0/4 - 00:05:86:71:f1:c0 ge-0/0/4 VMX-R6
ge-0/0/7 - 00:05:86:71:f1:c0 ge-0/0/7 VMX-R6

lab@VMX-R6> show lldp neighbors

Local Interface Parent Interface Chassis Id Port info System Name
ge-0/0/4 - 00:05:86:71:50:c0 ge-0/0/4 VMX-R1
ge-0/0/4 - 00:05:86:71:71:c0 ge-0/0/4 VMX-R4
ge-0/0/7 - 00:05:86:71:71:c0 ge-0/0/7 VMX-R4
ge-0/0/1 ae0 00:05:86:71:c8:c0 ge-0/0/1 VMX-R5
ge-0/0/2 ae0 00:05:86:71:c8:c0 ge-0/0/2 VMX-R5
ge-0/0/4 - 00:05:86:71:c8:c0 ge-0/0/4 VMX-R5
ge-0/0/4 - 00:05:86:71:db:c0 ge-0/0/4 VMX-R2
ge-0/0/4 - 00:05:86:71:e7:c0 ge-0/0/4 VMX-R7
ge-0/0/4 - 00:05:86:71:ec:c0 ge-0/0/4 VMX-R8
ge-0/0/6 - 00:05:86:71:ec:c0 ge-0/0/6 VMX-R8
ge-0/0/4 - 00:05:86:71:f1:c0 ge-0/0/4 VMX-R3

Task 4. COPP ACL stands for control-plane access-list that should be installed into interface loopback 0 in
the inbound direction. We can generate some test ping/traceroute or telnet/ssh traffic to test the ACL
but it also could be indirectly verified in the upcoming tasks where routing protocols’ neighbourship
from R1 should come up properly.
lab@VMX-R1> show firewall filter COPP

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

Filter: COPP
Counters:
Name Bytes Packets
DISCARDED-CP-PACKETS 5040 84
Policers:
Name Bytes Packets
1M-PING 0
1M-TRACEROUTE-REQ 0
1M-TRACEROUTE-RESP 0

lab@VMX-R1> show interfaces filters lo0

Interface Admin Link Proto Input Filter Output Filter
lo0 up up
lo0.0 up up inet COPP
iso
inet6
lo0.16384 up up inet
lo0.16385 up up inet
lo0.32768 up up

lab@VMX-R2> ping rapid 150.1.12.1

PING 150.1.12.1 (150.1.12.1): 56 data bytes
!!!!!
--- 150.1.12.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 9.281/9.821/10.147/0.292 ms

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
61
62 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

lab@VMX-R2> traceroute 150.1.12.1

traceroute to 150.1.12.1 (150.1.12.1), 30 hops max, 40 byte packets
1 150.1.12.1 (150.1.12.1) 14.100 ms 12.739 ms 14.933 ms

lab@VMX-R2> ssh [email protected]

ssh: connect to host 150.1.12.1 port 22: Operation timed out

lab@VMX-R2> telnet 150.1.12.1

Trying 150.1.12.1...
telnet: connect to address 150.1.12.1: Operation timed out
telnet: Unable to connect to remote host

lab@VMX-R1> show firewall filter COPP

Filter: COPP
Counters:
Name Bytes Packets
DISCARDED-CP-PACKETS 6000 102
Policers:
Name Bytes Packets
1M-PING 0
1M-TRACEROUTE-REQ 0
1M-TRACEROUTE-RESP 0

This task also challenges candidate for predicting the protocols needed in future tasks, the answer here
includes OSPF, RSVP, BGP, BFD, MPLS-OAM. If you are not sure whether you have specified all needed
protocols or not, just do not configure the last term (DENY-ALL) and leave it till the end until everything
is clear. BFD protocol by default uses only UDP port 3784 between directly connected routers, however
it will use TCP port 4784 for multihop sessions, particularly for application such as BFD-triggered MPLS
LSPs. MPLS OAM is a feature that employs UDP port 3503 for control channel between MPLS routers
which is used for activities such as ping mpls rsvp.

Task 5. JUNOS uses hashing and load-balancing mechanisms to share packets over equal-cost paths or
member interfaces of a LAG. By default only source and destination addresses are taken into account for
the calculation of a hash value which determines the outgoing ports. To check the factors being used by
JUNOS hashing mechanism, we can use command request pfe execute command "show jnh lb" target
tfeb0 (MX80 platform). For other MX platforms, the command is slightly different (due to modular
forwarding architecture as opposed to the built-in packet forwarding engine of MX80) request pfe
execute command "show jnh lb" target fpc0. Below is sample output of the shell command on MX80

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

platform.
request pfe execute command "show jnh lb" target tfeb0
SENT: Ukern command: show jnh lb
GOT:
GOT: Unilist Seed Configured 0x8bce4c39 System Mac address 00:00:00:00:00:00
GOT: Hash Key Configuration: 0x0000000000ecffff 0xffffffffffffffff
GOT: IIF-V4: Yes
GOT: SPORT-V4: Yes
GOT: DPORT-V4: Yes
GOT: TOS: Yes
GOT:
GOT: IIF-V6: Yes
GOT: SPORT-V6: Yes
GOT: DPORT-V6: Yes
GOT: TRAFFIC_CLASS: Yes
GOT:
GOT: IIF-MPLS: No
GOT: MPLS_PAYLOAD: Yes
GOT: MPLS_EXP: No
GOT:
GOT: IIF-BRIDGED: No
GOT: MAC ADDRESSES: Yes
GOT: ETHER_PAYLOAD: Yes
GOT: 802.1P OUTER: No
GOT:

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
62
63 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

GOT: Services Hash Key Configuration:

GOT: SADDR-V4: No
GOT: IIF-V4: No
GOT:
LOCAL: End of file

On Junos vMX platform, unfortunately the command above is not available on the CLI, and instead you
will need to access the actual PFE to execute it:
lab@VMX-R1> start shell user root
Password:
root@VMX-R1% vty fpc0

BSD platform (Pentium processor, 512MB memory, 0KB flash)

VMX(VMX-R1 vty)# show jnh lb

Unilist Seed Configured 0x00000000 System Mac address 00:00:00:00:00:00
Hash Key Configuration: 0x0000000100e00000 0xffffffffffffffff
IIF-V4: No
SPORT-V4: Yes
DPORT-V4: Yes
TOS: No
GTP-TEID-V4: No

IIF-V6: No
SPORT-V6: Yes
DPORT-V6: Yes
TRAFFIC_CLASS: No
GTP-TEID-V6: No

IIF-MPLS: No
MPLS_PAYLOAD: Yes
ETHER_PW: Yes
MPLS_EXP: No

IIF-BRIDGED: No
MAC ADDRESSES: Yes
ETHER_PAYLOAD: Yes
802.1P OUTER: No

Services Hash Key Configuration:

SADDR-V4: No
DADDR-V4: No
IIF-V4: No

SADDR-V6: No
DADDR-V6: No

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

IIF-V6: No
SRC-PREFIX-LEN: 127

On Juniper MX platforms, DPC linecards’ factors can be tweaked under the forwarding-options hash-key
stanza while newer MPC linecards add extra factors under forwarding-options enhanced-hash-key
stanza. Some reference URLs are below:

https://www.juniper.net/documentation/en_US/junos12.3/topics/reference/configuration-
statement/hash-key-edit-forwarding-options.html

http://www.juniper.net/documentation/en_US/junos12.3/topics/reference/configuration-
statement/enhanced-hash-key-edit-forwarding-options.html

Verification of equal-cost paths being available on the data plane will be carried out in the IGP topic
where we would have a route towards a destination using multiple IGP paths.

The indexed-load-balance statement causes the creation of a next-hop structure that is not a function of
the hash mechanism and the low-order bits of the IP address.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
63
64 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Task 6. By default an Ethernet frame would have an MTU value of 1500 bytes for the payload. A jumbo
Ethernet frame can increase MTU up to 9000 bytes to allow a significant amount of data transferred
with less resources utilised as the number of frames needed to process the same chunk of data is
effectively reduced. Best practices indicate that MTU value must be matched on both sides of an
Ethernet link, otherwise there would be issues such as flapping protocol neighbourship, overflow
buffering on the side that has got smaller MTU value or even OSPF would not come up at all.
lab@VMX-R1> show interfaces ae0 | match MTU
Link-level type: Ethernet, MTU: 2000, Speed: 2Gbps, BPDU Error: None, MAC-REWRITE
Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Disabled
Protocol inet, MTU: 1986
Protocol iso, MTU: 1983
Protocol inet6, MTU: 1986
Protocol multiservice, MTU: Unlimited

lab@VMX-R1> show interfaces ge-0/0/6 | match MTU

Link-level type: Ethernet, MTU: 2000, MRU: 2008, Speed: 1000mbps, BPDU Error: None,
MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control:
Enabled
Protocol inet, MTU: 1986
Protocol iso, MTU: 1983
Protocol inet6, MTU: 1986
Protocol multiservice, MTU: Unlimited

This task can be indirectly verified in the upcoming ones where we should not see OSPF neighbourships
get stuck in EXSTART phase which is normally due to MTU mismatch.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
64
65 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 2: IGP
Total Points: 20

Task 1 (4 points). Configure OSPFv2 area 0.0.0.0 for IPv4 routing and IS-IS Level 2 area 49.0016 for IPv6
routing of Service Provider Network 1 which consists of routers R1, R2, R3, R4, R5 and R6.
/* Answer for task 1 is merged with task 2’s */

R1
!
set interface lo0.0 family iso address 49.0016.0000.0000.0001.00

R2
!
set interface lo0.0 family iso address 49.0016.0000.0000.0002.00

R3
!
set interface lo0.0 family iso address 49.0016.0000.0000.0003.00

R4
!
set interface lo0.0 family iso address 49.0016.0000.0000.0004.00

R5
!
set interface lo0.0 family iso address 49.0016.0000.0000.0005.00

R6
!
set interface lo0.0 family iso address 49.0016.0000.0000.0006.00
R1,R2
!
edit protocols ospf area 0.0.0.0
set interface lo0.0 passive
set interface ae0.0 interface-type p2p bfd minimum-interval 250 multiplier 4
set interface ge-0/0/6 interface-type p2p bfd minimum-interval 250 multiplier 4

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

exit
edit protocols isis
set level 1 disable
set no-ipv4-routing
set interface lo0.0 passive
set interface ae0.0 point-to-point
set interface ge-0/0/6 point-to-point
exit

R3,R4
!
edit protocols ospf area 0.0.0.0
set interface lo0.0 passive
set interface ae0.0 interface-type p2p bfd minimum-interval 250 multiplier 4
set interface ge-0/0/6 interface-type p2p bfd minimum-interval 250 multiplier 4
set interface ge-0/0/7 interface-type p2p bfd minimum-interval 250 multiplier 4
exit
edit protocols isis
set level 1 disable
set no-ipv4-routing
set interface lo0.0 passive
set interface ae0.0 point-to-point
set interface ge-0/0/6 point-to-point
set interface ge-0/0/7 point-to-point
exit

R5,R6

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
65
66 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

!
edit protocols ospf area 0.0.0.0
set interface lo0.0 passive
set interface ae0.0 interface-type p2p bfd minimum-interval 250 multiplier 4
set interface ge-0/0/7 interface-type p2p bfd minimum-interval 250 multiplier 4
exit
edit protocols isis
set level 1 disable
set no-ipv4-routing
set interface lo0.0 passive
set interface ae0.0 point-to-point
set interface ge-0/0/7 point-to-point
exit

Task 3 (4 points). Ensure OSPF and IS-IS reflect the exact bandwidth capacity of the links; ensure that
routing information propagated is authenticated with MD5 hashing at interface level.
R1,R2,R3,R4,R5,R6
!
set protocols ospf reference-bandwidth 100g
set protocols isis reference-bandwidth 100g

R1,R2
!
edit protocols ospf area 0.0.0.0
set interface ae0.0 authentication md5 1 key JNCIE
set interface ge-0/0/6 authentication md5 1 key JNCIE
exit
edit protocols isis
set interface ae0.0 hello-authentication-type md5 hello-authentication-key JNCIE
set interface ge-0/0/6 hello-authentication-type md5 hello-authentication-key JNCIE
set level 2 authentication-type md5 authentication-key JNCIE-SP
exit

R3,R4
!
edit protocols ospf area 0.0.0.0
set interface ae0.0 authentication md5 1 key JNCIE
set interface ge-0/0/6 authentication md5 1 key JNCIE
set interface ge-0/0/7 authentication md5 1 key JNCIE
exit
edit protocols isis
set interface ae0.0 hello-authentication-type md5 hello-authentication-key JNCIE
set interface ge-0/0/6 hello-authentication-type md5 hello-authentication-key JNCIE
set interface ge-0/0/7 hello-authentication-type md5 hello-authentication-key JNCIE
set level 2 authentication-type md5 authentication-key JNCIE-SP
exit

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

R5,R6
!
edit protocols ospf area 0.0.0.0
set interface ae0.0 authentication md5 1 key JNCIE
set interface ge-0/0/7 authentication md5 1 key JNCIE
exit
edit protocols isis
set interface ae0.0 hello-authentication-type md5 hello-authentication-key JNCIE
set interface ge-0/0/7 hello-authentication-type md5 hello-authentication-key JNCIE
set level 2 authentication-type md5 authentication-key JNCIE-SP
exit

Task 4 (6 points). Configure OSPFv3 area 0.0.0.0 for IPv4/IPv6 routing between Service Provider Network
1 and DC1; advertise an IPv4 supernet prefix representing Service Provider Network 1 as well as an IPv4
default route into DC1; mutually redistribute IPv6 prefixes between OSPFv3 and IS-IS and ensure that
IPv4 traffic from DC1 prefer R1’s link while IPv6 traffic from DC1 prefer R3’s link. In the failure case of
either R1 or R3, the remaining router should take responsibility for both IPv4 and IPv6 from DC1. There
should be no routing loop or suboptimal routing path. Note: you are allowed to use one static route on
R1 and R3 temporarily if topic BGP is not completed yet.
R1
!

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
66
67 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

edit protocols ospf3

set area 0.0.0.0 interface ge-0/0/4.116
set export ISIS-TO-OSPF3
set import OSPF3-IMPORT
exit
edit protocols ospf3 realm ipv4-unicast
set area 0.0.0.0 interface ge-0/0/4.116
set export AGGREGATE-TO-OSPF3
set import OSPF3-IMPORT
exit
edit protocols ospf
set export OSPF3-TO-OSPF2
set import OSPF2-IMPORT
exit
edit protocols isis
set export OSPF3-TO-ISIS
exit
edit policy-options policy-statement ISIS-TO-OSPF3
set term 1 from protocol isis
set term 1 then tag 13
set term 1 then metric 100
set term 1 then accept
set term 2 from protocol direct
set term 2 from route-filter 2016:150:1:1::1/128 exact
set term 2 from route-filter 2016:150:1:12::/64 exact
set term 2 from route-filter 2016:150:1:13::/64 exact
set term 2 then tag 13
set term 2 then metric 100
set term 2 then accept
exit
edit policy-options policy-statement OSPF3-TO-ISIS
set term 1 from protocol ospf3
set term 1 then tag 13
set term 1 then metric 100
set term 1 then accept
exit
edit policy-options policy-statement OSPF3-IMPORT
set term 1 from protocol ospf3
set term 1 from tag 13
set term 1 then reject
exit
edit policy-options policy-statement AGGREGATE-TO-OSPF3
set term 1 from protocol aggregate
set term 1 from route-filter 150.1.0.0/16 exact
set term 1 then tag 13
set term 1 then metric 10
set term 1 then accept
set term 2 from protocol static
set term 2 from route-filter 0.0.0.0/0 exact
set term 2 then tag 13

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

set term 2 then metric 10
set term 2 then accept
exit
edit policy-options policy-statement OSPF3-TO-OSPF2
set term 1 from protocol ospf3
set term 1 then tag 13
set term 1 then metric 10
set term 1 then accept
exit
edit policy-options policy-statement OSPF2-IMPORT
set term 1 from protocol ospf2
set term 1 from tag 13
set term 1 then reject
exit
set routing-options aggregate route 150.1.0.0/16
set routing-options static route 0.0.0.0/0 discard

R3
!
edit protocols ospf3
set area 0.0.0.0 interface ge-0/0/4.115
set export ISIS-TO-OSPF3
set import OSPF3-IMPORT
exit
edit protocols ospf3 realm ipv4-unicast
set area 0.0.0.0 interface ge-0/0/4.115
set export AGGREGATE-TO-OSPF3

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
67
68 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set import OSPF3-IMPORT

exit
edit protocols ospf
set export OSPF3-TO-OSPF2
set import OSPF2-IMPORT
exit
edit protocols isis
set export OSPF3-TO-ISIS
exit
edit policy-options policy-statement ISIS-TO-OSPF3
set term 1 from protocol isis
set term 1 then tag 13
set term 1 then metric 10
set term 1 then accept
set term 2 from protocol direct
set term 2 from route-filter 2016:150:1:1::3/128 exact
set term 2 from route-filter 2016:150:1:13::/64 exact
set term 2 from route-filter 2016:150:1:34::/64 exact
set term 2 from route-filter 2016:150:1:35::/64 exact
set term 2 then tag 13
set term 2 then metric 10
set term 2 then accept
exit
edit policy-options policy-statement OSPF3-TO-ISIS
set term 1 from protocol ospf3
set term 1 then tag 13
set term 1 then metric 10
set term 1 then accept
exit
edit policy-options policy-statement OSPF3-IMPORT
set term 1 from protocol ospf3
set term 1 from tag 13
set term 1 then reject
exit
edit policy-options policy-statement AGGREGATE-TO-OSPF3
set term 1 from protocol aggregate
set term 1 from route-filter 150.1.0.0/16 exact
set term 1 then tag 13
set term 1 then metric 100
set term 1 then accept
set term 2 from protocol static
set term 2 from route-filter 0.0.0.0/0 exact
set term 2 then tag 13
set term 2 then metric 100
set term 2 then accept
exit
edit policy-options policy-statement OSPF3-TO-OSPF2
set term 1 from protocol ospf3
set term 1 then tag 13
set term 1 then metric 100

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

set term 1 then accept
exit
edit policy-options policy-statement OSPF2-IMPORT
set term 1 from protocol ospf2
set term 1 from tag 13
set term 1 then reject
exit
set routing-options aggregate route 150.1.0.0/16
set routing-options static route 0.0.0.0/0 discard

Task 5 (2 points). Ensure that OSPF2 LSDB is protected such that there would be no more than 2000
external prefixes redistributed into OSPFv2. At the same time, ensure that every OSPFv2 router is up
and running normally for 30 minutes before it can pass any traffic. Record OSPF neighbour state changes
into a local file called ospf.log.
R1,R2,R3,R4,R5,R6
!
edit protocols ospf
set prefix-export-limit 2000
set overload timeout 1800
set traceoptions file ospf.log
set traceoptions flag state
exit

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
68
69 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Verification
Tasks 1 and 2. OSPFv2 and IS-IS neighbourship should come up within Service Provide Network 1,
verified with commands below.
lab@VMX-R1> show ospf neighbor
Address Interface State ID Pri Dead
150.1.12.2 ae0.0 Full 150.1.1.2 128 35
150.1.13.3 ge-0/0/6.0 Full 150.1.1.3 128 35

lab@VMX-R2> show ospf neighbor

Address Interface State ID Pri Dead
150.1.12.1 ae0.0 Full 150.1.1.1 128 38
150.1.24.4 ge-0/0/6.0 Full 150.1.1.4 128 33

lab@VMX-R3> show ospf neighbor

Address Interface State ID Pri Dead
150.1.34.4 ae0.0 Full 150.1.1.4 128 33
150.1.13.1 ge-0/0/6.0 Full 150.1.1.1 128 32
150.1.35.5 ge-0/0/7.0 Full 150.1.1.5 128 38

lab@VMX-R4> show ospf neighbor

Address Interface State ID Pri Dead
150.1.34.3 ae0.0 Full 150.1.1.3 128 36
150.1.24.2 ge-0/0/6.0 Full 150.1.1.2 128 33
150.1.46.6 ge-0/0/7.0 Full 150.1.1.6 128 35

lab@VMX-R5> show ospf neighbor

Address Interface State ID Pri Dead
150.1.56.6 ae0.0 Full 150.1.1.6 128 38
150.1.35.3 ge-0/0/7.0 Full 150.1.1.3 128 35

lab@VMX-R6> show ospf neighbor

Address Interface State ID Pri Dead
150.1.56.5 ae0.0 Full 150.1.1.5 128 37
150.1.46.4 ge-0/0/7.0 Full 150.1.1.4 128 33

lab@VMX-R1> show isis adjacency

Interface System L State Hold (secs) SNPA
ae0.0 R2 2 Up 25
ge-0/0/6.0 R3 2 Up 26

lab@VMX-R2> show isis adjacency

Interface System L State Hold (secs) SNPA
ae0.0 R1 2 Up 24
ge-0/0/6.0 R4 2 Up 26

lab@VMX-R3> show isis adjacency

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

Interface System L State Hold (secs) SNPA
ae0.0 R4 2 Up 20
ge-0/0/6.0 R1 2 Up 23
ge-0/0/7.0 R5 2 Up 25

lab@VMX-R4> show isis adjacency

Interface System L State Hold (secs) SNPA
ae0.0 R3 2 Up 25
ge-0/0/6.0 R2 2 Up 24
ge-0/0/7.0 R6 2 Up 23

lab@VMX-R5> show isis adjacency

Interface System L State Hold (secs) SNPA
ae0.0 R6 2 Up 23
ge-0/0/7.0 R3 2 Up 22

lab@VMX-R6> show isis adjacency

Interface System L State Hold (secs) SNPA
ae0.0 R5 2 Up 23
ge-0/0/7.0 R4 2 Up 21

Only OSPFv2 should show as BFD client. If IS-IS shows up, it means it is still routing for IPv4 stack and
hence violate the design of the lab that uses OSPFv2 for IPv4 routing and IS-IS for IPv6 routing.
lab@VMX-R3> show bfd session
Detect Transmit

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
69
70 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Address State Interface Time Interval Multiplier

150.1.13.1 Up ge-0/0/6.0 1.000 0.250 4
150.1.34.4 Up ae0.0 1.000 0.250 4
150.1.35.5 Up ge-0/0/7.0 1.000 0.250 4

3 sessions, 3 clients
Cumulative transmit rate 12.0 pps, cumulative receive rate 12.0 pps

lab@VMX-R3> show bfd session detail

Detect Transmit
Address State Interface Time Interval Multiplier
150.1.13.1 Up ge-0/0/6.0 1.000 0.250 4
Client OSPF realm ospf-v2 Area 0.0.0.0, TX interval 0.250, RX interval 0.250
Session up time 00:02:23
Local diagnostic None, remote diagnostic None
Remote state Up, version 1
Session type: Single hop BFD
Detect Transmit
Address State Interface Time Interval Multiplier
150.1.34.4 Up ae0.0 1.000 0.250 4
Client OSPF realm ospf-v2 Area 0.0.0.0, TX interval 0.250, RX interval 0.250
Session up time 00:02:24
Local diagnostic None, remote diagnostic None
Remote state Up, version 1
Session type: Single hop BFD
Detect Transmit
Address State Interface Time Interval Multiplier
150.1.35.5 Up ge-0/0/7.0 1.000 0.250 4
Client OSPF realm ospf-v2 Area 0.0.0.0, TX interval 0.250, RX interval 0.250
Session up time 00:02:24
Local diagnostic None, remote diagnostic None
Remote state Up, version 1
Session type: Single hop BFD

3 sessions, 3 clients
Cumulative transmit rate 12.0 pps, cumulative receive rate 12.0 pps

Even if we forcefully configure IS-IS with BFD here, the protocol would not show up as a BFD client. It is
because we already disabled IPv4 routing via statement no-ipv4-routing which in turn disables IPv4 BFD
client functionality for IS-IS. Note that JUNOS version 12.3 does not support IPv6 BFD client for routing
protocols and this capability is only introduced in version 14.2, reference URL is below.

https://www.juniper.net/documentation/en_US/junos14.2/topics/reference/configuration-
statement/bfd-liveness-detection-edit-protocols-isis.html

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

We also should check for routing information propagated by OSPF and IS-IS. All routers should have
routes towards IPv4 and IPv6 prefixes Service Provide Network 1, particularly loopback networks.
lab@VMX-R6> show route protocol ospf active-path
<snip>
inet.0: 28 destinations, 28 routes (28 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

150.1.1.1/32 *[OSPF/10] 00:25:09, metric 250

to 150.1.56.5 via ae0.0
> to 150.1.46.4 via ge-0/0/7.0
150.1.1.2/32 *[OSPF/10] 00:25:14, metric 200
> to 150.1.46.4 via ge-0/0/7.0
150.1.1.3/32 *[OSPF/10] 00:25:14, metric 150
to 150.1.56.5 via ae0.0
> to 150.1.46.4 via ge-0/0/7.0
150.1.1.4/32 *[OSPF/10] 00:25:16, metric 100
> to 150.1.46.4 via ge-0/0/7.0
150.1.1.5/32 *[OSPF/10] 00:25:16, metric 50
> to 150.1.56.5 via ae0.0
150.1.12.0/24 *[OSPF/10] 00:25:14, metric 250
> to 150.1.46.4 via ge-0/0/7.0
150.1.13.0/24 *[OSPF/10] 00:25:14, metric 250
to 150.1.56.5 via ae0.0
> to 150.1.46.4 via ge-0/0/7.0
150.1.24.0/24 *[OSPF/10] 00:25:16, metric 200

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
70
71 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

> to 150.1.46.4 via ge-0/0/7.0

150.1.34.0/24 *[OSPF/10] 00:25:16, metric 150
> to 150.1.46.4 via ge-0/0/7.0
150.1.35.0/24 *[OSPF/10] 00:25:16, metric 150
> to 150.1.56.5 via ae0.0
224.0.0.5/32 *[OSPF/10] 00:55:16, metric 1
MultiRecv
<snip>

lab@VMX-R6> show route protocol isis active-path

<snip>
inet6.0: 31 destinations, 36 routes (31 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

2016:150:1:1::1/128*[IS-IS/18] 00:54:47, metric 176

to fe80::205:86ff:fe71:c8c0 via ae0.0
> to fe80::205:86ff:fe71:6e07 via ge-0/0/7.0
2016:150:1:1::2/128*[IS-IS/18] 00:54:47, metric 126
> to fe80::205:86ff:fe71:6e07 via ge-0/0/7.0
2016:150:1:1::3/128*[IS-IS/18] 00:54:55, metric 113
> to fe80::205:86ff:fe71:c8c0 via ae0.0
to fe80::205:86ff:fe71:6e07 via ge-0/0/7.0
2016:150:1:1::4/128*[IS-IS/18] 00:54:57, metric 63
> to fe80::205:86ff:fe71:6e07 via ge-0/0/7.0
2016:150:1:1::5/128*[IS-IS/18] 00:55:29, metric 50
> to fe80::205:86ff:fe71:c8c0 via ae0.0
2016:150:1:12::/64 *[IS-IS/18] 00:54:47, metric 176
> to fe80::205:86ff:fe71:6e07 via ge-0/0/7.0
2016:150:1:13::/64 *[IS-IS/18] 00:54:55, metric 176
> to fe80::205:86ff:fe71:c8c0 via ae0.0
to fe80::205:86ff:fe71:6e07 via ge-0/0/7.0
2016:150:1:24::/64 *[IS-IS/18] 00:54:57, metric 126
> to fe80::205:86ff:fe71:6e07 via ge-0/0/7.0
2016:150:1:34::/64 *[IS-IS/18] 00:54:57, metric 113
> to fe80::205:86ff:fe71:6e07 via ge-0/0/7.0
2016:150:1:35::/64 *[IS-IS/18] 00:55:29, metric 113
> to fe80::205:86ff:fe71:c8c0 via ae0.0
<snip>

We now can verify task 5 of Topic 1 that the data-plane can use multiple equal-cost paths to forward
traffic to a destination IPv4/IPv6 prefix.
lab@VMX-R6> show route 150.1.1.1/32

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

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

150.1.1.1/32 *[OSPF/10] 00:55:10, metric 250

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

to 150.1.56.5 via ae0.0
> to 150.1.46.4 via ge-0/0/7.0

lab@VMX-R6> show route forwarding-table destination 150.1.1.1/32

Routing table: default.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
150.1.1.1/32 user 0 ulst 1048574 4
150.1.56.5 ucst 614 5 ae0.0
150.1.46.4 ucst 615 8 ge-0/0/7.0

lab@VMX-R6> traceroute 150.1.1.1 source 150.1.1.6

traceroute to 150.1.1.1 (150.1.1.1) from 150.1.1.6, 30 hops max, 40 byte packets
1 150.1.56.5 (150.1.56.5) 13.811 ms 12.576 ms 150.1.46.4 (150.1.46.4) 24.961 ms
2 150.1.34.3 (150.1.34.3) 23.823 ms 150.1.35.3 (150.1.35.3) 19.519 ms 19.666 ms
3 150.1.1.1 (150.1.1.1) 30.060 ms 24.491 ms 24.817 ms

lab@VMX-R6> show route 2016:150:1:1::1/128

inet6.0: 31 destinations, 36 routes (31 active, 0 holddown, 0 hidden)

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

2016:150:1:1::1/128*[IS-IS/18] 01:25:23, metric 176

to fe80::205:86ff:fe71:c8c0 via ae0.0
> to fe80::205:86ff:fe71:6e07 via ge-0/0/7.0

lab@VMX-R6> show route forwarding-table destination 2016:150:1:1::1/128

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
71
72 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Routing table: default.inet6

Internet6:
Destination Type RtRef Next hop Type Index NhRef Netif
2016:150:1:1::1/128 user 0 ulst 1048575 4
fe80::205:86ff:fe71:c8c0
ucst 618 5 ae0.0
fe80::205:86ff:fe71:6e07
ucst 621 8 ge-0/0/7.0

lab@VMX-R6> traceroute 2016:150:1:1::1 source 2016:150:1:1::6

traceroute6 to 2016:150:1:1::1 (2016:150:1:1::1) from 2016:150:1:1::6, 64 hops max, 12
byte packets
1 2016:150:1:46::4 (2016:150:1:46::4) 6.563 ms 3.208 ms 2016:150:1:56::5
(2016:150:1:56::5) 3.920 ms
2 2016:150:1:35::3 (2016:150:1:35::3) 3.827 ms 2016:150:1:34::3 (2016:150:1:34::3)
3.737 ms 2.758 ms
3 2016:150:1:1::1 (2016:150:1:1::1) 4.602 ms 4.368 ms 5.866 ms

Task 3. By default, OSPF cost is derived from a reference bandwidth value which is equivalent to 1Gbps,
therefore OSPF cannot distinguish between a 1G interface or any interface that has got speed higher
than 1G. Since Service Provider networks nowadays are moving so fast towards giant links such as 40G,
100G or even 400G, it’s imperative to ensure the highest link in the network is know in order to
configure reference bandwidth accordingly. In this case you can configure it to be anything higher than
the default value of 1G. With the default reference bandwidth, both interfaces ge-0/0/6 (1Gbps) ae0
(2Gbps) on R1 has got cost of 1.
lab@VMX-R1> show ospf interface extensive
Interface State Area DR ID BDR ID Nbrs
ae0.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Type: P2P, Address: 150.1.12.1, Mask: 255.255.255.0, MTU: 8986, Cost: 1
Adj count: 1
Hello: 10, Dead: 40, ReXmit: 5, Not Stub
Auth type: None
Protection type: None
Topology default (ID 0) -> Cost: 1
ge-0/0/6.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Type: P2P, Address: 150.1.13.1, Mask: 255.255.255.0, MTU: 8986, Cost: 1
Adj count: 1
Hello: 10, Dead: 40, ReXmit: 5, Not Stub
Auth type: None
Protection type: None
Topology default (ID 0) -> Cost: 1
lo0.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0
Type: LAN, Address: 150.1.1.1, Mask: 255.255.255.255, MTU: 65535, Cost: 0

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

Adj count: 0, Passive
Hello: 10, Dead: 40, ReXmit: 5, Not Stub
Auth type: None
Protection type: None
Topology default (ID 0) -> Passive, Cost: 0

After changing the default reference bandwidth from 1G to 100G, their costs are now differentiated.
lab@VMX-R1> show ospf interface extensive
Interface State Area DR ID BDR ID Nbrs
ae0.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Type: P2P, Address: 150.1.12.1, Mask: 255.255.255.0, MTU: 8986, Cost: 50
Adj count: 1
Hello: 10, Dead: 40, ReXmit: 5, Not Stub
Auth type: MD5, Active key ID: 1, Start time: 1969 Dec 31 16:00:00 PST
Protection type: None
Topology default (ID 0) -> Cost: 50
ge-0/0/6.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Type: P2P, Address: 150.1.13.1, Mask: 255.255.255.0, MTU: 8986, Cost: 100
Adj count: 1
Hello: 10, Dead: 40, ReXmit: 5, Not Stub
Auth type: MD5, Active key ID: 1, Start time: 1969 Dec 31 16:00:00 PST
Protection type: None
Topology default (ID 0) -> Cost: 100
lo0.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0
Type: LAN, Address: 150.1.1.1, Mask: 255.255.255.255, MTU: 65535, Cost: 0
Adj count: 0, Passive

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
72
73 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Hello: 10, Dead: 40, ReXmit: 5, Not Stub

Auth type: None
Protection type: None
Topology default (ID 0) -> Passive, Cost: 0

Next step we verify MD5 authentication for OSPF and IS-IS links and ensure all neighbourships are still in
Full/Up states.
lab@VMX-R3> show ospf neighbor
Address Interface State ID Pri Dead
150.1.34.4 ae0.0 Full 150.1.1.4 128 36
150.1.13.1 ge-0/0/6.0 Full 150.1.1.1 128 35
150.1.35.5 ge-0/0/7.0 Full 150.1.1.5 128 31

lab@VMX-R3> show isis adjacency

Interface System L State Hold (secs) SNPA
ae0.0 R4 2 Up 25
ge-0/0/6.0 R1 2 Up 23
ge-0/0/7.0 R5 2 Up 22

lab@VMX-R3> show ospf interface extensive | match "0.0.0.0|Auth"

ae0.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Auth type: MD5, Active key ID: 1, Start time: 1969 Dec 31 16:00:00 PST
ge-0/0/6.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Auth type: MD5, Active key ID: 1, Start time: 1969 Dec 31 16:00:00 PST
ge-0/0/7.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Auth type: MD5, Active key ID: 1, Start time: 1969 Dec 31 16:00:00 PST
lo0.0 DRother 0.0.0.0 0.0.0.0 0.0.0.0 0
Auth type: None

lab@VMX-R3> show isis authentication

Interface Level IIH Auth CSN Auth PSN Auth
ae0.0 2 MD5 MD5 MD5
ge-0/0/6.0 2 MD5 MD5 MD5
ge-0/0/7.0 2 MD5 MD5 MD5

L2 LSP Authentication: MD5

The tricky part of this task is about IS-IS authentication which is required to be at interface level but
including routing information as well. This implies that apart from authenticating IS-IS hello messages
(IIH), we would need to authenticate IS-IS CSN and PSN packets as well because the latter carry actual
routing information. This is called LSP authentication and is done on a per-area basis. So the right
answer is to authenticate all three packet types. It is important to enter the passphrase correctly as IS-IS
neighbourship will still be Up even if LSP authentication fails, leading to an empty LSDB and no IS-IS

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

route. Sometimes a typo mistake can jeopardise everything, let’s see how IS-IS behaves.
lab@VMX-R3# set protocols isis level 2 authentication-key JNCIE-Sp

[edit]
lab@VMX-R3# show | compare
- authentication-key "$9$/7boAuBW8xdVsUjm5Qn9CvM8L-b"; ## SECRET-DATA
+ authentication-key "$9$ekKML7ZGjq.f9ABRhrKvaJGUkP"; ## SECRET-DATA

[edit]
lab@VMX-R3# commit
commit complete

[edit]
lab@VMX-R3# run clear isis adjacency

[edit]
lab@VMX-R3# run clear isis database

[edit]
lab@VMX-R3# run show isis adjacency
Interface System L State Hold (secs) SNPA
ae0.0 R4 2 Up 19
ge-0/0/6.0 R1 2 Up 19
ge-0/0/7.0 R5 2 Up 19

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
73
74 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

[edit]
lab@VMX-R3# run show isis authentication
Interface Level IIH Auth CSN Auth PSN Auth
ae0.0 2 MD5 MD5 MD5
ge-0/0/6.0 2 MD5 MD5 MD5
ge-0/0/7.0 2 MD5 MD5 MD5

L2 LSP Authentication: MD5

[edit]
lab@VMX-R3# run show isis database
IS-IS level 1 link-state database:
0 LSPs

IS-IS level 2 link-state database:

LSP ID Sequence Checksum Lifetime Attributes
R3.00-00 0x1 0x2b65 1185 L1 L2
1 LSPs

[edit]
lab@VMX-R3# run show route protocol isis

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

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

inet6.0: 15 destinations, 18 routes (15 active, 0 holddown, 0 hidden)

Task 4. OSPFv3 is developed mainly for IPv6 routing but it has got capabilities to propage routing
information of other stacks as well such as IPv4 unicast or multicast. The first verification is to check
OSPFv3 neighbourship between DC1 and R1, R3.
lab@VMX-R1> show ospf3 neighbor
ID Interface State Pri Dead
150.1.1.10 ge-0/0/4.116 Full 128 39
Neighbor-address fe80::5668:2800:743d:5d64

lab@VMX-R3> show ospf3 neighbor

ID Interface State Pri Dead
150.1.1.10 ge-0/0/4.115 Full 128 35
Neighbor-address fe80::5668:2800:733d:5d64

Next, since at multiple points (R1, R3) mutual redistribution is performed between OSPFv2 and OSPF3,
and between IS-IS and OSPF3, we should ensure optimal routing, being that each protocol uses its native
path to get to its original routes, i.e. R1 should not use OSPFv2 path (supposedly via R3’s redistribution)

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

to get to OSPFv3 routes as R1 can learn OSPFv3 routes directly from DC1. When checking, ensure you
use active-path statement to show the paths that local router selects as best paths.
lab@VMX-R1> show route protocol ospf3 active-path table inet.0

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

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

150.1.1.10/32 *[OSPF3/150] 00:26:57, metric 0, tag 0

> to 150.1.116.2 via ge-0/0/4.116
150.1.2.0/24 *[OSPF3/150] 00:26:57, metric 0, tag 0
> to 150.1.116.2 via ge-0/0/4.116
150.1.3.0/24 *[OSPF3/150] 00:26:57, metric 0, tag 0
> to 150.1.116.2 via ge-0/0/4.116
150.1.4.0/24 *[OSPF3/150] 00:26:57, metric 0, tag 0
> to 150.1.116.2 via ge-0/0/4.116
150.1.5.0/24 *[OSPF3/150] 00:26:57, metric 0, tag 0
> to 150.1.116.2 via ge-0/0/4.116
150.1.6.0/24 *[OSPF3/150] 00:26:57, metric 0, tag 0
> to 150.1.116.2 via ge-0/0/4.116
150.1.7.0/24 *[OSPF3/150] 00:26:57, metric 0, tag 0
> to 150.1.116.2 via ge-0/0/4.116
150.1.8.0/24 *[OSPF3/150] 00:26:57, metric 0, tag 0
> to 150.1.116.2 via ge-0/0/4.116
150.1.9.0/24 *[OSPF3/150] 00:26:57, metric 0, tag 0
> to 150.1.116.2 via ge-0/0/4.116

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
74
75 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

150.1.115.0/30 *[OSPF3/10] 00:31:03, metric 2

> to 150.1.116.2 via ge-0/0/4.116

lab@VMX-R1> show route protocol ospf3 active-path table inet6.0

inet6.0: 42 destinations, 48 routes (42 active, 0 holddown, 0 hidden)

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

2016:150:1:1::10/128
*[OSPF3/150] 00:28:49, metric 0, tag 0
> to fe80::205:8600:7471:df08 via ge-0/0/4.116
2016:150:1:2::/64 *[OSPF3/150] 00:28:49, metric 0, tag 0
> to fe80::205:8600:7471:df08 via ge-0/0/4.116
2016:150:1:3::/64 *[OSPF3/150] 00:28:49, metric 0, tag 0
> to fe80::205:8600:7471:df08 via ge-0/0/4.116
2016:150:1:4::/64 *[OSPF3/150] 00:28:49, metric 0, tag 0
> to fe80::205:8600:7471:df08 via ge-0/0/4.116
2016:150:1:5::/64 *[OSPF3/150] 00:28:49, metric 0, tag 0
> to fe80::205:8600:7471:df08 via ge-0/0/4.116
2016:150:1:6::/64 *[OSPF3/150] 00:28:49, metric 0, tag 0
> to fe80::205:8600:7471:df08 via ge-0/0/4.116
2016:150:1:7::/64 *[OSPF3/150] 00:28:49, metric 0, tag 0
> to fe80::205:8600:7471:df08 via ge-0/0/4.116
2016:150:1:8::/64 *[OSPF3/150] 00:28:49, metric 0, tag 0
> to fe80::205:8600:7471:df08 via ge-0/0/4.116
2016:150:1:9::/64 *[OSPF3/150] 00:28:49, metric 0, tag 0
> to fe80::205:8600:7471:df08 via ge-0/0/4.116
2016:150:1:115::/126
*[OSPF3/10] 00:32:55, metric 2
> to fe80::205:8600:7471:df08 via ge-0/0/4.116
ff02::5/128 *[OSPF3/10] 02:06:48, metric 1
MultiRecv

The same concept applies to OSPFv2 and IS-IS original routes, for example R2 should not follow router
R1, across DC1 in order to get to R6 as R2 should be able to reach R6 via its original OSPFv2/IS-IS routes.

lab@VMX-R3> show route protocol ospf2 active-path table inet.0

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

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

150.1.1.1/32 *[OSPF/10] 01:37:59, metric 100

> to 150.1.13.1 via ge-0/0/6.0
150.1.1.2/32 *[OSPF/10] 01:37:59, metric 150
> to 150.1.34.4 via ae0.0
to 150.1.13.1 via ge-0/0/6.0
150.1.1.4/32 *[OSPF/10] 01:37:59, metric 50

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

> to 150.1.34.4 via ae0.0
150.1.1.5/32 *[OSPF/10] 01:37:59, metric 100
> to 150.1.35.5 via ge-0/0/7.0
150.1.1.6/32 *[OSPF/10] 01:37:59, metric 150
> to 150.1.34.4 via ae0.0
to 150.1.35.5 via ge-0/0/7.0
150.1.12.0/24 *[OSPF/10] 01:37:59, metric 150
> to 150.1.13.1 via ge-0/0/6.0
150.1.24.0/24 *[OSPF/10] 01:37:59, metric 150
> to 150.1.34.4 via ae0.0
150.1.46.0/24 *[OSPF/10] 01:37:59, metric 150
> to 150.1.34.4 via ae0.0
150.1.56.0/24 *[OSPF/10] 01:37:59, metric 150
> to 150.1.35.5 via ge-0/0/7.0
224.0.0.5/32 *[OSPF/10] 02:08:02, metric 1
MultiRecv

lab@VMX-R3> show route protocol isis active-path table inet6.0

inet6.0: 38 destinations, 43 routes (38 active, 0 holddown, 0 hidden)

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

2016:150:1:1::1/128*[IS-IS/18] 02:08:37, metric 63

> to fe80::205:86ff:fe71:4d06 via ge-0/0/6.0
2016:150:1:1::2/128*[IS-IS/18] 02:08:11, metric 113
> to fe80::205:86ff:fe71:71c0 via ae0.0
to fe80::205:86ff:fe71:4d06 via ge-0/0/6.0

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
75
76 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

2016:150:1:1::4/128*[IS-IS/18] 02:09:02, metric 50

> to fe80::205:86ff:fe71:71c0 via ae0.0
2016:150:1:1::5/128*[IS-IS/18] 02:08:29, metric 63
> to fe80::205:86ff:fe71:c507 via ge-0/0/7.0
2016:150:1:1::6/128*[IS-IS/18] 02:08:29, metric 113
to fe80::205:86ff:fe71:71c0 via ae0.0
> to fe80::205:86ff:fe71:c507 via ge-0/0/7.0
2016:150:1:12::/64 *[IS-IS/18] 02:08:37, metric 113
> to fe80::205:86ff:fe71:4d06 via ge-0/0/6.0
2016:150:1:24::/64 *[IS-IS/18] 02:09:02, metric 113
> to fe80::205:86ff:fe71:71c0 via ae0.0
2016:150:1:46::/64 *[IS-IS/18] 02:09:02, metric 113
> to fe80::205:86ff:fe71:71c0 via ae0.0
2016:150:1:56::/64 *[IS-IS/18] 02:08:29, metric 113
> to fe80::205:86ff:fe71:c507 via ge-0/0/7.0

Now let’s verify that the OSPF domain receives IPv4 and IPv6 prefixes advertised by DC1. We also can
generate some ping test traffic to ensure that this works on the data-plane.
lab@VMX-R4> show route protocol ospf active-path | match "OSPF/150"
150.1.1.10/32 *[OSPF/150] 00:01:59, metric 10, tag 13
150.1.2.0/24 *[OSPF/150] 00:01:59, metric 10, tag 13
150.1.3.0/24 *[OSPF/150] 00:01:59, metric 10, tag 13
150.1.4.0/24 *[OSPF/150] 00:01:59, metric 10, tag 13
150.1.5.0/24 *[OSPF/150] 00:01:59, metric 10, tag 13
150.1.6.0/24 *[OSPF/150] 00:01:59, metric 10, tag 13
150.1.7.0/24 *[OSPF/150] 00:01:59, metric 10, tag 13
150.1.8.0/24 *[OSPF/150] 00:01:59, metric 10, tag 13
150.1.9.0/24 *[OSPF/150] 00:01:59, metric 10, tag 13
150.1.115.0/30 *[OSPF/150] 00:01:59, metric 10, tag 13
150.1.116.0/30 *[OSPF/150] 00:01:59, metric 100, tag 13

lab@VMX-R4> show route protocol isis active-path | match "IS-IS/165|/126|::10/128"

2016:150:1:1::10/128
*[IS-IS/165] 00:15:20, metric 60, tag 13
2016:150:1:2::/64 *[IS-IS/165] 00:15:20, metric 60, tag 13
2016:150:1:3::/64 *[IS-IS/165] 00:15:20, metric 60, tag 13
2016:150:1:4::/64 *[IS-IS/165] 00:15:20, metric 60, tag 13
2016:150:1:5::/64 *[IS-IS/165] 00:15:20, metric 60, tag 13
2016:150:1:6::/64 *[IS-IS/165] 00:15:20, metric 60, tag 13
2016:150:1:7::/64 *[IS-IS/165] 00:15:20, metric 60, tag 13
2016:150:1:8::/64 *[IS-IS/165] 00:15:20, metric 60, tag 13
2016:150:1:9::/64 *[IS-IS/165] 00:15:20, metric 60, tag 13
2016:150:1:115::/126
*[IS-IS/165] 00:15:20, metric 60, tag 13
2016:150:1:116::/126
*[IS-IS/165] 00:15:20, metric 60, tag 13

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

lab@VMX-R4> ping rapid 150.1.2.1 source 150.1.1.4
PING 150.1.2.1 (150.1.2.1): 56 data bytes
!!!!!
--- 150.1.2.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 14.761/15.983/20.191/2.109 ms

lab@VMX-R4> ping rapid 2016:150:1:2::1 source 2016:150:1:1::4

PING6(56=40+8+8 bytes) 2016:150:1:1::4 --> 2016:150:1:2::1
!!!!!
--- 2016:150:1:2::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 19.380/19.850/20.343/0.385 ms

Next, let’s check on DC1 to see if it would prefer R1 for IPv4 routes and prefer R3 for IPv6 routes as
required by the task. IS-IS does not advertise local IS-IS interfaces so we would need to add them into
the policies to redistribute into OSPFv3. We should see one single IPv4 prefix representing the Service
Provider network 1 on DC1, preferring the path via R1 while we could see all IPv6 prefixes following the
path via R3. You can see that on R1 and R3 we have to define the directly connected IPv6 networks in
the export policy from IS-IS to OSPFv3. It is due to the fact that by default these networks are not
treated as IS-IS routes.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
76
77 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

lab@VMX-VR> show route table DC1.inet.0 protocol ospf3 active-path

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

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

0.0.0.0/0 *[OSPF3/150] 00:03:02, metric 10, tag 13

> to 150.1.116.1 via ge-0/0/8.116
150.1.0.0/16 *[OSPF3/150] 00:03:02, metric 10, tag 13
> to 150.1.116.1 via ge-0/0/8.116

lab@VMX-VR> show route table DC1.inet6.0 protocol ospf3 active-path

DC1.inet6.0: 39 destinations, 40 routes (39 active, 0 holddown, 0 hidden)

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

2016:150:1:1::1/128*[OSPF3/150] 06:44:49, metric 10, tag 13

> to fe80::205:8600:7371:ee04 via ge-0/0/8.115
2016:150:1:1::2/128*[OSPF3/150] 06:44:49, metric 10, tag 13
> to fe80::205:8600:7371:ee04 via ge-0/0/8.115
2016:150:1:1::3/128*[OSPF3/150] 04:16:05, metric 10, tag 13
> to fe80::205:8600:7371:ee04 via ge-0/0/8.115
2016:150:1:1::4/128*[OSPF3/150] 06:44:49, metric 10, tag 13
> to fe80::205:8600:7371:ee04 via ge-0/0/8.115
2016:150:1:1::5/128*[OSPF3/150] 06:44:49, metric 10, tag 13
> to fe80::205:8600:7371:ee04 via ge-0/0/8.115
2016:150:1:1::6/128*[OSPF3/150] 06:44:49, metric 10, tag 13
> to fe80::205:8600:7371:ee04 via ge-0/0/8.115
2016:150:1:12::/64 *[OSPF3/150] 06:44:49, metric 10, tag 13
> to fe80::205:8600:7371:ee04 via ge-0/0/8.115
2016:150:1:13::/64 *[OSPF3/150] 04:10:22, metric 10, tag 13
> to fe80::205:8600:7371:ee04 via ge-0/0/8.115
2016:150:1:24::/64 *[OSPF3/150] 06:44:49, metric 10, tag 13
> to fe80::205:8600:7371:ee04 via ge-0/0/8.115
2016:150:1:34::/64 *[OSPF3/150] 04:16:05, metric 10, tag 13
> to fe80::205:8600:7371:ee04 via ge-0/0/8.115
2016:150:1:35::/64 *[OSPF3/150] 04:16:05, metric 10, tag 13
> to fe80::205:8600:7371:ee04 via ge-0/0/8.115
2016:150:1:46::/64 *[OSPF3/150] 06:44:49, metric 10, tag 13
> to fe80::205:8600:7371:ee04 via ge-0/0/8.115
2016:150:1:56::/64 *[OSPF3/150] 06:44:49, metric 10, tag 13
> to fe80::205:8600:7371:ee04 via ge-0/0/8.115
ff02::5/128 *[OSPF3/10] 13:10:51, metric 1
MultiRecv

Task 5. Overload bit is an important component of OSPF that allows for taking the local router out of
services or ensure it is less likely carrying traffic within OSPF routing domain. When overload is set, the
local router would advertise maximum OSPF cost towards all other routers, signalling that it does not

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

wish to carry any traffic using OSPF routes. In order to verify overload state, we can restart the RPD
process on R3 and observe that a timeout of 1800 seconds is counted down. Right now we see zero
prefix being redistributed on R3, it is because the router is overloaded so it would not redistribute
anything.
lab@VMX-R3> restart routing
Routing protocols process started, pid 93312

lab@VMX-R3> show ospf overview

Instance: master
Router ID: 150.1.1.3
Route table index: 0
Configured overload, expires in 1783 seconds
AS boundary router
LSA refresh time: 50 minutes
Area: 0.0.0.0
Stub type: Not Stub
Authentication Type: None
Area border routers: 0, AS boundary routers: 1
Neighbors
Up (in full state): 1
Topology: default (ID 0)
Prefix export count: 0, Prefix export limit: 200
Full SPF runs: 4
SPF delay: 0.200000 sec, SPF holddown: 5 sec, SPF rapid runs: 3

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
77
78 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Backup SPF: Not Needed

lab@VMX-R3> show ospf database advertising-router self extensive

OSPF database, Area 0.0.0.0

Type ID Adv Rtr Seq Age Opt Cksum Len
Router *150.1.1.3 150.1.1.3 0x80000098 9 0x22 0x6101 108
bits 0x2, link count 7
id 150.1.1.4, data 150.1.34.3, Type PointToPoint (1)
Topology count: 0, Default metric: 65535
id 150.1.34.0, data 255.255.255.0, Type Stub (3)
Topology count: 0, Default metric: 50
id 150.1.1.1, data 150.1.13.3, Type PointToPoint (1)
Topology count: 0, Default metric: 65535
id 150.1.13.0, data 255.255.255.0, Type Stub (3)
Topology count: 0, Default metric: 100
id 150.1.1.5, data 150.1.35.3, Type PointToPoint (1)
Topology count: 0, Default metric: 65535
id 150.1.35.0, data 255.255.255.0, Type Stub (3)
Topology count: 0, Default metric: 100
id 150.1.1.3, data 255.255.255.255, Type Stub (3)
Topology count: 0, Default metric: 0
Topology default (ID 0)
Type: PointToPoint, Node ID: 150.1.1.5
Metric: 65535, Bidirectional
Type: PointToPoint, Node ID: 150.1.1.1
Metric: 65535, Bidirectional
Type: PointToPoint, Node ID: 150.1.1.4
Metric: 65535, Bidirectional
Gen timer 00:49:51
Aging timer 00:59:51
Installed 00:00:09 ago, expires in 00:59:51, sent 00:00:07 ago
Last changed 00:00:09 ago, Change count: 4, Ours

We should be able to see OSPF state changes being logged into the file ospf.log.
lab@VMX-R3> show log ospf.log
Aug 23 22:47:09 trace_on: Tracing to "/var/log/ospf.log" started
Aug 23 22:50:40.114607 OSPF neighbor 150.1.13.1 (ge-0/0/6.0 area 0.0.0.0) state changed
from Full to Init due to 1WayRcvd (event reason: neighbor is in one-way mode) (nbr
helped: 0)
Aug 23 22:50:40.115466 RPD_OSPF_NBRDOWN: OSPF neighbor 150.1.13.1 (realm ospf-v2 ge-
0/0/6.0 area 0.0.0.0) state changed from Full to Init due to 1WayRcvd (event reason:
neighbor is in one-way mode)
Aug 23 22:50:40.134540 OSPF neighbor 150.1.13.1 (ge-0/0/6.0 area 0.0.0.0) state changed
from Init to ExStart due to 2WayRcvd (event reason: neighbor detected this router) (nbr
helped: 0)
Aug 23 22:50:40.134605 RPD_OSPF_NBRUP: OSPF neighbor 150.1.13.1 (realm ospf-v2 ge-0/0/6.0
area 0.0.0.0) state changed from Init to ExStart due to 2WayRcvd (event reason: neighbor

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

detected this router)
<snip-for-brevity>

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
78
79 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 3: MPLS
Total Points: 15

Task 1 (2 points). Configure OSPFv2 to build TE database for Service Provider Network 1 which consists
of routers R1, R2, R3, R4, R5 and R6; ensure the protocol takes into account label-switched paths as next
hops if possible; ensure the tailend router is the one who removes MPLS stack instead of the
penultimate router.
R1,R2,R3,R4,R5,R6
!
set protocols ospf traffic-engineering shortcuts
set protocols isis traffic-engineering disable
set protocols mpls interface all
set protocols mpls explicit-null
set groups ALL-INTERFACES interfaces <*> unit <*> family mpls

R1,R2,R3,R4,R5,R6
!
set protocols rsvp interface all link-protection
set protocols mpls icmp-tunneling
set protocols mpls path-mtu rsvp mtu-signaling
edit groups LSP-GROUP-CORE protocols mpls label-switched-path <*>
set bandwidth 100m
set link-protection
set optimize-timer 3600
set adaptive
exit
set apply-groups LSP-GROUP-CORE

R1
!

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

edit protocols mpls
set label-switched-path R1-TO-R2 to 150.1.1.2
set label-switched-path R1-TO-R3 to 150.1.1.3
set label-switched-path R1-TO-R4 to 150.1.1.4
set label-switched-path R1-TO-R5 to 150.1.1.5
set label-switched-path R1-TO-R6 to 150.1.1.6
set label-switched-path R1-TO-R6 link-protection
set label-switched-path R1-TO-R6 optimize-timer 3600
set label-switched-path R1-TO-R6 adaptive
exit

R2
!
edit protocols mpls
set label-switched-path R2-TO-R1 to 150.1.1.1
set label-switched-path R2-TO-R3 to 150.1.1.3
set label-switched-path R2-TO-R4 to 150.1.1.4
set label-switched-path R2-TO-R5 to 150.1.1.5
set label-switched-path R2-TO-R6 to 150.1.1.6
exit

R3
!
edit protocols mpls
set label-switched-path R3-TO-R1 to 150.1.1.1
set label-switched-path R3-TO-R2 to 150.1.1.2
set label-switched-path R3-TO-R4 to 150.1.1.4
set label-switched-path R3-TO-R5 to 150.1.1.5

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
79
80 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set label-switched-path R3-TO-R6 to 150.1.1.6

exit

R4
!
edit protocols mpls
set label-switched-path R4-TO-R1 to 150.1.1.1
set label-switched-path R4-TO-R2 to 150.1.1.2
set label-switched-path R4-TO-R3 to 150.1.1.3
set label-switched-path R4-TO-R5 to 150.1.1.5
set label-switched-path R4-TO-R6 to 150.1.1.6
exit

R5
!
edit protocols mpls
set label-switched-path R5-TO-R1 to 150.1.1.1
set label-switched-path R5-TO-R2 to 150.1.1.2
set label-switched-path R5-TO-R3 to 150.1.1.3
set label-switched-path R5-TO-R4 to 150.1.1.4
set label-switched-path R5-TO-R6 to 150.1.1.6
exit

R6
!
edit protocols mpls
set label-switched-path R6-TO-R1 to 150.1.1.1
set label-switched-path R6-TO-R1 link-protection
set label-switched-path R6-TO-R1 optimize-timer 3600
set label-switched-path R6-TO-R1 adaptive
set label-switched-path R6-TO-R2 to 150.1.1.2
set label-switched-path R6-TO-R3 to 150.1.1.3
set label-switched-path R6-TO-R4 to 150.1.1.4
set label-switched-path R6-TO-R5 to 150.1.1.5
exit

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

exit
edit protocols mpls statistics
set file autobw.log size 1m files 10
set interval 600
set auto-bandwidth
set no-transit-statistics
exit

R6
!
edit protocols mpls label-switched-path R6-TO-R1
set auto-bandwidth adjust-interval 3600 minimum-bandwidth 50m maximum-bandwidth 150m
exit
edit protocols mpls statistics
set file autobw.log size 1m files 10
set interval 600
set auto-bandwidth
set no-transit-statistics
exit

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
80
81 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

!
edit protocols mpls label-switched-path R5-TO-R6
set primary VIA-R2
set secondary VIA-R4
set standby
set adaptive
exit
set protocols mpls path VIA-R2 150.1.1.2 loose
set protocols mpls path VIA-R4 150.1.1.4 loose

R6
!
edit protocols mpls label-switched-path R6-TO-R5
set primary VIA-R2
set secondary VIA-R4
set standby
set adaptive
exit
set protocols mpls path VIA-R2 150.1.1.2 loose
set protocols mpls path VIA-R4 150.1.1.4 loose

Verification
Tasks 1 and 2. Once OSPF is enabled with TE extension, it generates and propagates Opaque LSA to
advertise link attributes throughout the OSPF domain in addition to the regular cost value. The
attributes include values such as reservable bandwidth for RSVP, remaining bandwidth, etc. By default
IS-IS with TE extension is enabled so we would need to disable that function.
lab@VMX-R1> show ospf database opaque-area

OSPF database, Area 0.0.0.0

Type ID Adv Rtr Seq Age Opt Cksum Len
OpaqArea*1.0.0.1 150.1.1.1 0x80000008 658 0x22 0xf6fd 28
OpaqArea 1.0.0.1 150.1.1.2 0x80000006 2407 0x22 0xfef5 28
OpaqArea 1.0.0.1 150.1.1.3 0x80000007 995 0x22 0x1f0 28
OpaqArea 1.0.0.1 150.1.1.4 0x80000006 2558 0x22 0x7e9 28
OpaqArea 1.0.0.1 150.1.1.5 0x80000007 220 0x22 0x9e4 28
OpaqArea 1.0.0.1 150.1.1.6 0x80000008 218 0x22 0xbdf 28
OpaqArea*1.0.0.3 150.1.1.1 0x80000007 427 0x22 0xf4f2 136

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

OpaqArea 1.0.0.3 150.1.1.2 0x80000004 908 0x22 0xaad7 136
OpaqArea 1.0.0.3 150.1.1.3 0x80000005 567 0x22 0xea32 136
OpaqArea 1.0.0.3 150.1.1.4 0x80000005 1358 0x22 0xd1ce 136
OpaqArea 1.0.0.3 150.1.1.5 0x80000006 220 0x22 0xa05c 136
OpaqArea 1.0.0.3 150.1.1.6 0x80000007 217 0x22 0xc61c 136
OpaqArea*1.0.0.4 150.1.1.1 0x80000007 213 0x22 0xff1c 136
OpaqArea 1.0.0.4 150.1.1.2 0x80000006 218 0x22 0xb1ec 136
OpaqArea 1.0.0.4 150.1.1.3 0x8000000a 218 0x22 0x90c1 136
OpaqArea 1.0.0.4 150.1.1.4 0x80000006 213 0x22 0xa494 136
OpaqArea 1.0.0.4 150.1.1.5 0x80000007 216 0x22 0x6918 136
OpaqArea 1.0.0.4 150.1.1.6 0x80000009 215 0x22 0xa525 136
OpaqArea 1.0.0.5 150.1.1.3 0x80000007 213 0x22 0x3fa8 136
OpaqArea 1.0.0.5 150.1.1.4 0x80000006 218 0x22 0xc8d5 136

lab@VMX-R1> show ted database extensive 150.1.1.1

TED database: 0 ISIS nodes 6 INET nodes
NodeID: 150.1.1.1
Type: Rtr, Age: 376 secs, LinkIn: 2, LinkOut: 2
Protocol: OSPF(0.0.0.0)
To: 150.1.1.3, Local: 150.1.13.1, Remote: 150.1.13.3
Local interface index: 87, Remote interface index: 0
Color: 0 <none>
Metric: 100
Static BW: 1000Mbps
Reservable BW: 1000Mbps
Available BW [priority] bps:
[0] 650Mbps [1] 650Mbps [2] 650Mbps [3] 650Mbps

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
81
82 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

[4] 650Mbps [5] 650Mbps [6] 650Mbps [7] 650Mbps

Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 650Mbps [1] 650Mbps [2] 650Mbps [3] 650Mbps
[4] 650Mbps [5] 650Mbps [6] 650Mbps [7] 650Mbps
To: 150.1.1.2, Local: 150.1.12.1, Remote: 150.1.12.2
Local interface index: 84, Remote interface index: 0
Color: 0 <none>
Metric: 50
Static BW: 2Gbps
Reservable BW: 2Gbps
Available BW [priority] bps:
[0] 1.6Gbps [1] 1.6Gbps [2] 1.6Gbps [3] 1.6Gbps
[4] 1.6Gbps [5] 1.6Gbps [6] 1.6Gbps [7] 1.6Gbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 1.6Gbps [1] 1.6Gbps [2] 1.6Gbps [3] 1.6Gbps
[4] 1.6Gbps [5] 1.6Gbps [6] 1.6Gbps [7] 1.6Gbps

The original design of MPLS allows for PHP (penultimate-hop-popping) behaviour where the hop just
before the last hop (or the tail end router) removes MPLS stack (or topmost label) and sends packets
towards the last hop. The intention is to avoid double lookup from happening at the last hop, thereby
optimise the forwarding performance of the last hop. However this design will not be ideal with some
application such as MPLS QoS where we would need to retain the MPLS stack until the last hop for
proper classification and/or queueing on the egress. In order to disable PHP behaviour, we use
explicit-null statement under protocols mpls stanza which has effect on RSVP-signaled LSP. According
to RFC3032 when disabling PHP, label 0 is advertised by the last hop instead of label 3 to signal the
penultimate hop that it wishes to retain MPLS label stack.
lab@VMX-R1> show mpls lsp egress extensive | match "LSPname|Label in"
LSPname: R3-TO-R1, LSPpath: Primary
Resv style: 1 SE, Label in: 0, Label out: -
LSPname: Bypass->150.1.13.1
Resv style: 1 SE, Label in: 0, Label out: -
LSPname: R5-TO-R1, LSPpath: Primary
Resv style: 1 SE, Label in: 0, Label out: -
LSPname: R6-TO-R1, LSPpath: Primary
Resv style: 1 SE, Label in: 0, Label out: -
LSPname: R4-TO-R1, LSPpath: Primary

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

Resv style: 1 SE, Label in: 0, Label out: -
LSPname: R2-TO-R1, LSPpath: Primary
Resv style: 1 SE, Label in: 0, Label out: -
LSPname: Bypass->150.1.12.1
Resv style: 1 SE, Label in: 0, Label out: -

In terms of configuration efficiency and consistency, we should configure a class of LSP (group LSP-
GROUP-CORE in this case) that has got all common attributes and then let all LSPs to inherit from those.
This way we can ensure that all LSPs would have similar behaviours and there is no need to maintain
per-LSP configuration which is not scalable and raises risks such as a typo mistake or missing attributes.
Now let’s verify that all designated LSPs are in Up state.
lab@VMX-R1> show mpls lsp ingress
Ingress LSP: 5 sessions
To From State Rt P ActivePath LSPname
150.1.1.2 150.1.1.1 Up 0 * R1-TO-R2
150.1.1.3 150.1.1.1 Up 0 * R1-TO-R3
150.1.1.4 150.1.1.1 Up 0 * R1-TO-R4
150.1.1.5 150.1.1.1 Up 0 * R1-TO-R5
150.1.1.6 150.1.1.1 Up 0 * R1-TO-R6
Total 5 displayed, Up 5, Down 0

lab@VMX-R2> show mpls lsp ingress

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
82
83 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Ingress LSP: 5 sessions

To From State Rt P ActivePath LSPname
150.1.1.1 150.1.1.2 Up 0 * R2-TO-R1
150.1.1.3 150.1.1.2 Up 0 * R2-TO-R3
150.1.1.4 150.1.1.2 Up 0 * R2-TO-R4
150.1.1.5 150.1.1.2 Up 0 * R2-TO-R5
150.1.1.6 150.1.1.2 Up 0 * R2-TO-R6
Total 5 displayed, Up 5, Down 0

lab@VMX-R3> show mpls lsp ingress

Ingress LSP: 5 sessions
To From State Rt P ActivePath LSPname
150.1.1.1 150.1.1.3 Up 0 * R3-TO-R1
150.1.1.2 150.1.1.3 Up 0 * R3-TO-R2
150.1.1.4 150.1.1.3 Up 0 * R3-TO-R4
150.1.1.5 150.1.1.3 Up 0 * R3-TO-R5
150.1.1.6 150.1.1.3 Up 0 * R3-TO-R6
Total 5 displayed, Up 5, Down 0

lab@VMX-R4> show mpls lsp ingress

Ingress LSP: 5 sessions
To From State Rt P ActivePath LSPname
150.1.1.1 150.1.1.4 Up 0 * R4-TO-R1
150.1.1.2 150.1.1.4 Up 0 * R4-TO-R2
150.1.1.3 150.1.1.4 Up 0 * R4-TO-R3
150.1.1.5 150.1.1.4 Up 0 * R4-TO-R5
150.1.1.6 150.1.1.4 Up 0 * R4-TO-R6
Total 5 displayed, Up 5, Down 0

lab@VMX-R5> show mpls lsp ingress

Ingress LSP: 5 sessions
To From State Rt P ActivePath LSPname
150.1.1.1 150.1.1.5 Up 0 * R5-TO-R1
150.1.1.2 150.1.1.5 Up 0 * R5-TO-R2
150.1.1.3 150.1.1.5 Up 0 * R5-TO-R3
150.1.1.4 150.1.1.5 Up 0 * R5-TO-R4
150.1.1.6 150.1.1.5 Up 0 * VIA-R2 R5-TO-R6
Total 5 displayed, Up 5, Down 0

lab@VMX-R6> show mpls lsp ingress

Ingress LSP: 5 sessions
To From State Rt P ActivePath LSPname
150.1.1.1 150.1.1.6 Up 0 * R6-TO-R1
150.1.1.2 150.1.1.6 Up 0 * R6-TO-R2
150.1.1.3 150.1.1.6 Up 0 * R6-TO-R3
150.1.1.4 150.1.1.6 Up 0 * R6-TO-R4
150.1.1.5 150.1.1.6 Up 0 * VIA-R2 R6-TO-R5
Total 5 displayed, Up 5, Down 0

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

JUNOS offers full set of standard MPLS techniques which are asked in the current task. From the output
below we can see that LSP R1-TO-R5 requires 100Mbps of bandwidth with link protection enabled and
every 3600 seconds, router R1 would recalculate to find a best path in the network for this LSP.
lab@VMX-R1> show mpls lsp ingress name R1-TO-R5 extensive
Ingress LSP: 5 sessions

150.1.1.5
From: 150.1.1.1, State: Up, ActiveRoute: 0, LSPname: R1-TO-R5
ActivePath: (primary)
Link protection desired
LSPtype: Static Configured
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Priorities: 7 0
Bandwidth: 100Mbps
OptimizeTimer: 3600
SmartOptimizeTimer: 180
Reoptimization in 3303 second(s).
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 200)
150.1.13.3 S 150.1.35.5 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-
ID):

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
83
84 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

150.1.1.3(flag=0x21) 150.1.13.3(flag=1 Label=300000) 150.1.1.5(flag=0x20)

150.1.35.5(Label=0)
8 Aug 24 05:41:45.430 CSPF: computation result ignored, new path no benefit[4 times]
7 Aug 24 02:14:24.041 Link-protection Up
6 Aug 24 02:14:15.126 Selected as active path
5 Aug 24 02:14:15.116 Record Route: 150.1.1.3(flag=0x21) 150.1.13.3(flag=1
Label=300000) 150.1.1.5(flag=0x20) 150.1.35.5(Label=0)
4 Aug 24 02:14:15.116 Up
3 Aug 24 02:14:15.031 Originate Call
2 Aug 24 02:14:15.031 CSPF: computation result accepted 150.1.13.3 150.1.35.5
1 Aug 24 02:13:45.731 CSPF failed: no route toward 150.1.1.5
Created: Wed Aug 24 02:10:21 2016
Total 1 displayed, Up 1, Down 0

Link Protection is one of three features that JUNOS offers (Link Protection, Node Protection and Fast
Reroute) when it comes to protecting LSPs. When an LSP is enabled with Link Protection, all routers
along the best path of the LSP will automatically create Bypass LSP to be ready to serve traffic in the
case of link failure. The switchover is theoretically expected to be close to 50msec even though there
are a lot of factors such as the number of LSPs contributing to it but overall it should be significantly
quicker than pure IP routing/forwarding. LSP R1-TO-R5 traverses R1, R3, R5 and we can see below that R1
created LSP Bypass->150.1.13.3 and R3 created LSP Bypass->150.1.35.5 for protection. Those LSPs go the
other way around of the links that LSP R1-TO-R5 traverses.
lab@VMX-R1> show mpls lsp bypass
Ingress LSP: 2 sessions
To From State Rt Style Labelin Labelout LSPname
150.1.1.2 150.1.1.1 Up 0 1 SE - 299888 Bypass->150.1.12.2
150.1.1.3 150.1.1.1 Up 0 1 SE - 299840 Bypass->150.1.13.3
Total 2 displayed, Up 2, Down 0

lab@VMX-R3> show mpls lsp bypass

Ingress LSP: 3 sessions
To From State Rt Style Labelin Labelout LSPname
150.1.1.1 150.1.1.3 Up 0 1 SE - 299776 Bypass->150.1.13.1
150.1.1.4 150.1.1.3 Up 0 1 SE - 299776 Bypass->150.1.34.4
150.1.1.5 150.1.1.3 Up 0 1 SE - 299808 Bypass->150.1.35.5
Total 3 displayed, Up 3, Down 0

lab@VMX-R1> show mpls lsp bypass extensive | find 150.1.1.3

150.1.1.3
From: 150.1.1.1, LSPstate: Up, ActiveRoute: 0
LSPname: Bypass->150.1.13.3
LSPtype: Static Configured
Suggested label received: -, Suggested label sent: -

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

Recovery label received: -, Recovery label sent: 299840
Resv style: 1 SE, Label in: -, Label out: 299840
Time left: -, Since: Wed Aug 24 02:13:55 2016
Tspec: rate 0bps size 0bps peak Infbps m 20 M 9192
Port number: sender 1 receiver 21638 protocol 0
Type: Bypass LSP
Number of data route tunnel through: 4
Number of RSVP session tunnel through: 0
PATH rcvfrom: localclient
Adspec: sent MTU 8986
Path MTU: received 8986
PATH sentto: 150.1.12.2 (ae0.0) 314 pkts
RESV rcvfrom: 150.1.12.2 (ae0.0) 314 pkts
Explct route: 150.1.12.2 150.1.24.4 150.1.34.3
Record route: <self> 150.1.12.2 150.1.24.4 150.1.34.3
Total 2 displayed, Up 2, Down 0

lab@VMX-R3> show mpls lsp bypass extensive | find 150.1.1.5

150.1.1.5
From: 150.1.1.3, LSPstate: Up, ActiveRoute: 0
LSPname: Bypass->150.1.35.5
LSPtype: Static Configured
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 299808
Resv style: 1 SE, Label in: -, Label out: 299808
Time left: -, Since: Wed Aug 24 02:13:51 2016
Tspec: rate 0bps size 0bps peak Infbps m 20 M 9192

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
84
85 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Port number: sender 1 receiver 8346 protocol 0

Type: Bypass LSP
Number of data route tunnel through: 7
Number of RSVP session tunnel through: 0
PATH rcvfrom: localclient
Adspec: sent MTU 8986
Path MTU: received 8986
PATH sentto: 150.1.34.4 (ae0.0) 316 pkts
RESV rcvfrom: 150.1.34.4 (ae0.0) 316 pkts
Explct route: 150.1.34.4 150.1.46.6 150.1.56.5
Record route: <self> 150.1.34.4 150.1.46.6 150.1.56.5
Total 3 displayed, Up 3, Down 0

One of the key things that Link Protection relies on is the enablement of ECMP on the data plane that
has been done in Topic 1: Device Infrastructure previously. Without it, there would be no fast
switchover when the primary path of LSP fails.
lab@VMX-R1> show route 150.1.1.5

inet.0: 42 destinations, 42 routes (40 active, 0 holddown, 2 hidden)

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

150.1.1.5/32 *[OSPF/10] 04:20:55, metric 200

> to 150.1.13.3 via ge-0/0/6.0

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

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

150.1.1.5/32 *[RSVP/7/1] 03:57:23, metric 200

> to 150.1.13.3 via ge-0/0/6.0, label-switched-path R1-TO-R5
to 150.1.12.2 via ae0.0, label-switched-path Bypass->150.1.13.3
[OSPF/10] 03:57:14, metric 200
> to 150.1.13.3 via ge-0/0/6.0, label-switched-path R1-TO-R5
to 150.1.12.2 via ae0.0, label-switched-path Bypass->150.1.13.3

Task 3. JUNOS also offers a feature that monitors bandwidth utilisation of LSP to adjust bandwidth
requirement of the LSP. This provides flexibility and efficiency for the whole network because it would
frequently monitor ensure that LSP only requests bandwidth capacity that it needs instead of a fixed
amount. In this task, LSPs R1-TO-R6 and R6-TO-R1 are enabled with this feature.
lab@VMX-R1> show mpls lsp name R1-TO-R6 extensive
Ingress LSP: 5 sessions

150.1.1.6

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

From: 150.1.1.1, State: Up, ActiveRoute: 0, LSPname: R1-TO-R6
ActivePath: (primary)
Link protection desired
LSPtype: Static Configured
LoadBalance: Random
Autobandwidth
MinBW: 50Mbps MaxBW: 150Mbps
AdjustTimer: 3600 secs
Max AvgBW util: 0bps, Bandwidth Adjustment in 295 second(s).
Overflow limit: 0, Overflow sample count: 0
Underflow limit: 0, Underflow sample count: 0
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Priorities: 7 0
Bandwidth: 50Mbps
OptimizeTimer: 3600
SmartOptimizeTimer: 180
Reoptimization in 2833 second(s).
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 250)
150.1.13.3 S 150.1.35.5 S 150.1.56.6 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-
ID):
150.1.1.3(flag=0x21) 150.1.13.3(flag=1 Label=300016) 150.1.1.5(flag=0x21)
150.1.35.5(flag=1 Label=299840) 150.1.1.6(flag=0x20) 150.1.56.6(Label=0)
7 Aug 24 06:04:39.014 CSPF: computation result ignored, new path no benefit[3 times]
6 Aug 24 02:20:56.873 Link-protection Up
5 Aug 24 02:20:47.998 Selected as active path

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
85
86 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

4 Aug 24 02:20:47.989 Record Route: 150.1.1.3(flag=0x21) 150.1.13.3(flag=1

Label=300016) 150.1.1.5(flag=0x21) 150.1.35.5(flag=1 Label=299840) 150.1.1.6(flag=0x20)
150.1.56.6(Label=0)
3 Aug 24 02:20:47.989 Up
2 Aug 24 02:20:47.869 Originate Call
1 Aug 24 02:20:47.869 CSPF: computation result accepted 150.1.13.3 150.1.35.5
150.1.56.6
Created: Wed Aug 24 02:20:47 2016
Total 1 displayed, Up 1, Down 0

Auto-bandwidth feature requires that statistics of the LSP are collected frequently, configured with
statement statistics under protocols mpls stanza. By now there should be some logs in the file
autobw.log. Because there is no packets traversing the LSPs yet so utilisation would be zero.
lab@VMX-R1> show log autobw.log
Aug 24 02:20:47 trace_on: Tracing to "/var/log/autobw.log" started
R3-TO-R2 (LSP ID 1, Tunnel ID 8340) 0 pkt 0 Byte 0 pps
0 Bps Util 0.00% Reserved Bw 12500000 Bps
R1-TO-R2 (LSP ID 1, Tunnel ID 21633) 0 pkt 0 Byte 0 pps
0 Bps Util 0.00% Reserved Bw 12500000 Bps
Bypass->150.1.12.2 (LSP ID 1, Tunnel ID 21639) 0 pkt 0 Byte
0 pps 0 Bps Reserved Bw 0 Bps
R5-TO-R2 (LSP ID 1, Tunnel ID 43369) 0 pkt 0 Byte 0 pps
0 Bps Util 0.00% Reserved Bw 12500000 Bps
Bypass->150.1.24.2 (LSP ID 1, Tunnel ID 51032) 0 pkt 0 Byte
0 pps 0 Bps Reserved Bw 0 Bps
R1-TO-R3 (LSP ID 1, Tunnel ID 21634) 0 pkt 0 Byte 0 pps
0 Bps Util 0.00% Reserved Bw 12500000 Bps
Bypass->150.1.13.3 (LSP ID 1, Tunnel ID 21638) 0 pkt 0 Byte
0 pps 0 Bps Reserved Bw 0 Bps
Bypass->150.1.34.3 (LSP ID 1, Tunnel ID 51033) 0 pkt 0 Byte
0 pps 0 Bps Reserved Bw 0 Bps
Bypass->150.1.34.4 (LSP ID 1, Tunnel ID 8345) 0 pkt 0 Byte 0
pps 0 Bps Reserved Bw 0 Bps
R1-TO-R4 (LSP ID 1, Tunnel ID 21635) 0 pkt 0 Byte 0 pps
0 Bps Util 0.00% Reserved Bw 12500000 Bps
Bypass->150.1.24.4 (LSP ID 1, Tunnel ID 56532) 0 pkt 0 Byte
0 pps 0 Bps Reserved Bw 0 Bps

Task 4. A part from per-link/node protection features (Link Protection, Node Protection and Fast
Reroute) that set up along the primary path of LSP, there is a different technique called Path Protection.
This Path Protection involves the manual setup of a secondary path alongside the primary path (which is
dynamically or manually set up). This secondary path can be used only by the current LSP that it is
configured in. Meanwhile Bypass LSPs of the per-link/node protection features above can be shared by

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

multiple LSPs. In this task, LSPs R5-TO-R6 and R6-TO-R5 are configured with their own secondary paths.
The standby statement will activate the secondary path and make it ready for use, while the adaptive
statement will avoid double-booking for the bandwidth reservation.
lab@VMX-R5> show mpls lsp name R5-TO-R6 extensive
Ingress LSP: 5 sessions

150.1.1.6
From: 150.1.1.5, State: Up, ActiveRoute: 0, LSPname: R5-TO-R6
ActivePath: VIA-R2 (primary)
Link protection desired
LSPtype: Static Configured
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary VIA-R2 State: Up
Priorities: 7 0
Bandwidth: 100Mbps
OptimizeTimer: 3600
SmartOptimizeTimer: 180
Reoptimization in 2960 second(s).
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 450)
150.1.35.3 S 150.1.13.1 S 150.1.12.2 S 150.1.24.4 S 150.1.46.6 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-
ID):

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
86
87 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

150.1.1.3(flag=0x21) 150.1.35.3(flag=1 Label=300048) 150.1.1.1(flag=0x21)

150.1.13.1(flag=1 Label=299872) 150.1.1.2(flag=0x21) 150.1.12.2(flag=1 Label=299872)
150.1.1.4(flag=0x21) 150.1.24.4(flag=1 Label=300016) 150.1.1.6(flag=0x20)
150.1.46.6(Label=0)
8 Aug 24 06:22:18.260 CSPF: computation result ignored, new path no benefit
7 Aug 24 05:25:15.557 CSPF failed: no route toward 150.1.1.6
6 Aug 24 04:43:04.469 Link-protection Up
5 Aug 24 04:42:55.654 Selected as active path
4 Aug 24 04:42:55.645 Record Route: 150.1.1.3(flag=0x21) 150.1.35.3(flag=1
Label=300048) 150.1.1.1(flag=0x21) 150.1.13.1(flag=1 Label=299872) 150.1.1.2(flag=0x21)
150.1.12.2(flag=1 Label=299872) 150.1.1.4(flag=0x21) 150.1.24.4(flag=1 Label=300016)
150.1.1.6(flag=0x20) 150.1.46.6(Label=0)
3 Aug 24 04:42:55.645 Up
2 Aug 24 04:42:55.456 Originate Call
1 Aug 24 04:42:55.456 CSPF: computation result accepted 150.1.35.3 150.1.13.1
150.1.12.2 150.1.24.4 150.1.46.6
Standby VIA-R4 State: Up
Priorities: 7 0
Bandwidth: 100Mbps
OptimizeTimer: 3600
SmartOptimizeTimer: 180
Reoptimization in 112 second(s).
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 250)
150.1.35.3 S 150.1.34.4 S 150.1.46.6 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-
ID):
150.1.1.3(flag=0x21) 150.1.35.3(flag=1 Label=300080) 150.1.1.4(flag=0x21)
150.1.34.4(flag=1 Label=300048) 150.1.1.6(flag=0x20) 150.1.46.6(Label=0)
6 Aug 24 05:34:44.280 CSPF: computation result ignored, new path no benefit
5 Aug 24 04:44:55.085 Link-protection Up
4 Aug 24 04:43:24.364 Record Route: 150.1.1.3(flag=0x21) 150.1.35.3(flag=1
Label=300080) 150.1.1.4(flag=0x21) 150.1.34.4(flag=1 Label=300048) 150.1.1.6(flag=0x20)
150.1.46.6(Label=0)
3 Aug 24 04:43:24.364 Up
2 Aug 24 04:43:24.234 Originate Call
1 Aug 24 04:43:24.234 CSPF: computation result accepted 150.1.35.3 150.1.34.4
150.1.46.6
Created: Wed Aug 24 04:42:55 2016
Total 1 displayed, Up 1, Down 0

Note: when configuring any MPLS path, the strict statement requires that the next-hop must be one of
IP addresses of a directly connected LSR while the loose statement allows for the next-hop to be on a
remote LSR that is not directly connected with local LSR.

Interesting enough, since both LSPs R5-TO-R6 and R6-TO-R5 inherit attributes from the common group
LSP-GROUP-CORE, there are still Bypass LSPs being created for them, but they would not be use unless

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

both primary and secondary paths fail.
lab@VMX-R5> show mpls lsp bypass
Ingress LSP: 2 sessions
To From State Rt Style Labelin Labelout LSPname
150.1.1.3 150.1.1.5 Up 0 1 SE - 299792 Bypass->150.1.35.3
150.1.1.6 150.1.1.5 Up 0 1 SE - 299936 Bypass->150.1.56.6
Total 2 displayed, Up 2, Down 0

lab@VMX-R5> show route 150.1.1.6

inet.0: 40 destinations, 40 routes (38 active, 0 holddown, 2 hidden)

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

150.1.1.6/32 *[OSPF/10] 04:59:30, metric 50

> to 150.1.56.6 via ae0.0

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

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

150.1.1.6/32 *[RSVP/7/1] 01:51:00, metric 50

> to 150.1.35.3 via ge-0/0/7.0, label-switched-path R5-TO-R6
to 150.1.35.3 via ge-0/0/7.0, label-switched-path R5-TO-R6
to 150.1.56.6 via ae0.0, label-switched-path Bypass->150.1.35.3
to 150.1.56.6 via ae0.0, label-switched-path Bypass->150.1.35.3
[OSPF/10] 01:49:00, metric 50

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
87
88 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

> to 150.1.35.3 via ge-0/0/7.0, label-switched-path R5-TO-R6

to 150.1.35.3 via ge-0/0/7.0, label-switched-path R5-TO-R6
to 150.1.56.6 via ae0.0, label-switched-path Bypass->150.1.35.3
to 150.1.56.6 via ae0.0, label-switched-path Bypass->150.1.35.3

Task 5. Verification for customers or peers performing ping/traceroute will be carried out in Topc 4:
BGP, tasks 1 and 2. For now, let’s test reachability via ping mpls rsvp which is part of MPLS OAM family
and uses UDP port 3503 as the underlying transport protocol. We can use sweep statement to find out
the max MTU value that fits all segments along the path.
lab@VMX-R5> ping mpls rsvp R5-TO-R1
!!!!!
--- lsping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

lab@VMX-R5> ping mpls rsvp R5-TO-R2

!!!!!
--- lsping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

lab@VMX-R5> ping mpls rsvp R5-TO-R3

!!!!!
--- lsping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

lab@VMX-R5> ping mpls rsvp R5-TO-R4

!!!!!
--- lsping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

lab@VMX-R5> ping mpls rsvp R5-TO-R6

!!!!!
--- lsping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

lab@VMX-R5> ping mpls rsvp R5-TO-R1 sweep

100! 5052. 2576. 1340! 2580. 1960! 2272. 2116. 2040. 2000. 1980. 1972! 1984. 1980. 1976.
--- lsp ping sweep result---
Maximum Transmission Unit (MTU) is 1972 bytes

lab@VMX-R5> ping mpls rsvp R5-TO-R2 sweep

100! 5052. 2576. 1340! 2580. 1960! 2272. 2116. 2040. 2000. 1980. 1972! 1984. 1980. 1976.
--- lsp ping sweep result---
Maximum Transmission Unit (MTU) is 1972 bytes

lab@VMX-R5> ping mpls rsvp R5-TO-R3 sweep

100! 5052. 2576. 1340! 2580. 1960! 2272. 2116. 2040. 2000. 1980. 1972! 1984. 1980. 1976.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

--- lsp ping sweep result---
Maximum Transmission Unit (MTU) is 1972 bytes

lab@VMX-R5> ping mpls rsvp R5-TO-R4 sweep

100! 5052. 2576. 1340! 2580. 1960! 2272. 2116. 2040. 2000. 1980. 1972! 1984. 1980. 1976.
--- lsp ping sweep result---
Maximum Transmission Unit (MTU) is 1972 bytes

lab@VMX-R5> ping mpls rsvp R5-TO-R6 sweep

100! 5052. 2576. 1340! 2580. 1960! 2272. 2116. 2040. 2000. 1980. 1972! 1984. 1980. 1976.
--- lsp ping sweep result---
Maximum Transmission Unit (MTU) is 1972 bytes

Now with regard to signalling MTU via RSVP, the basic concept is that MTU is signaled from the ingress
LSR to the egress LSR via RSVP Adspec object. Ingress LSR uses MTU associated with the outgoing
interface over which the RSVP path message is sent and at each hop along the path, MTU in the Adspec
object is updated to the minimum of the received value and the value of the outgoing interface.
lab@VMX-R6> show mpls lsp egress name R1-TO-R6 extensive
Egress LSP: 8 sessions

150.1.1.6
From: 150.1.1.1, LSPstate: Up, ActiveRoute: 0
LSPname: R1-TO-R6, LSPpath: Primary

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
88
89 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Suggested label received: -, Suggested label sent: -

Recovery label received: -, Recovery label sent: -
Resv style: 1 SE, Label in: 0, Label out: -
Time left: 126, Since: Wed Apr 5 01:51:28 2017
Tspec: rate 50Mbps size 50Mbps peak Infbps m 20 M 9192
Port number: sender 2 receiver 24145 protocol 0
Link protection desired
Type: Protection down
PATH rcvfrom: 150.1.46.4 (ge-0/0/7.0) 3 pkts
Adspec: received MTU 1986
PATH sentto: localclient
RESV rcvfrom: localclient , Entropy label: No
Record route: 150.1.12.1 150.1.24.2 150.1.46.4 <self>
Total 1 displayed, Up 1, Down 0

lab@VMX-R5> show mpls lsp transit name R6-TO-R3 extensive

Transit LSP: 3 sessions

150.1.1.3
From: 150.1.1.6, LSPstate: Up, ActiveRoute: 0
LSPname: R6-TO-R3, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: 0
Resv style: 1 SE, Label in: 299840, Label out: 0
Time left: 131, Since: Wed Apr 5 01:51:23 2017
Tspec: rate 100Mbps size 100Mbps peak Infbps m 20 M 9192
Port number: sender 2 receiver 43373 protocol 0
Link protection desired
Type: Link protected LSP, using Bypass->150.1.35.3
1 Apr 5 01:51:23 Link protection up, using Bypass->150.1.35.3
PATH rcvfrom: 150.1.56.6 (ae0.0) 5 pkts
Adspec: received MTU 1986 sent MTU 1986
PATH sentto: 150.1.35.3 (ge-0/0/7.0) 5 pkts
RESV rcvfrom: 150.1.35.3 (ge-0/0/7.0) 4 pkts, Entropy label: No
Explct route: 150.1.35.3
Record route: 150.1.56.6 <self> 150.1.1.3 (node-id) 150.1.35.3
Total 1 displayed, Up 1, Down 0

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
89
90 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 4: BGP
Total Points: 20

R1
!
set protocols bgp group IBGP local-address 150.1.1.1

R2
!
set protocols bgp group IBGP local-address 150.1.1.2

R5
!
set protocols bgp group IBGP local-address 150.1.1.5

R6
!
set protocols bgp group IBGP local-address 150.1.1.6

R3
!

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

set routing-options autonomous-system 123456
edit protocols bgp group IBGP
set type internal
set family inet unicast
set family inet6 labeled-unicast explicit-null
set family inet-vpn unicast
set family l2vpn signaling
set cluster 150.1.1.3
set local-address 150.1.1.3
set neighbor 150.1.1.1
set neighbor 150.1.1.2
set neighbor 150.1.1.5
set neighbor 150.1.1.6
set bfd minimum-interval 500 multiplier 4
set export NHS
set advertise-inactive
exit
edit protocols bgp group IBGP-RR
set type internal
set family inet unicast
set family inet6 labeled-unicast explicit-null
set family inet-vpn unicast
set family l2vpn signaling
set local-address 150.1.1.3
set neighbor 150.1.1.4
set bfd minimum-interval 500 multiplier 4
set export NHS

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
90
91 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set advertise-inactive
exit
edit policy-options policy-statement NHS
set term 1 from protocol bgp
set term 1 from route-type external
set term 1 then next-hop self
set term 1 then accept
exit

R4
!
set routing-options autonomous-system 123456
edit protocols bgp group IBGP
set type internal
set family inet unicast
set family inet6 labeled-unicast explicit-null
set family inet-vpn unicast
set family l2vpn signaling
set cluster 150.1.1.4
set local-address 150.1.1.4
set neighbor 150.1.1.1
set neighbor 150.1.1.2
set neighbor 150.1.1.5
set neighbor 150.1.1.6
set bfd minimum-interval 500 multiplier 4
set export NHS
set advertise-inactive
exit
edit protocols bgp group IBGP-RR
set type internal
set family inet unicast
set family inet6 labeled-unicast explicit-null
set family inet-vpn unicast
set family l2vpn signaling
set local-address 150.1.1.4
set neighbor 150.1.1.3
set bfd minimum-interval 250 multiplier 4
set export NHS
set advertise-inactive
exit
edit policy-options policy-statement NHS
set term 1 from protocol bgp
set term 1 from route-type external
set term 1 then next-hop self
set term 1 then accept
exit

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

transits and peers.

Router Peer Router ASN of Peer IPv4 of Peer IPv6 of Peer

Router Router Router
R1 C1 65001 150.1.119.2 2016:150:1:119::2
P1 100 150.1.100.2 2016:150:1:100::2
T1 111 111.1.120.2 2016:111:1:120::2
R2 C2 65002 150.1.102.2 2016:150:1::102::2
P2 200 150.1.101.2 2016:150:1::101::2
T2 222 222.1.123.2 2016:222:1:123::2
R3 P1 100 150.1.113.2 2016:150:1:113::2
R5 C3 65003 170.1.230.1 NIL
R6 C4 65004 150.1.107.2 ::ffff:150.1.107.2
T1 111 111.1.105.2 2016:111:1:105::2
T2 222 222.1.106.2 2016:111:1:106::2

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
91
92 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

R1,R2,R3,R4,R5,R6
!
set protocols mpls ipv6-tunneling
edit protocols bgp group IBGP
set family inet6 labeled-unicast explicit-null
set family inet unicast
exit

R1
!
edit protocols bgp group C1
set type external
set peer-as 65001
set neighbor 150.1.119.2
set neighbor 2016:150:1:119::2
exit
edit protocols bgp group P1
set type external
set peer-as 100
set neighbor 150.1.100.2
set neighbor 2016:150:1:100::2
exit
edit protocols bgp group T1
set type external
set peer-as 111
set neighbor 111.1.120.2
set neighbor 2016:111:1:120::2
exit

R2
!
edit protocols bgp group C2
set type external
set peer-as 65002
set neighbor 150.1.102.2
set neighbor 2016:150:1:102::2
exit
edit protocols bgp group P2
set type external
set peer-as 200
set neighbor 150.1.101.2
set neighbor 2016:150:1:101::2
exit
edit protocols bgp group T2
set type external
set peer-as 222
set neighbor 222.1.123.2
set neighbor 2016:222:1:123::2
exit

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

R3
!
edit protocols bgp group P1
set type external
set peer-as 100
set neighbor 150.1.113.2
set neighbor 2016:150:1:113::2
exit

R5
!
edit protocols bgp group C3
set type external
set peer-as 65003
set neighbor 170.1.230.1
set local-address 150.1.1.5
set multihop
exit
set routing-options static route 170.1.230.1/32 qualified-next-hop 169.254.110.2
set routing-options static route 170.1.230.1/32 qualified-next-hop 169.254.111.2

R6
!
edit protocols bgp group C4
set type external
set peer-as 65004
set neighbor 150.1.107.2

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
92
93 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set family inet unicast

set family inet6 unicast
exit
edit protocols bgp group T1
set type external
set peer-as 111
set neighbor 111.1.105.2
set neighbor 2016:111:1:105::2
exit
edit protocols bgp group T2
set type external
set peer-as 222
set neighbor 222.1.106.2
set neighbor 2016:222:1:106::2
exit

Task 3 (3 points). Ensure that R6 can load balance traffic across T1 and T2, you can use IPv4 prefix
12.0.0.0/24 or 2016:12::/64 to test this task.
R6
!
delete protocols bgp group T1
delete protocols bgp group T2
edit protocols bgp group TRANSIT
set type external
set neighbor 111.1.105.2 peer-as 111
set neighbor 2016:111:1:105::2 peer-as 111
set neighbor 222.1.106.2 peer-as 222
set neighbor 2016:222:1:106::2 peer-as 222
set multipath multiple-as
exit

Task 4 (4 points). Announce the IPv4/IPv6 supernets of Service Provider Network 1 on R3 and R4 (2
static routes are allowed on each router); and then signal to P1 that R3 is the primary inbound location
for prefixes owned by Service Provider Network 1.
R3,R4
!
set routing-options aggregate route 150.1.0.0/16 as-path origin igp
set routing-options rib inet6.0 aggregate route 2016:150:1::/48 as-path origin igp
set protocols bgp group IBGP export AS-AGGREGATE
edit policy-options policy-statement AS-AGGREGATE
set term 1 from protocol aggregate
set term 1 from route-filter 150.1.0.0/16 exact
set term 1 then accept
set term 2 from protocol aggregate

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

set term 2 from route-filter 2016:150:1::/48 exact
set term 2 then accept
exit

R1
!
set protocols bgp group P1 export P1-OUT
edit policy-options policy-statement P1-OUT
set term 1 from route-filter 150.1.0.0/16 prefix-length-range /16-/24
set term 1 then metric 1000
set term 1 then accept
set term 2 from route-filter 2016:150:1::/48 prefix-length-range /48-/64
set term 2 then metric 1000
set term 2 then accept
set term DENY-ALL then reject
exit
delete routing-options aggregate route 150.1.0.0/16
delete policy-options policy-statement AGGREGATE-TO-OSPF3 term 1 from protocol aggregate

R3
!
set protocols bgp group P1 export P1-OUT
edit policy-options policy-statement P1-OUT
set term 1 from route-filter 150.1.0.0/16 prefix-length-range /16-/24
set term 1 then metric 500
set term 1 then accept
set term 2 from route-filter 2016:150:1::/48 prefix-length-range /48-/64

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
93
94 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set term 2 then metric 500

set term 2 then accept
set term DENY-ALL then reject
exit

Task 5 (5 points). Configure Service Provider Network 1 to blackhole traffic destined to any IPv4/IPv6
host prefix that is tagged with BGP community 6500.:666 advertised by customers. Ensure that prefixes
with the same BGP community sent by transits or peers are not blackholed.
R1,R2,R3,R4,R5,R6
!
edit policy-options policy-statement EBGP-CUST-RTBH
set term 1 from protocol bgp
set term 1 from community RTBH
set term 1 then community set CUST-RTBH
set term 1 then next-hop discard
set term 1 then accept
exit
set protocols bgp group IBGP import IBGP-RTBH
edit policy-options policy-statement IBGP-RTBH
set term 1 from protocol bgp
set term 1 from community CUST-RTBH
set term 1 then next-hop discard
set term 1 then accept
exit
set policy-options community RTBH member 6500.:666
set policy-options community CUST-RTBH member 16:3000
set policy-options community CUST-RTBH member 16:666

R1
!
set protocols bgp group C1 import EBGP-CUST-RTBH

R2
!
set protocols bgp group C2 import EBGP-CUST-RTBH

R5
!
set protocols bgp group C3 import EBGP-CUST-RTBH

R6
!
set protocols bgp group C4 import EBGP-CUST-RTBH

Verification

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

Tasks 1 and 2. The first step is to ensure all iBGP neighbourships are Established and also iBGP is
installed as a client of BFD which verifies forwarding path and liberates BGP from reliance upon OSPF for
notification of device failure. BGP no longer needs to rely on event-driven or periodic next-hop scanning.
The ultimate outcome is to improve convergence by rapidly detecting BGP neighbour failure.
lab@VMX-R3> show bgp summary | match 123456
150.1.1.1 123456 3069 3085 0 0 23:03:42 Establ
150.1.1.2 123456 3068 3076 0 0 23:03:38 Establ
150.1.1.4 123456 3108 3092 0 0 23:03:26 Establ
150.1.1.5 123456 3066 3089 0 0 23:03:34 Establ
150.1.1.6 123456 3090 3078 0 0 23:03:30 Establ

lab@VMX-R4> show bgp summary | match 123456

150.1.1.1 123456 3070 3102 0 0 23:03:42 Establ
150.1.1.2 123456 3069 3096 0 0 23:03:38 Establ
150.1.1.3 123456 3096 3107 0 0 23:03:48 Establ
150.1.1.5 123456 3066 3110 0 0 23:03:34 Establ
150.1.1.6 123456 3089 3098 0 0 23:03:30 Establ

lab@VMX-R3> show bfd session

Detect Transmit
Address State Interface Time Interval Multiplier
150.1.1.1 Up 2.000 0.250 8
150.1.1.2 Up 2.000 0.250 8
150.1.1.4 Up 2.000 0.250 8

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
94
95 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

150.1.1.5 Up 2.000 0.250 8

150.1.1.6 Up 2.000 0.250 8
150.1.13.1 Up ge-0/0/6.0 1.000 0.250 4
150.1.34.4 Up ae0.0 1.000 0.250 4
150.1.35.5 Up ge-0/0/7.0 1.000 0.250 4

lab@VMX-R4> show bfd session

Detect Transmit
Address State Interface Time Interval Multiplier
150.1.1.1 Up 2.000 0.250 8
150.1.1.2 Up 2.000 0.250 8
150.1.1.3 Up 2.000 0.250 8
150.1.1.5 Up 2.000 0.250 8
150.1.1.6 Up 2.000 0.250 8
150.1.24.2 Up ge-0/0/6.0 1.000 0.250 4
150.1.34.3 Up ae0.0 1.000 0.250 4
150.1.46.6 Up ge-0/0/7.0 1.000 0.250 4

iBGP address families needed in this lab includes inet unicast for pure IPv4 routing, inet6 labeled-
unicast explicit-null for IPv6 routing/forwarding over MPLS domain (6PE), inet-vpn unicast for MPLS
L3VPN and l2vpn signaling for MPLS L2VPN in Topic 5: VPN. The respective tables created by the
routers are inet.0, inet6.0, bgp.l3vpn.0 and bgp.l2vpn.0.
lab@VMX-R3> show bgp summary | find 150.1.1.
150.1.1.1 123456 3068 3084 0 0 23:03:13 Establ
inet.0: 15/22/22/0
bgp.l3vpn.0: 0/0/0/0
inet6.0: 15/22/22/0
bgp.l2vpn.0: 0/0/0/0
150.1.1.2 123456 3067 3075 0 0 23:03:09 Establ
inet.0: 21/22/22/0
bgp.l3vpn.0: 0/0/0/0
inet6.0: 21/22/22/0
bgp.l2vpn.0: 0/0/0/0
150.1.1.4 123456 3107 3091 0 0 23:02:57 Establ
inet.0: 0/50/50/0
bgp.l3vpn.0: 0/0/0/0
inet6.0: 0/43/43/0
bgp.l2vpn.0: 0/0/0/0
150.1.1.5 123456 3064 3088 0 0 23:03:05 Establ
inet.0: 7/7/7/0
bgp.l3vpn.0: 0/0/0/0
inet6.0: 0/0/0/0
bgp.l2vpn.0: 0/0/0/0
150.1.1.6 123456 3089 3076 0 0 23:03:01 Establ
inet.0: 7/22/22/0
bgp.l3vpn.0: 0/0/0/0

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

inet6.0: 7/22/22/0
bgp.l2vpn.0: 0/0/0/0
<snip-for-brevity>

This practice lab uses a redundant route reflection scenario with R3 and R4 being route reflectors which
have different cluster-IDs configured. Having different cluster-IDs has a benefit for re-convergence upon
failure of one route reflector, however the drawback is that it requires significant high amount of
memory on routers. Every client router would have to store at least double the amount of routes in its
BGP table.

Next, let’s check eBGP neighbourships with external ASNs, being customers’, peers’ and transits’. The
special eBGP sessions are between R5 and C3 where eBGP is set up over two interfaces and between R6
and C4 where a single eBGP session is used to propagate both IPv4 and IPv6 routing information. For the
session between R5 and C3, it is very straight forward that we just need to enable eBGP multihop
feature to allow for eBGP message with TTL > 1 to be accepted.
lab@VMX-R1> show bgp summary | match Establ | except 123456
111.1.120.2 111 1094 1142 0 0 8:30:26 Establ
150.1.100.2 100 1066 1114 0 0 8:18:01 Establ

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
95
96 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

150.1.119.2 65001 1094 1141 0 0 8:30:42 Establ

2016:111:1:120::2 111 1092 1138 0 0 8:30:22 Establ
2016:150:1:100::2 100 1066 1115 0 0 8:17:57 Establ
2016:150:1:119::2 65001 1094 1137 0 0 8:30:38 Establ

lab@VMX-R2> show bgp summary | match Establ | except 123456

150.1.101.2 200 1059 1107 0 0 8:14:51 Establ
150.1.102.2 65002 1063 1109 0 0 8:16:33 Establ
222.1.123.2 222 1105 1143 0 0 8:30:54 Establ
2016:150:1:101::2 200 1059 1102 0 0 8:14:47 Establ
2016:150:1:102::2 65002 1063 1105 0 0 8:16:29 Establ
2016:222:1:123::2 222 1105 1138 0 0 8:30:50 Establ

lab@VMX-R3> show bgp summary | match Establ | except 123456

150.1.113.2 100 1096 1148 0 0 8:31:20 Establ
2016:150:1:113::2 100 1096 1152 0 0 8:31:16 Establ

lab@VMX-R5> show bgp summary | match Establ | except 123456

170.1.230.1 65003 872 926 0 0 6:46:53 Establ

lab@VMX-R6> show bgp summary | match Establ | except 123456

111.1.105.2 111 846 896 0 0 6:35:22 Establ
150.1.107.2 65004 1100 1172 0 0 8:32:03 Establ
222.1.106.2 222 846 894 0 0 6:35:14 Establ
2016:111:1:105::2 111 846 891 0 0 6:35:18 Establ
2016:222:1:106::2 222 846 890 0 0 6:35:10 Establ

lab@VMX-R6> show route receive-protocol bgp 150.1.107.2 table inet.0

inet.0: 97 destinations, 157 routes (96 active, 0 holddown, 1 hidden)

Prefix Nexthop MED Lclpref AS path
* 170.1.240.0/24 150.1.107.2 65004 I
* 170.1.241.0/24 150.1.107.2 65004 I
* 170.1.242.0/24 150.1.107.2 65004 I
* 170.1.243.0/24 150.1.107.2 65004 I
* 170.1.244.0/24 150.1.107.2 65004 I
* 170.1.245.0/24 150.1.107.2 65004 I
* 170.1.246.1/32 150.1.107.2 65004 I

lab@VMX-R6> show route receive-protocol bgp 150.1.107.2 table inet6.0

inet6.0: 92 destinations, 150 routes (92 active, 0 holddown, 0 hidden)

Prefix Nexthop MED Lclpref AS path
* 2016:170:1:240::/64 ::ffff:150.1.107.2 65004 I
* 2016:170:1:241::/64 ::ffff:150.1.107.2 65004 I
* 2016:170:1:242::/64 ::ffff:150.1.107.2 65004 I
* 2016:170:1:243::/64 ::ffff:150.1.107.2 65004 I
* 2016:170:1:244::/64 ::ffff:150.1.107.2 65004 I
* 2016:170:1:245::/64 ::ffff:150.1.107.2 65004 I
2016:170:1:246::1/128

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

* ::ffff:150.1.107.2 65004 I

Side Note: it is possible that your lab system becomes unstable by getting flooded with lots of BGP
routing updates, causing iBGP sessions between R1 -> R8 to flap. One trick is to let the internal networks
(such as AS 123456 and/or AS 78) converge first and become stable before enabling the external BGP
sessions with virtual routing-instances hosted on the VR router such as C,T,P,CE virtual routers. In order
to stop these sessions temporarily, you can use command request chassis fpc offline slot 0 on the VR
router. Likewise, when you want to re-enable those sessions, you can use command request chassis fpc
online slot 0.

Task 2 requires IPv6 routing/forwarding over MPLS domain to be configured so that customers can have
IPv6 reachability to peers and transits. This refers to 6PE implementation for Service Provider Network 1
which requires the following:

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
96
97 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

indicating v6 in MPLS payload. Note: this keyword being set here is different from the same
keyword used in commands set protocols ldp explicit-null or set protocols mpls explicit-
null in which MPLS label will be advertised as "3" indicating PHP hop to not pop out the outer
label.
• set protocols mpls ipv6-tunneling, we convert IPv4 next-hop being routers’ loopback address
in table inet.3 into IPv4-mapped IPv6 next-hop and install them into table inet6.3 for IPv6 label-
based forwarding.
• family inet6 on all core-facing interfaces, this is already configured as part of initial
configurations. There is no need for specific IPv6 address to be configured, but instead just the
activation of the IPv6 AFI on the interfaces.

Let’s verify IPv4 and IPv6 reachability between customer C1 and all the peers and transits by generating
some ping tests from routing instance C1 of router VR towards all other customers, peers and transits.
lab@VMX-VR> ping routing-instance C1 rapid source 170.1.210.1 170.1.220.1
PING 170.1.220.1 (170.1.220.1): 56 data bytes
!!!!!
--- 170.1.220.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 20.261/23.964/25.121/1.857 ms

lab@VMX-VR> ping routing-instance C1 rapid source 170.1.210.1 170.1.230.1

PING 170.1.230.1 (170.1.230.1): 56 data bytes
!!!!!
--- 170.1.230.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 23.839/24.942/26.110/0.732 ms

lab@VMX-VR> ping routing-instance C1 rapid source 170.1.210.1 170.1.240.1

PING 170.1.240.1 (170.1.240.1): 56 data bytes
!!!!!
--- 170.1.240.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 29.796/29.952/30.151/0.119 ms

lab@VMX-VR> ping routing-instance C1 rapid source 170.1.210.1 111.0.0.1

PING 111.0.0.1 (111.0.0.1): 56 data bytes
!!!!!
--- 111.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 14.856/14.963/14.998/0.054 ms

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

lab@VMX-VR> ping routing-instance C1 rapid source 170.1.210.1 222.0.0.1
PING 222.0.0.1 (222.0.0.1): 56 data bytes
!!!!!
--- 222.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 24.840/24.952/25.083/0.083 ms

lab@VMX-VR> ping routing-instance C1 rapid source 170.1.210.1 100.0.0.1

PING 100.0.0.1 (100.0.0.1): 56 data bytes
!!!!!
--- 100.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 19.903/19.965/20.045/0.066 ms

lab@VMX-VR> ping routing-instance C1 rapid source 170.1.210.1 200.0.0.1

PING 200.0.0.1 (200.0.0.1): 56 data bytes
!!!!!
--- 200.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 24.855/24.975/25.077/0.074 ms

lab@VMX-VR> ping routing-instance C1 rapid source 170.1.210.1 12.0.0.1

PING 12.0.0.1 (12.0.0.1): 56 data bytes
!!!!!
--- 12.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
97
98 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

round-trip min/avg/max/stddev = 14.896/14.974/15.115/0.082 ms

lab@VMX-VR> ping routing-instance C1 rapid source 170.1.210.1 12.0.0.2

PING 12.0.0.2 (12.0.0.2): 56 data bytes
!!!!!
--- 12.0.0.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 19.807/20.963/25.044/2.043 ms

lab@VMX-VR> ping routing-instance C1 rapid source 2016:170:1:210::1 2016:170:1:220::1

PING6(56=40+8+8 bytes) 2016:170:1:210::1 --> 2016:170:1:220::1
!!!!!
--- 2016:170:1:220::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 24.926/28.935/30.070/2.007 ms

lab@VMX-VR> ping routing-instance C1 rapid source 2016:170:1:210::1 2016:170:1:240::1

PING6(56=40+8+8 bytes) 2016:170:1:210::1 --> 2016:170:1:240::1
!!!!!
--- 2016:170:1:240::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 34.789/34.958/35.041/0.100 ms

lab@VMX-VR> ping routing-instance C1 rapid source 2016:170:1:210::1 2016:111::1

PING6(56=40+8+8 bytes) 2016:170:1:210::1 --> 2016:111::1
!!!!!
--- 2016:111::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 19.834/20.958/24.829/1.937 ms

lab@VMX-VR> ping routing-instance C1 rapid source 2016:170:1:210::1 2016:222::1

PING6(56=40+8+8 bytes) 2016:170:1:210::1 --> 2016:222::1
!!!!!
--- 2016:222::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 24.834/27.956/30.445/2.453 ms

lab@VMX-VR> ping routing-instance C1 rapid source 2016:170:1:210::1 2016:100::1

PING6(56=40+8+8 bytes) 2016:170:1:210::1 --> 2016:100::1
!!!!!
--- 2016:100::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 24.756/24.946/25.026/0.098 ms

lab@VMX-VR> ping routing-instance C1 rapid source 2016:170:1:210::1 2016:200::1

PING6(56=40+8+8 bytes) 2016:170:1:210::1 --> 2016:200::1
!!!!!
--- 2016:200::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 24.929/27.926/30.132/2.425 ms

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

lab@VMX-VR> ping routing-instance C1 rapid source 2016:170:1:210::1 2016:12::1
PING6(56=40+8+8 bytes) 2016:170:1:210::1 --> 2016:12::1
!!!!!
--- 2016:12::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 18.115/19.896/21.843/1.195 ms

lab@VMX-VR> ping routing-instance C1 rapid source 2016:170:1:210::1 2016:12::2

PING6(56=40+8+8 bytes) 2016:170:1:210::1 --> 2016:12::2
!!!!!
--- 2016:12::2 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 24.701/25.966/30.001/2.023 ms

We also can perform some traceroute tests as well to see the forwarding paths of such IPv6 reachability
to be MPLS label-switched. Notice the label value of 2 due to explicit-null keyword. This test also
validates task 5 of Topic 3: MPLS.
lab@VMX-VR> traceroute routing-instance C1 source 170.1.210.1 170.1.240.1
traceroute to 170.1.240.1 (170.1.240.1) from 170.1.210.1, 30 hops max, 40 byte packets
1 150.1.119.1 (150.1.119.1) 13.298 ms 12.609 ms 9.706 ms
2 150.1.12.2 (150.1.12.2) 29.919 ms 29.803 ms 29.989 ms
MPLS Label=299952 CoS=0 TTL=1 S=1

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
98
99 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

3 150.1.24.4 (150.1.24.4) 29.842 ms 29.514 ms 29.968 ms

MPLS Label=300224 CoS=0 TTL=1 S=1
4 150.1.46.6 (150.1.46.6) 29.920 ms 29.668 ms 29.721 ms
5 170.1.240.1 (170.1.240.1) 35.021 ms 34.709 ms 34.811 ms

lab@VMX-VR> traceroute routing-instance C1 source 2016:170:1:210::1 2016:170:1:240::1

traceroute6 to 2016:170:1:240::1 (2016:170:1:240::1) from 2016:170:1:210::1, 64 hops max,
12 byte packets
1 2016:150:1:119::1 (2016:150:1:119::1) 14.641 ms 14.386 ms 14.994 ms
2 2016:150:1:12::2 (2016:150:1:12::2) 29.926 ms 29.890 ms 34.764 ms
MPLS Label=299952 CoS=0 TTL=1 S=0
MPLS Label=2 CoS=0 TTL=1 S=1
3 2016:150:1:24::4 (2016:150:1:24::4) 30.042 ms 29.893 ms 29.767 ms
MPLS Label=300224 CoS=0 TTL=1 S=0
MPLS Label=2 CoS=0 TTL=2 S=1
4 2016:150:1:46::6 (2016:150:1:46::6) 29.948 ms 29.720 ms 30.069 ms
5 2016:170:1:240::1 (2016:170:1:240::1) 35.055 ms 35.300 ms 34.277 ms

Task 3. In this task, we learn that in order to perform multipath load-balancing for eBGP neighbours,
they must be configured under the same BGP group. On R6, we should see the router chooses two paths
for prefix 12.0.0.0/24. The multipath multiple-as statement allows for load-balancing across paths from
different ASNs as long as the length of the AS_PATH attributes are equal amongst them.
lab@VMX-R6> show route 12.0.0.0

inet.0: 120 destinations, 268 routes (118 active, 0 holddown, 2 hidden)

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

12.0.0.0/24 *[BGP/170] 03:51:34, localpref 100

AS path: 111 I, validation-state: unverified
> to 111.1.105.2 via ge-0/0/4.105
to 222.1.106.2 via ge-0/0/4.106
[BGP/170] 00:11:41, localpref 100, from 150.1.1.3
AS path: 111 I, validation-state: unverified
> to 150.1.46.4 via ge-0/0/7.0, label-switched-path R6-TO-R1
to 150.1.56.5 via ae0.0, label-switched-path Bypass->150.1.46.4
[BGP/170] 03:51:26, localpref 100
AS path: 222 I, validation-state: unverified
> to 222.1.106.2 via ge-0/0/4.106
[BGP/170] 00:09:34, localpref 100, from 150.1.1.4
AS path: 222 I, validation-state: unverified
> to 150.1.46.4 via ge-0/0/7.0, label-switched-path R6-TO-R2
to 150.1.56.5 via ae0.0, label-switched-path Bypass->150.1.46.4

Task 4. Aggregated prefixes of IPv4 and IPv6 ranges of Service Provider Network 1 are originated on R3
and R4 being the route reflectors. They will be announced as long as there is a subnet fallen into their

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

ranges exists in the routing table. We can check the contributing subnets as below:
lab@VMX-R3> show route 150.1.0.0/16 exact extensive
<snip-for-brevity>
Contributing Routes (24):
150.1.1.3/32 proto Direct
150.1.13.0/24 proto Direct
150.1.34.0/24 proto Direct
150.1.35.0/24 proto Direct
150.1.113.0/30 proto Direct
150.1.115.0/30 proto Direct
150.1.1.1/32 proto OSPF
150.1.1.2/32 proto OSPF
150.1.1.4/32 proto OSPF
150.1.1.5/32 proto OSPF
150.1.1.6/32 proto OSPF
<snip-for-brevity>

lab@VMX-R3> show route 2016:150:1::/48 exact extensive

<snip-for-brevity>
Contributing Routes (24):
2016:150:1:1::3/128 proto Direct
2016:150:1:13::/64 proto Direct
2016:150:1:34::/64 proto Direct
2016:150:1:35::/64 proto Direct

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
99
100 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

2016:150:1:113::/126 proto Direct

2016:150:1:115::/126 proto OSPF3
2016:150:1:116::/126 proto OSPF3
2016:150:1:1::1/128 proto IS-IS
2016:150:1:1::2/128 proto IS-IS
2016:150:1:1::4/128 proto IS-IS
2016:150:1:1::5/128 proto IS-IS
2016:150:1:1::6/128 proto IS-IS
<snip-for-brevity>

lab@VMX-R3> show route advertising-protocol bgp 150.1.1.1 | match

"150.1.0.0|2016:150:1::"
* 150.1.0.0/16 Self 100 I
* 2016:150:1::/48 Self 100 I

In this task, we also remove the origination of the supernet 150.1.0.0/16 and its dependencies as
specified in Topic 2: IGP, task 4 since router R1 now can learn this supernet advertised by R3 and R4 via
iBGP. Let’s ensure that the IPv4 supernet is still advertised from R1 to DC1 and DC1 is still preferring R1.

lab@VMX-VR> restart routing

Routing protocols process started, pid 72863

lab@VMX-VR> show route table DC1.inet.0 150.1.0.0/16 exact

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

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

150.1.0.0/16 *[OSPF3/150] 00:00:08, metric 10, tag 13

> to 150.1.116.1 via ge-0/0/8.116

P1 connects to Service Provide Network 1 via both R1 and R3. In order to signal P1 to prefer a particular
location (R3 in this case) when sending traffic to Service Provide Network 1, we can use either AS_PATH
prepending or MED method. In this task the latter is chosen. It is only necessary to tune MED metric
high on R1 when advertising prefixes out to P1 and leave MED metric of zero on R3 (by default) so that
P1 would prefer prefixes with lower MED metric via R3. However, according to industry best practices
we should tune MED metrics on both R1 and R3 in a deterministic manner. We just need to ensure the
MED metric on R1 is higher than on R3. In real world scenarios, some Service Providers actually ‘see’
none/zero MED metric as worse than non-zero MED value. Let’s check P1’s point of view and how it is
sending traffic towards Service Provider Network 1.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

lab@VMX-VR> show route table P1.inet.0 150.1.0.0/16 exact

P1.inet.0: 108 destinations, 125 routes (108 active, 0 holddown, 0 hidden)

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

150.1.0.0/16 *[BGP/170] 00:17:32, MED 500, localpref 100

AS path: 123456 I, validation-state: unverified
> to 150.1.113.1 via ge-0/0/8.113
[BGP/170] 00:17:34, MED 1000, localpref 100
AS path: 123456 I, validation-state: unverified
> to 150.1.100.1 via ge-0/0/8.100
[BGP/170] 00:17:34, localpref 100
AS path: 111 123456 I, validation-state: unverified
> to 111.0.34.1 via lt-0/0/0.3

lab@VMX-VR> show route table P1.inet6.0 2016:150:1::/48 exact

P1.inet6.0: 91 destinations, 110 routes (91 active, 0 holddown, 0 hidden)

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

2016:150:1::/48 *[BGP/170] 00:16:28, MED 500, localpref 100

AS path: 123456 I, validation-state: unverified
> to 2016:150:1:113::1 via ge-0/0/8.113
[BGP/170] 00:16:28, MED 1000, localpref 100
AS path: 123456 I, validation-state: unverified
> to 2016:150:1:100::1 via ge-0/0/8.100
[BGP/170] 00:16:21, localpref 100

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
100
101 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

AS path: 111 123456 I, validation-state: unverified

> to 2016:111:0:34::1 via lt-0/0/0.3

lab@VMX-VR> traceroute routing-instance P1 150.1.1.6 source 100.0.0.1

traceroute to 150.1.1.6 (150.1.1.6) from 100.0.0.1, 30 hops max, 40 byte packets
1 150.1.113.1 (150.1.113.1) 14.912 ms 14.747 ms 14.987 ms
2 150.1.34.4 (150.1.34.4) 20.172 ms 19.423 ms 150.1.35.5 (150.1.35.5) 19.834 ms
3 150.1.1.6 (150.1.1.6) 24.624 ms 24.521 ms 26.896 ms

lab@VMX-VR> traceroute routing-instance P1 2016:150:1:1::6 source 2016:100::1

traceroute6 to 2016:150:1:1::6 (2016:150:1:1::6) from 2016:100::1, 64 hops max, 12 byte
packets
1 2016:150:1:113::1 (2016:150:1:113::1) 15.096 ms 15.029 ms 15.058 ms
2 2016:150:1:35::5 (2016:150:1:35::5) 19.976 ms 2016:150:1:34::4 (2016:150:1:34::4)
19.609 ms 2016:150:1:35::5 (2016:150:1:35::5) 19.798 ms
3 2016:150:1:1::6 (2016:150:1:1::6) 24.704 ms 24.780 ms 24.945 ms

We also limit the scope of the MED setting to only prefixes that Service Provider Network 1 owns by
using prefix-length-range keyword along with the proper subnet masks specifying the range of
prefixes. This will also ensure that we do not advertise prefixes automatically without any control, e.g.
mistakenly leaking out /32 prefixes or transit prefixes.
lab@VMX-R1> show route advertising-protocol bgp 150.1.100.2

inet.0: 122 destinations, 287 routes (120 active, 0 holddown, 2 hidden)

Prefix Nexthop MED Lclpref AS path
* 150.1.0.0/16 Self 1000 I
* 150.1.2.0/24 Self 1000 I
* 150.1.3.0/24 Self 1000 I
* 150.1.4.0/24 Self 1000 I
* 150.1.5.0/24 Self 1000 I
* 150.1.6.0/24 Self 1000 I
* 150.1.7.0/24 Self 1000 I
* 150.1.8.0/24 Self 1000 I
* 150.1.9.0/24 Self 1000 I
* 150.1.12.0/24 Self 1000 I
* 150.1.13.0/24 Self 1000 I
* 150.1.24.0/24 Self 1000 I
* 150.1.34.0/24 Self 1000 I
* 150.1.35.0/24 Self 1000 I
* 150.1.46.0/24 Self 1000 I
* 150.1.56.0/24 Self 1000 I

lab@VMX-R3> show route advertising-protocol bgp 150.1.113.2

inet.0: 120 destinations, 336 routes (117 active, 0 holddown, 3 hidden)

Prefix Nexthop MED Lclpref AS path

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

* 150.1.0.0/16 Self 500 I
* 150.1.2.0/24 Self 500 I
* 150.1.3.0/24 Self 500 I
* 150.1.4.0/24 Self 500 I
* 150.1.5.0/24 Self 500 I
* 150.1.6.0/24 Self 500 I
* 150.1.7.0/24 Self 500 I
* 150.1.8.0/24 Self 500 I
* 150.1.9.0/24 Self 500 I
* 150.1.12.0/24 Self 500 I
* 150.1.13.0/24 Self 500 I
* 150.1.24.0/24 Self 500 I
* 150.1.34.0/24 Self 500 I
* 150.1.35.0/24 Self 500 I
* 150.1.46.0/24 Self 500 I
* 150.1.56.0/24 Self 500 I

Task 5. In this task we configure BGP remote-triggered blackhole (RTBH) for prefixes learnt via
customers but not via peers or transits. The RTBH policies include two parts, one is eBGP signalling via
directly connected eBGP sessions with customers and the other is via iBGP signalling from the receiving
PE router towards route reflectors and other PE routers via iBGP sessions. The first part is important in
the sense of setting up the tag for discarding packets destined to customer’s victim IP address on an AS-
wide basis. It needs to ensure that the Service Provider Network 1 is deterministic about blackholing,

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
101
102 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

instead of blackholing any prefix that has got community 6500.:666 tagged. We can see that there are
some prefixes having community 6500.:666 sent from peers and transits which are not blackholed. The
second part of the RTBH policies is to signal the far end PE routers to drop offending packets right at the
ingress. This helps avoid carrying offending traffic across the core networks which can lead to
congestion. Note: this is not RTBH standard configuration and serves for the demonstration of JUNOS
configuration only.
lab@VMX-R1> show route community .*:666 table inet.0 active-path

inet.0: 126 destinations, 242 routes (124 active, 0 holddown, 2 hidden)

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

100.6.0.1/32 *[BGP/170] 07:24:55, localpref 100

AS path: 100 I, validation-state: unverified
> to 150.1.100.2 via ge-0/0/4.100
111.6.0.1/32 *[BGP/170] 07:25:11, localpref 100
AS path: 111 I, validation-state: unverified
> to 111.1.120.2 via ge-0/0/4.120
123.6.0.1/32 *[BGP/170] 07:25:11, localpref 100
AS path: 111 123 I, validation-state: unverified
> to 111.1.120.2 via ge-0/0/4.120
170.1.216.1/32 *[BGP/170] 07:25:03, localpref 100, from 150.1.119.2
AS path: 65001 I, validation-state: unverified
Discard
170.1.226.1/32 *[BGP/170] 07:25:03, localpref 100, from 150.1.1.3
AS path: 65002 I, validation-state: unverified
Discard
170.1.236.1/32 *[BGP/170] 07:25:02, localpref 100, from 150.1.1.3
AS path: 65003 I, validation-state: unverified
Discard
170.1.246.1/32 *[BGP/170] 07:24:59, localpref 100, from 150.1.1.3
AS path: 65004 I, validation-state: unverified
Discard
200.6.0.1/32 *[BGP/170] 07:24:55, localpref 100, from 150.1.1.3
AS path: 200 I, validation-state: unverified
> to 150.1.12.2 via ae0.0, label-switched-path R1-TO-R2
to 150.1.13.3 via ge-0/0/6.0, label-switched-path Bypass-
>150.1.12.2
222.6.0.1/32 *[BGP/170] 07:25:11, localpref 100, from 150.1.1.3
AS path: 222 I, validation-state: unverified
> to 150.1.12.2 via ae0.0, label-switched-path R1-TO-R2
to 150.1.13.3 via ge-0/0/6.0, label-switched-path Bypass-
>150.1.12.2

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
102
103 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 5: VPN
Total Points: 20

• CE1-1: 172.30.1[0-9].1
• CE1-2: 172.30.2[0-9].1
• CE1-3: 172.30.3[0-9].1
R1,R2,R3,R4,R5
!
set protocols bgp group IBGP family inet-vpn unicast
set routing-options autonomous-system 123456 loops 3

R1
!
set routing-options route-distinguisher-id 150.1.1.1
edit routing-instance VPN1-HUB
set instance-type vrf
set vrf-import DENY-ALL
set vrf-export VPN1-HUB-EXPORT
set interface ge-0/0/4.117
set protocols bgp group VPN1-HUB type external
set protocols bgp group VPN1-HUB peer-as 65501
set protocols bgp group VPN1-HUB as-override
set protocols bgp group VPN1-HUB neighbor 172.16.117.2
exit
edit routing-instance VPN1-SPOKE
set instance-type vrf
set vrf-import VPN1-SPOKE-IMPORT
set vrf-export DENY-ALL
set interface ge-0/0/4.118
set protocols bgp group VPN1-SPOKE type external
set protocols bgp group VPN1-SPOKE peer-as 65501
set protocols bgp group VPN1-SPOKE as-override
set protocols bgp group VPN1-SPOKE neighbor 172.16.118.2
exit
set policy-options policy-statement DENY-ALL term DENY-ALL then reject
edit policy-options policy-statement VPN1-HUB-EXPORT
set term 1 from protocol [direct bgp]

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

set term 1 then community set VPN1-HUB-RT
set term 1 then accept
exit
edit policy-options policy-statement VPN1-SPOKE-IMPORT
set term 1 from protocol bgp
set term 1 from community VPN1-SPOKE-RT
set term 1 then accept
exit
set policy-options community VPN1-HUB-RT member target:16:3310
set policy-options community VPN1-SPOKE-RT member target:16:3311
set policy-options prefix-list BGP-NEIGHBOURS-VPN apply-path "routing-instances <*>
protocols bgp group <*> neighbor <*>"
!
edit firewall filter COPP
set term BGP-VPN from source-prefix-list BGP-NEIGHBOURS-VPN
set term BGP-VPN from protocol tcp
set term BGP-VPN from port bgp
set term BGP-VPN then accept
insert term BGP-VPN after term BGP
exit

R2
!
set routing-options route-distinguisher-id 150.1.1.2
edit routing-instance VPN1-SPOKE
set instance-type vrf
set vrf-import VPN1-SPOKE-IMPORT

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
103
104 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set vrf-export VPN1-SPOKE-EXPORT

set interface ge-0/0/4.103
set protocols bgp group VPN1-SPOKE type external
set protocols bgp group VPN1-SPOKE peer-as 65501
set protocols bgp group VPN1-SPOKE as-override
set protocols bgp group VPN1-SPOKE neighbor 172.16.103.2
exit
edit policy-options policy-statement VPN1-SPOKE-EXPORT
set term 1 from protocol [direct bgp]
set term 1 then community add VPN1-SPOKE-RT
set term 1 then accept
exit
edit policy-options policy-statement VPN1-SPOKE-IMPORT
set term 1 from protocol bgp
set term 1 from community VPN1-HUB-RT
set term 1 then accept
exit
set policy-options community VPN1-HUB-RT member target:16:3310
set policy-options community VPN1-SPOKE-RT member target:16:3311

R5
!
set routing-options route-distinguisher-id 150.1.1.5
edit routing-instance VPN1-SPOKE
set instance-type vrf
set vrf-import VPN1-SPOKE-IMPORT
set vrf-export VPN1-SPOKE-EXPORT
set interface ge-0/0/4.112
set protocols bgp group VPN1-SPOKE type external
set protocols bgp group VPN1-SPOKE peer-as 65501
set protocols bgp group VPN1-SPOKE as-override
set protocols bgp group VPN1-SPOKE neighbor 172.16.112.2
exit
edit policy-options policy-statement VPN1-SPOKE-EXPORT
set term 1 from protocol [direct bgp]
set term 1 then community add VPN1-SPOKE-RT
set term 1 then accept
exit
edit policy-options policy-statement VPN1-SPOKE-IMPORT
set term 1 from protocol bgp
set term 1 from community VPN1-HUB-RT
set term 1 then accept
exit
set policy-options community VPN1-HUB-RT member target:16:3310
set policy-options community VPN1-SPOKE-RT member target:16:3311

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

connection. You can launch ping tests from any participating CE routing-instance on VRF device with
some test IPv4 addresses below. Note that CE2-2 uses VLAN 114 while CE2-1 and CE2-2 use VLAN 104.

• CE2-1: 172.30.40.1
• CE2-2: 172.30.40.2
• CE2-3: 172.30.40.3
R2,R3,R4,R5,R6
!
set protocols bgp group IBGP family l2vpn signaling

R2
!
set routing-options route-distinguisher-id 150.1.1.2
set interface ge-0/0/4 vlan-tagging
set interface ge-0/0/4 encapsulation flexible-ethernet-services
set interface ge-0/0/4.104 encapsulation vlan-vpls
set interface ge-0/0/4.104 apply-groups-except ALL-INTERFACES
edit routing-instances VPN2-CE2-2
set instance-type vpls
set vrf-target target:16:3220
set interface ge-0/0/4.104
set protocol vpls site CE2-2 site-id 2

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
104
105 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set protocol vpls site CE2-2 multi-homing

set protocol vpls site CE2-2 site-preference primary
set protocol vpls no-tunnel-services
exit

R4
!
set routing-options route-distinguisher-id 150.1.1.4
set interface ge-0/0/4 vlan-tagging
set interface ge-0/0/4 encapsulation flexible-ethernet-services
set interface ge-0/0/4.104 encapsulation vlan-vpls
set interface ge-0/0/4.104 apply-groups-except ALL-INTERFACES
edit routing-instances VPN2-CE2-2
set instance-type vpls
set vrf-target target:16:3220
set interface ge-0/0/4.104
set protocol vpls site CE2-2 site-id 2
set protocol vpls site CE2-2 multi-homing
set protocol vpls site CE2-2 site-preference backup
set protocol vpls no-tunnel-services
exit

R5
!
set routing-options route-distinguisher-id 150.1.1.5
set interface ge-0/0/3 encapsulation flexible-ethernet-services
set interface ge-0/0/3.114 encapsulation vlan-vpls
set interface ge-0/0/3.114 input-vlan-map swap vlan-id 104
set interface ge-0/0/3.114 output-vlan-map swap
set interface ge-0/0/3.114 apply-groups-except ALL-INTERFACES
edit routing-instances VPN2-CE2-1
set instance-type vpls
set vrf-target target:16:3220
set interface ge-0/0/3.114
set protocol vpls site CE2-1 site-id 1
set protocol vpls no-tunnel-services
exit

R6
!
set routing-options route-distinguisher-id 150.1.1.6
set interface ge-0/0/3 encapsulation flexible-ethernet-services
set interface ge-0/0/3.104 encapsulation vlan-vpls
set interface ge-0/0/3.104 apply-groups-except ALL-INTERFACES
edit routing-instances VPN2-CE2-3
set instance-type vpls
set vrf-target target:16:3220
set interface ge-0/0/3.104
set protocol vpls site CE2-3 site-id 3
set protocol vpls no-tunnel-services

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

exit

• CE3-1: 172.30.70.1
• CE3-2: 172.30.80.1
R3,R4,R5,R6
!
set protocols bgp group IBGP family inet-vpn unicast

R5
!
set routing-options route-distinguisher-id 150.1.1.5
edit routing-instance CSC-SP2
set instance-type vrf
set vrf-target target:16:3330
set interface ge-0/0/6
set protocols bgp group SP2 type external

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
105
106 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set protocols bgp group SP2 peer-as 78

set protocols bgp group SP2 as-override
set protocols bgp group SP2 neighbor 150.1.57.7 family inet labeled-unicast
exit

R6
!
set routing-options route-distinguisher-id 150.1.1.6
edit routing-instance CSC-SP2
set instance-type vrf
set vrf-target target:16:3330
set interface ge-0/0/6
set protocols bgp group SP2 type external
set protocols bgp group SP2 peer-as 78
set protocols bgp group SP2 as-override
set protocols bgp group SP2 neighbor 150.1.68.8 family inet labeled-unicast
exit

R7
!
set protocols mpls interface all
set protocols mpls explicit-null
set protocols mpls icmp-tunneling
set groups ALL-INTERFACES interfaces <*> unit <*> family mpls
set routing-options autonomous-system 78
edit protocols bgp group CSC-SP1
set type external
set peer-as 123456
set as-override
set neighbor 150.1.57.5 family inet labeled-unicast resolve-vpn
set export SP1-OUT
exit
edit policy-options policy-statement SP1-OUT
set term 1 from proto direct
set term 1 from route-filter 151.1.1.7/32 exact
set term 1 then accept
exit
edit protocols bgp group IBGP
set type internal
set neighbor 151.1.1.8 family inet labeled-unicast
set neighbor 151.1.1.8 family inet-vpn unicast
set local-address 151.1.1.7
exit
set routing-options route-distinguisher-id 151.1.1.7
edit routing-instance VPN3-CE3-1
set instance-type vrf
set vrf-target target:78:3330
set interface ge-0/0/4.109
set protocols ospf area 0.0.0.0 interface all
set protocols ospf export BGP-TO-OSPF

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

exit
edit policy-options policy-statement BGP-TO-OSPF
set term 1 from protocol bgp
set term 1 then accept
exit

R8
!
set protocols mpls interface all
set protocols mpls explicit-null
set protocols mpls icmp-tunneling
set groups ALL-INTERFACES interfaces <*> unit <*> family mpls
set routing-options autonomous-system 78
edit protocols bgp group CSC-SP1
set type external
set peer-as 123456
set as-override
set neighbor 150.1.68.6 family inet labeled-unicast resolve-vpn
set export SP1-OUT
exit
edit policy-options policy-statement SP1-OUT
set term 1 from proto direct
set term 1 from route-filter 151.1.1.8/32 exact
set term 1 then accept
exit
edit protocols bgp group IBGP
set type internal

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
106
107 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set neighbor 151.1.1.7 family inet labeled-unicast

set neighbor 151.1.1.7 family inet-vpn unicast
set local-address 151.1.1.8
exit
set routing-options route-distinguisher-id 151.1.1.8
edit routing-instance VPN3-CE3-1
set instance-type vrf
set vrf-target target:78:3330
set interface ge-0/0/4.108
set protocols ospf traceoptions file vpn3.ospf.log
set protocols ospf traceoptions flag all
set protocols ospf area 0.0.0.1 interface all
set protocols ospf export BGP-TO-OSPF
exit
edit policy-options policy-statement BGP-TO-OSPF
set term 1 from protocol bgp
set term 1 then accept
exit

Verification
Task 1. Firstly let’s ensure all BGP neighbourships with CE routers are now Established. And then we
check routing instance on spoke PE routers R2 and R5 to see whether they now have VPN routes
advertised by the hub PE router being R1 as well as each other’s. Output on R5 is omitted for brevity.
lab@VMX-R1> show bgp summary | match 65501
172.16.117.2 65501 107 122 0 1 3:50 Establ
172.16.118.2 65501 93 120 0 1 3:54 Establ

lab@VMX-R2> show bgp summary | match 65501

172.16.103.2 65501 117 157 0 1 4:01 Establ

lab@VMX-R5> show bgp summary | match 65501

172.16.112.2 65501 9 13 0 1 2:44 Establ

lab@VMX-R2> show route table VPN1-SPOKE.inet.0 protocol bgp active-path | match 172.30
172.30.10.0/24 *[BGP/170] 00:02:10, localpref 100, from 150.1.1.3
172.30.11.0/24 *[BGP/170] 00:02:10, localpref 100, from 150.1.1.3
172.30.12.0/24 *[BGP/170] 00:02:10, localpref 100, from 150.1.1.3
172.30.13.0/24 *[BGP/170] 00:02:10, localpref 100, from 150.1.1.3
172.30.14.0/24 *[BGP/170] 00:02:10, localpref 100, from 150.1.1.3
172.30.15.0/24 *[BGP/170] 00:02:10, localpref 100, from 150.1.1.3
172.30.16.0/24 *[BGP/170] 00:02:10, localpref 100, from 150.1.1.3
172.30.17.0/24 *[BGP/170] 00:02:10, localpref 100, from 150.1.1.3
172.30.18.0/24 *[BGP/170] 00:02:10, localpref 100, from 150.1.1.3
172.30.19.0/24 *[BGP/170] 00:02:10, localpref 100, from 150.1.1.3
172.30.20.0/24 *[BGP/170] 00:02:22, localpref 100
172.30.21.0/24 *[BGP/170] 00:02:22, localpref 100

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

172.30.22.0/24 *[BGP/170] 00:02:22, localpref 100
172.30.23.0/24 *[BGP/170] 00:02:22, localpref 100
172.30.24.0/24 *[BGP/170] 00:02:22, localpref 100
172.30.25.0/24 *[BGP/170] 00:02:22, localpref 100
172.30.26.0/24 *[BGP/170] 00:02:22, localpref 100
172.30.27.0/24 *[BGP/170] 00:02:22, localpref 100
172.30.28.0/24 *[BGP/170] 00:02:22, localpref 100
172.30.29.0/24 *[BGP/170] 00:02:22, localpref 100
172.30.30.0/24 *[BGP/170] 00:00:42, localpref 100, from 150.1.1.3
172.30.31.0/24 *[BGP/170] 00:00:42, localpref 100, from 150.1.1.3
172.30.32.0/24 *[BGP/170] 00:00:42, localpref 100, from 150.1.1.3
172.30.33.0/24 *[BGP/170] 00:00:42, localpref 100, from 150.1.1.3
172.30.34.0/24 *[BGP/170] 00:00:42, localpref 100, from 150.1.1.3
172.30.35.0/24 *[BGP/170] 00:00:42, localpref 100, from 150.1.1.3
172.30.36.0/24 *[BGP/170] 00:00:42, localpref 100, from 150.1.1.3
172.30.37.0/24 *[BGP/170] 00:00:42, localpref 100, from 150.1.1.3
172.30.38.0/24 *[BGP/170] 00:00:42, localpref 100, from 150.1.1.3
172.30.39.0/24 *[BGP/170] 00:00:42, localpref 100, from 150.1.1.3

PE router R1 has got two VRFs connecting to the hub CE1-1, one VRF receives routes from spoke CE1-2
and spoke CE1-3, then it advertises to the hub CE1-1 and at the same time rewirtes customer ASN 65001
to Service Provider 1’s ASN.
lab@VMX-R1> show route receive-protocol bgp 150.1.1.3 table VPN1-SPOKE.inet.0

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
107
108 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

VPN1-SPOKE.inet.0: 24 destinations, 46 routes (24 active, 0 holddown, 0 hidden)

Prefix Nexthop MED Lclpref AS path
* 172.16.103.0/30 150.1.1.2 100 I
* 172.16.112.0/30 150.1.1.5 100 I
* 172.30.20.0/24 150.1.1.2 100 65501 I
* 172.30.21.0/24 150.1.1.2 100 65501 I
* 172.30.22.0/24 150.1.1.2 100 65501 I
* 172.30.23.0/24 150.1.1.2 100 65501 I
* 172.30.24.0/24 150.1.1.2 100 65501 I
* 172.30.25.0/24 150.1.1.2 100 65501 I
* 172.30.26.0/24 150.1.1.2 100 65501 I
* 172.30.27.0/24 150.1.1.2 100 65501 I
* 172.30.28.0/24 150.1.1.2 100 65501 I
* 172.30.29.0/24 150.1.1.2 100 65501 I
* 172.30.30.0/24 150.1.1.5 100 65501 I
* 172.30.31.0/24 150.1.1.5 100 65501 I
* 172.30.32.0/24 150.1.1.5 100 65501 I
* 172.30.33.0/24 150.1.1.5 100 65501 I
* 172.30.34.0/24 150.1.1.5 100 65501 I
* 172.30.35.0/24 150.1.1.5 100 65501 I
* 172.30.36.0/24 150.1.1.5 100 65501 I
* 172.30.37.0/24 150.1.1.5 100 65501 I
* 172.30.38.0/24 150.1.1.5 100 65501 I
* 172.30.39.0/24 150.1.1.5 100 65501 I

lab@VMX-R1> show route advertising-protocol bgp 172.16.118.2

VPN1-SPOKE.inet.0: 24 destinations, 46 routes (24 active, 0 holddown, 0 hidden)

Prefix Nexthop MED Lclpref AS path
* 172.16.103.0/30 Self I
* 172.16.112.0/30 Self I
* 172.30.20.0/24 Self 123456 I
* 172.30.21.0/24 Self 123456 I
* 172.30.22.0/24 Self 123456 I
* 172.30.23.0/24 Self 123456 I
* 172.30.24.0/24 Self 123456 I
* 172.30.25.0/24 Self 123456 I
* 172.30.26.0/24 Self 123456 I
* 172.30.27.0/24 Self 123456 I
* 172.30.28.0/24 Self 123456 I
* 172.30.29.0/24 Self 123456 I
* 172.30.30.0/24 Self 123456 I
* 172.30.31.0/24 Self 123456 I
* 172.30.32.0/24 Self 123456 I
* 172.30.33.0/24 Self 123456 I
* 172.30.34.0/24 Self 123456 I
* 172.30.35.0/24 Self 123456 I
* 172.30.36.0/24 Self 123456 I
* 172.30.37.0/24 Self 123456 I

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

* 172.30.38.0/24 Self 123456 I
* 172.30.39.0/24 Self 123456 I

After that the hub CE1-1 re-advertises VPN1 routes back to PE router R1 but via the second VRF, from
there the routes from spoke CE1-2 and spoke CE1-3, including routes from the hub CE1-1 itself are
propagated to the route reflectors.
lab@VMX-R1> show route receive-protocol bgp 172.16.117.2 table VPN1-HUB.inet.0

VPN1-HUB.inet.0: 34 destinations, 34 routes (34 active, 0 holddown, 0 hidden)

Prefix Nexthop MED Lclpref AS path
* 172.16.103.0/30 172.16.117.2 65501 123456 I
* 172.16.112.0/30 172.16.117.2 65501 123456 I
* 172.30.10.0/24 172.16.117.2 65501 I
* 172.30.11.0/24 172.16.117.2 65501 I
* 172.30.12.0/24 172.16.117.2 65501 I
* 172.30.13.0/24 172.16.117.2 65501 I
* 172.30.14.0/24 172.16.117.2 65501 I
* 172.30.15.0/24 172.16.117.2 65501 I
* 172.30.16.0/24 172.16.117.2 65501 I
* 172.30.17.0/24 172.16.117.2 65501 I
* 172.30.18.0/24 172.16.117.2 65501 I
* 172.30.19.0/24 172.16.117.2 65501 I
* 172.30.20.0/24 172.16.117.2 65501 123456 123456 I

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
108
109 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

* 172.30.21.0/24 172.16.117.2 65501 123456 123456 I

* 172.30.22.0/24 172.16.117.2 65501 123456 123456 I
* 172.30.23.0/24 172.16.117.2 65501 123456 123456 I
* 172.30.24.0/24 172.16.117.2 65501 123456 123456 I
* 172.30.25.0/24 172.16.117.2 65501 123456 123456 I
* 172.30.26.0/24 172.16.117.2 65501 123456 123456 I
* 172.30.27.0/24 172.16.117.2 65501 123456 123456 I
* 172.30.28.0/24 172.16.117.2 65501 123456 123456 I
* 172.30.29.0/24 172.16.117.2 65501 123456 123456 I
* 172.30.30.0/24 172.16.117.2 65501 123456 123456 I
* 172.30.31.0/24 172.16.117.2 65501 123456 123456 I
* 172.30.32.0/24 172.16.117.2 65501 123456 123456 I
* 172.30.33.0/24 172.16.117.2 65501 123456 123456 I
* 172.30.34.0/24 172.16.117.2 65501 123456 123456 I
* 172.30.35.0/24 172.16.117.2 65501 123456 123456 I
* 172.30.36.0/24 172.16.117.2 65501 123456 123456 I
* 172.30.37.0/24 172.16.117.2 65501 123456 123456 I
* 172.30.38.0/24 172.16.117.2 65501 123456 123456 I
* 172.30.39.0/24 172.16.117.2 65501 123456 123456 I

lab@VMX-R1> show route advertising-protocol bgp 150.1.1.3 table VPN1-HUB.inet.0

VPN1-HUB.inet.0: 34 destinations, 34 routes (34 active, 0 holddown, 0 hidden)

Prefix Nexthop MED Lclpref AS path
* 172.16.103.0/30 Self 100 65501 123456 I
* 172.16.112.0/30 Self 100 65501 123456 I
* 172.16.117.0/30 Self 100 I
* 172.30.10.0/24 Self 100 65501 I
* 172.30.11.0/24 Self 100 65501 I
* 172.30.12.0/24 Self 100 65501 I
* 172.30.13.0/24 Self 100 65501 I
* 172.30.14.0/24 Self 100 65501 I
* 172.30.15.0/24 Self 100 65501 I
* 172.30.16.0/24 Self 100 65501 I
* 172.30.17.0/24 Self 100 65501 I
* 172.30.18.0/24 Self 100 65501 I
* 172.30.19.0/24 Self 100 65501 I
* 172.30.20.0/24 Self 100 65501 123456 123456 I
* 172.30.21.0/24 Self 100 65501 123456 123456 I
* 172.30.22.0/24 Self 100 65501 123456 123456 I
* 172.30.23.0/24 Self 100 65501 123456 123456 I
* 172.30.24.0/24 Self 100 65501 123456 123456 I
* 172.30.25.0/24 Self 100 65501 123456 123456 I
* 172.30.26.0/24 Self 100 65501 123456 123456 I
* 172.30.27.0/24 Self 100 65501 123456 123456 I
* 172.30.28.0/24 Self 100 65501 123456 123456 I
* 172.30.29.0/24 Self 100 65501 123456 123456 I
* 172.30.30.0/24 Self 100 65501 123456 123456 I
* 172.30.31.0/24 Self 100 65501 123456 123456 I
* 172.30.32.0/24 Self 100 65501 123456 123456 I

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

* 172.30.33.0/24 Self 100 65501 123456 123456 I
* 172.30.34.0/24 Self 100 65501 123456 123456 I
* 172.30.35.0/24 Self 100 65501 123456 123456 I
* 172.30.36.0/24 Self 100 65501 123456 123456 I
* 172.30.37.0/24 Self 100 65501 123456 123456 I
* 172.30.38.0/24 Self 100 65501 123456 123456 I
* 172.30.39.0/24 Self 100 65501 123456 123456 I

Now let’s ensure that the forwarding path between CE1-2 (connecting to R2) and CE1-3 (connecting to
R5) actually is across CE1-1 (connecting to R1). And also we should verify full connectivity between the
CE routers as well.
lab@VMX-VR> traceroute routing-instance CE1-2 source 172.30.20.1 172.30.30.1
traceroute to 172.30.30.1 (172.30.30.1) from 172.30.20.1, 30 hops max, 40 byte packets
1 172.16.103.1 (172.16.103.1) 14.802 ms 14.637 ms 14.961 ms
2 150.1.12.1 (150.1.12.1) 24.997 ms 24.333 ms 24.979 ms
MPLS Label=299984 CoS=0 TTL=1 S=1
3 172.16.117.2 (172.16.117.2) 24.970 ms 24.467 ms 25.172 ms
4 172.16.118.1 (172.16.118.1) 19.850 ms 24.455 ms 25.087 ms
5 150.1.13.3 (150.1.13.3) 44.892 ms 44.678 ms 44.955 ms
MPLS Label=300240 CoS=0 TTL=1 S=0
MPLS Label=299904 CoS=0 TTL=1 S=1
6 150.1.35.5 (150.1.35.5) 39.827 ms 39.513 ms 44.953 ms
MPLS Label=299904 CoS=0 TTL=1 S=1

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
109
110 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

7 172.30.30.1 (172.30.30.1) 45.102 ms 44.717 ms 44.662 ms

lab@VMX-VR> ping rapid routing-instance CE1-1 source 172.30.10.1 172.30.20.1

PING 172.30.20.1 (172.30.20.1): 56 data bytes
!!!!!
--- 172.30.20.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 19.887/19.958/20.041/0.056 ms

lab@VMX-VR> ping rapid routing-instance CE1-1 source 172.30.10.1 172.30.30.1

PING 172.30.30.1 (172.30.30.1): 56 data bytes
!!!!!
--- 172.30.30.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 24.881/26.951/30.037/2.476 ms

lab@VMX-VR> ping rapid routing-instance CE1-2 source 172.30.20.1 172.30.30.1

PING 172.30.10.1 (172.30.30.1): 56 data bytes
!!!!!
--- 172.30.10.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 19.791/19.963/20.083/0.100 ms

Task 2. With regard to VPLS, there are two main signalling protocols: BGP and LDP. BGP is more scalable
and it offers the autodiscovery feature. This task is very straight forward that an emulated shared
segment is established by VPLS over Service Provider Network 1 for the CE routers, signalled by BGP
L2VPN AFI configured with statement family l2vpn signaling. We should ensure that VPLS connections
are Up for all sites and CE routers have reachability with each other. Particularly for CE2-1 with dual PE
routers, when the primary PE router R2 fails, the backup PE router R4 should be able to maintain the
VPLS connectivity for the site.
lab@VMX-R5> show vpls connections | find Instance:

Instance: VPN2-CE2-1
Local site: CE2-1 (1)
connection-site Type St Time last up # Up trans
2 rmt Up Aug 26 18:08:42 2016 1
Remote PE: 150.1.1.2, Negotiated control-word: No
Incoming label: 262146, Outgoing label: 262145
Local interface: lsi.1048578, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPN2-CE2-1 local site 1 remote site 2
3 rmt Up Aug 26 18:08:42 2016 1
Remote PE: 150.1.1.6, Negotiated control-word: No
Incoming label: 262147, Outgoing label: 262145

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

Local interface: lsi.1048579, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPN2-CE2-1 local site 1 remote site 3

lab@VMX-R2# deactivate routing-instances VPN2-CE2-2

[edit]
lab@VMX-R2# show | compare
[edit routing-instances]
! inactive: VPN2-CE2-2 { ... }

[edit]
lab@VMX-R2# commit
commit complete

lab@VMX-R5> show vpls connections | find Instance:

Instance: VPN2-CE2-1
Local site: CE2-1 (1)
connection-site Type St Time last up # Up trans
2 rmt Up Aug 26 18:08:42 2016 1
Remote PE: 150.1.1.4, Negotiated control-word: No
Incoming label: 262146, Outgoing label: 262145
Local interface: lsi.1048578, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPN2-CE2-1 local site 1 remote site 2
3 rmt Up Aug 26 18:08:42 2016 1
Remote PE: 150.1.1.6, Negotiated control-word: No
Incoming label: 262147, Outgoing label: 262145
Local interface: lsi.1048579, Status: Up, Encapsulation: VPLS

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
110
111 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Description: Intf - vpls VPN2-CE2-1 local site 1 remote site 3

lab@VMX-VR> ping rapid routing-instance CE2-1 172.30.40.2

PING 172.30.40.2 (172.30.40.2): 56 data bytes
!!!!!
--- 172.30.40.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 29.964/30.023/30.201/0.090 ms

lab@VMX-VR> ping rapid routing-instance CE2-1 172.30.40.3

PING 172.30.40.3 (172.30.40.3): 56 data bytes
!!!!!
--- 172.30.40.3 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 34.895/38.964/40.131/2.038 ms

lab@VMX-VR> ping rapid routing-instance CE2-2 172.30.40.3

In this task we also examine VLAN-map when normalising VLAN tags across the point-to-point MPLS
L2VPN connection with the use of statements input-vlan-map and output-vlan-map at the interface
stanza. At site CE2-1, these statements will help the PE router R5 swap the configured VLAN-ID 114 with
VLAN-ID 104 which is used by other sites. This kind of VLAN modification is completely transparent to
the CE routers.

We also should check over the data-plane to see whether VPLS has learnt MAC addresses associated
with the CE routers, for example on R2.
lab@VMX-R2> show route forwarding-table family vpls
Routing table: VPN2-CE2-2.vpls
VPLS:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 dscd 662 1
lsi.1048576 intf 0 indr 1048591 5
ulst 1048594 2
150.1.24.4 Push 262146, Push 299782(top) 703
1 ge-0/0/6.0
150.1.12.1 Push 262146, Push 299782, Push
299847(top) 719 1 ae0.0
lsi.1048580 intf 0 indr 1048582 5

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

ulst 1048588 2
150.1.24.4 Push 262146, Push 299886(top) 697
1 ge-0/0/6.0
150.1.12.1 Push 262146, Push 299886, Push
299847(top) 714 1 ae0.0
02:06:0a:0e:09:04/48 user 0 indr 1048582 5
ulst 1048588 2
150.1.24.4 Push 262146, Push 299886(top) 697
1 ge-0/0/6.0
150.1.12.1 Push 262146, Push 299886, Push
299847(top) 714 1 ae0.0
02:06:0a:0e:09:05/48 user 0 indr 1048591 5
ulst 1048594 2
150.1.24.4 Push 262146, Push 299782(top) 703
1 ge-0/0/6.0
150.1.12.1 Push 262146, Push 299782, Push
299847(top) 719 1 ae0.0
02:06:0a:0e:09:08/48 user 0 ucst 669 5 ge-0/0/4.104
0x30003/51 user 0 comp 712 2
ge-0/0/4.104 intf 0 ucst 669 5 ge-0/0/4.104
0x30002/51 user 0 comp 695 2
0x30001/51 user 0 comp 694 2

Task 3. This task asks for the provisioning of MPLS CSC or Carrier-Supporting-Carrier service so that the
end customer VPN3 can have MPLS L3VPN service across two different Service Providers being ASN 78
and ASN 123456. In order to do that firstly ASN 123456 provides normal MPLS L3VPN service for ASN 78

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
111
112 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

with an extra setup for the inter-AS BGP sessions which are converted into a labelled-unicast session or
BGP-LU. This provides an LSP to be set up between two POPs of ASN 78 being R7 and R8. Why do we
need such LSP? It is because R7 and R8 will have an inner label structure that carries their own VPN
routes which ASN 123456 does not need to know or care about. ASN 123456 only provides transport for
the two POPs of ASN 78 to talk to each other, and it does not need to participate into routing
communications of ASN 78. The LSP between R7 and R8 would simplify the job of ASN 123456. Firstly
let’s check BGP neighbourship between the two ASNs and make sure the are Established, and also the
iBGP between R7 and R8 as well as the LSP between them is working on data plane. The BGP-LU
sessions from R7 and R8 have an extra configuration of resolve-vpn keyword which is very important, it
allows labeled routes to be placed in the inet.3 routing table for route resolution. Without that the BGP
NEXT_HOP for VPN3 routes will be unusable.
lab@VMX-R7> show bgp summary
<snip-for-brevity>
150.1.57.5 123456 168 170 0 0 1:15:36 Establ
inet.0: 1/1/1/0
151.1.1.8 78 173 173 0 0 1:15:32 Establ
inet.0: 0/1/1/0
bgp.l3vpn.0: 11/11/11/0
VPN3-CE3-1.inet.0: 11/11/11/0

lab@VMX-R8> show bgp summary

<snip-for-brevity>
150.1.68.6 123456 167 171 0 0 1:15:39 Establ
inet.0: 1/1/1/0
151.1.1.7 78 174 173 0 0 1:15:36 Establ
inet.0: 0/1/1/0
bgp.l3vpn.0: 12/12/12/0
VPN3-CE3-1.inet.0: 12/12/12/0

lab@VMX-R7> traceroute 151.1.1.8 source 151.1.1.7

traceroute to 151.1.1.8 (151.1.1.8) from 151.1.1.7, 30 hops max, 40 byte packets
1 150.1.57.5 (150.1.57.5) 43.675 ms 42.555 ms 44.941 ms
MPLS Label=299904 CoS=0 TTL=1 S=1
2 150.1.35.3 (150.1.35.3) 43.533 ms 44.549 ms 45.062 ms
MPLS Label=300048 CoS=0 TTL=1 S=0
MPLS Label=299872 CoS=0 TTL=1 S=1
3 150.1.13.1 (150.1.13.1) 45.015 ms 44.516 ms 45.053 ms
MPLS Label=299872 CoS=0 TTL=1 S=0
MPLS Label=299872 CoS=0 TTL=2 S=1
4 150.1.12.2 (150.1.12.2) 44.760 ms 44.466 ms 45.018 ms
MPLS Label=299888 CoS=0 TTL=1 S=0

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

MPLS Label=299872 CoS=0 TTL=3 S=1
5 150.1.24.4 (150.1.24.4) 44.987 ms 44.390 ms 44.916 ms
MPLS Label=300064 CoS=0 TTL=1 S=0
MPLS Label=299872 CoS=0 TTL=4 S=1
6 150.1.46.6 (150.1.46.6) 40.078 ms 39.773 ms 39.675 ms
MPLS Label=299872 CoS=0 TTL=1 S=1
7 151.1.1.8 (151.1.1.8) 49.952 ms 44.552 ms 44.981 ms

Next we check to make sure that routing information for VPN3 is propagated properly between the two
POPs of ASN 78.
lab@VMX-R7> show route table VPN3-CE3-1.inet.0 active-path | match "OSPF|BGP"
172.16.108.0/30 *[BGP/170] 01:15:00, localpref 100, from 151.1.1.8
172.16.145.0/30 *[OSPF/10] 01:15:01, metric 2
172.30.70.0/24 *[OSPF/150] 01:15:01, metric 0, tag 0
172.30.71.0/24 *[OSPF/150] 01:15:01, metric 0, tag 0
172.30.72.0/24 *[OSPF/150] 01:15:01, metric 0, tag 0
172.30.73.0/24 *[OSPF/150] 01:15:01, metric 0, tag 0
172.30.74.0/24 *[OSPF/150] 01:15:01, metric 0, tag 0
172.30.75.0/24 *[OSPF/150] 01:15:01, metric 0, tag 0
172.30.76.0/24 *[OSPF/150] 01:15:01, metric 0, tag 0
172.30.77.0/24 *[OSPF/150] 01:15:01, metric 0, tag 0
172.30.78.0/24 *[OSPF/150] 01:15:01, metric 0, tag 0
172.30.79.0/24 *[OSPF/150] 01:15:01, metric 0, tag 0
172.30.80.0/24 *[BGP/170] 01:15:00, MED 0, localpref 100, from 151.1.1.8

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
112
113 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

172.30.81.0/24 *[BGP/170] 01:15:00, MED 0, localpref 100, from 151.1.1.8

172.30.82.0/24 *[BGP/170] 01:15:00, MED 0, localpref 100, from 151.1.1.8
172.30.83.0/24 *[BGP/170] 01:15:00, MED 0, localpref 100, from 151.1.1.8
172.30.84.0/24 *[BGP/170] 01:15:00, MED 0, localpref 100, from 151.1.1.8
172.30.85.0/24 *[BGP/170] 01:15:00, MED 0, localpref 100, from 151.1.1.8
172.30.86.0/24 *[BGP/170] 01:15:00, MED 0, localpref 100, from 151.1.1.8
172.30.87.0/24 *[BGP/170] 01:15:00, MED 0, localpref 100, from 151.1.1.8
172.30.88.0/24 *[BGP/170] 01:15:00, MED 0, localpref 100, from 151.1.1.8
172.30.89.0/24 *[BGP/170] 01:15:00, MED 0, localpref 100, from 151.1.1.8
224.0.0.5/32 *[OSPF/10] 01:15:16, metric 1

The task does not provide OSPF Area-ID for the site CE3-2 and we would need to figure it out with
traceoptions statements.

lab@VMX-R8> show configuration | display set |match traceoptions

set routing-instances VPN3-CE3-1 protocols ospf traceoptions file vpn3.ospf.log
set routing-instances VPN3-CE3-1 protocols ospf traceoptions flag all

lab@VMX-R8> show log vpn3.ospf.log

Aug 26 19:32:04 trace_on: Tracing to "/var/log/vpn3.ospf.log" started
<snip-for-brevity>
Aug 26 19:32:08.347313 OSPF rcvd Hello 172.16.108.2 -> 224.0.0.5 (ge-0/0/4.108 IFL 76
area 0.0.0.1)
Aug 26 19:32:08.347327 Version 2, length 48, ID 172.30.80.1, area 0.0.0.1
Aug 26 19:32:08.347340 checksum 0x0, authtype 0
Aug 26 19:32:08.347353 mask 255.255.255.252, hello_ivl 10, opts 0x12, prio 128
Aug 26 19:32:08.347366 dead_ivl 40, DR 172.16.108.2, BDR 172.16.108.1
Aug 26 19:32:08.347379 neighbor 172.16.108.1
<snip-for-brevity>

Now let’s verify end-to-end connectivity between sites of VPN3. We should see that any packet leaving
AS 78 would have two labels, one is the transport label between R7 and R8 built by BGP-LU, one is the
VPN label built by MP-BGP between R7 and R8. Once it enters ASN 123456, the outer transport label is
replaced by two other labels: one enables transport between R5 and R6 built by RSVP within AS 123456
and the other is CSC-VPN label built by MP-BGP between R5 and R6.
lab@VMX-VR> ping rapid routing-instance CE3-1 172.30.80.1 source 172.30.70.1
PING 172.30.80.1 (172.30.80.1): 56 data bytes
!!!!!
--- 172.30.80.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 49.604/49.987/50.431/0.268 ms

lab@VMX-VR> traceroute routing-instance CE3-1 172.30.80.1 source 172.30.70.1

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

traceroute to 172.30.80.1 (172.30.80.1) from 172.30.70.1, 30 hops max, 40 byte packets
1 172.16.109.1 (172.16.109.1) 17.429 ms 12.738 ms 14.848 ms
2 150.1.57.5 (150.1.57.5) 74.601 ms 59.738 ms 60.069 ms
MPLS Label=299904 CoS=0 TTL=1 S=0
MPLS Label=299808 CoS=0 TTL=1 S=1
3 150.1.35.3 (150.1.35.3) 60.048 ms 59.417 ms 55.052 ms
MPLS Label=300048 CoS=0 TTL=1 S=0
MPLS Label=299872 CoS=0 TTL=1 S=0
MPLS Label=299808 CoS=0 TTL=2 S=1
4 150.1.13.1 (150.1.13.1) 59.813 ms 54.467 ms 59.940 ms
MPLS Label=299872 CoS=0 TTL=1 S=0
MPLS Label=299872 CoS=0 TTL=2 S=0
MPLS Label=299808 CoS=0 TTL=3 S=1
5 150.1.12.2 (150.1.12.2) 54.984 ms 54.555 ms 59.978 ms
MPLS Label=299888 CoS=0 TTL=1 S=0
MPLS Label=299872 CoS=0 TTL=3 S=0
MPLS Label=299808 CoS=0 TTL=4 S=1
6 150.1.24.4 (150.1.24.4) 60.119 ms 54.347 ms 60.045 ms
MPLS Label=300064 CoS=0 TTL=1 S=0
MPLS Label=299872 CoS=0 TTL=4 S=0
MPLS Label=299808 CoS=0 TTL=5 S=1
7 150.1.46.6 (150.1.46.6) 54.846 ms 59.468 ms 55.000 ms
MPLS Label=299872 CoS=0 TTL=1 S=0
MPLS Label=299808 CoS=0 TTL=6 S=1
8 150.1.68.8 (150.1.68.8) 54.994 ms 49.549 ms 50.015 ms
MPLS Label=299808 CoS=0 TTL=1 S=1
9 172.30.80.1 (172.30.80.1) 59.872 ms 54.523 ms 59.927 ms

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
113
114 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 6: CoS
Total Points: 5

Task 1 (5 points). Configure a 4-class CoS system within core network of Service Provider Network 1 in
accordance with the following table.

Class Queue Priority Allocated Drop Probability

Bandwidth
NC 3 High 10% Low, Interpolated
EF 2 Medium-High 20% Low, Interpolated
AF 1 Medium-Low 20% Low, Interpolated
BE 0 Low 50% High, Interpolated

R1,R2,R3,R4,R5,R6
!
edit class-of-service forwarding-classes
set queue 3 NC
set queue 2 EF
set queue 1 AF
set queue 0 BE
exit
edit class-of-service schedulers SCHED-NC
set priority high
set transmit-rate percent 10
set drop-profile-map loss-prio any protocol any drop-profile LOW-DROP
exit
edit class-of-service schedulers SCHED-EF
set priority medium-high
set transmit-rate percent 20
set drop-profile-map loss-prio any protocol any drop-profile LOW-DROP
exit
edit class-of-service schedulers SCHED-AF
set priority medium-low
set transmit-rate percent 20
set drop-profile-map loss-prio any protocol any drop-profile LOW-DROP
exit
edit class-of-service schedulers SCHED-BE
set priority low
set transmit-rate percent 50
set drop-profile-map loss-prio any protocol any drop-profile HIGH-DROP
exit

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

edit class-of-service drop-profile LOW-DROP interpolate
set fill [ 50 75 90 ]
set drop [ 5 15 35 ]
exit
edit class-of-service drop-profile HIGH-DROP interpolate
set fill [ 50 75 90 ]
set drop [ 20 35 50 ]
exit
edit class-of-service scheduler-map CORE-EGRESS
set forwarding-class NC scheduler SCHED-NC
set forwarding-class EF scheduler SCHED-EF
set forwarding-class AF scheduler SCHED-AF
set forwarding-class BE scheduler SCHED-BE
exit

R1,R2
!
set class-of-service interface ae0 scheduler-map CORE-EGRESS
set class-of-service interface ge-0/0/6 scheduler-map CORE-EGRESS

R3,R4
!
set class-of-service interface ae0 scheduler-map CORE-EGRESS
set class-of-service interface ge-0/0/6 scheduler-map CORE-EGRESS
set class-of-service interface ge-0/0/7 scheduler-map CORE-EGRESS

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
114
115 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

R5,R6
!
set class-of-service interface ae0 scheduler-map CORE-EGRESS
set class-of-service interface ge-0/0/7 scheduler-map CORE-EGRESS

Verification
Task 1. It is imperative to form a CoS strategy within any Service Provider network, attaining minimal
and predictable delay/jitter of real-time data such as Voice, Video, guaranteeing throughput for certain
services under link congestion periods, i.e. protecting customers and services with contracted SLAs from
best effort data or Internet traffic. Also a CoS strategy provides bandwidth isolation between different
service classes. There are many ways to create a CoS strategy, depending on specific environments,
services and customers. This task examines the configuration of egress queueing for interfaces and the
implementation of RED (random-early detection) to randomly discard packets before congestion
happens, preventing TCP slow start/synchronisation syndrome when tail-drop/fabric drop or discard-out
happens that affect all TCP flows, thereby maximise bandwidth usage of interfaces.

By default Juniper routers have got 4 queues being best-effort, expedited-forwarding, assured-
forwarding, network-control which are normally sufficient to support regular CoS strategy. However we
can create custom queues to expand traffic classification. MX-series Juniper routers may support up to
16 forwarding classes.
lab@VMX-R1> show class-of-service forwarding-class
Forwarding class ID Queue Policing priority
SPU priority
BE 0 0 normal
low
AF 1 1 normal
low
EF 2 2 normal
low
NC 3 3 normal
low

Associated with each forwarding class is a scheduler which is part of egress queueing (CoS scheduling)
on JUNOS router. The function of egress queueing is to define parameters for how system queues treat
different classes of traffic. Egress queueing determines the order that packets from different classes are
sent down to physical medium, the rate that packets of each class are sent/buffer and how to deal with

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

them in the event of congestion. In JUNOS, CoS scheduling and shaping are normally configured with 3
components: schedulers, scheduler-maps, and traffic-control-profiles under class-of-service stanza.

• The most basic component is a scheduler, defining the egress behavior of traffic associated with
a class which corresponds to a queue. In this task, we define different priorities for classes and
their allocated bandwidth. This would also protect classes with lower priorities from bandwidth
starvation when there are continuous stream of packets in classes with higher priorities.
• schedulers from multiple classes are then grouped into a compilation set called scheduler-map,
which is applied to interfaces with egress effect.
lab@VMX-R1> show class-of-service scheduler-map CORE-EGRESS
Scheduler map: CORE-EGRESS, Index: 24909

Scheduler: SCHED-BE, Forwarding class: BE, Index: 60159

Transmit rate: 50 percent, Rate Limit: none, Buffer size: remainder, Buffer Limit:
none, Priority: low
Excess Priority: unspecified
Drop profiles:
Loss priority Protocol Index Name
Low any 22810 HIGH-DROP
Medium low any 22810 HIGH-DROP

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
115
116 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Medium high any 22810 HIGH-DROP

High any 22810 HIGH-DROP

Scheduler: SCHED-AF, Forwarding class: AF, Index: 60060

Transmit rate: 20 percent, Rate Limit: none, Buffer size: remainder, Buffer Limit:
none, Priority: medium-low
Excess Priority: unspecified
Drop profiles:
Loss priority Protocol Index Name
Low any 12080 LOW-DROP
Medium low any 12080 LOW-DROP
Medium high any 12080 LOW-DROP
High any 12080 LOW-DROP

Scheduler: SCHED-EF, Forwarding class: EF, Index: 59932

Transmit rate: 20 percent, Rate Limit: none, Buffer size: remainder, Buffer Limit:
none, Priority: medium-high
Excess Priority: unspecified
Drop profiles:
Loss priority Protocol Index Name
Low any 12080 LOW-DROP
Medium low any 12080 LOW-DROP
Medium high any 12080 LOW-DROP
High any 12080 LOW-DROP

Scheduler: SCHED-NC, Forwarding class: NC, Index: 60281

Transmit rate: 10 percent, Rate Limit: none, Buffer size: remainder, Buffer Limit:
none, Priority: high
Excess Priority: unspecified
Drop profiles:
Loss priority Protocol Index Name
Low any 12080 LOW-DROP
Medium low any 12080 LOW-DROP
Medium high any 12080 LOW-DROP
High any 12080 LOW-DROP

When configuring drop profile for a forwarding class (queue), there are two values: queue fill-level and
drop-probability. Fill-level of a queue is measured by percentage of buffer memory used to temporarily
store packets of that queue before serialising packets out of the physical medium. Drop probability is
percentage value that corresponds to the likelihood of packets enqueued. The combination of those two
values allows for creating an interpolated way of dropping packets in accordance with the fill-levels of
queues. It is possible to configure up to 64 pairs of fill-level and drop-probability. JUNOS automatically
calculates the drop probability for unconfigured fill-levels to arrive at a smooth curve. You can see below
that JUNOS automatically comes up with pairs of fill-level and drop-probability which we have not

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

explicitly configured.
lab@VMX-R1> show class-of-service drop-profile LOW-DROP | no-more
Drop profile: LOW-DROP, Type: interpolated, Index: 12080
Fill level Drop probability
0 0
1 0
2 0
4 0
5 0
6 0
8 0
10 1
12 1
14 1
15 1
16 1
18 1
20 2
22 2
24 2
25 2
26 2
28 2
30 3
32 3

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
116
117 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

34 3
35 3
36 3
38 3
40 4
42 4
44 4
45 4
46 4
48 4
49 4
51 5
52 5
54 6
55 7
56 7
58 8
60 9
62 9
64 10
65 11
66 11
68 12
70 13
72 13
74 14
75 15
76 16
78 19
80 21
82 24
84 27
85 28
86 29
88 32
90 35
92 48
94 61
95 67
96 74
98 87
99 93
100 100

lab@VMX-R1> show class-of-service drop-profile HIGH-DROP | no-more

Drop profile: HIGH-DROP, Type: interpolated, Index: 22810
Fill level Drop probability
0 0
1 0
2 0

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

4 1
5 2
6 2
8 3
10 4
12 4
14 5
15 6
16 6
18 7
20 8
22 8
24 9
25 10
26 10
28 11
30 12
32 12
34 13
35 14
36 14
38 15
40 16
42 16
44 17
45 18
46 18

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
117
118 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

48 19
49 19
51 20
52 21
54 22
55 23
56 23
58 24
60 26
62 27
64 28
65 29
66 29
68 30
70 32
72 33
74 34
75 35
76 36
78 38
80 40
82 42
84 44
85 45
86 46
88 48
90 50
92 60
94 70
95 75
96 80
98 90
99 95
100 100

End of Practice Lab 1 Solutions!

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 1 Solutions

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
118
119 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Practice Lab 2 Solutions

Topic 1: Device Infrastructure

Total Points: 16

Task 2 (2 points). Configure LAG interface ae0 on each of routers R1, R2, R5, R6, R7 and R8 such that it
consists of ports ge-0/0/1 and ge-0/0/2, ensure that each LAG stays up only if all member interfaces in
the LAG are up, and all routers proactively monitor status of member links; explicitly enable LACP to
send keepalive messages every second.
R1,R2,R5,R6,R7,R8
!
set interfaces ge-0/0/1 gigether-options 802.3ad ae0
set interfaces ge-0/0/2 gigether-options 802.3ad ae0
set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 aggregated-ether-options lacp periodic fast
set interfaces ae0 aggregated-ether-options minimum-links 2

Task 3 (3 points). Configure all routers in Service Provider Network 1 to send the following syslog
messages to host 10.10.1.88: messages with warning level of facility, messages with information about
daemon processes or interactive commands entered by users. Ensure that priority and facility are
included in the messages.
R1,R2,R3,R4,R5,R6
!
set system syslog user * any emergency
edit system syslog host 10.10.1.88
set any warning
set daemon info
set interactive-commands any
set explicit-priority
exit

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

Task 4 (3 points). Configure all routers in Service Provider Network 1 such that for any locally-originated
traffic, they source from the primary address of interface loopback0. Deny SSH access with username
root, also limit the total of SSH/NETCONF sessions up to 5 at a given time and up to 3 per minute, accept
only SSHv2 sessions. Send a copy of full configuration to URL ftp://admin:[email protected] any time a
commit is made and also compress the local configuration file.
R1,R2,R3,R4,R5,R6
!
set system default-address-selection
edit system services
set ssh root-login deny
set ssh protocol-version v2
set ssh connection-limit 5
set ssh rate-limit 3
set netconf ssh connection-limit 5
set netconf ssh rate-limit 3
exit
set system compress-configuration-files
set system archival config transfer-on-commit
set system archival config archive-sites ftp://admin:[email protected]

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
119
120 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

• Term 1 – block Internet traffic sourcing from to addresses documented in RFCs 1918, 3330,
5735, and 6598; count packets hit this term in counter name T1-BOGON-DISCARDED.
• Term 2 – allow ICMP Echo-Request, Echo-Reply, Time-Exceeded, Unreachable to allow for
ping/traceroute but limit their rate at 10Mbps; count packets hit and confirm to this term in
counter name T2-ICMP-POLICED.
• Term 3 – allow BGP traffic from configured BGP sessions only; this ACL should not be updated
any time there is a new BGP neighbour; count packets hit this term in counter name T3-BGP-
ALLOWED.
• Term 4 – block all traffic destined to addresses of local router as well as to infrastructure ranges
that interconnect R1, R2, R3, R4, R5 and R6; count packets hit this term in counter name T4-
INFRA-DISCARDED.
• Term 5 – allow everything else and count packets hit this term in counter name T5-DEFAULT-
ALLOWED.
R1,R2,R3,R4,R5,R6
!
edit firewall filter ACL-OUTSIDE-IN
set term 1 from source-prefix-list PL-BOGON
set term 1 then count T1-BOGON-DISCARDED
set term 1 then discard
set term 2 from icmp-type [echo-request echo-reply time-exceeded unreachable]
set term 2 then police 10M
set term 2 then count T2-ICMP-POLICED
set term 2 then accept
set term 3 from protocol tcp
set term 3 from port bgp
set term 3 from source-prefix-list PL-BGP-NEIGHBOURS
set term 3 then count T3-BGP-ALLOWED
set term 3 then accept
set term 4 from destination-prefix-list PL-LOCAL-LINKS
set term 4 from destination-prefix-list PL-INFRA
set term 4 then count T4-INFRA-DISCARDED
set term 4 then discard
set term 5 then count T5-DEFAULT-ALLOWED

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

set term 5 then accept
exit
edit policy-options prefix-list PL-BOGON
set 0.0.0.0/8
set 10.0.0.0/8
set 127.0.0.0/8
set 169.254.0.0/16
set 172.16.0.0/12
set 192.0.2.0/24
set 192.168.0.0/16
set 198.18.0.0/15
set 224.0.0.0/3
set 255.255.255.255/32
exit
edit policy-options prefix-list PL-INFRA
set 150.1.1.0/24
set 150.1.12.0/24
set 150.1.13.0/24
set 150.1.23.0/24
set 150.1.24.0/24
set 150.1.35.0/24
set 150.1.45.0/24
set 150.1.46.0/24
set 150.1.56.0/24
exit
edit policy-options prefix-list PL-LOCAL-LINKS
set apply-path "interfaces <*> family inet address <*>"

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
120
121 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

exit
edit policy-options prefix-list PL-BGP-NEIGHBOURS
set apply-path "protocols bgp group <*> neighbor <*>"
exit
edit firewall policer 10M
set if-exceeding bandwidth-limit 10m burst 1024k
set then discard
exit

R1
!
set interface ge-0/0/4.100 family inet filter input ACL-OUTSIDE-IN
set interface ge-0/0/4.119 family inet filter input ACL-OUTSIDE-IN
set interface ge-0/0/4.120 family inet filter input ACL-OUTSIDE-IN

R2
!
set interface ge-0/0/4.101 family inet filter input ACL-OUTSIDE-IN
set interface ge-0/0/4.123 family inet filter input ACL-OUTSIDE-IN

R4
!
set interface ge-0/0/4.105 family inet filter input ACL-OUTSIDE-IN

R5
!
set interface ge-0/0/4.113 family inet filter input ACL-OUTSIDE-IN
set interface ge-0/0/6.0 family inet filter input ACL-OUTSIDE-IN

R6
!
set interface ge-0/0/4.106 family inet filter input ACL-OUTSIDE-IN
set interface ge-0/0/4.131 family inet filter input ACL-OUTSIDE-IN
set interface ge-0/0/6.0 family inet filter input ACL-OUTSIDE-IN

Task 6 (1 point). Configure all routers so that they can utilise equal-cost paths on the data plane.
R1,R2,R3,R4,R5,R6,R7,R8
!
set policy-options policy-statement ECMP term ECMP then load-balance per-packet
set routing-options forwarding-table export ECMP

Verification
Task 1. System configuration should be annotated as below. Perform the same command on all routers
R1->R8 to ensure annotation is put in all routers’ configuration.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

lab@VMX-R2> show configuration | find "Config made"
/* Config made by Tony Tuan Nguyen, 2017-01-16 */
system {
<snip-for-brevity>
}

Task 2. LACP port bundling should come up as below, i.e. both ports show ‘distributing’ state and
‘Active’ participation. Perform the same command on all routers R1->R8 to check LACP operations
across all LAGs. By default, the LACP actor and partner send LACP packets every second already but we
can explicitly configure that.
lab@VMX-R2> show lacp interfaces
Aggregated interface: ae0
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
ge-0/0/1 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/1 Partner No No Yes Yes Yes Yes Fast Active
ge-0/0/2 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/2 Partner No No Yes Yes Yes Yes Fast Active
LACP protocol: Receive State Transmit State Mux State
ge-0/0/1 Current Fast periodic Collecting distributing
ge-0/0/2 Current Fast periodic Collecting distributing

lab@VMX-R6> show lacp interfaces

Aggregated interface: ae0
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
121
122 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

ge-0/0/1 Actor No No Yes Yes Yes Yes Fast Active

ge-0/0/1 Partner No No Yes Yes Yes Yes Fast Active
ge-0/0/2 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/2 Partner No No Yes Yes Yes Yes Fast Active
LACP protocol: Receive State Transmit State Mux State
ge-0/0/1 Current Fast periodic Collecting distributing
ge-0/0/2 Current Fast periodic Collecting distributing

lab@VMX-R8> show lacp interfaces

Task 3. To direct syslog messages to a remote server, we would need to use keyword host in system
syslog stanza. If you could set up a syslog server on address 10.10.1.88, you should be able to see syslog
messages coming in from all routers R1->R6. In each directed syslog message, after the timestamp there
is hostname of the source router that generates the message to allow the administrator of the server to
identify where the syslog message comes from.

Task 4. The default address that JUNOS uses as the source for all locally generated IP packets are the
primary address of outgoing interfaces. However we can generalise it to be loopback0 address with
statement default-address-selection. As can be seen from the SSH below from R2 to R1, the source
that R2 uses is its lo0. Note that if you have not completed IGP section, this probably won’t work as the
R1 would not have the route back to network of R2’s lo0 interface.
lab@VMX-R2> ssh [email protected]
Password:
--- JUNOS 14.1-20140130_ib_14_1_psd.0 built 2014-01-30 05:34:04 UTC
lab@VMX-R1> show system users
12:35AM up 3 days, 6:02, 1 user, load averages: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE WHAT
lab pts/0 10.10.1.254 12:30PM 3 -cli (cli)
lab p0 150.1.1.2 12:35AM - -cli (cli)

As a security best practice, we should not allow root access anywhere apart from the console. We can

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

test this out by using username root, the system should reject any non-console access using such
username.
lab@VMX-R2> ssh [email protected]
Password:
Password:
Password:
Received disconnect from 150.1.12.1: 2: Too many password failures for root

By default, configuration file is not compressed and stored in the file juniper.conf, in the /config file
system, along with the last three committed versions of the configuration. However with large networks
with long configurations the file might exceed the available space in the /config file system.
Compressing the configuration file allows the file to fit in the file system, typically reducing the size of
the file roughly by 90%. If you could set up a FTP server on address 10.10.1.99 with the specified
username and password, you should be able to see the configuration files that R1->R6 send to after
each commit command is made.
lab@VMX-R2> show log messages | match fetch
Oct 18 13:51:00 cfmd[3324]: cfmd_chassis_mac_addr_init:631 Done fetching reserved mac
address. Going past mac-address init

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
122
123 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Apr 21 21:59:46 vMX2 cfmd[3147]: cfmd_chassis_mac_addr_init:631 Done fetching reserved

mac address. Going past mac-address init
Apr 21 23:00:37 VMX-R2 fetch: fetch-secure: ftp://admin:*@10.10.1.99/VMX-
R2_20170421_225838_juniper.conf.gz: Operation timed out

Task 5. RFCs 1918, 3330, 5735, and 6598 define specific IP address ranges which are used for special
purpose rather than regular routing over the Internet. Such ranges are referred as ‘bogon’ addresses.
Best practices indicate that we should drop Internet traffic sourcing from those ranges completely. Also
we should limit the rate of ICMP packets to avoid certain flood attacks that could overwhelm core links
while leaving some room for customers/peers performing ping test. Furthermore, we also should limit
reachability to infrastructure ranges of SP networks including all local addresses of router since there is
no need for external hosts to communicate with them. At the same time we need to make sure that BGP
sessions with external ASNs are allowed. We can verify the number of packets hitting each term of the
ACL and their size as below. You can generate test/synthetic traffic to ensure the ACL terms work as
expected.
lab@VMX-R2> show firewall filter ACL-OUTSIDE-IN

Filter: ACL-OUTSIDE-IN
Counters:
Name Bytes Packets
T1-BOGON-DISCARDED 0 0
T2-ICMP-POLICED 1388093 22554
T3-BGP-ALLOWED 1118347 18170
T4-INFRA-DISCARDED 0 0
T5-DEFAULT-ALLOWED 0 0
Policers:
Name Bytes Packets
10M-2 0

Topic 2: IGP
Total Points: 10

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

R2
!
edit protocols ospf area 0.0.0.0
set interface lo0.0 passive
set interface ge-0/0/6
set interface ge-0/0/8
exit

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
123
124 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

edit protocols ospf area 0.0.0.1

set interface ae0.0
exit
edit protocols ospf area 0.0.0.22
set interface ge-0/0/4.126
set nssa
exit

R3
!
edit protocols ospf area 0.0.0.0
set interface lo0.0 passive
set interface ge-0/0/7
set interface ge-0/0/8
exit
edit protocols ospf area 0.0.0.1
set interface ge-0/0/6
exit

R4
!
edit protocols ospf area 0.0.0.0
set interface lo0.0 passive
set interface ge-0/0/6
set interface ge-0/0/8
exit
edit protocols ospf area 0.0.0.6
set interface ge-0/0/7
exit
edit protocols ospf area 0.0.0.22
set interface ge-0/0/4.130
set nssa
exit

R5
!
edit protocols ospf area 0.0.0.0
set interface lo0.0 passive
set interface ge-0/0/7
set interface ge-0/0/8
exit
edit protocols ospf area 0.0.0.6
set interface ae0.0
exit

R6
!
edit protocols ospf area 0.0.0.6
set interface lo0.0 passive
set interface ae0.0

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

set interface ge-0/0/7
exit

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
124
125 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

R1,R2,R3,R4,R5,R6,R7,R8
!
set protocols ospf reference-bandwidth 100g
edit group OSPF-INTERFACES
set protocols ospf area <*> interface <*> interface-type p2p
set protocols ospf area <*> interface <*> bfd minimum-interval 250 multiplier 4
set protocols ospf area <*> interface <*> authentication md5 1 key JNCIE
set protocols ospf area <*> interface <*> link-protection
exit
set apply-group OSPF-INTERFACES

R2,R4
!
set protocols ospf area 0.0.0.22 apply-groups-except OSPF-INTERFACES

Verification
Tasks 1 and 2. OSPFv2 should come up within Service Provider Networks 1 and 2, verified as below on
R1, R3 and R7 for example:
lab@VMX-R1> show ospf neighbor
Address Interface State ID Pri Dead
150.1.12.2 ae0.0 Full 150.1.1.2 128 33
150.1.13.3 ge-0/0/6.0 Full 150.1.1.3 128 34

lab@VMX-R2> show ospf neighbor

Address Interface State ID Pri Dead
150.1.24.4 ge-0/0/6.0 Full 150.1.1.4 128 39
150.1.23.3 ge-0/0/8.0 Full 150.1.1.3 128 39
150.1.12.1 ae0.0 Full 150.1.1.1 128 39
150.1.126.2 ge-0/0/4.126 Full 150.1.126.2 128 39

lab@VMX-R3> show ospf neighbor

Address Interface State ID Pri Dead
150.1.35.5 ge-0/0/7.0 Full 150.1.1.5 128 34
150.1.23.2 ge-0/0/8.0 Full 150.1.1.2 128 34
150.1.13.1 ge-0/0/6.0 Full 150.1.1.1 128 36

lab@VMX-R4> show ospf neighbor

Address Interface State ID Pri Dead
150.1.24.2 ge-0/0/6.0 Full 150.1.1.2 128 31
150.1.45.5 ge-0/0/8.0 Full 150.1.1.5 128 32
150.1.46.6 ge-0/0/7.0 Full 150.1.1.6 128 36
150.1.130.2 ge-0/0/4.130 Full 150.1.126.2 128 30

lab@VMX-R5> show ospf neighbor

Address Interface State ID Pri Dead
150.1.35.3 ge-0/0/7.0 Full 150.1.1.3 128 36

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

150.1.45.4 ge-0/0/8.0 Full 150.1.1.4 128 32
150.1.56.6 ae0.0 Full 150.1.1.6 128 33

lab@VMX-R6> show ospf neighbor

Address Interface State ID Pri Dead
150.1.56.5 ae0.0 Full 150.1.1.5 128 35
150.1.46.4 ge-0/0/7.0 Full 150.1.1.4 128 38

lab@VMX-R7> show ospf neighbor

Address Interface State ID Pri Dead
151.1.78.8 ae0.0 Full 151.1.1.8 128 39

lab@VMX-R8> show ospf neighbor

Address Interface State ID Pri Dead
151.1.78.7 ae0.0 Full 151.1.1.7 128 32

lab@VMX-R1> show ospf interface

Interface State Area DR ID BDR ID Nbrs
ae0.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1
ge-0/0/6.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1

lab@VMX-R3> show ospf interface

Interface State Area DR ID BDR ID Nbrs
ge-0/0/7.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
ge-0/0/8.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
ge-0/0/6.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1

lab@VMX-R7> show ospf interface

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
125
126 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Interface State Area DR ID BDR ID Nbrs

ae0.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1

This task requires that area 0.0.0.22 does not accept external prefixes (LSA Type 5) from area 0.0.0.0 but
can inject those in the opposite direction. This implies that area 0.0.0.22 needs to operate as a NSSA
area which behaves like a Stub area but allows for the existence of an ASBR router inside. Two
interesting parts related to NSSA area are that 1) external prefixes are redistributed into NSSA area as
LSAs Type 7, as can be seen below for 10 prefixes injected by DC2 being ASBR.
lab@VMX-R2> show ospf database area 0.0.0.22 | match NSSA
NSSA 150.1.90.0 150.1.90.1 0x80000085 94 0x28 0x29ff 36
NSSA 150.1.91.0 150.1.90.1 0x80000084 2821 0x28 0x2009 36
NSSA 150.1.92.0 150.1.90.1 0x80000084 2548 0x28 0x1513 36
NSSA 150.1.93.0 150.1.90.1 0x80000084 2003 0x28 0xa1d 36
NSSA 150.1.94.0 150.1.90.1 0x80000084 1730 0x28 0xfe27 36
NSSA 150.1.95.0 150.1.90.1 0x80000084 1458 0x28 0xf331 36
NSSA 150.1.96.0 150.1.90.1 0x80000084 1185 0x28 0xe83b 36
NSSA 150.1.97.0 150.1.90.1 0x80000084 912 0x28 0xdd45 36
NSSA 150.1.98.0 150.1.90.1 0x80000084 640 0x28 0xd24f 36
NSSA 150.1.99.0 150.1.90.1 0x80000084 367 0x28 0xc759 36

And 2) when these external prefixes are advertised into area 0.0.0.0, they will be translated into LSA
Type 5 without LSA Type 4 generated (as usual). Also if the NSSA area has got multiple ABR routers
(being R2 and R4), only the ABR that has got higher router-ID will perform the translation. In this case it
is R4.
lab@VMX-R3> show ospf database area 0.0.0.0 | match Extern
Extern 150.1.90.0 150.1.1.4 0x8000000e 1899 0x22 0xed11 36
Extern 150.1.91.0 150.1.1.4 0x8000000e 1842 0x22 0xe21b 36
Extern 150.1.92.0 150.1.1.4 0x8000000e 1786 0x22 0xd725 36
Extern 150.1.93.0 150.1.1.4 0x8000000e 1673 0x22 0xcc2f 36
Extern 150.1.94.0 150.1.1.4 0x8000000e 1616 0x22 0xc139 36
Extern 150.1.95.0 150.1.1.4 0x8000000e 1559 0x22 0xb643 36
Extern 150.1.96.0 150.1.1.4 0x8000000e 1503 0x22 0xab4d 36
Extern 150.1.97.0 150.1.1.4 0x8000000e 1446 0x22 0xa057 36
Extern 150.1.98.0 150.1.1.4 0x8000000e 1390 0x22 0x9561 36
Extern 150.1.99.0 150.1.1.4 0x8000000e 1333 0x22 0x8a6b 36

lab@VMX-R3> show ospf database area 0.0.0.0 | match ASBR | count

Count: 0 lines

By default, OSPF cost is derived from a reference bandwidth value which is equivalent to 1Gbps,

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

therefore OSPF cannot distinguish between a 1G interface or any interface that has got speed higher
than 1G. In this case you can configure the reference bandwidth to be anything higher than the default
value of 1G.
lab@VMX-R2> show ospf interface detail area 0.0.0.1
Interface State Area DR ID BDR ID Nbrs
ae0.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1
Type: P2P, Address: 150.1.12.2, Mask: 255.255.255.0, MTU: 1500, Cost: 50
Adj count: 1
Hello: 10, Dead: 40, ReXmit: 5, Not Stub
Auth type: MD5, Active key ID: 1, Start time: 1969 Dec 31 16:00:00 PST
Protection type: Link
Topology default (ID 0) -> Cost: 50

lab@VMX-R2> show ospf interface detail area 0.0.0.0

Interface State Area DR ID BDR ID Nbrs
ge-0/0/6.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Type: P2P, Address: 150.1.24.2, Mask: 255.255.255.0, MTU: 1500, Cost: 100
Adj count: 1
Hello: 10, Dead: 40, ReXmit: 5, Not Stub
Auth type: MD5, Active key ID: 1, Start time: 1969 Dec 31 16:00:00 PST
Protection type: Link
Topology default (ID 0) -> Cost: 100
<snip>

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
126
127 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Task 3. In this task it has been asked to use the most efficient method to configure multiple features
related to OSPF interfaces, so we use a group OSPF-INTERFACES that activates those features to all OSPF
interfaces with statement set protocols ospf area <*> interface <*>. This way we also ensure
configuration consistency across a lot of interfaces without worrying about whether their specific details
are coherent or not. The point-to-point interface type would have remove unnecessary DR, BDR election
on every Ethernet interface that has got only 2 neighbours, reducing establishment time for OSPF
neighbourship. The BFD would verify bidirectional connectivity and help OSPF detect failure in a sub-
second manner.
lab@VMX-R3> show bfd session
Detect Transmit
Address State Interface Time Interval Multiplier
<snip>
150.1.13.1 Up ge-0/0/6.0 1.000 0.250 4
150.1.23.2 Up ge-0/0/8.0 1.000 0.250 4
150.1.35.5 Up ge-0/0/7.0 1.000 0.250 4
<snip>

lab@VMX-R3> show ospf interface extensive | match "0.0.0.0|Auth"

ge-0/0/7.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Auth type: MD5, Active key ID: 1, Start time: 1969 Dec 31 16:00:00 PST
ge-0/0/8.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Auth type: MD5, Active key ID: 1, Start time: 1969 Dec 31 16:00:00 PST
lo0.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 0
Auth type: MD5, Active key ID: 1, Start time: 1969 Dec 31 16:00:00 PST
lo0.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 0
Auth type: MD5, Active key ID: 1, Start time: 1969 Dec 31 16:00:00 PST
ge-0/0/6.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1
Auth type: MD5, Active key ID: 1, Start time: 1969 Dec 31 16:00:00 PST

An interesting part of this task is about enabling OSPF LFA capability with statement link-protection
which activates the operation of a second SPF calculation which provides alternate paths for OSPF
prefixes. These alternate paths are loop free and can be used immediately upon failure of the primary
paths. The concept of OSPF LFA feature is somewhat similar to EIGRP feasible successor mechanism.
OSPF LFA will build alternate paths for each OSPF area individually just like SPF computation for
different LSDBs.
lab@VMX-R2> show ospf backup coverage
Topology default coverage:

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

Node Coverage:

Area Covered Total Percent

Nodes Nodes Covered
0.0.0.0 1 3 33.33%
0.0.0.1 0 0 100.00%
0.0.0.22 0 2 0.00%

Route Coverage:

Path Type Covered Total Percent

Routes Routes Covered
Intra 1 10 10.00%
Inter 1 6 16.67%
Ext1 0 0 100.00%
Ext2 0 10 0.00%
All 2 26 7.69%

Best practices indicate when configuring LFA, a “per-packet” load-balancing routing policy should be
configured to ensure that OSPF process installs all next hops for a given route in the routing table.
However this has been configured in topic 1, task 6 already hence we do not need to repeat it here. At
the end of this topic, we should verify reachability within Service Provider Networks 1 and 2, particularly
between loopback interfaces of the routers as it would be instrumental for the upcoming tasks.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
127
128 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

lab@VMX-R1> ping rapid source 150.1.1.1 150.1.1.2

PING 150.1.1.2 (150.1.1.2): 56 data bytes
!!!!!
--- 150.1.1.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 7.742/9.555/10.478/0.973 ms

lab@VMX-R1> ping rapid source 150.1.1.1 150.1.1.3

PING 150.1.1.3 (150.1.1.3): 56 data bytes
!!!!!
--- 150.1.1.3 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 9.635/10.021/10.235/0.231 ms

lab@VMX-R1> ping rapid source 150.1.1.1 150.1.1.4

PING 150.1.1.4 (150.1.1.4): 56 data bytes
!!!!!
--- 150.1.1.4 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 14.812/15.015/15.186/0.140 ms

lab@VMX-R1> ping rapid source 150.1.1.1 150.1.1.5

PING 150.1.1.5 (150.1.1.5): 56 data bytes
!!!!!
--- 150.1.1.5 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 9.626/15.031/20.133/3.329 ms

lab@VMX-R1> ping rapid source 150.1.1.1 150.1.1.6

PING 150.1.1.6 (150.1.1.6): 56 data bytes
!!!!!
--- 150.1.1.6 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 14.657/19.019/25.110/3.752 ms

lab@VMX-R1> ping rapid source 150.1.1.1 150.1.90.1

PING 150.1.90.1 (150.1.90.1): 56 data bytes
!!!!!
--- 150.1.90.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 13.816/15.002/15.736/0.648 ms

lab@VMX-R1> ping rapid source 150.1.1.1 150.1.99.1

PING 150.1.99.1 (150.1.99.1): 56 data bytes
!!!!!
--- 150.1.99.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 14.749/15.036/15.387/0.239 ms

lab@VMX-R7> ping rapid source 151.1.1.7 151.1.1.8

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

PING 151.1.1.8 (151.1.1.8): 56 data bytes
!!!!!
--- 151.1.1.8 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 9.579/9.980/10.362/0.263 ms

Topic 3: MPLS
Total Points: 20

Task 1 (2 points). Configure OSPFv2 to build TE database for Service Provider Networks 1 and 2; ensure
the tail-end router is the one who removes MPLS stack instead of the penultimate router. For Service
Provider Network 2, enable LDP as the signalling protocol between R7 and R8. Disable MPLS on the OOB
management interface.
R1,R2,R3,R4,R5,R6
!
set protocols ospf traffic-engineering
set protocols mpls interface all
set protocols mpls interface fxp0.0 disable
set protocols mpls explicit-null
set groups ALL-INTERFACES interfaces <*> unit <*> family mpls
set apply-groups ALL-INTERFACES

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
128
129 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

R7,R8
!
set protocols ospf traffic-engineering
set protocols mpls interface all
set protocols mpls interface fxp0.0 disable
set protocols ldp interface ae0.0
set protocols ldp explicit-null
set groups ALL-INTERFACES interfaces <*> unit <*> family mpls
set apply-groups ALL-INTERFACES

Task 2 (8 points). Configure full-mesh RSVP-signaled LSPs between all routers of Service Provider
Network 1, ensure big chunks of traffic between each pair of routers can be broken into smaller portions
to be fit across the network paths. All LSPs should be re-routed within tens of milliseconds upon failure
of any node within the core networks; all LSPs should be monitored and optimised for better path every
1 hour and ensure that the newly optimised path is established before old path is torn down for
reoptimisation activities. Log the events of LSP up and down into syslog. Bidirectional forwarding
capability of each LSP should be verified and signalled within 1 second. Please use the most efficient
configuration method to group common attributes of LSPs.
R1,R2,R3,R4,R5,R6
!
set protocols rsvp interface all link-protection
set protocols mpls expand-loose-hop
set protocols mpls log-updown syslog
!
edit groups LSP-GROUP-CORE protocols mpls label-switched-path <*>
set node-link-protection
set optimize-timer 3600
set adaptive
set oam bfd minimum-interval 250 multiplier 4
exit
set apply-groups LSP-GROUP-CORE
set interface lo0 unit 0 family inet address 127.0.0.1/32

R1
!
edit protocols mpls
set label-switched-path R1-TO-R2-TUN1 to 150.1.1.2
set label-switched-path R1-TO-R2-TUN2 to 150.1.1.2
set label-switched-path R1-TO-R3-TUN1 to 150.1.1.3
set label-switched-path R1-TO-R3-TUN2 to 150.1.1.3
set label-switched-path R1-TO-R4-TUN1 to 150.1.1.4 inter-domain
set label-switched-path R1-TO-R4-TUN2 to 150.1.1.4 inter-domain

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

set label-switched-path R1-TO-R5-TUN1 to 150.1.1.5 inter-domain
set label-switched-path R1-TO-R5-TUN2 to 150.1.1.5 inter-domain
set label-switched-path R1-TO-R6-TUN1 to 150.1.1.6 inter-domain
set label-switched-path R1-TO-R6-TUN2 to 150.1.1.6 inter-domain
exit

R2
!
edit protocols mpls
set label-switched-path R2-TO-R1-TUN1 to 150.1.1.1
set label-switched-path R2-TO-R1-TUN2 to 150.1.1.1
set label-switched-path R2-TO-R3-TUN1 to 150.1.1.3
set label-switched-path R2-TO-R3-TUN2 to 150.1.1.3
set label-switched-path R2-TO-R4-TUN1 to 150.1.1.4
set label-switched-path R2-TO-R4-TUN2 to 150.1.1.4
set label-switched-path R2-TO-R5-TUN1 to 150.1.1.5
set label-switched-path R2-TO-R5-TUN2 to 150.1.1.5
set label-switched-path R2-TO-R6-TUN1 to 150.1.1.6 inter-domain
set label-switched-path R2-TO-R6-TUN2 to 150.1.1.6 inter-domain
exit

R3
!
edit protocols mpls
set label-switched-path R3-TO-R1-TUN1 to 150.1.1.1
set label-switched-path R3-TO-R1-TUN2 to 150.1.1.1
set label-switched-path R3-TO-R2-TUN1 to 150.1.1.2

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
129
130 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set label-switched-path R3-TO-R2-TUN2 to 150.1.1.2

set label-switched-path R3-TO-R4-TUN1 to 150.1.1.4
set label-switched-path R3-TO-R4-TUN2 to 150.1.1.4
set label-switched-path R3-TO-R5-TUN1 to 150.1.1.5
set label-switched-path R3-TO-R5-TUN2 to 150.1.1.5
set label-switched-path R3-TO-R6-TUN1 to 150.1.1.6 inter-domain
set label-switched-path R3-TO-R6-TUN2 to 150.1.1.6 inter-domain
exit

R4
!
edit protocols mpls
set label-switched-path R4-TO-R1-TUN1 to 150.1.1.1 inter-domain
set label-switched-path R4-TO-R1-TUN2 to 150.1.1.1 inter-domain
set label-switched-path R4-TO-R2-TUN1 to 150.1.1.2
set label-switched-path R4-TO-R2-TUN2 to 150.1.1.2
set label-switched-path R4-TO-R3-TUN1 to 150.1.1.3
set label-switched-path R4-TO-R3-TUN2 to 150.1.1.3
set label-switched-path R4-TO-R5-TUN1 to 150.1.1.5
set label-switched-path R4-TO-R5-TUN2 to 150.1.1.5
set label-switched-path R4-TO-R6-TUN1 to 150.1.1.6
set label-switched-path R4-TO-R6-TUN2 to 150.1.1.6
exit

R5
!
edit protocols mpls
set label-switched-path R5-TO-R1-TUN1 to 150.1.1.1 inter-domain
set label-switched-path R5-TO-R1-TUN2 to 150.1.1.1 inter-domain
set label-switched-path R5-TO-R2-TUN1 to 150.1.1.2
set label-switched-path R5-TO-R2-TUN2 to 150.1.1.2
set label-switched-path R5-TO-R3-TUN1 to 150.1.1.3
set label-switched-path R5-TO-R3-TUN2 to 150.1.1.3
set label-switched-path R5-TO-R4-TUN1 to 150.1.1.4
set label-switched-path R5-TO-R4-TUN2 to 150.1.1.4
set label-switched-path R5-TO-R6-TUN1 to 150.1.1.6
set label-switched-path R5-TO-R6-TUN2 to 150.1.1.6
exit

R6
!
edit protocols mpls
set label-switched-path R6-TO-R1-TUN1 to 150.1.1.1 inter-domain
set label-switched-path R6-TO-R1-TUN2 to 150.1.1.1 inter-domain
set label-switched-path R6-TO-R2-TUN1 to 150.1.1.2 inter-domain
set label-switched-path R6-TO-R2-TUN2 to 150.1.1.2 inter-domain
set label-switched-path R6-TO-R3-TUN1 to 150.1.1.3 inter-domain
set label-switched-path R6-TO-R3-TUN2 to 150.1.1.3 inter-domain
set label-switched-path R6-TO-R4-TUN1 to 150.1.1.4
set label-switched-path R6-TO-R4-TUN2 to 150.1.1.4

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

set label-switched-path R6-TO-R5-TUN1 to 150.1.1.5
set label-switched-path R6-TO-R5-TUN2 to 150.1.1.5
exit

Task 3 (3 points). Configure all LSPs that their bandwidth utilisation is monitored and adjusted every 1
hour, the adjustment should be contained within range of 50Mbps and 200Mbps. The statistics of
bandwidth utilisation should be recorded every 10 minutes into files called autobw.log for diagnostic
purpose. Please do not record statistics of transit LSPs. Also ensure that the path that each LSP chooses
is the one that concurrently has lowest bandwidth reserved by RSVP.
R1,R2,R3,R4,R5,R6
!
edit groups LSP-GROUP-CORE protocols mpls label-switched-path <*>
set auto-bandwidth adjust-interval 3600 minimum-bandwidth 50m maximum-bandwidth 200m
set least-fill
exit
edit protocols mpls statistics
set file autobw.log size 1m files 10
set interval 600
set auto-bandwidth
set no-transit-statistics
exit

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
130
131 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Task 4 (3 points). Configure all routers such that they concatenate RSVP messages and explicitly require
acknowledgement for them. Allow only up to 90% of link bandwidth to be reservable. Moreover, they
should trigger an immediate reservation update via OSPF LSA Type 10 when the current reported usage
of LSA is different from the actual RSVP reservation by an amount that is less than default threshold.

R1,R2,R3,R4,R5,R6
!
set protocols rsvp interface all aggregate
set protocols rsvp interface all reliable
set protocols rsvp interface all subscription 90
set protocols rsvp interface all update-threshold 5

Verification
Task 1. Once OSPF is enabled with TE extension, it generates and propagates Opaque LSA to advertise
link attributes throughout the OSPF domain in addition to the regular cost value. The attributes include
values such as reservable bandwidth for RSVP, remaining bandwidth, etc. Another interesting part of
this practice lab is that there are multiple OSPF areas, hence there would be multiple TE databases (TE)
being created. And this behaviour does create some challenges for MPLS RSVP-signaled LSPs to be
formed which we will see in the upcoming task. As can be seen below, there are 3 TEDs for area 0.0.0.0,
area 0.0.0.6 and 0.0.0.22 on router R4.
lab@VMX-R4> show ospf database opaque-area

OSPF database, Area 0.0.0.0

Type ID Adv Rtr Seq Age Opt Cksum Len
OpaqArea 1.0.0.1 150.1.1.2 0x8000001a 1175 0x22 0xd60a 28
OpaqArea 1.0.0.1 150.1.1.3 0x8000001b 1852 0x22 0xd805 28

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

OpaqArea*1.0.0.1 150.1.1.4 0x8000001a 1250 0x22 0xdefd 28
OpaqArea 1.0.0.1 150.1.1.5 0x8000001b 418 0x22 0xe0f8 28
OpaqArea 1.0.0.3 150.1.1.2 0x80000024 128 0x22 0x540a 136
OpaqArea 1.0.0.3 150.1.1.3 0x80000024 52 0x22 0x6ddb 136
OpaqArea*1.0.0.3 150.1.1.4 0x80000021 2552 0x22 0xc5a3 136
OpaqArea 1.0.0.3 150.1.1.5 0x8000002a 298 0x22 0xc018 136
OpaqArea 1.0.0.4 150.1.1.2 0x80000020 547 0x22 0x9b65 136
OpaqArea 1.0.0.4 150.1.1.3 0x80000027 532 0x22 0x342f 136
OpaqArea*1.0.0.4 150.1.1.4 0x8000002b 174 0x22 0xd9e7 136
OpaqArea 1.0.0.4 150.1.1.5 0x80000024 58 0x22 0x1319 136

OSPF database, Area 0.0.0.6

Type ID Adv Rtr Seq Age Opt Cksum Len
OpaqArea*1.0.0.1 150.1.1.4 0x8000001a 1193 0x22 0xdefd 28
OpaqArea 1.0.0.1 150.1.1.5 0x8000001b 179 0x22 0xe0f8 28
OpaqArea 1.0.0.1 150.1.1.6 0x8000001c 2204 0x22 0xe2f3 28
OpaqArea*1.0.0.3 150.1.1.4 0x80000021 118 0x22 0x72c1 136
OpaqArea 1.0.0.3 150.1.1.5 0x8000001f 539 0x22 0xdaf2 136
OpaqArea 1.0.0.3 150.1.1.6 0x80000021 1454 0x22 0xe0b9 136
OpaqArea 1.0.0.4 150.1.1.6 0x80000024 704 0x22 0x6727 136

OSPF database, Area 0.0.0.22

Type ID Adv Rtr Seq Age Opt Cksum Len
OpaqArea 1.0.0.1 150.1.1.2 0x800000a6 1036 0x20 0xdb7a 28
OpaqArea*1.0.0.1 150.1.1.4 0x800000a5 1137 0x20 0xe56d 28
OpaqArea 1.0.0.3 150.1.1.2 0x800000a8 966 0x20 0xac10 136
OpaqArea*1.0.0.3 150.1.1.4 0x800000a9 910 0x20 0xfdb7 136

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
131
132 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Furthermore, we need to enable MPLS and ensure PHP (penultimate-hop-popping) behaviour is disabled
where the last hop removes MPLS stack (or topmost label) instead of the hop before it. This design
facilitates certain MPLS QoS implementations where we would need to retain the MPLS stack until the
last hop for proper classification and/or queueing on the egress. In order to disable PHP behaviour, we
use explicit-null statement under protocols mpls stanza which has effect on RSVP-signaled LSP.
According to RFC3032 when disabling PHP, label 0 is advertised by the last hop instead of label 3 to
signal the penultimate hop that it wishes to retain MPLS label stack. There is a detailed explanation
http://www.juniper.net/documentation/en_US/junos12.3/topics/task/configuration/mpls-ultimate-
hop-popping-enabling.html for the the impact of disabling PHP in JUNOS.

For simplicity Service Provider Network 2 only uses LDP as the signalling protocol, we should verify LDP
neighbourship and label binding database.

lab@VMX-R7> show ldp neighbor

Address Interface Label space ID Hold time
151.1.78.8 ae0.0 151.1.1.8:0 14

lab@VMX-R7> show ldp database

Input label database, 151.1.1.7:0--151.1.1.8:0
Label Prefix
299776 151.1.1.7/32
0 151.1.1.8/32

Output label database, 151.1.1.7:0--151.1.1.8:0

Label Prefix
0 151.1.1.7/32
299776 151.1.1.8/32

Task 2. This task requires you to configure a full-mesh system of RSVP-signalled LSPs between the
routers in Service Provider Network 1, let’s quickly see if they are all up and running before we discuss
their characteristics. Below is the output on R1, R3 and R5, you should perform the same check on R2,
R4 and R6 using the same command.
lab@VMX-R1> show mpls lsp ingress
Ingress LSP: 12 sessions
To From State Rt P ActivePath LSPname
150.1.1.2 150.1.1.1 Up 0 * R1-TO-R2-TUN1
150.1.1.2 150.1.1.1 Up 0 * R1-TO-R2-TUN2
150.1.1.3 150.1.1.1 Up 0 * R1-TO-R3-TUN1

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

150.1.1.3 150.1.1.1 Up 0 * R1-TO-R3-TUN2
150.1.1.4 150.1.1.1 Up 0 * R1-TO-R4-TUN1
150.1.1.4 150.1.1.1 Up 0 * R1-TO-R4-TUN2
150.1.1.5 150.1.1.1 Up 0 * R1-TO-R5-TUN1
150.1.1.5 150.1.1.1 Up 0 * R1-TO-R5-TUN2
150.1.1.6 150.1.1.1 Up 0 * R1-TO-R6-TUN1
150.1.1.6 150.1.1.1 Up 0 * R1-TO-R6-TUN2
150.1.1.6 150.1.1.1 Up 0 * R1-TO-R6-TUN3
150.1.1.6 150.1.1.1 Up 0 * R1-TO-R6-TUN4
Total 12 displayed, Up 12, Down 0

lab@VMX-R3> show mpls lsp ingress

Ingress LSP: 10 sessions
To From State Rt P ActivePath LSPname
150.1.1.1 150.1.1.3 Up 0 * R3-TO-R1-TUN1
150.1.1.1 150.1.1.3 Up 0 * R3-TO-R1-TUN2
150.1.1.2 150.1.1.3 Up 0 * R3-TO-R2-TUN1
150.1.1.2 150.1.1.3 Up 0 * R3-TO-R2-TUN2
150.1.1.4 150.1.1.3 Up 0 * R3-TO-R4-TUN1
150.1.1.4 150.1.1.3 Up 0 * R3-TO-R4-TUN2
150.1.1.5 150.1.1.3 Up 0 * R3-TO-R5-TUN1
150.1.1.5 150.1.1.3 Up 0 * R3-TO-R5-TUN2
150.1.1.6 150.1.1.3 Up 0 * R3-TO-R6-TUN1
150.1.1.6 150.1.1.3 Up 0 * R3-TO-R6-TUN2
Total 10 displayed, Up 10, Down 0

lab@VMX-R5> show mpls lsp ingress

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
132
133 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Ingress LSP: 10 sessions

To From State Rt P ActivePath LSPname
150.1.1.1 150.1.1.5 Up 0 * R5-TO-R1-TUN1
150.1.1.1 150.1.1.5 Up 0 * R5-TO-R1-TUN2
150.1.1.2 150.1.1.5 Up 0 * R5-TO-R2-TUN1
150.1.1.2 150.1.1.5 Up 0 * R5-TO-R2-TUN2
150.1.1.3 150.1.1.5 Up 0 * R5-TO-R3-TUN1
150.1.1.3 150.1.1.5 Up 0 * R5-TO-R3-TUN2
150.1.1.4 150.1.1.5 Up 0 * R5-TO-R4-TUN1
150.1.1.4 150.1.1.5 Up 0 * R5-TO-R4-TUN2
150.1.1.6 150.1.1.5 Up 0 * R5-TO-R6-TUN1
150.1.1.6 150.1.1.5 Up 0 * R5-TO-R6-TUN2
Total 10 displayed, Up 10, Down 0

Now let’s sequentially discuss three interesting parts of this tasks which would probably make things
convoluted a little bit, being 1) inter-area MPLS RSVP, 2) parallel MPLS RSVP-signalled LSPs, 3) MPLS
OAM with BFD.

For the first point, from task 1 we know that we now have multiple TEDs corresponding to OSPF areas
and really routers will perform separate CSPF computations for each area. Therefore if we configure
things normally, the LSPs that need to traverse across area border will not come up, for example LSPs
between R1 and R6 will need to traverse 3 different areas being 0.0.0.1, 0.0.0.0 and 0.0.0.22. Therefore
we would need to enable inter-area function of MPLS RSVP that JUNOS provides with statement expand-
loose-hop at the global MPLS configuration stanza, combined with statement inter-domain at LSP level.
The function allows for selecting a node which is not in the same area to be LSP egress endpoint.
lab@VMX-R1> show mpls lsp name R1-TO-R6-TUN1 extensive | match "state|domain"
From: 150.1.1.1, State: Up, ActiveRoute: 0, LSPname: R1-TO-R6-TUN1
PathDomain: Inter-domain
*Primary State: Up, No-decrement-ttl
OAM state : BFD session up LSP-ping up

For the second point, JUNOS actually allows for configuring multiple LSPs in parallel between a same
pair of MPLS nodes, theoretically we can configure an unlimited number for that but best practices
indicate that there should be no more than 8 LSPs. The intention is to allow for load-sharing traffic
between the two MPLS nodes across parallel LSPs; this will break a big chunk of traffic into multiple
smaller streams and bring about a benefit that there are more chances that these smaller streams can
fit into the network rather than a big giant stream. Also multiple LSPs can traverse different paths on the

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

network, creating diversity and reduce impact when failure happens, i.e. we would be unlikely to lose all
traffic between the pair of MPLS nodes at one time. For demonstration purpose, this task requires
configuration of at least 2 LSPs for each destination MPLS node.
lab@VMX-R1> show mpls lsp name R1-TO-R6-TUN1 extensive | find "Received RRO"
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-
ID):
150.1.1.2(flag=0x29) 150.1.12.2(flag=9 Label=300656) 150.1.1.4(flag=0x21)
150.1.24.4(flag=1 Label=300544) 150.1.1.6(flag=0x20) 150.1.46.6(Label=0)
<snip>

lab@VMX-R1> show mpls lsp name R1-TO-R6-TUN2 extensive | find "Received RRO"
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-
ID):
150.1.1.3(flag=0x29) 150.1.13.3(flag=9 Label=300512) 150.1.1.5(flag=0x21)
150.1.35.5(flag=1 Label=300560) 150.1.1.6(flag=0x20) 150.1.56.6(Label=0)
<snip>

Mostly, nowadays we need to statically configure those LSPs, but some later developments of Juniper
such as TE++ actually allows for dynamically creating ‘sub-LSPs’ based on traffic profile of the main LSP.
Ref: https://www.juniper.net/techpubs/en_US/northstar1.0.0/topics/concept/te-label-switched-paths-
overview.html

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
133
134 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

For the third point, MPLS OAM in which we can leverage BFD to actually check two-way forwarding
capability between the endpoint of the LSP. This requires the configuration of local address 127.0.0.1/32
on the loopback0 interfaces and the statement oam at LSP level. BFD aids in the detection of link/node
failures within MPLS domain and can help accelerate the switchover to the backup paths. Let’s verify
this point as below. We can see that alongside the BFD sessions enabled for OSPF earlier at the physical
interface level, there are now multi-hop BFD sessions between loopback0 interfaces of MPLS nodes as
the result of MPLS OAM.
lab@VMX-R1> show mpls lsp name R1-TO-R6-TUN1 extensive | match OAM
OAM state : BFD session up LSP-ping up

lab@VMX-R1> show bfd session

Detect Transmit
Address State Interface Time Interval Multiplier
127.0.0.1 Up ae0.0 0.750 0.250 4
127.0.0.1 Up ae0.0 0.750 0.250 4
127.0.0.1 Up ae0.0 0.750 0.250 4
127.0.0.1 Up ae0.0 0.750 0.250 4
127.0.0.1 Up ge-0/0/6.0 0.750 0.250 4
127.0.0.1 Up ae0.0 0.750 0.250 4
127.0.0.1 Up ge-0/0/6.0 0.750 0.250 4
127.0.0.1 Up ge-0/0/6.0 0.750 0.250 4
127.0.0.1 Up ae0.0 0.750 0.250 4
127.0.0.1 Up ae0.0 0.750 0.250 4
150.1.1.2 Up 1.000 0.250 3
150.1.1.2 Up 1.000 0.250 3
150.1.1.3 Up 1.000 0.250 3
150.1.1.3 Up 1.000 0.250 3
150.1.1.3 Up 1.000 0.250 4
150.1.1.4 Up 1.000 0.250 3
150.1.1.4 Up 1.000 0.250 3
150.1.1.4 Up 1.000 0.250 4
150.1.1.5 Up 1.000 0.250 3
150.1.1.5 Up 1.000 0.250 3
150.1.1.6 Up 1.000 0.250 3
150.1.1.6 Up 1.000 0.250 3
150.1.12.2 Up ae0.0 1.000 0.250 4
150.1.13.3 Up ge-0/0/6.0 1.000 0.250 4

lab@VMX-R1> show bfd session address 150.1.1.6 extensive

Detect Transmit
Address State Interface Time Interval Multiplier
150.1.1.6 Up 1.000 0.250 3
Client RSVP-OAM, TX interval 0.050, RX interval 0.050
Session up time 15:37:46

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

Local diagnostic None, remote diagnostic NbrSignal
Remote state Up, version 1
Min async interval 0.050, min slow interval 1.000
Adaptive async TX interval 0.050, RX interval 0.050
Local min TX interval 0.050, minimum RX interval 0.050, multiplier 3
Remote min TX interval 0.250, min RX interval 0.250, multiplier 4
Local discriminator 171, remote discriminator 175
Echo mode disabled/inactive
LSP-Name R6-TO-R1-TUN2
Egress

Detect Transmit
Address State Interface Time Interval Multiplier
150.1.1.6 Up 1.000 0.250 3
Client RSVP-OAM, TX interval 0.050, RX interval 0.050
Session up time 15:40:43
Local diagnostic None, remote diagnostic NbrSignal
Remote state Up, version 1
Min async interval 0.050, min slow interval 1.000
Adaptive async TX interval 0.050, RX interval 0.050
Local min TX interval 0.050, minimum RX interval 0.050, multiplier 3
Remote min TX interval 0.250, min RX interval 0.250, multiplier 4
Local discriminator 151, remote discriminator 171
Echo mode disabled/inactive
LSP-Name R6-TO-R1-TUN1
Egress

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
134
135 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

2 sessions, 2 clients
Cumulative transmit rate 8.0 pps, cumulative receive rate 8.0 pps

Task 3. JUNOS offers a feature that monitors bandwidth utilisation of LSP to adjust bandwidth
requirement of the LSP. This provides flexibility and efficiency for the whole network because it would
frequently monitor ensure that LSP only requests bandwidth capacity that it needs instead of a fixed
amount. In this task, all LSPs are enabled with this feature.
lab@VMX-R5> show mpls lsp name R5-TO-R2-TUN1 extensive
Ingress LSP: 10 sessions

150.1.1.2
From: 150.1.1.5, State: Up, ActiveRoute: 0, LSPname: R5-TO-R2-TUN1
ActivePath: (primary)
Node/Link protection desired
LSPtype: Static Configured
LoadBalance: Least-fill
Autobandwidth
MinBW: 50Mbps MaxBW: 200Mbps
AdjustTimer: 3600 secs
Max AvgBW util: 0bps, Bandwidth Adjustment in 526 second(s).
Overflow limit: 0, Overflow sample count: 0
Underflow limit: 0, Underflow sample count: 0
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up, No-decrement-ttl
Priorities: 7 0
Bandwidth: 50Mbps
OptimizeTimer: 3600
SmartOptimizeTimer: 180
Reoptimization in 3392 second(s).

Node-Link Protection is one of three features that JUNOS offers (Link Protection, Node Protection and
Fast Reroute) when it comes to protecting LSPs. When an LSP is enabled with Node-Link Protection, all
routers along the best path of the LSP will automatically create Bypass LSPs to be ready to serve traffic
in the case of node failure. The switchover is theoretically expected to be close to 50msec even though
there are a lot of factors such as the number of LSPs contributing to it but overall it should be

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

significantly quicker than pure IP routing/forwarding.
lab@VMX-R5> show mpls lsp name R5-TO-R2-TUN1 extensive | match protection
Node/Link protection desired
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-
ID):
15 Sep 7 21:45:07.565 Link-protection Up
13 Sep 7 21:44:15.035 Link-protection Down
6 Sep 7 20:38:58.788 Link-protection Up

As can be seen below, LSP R5-TO-R1-TUN1 traverses R5, R3, R1 and we can see below that R5 created LSP
Bypass->150.1.35.3->150.1.13.1 for protection. Those LSPs go the other way around of node R3
completely, not just the link between R3 and R5. An interesting point here is that the bypass LSP can be
used by multiple LSPs being R5-TO-R1-TUN1 and R5-TO-R1-TUN2.
lab@VMX-R5> show mpls lsp name R5-TO-R1-TUN1 extensive | find RRO
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-
ID):
150.1.1.3(flag=0x21) 150.1.35.3(flag=1 Label=300608) 150.1.1.1(flag=0x20)
150.1.13.1(Label=0)

lab@VMX-R5> show mpls lsp name R5-TO-R1-TUN2 extensive | find RRO

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
135
136 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-

ID):
150.1.1.3(flag=0x21) 150.1.35.3(flag=1 Label=300448) 150.1.1.1(flag=0x20)
150.1.13.1(Label=0)
OAM state : BFD session up LSP-ping up

lab@VMX-R5> show mpls lsp bypass name Bypass->150.1.35.3->150.1.13.1 extensive | match

"Record route:"
Record route: <self> 150.1.45.4 150.1.24.2 150.1.12.1

Another important feature in this task is the style of selecting best path for each LSP being least-fill
which is one of the tie-breakers when more than one path is available after running the CSPF algorithm.
There are 3 tie-breaking rules: random, least-fill, and most-fill. The least-fill method chooses the
path with the largest minimum available bandwidth ratio. Its intention is to equalise the reservation
levels on each MPLS link and it might be preferred when the goal is to minimise the total number of LSPs
that are disrupted when a node/link failure occurs.
lab@VMX-R5> show mpls lsp name R5-TO-R2-TUN1 extensive | match fill
LoadBalance: Least-fill

Task 4. JUNOS offers methods that bring about efficiency for propagating RSVP messages. The first one
is the aggregation of RSVP messages which can pack multiple RSVP messages into a single transmission,
reducing network overhead and enhancing efficiency. It is enabled with statement aggregate and should
be used alongside statement reliable which is another method that requires acknowledgement for any
RSVP aggregated message to improve reliability.
lab@VMX-R6> show rsvp neighbor detail
RSVP neighbor: 2 learned
Address: 150.1.46.4 via: ge-0/0/7.0 status: Up
Last changed time: 20:25:14, Idle: 0 sec, Up cnt: 1, Down cnt: 0
Message received: 21837
Hello: sent 8097, received: 8097, interval: 9 sec
Remote instance: 0x1e0bc717, Local instance: 0x23332218
Refresh reduction: operational
Remote end: enabled, Ack-extension: enabled

Address: 150.1.56.5 via: ae0.0 status: Up

Last changed time: 20:25:12, Idle: 5 sec, Up cnt: 1, Down cnt: 0
Message received: 27416
Hello: sent 8097, received: 8097, interval: 9 sec
Remote instance: 0xa792797f, Local instance: 0x1facd54a

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

Refresh reduction: operational
Remote end: enabled, Ack-extension: enabled

By default, the available bandwidth for LSP reservation of each RSVP-enabled interface is equivalent to
the physical speed or 100% of its capacity. In some certain networks we should limit the reservation to a
certain percentage to ensure bandwidth-constraint LSPs do not starve other traffic such as LSPs that do
not require bandwidth (as they are best-effort and do not utilise a lot of bandwidth) or even we want to
guarantee some headroom for control-plane/monitoring traffic, etc.
lab@VMX-R6> show rsvp interface
RSVP interface: 7 active
Active Subscr- Static Available Reserved Highwater
Interface State resv iption BW BW BW mark
<snip>
ae0.0 Up 9 90% 2Gbps 1.45Gbps 350Mbps 350Mbps
ge-0/0/0.0 Up 0 90% 1000Mbps 900Mbps 0bps 0bps
ge-0/0/6.0 Up 0 90% 1000Mbps 900Mbps 0bps 0bps
ge-0/0/7.0 Up 5 90% 1000Mbps 750Mbps 150Mbps 300Mbps
sp-0/0/0.0 Up 0 90% 800Mbps 720Mbps 0bps 0bps
<snip>

By default, OSPF with TE extensions only sends an LSU message if the available bandwidth of link
changes by greater than 10%. In certain large network environments, we may need to signal that a little

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
136
137 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

quicker to propagate bandwidth availability information as soon as possible. The trade-off is really about
the number of IGP update/cycle of computation and stability of the topology. In order to tune the
percentage that triggers an IGP update, we can use statement update-threshold.
lab@VMX-R6> show rsvp interface ge-0/0/7.0 extensive
ge-0/0/7.0 Index 81, State Ena/Up
NoAuthentication, Aggregate, Reliable, LinkProtection
HelloInterval 9(second)
Address 150.1.46.6
ActiveResv 5, PreemptionCnt 0, Update threshold 5%
Subscription 90%,
bc0 = ct0, StaticBW 1000Mbps
ct0: StaticBW 1000Mbps, AvailableBW 750Mbps
MaxAvailableBW 900Mbps = (bc0*subscription)
ReservedBW [0] 150Mbps[1] 0bps[2] 0bps[3] 0bps[4] 0bps[5] 0bps[6] 0bps[7] 0bps
<snip>

Task 5. On the ingress node of an LSP, if statement the no-decrement-ttl is included, the ingress node
negotiates with all downstream routers using a JUNOS proprietary RSVP object to ensure all routers are
in agreement for the whole LSP appears as two hops for transit traffic. The ingress node pushes a MPLS
label on transit IP packets with the MPLS TTL field generalised to 255. This MPLS TTL value is
decremented by 1 as usual for every hop the MPLS packet traverses. On the egress, the router that pops
the label won’t write MPLS TTL into IP TTL (default setting), but instead decrement the original IP TTL by
1. This would help hide MPLS topology for any traceroute from the outside network. If the network
consists of different vendor devices, this will not work.
lab@VMX-R6> show mpls lsp ingress extensive | match "LSPname|ttl"
From: 150.1.1.6, State: Up, ActiveRoute: 0, LSPname: R6-TO-R1-TUN1
*Primary State: Up, No-decrement-ttl
From: 150.1.1.6, State: Up, ActiveRoute: 0, LSPname: R6-TO-R1-TUN2
*Primary State: Up, No-decrement-ttl
<snip>

This point can be verified when you complete BGP topic with routing between customers. For example,
as can be seen in the traceroute output below between C1 and C4 (across the SP1), there is no MPLS
label information and the topology of SP1 is concealed from customer point of view.
lab@VMX-VR> traceroute routing-instance C1 source 170.1.210.1 170.1.240.1
traceroute to 170.1.240.1 (170.1.240.1) from 170.1.210.1, 30 hops max, 52 byte packets

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

1 150.1.119.1 (150.1.119.1) 1.734 ms 1.199 ms 0.877 ms
2 150.1.56.6 (150.1.56.6) 3.280 ms 3.054 ms 3.347 ms
3 170.1.240.1 (170.1.240.1) 4.094 ms 5.338 ms 3.775 ms

The other ask of this task is to explicitly designate that only BGP is allowed to use MPLS LSPs for
transport. By default BGP is the only protocol that can use information in inet.3 table to route packets
towards destinations in table inet.0. The configuration in this task does not change anything from the
default behaviour. When tasks in topic BGP are fully configured, we can have a look at an OSPF route
and an BGP route in table inet.0 to see the difference. For demonstration purpose, the output is
provided below.
lab@VMX-R5> show route 150.1.1.1 active-path table inet.0

inet.0: 86 destinations, 130 routes (79 active, 0 holddown, 7 hidden)

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

150.1.1.1/32 *[OSPF/10] 16:36:57, metric 200

> to 150.1.35.3 via ge-0/0/7.0

lab@VMX-R5> show route 111.0.0.1 active-path table inet.0

inet.0: 86 destinations, 130 routes (79 active, 0 holddown, 7 hidden)

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

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
137
138 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

111.0.0.0/24 *[BGP/170] 20:48:17, localpref 100, from 150.1.1.4

AS path: 111 I
to 150.1.45.4 via ge-0/0/8.0, label-switched-path R5-TO-R4-TUN1
> to 150.1.45.4 via ge-0/0/8.0, label-switched-path R5-TO-R4-TUN2
to 150.1.56.6 via ae0.0, label-switched-path Bypass->150.1.45.4
to 150.1.56.6 via ae0.0, label-switched-path Bypass->150.1.45.4

Topic 4: BGP
Total Points: 25

R1
!
set protocols bgp group IBGP local-address 150.1.1.1

R2
!
set protocols bgp group IBGP local-address 150.1.1.2

R5
!

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

set protocols bgp group IBGP local-address 150.1.1.5

R6
!
set protocols bgp group IBGP local-address 150.1.1.6

R3
!
set routing-options autonomous-system 123456
edit protocols bgp group IBGP
set type internal
set cluster 150.1.1.3
set local-address 150.1.1.3
set neighbor 150.1.1.1
set neighbor 150.1.1.2
set neighbor 150.1.1.5
set neighbor 150.1.1.6
set bfd minimum-interval 500 multiplier 4
set export NHS
set advertise-inactive
exit
edit protocols bgp group IBGP-RR
set type internal
set local-address 150.1.1.3
set neighbor 150.1.1.4
set bfd minimum-interval 500 multiplier 4
set export NHS

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
138
139 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set advertise-inactive
exit
edit policy-options policy-statement NHS
set term 1 from protocol bgp
set term 1 from route-type external
set term 1 then next-hop self
set term 1 then accept
exit
R4
!
set routing-options autonomous-system 123456
edit protocols bgp group IBGP
set type internal
set cluster 150.1.1.4
set local-address 150.1.1.4
set neighbor 150.1.1.1
set neighbor 150.1.1.2
set neighbor 150.1.1.5
set neighbor 150.1.1.6
set bfd minimum-interval 500 multiplier 4
set export NHS
set advertise-inactive
exit
edit protocols bgp group IBGP-RR
set type internal
set local-address 150.1.1.4
set neighbor 150.1.1.3
set bfd minimum-interval 500 multiplier 4
set export NHS
set advertise-inactive
exit
edit policy-options policy-statement NHS
set term 1 from protocol bgp
set term 1 from route-type external
set term 1 then next-hop self
set term 1 then accept
exit

Local Router Peer Router ASN of Peer IPv4 of Peer IPv6 of Peer
Router Router Router
R1 C1 65001 150.1.119.2 2016:150:1:119::2
P1 100 150.1.100.2 2016:150:1:100::2

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

T1 111 111.1.120.2 2016:111:1:120::2
R2 P2 200 150.1.101.2 2016:150:1::101::2
T2 222 222.1.123.2 2016:222:1:123::2
R4 T1 111 111.1.105.2 2016:111:1:105::2
R5 P1 100 150.1.113.2 2016:150:1:113::2
R6 C4 65004 150.1.131.2 ::150.1.131.2
T2 222 222.1.106.2 2016:111:1:106::2

You can launch ping tests from any C/T/P routing-instance on VRF device with some test IPv4/IPv6
addresses below.

• C1: 170.1.210.1, 2016:170:1:210::1

• C4: 170.1.240.1, 2016:170:1:240::1
• P1: 100.0.0.1, 2016:100::1
• P2: 200.0.0.1, 2016:200::1
• T1: 111.0.0.1, 2016:111::1, 12.0.0.1, 2016:12::1

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
139
140 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

• T2: 222.0.0.1, 2016:222::1, 12.0.0.2, 2016:12::2

• T3 (BEHIND T1, T2): 123.0.0.1, 2016:123::1

R1,R2,R3,R4,R5,R6
!
set protocols mpls ipv6-tunneling
set protocols bgp group IBGP family inet unicast
set protocols bgp group IBGP family inet6 labeled-unicast explicit-null

R3,R4
!
set protocols bgp group IBGP-RR family inet unicast
set protocols bgp group IBGP-RR family inet6 labeled-unicast explicit-null

R2
!
edit protocols bgp group P2
set type external
set peer-as 200
set neighbor 150.1.101.2
set neighbor 2016:150:1:101::2
exit
edit protocols bgp group T2
set type external
set peer-as 222
set neighbor 222.1.123.2
set neighbor 2016:222:1:123::2

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

exit

R4
!
edit protocols bgp group T1
set type external
set peer-as 111
set neighbor 111.1.105.2
set neighbor 2016:111:1:105::2
exit

R5
!
edit protocols bgp group P1
set type external
set peer-as 100
set neighbor 150.1.113.2
set neighbor 2016:150:1:113::2
exit

R6
!
edit protocols bgp group C4
set type external
set peer-as 65004
set neighbor 150.1.131.2 import C4-IN-INET6 export C4-OUT-INET6
set family inet unicast

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
140
141 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set family inet6 unicast

set accept-remote-nexthop
exit
edit protocols bgp group T2
set type external
set peer-as 222
set neighbor 222.1.106.2
set neighbor 2016:222:1:106::2
exit
edit policy-options policy-statement C4-IN-INET6
set term 1 from family inet6
set term 1 from protocol bgp
set term 1 then next-hop ::150.1.131.2
set term 1 then accept
exit
edit policy-options policy-statement C4-OUT-INET6
set term 1 from family inet6
set term 1 from protocol bgp
set term 1 then next-hop ::150.1.131.1
set term 1 then accept
exit

Task 3 (4 points). Protect BGP routing tables of Service Provider Network 1 by accepting only IPv4
prefixes with subnet mask length between /8 and /24, and IPv6 prefixes with subnet mask length
between /32 and /64.
R1,R2,R3,R4,R5,R6
!
edit policy-options policy-statement EBGP-IN-INET
set term 1 from family inet
set term 1 from protocol bgp
set term 1 from route-filter 0.0.0.0/0 prefix-length /8-/24
set term 1 then next policy
set term DENY-ALL from family inet
set term DENY-ALL from protocol bgp
set term DENY-ALL then reject
exit
edit policy-options policy-statement EBGP-IN-INET6
set term 1 from family inet6
set term 1 from protocol bgp
set term 1 from route-filter ::/0 prefix-length /32-/64
set term 1 then community add CUST
set term 1 then next policy
set term DENY-ALL from family inet6
set term DENY-ALL from protocol bgp
set term DENY-ALL then reject
exit

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

R1
!
edit protocols bgp group C1
set neighbor 150.1.119.2 import [EBGP-IN-INET C1-IN-INET]
set neighbor 2016:150:1:119::2 import [EBGP-IN-INET6 C1-IN-INET6]
exit
edit protocols bgp group P1
set neighbor 150.1.100.2 import [EBGP-IN-INET P1-IN-INET]
set neighbor 2016:150:1:100::2 import [EBGP-IN-INET6 P1-IN-INET6]
exit
edit protocols bgp group T1
set neighbor 111.1.120.2 import [EBGP-IN-INET T1-IN-INET]
set neighbor 2016:111:1:120::2 import [EBGP-IN-INET6 T1-IN-INET6]
exit
edit policy-options policy-statement C1-IN-INET
set term 1 from family inet
set term 1 then accept
exit
edit policy-options policy-statement C1-IN-INET6
set term 1 from family inet6
set term 1 then accept
exit
edit policy-options policy-statement P1-IN-INET
set term 1 from family inet
set term 1 then accept
exit

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
141
142 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

edit policy-options policy-statement P1-IN-INET6

set term 1 from family inet6
set term 1 then accept
exit
edit policy-options policy-statement T1-IN-INET
set term 1 from family inet
set term 1 then accept
exit
edit policy-options policy-statement T1-IN-INET6
set term 1 from family inet6
set term 1 then accept
exit

R2
!
edit protocols bgp group P2
set neighbor 150.1.101.2 import [EBGP-IN-INET P2-IN-INET]
set neighbor 2016:150:1:101::2 import [EBGP-IN-INET P2-IN-INET6]
exit
edit protocols bgp group T2
set neighbor 222.1.123.2 import [EBGP-IN-INET T2-IN-INET]
set neighbor 2016:222:1:123::2 import [EBGP-IN-INET6 T2-IN-INET6]
exit
edit policy-options policy-statement P2-IN-INET
set term 1 from family inet
set term 1 then accept
exit
edit policy-options policy-statement P2-IN-INET6
set term 1 from family inet6
set term 1 then accept
exit
edit policy-options policy-statement T2-IN-INET
set term 1 from family inet
set term 1 then accept
exit
edit policy-options policy-statement T2-IN-INET6
set term 1 from family inet6
set term 1 then accept
exit

R4
!
edit protocols bgp group T1
set neighbor 111.1.105.2 import [EBGP-IN-INET T1-IN-INET]
set neighbor 2016:111:1:105::2 import [EBGP-IN-INET6 T1-IN-INET6]
exit
edit policy-options policy-statement T1-IN-INET
set term 1 from family inet
set term 1 then accept
exit

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

edit policy-options policy-statement T1-IN-INET6
set term 1 from family inet6
set term 1 then accept
exit

R5
!
edit protocols bgp group P1
set neighbor 150.1.113.2 import [EBGP-IN-INET P1-IN-INET]
set neighbor 2016:150:1:113::2 import [EBGP-IN-INET6 P1-IN-INET6]
exit
edit policy-options policy-statement P1-IN-INET
set term 1 from family inet
set term 1 then accept
exit
edit policy-options policy-statement P1-IN-INET6
set term 1 from family inet6
set term 1 then accept
exit

R6
!
edit protocols bgp group C4
delete neighbor 150.1.131.2 import
set neighbor 150.1.131.2 import [EBGP-IN-INET EBGP-IN-INET6]
set neighbor 150.1.131.2 import [C4-IN-INET C4-IN-INET6]
exit

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
142
143 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

edit protocols bgp group T2

set neighbor 222.1.106.2 import [EBGP-IN-INET T2-IN-INET]
set neighbor 2016:222:1:106::2 import [EBGP-IN-INET6 T2-IN-INET6]
exit
edit policy-options policy-statement C4-IN-INET
set term 1 from family inet
set term 1 then accept
exit
edit policy-options policy-statement T2-IN-INET
set term 1 from family inet
set term 1 then accept
exit
edit policy-options policy-statement T2-IN-INET6
set term 1 from family inet6
set term 1 then accept
exit

Community Description
16:1611 Prepend 1x ASN outbound to other customers
16:1612 Prepend 2x ASN outbound to other customers
16:1613 Prepend 3x ASN outbound to other customers
16:1621 Prepend 1x ASN outbound to other peers
16:1622 Prepend 2x ASN outbound to other peers
16:1623 Prepend 3x ASN outbound to other peers
R1,R2,R3,R4,R5,R6
!
edit policy-options policy-statement PREPEND-OUT-CUST
set term 1 from protocol bgp
set term 1 from community PREPEND-1AS-OUT-CUST
set term 1 then as-path-prepend 123456
set term 1 then community delete ALL-COMMUNITIES
set term 1 then accept
set term 2 from protocol bgp
set term 2 from community PREPEND-2AS-OUT-CUST
set term 2 then as-path-prepend "123456 123456"
set term 2 then community delete ALL-COMMUNITIES
set term 2 then accept

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

set term 3 from protocol bgp
set term 3 from community PREPEND-3AS-OUT-CUST
set term 3 then as-path-prepend "123456 123456 123456"
set term 3 then community delete ALL-COMMUNITIES
set term 3 then accept
exit
edit policy-options policy-statement PREPEND-OUT-PEER
set term 1 from protocol bgp
set term 1 from community PREPEND-1AS-OUT-PEER
set term 1 then as-path-prepend 123456
set term 1 then community delete ALL-COMMUNITIES
set term 1 then accept
set term 2 from protocol bgp
set term 2 from community PREPEND-2AS-OUT-PEER
set term 2 then as-path-prepend "123456 123456"
set term 2 then community delete ALL-COMMUNITIES
set term 2 then accept
set term 3 from protocol bgp
set term 3 from community PREPEND-3AS-OUT-PEER
set term 3 then as-path-prepend "123456 123456 123456"
set term 3 then community delete ALL-COMMUNITIES
set term 3 then accept
exit
set policy-options community ALL-COMMUNITIES member .*:.*
set policy-options community CUST member 16:3000
set policy-options community PREPEND-1AS-OUT-CUST members [16:3000 16:1611]
set policy-options community PREPEND-1AS-OUT-PEER members [16:3000 16:1621]

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
143
144 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set policy-options community PREPEND-2AS-OUT-CUST members [16:3000 16:1612]

set policy-options community PREPEND-2AS-OUT-PEER members [16:3000 16:1622]
set policy-options community PREPEND-3AS-OUT-CUST members [16:3000 16:1613]
set policy-options community PREPEND-3AS-OUT-PEER members [16:3000 16:1623]

R1
!
edit protocols bgp group C1
set neighbor 150.1.119.2 export PREPEND-OUT-CUST
set neighbor 2016:150:1:119::2 export PREPEND-OUT-CUST
exit
edit protocols bgp group P1
set neighbor 150.1.100.2 export PREPEND-OUT-PEER
set neighbor 2016:150:1:100::2 export PREPEND-OUT-PEER
exit
edit policy-options policy-statement C1-IN-INET
set term 1 then community add CUST
exit
edit policy-options policy-statement C1-IN-INET6
set term 1 then community add CUST
exit

R2
!
edit protocols bgp group P2
set neighbor 150.1.101.2 export PREPEND-OUT-PEER
set neighbor 2016:150:1:101::2 export PREPEND-OUT-PEER
exit

R5
!
edit protocols bgp group P1
set neighbor 150.1.113.2 export PREPEND-OUT-PEER
set neighbor 2016:150:1:113::2 export PREPEND-OUT-PEER
exit

R6
!
edit protocols bgp group C4
set neighbor 150.1.131.2 export [C4-OUT-INET6 PREPEND-OUT-CUST]
exit
edit policy-options policy-statement C4-IN-INET
set term 1 then community add CUST
exit
edit policy-options policy-statement C4-IN-INET6
set term 1 then community add CUST
exit
edit policy-options policy-statement C4-OUT-INET6
delete term 1 then accept
set term 1 then next policy

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

exit

Task 5 (3 points). Announce the IPv4/IPv6 supernets of Service Provider Network 1 on R3 and R4 (2
static routes are allowed on each router); ensure that prefixes owned by Service Provider Network 1 are
advertised towards peers with IGP metric tagged, please use the most efficient method for this point.
R3,R4
!
set routing-options aggregate route 150.1.0.0/16
set routing-options rib inet6.0 aggregate route 2016:150:1::/48
set protocols bgp group IBGP export AS-AGGREGATE
edit policy-options policy-statement AS-AGGREGATE
set term 1 from protocol aggregate
set term 1 from route-filter 150.1.0.0/16 exact
set term 1 then accept
set term 2 from protocol aggregate
set term 2 from route-filter 2016:150:1::/48 exact
set term 2 then accept
exit

R1,R5
!
set protocols bgp group P1 metric-out igp

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
144
145 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

R2
!
set protocols bgp group P2 metric-out igp

Verification
Tasks 1 and 2. The first step is to ensure all iBGP neighbourships are Established and also iBGP is
installed as a client of BFD which verifies forwarding path and liberates BGP from reliance upon OSPF for
notification of device failure. BGP no longer needs to rely on event-driven or periodic next-hop scanning.
The ultimate outcome is to improve convergence by rapidly detecting BGP neighbour failure.
lab@VMX-R3> show bgp summary | match 123456
150.1.1.1 123456 2955 2997 0 1 17:42:41 Establ
150.1.1.2 123456 2895 3074 0 0 21:54:08 Establ
150.1.1.4 123456 3023 3065 0 0 21:53:54 Establ
150.1.1.5 123456 2899 3103 0 0 21:54:06 Establ
150.1.1.6 123456 2966 3067 0 0 21:54:07 Establ

lab@VMX-R4> show bgp summary | match 123456

150.1.1.1 123456 2953 2999 0 1 17:43:57 Establ
150.1.1.2 123456 2896 3022 0 0 21:55:24 Establ
150.1.1.3 123456 3070 3023 0 0 21:55:10 Establ
150.1.1.5 123456 2901 3042 0 0 21:55:19 Establ
150.1.1.6 123456 2967 3019 0 0 21:55:19 Establ

Next, let’s check eBGP neighbourships with external ASNs, being customers’, peers’ and transits’. The
special eBGP sessions are between R6 and C4 where an v4-compatible IPv6 address is used instead of an
v4-mapped IPv6 address or the ::ffff style which is used in Practice Lab 1. Sometimes you do not have a
choice of which sort of IP style. Some older versions of JUNOS used v4-compatible style but the newer
ones use v4-mapped style. In this lab the IPv6 address of C4 is in v4-compatible style but we still need
to configure a special statement accept-remote-nexthop and rewrite BGP NEXT_HOP attributes for
prefixes learnt and advertised from/to C4. Let’s see what would happen if neither of them is in place:
lab@VMX-R6# deactivate protocols bgp group C4 accept-remote-nexthop

[edit]
lab@VMX-R6# deactivate protocols bgp group C4 neighbor 150.1.131.2 import

[edit]
lab@VMX-R6# deactivate protocols bgp group C4 neighbor 150.1.131.2 export

[edit]

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

lab@VMX-R6# commit
commit complete

[edit]
lab@VMX-R6# run show bgp summary
<snip>
150.1.131.2 65004 10 36 0 0 37 Establ
inet.0: 7/7/7/0
inet6.0: 0/0/0/0
<snip>

We can see that without the statement accept-remote-nexthop and NEXT_HOP rewriting R6 does not
accept any prefix advertised to C4. Interestingly, if we check R6’s logs, we would see that the reason for
not learning any route from C4 is that R6 sees unexpected value in the NEXT_HOP attribute, being the
IPv4-mapped IPv6 address style, even though C4 is administratively configured with the IPv4-compatible
IPv6 address. This is an inconsistency of newer JUNOS version which governs the default address tyle for
IPv6 NLRI advertised over IPv4 session.
[edit]
lab@VMX-R6# run show log messages | match sanity
Sep 16 18:28:23 R6 rpd[1198]: bgp_nexthop_sanity: peer 150.1.131.2 (External AS 65004)
next hop ::ffff:150.1.131.2 unexpectedly remote, ignoring routes in this update

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
145
146 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

lab@VMX-VR# show interfaces ge-0/0/8.131

description C4-PE;
vlan-id 131;
family inet {
address 150.1.131.2/30;
}
family inet6 {
address ::150.1.131.2/126;
}

Now let’s reactivate accept-remote-nexthop, we should then see that we can see C4’s prefixes in BGP
table of R6 however, they are hidden as the BGP NEXT_HOP is unresolvable.
lab@VMX-R6# activate protocols bgp group C4 accept-remote-nexthop

[edit]
lab@VMX-R6# commit
commit complete

[edit]
lab@VMX-R6# run clear bgp neighbor 150.1.131.2
Cleared 1 connections

lab@VMX-R6# run show bgp summary

<snip>
150.1.131.2 65004 32 84 0 3 2:26 Establ
inet.0: 7/7/7/0
inet6.0: 0/7/7/0
<snip>

[edit]
lab@VMX-R6# run show route receive-protocol bgp 150.1.131.2 table inet6.0 hidden

inet6.0: 60 destinations, 109 routes (53 active, 0 holddown, 7 hidden)

Prefix Nexthop MED Lclpref AS path
2016:170:1:240::/64 ::ffff:150.1.131.2 65004 I
2016:170:1:241::/64 ::ffff:150.1.131.2 65004 I
2016:170:1:242::/64 ::ffff:150.1.131.2 65004 I
2016:170:1:243::/64 ::ffff:150.1.131.2 65004 I
2016:170:1:244::/64 ::ffff:150.1.131.2 65004 I
2016:170:1:245::/64 ::ffff:150.1.131.2 65004 I
2016:170:1:246::1/128
::ffff:150.1.131.2 65004 I

[edit]
lab@VMX-R6# run show route resolution unresolved
Tree Index 1
Tree Index 2

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

2016:170:1:244::/64
Protocol Nexthop: ::ffff:150.1.131.2
Indirect nexthop: 0 -
2016:170:1:243::/64
Protocol Nexthop: ::ffff:150.1.131.2
Indirect nexthop: 0 -
2016:170:1:242::/64
Protocol Nexthop: ::ffff:150.1.131.2
Indirect nexthop: 0 -
2016:170:1:241::/64
Protocol Nexthop: ::ffff:150.1.131.2
Indirect nexthop: 0 -
2016:170:1:240::/64
Protocol Nexthop: ::ffff:150.1.131.2
Indirect nexthop: 0 -
2016:170:1:246::1/128
Protocol Nexthop: ::ffff:150.1.131.2
Indirect nexthop: 0 -
2016:170:1:245::/64
Protocol Nexthop: ::ffff:150.1.131.2
Indirect nexthop: 0 -
Tree Index 3

Now let’s reactivate the corresponding policies which rewrite NEXT_HOP attribute and we should see
C4’s prefixes properly installed into BGP table on R6.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
146
147 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

lab@VMX-R6# activate protocols bgp group C4 neighbor 150.1.131.2 import

[edit]
lab@VMX-R6# activate protocols bgp group C4 neighbor 150.1.131.2 export

[edit]
lab@VMX-R6# commit
commit complete

[edit]
lab@VMX-R6# run clear bgp neighbor 150.1.131.2 soft

lab@VMX-R6# run show route receive-protocol bgp 150.1.131.2 table inet6.0

inet6.0: 60 destinations, 109 routes (60 active, 0 holddown, 0 hidden)

Prefix Nexthop MED Lclpref AS path
* 2016:170:1:240::/64 ::ffff:150.1.131.2 65004 I
* 2016:170:1:241::/64 ::ffff:150.1.131.2 65004 I
* 2016:170:1:242::/64 ::ffff:150.1.131.2 65004 I
* 2016:170:1:243::/64 ::ffff:150.1.131.2 65004 I
* 2016:170:1:244::/64 ::ffff:150.1.131.2 65004 I
* 2016:170:1:245::/64 ::ffff:150.1.131.2 65004 I

lab@VMX-R6# run show bgp summary

<snip>
150.1.131.2 65004 42 144 0 3 7:13 Establ
inet.0: 6/7/6/0
inet6.0: 6/7/6/0

[edit]
lab@VMX-R6# run show route resolution unresolved
Tree Index 1
Tree Index 2
Tree Index 3

Apart from regular IPv4 routing/switching between ASNs, task 2 requires IPv6 routing/forwarding over
MPLS domain to be configured so that customers can have IPv6 reachability to peers and transits. This
refers to 6PE implementation for Service Provider Network 1 which requires the following:

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

null in which MPLS label will be advertised as "3" indicating PHP hop to not pop out the outer
label.
• set protocols mpls ipv6-tunneling, we convert IPv4 next-hop being routers’ loopback address
in table inet.3 into IPv4-mapped IPv6 next-hop and install them into table inet6.3 for IPv6 label-
based forwarding.
• family inet6 on all core-facing interfaces, this is already configured as part of initial
configurations. There is no need for specific IPv6 address to be configured, but instead just the
activation of the IPv6 AFI on the interfaces.

Since our BGP implementation does require IPv4 routing/switching, we would need to enable family
inet unicast along family inet6 labeled-unicast, because without it only the latter is activated
between the routers. By the end of task 2, we should test reachability of IPv4/IPv6 routing/switching
between customers, peers and transits. However let’s wait until policies from task 3 are in place to
ensure we don’t accidentally filter any test prefix.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
147
148 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

With task 3, for each address family (IPv4 and IPv6) we would configure an import policy to filter
incoming eBGP prefixes with statement prefix-length to limit the subnet mask lengths required.. The
first term of the import policy acts as a filter, any matched prefix will be processed in the next policy
while any unmatched prefix will be filtered off at the end with a denial rule. JUNOS allows for multiple
import polcies to be combined in a list and the order is importance as that is the sequence they are
evaluated. The import policies can be shared between multiple eBGP groups as a standard of filtering
external prefixes at the edge. Let’s test filtering policies:
lab@VMX-R1> show route receive-protocol bgp 111.1.120.2 table inet.0

inet.0: 111 destinations, 221 routes (102 active, 0 holddown, 29 hidden)

Prefix Nexthop MED Lclpref AS path
* 6.0.0.0/8 111.1.120.2 111 123 12 47 591 412
551 267 6 I
* 7.0.0.0/8 111.1.120.2 111 123 235 1256 2356
9587 6834 1351 7 I
* 8.0.0.0/8 111.1.120.2 111 123 549 8973 2168
5488 2437 5489 6543 8 I
* 9.0.0.0/8 111.1.120.2 111 123 1125 2678 35122
42516 54754 6125 751 8623 9 I
* 12.0.0.0/24 111.1.120.2 111 I
* 23.0.0.0/24 111.1.120.2 111 123 I
* 30.1.0.0/16 111.1.120.2 111 123 301 I
* 30.2.0.0/16 111.1.120.2 111 123 302 I
* 30.3.0.0/16 111.1.120.2 111 123 303 I
* 30.4.0.0/16 111.1.120.2 111 123 304 I
100.0.0.0/24 111.1.120.2 111 100 I
100.5.0.0/21 111.1.120.2 111 100 I
* 111.0.0.0/24 111.1.120.2 111 I
* 111.3.0.0/23 111.1.120.2 111 I
* 111.4.0.0/22 111.1.120.2 111 I
* 111.5.0.0/21 111.1.120.2 111 I
* 123.0.0.0/24 111.1.120.2 111 123 I
* 123.0.1.0/24 111.1.120.2 111 123 I
* 123.0.2.0/24 111.1.120.2 111 123 I
* 123.0.3.0/24 111.1.120.2 111 123 I
* 123.0.4.0/24 111.1.120.2 111 123 I
* 123.3.0.0/23 111.1.120.2 111 123 I
* 123.4.0.0/22 111.1.120.2 111 123 I
* 123.5.0.0/21 111.1.120.2 111 123 I
170.1.210.0/24 111.1.120.2 111 65001 I
170.1.211.0/24 111.1.120.2 111 65001 I
170.1.212.0/24 111.1.120.2 111 65001 I
170.1.213.0/24 111.1.120.2 111 65001 I
170.1.214.0/24 111.1.120.2 111 65001 I

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

170.1.215.0/24 111.1.120.2 111 65001 I

lab@VMX-R1> show route receive-protocol bgp 111.1.120.2 table inet.0 hidden

inet.0: 111 destinations, 221 routes (102 active, 0 holddown, 29 hidden)

Prefix Nexthop MED Lclpref AS path
10.0.0.0/29 111.1.120.2 111 123 I
100.6.0.1/32 111.1.120.2 111 100 I
111.1.0.0/26 111.1.120.2 111 I
111.2.0.0/25 111.1.120.2 111 I
111.6.0.1/32 111.1.120.2 111 I
123.1.0.0/26 111.1.120.2 111 123 I
123.2.0.0/25 111.1.120.2 111 123 I
123.6.0.1/32 111.1.120.2 111 123 I
170.1.216.1/32 111.1.120.2 111 65001 I
172.16.0.0/28 111.1.120.2 111 123 I
192.168.1.0/27 111.1.120.2 111 123 I

lab@VMX-R1> show route receive-protocol bgp 2016:111:1:120::2 table inet6.0

inet6.0: 70 destinations, 153 routes (65 active, 0 holddown, 19 hidden)

Prefix Nexthop MED Lclpref AS path
* 2016:12::/64 2016:111:1:120::2 111 I
* 2016:23::/64 2016:111:1:120::2 111 123 I
2016:100::/64 2016:111:1:120::2 111 100 I
2016:100:5::/48 2016:111:1:120::2 111 100 I
* 2016:111::/64 2016:111:1:120::2 111 I

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
148
149 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

* 2016:111:3::/63 2016:111:1:120::2 111 I

* 2016:111:4::/62 2016:111:1:120::2 111 I
* 2016:111:5::/48 2016:111:1:120::2 111 I
* 2016:123::/64 2016:111:1:120::2 111 123 I
* 2016:123:3::/63 2016:111:1:120::2 111 123 I
* 2016:123:4::/62 2016:111:1:120::2 111 123 I
* 2016:123:5::/48 2016:111:1:120::2 111 123 I
2016:170:1:210::/64 2016:111:1:120::2 111 65001 I
2016:170:1:211::/64 2016:111:1:120::2 111 65001 I
2016:170:1:212::/64 2016:111:1:120::2 111 65001 I
2016:170:1:213::/64 2016:111:1:120::2 111 65001 I
2016:170:1:214::/64 2016:111:1:120::2 111 65001 I
2016:170:1:215::/64 2016:111:1:120::2 111 65001 I

lab@VMX-R1> show route receive-protocol bgp 2016:111:1:120::2 table inet6.0 hidden

inet6.0: 70 destinations, 153 routes (65 active, 0 holddown, 19 hidden)

Prefix Nexthop MED Lclpref AS path
2016:100:6::1/128 2016:111:1:120::2 111 100 I
2016:111:1::/66 2016:111:1:120::2 111 I
2016:111:2::/65 2016:111:1:120::2 111 I
2016:111:6::1/128 2016:111:1:120::2 111 I
2016:123:1::/66 2016:111:1:120::2 111 123 I
2016:123:2::/65 2016:111:1:120::2 111 123 I
2016:123:6::1/128 2016:111:1:120::2 111 123 I
2016:170:1:216::1/128
2016:111:1:120::2 111 65001 I

Now let’s test IPv4/v6 reachability between customers, peers and transits by issuing ping tests from
customer C1 for example:
IPv4:

lab@VMX-VR> ping rapid routing-instance C1 source 170.1.210.1 170.1.240.1

lab@VMX-VR> ping rapid routing-instance C1 source 170.1.210.1 100.0.0.1

PING 100.0.0.1 (100.0.0.1): 56 data bytes
!!!!!
--- 100.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 14.800/14.944/15.052/0.092 ms

lab@VMX-VR> ping rapid routing-instance C1 source 170.1.210.1 200.0.0.1

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

PING 200.0.0.1 (200.0.0.1): 56 data bytes
!!!!!
--- 200.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 15.064/19.030/20.250/1.990 ms

lab@VMX-VR> ping rapid routing-instance C1 source 170.1.210.1 111.0.0.1

lab@VMX-VR> ping rapid routing-instance C1 source 170.1.210.1 222.0.0.1

PING 222.0.0.1 (222.0.0.1): 56 data bytes
!!!!!
--- 222.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 15.170/18.950/20.125/1.896 ms

lab@VMX-VR> ping rapid routing-instance C1 source 170.1.210.1 12.0.0.1

PING 12.0.0.1 (12.0.0.1): 56 data bytes
!!!!!
--- 12.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 14.833/14.948/15.078/0.085 ms

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
149
150 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

lab@VMX-VR> ping rapid routing-instance C1 source 170.1.210.1 12.0.0.2

PING 12.0.0.2 (12.0.0.2): 56 data bytes
!!!!!
--- 12.0.0.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 19.667/19.903/20.152/0.189 ms

IPv6:

lab@VMX-VR> ping rapid routing-instance C1 source 2016:170:1:210::1 2016:170:1:240::1

lab@VMX-VR> ping rapid routing-instance C1 source 2016:170:1:210::1 2016:100::1

lab@VMX-VR> ping rapid routing-instance C1 source 2016:170:1:210::1 2016:200::1

lab@VMX-VR> ping rapid routing-instance C1 source 2016:170:1:210::1 2016:111::1

lab@VMX-VR> ping rapid routing-instance C1 source 2016:170:1:210::1 2016:222::1

lab@VMX-VR> ping rapid routing-instance C1 source 2016:170:1:210::1 2016:12::1

PING6(56=40+8+8 bytes) 2016:170:1:210::1 --> 2016:12::1
!!!!!
--- 2016:12::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 19.591/19.936/20.209/0.237 ms

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

lab@VMX-VR> ping rapid routing-instance C1 source 2016:170:1:210::1 2016:12::2
PING6(56=40+8+8 bytes) 2016:170:1:210::1 --> 2016:12::2
!!!!!
--- 2016:12::2 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 24.346/24.825/25.144/0.264 ms

Task 4 is really about setting BGP policies based on the receiving community of inbound prefixes. Such
community-based policies allow for dynamically setting BGP attributes to achieve traffic engineering
without manual engagement between customers and Service Provider 1. The issue of this task is that we
need to ensure the policies have effect with community (policy-signalling community) tagged by
customers only, not by peers or transits. The solution is to tag customer routes with a community
(customer-identifying community) to distinguish them from peers and transits and then set outbound
policies based on a combination of customer-identifying community and the policy-signalling
community. Particularly for C4 outbound policies, we already have one (C4-OUT-INET6) that rewrites
NEXT_HOP value previously in task 2 so we would need to amend the decision to be next-policy so the
new policy PREPEND-OUT-CUST will have effect.
lab@VMX-R6> show route advertising-protocol bgp 150.1.131.2 table inet.0 | match 170.1.21

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
150
151 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

* 170.1.210.0/24 Self 65001 I

* 170.1.211.0/24 Self 123456 [123456] 65001 I
* 170.1.212.0/24 Self 123456 123456 [123456]
65001 I
* 170.1.213.0/24 Self 123456 123456 123456
[123456] 65001 I
* 170.1.214.0/24 Self 65001 I
* 170.1.215.0/24 Self 65001 I

lab@VMX-R6> show route advertising-protocol bgp 150.1.131.2 170.1.212.0/24 extensive

inet.0: 65 destinations, 95 routes (60 active, 0 holddown, 5 hidden)

* 170.1.212.0/24 (2 entries, 1 announced)
BGP group C4 type External
Nexthop: Self
AS path: 123456 123456 [123456] 65001 I

lab@VMX-R6> show route 170.1.212.0/24 extensive | match Comm

Communities:
Communities: 16:1612 16:1622 16:3000 16:3010
Communities: 16:1612 16:1622 16:3000 16:3010
Communities: 16:1612 16:1622 16:3000 16:3010

lab@VMX-R6> show route advertising-protocol bgp 150.1.131.2 table inet6.0 | match

2016:170:1:21
* 2016:170:1:210::/64 ::150.1.131.1 65001 I
* 2016:170:1:211::/64 ::150.1.131.1 123456 [123456] 65001 I
* 2016:170:1:212::/64 ::150.1.131.1 123456 123456 [123456]
65001 I
* 2016:170:1:213::/64 ::150.1.131.1 123456 123456 123456
[123456] 65001 I
* 2016:170:1:214::/64 ::150.1.131.1 65001 I
* 2016:170:1:215::/64 ::150.1.131.1 65001 I

Task 5 discusses an ability to advertise IGP metric in form of BGP MED attribute to external networks.
This feature while has good intention of allowing external networks to send traffic to/via Service
Provider 1 over ‘shortest’ paths, but it also poses a stability-related problem, i.e. whenever there is a
path change in the IGP domain, it is reflected to BGP, creating constant updates. Therefore it is here for
demonstration purpose only.
lab@VMX-R5> show route advertising-protocol bgp 150.1.113.2

inet.0: 108 destinations, 185 routes (88 active, 0 holddown, 20 hidden)

Prefix Nexthop MED Lclpref AS path
* 6.0.0.0/8 Self 100 111 123 12 47 591 412
551 267 6 I

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

* 7.0.0.0/8 Self 100 111 123 235 1256 2356
9587 6834 1351 7 I
* 8.0.0.0/8 Self 100 111 123 549 8973 2168
5488 2437 5489 6543 8 I
* 9.0.0.0/8 Self 100 111 123 1125 2678 35122
42516 54754 6125 751 8623 9 I
* 12.0.0.0/24 Self 100 111 I
* 13.0.0.0/24 Self 200 222 123 I
* 23.0.0.0/24 Self 100 111 123 I
* 30.1.0.0/16 Self 100 111 123 301 I
* 30.2.0.0/16 Self 100 111 123 302 I
* 30.3.0.0/16 Self 100 111 123 303 I
* 30.4.0.0/16 Self 100 111 123 304 I
* 111.0.0.0/24 Self 100 111 I
* 111.3.0.0/23 Self 100 111 I
* 111.4.0.0/22 Self 100 111 I
* 111.5.0.0/21 Self 100 111 I
* 123.0.0.0/24 Self 100 111 123 I
* 123.0.1.0/24 Self 100 111 123 I
* 123.0.2.0/24 Self 100 111 123 I
* 123.0.3.0/24 Self 100 111 123 I
* 123.0.4.0/24 Self 100 111 123 I
* 123.3.0.0/23 Self 100 111 123 I
* 123.4.0.0/22 Self 100 111 123 I
* 123.5.0.0/21 Self 100 111 123 I
* 150.1.0.0/16 Self 100 I
* 170.1.210.0/24 Self 200 65001 I

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
151
152 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

* 170.1.211.0/24 Self 200 123456 [123456] 65001 I

* 170.1.212.0/24 Self 200 123456 123456 [123456]
65001 I
* 170.1.213.0/24 Self 200 123456 123456 123456
[123456] 65001 I
* 170.1.214.0/24 Self 200 65001 I
* 170.1.215.0/24 Self 200 65001 I
* 170.1.240.0/24 Self 50 65004 I
* 170.1.241.0/24 Self 50 123456 [123456] 65004 I
* 170.1.242.0/24 Self 50 123456 123456 [123456]
65004 I
* 170.1.243.0/24 Self 50 123456 123456 123456
[123456] 65004 I
* 170.1.244.0/24 Self 50 65004 I
* 170.1.245.0/24 Self 50 65004 I
* 200.0.0.0/24 Self 200 200 I
* 200.3.0.0/23 Self 200 200 I
* 200.4.0.0/22 Self 200 200 I
* 200.5.0.0/21 Self 200 200 I
* 222.0.0.0/24 Self 200 222 I
* 222.3.0.0/23 Self 200 222 I
* 222.4.0.0/22 Self 200 222 I
* 222.5.0.0/21 Self 200 222 I

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
152
153 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 5: VPN
Total Points: 24

• CE1-1: 172.30.1[0-9].1
• CE1-2: 172.30.2[0-9].1
• CE1-3: 172.30.3[0-9].1
R1,R2,R3,R4,R5
!
set protocols bgp group IBGP family inet-vpn unicast

R3,R4
!
set protocols bgp group IBGP-RR family inet-vpn unicast

R1
!
set routing-options route-distinguisher-id 150.1.1.1
edit routing-instance VPN1-HUB
set instance-type vrf
set vrf-import DENY-ALL
set vrf-export VPN1-HUB-EXPORT
set interface ge-0/0/4.117
set protocols ospf area 0.0.0.0 interface ge-0/0/4.117
set protocols ospf export BGP-TO-OSPF
exit
edit routing-instance VPN1-SPOKE
set instance-type vrf
set vrf-import VPN1-SPOKE-IMPORT
set vrf-export DENY-ALL
set interface ge-0/0/4.118
set protocols ospf area 0.0.0.0 interface ge-0/0/4.118
set protocols ospf export BGP-TO-OSPF
set protocols ospf domain-vpn-tag 0
exit
edit policy-options policy-statement BGP-TO-OSPF
set term 1 from protocol bgp
set term 1 then accept

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

exit
edit policy-options policy-statement VPN1-HUB-EXPORT
set term 1 from protocol [direct ospf]
set term 1 then community set VPN1-HUB-RT
set term 1 then accept
exit
edit policy-options policy-statement VPN1-SPOKE-IMPORT
set term 1 from protocol bgp
set term 1 from community VPN1-SPOKE-RT
set term 1 then accept
exit
set policy-options policy-statement DENY-ALL term DENY-ALL then reject
set policy-options community VPN1-HUB-RT member target:16:3310
set policy-options community VPN1-SPOKE-RT member target:16:3311

R2
!
set routing-options route-distinguisher-id 150.1.1.2
edit routing-instance VPN1-SPOKE
set instance-type vrf
set vrf-import VPN1-SPOKE-IMPORT
set vrf-export VPN1-SPOKE-EXPORT
set interface ge-0/0/4.103
set protocols ospf area 0.0.0.0 interface ge-0/0/4.103
set protocols ospf export BGP-TO-OSPF
exit

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
153
154 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

edit policy-options policy-statement BGP-TO-OSPF

set term 1 from protocol bgp
set term 1 then accept
exit
edit policy-options policy-statement VPN1-SPOKE-EXPORT
set term 1 from protocol [direct ospf]
set term 1 then community add VPN1-SPOKE-RT
set term 1 then accept
exit
edit policy-options policy-statement VPN1-SPOKE-IMPORT
set term 1 from protocol bgp
set term 1 from community VPN1-HUB-RT
set term 1 then accept
exit
set policy-options community VPN1-HUB-RT member target:16:3310
set policy-options community VPN1-SPOKE-RT member target:16:3311

R5
!
set routing-options route-distinguisher-id 150.1.1.5
edit routing-instance VPN1-SPOKE
set instance-type vrf
set vrf-import VPN1-SPOKE-IMPORT
set vrf-export VPN1-SPOKE-EXPORT
set interface ge-0/0/4.112
set protocols ospf area 0.0.0.0 interface ge-0/0/4.112
set protocols ospf export BGP-TO-OSPF
exit
edit policy-options policy-statement BGP-TO-OSPF
set term 1 from protocol bgp
set term 1 then accept
exit
edit policy-options policy-statement VPN1-SPOKE-EXPORT
set term 1 from protocol [direct ospf]
set term 1 then community add VPN1-SPOKE-RT
set term 1 then accept
exit
edit policy-options policy-statement VPN1-SPOKE-IMPORT
set term 1 from protocol bgp
set term 1 from community VPN1-HUB-RT
set term 1 then accept
exit
set policy-options community VPN1-HUB-RT member target:16:3310
set policy-options community VPN1-SPOKE-RT member target:16:3311

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

• CE4-1: 2016:172:30:9[0-9]::1
• CE4-2: 2016:172:30:10[0-9]::1
R3,R4
!
set protocols bgp group IBGP-RR family inet6-vpn unicast
set protocols mpls ipv6-tunneling

R3
!
set routing-options route-distinguisher-id 150.1.1.3
edit routing-instance VPN4
set routing-options router-id 150.1.1.3
set instance-type vrf
set vrf-target target:16:3340
set interface ge-0/0/4.127
set protocols bgp group VPN4 type external
set protocols bgp group VPN4 peer-as 65504
set protocols bgp group VPN4 neighbor 2016:172:16:127::2
set protocols bgp group VPN4 as-override
exit

R4
!

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
154
155 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set routing-options route-distinguisher-id 150.1.1.4

edit routing-instance VPN4
set routing-options router-id 150.1.1.4
set instance-type vrf
set vrf-target target:16:3340
set interface ge-0/0/4.128
set protocols bgp group VPN4 type external
set protocols bgp group VPN4 peer-as 65504
set protocols bgp group VPN4 neighbor 2016:172:16:128::2
set protocols bgp group VPN4 as-override
exit

Task 3 (6 points). Provide Inter-AS MPLS L3 VPN Option B, for VPN1 customer in co-operation with
Service Provider Network 2, including site CE1-5 using OSPF as routing protocol. You can launch ping
tests from any participating CE routing-instance on VRF device with some test IPv4 addresses below. You
are not allowed to use the same route-target value in two Servicer Provider networks 1 and 2.

• CE1-5: 172.30.11[0-9].1

R3,R4,R5,R6
!
set protocols bgp group IBGP family inet-vpn unicast

R5
!
edit protocols bgp group R7
set type external
set peer-as 78
set family inet-vpn unicast
set neighbor 150.1.57.7
set import R7-IN-VPN
set export R7-OUT-VPN
exit
edit policy-options policy-statement R7-IN-VPN
set term 1 from family inet-vpn
set term 1 from protocol bgp
set term 1 from community VPN1-SPOKE-RT-EXTERNAL
set term 1 then community set VPN1-SPOKE-RT
set term 1 then accept
exit
edit policy-options policy-statement R7-OUT-VPN
set term 1 from family inet-vpn
set term 1 from protocol bgp
set term 1 from community VPN1-HUB-RT
set term 1 then community set VPN1-SPOKE-RT-EXTERNAL

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

set term 1 then accept
exit
set policy-options community VPN1-HUB-RT member target:16:3310
set policy-options community VPN1-SPOKE-RT member target:16:3311
set policy-options community VPN1-SPOKE-RT-EXTERNAL member target:78:3311

R6
!
edit protocols bgp group R8
set type external
set peer-as 78
set family inet-vpn unicast
set neighbor 150.1.68.8
set import R8-IN-VPN
set export R8-OUT-VPN
exit
edit policy-options policy-statement R8-IN-VPN
set term 1 from family inet-vpn
set term 1 from protocol bgp
set term 1 from community VPN1-SPOKE-RT-EXTERNAL
set term 1 then community set VPN1-SPOKE-RT
set term 1 then accept
exit
edit policy-options policy-statement R8-OUT-VPN
set term 1 from family inet-vpn
set term 1 from protocol bgp
set term 1 from community VPN1-HUB-RT

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
155
156 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set term 1 then community set VPN1-SPOKE-RT-EXTERNAL

R7
!
set routing-options autonomous-system 78
set routing-options route-distinguisher-id 151.1.1.7
edit protocols bgp group R5
set type external
set peer-as 123456
set family inet-vpn unicast
set neighbor 150.1.57.5
exit
edit protocols bgp group IBGP
set type internal
set family inet-vpn unicast
set local-address 151.1.1.7
set neighbor 151.1.1.8
set export NHS
exit
edit policy-options policy-statement NHS
set term 1 from protocol bgp
set term 1 from route-type external
set term 1 then next-hop self
set term 1 then accept
exit

R8
!
set routing-options autonomous-system 78
set routing-options route-distinguisher-id 151.1.1.8
edit protocols bgp group R6
set type external
set peer-as 123456
set family inet-vpn unicast
set family inet6-vpn unicast
set neighbor 150.1.68.6
set accept-remote-nexthop
exit
edit protocols bgp group IBGP
set type internal
set family inet-vpn unicast
set family inet6-vpn unicast
set local-address 151.1.1.8
set neighbor 151.1.1.7
set export NHS

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

exit
edit policy-options policy-statement NHS
set term 1 from protocol bgp
set term 1 from route-type external
set term 1 then next-hop self
set term 1 then accept
exit
edit routing-instance VPN1
set instance-type vrf
set vrf-import VPN1-IMPORT
set vrf-export VPN1-EXPORT
set interface ge-0/0/4.129
set protocols ospf area 0.0.0.0 interface ge-0/0/4.129
set protocols ospf export BGP-TO-OSPF
exit
edit policy-options policy-statement VPN1-EXPORT
set term 1 from protocol [direct ospf]
set term 1 then community add VPN1-RT
set term 1 then accept
exit
edit policy-options policy-statement VPN1-IMPORT
set term 1 from protocol bgp
set term 1 from community VPN1-RT
set term 1 then accept
exit
edit policy-options policy-statement BGP-TO-OSPF
set term 1 from protocol bgp

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
156
157 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set term 1 then accept

exit
set policy-options community VPN1-RT members target:78:3311
set policy-options community VPN1-RT-EXTERNAL members target:16:3311

Task 4 (6 points). Provide Inter-AS MPLS L3 VPN Option B, for VPN6 customer in co-operation with
Service Provider Network 2, including site CE4-3 using BGP as routing protocol. You can launch ping tests
from any participating CE routing-instance on VRF device with some test IPv4 addresses below. You are
not allowed to use the same route-target value in two Servicer Provider networks 1 and 2. You are also
not allowed to use native IPv6 peering between the two Service Provider networks.

• CE4-3: 2016:172:30:12[0-9]::1

R3,R4,R5,R6
!
set protocols bgp group IBGP family inet6-vpn unicast

R5
!
set protocols mpls ipv6-tunneling
set interfaces ge-0/0/6 unit 0 family inet6 address ::ffff:150.1.57.5/124
edit protocols bgp group R7
set family inet6-vpn unicast
exit
edit policy-options policy-statement R7-IN-VPN
set term 6 from family inet6-vpn
set term 6 from protocol bgp
set term 6 from community VPN4-RT-EXTERNAL
set term 6 then community set VPN4-RT
set term 6 then accept
exit
edit policy-options policy-statement R7-OUT-VPN
set term 6 from family inet6-vpn
set term 6 from protocol bgp
set term 6 from community VPN4-RT
set term 6 then community set VPN4-RT-EXTERNAL
set term 6 then accept
exit
set policy-options community VPN4-RT-EXTERNAL member target:78:3340
set policy-options community VPN4-RT member target:16:3340

R6
!

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

set protocols mpls ipv6-tunneling
set interfaces ge-0/0/6 unit 0 family inet6 address ::ffff:150.1.68.6/124
edit protocols bgp group R8
set family inet6-vpn unicast
exit
edit policy-options policy-statement R8-IN-VPN
set term 6 from family inet6-vpn
set term 6 from protocol bgp
set term 6 from community VPN4-RT-EXTERNAL
set term 6 then community set VPN4-RT
set term 6 then accept
exit
edit policy-options policy-statement R8-OUT-VPN
set term 6 from family inet6-vpn
set term 6 from protocol bgp
set term 6 from community VPN4-RT
set term 6 then community set VPN4-RT-EXTERNAL
set term 6 then accept
exit
set policy-options community VPN4-RT-EXTERNAL member target:78:3340
set policy-options community VPN4-RT member target:16:3340

R7
!
set routing-options autonomous-system 78
set routing-options route-distinguisher-id 151.1.1.7
set protocols mpls ipv6-tunneling

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
157
158 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set interfaces ge-0/0/6 unit 0 family inet6 address ::ffff:150.1.57.7/124

edit protocols bgp group R5
set family inet6-vpn unicast
exit
edit protocols bgp group IBGP
set family inet6-vpn unicast
exit
edit routing-instance VPN4
set routing-options router-id 151.1.1.7
set instance-type vrf
set vrf-target target:78:3340
set interface ge-0/0/4.125
set protocols bgp group VPN4 type external
set protocols bgp group VPN4 peer-as 65504
set protocols bgp group VPN4 neighbor 2016:172:16:125::2
set protocols bgp group VPN4 as-override
exit

R8
!
set protocols mpls ipv6-tunneling
set interfaces ge-0/0/6 unit 0 family inet6 address ::ffff:150.1.68.8/124
edit protocols bgp group R6
set family inet6-vpn unicast
exit
edit protocols bgp group IBGP
set family inet6-vpn unicast
exit

Verification
Task 1. Firstly let’s ensure all OSPF neighbourships with CE routers are now Full. And then we check
routing instance on spoke PE routers R2 and R5 to see whether they now have VPN routes advertised by
the hub PE router being R1 as well as each other’s. Output on R5 is omitted for brevity.
lab@VMX-R1> show ospf neighbor instance VPN1-HUB
Address Interface State ID Pri Dead
172.16.117.2 ge-0/0/4.117 Full 172.30.10.1 128 38

lab@VMX-R1> show ospf neighbor instance VPN1-SPOKE

Address Interface State ID Pri Dead
172.16.118.2 ge-0/0/4.118 Full 172.30.10.1 128 33

lab@VMX-R2> show ospf neighbor instance VPN1-SPOKE

Address Interface State ID Pri Dead
172.16.103.2 ge-0/0/4.103 Full 172.30.20.1 128 38

lab@VMX-R5> show ospf neighbor instance VPN1-SPOKE

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

Address Interface State ID Pri Dead
172.16.112.2 ge-0/0/4.112 Full 172.30.30.1 128 31

lab@VMX-R5> show route table VPN1-SPOKE.inet.0 active-path | match 172.30

172.30.10.0/24 *[BGP/170] 05:27:38, MED 0, localpref 100, from 150.1.1.3
172.30.11.0/24 *[BGP/170] 05:27:38, MED 0, localpref 100, from 150.1.1.3
172.30.12.0/24 *[BGP/170] 05:27:38, MED 0, localpref 100, from 150.1.1.3
172.30.13.0/24 *[BGP/170] 05:27:38, MED 0, localpref 100, from 150.1.1.3
172.30.14.0/24 *[BGP/170] 05:27:38, MED 0, localpref 100, from 150.1.1.3
172.30.15.0/24 *[BGP/170] 05:27:38, MED 0, localpref 100, from 150.1.1.3
172.30.16.0/24 *[BGP/170] 05:27:38, MED 0, localpref 100, from 150.1.1.3
172.30.17.0/24 *[BGP/170] 05:27:38, MED 0, localpref 100, from 150.1.1.3
172.30.18.0/24 *[BGP/170] 05:27:38, MED 0, localpref 100, from 150.1.1.3
172.30.19.0/24 *[BGP/170] 05:27:38, MED 0, localpref 100, from 150.1.1.3
172.30.20.0/24 *[BGP/170] 05:25:02, MED 0, localpref 100, from 150.1.1.3
172.30.21.0/24 *[BGP/170] 05:25:02, MED 0, localpref 100, from 150.1.1.3
172.30.22.0/24 *[BGP/170] 05:25:02, MED 0, localpref 100, from 150.1.1.3
172.30.23.0/24 *[BGP/170] 05:25:02, MED 0, localpref 100, from 150.1.1.3
172.30.24.0/24 *[BGP/170] 05:25:02, MED 0, localpref 100, from 150.1.1.3
172.30.25.0/24 *[BGP/170] 05:25:02, MED 0, localpref 100, from 150.1.1.3
172.30.26.0/24 *[BGP/170] 05:25:02, MED 0, localpref 100, from 150.1.1.3
172.30.27.0/24 *[BGP/170] 05:25:02, MED 0, localpref 100, from 150.1.1.3
172.30.28.0/24 *[BGP/170] 05:25:02, MED 0, localpref 100, from 150.1.1.3
172.30.29.0/24 *[BGP/170] 05:25:02, MED 0, localpref 100, from 150.1.1.3
172.30.30.0/24 *[OSPF/150] 05:24:46, metric 0, tag 0
172.30.31.0/24 *[OSPF/150] 05:24:46, metric 0, tag 0
172.30.32.0/24 *[OSPF/150] 05:24:46, metric 0, tag 0

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
158
159 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

172.30.33.0/24 *[OSPF/150] 05:24:46, metric 0, tag 0

172.30.34.0/24 *[OSPF/150] 05:24:46, metric 0, tag 0
172.30.35.0/24 *[OSPF/150] 05:24:46, metric 0, tag 0
172.30.36.0/24 *[OSPF/150] 05:24:46, metric 0, tag 0
172.30.37.0/24 *[OSPF/150] 05:24:46, metric 0, tag 0
172.30.38.0/24 *[OSPF/150] 05:24:46, metric 0, tag 0
172.30.39.0/24 *[OSPF/150] 05:24:46, metric 0, tag 0
<snip>

PE router R1 has got two VRFs connecting to the hub CE1-1, one VRF receives routes from spoke CE1-2
and spoke CE1-3, then it advertises to the hub CE1-1. After that the hub CE1-1 re-advertises VPN1
routes back to PE router R1 but via the second VRF, from there the routes from spoke CE1-2 and spoke
CE1-3, including routes from the hub CE1-1 itself are propagated to the route reflectors. In order for PE
router R1 to accept all prefixes advertised by hub CE1-1 via the second VRF, the prefixes must not have
domain-tag associated. By default on PE router when redistributing MP-BGP routes into OSPF on a VRF,
all prefixes are tagged with a domain-tag value to prevent routing loops/feedback when such prefixes
arrive back at the PE router. However in this case, there is no routing loop/feedback, but the intention
to re-advertise back to PE router (Spoke VRF on PE --> Hub CE --> Hub VRF on PE) in order to create
indirect spoke-spoke connectivity across hub (rather than direct spoke-spoke). We would need to erase
any domain value with statement domain-vpn-tag 0.
lab@VMX-R1> show ospf database instance VPN1-SPOKE lsa-id 172.30.20.0 extensive
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern *172.30.20.0 172.16.118.1 0x80000008 1349 0x22 0x1286 36
mask 255.255.255.0
Topology default (ID 0)
Type: 2, Metric: 0, Fwd addr: 0.0.0.0, Tag: 0.0.0.0
Gen timer 00:27:30
Aging timer 00:37:30
Installed 00:22:29 ago, expires in 00:37:31, sent 00:22:27 ago
Last changed 05:31:28 ago, Change count: 1, Ours

lab@VMX-R1> show ospf database instance VPN1-HUB lsa-id 172.30.20.0 extensive

OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern 172.30.20.0 172.16.118.1 0x80000008 1394 0x22 0x1286 36
mask 255.255.255.0
Topology default (ID 0)
Type: 2, Metric: 0, Fwd addr: 0.0.0.0, Tag: 0.0.0.0
Aging timer 00:36:46
Installed 00:23:08 ago, expires in 00:36:46

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

Last changed 05:32:11 ago, Change count: 1

lab@VMX-R1> show route table VPN1-HUB.inet.0 172.30.20.0 active-path

VPN1-HUB.inet.0: 36 destinations, 36 routes (36 active, 0 holddown, 0 hidden)

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

172.30.20.0/24 *[OSPF/150] 00:00:54, metric 0, tag 0

> to 172.16.117.2 via ge-0/0/4.117

Now let’s deactivate this feature and we should see the prefixes being tagged with a value and the
second VRF would not accept it to prevent loop.
lab@VMX-R1# deactivate routing-instances VPN1-SPOKE protocols ospf domain-vpn-tag

[edit]
lab@VMX-R1# commit and-quit
commit complete
Exiting configuration mode

lab@VMX-R1> show ospf database instance VPN1-SPOKE lsa-id 172.30.20.0 extensive

lab@VMX-R1> show ospf database instance VPN1-HUB lsa-id 172.30.20.0 extensive

lab@VMX-R1> show ospf neighbor instance VPN1-HUB

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
159
160 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Address Interface State ID Pri Dead

172.16.117.2 ge-0/0/4.117 Full 172.30.10.1 128 31

lab@VMX-R1> show ospf neighbor instance VPN1-SPOKE

Address Interface State ID Pri Dead
172.16.118.2 ge-0/0/4.118 Full 172.30.10.1 128 33

lab@VMX-R1> show ospf database instance VPN1-SPOKE lsa-id 172.30.20.0 extensive

OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern *172.30.20.0 172.16.118.1 0x80000001 26 0xa2 0x6ac0 36
mask 255.255.255.0
Topology default (ID 0)
Type: 2, Metric: 0, Fwd addr: 0.0.0.0, Tag: 208.0.226.64
Gen timer 00:49:33
Aging timer 00:59:33
Installed 00:00:26 ago, expires in 00:59:34, sent 00:00:26 ago
Last changed 00:00:26 ago, Change count: 1, Ours

lab@VMX-R1> show ospf database instance VPN1-HUB lsa-id 172.30.20.0 extensive

OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern 172.30.20.0 172.16.118.1 0x80000001 34 0xa2 0x6ac0 36
mask 255.255.255.0
Topology default (ID 0)
Type: 2, Metric: 0, Fwd addr: 0.0.0.0, Tag: 208.0.226.64
Aging timer 00:59:26
Installed 00:00:32 ago, expires in 00:59:26
Last changed 00:00:32 ago, Change count: 1

lab@VMX-R1> show route table VPN1-HUB.inet.0 172.30.20.0 active-path | count

Count: 0 lines

Now let’s re-enable the feature and let’s ensure that the forwarding path between CE1-2 (connecting to
R2) and CE1-3 (connecting to R5) actually is across CE1-1 (connecting to R1). And also we should verify
full connectivity between the CE routers as well.
lab@VMX-VR> traceroute routing-instance CE1-2 source 172.30.20.1 172.30.30.1
traceroute to 172.30.30.1 (172.30.30.1) from 172.30.20.1, 30 hops max, 40 byte packets
1 172.16.103.1 (172.16.103.1) 10.747 ms 12.084 ms 14.923 ms
2 172.16.117.2 (172.16.117.2) 25.058 ms 24.401 ms 25.025 ms
3 172.16.118.1 (172.16.118.1) 25.013 ms 24.498 ms 24.980 ms
4 172.30.30.1 (172.30.30.1) 44.949 ms 44.392 ms 44.998 ms

lab@VMX-VR> ping rapid routing-instance CE1-1 source 172.30.10.1 172.30.20.1

PING 172.30.20.1 (172.30.20.1): 56 data bytes
!!!!!

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

--- 172.30.20.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 19.669/19.951/20.314/0.258 ms

lab@VMX-VR> ping rapid routing-instance CE1-1 source 172.30.10.1 172.30.30.1

lab@VMX-VR> ping rapid routing-instance CE1-2 source 172.30.20.1 172.30.30.1

Task 2 requires IPv6 routing/forwarding over MPLS domain to be configured so that customers can have
IPv6 reachability in a virtual private network. This refers to 6VPE implementation for Service Provider
Network 1 which requires the following:

• family inet6 unicast between PE and CE routers (if BGP is the selected routing protocol) to
exchange IPv6 routes. It is similar to family inet unicast which is for IPv4 stack. If the VRF is

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
160
161 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

IPv6-only, meaning that the virtual private network is IPv6, on the PE routers we would need to
statically configure BGP Router-ID, otherwise BGP session will not be able to form.
• family inet6-vpn unicast between iBGP neighbours to allocate labels for IPv6 prefixes over IPv4
iBGP sessions so that we don't need to enable native IPv6 iBGP sessions in the core network. It is
similar to family inet-vpn unicast which is for IPv4 stack.
• set protocols mpls ipv6-tunneling, we convert IPv4 next-hop being routers’ loopback address
in table inet.3 into IPv4-mapped IPv6 next-hop and install them into table inet6.3 for IPv6 label-
based forwarding.
• family inet6 on all core-facing interfaces, this is already configured as part of initial
configurations. There is no need for specific IPv6 address to be configured, but instead just the
activation of the IPv6 AFI on the interfaces.

Let’s ensure IPv6 BGP sessions are up between PE and CE routers and then verify IPv6 reachability
between CE4-1 and CE4-2 by generating some ping/traceroute tests. We do not see any MPLS node in
the traceroute as we are not decrementing TTL inside Service Provider 1 MPLS domain.
lab@VMX-R3> show bgp summary | match 65504
2016:172:16:127::2 65504 11 15 0 0 3:27 Establ

lab@VMX-R4> show bgp summary | match 65504

2016:172:16:128::2 65504 11 15 0 0 3:31 Establ

lab@VMX-VR> ping rapid routing-instance CE4-1 source 2016:172:30:90::1 2016:172:30:100::1

PING6(56=40+8+8 bytes) 2016:172:30:90::1 --> 2016:172:30:100::1
!!!!!
--- 2016:172:30:100::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 23.584/25.703/30.133/2.277 ms

lab@VMX-VR> traceroute routing-instance CE4-1 source 2016:172:30:90::1 2016:172:30:100::1

traceroute6 to 2016:172:30:100::1 (2016:172:30:100::1) from 2016:172:30:90::1, 64 hops
max, 12 byte packets
1 2016:172:16:127::1 (2016:172:16:127::1) 15.832 ms 14.337 ms 19.980 ms
2 2016:172:30:100::1 (2016:172:30:100::1) 34.949 ms 34.765 ms 34.945 ms

Task 3 specifically asks for Inter-AS MPLS L3 VPN Option B to be deployed between Service Provider
networks 1 and 2 for VPNv4 routes, which requires the following:

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

• family inet-vpn unicast between ASBR routers being R5,R6,R7,R8 to exchange IPv4 VPN routes.
• family inet-vpn unicast between ASBR routers of each Service Provider network with its
internal AS network. For R5, R6 we would need to establish this AFI between them and the
route reflectors being R3, R4. And for R7,R8 we just need to enable it between themselves.

The next requirement is to use different route-target values for Service Provider networks 1 and 2,
which probably makes sense as different networks normally would have different BGP community
systems. Thus, the challenge to be addressed would be setting BGP policies to rewrite route-target on
either side of the inter-AS connection so that once VPNv4 routes reach the other side, they are accepted
and properly imported into VRF. The BGP policies should have family inet-vpn referenced so that it
would have effect on VPNv4 routes, instead of regular IPv4 routes. Let’s ensure BGP sessions are up
between ASBR routers and then verify reachability between CE1-5 and CE1-1, CE1-2, CE1-3 by
generating some ping/traceroute tests. Also we should generate traceroute tests as well to ensure that
inter-AS spoke-spoke communication is still across the hub.
lab@VMX-R7> show bgp summary
<snip>

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
161
162 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

150.1.57.5 123456 33 17 0 3 42 Establ

bgp.l3vpn.0: 67/67/67/0
bgp.l3vpn-inet6.0: 14/14/14/0
VPN4.inet6.0: 14/14/14/0
151.1.1.8 78 15 17 0 2 42 Establ
bgp.l3vpn.0: 11/78/78/0
bgp.l3vpn-inet6.0: 0/14/14/0
VPN4.inet6.0: 0/14/14/0
<snip>

lab@VMX-R8> show bgp summary

<snip>
150.1.68.6 123456 4290 4343 0 4 46 Establ
bgp.l3vpn.0: 67/67/67/0
bgp.l3vpn-inet6.0: 14/14/14/0
VPN1.inet.0: 34/45/45/0
151.1.1.7 78 77 74 0 2 42 Establ
bgp.l3vpn.0: 0/67/67/0
bgp.l3vpn-inet6.0: 7/21/21/0
VPN1.inet.0: 0/45/45/0
<snip>

lab@VMX-VR> ping rapid routing-instance CE1-5 source 172.30.110.1 172.30.10.1

PING 172.30.10.1 (172.30.10.1): 56 data bytes
!!!!!
--- 172.30.10.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 29.754/30.916/34.762/1.931 ms

lab@VMX-VR> ping rapid routing-instance CE1-5 source 172.30.110.1 172.30.20.1

lab@VMX-VR> ping rapid routing-instance CE1-5 source 172.30.110.1 172.30.30.1

lab@VMX-VR> traceroute routing-instance CE1-5 source 172.30.110.1 172.30.20.1

traceroute to 172.30.20.1 (172.30.20.1) from 172.30.110.1, 30 hops max, 40 byte packets
1 172.16.129.1 (172.16.129.1) 14.666 ms 14.215 ms 15.049 ms
2 * * *
3 150.1.13.1 (150.1.13.1) 50.268 ms 49.208 ms 50.172 ms
MPLS Label=299808 CoS=0 TTL=1 S=1
4 172.16.117.2 (172.16.117.2) 39.745 ms 44.295 ms 49.992 ms

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

5 172.16.118.1 (172.16.118.1) 49.998 ms 49.014 ms 50.008 ms
6 172.30.20.1 (172.30.20.1) 60.001 ms 64.065 ms 69.960 ms

lab@VMX-VR> traceroute routing-instance CE1-5 source 172.30.110.1 172.30.30.1

traceroute to 172.30.30.1 (172.30.30.1) from 172.30.110.1, 30 hops max, 40 byte packets
1 172.16.129.1 (172.16.129.1) 14.691 ms 9.355 ms 15.030 ms
2 * * *
3 150.1.13.1 (150.1.13.1) 50.470 ms 44.114 ms 50.008 ms
MPLS Label=299808 CoS=0 TTL=1 S=1
4 172.16.117.2 (172.16.117.2) 49.884 ms 39.275 ms 50.016 ms
5 172.16.118.1 (172.16.118.1) 45.159 ms 48.956 ms 49.986 ms
6 172.30.30.1 (172.30.30.1) 79.980 ms 74.401 ms 74.750 ms

Task 4 specifically asks for Inter-AS MPLS L3 VPN Option B to be deployed between Service Provider
networks 1 and 2 for VPNv6 routes, which requires the following:

• family inet6-vpn unicast between ASBR routers being R5,R6,R7,R8 to exchange VPNv6 routes.
• family inet6-vpn unicast between ASBR routers of each Service Provider network with its
internal AS network. For R5, R6 we would need to establish this AFI between them and the
route reflectors being R3, R4. And for R7,R8 we just need to enable it between themselves.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
162
163 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

• set protocols mpls ipv6-tunneling, we convert IPv4 next-hop being routers’ loopback address
in table inet.3 into IPv4-mapped IPv6 next-hop and install them into table inet6.3 for IPv6 label-
based forwarding. This command is needed on all ASBR routers.
• IPv4-mapped IPv6 addresses on the ASBR-ASBR links, because according to section 3.2.1.2 of
RFC4659, VPNv6 routes advertised over an IPv4 based MP-eBGP session, their NEXT_HOP
attribute is translated to an IPv4-mapped IPv6 address for forwarding consistency and sanity
purposes.

Let’s ensure BGP sessions are up between ASBR routers and then verify reachability between CE4-3 and
CE4-1, CE4-2 by generating some ping/traceroute tests.
lab@VMX-VR> ping rapid routing-instance CE4-3 source 2016:172:30:120::1 2016:172:30:90::1
PING6(56=40+8+8 bytes) 2016:172:30:120::1 --> 2016:172:30:90::1
!!!!!
--- 2016:172:30:90::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 29.426/29.853/29.979/0.214 ms

lab@VMX-VR> ping rapid routing-instance CE4-3 source 2016:172:30:120::1

2016:172:30:100::1
PING6(56=40+8+8 bytes) 2016:172:30:120::1 --> 2016:172:30:100::1
!!!!!
--- 2016:172:30:100::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 29.438/29.868/30.296/0.343 ms

lab@VMX-VR> traceroute routing-instance CE4-3 source 2016:172:30:120::1 2016:172:30:90::1

traceroute6 to 2016:172:30:90::1 (2016:172:30:90::1) from 2016:172:30:120::1, 64 hops
max, 12 byte packets
1 2016:172:16:125::1 (2016:172:16:125::1) 19.458 ms 17.323 ms 12.681 ms
2 * * *
3 2016:150:1:35::3 (2016:150:1:35::3) 25.404 ms 24.363 ms 29.764 ms

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

MPLS Label=300304 CoS=0 TTL=1 S=1
4 2016:172:30:90::1 (2016:172:30:90::1) 30.177 ms 29.908 ms 29.909 ms

lab@VMX-VR> traceroute routing-instance CE4-3 source 2016:172:30:120::1

2016:172:30:100::1
traceroute6 to 2016:172:30:100::1 (2016:172:30:100::1) from 2016:172:30:120::1, 64 hops
max, 12 byte packets
1 2016:172:16:125::1 (2016:172:16:125::1) 14.970 ms 15.165 ms 15.141 ms
2 * * *
3 2016:150:1:45::4 (2016:150:1:45::4) 25.450 ms 24.401 ms 29.492 ms
MPLS Label=300208 CoS=0 TTL=1 S=1
4 2016:172:30:100::1 (2016:172:30:100::1) 30.395 ms 29.718 ms 30.193 ms

Topic 6: CoS
Total Points: 5

Task 1 (5 points). Ensure that IPv4 and IPv6 between customers C1 and C4 traverse different LSPs across
the network of SP1.
R1
!
edit protocols mpls
set label-switched-path R1-TO-R6-TUN3 to 150.1.1.6 inter-domain

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
163
164 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set label-switched-path R1-TO-R6-TUN4 to 150.1.1.6 inter-domain

exit
edit policy-options policy-statement C4-LSP-MAPPING
set term 1 from protocol bgp
set term 1 from community C4
set term 1 from family inet
set term 1 then install-nexthop lsp-regex R1-TO-R6-TUN[13]
set term 1 then accept
set term 6 from protocol bgp
set term 6 from community C4
set term 6 from family inet6
set term 6 then install-nexthop lsp-regex R1-TO-R6-TUN[24]
set term 6 then accept
exit
set policy-options community C1 members 16:3010
set policy-options community C4 members 16:3040
set policy-options policy-statement C1-IN-INET term 1 then community add C1
set policy-options policy-statement C1-IN-INET6 term 1 then community add C1
delete routing-options forwarding-table export ECMP
set routing-options forwarding-table export [C4-LSP-MAPPING ECMP]

R6
!
edit protocols mpls
set label-switched-path R6-TO-R1-TUN3 to 150.1.1.1 inter-domain
set label-switched-path R6-TO-R1-TUN4 to 150.1.1.1 inter-domain
exit
edit policy-options policy-statement C1-LSP-MAPPING
set term 1 from protocol bgp
set term 1 from community C1
set term 1 from family inet
set term 1 then install-nexthop lsp-regex R6-TO-R1-TUN[13]
set term 1 then accept
set term 6 from protocol bgp
set term 6 from community C1
set term 6 from family inet6
set term 6 then install-nexthop lsp-regex R6-TO-R1-TUN[24]
set term 6 then accept
exit
set policy-options community C1 members 16:3010
set policy-options community C4 members 16:3040
set policy-options policy-statement C4-IN-INET term 1 then community add C4
set policy-options policy-statement C4-IN-INET6 term 1 then community add C4
delete routing-options forwarding-table export ECMP
set routing-options forwarding-table export [C1-LSP-MAPPING ECMP]

Verification
The only task of Practice Lab 2, topic 6 is about mapping certain traffic onto MPLS LSPs. Between R1 and

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

R6, we already have created two LSPs between R1 and R6 and we can simply map IPv4 traffic to TUN1
and IPv6 to TUN2. However that would not be compliant with topc 3, task 2 which requires “ensure big
chunks of traffic between each pair of routers can be broken into smaller portions to be fit across the
network paths”. Having said that, the topic 3, task 2 does not limit us to create more LSPs. This way we
can spread IPv4 traffic onto multiple LSPs and also at the same time, spread IPv6 traffic onto multiple
different LSPs. We use the statement install-nexthop lsp-regex to perform such mapping. The value
coming along with that statement is in form of regular expression. The other issue is to tag routes
received from customers C1 and C4 with a community in the inbound direction. Now let’s check the
mapping on forwarding plane.
lab@VMX-R1> show route community-name C4 table inet.0 active-path

inet.0: 103 destinations, 194 routes (85 active, 0 holddown, 30 hidden)

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

170.1.240.0/24 *[BGP/170] 00:28:01, localpref 100, from 150.1.1.3

AS path: 65004 I, validation-state: unverified
to 150.1.13.3 via ge-0/0/6.0, label-switched-path R1-TO-R6-TUN1
to 150.1.13.3 via ge-0/0/6.0, label-switched-path R1-TO-R6-TUN3
to 150.1.12.2 via ae0.0, label-switched-path Bypass->150.1.13.3-
>150.1.35.5

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
164
165 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

to 150.1.12.2 via ae0.0, label-switched-path Bypass->150.1.13.3-

>150.1.35.5
170.1.241.0/24 *[BGP/170] 00:28:01, localpref 100, from 150.1.1.3
AS path: 65004 I, validation-state: unverified
to 150.1.13.3 via ge-0/0/6.0, label-switched-path R1-TO-R6-TUN1
to 150.1.13.3 via ge-0/0/6.0, label-switched-path R1-TO-R6-TUN3
to 150.1.12.2 via ae0.0, label-switched-path Bypass->150.1.13.3-
>150.1.35.5
to 150.1.12.2 via ae0.0, label-switched-path Bypass->150.1.13.3-
>150.1.35.5
<snip>

lab@VMX-R1> show route community-name C4 table inet6.0 active-path

inet6.0: 66 destinations, 125 routes (56 active, 0 holddown, 19 hidden)

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

2016:170:1:240::/64*[BGP/170] 00:00:34, localpref 100, from 150.1.1.3

AS path: 65004 I, validation-state: unverified
to 150.1.13.3 via ge-0/0/6.0, label-switched-path R1-TO-R6-TUN2
to 150.1.13.3 via ge-0/0/6.0, label-switched-path R1-TO-R6-TUN4
to 150.1.12.2 via ae0.0, label-switched-path Bypass->150.1.13.3-
>150.1.35.5
to 150.1.12.2 via ae0.0, label-switched-path Bypass->150.1.13.3-
>150.1.35.5
2016:170:1:241::/64*[BGP/170] 00:00:34, localpref 100, from 150.1.1.3
AS path: 65004 I, validation-state: unverified
to 150.1.13.3 via ge-0/0/6.0, label-switched-path R1-TO-R6-TUN2
to 150.1.13.3 via ge-0/0/6.0, label-switched-path R1-TO-R6-TUN4
to 150.1.12.2 via ae0.0, label-switched-path Bypass->150.1.13.3-
>150.1.35.5
to 150.1.12.2 via ae0.0, label-switched-path Bypass->150.1.13.3-
>150.1.35.5
<snip>

lab@VMX-R6> show route community-name C1 table inet.0 active-path

inet.0: 103 destinations, 176 routes (87 active, 0 holddown, 16 hidden)

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

170.1.210.0/24 *[BGP/170] 00:03:10, localpref 100, from 150.1.1.3

AS path: 65001 I, validation-state: unverified
to 150.1.56.5 via ae0.0, label-switched-path R6-TO-R1-TUN1
to 150.1.46.4 via ge-0/0/7.0, label-switched-path R6-TO-R1-TUN3
to 150.1.46.4 via ge-0/0/7.0, label-switched-path Bypass-
>150.1.56.5->150.1.35.3
to 150.1.56.5 via ae0.0, label-switched-path Bypass->150.1.46.4-
>150.1.24.2
170.1.211.0/24 *[BGP/170] 00:03:10, localpref 100, from 150.1.1.3
AS path: 65001 I, validation-state: unverified

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

to 150.1.56.5 via ae0.0, label-switched-path R6-TO-R1-TUN1
to 150.1.46.4 via ge-0/0/7.0, label-switched-path R6-TO-R1-TUN3
to 150.1.46.4 via ge-0/0/7.0, label-switched-path Bypass-
>150.1.56.5->150.1.35.3
to 150.1.56.5 via ae0.0, label-switched-path Bypass->150.1.46.4-
>150.1.24.2
170.1.212.0/24 *[BGP/170] 00:03:10, localpref 100, from 150.1.1.3
<snip>

lab@VMX-R6> show route community-name C1 table inet6.0 active-path

inet6.0: 66 destinations, 121 routes (57 active, 0 holddown, 9 hidden)

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

2016:170:1:210::/64*[BGP/170] 00:16:49, localpref 100, from 150.1.1.3

AS path: 65001 I, validation-state: unverified
to 150.1.56.5 via ae0.0, label-switched-path R6-TO-R1-TUN2
to 150.1.46.4 via ge-0/0/7.0, label-switched-path R6-TO-R1-TUN4
to 150.1.46.4 via ge-0/0/7.0, label-switched-path Bypass-
>150.1.56.5->150.1.35.3
to 150.1.56.5 via ae0.0, label-switched-path Bypass->150.1.46.4-
>150.1.24.2
2016:170:1:211::/64*[BGP/170] 00:16:49, localpref 100, from 150.1.1.3
AS path: 65001 I, validation-state: unverified
to 150.1.56.5 via ae0.0, label-switched-path R6-TO-R1-TUN2
to 150.1.46.4 via ge-0/0/7.0, label-switched-path R6-TO-R1-TUN4

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
165
166 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

to 150.1.46.4 via ge-0/0/7.0, label-switched-path Bypass-

>150.1.56.5->150.1.35.3
to 150.1.56.5 via ae0.0, label-switched-path Bypass->150.1.46.4-
>150.1.24.2
<snip>

End of Practice Lab 2 Solutions!

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 2 Solutions

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
166
167 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Practice Lab 3 Solutions

Topic 1: Device Infrastructure

Total Points: 14

• LAG ae0 consists of ports ge-0/0/1 and ge-0/0/2, ensure that the LAG stays up only if all
member interfaces are up.
• LAG ae6 consists of port ge-0/0/6, except for R5-R7 and R6-R8 connections.
• LAG ae7 consists of port ge-0/0/7.
• LAG ae8 consists of port ge-0/0/8.
R1
!
set chassis aggregated-devices ethernet device-count 7
set interfaces ge-0/0/1 gigether-options 802.3ad ae0
set interfaces ge-0/0/2 gigether-options 802.3ad ae0
set interfaces ge-0/0/6 gigether-options 802.3ad ae6
set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 aggregated-ether-options minimum-links 2
set interfaces ae0.0 desc R1-R2 family inet address 150.1.12.1/24
set interfaces ae0.0 desc R1-R2 family inet6 address 2016:150:1:12::1/64
set interfaces ae6 aggregated-ether-options lacp active
set interfaces ae6.0 desc R1-R3 family inet address 150.1.13.1/24
set interfaces ae6.0 desc R1-R3 family inet6 address 2016:150:1:13::1/64

R2
!
set chassis aggregated-devices ethernet device-count 7
set interfaces ge-0/0/1 gigether-options 802.3ad ae0
set interfaces ge-0/0/2 gigether-options 802.3ad ae0
set interfaces ge-0/0/6 gigether-options 802.3ad ae6

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 aggregated-ether-options minimum-links 2
set interfaces ae0.0 desc R2-R1 family inet address 150.1.12.2/24
set interfaces ae0.0 desc R2-R1 family inet6 address 2016:150:1:12::2/64
set interfaces ae6 aggregated-ether-options lacp active
set interfaces ae6.0 desc R2-R4 family inet address 150.1.24.2/24
set interfaces ae6.0 desc R2-R4 family inet6 address 2016:150:1:24::2/64

R3
!
set chassis aggregated-devices ethernet device-count 8
set interfaces ge-0/0/1 gigether-options 802.3ad ae0
set interfaces ge-0/0/2 gigether-options 802.3ad ae0
set interfaces ge-0/0/6 gigether-options 802.3ad ae6
set interfaces ge-0/0/7 gigether-options 802.3ad ae7
set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 aggregated-ether-options minimum-links 2
set interfaces ae0.0 desc R3-R4 family inet address 150.1.34.3/24
set interfaces ae0.0 desc R3-R4 family inet6 address 2016:150:1:34::3/64
set interfaces ae6 aggregated-ether-options lacp active
set interfaces ae6.0 desc R3-R1 family inet address 150.1.13.3/24
set interfaces ae6.0 desc R3-R1 family inet6 address 2016:150:1:13::3/64
set interfaces ae7 aggregated-ether-options lacp active
set interfaces ae7.0 desc R3-R5 family inet address 150.1.35.3/24
set interfaces ae7.0 desc R3-R5 family inet6 address 2016:150:1:35::3/64

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
167
168 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

R4
!
set chassis aggregated-devices ethernet device-count 9
set interfaces ge-0/0/1 gigether-options 802.3ad ae0
set interfaces ge-0/0/2 gigether-options 802.3ad ae0
set interfaces ge-0/0/6 gigether-options 802.3ad ae6
set interfaces ge-0/0/7 gigether-options 802.3ad ae7
set interfaces ge-0/0/8 gigether-options 802.3ad ae8
set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 aggregated-ether-options minimum-links 2
set interfaces ae0.0 desc R4-R3 family inet address 150.1.34.4/24
set interfaces ae0.0 desc R4-R3 family inet6 address 2016:150:1:34::4/64
set interfaces ae6 aggregated-ether-options lacp active
set interfaces ae6.0 desc R4-R2 family inet address 150.1.24.4/24
set interfaces ae6.0 desc R4-R2 family inet6 address 2016:150:1:24::4/64
set interfaces ae7 aggregated-ether-options lacp active
set interfaces ae7.0 desc R4-R6 family inet address 150.1.46.4/24
set interfaces ae7.0 desc R4-R6 family inet6 address 2016:150:1:46::4/64
set interfaces ae8 aggregated-ether-options lacp active
set interfaces ae8.0 desc R4-R5 family inet address 150.1.45.4/24
set interfaces ae8.0 desc R4-R5 family inet6 address 2016:150:1:45::4/64

R5
!
set chassis aggregated-devices ethernet device-count 9
set interfaces ge-0/0/1 gigether-options 802.3ad ae0
set interfaces ge-0/0/2 gigether-options 802.3ad ae0
set interfaces ge-0/0/7 gigether-options 802.3ad ae7
set interfaces ge-0/0/8 gigether-options 802.3ad ae8
set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 aggregated-ether-options minimum-links 2
set interfaces ae0.0 desc R5-R6 family inet address 150.1.56.5/24
set interfaces ae0.0 desc R5-R6 family inet6 address 2016:150:1:56::5/64
set interfaces ae7 aggregated-ether-options lacp active
set interfaces ae7.0 desc R5-R3 family inet address 150.1.35.5/24
set interfaces ae7.0 desc R5-R3 family inet6 address 2016:150:1:35::5/64
set interfaces ae8 aggregated-ether-options lacp active
set interfaces ae8.0 desc R5-R4 family inet address 150.1.45.5/24
set interfaces ae8.0 desc R5-R4 family inet6 address 2016:150:1:45::5/64

R6
!
set chassis aggregated-devices ethernet device-count 8
set interfaces ge-0/0/1 gigether-options 802.3ad ae0
set interfaces ge-0/0/2 gigether-options 802.3ad ae0
set interfaces ge-0/0/7 gigether-options 802.3ad ae7
set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 aggregated-ether-options minimum-links 2
set interfaces ae0.0 desc R6-R5 family inet address 150.1.56.6/24
set interfaces ae0.0 desc R6-R5 family inet6 address 2016:150:1:56::6/64

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

set interfaces ae7 aggregated-ether-options lacp active
set interfaces ae7.0 desc R6-R4 family inet address 150.1.46.6/24
set interfaces ae7.0 desc R6-R4 family inet6 address 2016:150:1:46::6/64

R7
!
set chassis aggregated-devices ethernet device-count 1
set interfaces ge-0/0/1 gigether-options 802.3ad ae0
set interfaces ge-0/0/2 gigether-options 802.3ad ae0
set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 aggregated-ether-options minimum-links 2
set interfaces ae0.0 desc R7-R8 family inet address 151.1.78.7/24
set interfaces ae0.0 desc R7-R8 family inet6 address 2016:151:1:78::7/64

R8
!
set chassis aggregated-devices ethernet device-count 1
set interfaces ge-0/0/1 gigether-options 802.3ad ae0
set interfaces ge-0/0/2 gigether-options 802.3ad ae0
set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 aggregated-ether-options minimum-links 2
set interfaces ae0.0 desc R8-R7 family inet address 151.1.78.8/24
set interfaces ae0.0 desc R8-R7 family inet6 address 2016:151:1:78::8/64

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
168
169 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

R1,R2,R3,R4,R5,R6,R7,R8
!
edit system syslog file syslog
set any warning
set daemon info
set interactive-command any
set explicit-priority
exit
edit system syslog file messages
set any warning
set firewall none
set interactive-command none
set explicit-priority
exit
edit system syslog file firewall
set firewall any
set explicit-priority
exit
edit system syslog file mpls
set match ".*RPD_(RSVP|MPLS).*"
set daemon warning
set explicit-priority
exit

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

set virtual-address 150.1.136.1
set priority 129
set authentication-type md5
set authentication-key JNCIE-SP
set track interface ae0.0 priority 10
set track interface ae6.0 priority 10
set track interface ae7.0 priority 10
exit
set interfaces ge-0/0/4 unit 136 family inet6 address fe80:150:1:136::3/64
edit interfaces ge-0/0/4 unit 136 family inet6 address 2016:150:1:136::3/64 vrrp-inet6-
group 136
set virtual-inet6-address 2016:150:1:136::1
set virtual-link-local-address fe80:150:1:136::1
set priority 100
exit
edit protocols router-advertisement
set interface ge-0/0/4.136 prefix 2016:150:1:136::/64
exit

R5
!
edit interface ge-0/0/4.136 family inet address 150.1.136.5/24 vrrp-group 136
set virtual-address 150.1.136.1
set priority 100
set authentication-type md5
set authentication-key JNCIE-SP
exit

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
169
170 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set interfaces ge-0/0/4 unit 136 family inet6 address fe80:150:1:136::5/64

edit interfaces ge-0/0/4 unit 136 family inet6 address 2016:150:1:136::5/64 vrrp-inet6-
group 136
set virtual-inet6-add 2016:150:1:136::1
set virtual-link-local-address fe80:150:1:136::1
set priority 129
set track interface ae0.0 priority 10
set track interface ae7.0 priority 10
set track interface ae8.0 priority 10
exit
edit protocols router-advertisement
set interface ge-0/0/4.136 prefix 2016:150:1:136::/64
exit

Task 5 (3 points). Configure all routers in Service Provider Network 1 to sample 1 out of 1000 transiting
IPv4 packets coming in/out via interfaces connecting to external networks (except for MPLS L3/L2VPN
links). There should be no more than 5000 sampled packets per second. All routers should store
sampling data in series of file sampling.log and send to remote server 10.10.1.77 on port 9996. The
number of local files should not exceed 10 with 5MB per file.
R1,R2,R3,R4,R5,R6
!
set firewall family inet filter ACL-OUTSIDE-IN term SAMPLING then sample
set firewall family inet filter ACL-OUTSIDE-IN term SAMPLING then accept
edit forwarding-options sampling
set input rate 1000
set input max-packets-per-second 5000
set family inet output file filename sampling.log files 10 size 5m
set family inet output flow-server 10.10.1.77 version 5
set family inet output flow-server 10.10.1.77 port 9996
exit
set system ntp server 10.10.1.77

R1
!
edit interfaces
set ge-0/0/4.100 family inet filter input ACL-OUTSIDE-IN
set ge-0/0/4.106 family inet filter input ACL-OUTSIDE-IN
set ge-0/0/4.119 family inet filter input ACL-OUTSIDE-IN
set ge-0/0/4.120 family inet filter input ACL-OUTSIDE-IN
set ge-0/0/4.100 family inet sampling input output
set ge-0/0/4.106 family inet sampling input output
set ge-0/0/4.119 family inet sampling input output
set ge-0/0/4.120 family inet sampling input output
exit

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

R2
!
edit interfaces
set ge-0/0/4.101 family inet filter input ACL-OUTSIDE-IN
set ge-0/0/4.123 family inet filter input ACL-OUTSIDE-IN
set ge-0/0/4.102 family inet filter input ACL-OUTSIDE-IN
set ge-0/0/4.113 family inet filter input ACL-OUTSIDE-IN
set ge-0/0/4.101 family inet sampling input output
set ge-0/0/4.123 family inet sampling input output
set ge-0/0/4.102 family inet sampling input output
set ge-0/0/4.113 family inet sampling input output
exit

R3
!
edit interfaces
set ge-0/0/4.137 family inet filter input ACL-OUTSIDE-IN
set ge-0/0/4.137 family inet sampling input output
exit

R4
!
edit interfaces
set ge-0/0/4.105 family inet filter input ACL-OUTSIDE-IN
set ge-0/0/4.105 family inet sampling input output
exit

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
170
171 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

R5
!
edit interfaces
set ge-0/0/6.0 family inet filter input ACL-OUTSIDE-IN
set ge-0/0/6.0 family inet sampling input output
exit

R6
!
edit interfaces
set ge-0/0/4.131 family inet filter input ACL-OUTSIDE-IN
set ge-0/0/6.0 family inet filter input ACL-OUTSIDE-IN
set ge-0/0/4.131 family inet sampling input output
set ge-0/0/6.0 family inet sampling input output
exit

Task 6 (1 point). Configure all routers so that the SP Core Networks can handle jumbo Ethernet frames
as well as variable packets of MPLS L3/L2 VPN, MPLS TE and FRR services without fragmentation

R1,R2,R3,R4,R5,R6
!
set groups CORE-INTERFACES interfaces <ae*> mtu 2000
set apply-groups CORE-INTERFACES

Verification
Task 1. System configuration should be annotated as below. Perform the same command on all routers
R1->R8 to ensure annotation is put in all routers’ configuration.
lab@VMX-R3> show configuration | find "Config made"
/* Config made by Tony Tuan Nguyen, 2017-01-16 */
system {
<snip-for-brevity>
}

Task 2. In order to configure LAG number higher than 0, we need to define the highest LAG number that
the system supports with statement chassis aggregated-devices ethernet device-count <nbr>. The
number to be configured must be one higher than the highest LAG number, e.g. <nbr> = 8 for the LAG
ae7 to be valid. LACP port bundling should come up as below, i.e. both ports show ‘distributing’ state
and ‘Active’ participation. Perform the same command on all routers R1->R8 to check LACP operations
across all LAGs. By default, the LACP actor and partner send LACP packets every second already but we

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

can explicitly configure that.
lab@VMX-R1> show lacp interfaces
Aggregated interface: ae0
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
ge-0/0/1 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/1 Partner No No Yes Yes Yes Yes Fast Active
ge-0/0/2 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/2 Partner No No Yes Yes Yes Yes Fast Active
LACP protocol: Receive State Transmit State Mux State
ge-0/0/1 Current Fast periodic Collecting distributing
ge-0/0/2 Current Fast periodic Collecting distributing

Aggregated interface: ae6

LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
ge-0/0/6 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/6 Partner No No Yes Yes Yes Yes Fast Active
LACP protocol: Receive State Transmit State Mux State
ge-0/0/6 Current Fast periodic Collecting distributing

lab@VMX-R3> show lacp interfaces

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
171
172 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

LACP protocol: Receive State Transmit State Mux State

ge-0/0/1 Current Fast periodic Collecting distributing
ge-0/0/2 Current Fast periodic Collecting distributing

Aggregated interface: ae6

Aggregated interface: ae7

LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
ge-0/0/7 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/7 Partner No No Yes Yes Yes Yes Fast Active
LACP protocol: Receive State Transmit State Mux State
ge-0/0/7 Current Fast periodic Collecting distributing

Task 3. It is recommended to sub-divide different syslog messages into different files for easy
monitoring and troubleshooting. In this case we should have syslog, messages, firewall and mpls files.
lab@VMX-R1> show log syslog
Sep 28 03:00:00 R1 newsyslog[1553]: logfile turned over due to size>1024K
Sep 28 03:00:03 R1 sshd[1555]: %AUTH-3: error: Could not load host key:
/etc/ssh/ssh_host_ecdsa_key
Sep 28 03:00:05 R1 bfdd[1148]: %DAEMON-6-BFDD_TRAP_STATE_UP: local discriminator: 6, new
state: up
Sep 28 03:00:07 R1 mgd[1568]: %INTERACT-6-UI_AUTH_EVENT: Authenticated user 'juniper' at
permission level 'j-super-user'
Sep 28 03:00:07 R1 mgd[1568]: %INTERACT-6-UI_LOGIN_EVENT: User 'juniper' login, class
'j-super-user' [1568], ssh-connection '10.233.244.1 53184 10.233.248.47 22', client-mode
'cli'
Sep 28 03:00:08 R1 bfdd[1148]: %DAEMON-6-BFDD_TRAP_STATE_UP: local discriminator: 7, new
state: up
Sep 28 03:00:09 R1 bfdd[1148]: %DAEMON-6-BFDD_TRAP_STATE_UP: local discriminator: 8, new
state: up
Sep 28 03:00:11 R1 bfdd[1148]: %DAEMON-6-BFDD_TRAP_STATE_UP: local discriminator: 9, new
state: up
<snip>

lab@VMX-R1> show log mpls

Sep 23 21:09:12 R1 rpd[1197]: %DAEMON-4-RPD_MPLS_PATH_UP: MPLS path up on LSP R1-TO-R3
path bandwidth 0 bps
Sep 23 21:09:12 R1 rpd[1197]: %DAEMON-4-RPD_MPLS_LSP_UP: MPLS LSP R1-TO-R3 up on
primary() Route 150.1.1.3(flag=0x20) 150.1.13.3(Label=0) lsp bandwidth 0 bps
Sep 23 21:09:13 R1 rpd[1197]: %DAEMON-4-RPD_MPLS_PATH_UP: MPLS path up on LSP R1-TO-R2
path bandwidth 0 bps
Sep 23 21:09:13 R1 rpd[1197]: %DAEMON-4-RPD_MPLS_LSP_UP: MPLS LSP R1-TO-R2 up on

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

primary() Route 150.1.1.2(flag=0x20) 150.1.12.2(Label=0) lsp bandwidth 0 bps
Sep 23 21:09:13 R1 rpd[1197]: %DAEMON-4-RPD_RSVP_NBRUP: RSVP neighbor 150.1.13.3 up on
interface ae6.0
Sep 23 21:09:32 R1 rpd[1197]: %DAEMON-4-RPD_RSVP_NBRUP: RSVP neighbor 150.1.12.2 up on
interface ae0.0
Sep 23 21:28:46 R1 rpd[1197]: %DAEMON-4-RPD_MPLS_PATH_UP: MPLS path up on LSP R1-TO-R5
path bandwidth 0 bps
Sep 23 21:28:46 R1 rpd[1197]: %DAEMON-4-RPD_MPLS_LSP_UP: MPLS LSP R1-TO-R5 up on
primary() Route 150.1.1.3(flag=0x20) 150.1.13.3(Label=300560) 150.1.1.4(flag=0x21)
150.1.34.4(flag=1 Label=300512) 150.1.1.5(flag=0x20) 150.1.45.5(Label=0) lsp bandwidth 0
bps
<snip>

Task 4. In this task VRRP configurations for both IPv4 and IPv6 are required. We simply load-share traffic
across R3 and R5 by designating each of them as the master router for IPv4 and IPv6 traffic respectively.
For IPv6, the VRRP routers can advertise the subnet address in RA messages, allowing for
autoconfiguration of IPv6 hosts along with the default gateway address.
lab@VMX-R3> show vrrp brief
Interface State Group VR state VR Mode Timer Type Address
ge-0/0/4.136 up 136 master Active A 0.390 lcl 150.1.136.3
vip 150.1.136.1
ge-0/0/4.136 up 136 backup Active D 3.309 lcl 2016:150:1:136::3
vip fe80:150:1:136::1

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
172
173 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

vip 2016:150:1:136::1
mas fe80:150:1:136::5

lab@VMX-R5> show vrrp brief

Interface State Group VR state VR Mode Timer Type Address
ge-0/0/4.136 up 136 backup Active D 3.218 lcl 150.1.136.5
vip 150.1.136.1
mas 150.1.136.3
ge-0/0/4.136 up 136 master Active A 0.497 lcl 2016:150:1:136::5
vip fe80:150:1:136::1
vip 2016:150:1:136::1

lab@VMX-R3> show ipv6 router-advertisement

Interface: ge-0/0/4.136
Advertisements sent: 9, last sent 00:01:37 ago
Solicits received: 0
Advertisements received: 8
Advertisement from fe80:150:1:136::5, heard 00:09:29 ago
Managed: 0
Other configuration: 0
Reachable time: 0 ms
Default lifetime: 1800 sec
Retransmit timer: 0 ms
Current hop limit: 64
Prefix: 2016:150:1:136::/64
Valid lifetime: 2592000 sec
Preferred lifetime: 604800 sec
On link: 1
Autonomous: 1

lab@VMX-R5> show ipv6 router-advertisement

Interface: ge-0/0/4.136
Advertisements sent: 8, last sent 00:07:40 ago
Solicits received: 0
Advertisements received: 8
Advertisement from fe80:150:1:136::3, heard 00:08:57 ago
Managed: 0
Other configuration: 0
Reachable time: 0 ms
Default lifetime: 1800 sec
Retransmit timer: 0 ms
Current hop limit: 64
Prefix: 2016:150:1:136::/64
Valid lifetime: 2592000 sec
Preferred lifetime: 604800 sec
On link: 1
Autonomous: 1

Task 5. JUNOS’s traffic sampling allows you to replicate traffic on the forwarding plane for accounting

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

purpose at three locations below:

• At Routing Engine (RE) level using sampling process configured via a firewall filter with
keyword then sample.

• On specialised cards such as Monitoring Services, Adaptive Services, or Multiservices PICs.

• On an inline forwarding path right at Flexible PIC Concentrator (FPC) level.

If you set up a NetFlow server on address 10.10.1.77, you should be able to see NetFlow messages
coming in from all routers R1->R6. However, locally on the routers, traffic sampling results are
automatically saved in the path /var/tmp even if we do not specify a file name along with its parameters
such as number of files and size of each file. In this task our file is named as sampling.log. It may take
some time for the router to populate data into this file.
lab@VMX-R1> file show /var/tmp/sampling.log
# Jan 18 22:40:12
# Dest Src Dest Src Proto TOS Pkt Intf IP TCP
# addr addr port port len num frag flags
170.1.210.1 111.0.0.1 0 0 1 0x0 84 334 0x0 0x0
170.1.240.1 170.1.210.1 2048 0 1 0x0 84 333 0x0 0x0

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
173
174 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

172.16.118.1 172.16.118.2 61547 179 6 0xc0 71 345 0x0 0x18

Task 6. By default an Ethernet frame would have an MTU value of 1500 bytes for the payload. A jumbo
Ethernet frame increases MTU up to 9000 bytes to allow a significant amount of data transferred with
less resources utilised as the number of frames needed to process the same chunk of data is reduced
effectively.
lab@VMX-R1> show interfaces ae0 | match MTU
Link-level type: Ethernet, MTU: 2000, Speed: 2Gbps, BPDU Error: None, MAC-REWRITE
Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Disabled
Protocol inet, MTU: 1986
Protocol inet6, MTU: 1986
Protocol multiservice, MTU: Unlimited

Best practices indicate that MTU value must be matched on both sides of an Ethernet link, otherwise
there would be issues such as flapping protocol neighbourship, overflow buffering on the side that has
got smaller MTU value or even OSPF would not come up at all. This task can be indirectly verified in the
upcoming ones where we should not see OSPF neighbourships get stuck in EXSTART phase which is
normally due to MTU mismatch. Another point of this task is that it uses group-based configuration to
avoid per-LAG/link MTU configuration, ensuring that the MTU value is identical across LAG/link without
any risk of a typo mistake being made jeopardising the network.

Topic 2: IGP
Total Points: 12

R1,R2,R3,R4,R5,R6
!
edit groups CORE-INTERFACES
set interfaces <ae*> unit 0 family iso
set protocols isis interface <ae*.0> point-to-point

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

set protocols isis interface <ae*.0> hello-authentication-type md5
set protocols isis interface <ae*.0> hello-authentication-key JNCIE
exit
set apply-groups CORE-INTERFACES
set protocols isis reference-bandwidth 100g
set protocols isis interface lo0.0 passive
set policy-options policy-statement ECMP term ECMP then load-balance per-packet
set routing-options forwarding-table export ECMP

R1
!
set interface lo0.0 family iso address 49.0016.0000.0000.0001.00
set protocols isis level 2 disable
set protocols isis interface ae0.0
set protocols isis interface ae6.0

R2
!
set interface lo0.0 family iso address 49.0016.0000.0000.0002.00
set protocols isis interface ae0.0 level 2 disable
set protocols isis interface ae6.0 level 1 disable
set protocols isis export ISIS-TO-L1
edit policy-options policy-statement ISIS-TO-L1
set term V4DEF from protocol static
set term V4DEF from route-filter 0.0.0.0/0 exact
set term V4DEF to level 1
set term V4DEF then accept

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
174
175 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set term V6DEF from protocol static

set term V6DEF from route-filter ::/0 exact
set term V6DEF to level 1
set term V6DEF then accept
exit
set routing-options static route 0.0.0.0/0 receive
set routing-options rib inet6.0 static route ::/0 receive

R3
!
set interface lo0.0 family iso address 49.0016.0000.0000.0003.00
set protocols isis interface ae0.0 level 1 disable
set protocols isis interface ae6.0 level 2 disable
set protocols isis interface ae7.0 level 1 disable
set protocols isis interface ge-0/0/4.136 passive
set protocols isis export ISIS-TO-L1
edit policy-options policy-statement ISIS-TO-L1
set term V4DEF from protocol static
set term V4DEF from route-filter 0.0.0.0/0 exact
set term V4DEF to level 1
set term V4DEF then accept
set term V6DEF from protocol static
set term V6DEF from route-filter ::/0 exact
set term V6DEF to level 1
set term V6DEF then accept
exit
set routing-options static route 0.0.0.0/0 receive
set routing-options rib inet6.0 static route ::/0 receive

R4
!
set interface lo0.0 family iso address 49.0016.0000.0000.0004.00
set protocols isis level 1 disable
set protocols isis interface ae0.0
set protocols isis interface ae6.0
set protocols isis interface ae7.0
set protocols isis interface ae8.0

R5
!
set interface lo0.0 family iso address 49.0016.0000.0000.0005.00
set protocols isis level 1 disable
set protocols isis interface ae0.0
set protocols isis interface ae7.0
set protocols isis interface ae8.0
set protocols isis interface ge-0/0/4.136 passive

R6
!
set interface lo0.0 family iso address 49.0016.0000.0000.0006.00

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

set protocols isis level 1 disable
set protocols isis interface ae0.0
set protocols isis interface ae7.0

Task 2 (2 points). Configure OSPFv2 area 0.0.0.0 for IPv4 routing of Service Provider Network 2 in
accordance with the provided routing protocols diagram. All routers should not attempt to establish any
neighbourship over loopback interfaces. Ensure OSPFv2 neighbourship can get established over the links
as fast as possible and the protocol can detect link failure events less than 1 second. Also ensure OSPFv2
reflect the exact bandwidth capacity of the links; and that routing information propagated (except for
DC2) is authenticated with MD5 hashing. Please use the most efficient configuration method to enable
the features.
R7,R8
!
edit protocols ospf
set reference-bandwidth 100g
set area 0.0.0 interface lo0.0 passive
set area 0.0.0 interface ae0.0
exit
edit group CORE-INTERFACES
set protocols ospf area 0.0.0 interface <ae*> interface-type p2p
set protocols ospf area 0.0.0 interface <ae*> bfd minimum-interval 250 multiplier 4

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
175
176 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set protocols ospf area 0.0.0 interface <ae*> authentication md5 1 key JNCIE
exit
set apply-group CORE-INTERFACES

Task 3 (3 points). Ensure IS-IS neighbourship can get established over the links as fast as possible. Taking
a further step, IS-IS should pre-build free loop alternate paths to achieve sub-second re-convergence.
Also ensure IS-IS reflect the exact bandwidth capacity of the links; and that routing information
propagated is authenticated with MD5 hashing. Please use the most efficient configuration method to
enable the features.
/* Answer for task 3 is included in task 1’s */

Task 4 (4 points). Configure the following IS-IS features. At the end of this topic, all routers should have
full IPv4 reachability with each other within their respective Service Provider Networks.

• Allow IS-IS path metric to scale over the value of 1023.

• Reduce the amount of control traffic generated by IS-IS, but also tune SPF calculation of IS-IS to
react quicker to the change of topology.
• Ensure that IS-IS LSDB is protected such that there would be no more than 200 external prefixes
redistributed into IS-IS.
• At the same time, ensure that every IS-IS router is up and running normally for 30 minutes
before it can pass any traffic.
• Record IS-IS neighbour state changes into a local file called isis.log.
R1,R2,R3,R4,R5,R6
!
edit protocols isis
set lsp-lifetime 3600
set spf-options delay 100
set overload timeout 1800
set traceoptions file isis.log
set traceoptions flag state
exit

R1,R2,R3
!
edit protocols isis
set level 1 prefix-export-limit 200

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

set level 1 wide-metrics-only
exit

R2,R3,R4,R5,R6
!
edit protocols isis
set level 2 prefix-export-limit 200
set level 2 wide-metrics-only
exit

Verification
Tasks 1 and 3. Task 1 starts the IGP section with configuration of multi-level IS-IS within Service Provider
Network 1. You can start the task right away but if you take a step back and read through the whole IGP
section, you would notice that you can combine multiple tasks into one configuration effort and also the
best uniformed way to do it. Again, this book emphasises the implementation of group-based
configuration which not only saves work cycles but also ensures the consistency of your configuration on
a system-wide basis. At the very beginning, we should start with verifying IS-IS adjacency.
lab@VMX-R1> show isis adjacency
Interface System L State Hold (secs) SNPA
ae0.0 VMX-R2 1 Up 24
ae6.0 VMX-R3 1 Up 23

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
176
177 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

lab@VMX-R2> show isis adjacency

Interface System L State Hold (secs) SNPA
ae0.0 VMX-R1 1 Up 23
ae6.0 VMX-R4 2 Up 26

lab@VMX-R3> show isis adjacency

Interface System L State Hold (secs) SNPA
ae0.0 VMX-R4 2 Up 20
ae6.0 VMX-R1 1 Up 22
ae7.0 VMX-R5 2 Up 23

lab@VMX-R4> show isis adjacency

Interface System L State Hold (secs) SNPA
ae0.0 VMX-R3 2 Up 25
ae6.0 VMX-R2 2 Up 23
ae7.0 VMX-R6 2 Up 23
ae8.0 VMX-R5 2 Up 23

lab@VMX-R5> show isis adjacency

Interface System L State Hold (secs) SNPA
ae0.0 VMX-R6 2 Up 21
ae7.0 VMX-R3 2 Up 19
ae8.0 VMX-R4 2 Up 24

lab@VMX-R6> show isis adjacency

Interface System L State Hold (secs) SNPA
ae0.0 VMX-R5 2 Up 23
ae7.0 VMX-R4 2 Up 26

By default, across IS-IS level boundary, all IS-IS level 1 routing information is propagated into IS-IS level 2
but it is not the case on the way back (multilevel IS-IS works similarly to an OSPF NSSA area). IS-IS router
with level 2 adjacency would inject default route into its level 1 to provide inter-area reachability. IS-IS
implementation on JUNOS does not perform such injection by default, hence we would need to
explicitly configure default routes for level 1 injection with statement to level 1 in the policy
statement, and remember to do it for both IPv4 and IPv6 stacks as IS-IS in this task is used to do routing
for both stacks. Obviously we would need to generate default routes on R2 and R3 and redistribute into
their level 1 routing domain. As a result, R1 should receive such default routes as below. Note that if the
overload bit of IS-IS is still not cleared, there would be no route redistributed from level 2 to level 1,
including the default route. You can check overload bit set with command show isis overview.
lab@VMX-R1> show route protocol isis active-path table inet.0 0.0.0.0/0 exact

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

inet.0: 64 destinations, 72 routes (49 active, 2 holddown, 16 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0 *[IS-IS/15] 17:51:12, metric 50

> to 150.1.12.2 via ae0.0

lab@VMX-R1> show route protocol isis active-path table inet6.0 ::/0 exact

inet6.0: 62 destinations, 70 routes (59 active, 3 holddown, 0 hidden)

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

::/0 *[IS-IS/160] 17:51:19, metric 50

> to fe80::4e96:14ff:feaa:5e80 via ae0.0

For the network segment with DC2 to be routable within IS-IS domain, we can simply announce it in IS-IS
with a passive statement which advertises the segment into IS-IS but doesn’t expect any neighbourship
to be formed across it.

For task 3, the point-to-point interface type would remove uncessary DIS election on every Ethernet
interface that has got only 2 neighbours, reducing establishment time for IS-IS adjacency.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
177
178 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

By default IS-IS treats all interfaces equally with the same metric of 10 regardless of their actual
bandwidth. Configuring a new reference bandwidth tunes IS-IS to take into account the physical port
speed.
lab@VMX-R1> show isis interface
IS-IS interface database:
Interface L CirID Level 1 DR Level 2 DR L1/L2 Metric
ae0.0 1 0x1 Point to Point Disabled 50/50
ae6.0 1 0x1 Point to Point Disabled 100/100
lo0.0 0 0x1 Passive Passive 0/0

Task 2, we should verify OSPF neighbourship, authentication, interface cost and BFD status as the
following:
lab@VMX-R8> show ospf neighbor
Address Interface State ID Pri Dead
151.1.78.7 ae0.0 Full 151.1.1.7 128 34

lab@VMX-R8> show ospf interface detail

Interface State Area DR ID BDR ID Nbrs
ae0.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Type: P2P, Address: 151.1.78.8, Mask: 255.255.255.0, MTU: 1500, Cost: 50
Adj count: 1
Hello: 10, Dead: 40, ReXmit: 5, Not Stub
Auth type: MD5, Active key ID: 1, Start time: 1969 Dec 31 16:00:00 PST
Protection type: None
Topology default (ID 0) -> Cost: 50

Similar to point-to-point interface type of IS-IS as discussed in tasks 1 and 3, the interface-type p2p of
OSPF would remove uncessary DR/BDR election on every Ethernet interface that has got only 2
neighbours, reducing establishment time for OSPF neighbours. Meanwhile the BFD would verify
bidirectional connectivity and help OSPF detect failure in a sub-second manner rather than relying on
interface status. Another advantage is that we won’t need to implement Fast-Hello feature for OSPF
which may have severe impact on CPU resources, rather we only need just one single BFD function for
all routing protocols including BGP subsequently.
lab@VMX-R7> show bfd session detail
Detect Transmit
Address State Interface Time Interval Multiplier
151.1.1.8 Up 2.000 0.500 4
Client BGP, TX interval 0.500, RX interval 0.500

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

Session up time 00:05:54
Local diagnostic None, remote diagnostic None
Remote state Up, version 1
Session type: Multi hop BFD
Detect Transmit
Address State Interface Time Interval Multiplier
151.1.78.8 Up ae0.0 1.000 0.250 4
Client OSPF realm ospf-v2 Area 0.0.0.0, TX interval 0.250, RX interval 0.250
Session up time 00:05:27, previous down time 00:00:05
Local diagnostic None, remote diagnostic None
Remote state Up, version 1
Session type: Single hop BFD

Task 4 requires some advanced tuning of IS-IS, starting with the wide style of metrics. By default IS-IS
operates in narrow metric style which allows for interface cost to be within 1-63 range which is not
scalable for Service Provider networks today. Using wide style, IS-IS is allowed to grow metric scale to 1-
16777215, and metric of a route can be higher than 1023. Next, using lsp-lifetime statement, we can
reduce the amount of LSP messages generated by allowing LSP to live longer, i.e. from 1200sec by
default to a higher value. Since network devices nowadays are featured with much stronger CPU and
faster memory, it is possible to tune IS-IS to react quicker to topology changes than by default by using

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
178
179 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

spf-options delay statement with a value that is lower than the default of 200msec. All of IS-IS timers
and operating features can be viewed by:
lab@VMX-R6> show isis overview
Instance: master
Router ID: 150.1.1.6
Adjacency holddown: enabled
Maximum Areas: 3
LSP life time: 3600
Reference bandwidth: 1215752192
Attached bit evaluation: enabled
SPF delay: 100 msec, SPF holddown: 5000 msec, SPF rapid runs: 3
Overload bit at startup is set
Overload high metrics: disabled
Allow route leaking: disabled
Overload timeout: 1800 sec
IPv4 is enabled, IPv6 is enabled
Traffic engineering: enabled
Restart: Enabled
Restart duration: 210 sec
Helper mode: Enabled
Level 1
Internal route preference: 15
External route preference: 160
Wide metrics are enabled, Narrow metrics are enabled
Level 2
Internal route preference: 18
External route preference: 165
Prefix export limit: 200
Wide metrics are enabled

At the end of this topic, we should verify reachability within Service Provider Networks 1 and 2,
particularly between loopback interfaces of the routers as it would be instrumental for the upcoming
tasks.
lab@VMX-R1> ping rapid source 150.1.1.1 150.1.1.2
PING 150.1.1.2 (150.1.1.2): 56 data bytes
!!!!!
--- 150.1.1.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 7.895/9.705/10.409/0.946 ms

lab@VMX-R1> ping rapid source 150.1.1.1 150.1.1.3

PING 150.1.1.3 (150.1.1.3): 56 data bytes
!!!!!
--- 150.1.1.3 ping statistics ---

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 9.878/11.020/14.680/1.850 ms

lab@VMX-R1> ping rapid source 150.1.1.1 150.1.1.4

lab@VMX-R1> ping rapid source 150.1.1.1 150.1.1.5

PING 150.1.1.5 (150.1.1.5): 56 data bytes
!!!!!
--- 150.1.1.5 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 14.851/15.077/15.329/0.181 ms

lab@VMX-R1> ping rapid source 150.1.1.1 150.1.1.6

PING 150.1.1.6 (150.1.1.6): 56 data bytes
!!!!!
--- 150.1.1.6 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 19.709/21.919/24.917/2.399 ms

lab@VMX-R1> ping rapid source 150.1.1.1 150.1.136.3

PING 150.1.136.3 (150.1.136.3): 56 data bytes
!!!!!

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
179
180 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

--- 150.1.136.3 ping statistics ---

5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 9.685/10.004/10.301/0.212 ms

lab@VMX-R1> ping rapid source 150.1.1.1 150.1.136.5

PING 150.1.136.5 (150.1.136.5): 56 data bytes
!!!!!
--- 150.1.136.5 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 14.758/21.993/50.010/14.010 ms

lab@VMX-R7> ping rapid source 151.1.1.7 151.1.1.8

PING 151.1.1.8 (151.1.1.8): 56 data bytes
!!!!!
--- 151.1.1.8 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 6.503/9.229/10.137/1.386 ms

Topic 3: MPLS
Total Points: 15

Task 1 (2 points). Configure IS-IS to build TE database for Service Provider Network 1; for Service
Provider Network 2, enable LDP as the signalling protocol between R7 and R8. Ensure the tailend router
is the one who removes MPLS stack instead of the penultimate router.
R1,R2,R3,R4,R5,R6
!
set groups CORE-INTERFACES interfaces <ae*> unit 0 family mpls
set protocols mpls interface all
set protocols mpls explicit-null

R7,R8
!
set groups CORE-INTERFACES interfaces <ae*> unit 0 family mpls
set protocols mpls interface all
set protocols ldp interface ae0.0
set protocols ldp explicit-null

Task 2 (10 points). Configure full-mesh RSVP-signaled LSPs between all routers of Service Provider
Network 1 with the following characteristics.

• All LSPs should have setup/holding priorities of 5. There could be other LSPs with higher
priorities being configured in upcoming projects so please ensure for all routers except R5 that

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

when a LSP is to be moved due to pre-emption, the system gives it at least 30sec to find an
alternative path before tearing it down.
• All LSPs should be re-routed within tens of milliseconds upon failure of any link within the core
network.
• All LSPs should be monitored and optimised for better path every 1 hour and ensure that the
newly optimised path is established before old path is torn down for reoptimisation activities.
• Ensure that the old path is kept for at least 60 second after the newly optimised path is in use to
prevent stale MPLS label due to big churn of re-convergence that could drop traffic.
• Any link can be taken out of services easily without reconfiguring all LSPs on all routers.
• When equal cost paths exist, all LSPs should randomly select the best one to follow.
• Please use the most efficient configuration method to group common attributes of LSPs.
R1,R2,R3,R4,R5,R6
!
set protocols rsvp interface all link-protection
set protocols mpls expand-loose-hop
set protocols mpls admin-groups OOS 0
set interface lo0 unit 0 family inet address 127.0.0.1/32

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
180
181 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

edit groups LSP-GROUP-CORE protocols mpls label-switched-path <*>

set priority 5 5
set soft-preemption
set link-protection
set optimize-timer 3600
set adaptive
set optimize-hold-dead-delay 60
set admin-group exclude OOS
set random
exit
set apply-groups LSP-GROUP-CORE
set routing-options forwarding-table export ECMP
set policy-options policy-statement ECMP term ECMP then load-balance per-packet

R2,R3
!
edit policy-options policy-statement ISIS-TO-L1
set term LSR-RID from route-filter 150.1.1.0/24 prefix-length-range /32-/32
set term LSR-RID to level 1
set term LSR-RID then accept
exit

R1
!
edit protocols mpls
set label-switched-path R1-TO-R2 to 150.1.1.2 inter-domain
set label-switched-path R1-TO-R3 to 150.1.1.3 inter-domain
set label-switched-path R1-TO-R4 to 150.1.1.4 inter-domain
set label-switched-path R1-TO-R5 to 150.1.1.5 inter-domain
set label-switched-path R1-TO-R6 to 150.1.1.6 inter-domain
exit
set interface lo0 unit 0 family inet address 150.1.1.1/32 primary

R3
!
edit protocols mpls
set label-switched-path R3-TO-R1 to 150.1.1.1
set label-switched-path R3-TO-R2 to 150.1.1.2
set label-switched-path R3-TO-R4 to 150.1.1.4

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

set label-switched-path R3-TO-R5 to 150.1.1.5
set label-switched-path R3-TO-R6 to 150.1.1.6
exit
set interface lo0 unit 0 family inet address 150.1.1.3/32 primary

R4
!
edit protocols mpls
set label-switched-path R4-TO-R1 to 150.1.1.1 inter-domain
set label-switched-path R4-TO-R2 to 150.1.1.2
set label-switched-path R4-TO-R3 to 150.1.1.3
set label-switched-path R4-TO-R5 to 150.1.1.5
set label-switched-path R4-TO-R6 to 150.1.1.6
exit
set interface lo0 unit 0 family inet address 150.1.1.4/32 primary

R5
!
edit protocols mpls
set label-switched-path R5-TO-R1 to 150.1.1.1 inter-domain
set label-switched-path R5-TO-R2 to 150.1.1.2
set label-switched-path R5-TO-R3 to 150.1.1.3
set label-switched-path R5-TO-R4 to 150.1.1.4
set label-switched-path R5-TO-R6 to 150.1.1.6
exit
set interface lo0 unit 0 family inet address 150.1.1.5/32 primary

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
181
182 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

R6
!
edit protocols mpls
set label-switched-path R6-TO-R1 to 150.1.1.1 inter-domain
set label-switched-path R6-TO-R2 to 150.1.1.2
set label-switched-path R6-TO-R3 to 150.1.1.3
set label-switched-path R6-TO-R4 to 150.1.1.4
set label-switched-path R6-TO-R5 to 150.1.1.5
exit
set interface lo0 unit 0 family inet address 150.1.1.6/32 primary

Task 3 (5 points). Information from optical/transport team shows that fibre connections between R4-R5
and R5-R6 are actually housed by the same WDM system. Ensure that this fact is taken into account by
CSPF calculation for the redundant LSP paths on R5. Please use RFC 4202 standard for this task.
R5
!
set routing-options srlg PIPE-1 srlg-value 1 srlg-cost 1000
set routing-options srlg PIPE-2 srlg-value 2 srlg-cost 2000
edit protocols mpls
set interface ae0.0 srlg PIPE-1
set interface ae8.0 srlg PIPE-1
set interface ae7.0 srlg PIPE-2
set label-switched-path R5-TO-R1 to 150.1.1.1 primary A
set label-switched-path R5-TO-R2 to 150.1.1.2 primary A
set label-switched-path R5-TO-R3 to 150.1.1.3 primary A
set label-switched-path R5-TO-R4 to 150.1.1.4 primary A
set label-switched-path R5-TO-R6 to 150.1.1.6 primary A
set label-switched-path R5-TO-R1 to 150.1.1.1 exclude-srlg secondary B standby
set label-switched-path R5-TO-R2 to 150.1.1.2 exclude-srlg secondary B standby
set label-switched-path R5-TO-R3 to 150.1.1.3 exclude-srlg secondary B standby
set label-switched-path R5-TO-R4 to 150.1.1.4 exclude-srlg secondary B standby
set label-switched-path R5-TO-R6 to 150.1.1.6 exclude-srlg secondary B standby
set path A
set path B
exit
delete groups LSP-GROUP-CORE protocols mpls label-switched-path <*> soft-preemption

Task 4 (1 point). Allow for customers or peers to see MPLS hops of Service Provider Networks 1 and 2
when performing ICMP ping and traceroute; Enable RSVP to signal MTU value along the path of all LSPs.
R1,R2,R3,R4,R5,R6
!
set protocols mpls icmp-tunneling
set protocols mpls path-mtu rsvp mtu-signaling

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

R7,R8
!
set protocols mpls icmp-tunneling

Verification
Task 1. IS-IS is enabled with TE extension by default, it automatically generates and propagates link
attributes throughout the IS-IS domain in addition to the regular metric value. The attributes include
values such as reservable bandwidth for RSVP, remaining bandwidth, etc. Another interesting part of
this practice lab is that there are multiple IS-IS levels, hence there would be multiple TE databases (TE)
being created. And this behaviour does create some challenges for MPLS RSVP-signalled LSPs to be
formed which we will see in the upcoming task. As can be seen below, there are 2 TEDs for levels 1 and
2 on router R2.
lab@VMX-R2> show isis database
IS-IS level 1 link-state database:
LSP ID Sequence Checksum Lifetime Attributes
R1.00-00 0x6e 0x4617 2959 L1
R2.00-00 0x6b 0x7428 2954 L1 L2
R3.00-00 0x6b 0x6548 2959 L1 L2
3 LSPs

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
182
183 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

IS-IS level 2 link-state database:

LSP ID Sequence Checksum Lifetime Attributes
R2.00-00 0x6a 0xd00e 2954 L1 L2
R3.00-00 0x70 0xd579 2958 L1 L2
R4.00-00 0x6f 0xc7d2 2959 L1 L2
R5.00-00 0x6a 0xe3d2 3047 L1 L2
R6.00-00 0x67 0x33a0 2948 L1 L2
5 LSPs

lab@VMX-R2> show ted database extensive

TED database: 6 ISIS nodes 6 INET nodes
NodeID: R1.00(150.1.1.1)
Type: Rtr, Age: 644 secs, LinkIn: 2, LinkOut: 2
Protocol: IS-IS(1)
To: R2.00(150.1.1.2), Local: 150.1.12.1, Remote: 150.1.12.2
Local interface index: 72, Remote interface index: 70
Color: 0 <none>
Metric: 50
Static BW: 2Gbps
Reservable BW: 2Gbps
Available BW [priority] bps:
[0] 2Gbps [1] 2Gbps [2] 2Gbps [3] 2Gbps
[4] 2Gbps [5] 2Gbps [6] 2Gbps [7] 2Gbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 2Gbps [1] 2Gbps [2] 2Gbps [3] 2Gbps
[4] 2Gbps [5] 2Gbps [6] 2Gbps [7] 2Gbps
To: R3.00(150.1.1.3), Local: 150.1.13.1, Remote: 150.1.13.3
Local interface index: 73, Remote interface index: 73
Color: 0 <none>
Metric: 100
Static BW: 1000Mbps
Reservable BW: 1000Mbps
Available BW [priority] bps:
[0] 1000Mbps [1] 1000Mbps [2] 1000Mbps [3] 1000Mbps
[4] 1000Mbps [5] 1000Mbps [6] 1000Mbps [7] 1000Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 1000Mbps [1] 1000Mbps [2] 1000Mbps [3] 1000Mbps
[4] 1000Mbps [5] 1000Mbps [6] 1000Mbps [7] 1000Mbps
<snip-for-brevity>

Furthermore, we need to enable MPLS and ensure PHP (penultimate-hop-popping) behaviour is disabled
where the last hop removes MPLS stack (or topmost label) instead of the hop before. This design

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

facilitates certain MPLS QoS implementations where we would need to retain the MPLS stack until the
last hop for proper classification and/or queueing on the egress. In order to disable PHP behaviour, we
use explicit-null statement under protocols mpls stanza which has effect on RSVP-signaled LSP.
According to RFC3032 when disabling PHP, label 0 is advertised by the last hop instead of label 3 to
signal the penultimate hop that it wishes to retain MPLS label stack. There is a detailed explanation
http://www.juniper.net/documentation/en_US/junos12.3/topics/task/configuration/mpls-ultimate-
hop-popping-enabling.html for the the impact of disabling PHP in JUNOS.

For simplicity Service Provider Network 2 only uses LDP as the signalling protocol, we should verify LDP
neighbourship and label binding database.
lab@VMX-R8> show ldp neighbor
Address Interface Label space ID Hold time
151.1.78.7 ae0.0 151.1.1.7:0 11

lab@VMX-R8> show ldp database

Input label database, 151.1.1.8:0--151.1.1.7:0
Label Prefix
0 151.1.1.7/32
299776 151.1.1.8/32

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
183
184 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Output label database, 151.1.1.8:0--151.1.1.7:0

Label Prefix
299776 151.1.1.7/32
0 151.1.1.8/32

Now let’s discuss two interesting parts of this tasks which would probably make things convoluted a
little bit, being 1) inter-IS-IS level MPLS RSVP, 2) optimisation of MPLS RSVP-signalled LSPs. For the first
point, from task 1 we know that we now have multiple TEDs corresponding to IS-IS levels and really
routers will perform separate CSPF computations for each level. Therefore if we configure things
normally, the LSPs that need to traverse across area border will not come up, for example LSPs between
R1 and R6 will need to traverse boundary between level 1 and level 2. Therefore we would need to
enable inter-area function of MPLS RSVP that JUNOS provides with statement expand-loose-hop at the
global MPLS configuration stanza, combined with statement inter-domain at LSP level. The function
allows for selecting a node which is not in the same area to be LSP egress endpoint. Moreover we would
need to leak /32 host routes corresponding to Router-ID from level 2 to level 1 because inter-level LSPs
would not simply follow default route that level 1 has got. We can validate this point by deactivating the
leaking term on routers R2 and R3. You should see that the inter-domain LSPs go down.
lab@VMX-R6> show mpls lsp name R6-TO-R1 extensive | match "State:|domain"
From: 150.1.1.6, State: Up, ActiveRoute: 0, LSPname: R6-TO-R1
PathDomain: Inter-domain
*Primary State: Up

lab@VMX-R2# deactivate policy-options policy-statement ISIS-TO-L1 term LSR-RID

[edit]
lab@VMX-R2# commit
commit complete

lab@VMX-R3# deactivate policy-options policy-statement ISIS-TO-L1 term LSR-RID

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

[edit]
lab@VMX-R3# commit
commit complete

lab@VMX-R1> restart routing

Routing protocols process started, pid 50726

lab@VMX-R1> show mpls lsp ingress

Ingress LSP: 5 sessions
To From State Rt P ActivePath LSPname
150.1.1.2 150.1.1.1 Up 0 * R1-TO-R2
150.1.1.3 150.1.1.1 Up 0 * R1-TO-R3
150.1.1.4 150.1.1.1 Dn 0 - R1-TO-R4
150.1.1.5 150.1.1.1 Dn 0 - R1-TO-R5
150.1.1.6 150.1.1.1 Dn 0 - R1-TO-R6
Total 5 displayed, Up 2, Down 3

Before moving on with discussion of LSP’s attributes in detailed, let’s ensure that all LSPs are fully
signalled and in Up state.
lab@VMX-R1> show mpls lsp ingress
Ingress LSP: 5 sessions
To From State Rt P ActivePath LSPname
150.1.1.2 150.1.1.1 Up 0 * R1-TO-R2
150.1.1.3 150.1.1.1 Up 0 * R1-TO-R3
150.1.1.4 150.1.1.1 Up 0 * R1-TO-R4

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
184
185 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

150.1.1.5 150.1.1.1 Up 0 * R1-TO-R5

150.1.1.6 150.1.1.1 Up 0 * R1-TO-R6
Total 5 displayed, Up 5, Down 0

lab@VMX-R2> show mpls lsp ingress

Ingress LSP: 5 sessions
To From State Rt P ActivePath LSPname
150.1.1.1 150.1.1.2 Up 0 * R2-TO-R1
150.1.1.3 150.1.1.2 Up 0 * R2-TO-R3
150.1.1.4 150.1.1.2 Up 0 * R2-TO-R4
150.1.1.5 150.1.1.2 Up 0 * R2-TO-R5
150.1.1.6 150.1.1.2 Up 0 * R2-TO-R6
Total 5 displayed, Up 5, Down 0

lab@VMX-R3> show mpls lsp ingress

lab@VMX-R4> show mpls lsp ingress

lab@VMX-R5> show mpls lsp ingress

Ingress LSP: 5 sessions
To From State Rt P ActivePath LSPname
150.1.1.1 150.1.1.5 Up 0 * A R5-TO-R1
150.1.1.2 150.1.1.5 Up 0 * A R5-TO-R2
150.1.1.3 150.1.1.5 Up 0 * A R5-TO-R3
150.1.1.4 150.1.1.5 Up 0 * A R5-TO-R4
150.1.1.6 150.1.1.5 Up 0 * A R5-TO-R6
Total 5 displayed, Up 5, Down 0

lab@VMX-R6> show mpls lsp ingress

Ingress LSP: 5 sessions
To From State Rt P ActivePath LSPname
150.1.1.1 150.1.1.6 Up 0 * R6-TO-R1
150.1.1.2 150.1.1.6 Up 0 * R6-TO-R2
150.1.1.3 150.1.1.6 Up 0 * R6-TO-R3

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

150.1.1.4 150.1.1.6 Up 0 * R6-TO-R4
150.1.1.5 150.1.1.6 Up 0 * R6-TO-R5
Total 5 displayed, Up 5, Down 0

For the second point, JUNOS offers full-blown of features to optimise RSVP-signalled LSPs. The use of
these features requires thorough understanding and must be prepared carefully as otherwise they
might de-stablise the networks.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
185
186 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

• Next we use link-protection to enable Link Protection feature which requires all nodes along
the LSP path to signal bypass LSP across each link of the path and get the bypass LSP ready upon
failure event of link.
• Another important feature is the reoptimisation period, tuned by optimize-timer statement
which should be used with adaptive statement to ensure that the new more-optimised path is
fully signalled before the old less-optimised path is torn down.
• An interesting feature follow reoptimisation period is somewhat called OHDD which is
controlled by statement optimize-hold-dead-delay which keeps the old less-optimised path for
some time to ensure all routes can switch over to the new path.
• When a grey failure such as slow-flap or low packet loss happens for a link in the networks, you
would want to take such link out of services quickly for further diagnostic. However you would
not want to reconfigure all LSPs in the network to exclude such link. A nice and neat feature is to
preconfigure a blacklist code that all LSPs would avoid. This refers to the use of admin-group
feature which can be used to colour links in the network with statement set protocols mpls
interface <intf> admin-group <colour-name>. IS-IS or OSPF will propagate such colour
information in their TE extensions (TLVs for IS-IS and Opaque LSAs for OSPF). And then we can
configure LSPs to either include or exclude the colour we want. In this task, a colour called OOS
(out-of-services) is precreated and all LSPs would avoid that colour. When we want to take a link
OOS, we can configure that link with the OOS colour.
• If multiple paths are available upon completion of CSPF, a tie-breaking rule is applied to choose
the path for the LSP. The default tie-breaking method is random, intending to place an equal
number of LSPs on each link, regardless of the available bandwidth.
lab@VMX-R6> show mpls lsp ingress name R6-TO-R2 extensive
Ingress LSP: 5 sessions

150.1.1.2
From: 150.1.1.6, State: Up, ActiveRoute: 0, LSPname: R6-TO-R2
ActivePath: (primary)
Link protection desired
LSPtype: Static Configured
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

Priorities: 5 5
OptimizeTimer: 3600
SmartOptimizeTimer: 180
Exclude: OOS
Reoptimization in 2409 second(s).
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 200)
150.1.46.4 S 150.1.24.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-
ID):
150.1.1.4(flag=0x20) 150.1.46.4(Label=299840) 150.1.1.2(flag=0x20)
150.1.24.2(Label=0)
7 Oct 2 22:21:46.315 CSPF: computation result ignored, new path no benefit[81 times]
6 Sep 29 16:59:08.249 Link-protection Up
5 Sep 29 16:29:08.957 Selected as active path
4 Sep 29 16:29:08.947 Record Route: 150.1.1.4(flag=0x20) 150.1.46.4(Label=299840)
150.1.1.2(flag=0x20) 150.1.24.2(Label=0)
3 Sep 29 16:29:08.947 Up
2 Sep 29 16:29:08.858 Originate Call
1 Sep 29 16:29:08.858 CSPF: computation result accepted 150.1.46.4 150.1.24.2
Created: Thu Sep 29 16:28:36 2016
Total 1 displayed, Up 1, Down 0

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
186
187 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

same fibre conduit or DWDM system, there is literally no redundancy at all because both paths are likely
to go down at the same time. RFCs 4203 and 5307 document extensions to OSPF and IS-IS respectively
to distribute SRLG (shared risk link group) value for TE-enabled links. This information if exists is an input
in the path calculation such that the backup path is unlikely to go in the same way as the primary path.
By default JUNOS implementation of SRLG requires a numerical SRLG value for each configured group
and it will add that SRLG value into the total path cost when comparing paths belonging to the same
SRLG and paths not within the same SRLG giving more chance for the out-of-group paths to win. From
configuration perspectives, with statement srlg at routing-options level and protocols mpls level we
define two SRLG groups on R5 and then group ae0 and ae8 into one group while leaving ae7 solely in
another group. In order to tap in the calculation of backup path for LSPs of R5, we configure explicitly
secondary paths for them and to ensure the backup path to not go in the same fibre conduit with the
primary path, we use statement exclude-srlg at the LSP level. This will change the behaviour of SRLG
calculation from adding SRLG cost to the path cost into avoiding path going across link within the same
SRLG. As can be seen from the output below, primary path of LSP R5-TO-R6 is the direct path, while the
backup path is an indirect path R5-R3-R4-R6. The indirect path R5-R4-R6 is shorter but not choosen as
backup path because it contains one link in the same SRLG group with the primary path. Note that you
may need to issue CLI command clear mpls lsp name R5-TO-R6 path B for R5 to realign its paths.
lab@VMX-R5> show mpls lsp ingress name R5-TO-R6 detail
Ingress LSP: 5 sessions

150.1.1.6
From: 150.1.1.5, State: Up, ActiveRoute: 0, LSPname: R5-TO-R6
ActivePath: A (primary)
Link protection desired
LSPtype: Static Configured
LoadBalance: Random
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary A State: Up
Priorities: 5 5
OptimizeTimer: 3600
SmartOptimizeTimer: 180
Exclude: OOS
SRLG: PIPE-1
Reoptimization in 2892 second(s).
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 50)
150.1.56.6 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

ID):
150.1.1.6(flag=0x20) 150.1.56.6(Label=0)
Standby B State: Up
Priorities: 5 5
OptimizeTimer: 3600
SmartOptimizeTimer: 180
Exclude: OOS
SRLG: PIPE-2
Reoptimization in 2546 second(s).
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 250)
150.1.35.3 S 150.1.34.4 S 150.1.46.6 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-
ID):
150.1.1.3(flag=0x21) 150.1.35.3(flag=1 Label=299968) 150.1.1.4(flag=0x21)
150.1.34.4(flag=1 Label=300176) 150.1.1.6(flag=0x20) 150.1.46.6(Label=0)
Total 1 displayed, Up 1, Down 0

Task 4. Verification for customers or peers performing ping/traceroute will be carried out in Topc 4:
BGP, tasks 1 and 2. For now, let’s test reachability via ping mpls rsvp which is part of MPLS OAM family
and uses UDP port 3503 as the underlying transport protocol, for example:
lab@VMX-R4> ping mpls rsvp R4-TO-R1
!!!!!
--- lsping statistics ---

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
187
188 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

5 packets transmitted, 5 packets received, 0% packet loss

lab@VMX-R4> ping mpls rsvp R4-TO-R2

!!!!!
--- lsping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

lab@VMX-R4> ping mpls rsvp R4-TO-R3

!!!!!
--- lsping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

lab@VMX-R4> ping mpls rsvp R4-TO-R5

!!!!!
--- lsping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

lab@VMX-R4> ping mpls rsvp R4-TO-R6

!!!!!
--- lsping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

With regard to signalling MTU via RSVP, the basic concept is that MTU is signaled from the ingress LSR to
the egress LSR via RSVP Adspec object. Ingress LSR uses MTU associated with the outgoing interface over
which the RSVP path message is sent and at each hop along the path, MTU in the Adspec object is
updated to the minimum of the received value and the value of the outgoing interface.
lab@VMX-R6> show mpls lsp egress name R1-TO-R6 extensive
Egress LSP: 8 sessions

150.1.1.6
From: 150.1.1.1, LSPstate: Up, ActiveRoute: 0
LSPname: R1-TO-R6, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: -
Resv style: 1 SE, Label in: 0, Label out: -
Time left: 154, Since: Fri Apr 7 18:49:47 2017
Tspec: rate 0bps size 0bps peak Infbps m 20 M 9192
Port number: sender 1 receiver 11304 protocol 0
Link protection desired
Soft preemption desired
Type: Protection down
PATH rcvfrom: 150.1.56.5 (ae0.0) 11 pkts
Adspec: received MTU 1986
PATH sentto: localclient
RESV rcvfrom: localclient , Entropy label: No
Record route: 150.1.13.1 150.1.35.3 150.1.56.5 <self>

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

Total 1 displayed, Up 1, Down 0

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
188
189 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 4: BGP
Total Points: 30

Task 1 (5 points). Configure R3 and R4 as iBGP route reflectors for Service Provider Network 1 serving
R1, R2, R5 and R6 as their clients. R3 and R4 should always advertise BGP best paths regardless of
whether they are active in the RIB or not. Ensure iBGP sessions are enabled with MD5 authentication.
Configure R8 as iBGP route reflector for Service Provider Network 2 serving R7 as its only client;
replicate all features of SP1 above. Additionally for Service Provider Network 2: ensure iBGP session’s
bidirectional forwarding capability is verified; optimise BGP transport for routing updates and re-
convergence; enable GR/NSF functionality such that BGP routers help each other re-converge under
reboot/maintenance/OS upgrade situations while minimising the radius of the impact.
R1,R2,R5,R6
!
set routing-options autonomous-system 123456
edit protocols bgp group IBGP
set type internal
set neighbor 150.1.1.3
set neighbor 150.1.1.4
set export NHS
exit

R1
!
set protocols bgp group IBGP local-address 150.1.1.1

R2
!
set protocols bgp group IBGP local-address 150.1.1.2

R5
!
set protocols bgp group IBGP local-address 150.1.1.5

R6
!
set protocols bgp group IBGP local-address 150.1.1.6

R3
!
set routing-options autonomous-system 123456
edit protocols bgp group IBGP

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

set type internal
set cluster 150.1.1.3
set local-address 150.1.1.3
set neighbor 150.1.1.1
set neighbor 150.1.1.2
set neighbor 150.1.1.5
set neighbor 150.1.1.6
set export NHS
set advertise-inactive
exit
edit protocols bgp group IBGP-RR
set type internal
set local-address 150.1.1.3
set neighbor 150.1.1.4
set export NHS
set advertise-inactive
exit

R4
!
set routing-options autonomous-system 123456
edit protocols bgp group IBGP
set type internal
set cluster 150.1.1.4
set local-address 150.1.1.4
set neighbor 150.1.1.1
set neighbor 150.1.1.2

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
189
190 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set neighbor 150.1.1.5

set neighbor 150.1.1.6
set export NHS
set advertise-inactive
exit
edit protocols bgp group IBGP-RR
set type internal
set local-address 150.1.1.4
set neighbor 150.1.1.3
set export NHS
set advertise-inactive
exit

R1,R2,R3,R4,R5,R6
!
edit policy-options policy-statement NHS
set term 1 from protocol bgp
set term 1 from route-type external
set term 1 then next-hop self
set term 1 then accept
exit

R7
!
set protocols bgp graceful-restart
set protocols bgp mtu-discovery
set routing-options autonomous-system 78
edit protocols bgp group IBGP
set type internal
set local-address 151.1.1.7
set neighbor 151.1.1.8
set bfd minimum-interval 500 multiplier 4
set advertise-inactive
exit

R8
!
set protocols bgp graceful-restart
set protocols bgp mtu-discovery
set routing-options autonomous-system 78
edit protocols bgp group IBGP
set type internal
set cluster 151.1.1.8
set local-address 151.1.1.8
set neighbor 151.1.1.7
set bfd minimum-interval 500 multiplier 4
set advertise-inactive
exit

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

Local Link Peer ASN of Peer IPv4 of Peer IPv6 of Peer

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
190
191 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

You can launch ping tests from any C/T/P routing-instance on VRF device with some test IPv4/IPv6
addresses below.

• C1: 170.1.210.1, 2016:170:1:210::1

• C4: 170.1.240.1, 2016:170:1:240::1
• P1: 100.0.0.1, 2016:100::1
• P2: 200.0.0.1, 2016:200::1
• T1: 111.0.0.1, 2016:111::1, 12.0.0.1, 2016:12::1
• T2: 222.0.0.1, 2016:222::1, 12.0.0.2, 2016:12::2
• T3 (behind T1, T2): 123.0.0.1, 2016:123::1
R1,R2,R3,R4,R5,R6
!
set protocols mpls ipv6-tunneling
set protocols bgp group IBGP family inet unicast
set protocols bgp group IBGP family inet6 labeled-unicast explicit-null

R1
!
edit protocols bgp group C1
set type external
set peer-as 65001
set neighbor 150.1.119.2
set neighbor 2016:150:1:119::2
exit
edit protocols bgp group P1
set type external
set peer-as 100
set neighbor 150.1.100.2
set neighbor 2016:150:1:100::2
exit
edit protocols bgp group TRANSIT
set type external
set neighbor 111.1.120.2 peer-as 111
set neighbor 2016:111:1:120::2 peer-as 111
set neighbor 222.1.106.2 peer-as 222
set neighbor 2016:222:1:106::2 peer-as 222
exit

R2
!
edit protocols bgp group P1
set type external

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

set peer-as 100
set neighbor 150.1.113.2
set neighbor 2016:150:1:113::2
exit
edit protocols bgp group P2
set type external
set peer-as 200
set neighbor 150.1.101.2
set neighbor 2016:150:1:101::2
exit
edit protocols bgp group T2
set type external
set peer-as 222
set neighbor 222.1.123.2
set neighbor 2016:222:1:123::2
exit
edit protocols bgp group C2
set type external
set peer-as 65002
set neighbor 150.1.102.2
set neighbor 2016:150:1:102::2
exit

R3
!
edit protocols bgp group P2
set type external

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
191
192 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set peer-as 200

set neighbor 150.1.137.2
set neighbor 2016:150:1:137::2
exit
set protocols bgp group IBGP-RR family inet unicast
set protocols bgp group IBGP-RR family inet6 labeled-unicast explicit-null

R4
!
edit protocols bgp group T1
set type external
set peer-as 111
set neighbor 111.1.105.2
set neighbor 2016:111:1:105::2
exit
set protocols bgp group IBGP-RR family inet unicast
set protocols bgp group IBGP-RR family inet6 labeled-unicast explicit-null

R6
!
edit protocols bgp group C4
set type external
set peer-as 65004
set neighbor 150.1.131.2 import C4-IN-INET6 export C4-OUT-INET6
set family inet unicast
set family inet6 unicast
set accept-remote-nexthop
exit
edit policy-options policy-statement C4-IN-INET6
set term 1 from family inet6
set term 1 from protocol bgp
set term 1 then next-hop ::150.1.131.2
set term 1 then accept
exit
edit policy-options policy-statement C4-OUT-INET6
set term 1 from family inet6
set term 1 from protocol bgp
set term 1 then next-hop ::150.1.131.1
set term 1 then accept
exit

Task 3 (5 points). Implement the following features/policies for Service Provider Network 1:

• Display the true 4-byte ASN form.

• Any private ASN in the AS_PATH of prefixes should be removed before advertising out to
Internet.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

• Protect BGP routing table by accepting only up to 1000 prefixes via peers to avoid mistaken
route-leak of Internet routes. Any violated session should be kept in Idle for 15 minutes and
automatically attempt to recover.
R1,R2,R3,R4,R5,R6
!
set routing-options autonomous-system asdot-notation

R1
!
edit protocols bgp group P1
set remove-private all
set neighbor 150.1.100.2 family inet unicast prefix-limit maximum 1000 teardown idle-
timeout 15
set neighbor 2016:150:1:100::2 family inet6 unicast prefix-limit maximum 1000 teardown
idle-timeout 15
exit
edit protocols bgp group TRANSIT
set remove-private all
exit

R2
!
edit protocols bgp group P1
set remove-private all

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
192
193 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set neighbor 150.1.113.2 family inet unicast prefix-limit maximum 1000 teardown idle-
timeout 15
set neighbor 2016:150:1:113::2 family inet6 unicast prefix-limit maximum 1000 teardown
idle-timeout 15
exit
edit protocols bgp group P2
set remove-private all
set neighbor 150.1.101.2 family inet unicast prefix-limit maximum 1000 teardown idle-
timeout 15
set neighbor 2016:150:1:101::2 family inet6 unicast prefix-limit maximum 1000 teardown
idle-timeout 15
exit
edit protocols bgp group T2
set remove-private all
exit

R3
!
edit protocols bgp group P2
set remove-private all
set neighbor 150.1.137.2 family inet unicast prefix-limit maximum 1000 teardown idle-
timeout 15
set neighbor 2016:150:1:137::2 family inet6 unicast prefix-limit maximum 1000 teardown
idle-timeout 15
exit
R4
!
edit protocols bgp group T1
set remove-private all
exit

Task 4 (5 points). Implement the following features/policies for Service Provider Network 1:

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

set 10.0.0.0/8
set 127.0.0.0/8
set 169.254.0.0/16
set 172.16.0.0/12
set 192.0.2.0/24
set 192.168.0.0/16
set 198.18.0.0/15
set 224.0.0.0/3
set 255.255.255.255/32
exit
edit policy-options policy-statement EBGP-FILTER
set term 0 from family inet
set term 0 from protocol bgp
set term 0 from prefix-list PL-BOGON
set term 0 then next policy
set term 4 from family inet
set term 4 from protocol bgp
set term 4 from route-filter 0.0.0.0/0 prefix-length /8-/24
set term 4 then next policy
set term 6 from family inet6
set term 6 from protocol bgp
set term 6 from route-filter ::/0 prefix-length /32-/64
set term 6 then next policy
set term DENY-ALL from family inet
set term DENY-ALL from protocol bgp
set term DENY-ALL then reject
exit

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
193
194 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

edit policy-options policy-statement TRANSIT-OUT

set term 4 from family inet
set term 4 from protocol bgp
set term 4 from community [TRANSIT PEER]
set term 4 then reject
set term 6 from family inet6
set term 6 from protocol bgp
set term 6 from community [TRANSIT PEER]
set term 6 then reject
exit
edit policy-options policy-statement PEER-OUT
set term 4 from family inet
set term 4 from protocol bgp
set term 4 from community [TRANSIT PEER]
set term 4 then reject
set term 6 from family inet6
set term 6 from protocol bgp
set term 6 from community [TRANSIT PEER]
set term 6 then reject
exit
set policy-options community TRANSIT members 16:1000
set policy-options community PEER members 16:2000
set policy-options community CUST members 16:3000

R1
!
edit protocols bgp group P1
set import EBGP-FILTER
set import P1-IN
set export PEER-OUT
exit
edit protocols bgp group TRANSIT
set neighbor 111.1.120.2 import [EBGP-FILTER T1-IN] export TRANSIT-OUT
set neighbor 2016:111:1:120::2 import [EBGP-FILTER T1-IN] export TRANSIT-OUT
set neighbor 222.1.106.2 import [EBGP-FILTER T2-IN] export TRANSIT-OUT
set neighbor 2016:222:1:106::2 import [EBGP-FILTER T2-IN] export TRANSIT-OUT
set multipath multiple-as
exit
edit policy-options policy-statement P1-IN
set term 4 from family inet
set term 4 from protocol bgp
set term 4 then community add PEER
set term 4 then accept
set term 6 from family inet6
set term 6 from protocol bgp
set term 6 then community add PEER
set term 6 then accept
exit
edit policy-options policy-statement T1-IN
set term 4 from family inet

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

set term 4 from protocol bgp
set term 4 then community add TRANSIT
set term 4 then accept
set term 6 from family inet6
set term 6 from protocol bgp
set term 6 then community add TRANSIT
set term 6 then accept
exit
edit policy-options policy-statement T2-IN
set term 4 from family inet
set term 4 from protocol bgp
set term 4 then community add TRANSIT
set term 4 then accept
set term 6 from family inet6
set term 6 from protocol bgp
set term 6 then community add TRANSIT
set term 6 then accept
exit
edit policy-options policy-statement C1-IN
set term 4 from family inet
set term 4 from protocol bgp
set term 4 then community add CUST
set term 4 then accept
set term 6 from family inet6
set term 6 from protocol bgp
set term 6 then community add CUST
set term 6 then accept

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
194
195 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

exit

R2
!
edit protocols bgp group P1
set import EBGP-FILTER
set import P1-IN
set export PEER-OUT
exit
edit protocols bgp group P2
set import EBGP-FILTER
set import P2-IN
set export PEER-OUT
exit
edit protocols bgp group C2
set import EBGP-FILTER
set import C2-IN
exit
edit protocols bgp group T2
set import EBGP-FILTER
set import T2-IN
set export TRANSIT-OUT
exit
edit policy-options policy-statement P1-IN
set term 4 from family inet
set term 4 from protocol bgp
set term 4 then community add PEER
set term 4 then accept
set term 6 from family inet6
set term 6 from protocol bgp
set term 6 then community add PEER
set term 6 then accept
exit
edit policy-options policy-statement P2-IN
set term 4 from family inet
set term 4 from protocol bgp
set term 4 then community add PEER
set term 4 then accept
set term 6 from family inet6
set term 6 from protocol bgp
set term 6 then community add PEER
set term 6 then accept
exit
edit policy-options policy-statement T1-IN
set term 4 from family inet
set term 4 from protocol bgp
set term 4 then community add TRANSIT
set term 4 then accept
set term 6 from family inet6
set term 6 from protocol bgp

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

set term 6 then community add TRANSIT
set term 6 then accept
exit
edit policy-options policy-statement T2-IN
set term 4 from family inet
set term 4 from protocol bgp
set term 4 then community add TRANSIT
set term 4 then accept
set term 6 from family inet6
set term 6 from protocol bgp
set term 6 then community add TRANSIT
set term 6 then accept
exit
edit policy-options policy-statement C2-IN
set term 4 from family inet
set term 4 from protocol bgp
set term 4 then community add CUST
set term 4 then accept
set term 6 from family inet6
set term 6 from protocol bgp
set term 6 then community add CUST
set term 6 then accept
exit

R3
!
edit protocols bgp group P2

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
195
196 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set import EBGP-FILTER

set import P2-IN
set export PEER-OUT
exit
edit policy-options policy-statement P2-IN
set term 4 from family inet
set term 4 from protocol bgp
set term 4 then community add PEER
set term 4 then accept
set term 6 from family inet6
set term 6 from protocol bgp
set term 6 then community add PEER
set term 6 then accept
exit

R4
!
edit protocols bgp group T1
set import EBGP-FILTER
set import T1-IN
set export TRANSIT-OUT
exit
edit policy-options policy-statement T1-IN
set term 4 from family inet
set term 4 from protocol bgp
set term 4 then community add TRANSIT
set term 4 then accept
set term 6 from family inet6
set term 6 from protocol bgp
set term 6 then community add TRANSIT
set term 6 then accept
exit
edit policy-options policy-statement T2-IN
set term 4 from family inet
set term 4 from protocol bgp
set term 4 then community add TRANSIT
set term 4 then accept
set term 6 from family inet6
set term 6 from protocol bgp
set term 6 then community add TRANSIT
set term 6 then accept
exit

R6
!
edit protocols bgp group C4
delete import
set import EBGP-FILTER
set import C4-IN-INET
set import C4-IN-INET6

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

exit
edit policy-options policy-statement C4-IN-INET
set term 4 from family inet
set term 4 from protocol bgp
set term 4 then community add CUST
set term 4 then accept
exit
edit policy-options policy-statement C4-IN-INET6
set term 1 then community add CUST
exit

Task 5 (5 points). Implement the following features/policies for Service Provider Network 1:

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
196
197 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

lab@VMX-R5> show route 100.0.0.0/24 active-path extensive | match balance

Protocol next hop: 150.1.1.1 Balance: 83%
Protocol next hop: 150.1.1.2 Balance: 17%

/* route reflection with multipath */

R1,R2,R5,R6
!
edit protocols bgp group IBGP
set family inet unicast add-path receive
set multipath multiple-as
exit

R3,R4
!
edit protocols bgp group IBGP
set family inet unicast add-path send path-count 4
set multipath multiple-as
exit
edit protocols bgp group IBGP-RR
set family inet unicast add-path send path-count 4
set family inet unicast add-path receive
set multipath multiple-as
exit

/* proportional load-sharing */

R1
!
edit policy-options policy-statement P1-IN
set term 4 then community add BW-5G
set term 6 then community add BW-5G
exit
edit policy-options policy-statement T1-IN
set term 4 then community add BW-1G
set term 6 then community add BW-1G
exit
edit policy-options policy-statement T2-IN
set term 4 then community add BW-2G
set term 6 then community add BW-2G
exit
set policy-options community BW-1G members bandwidth:16:1000
set policy-options community BW-2G members bandwidth:16:2000
set policy-options community BW-5G members bandwidth:16:5000

R2
!
edit policy-options policy-statement P1-IN
set term 4 then community add BW-1G

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

set term 6 then community add BW-1G
exit
edit policy-options policy-statement P2-IN
set term 4 then community add BW-6G
set term 6 then community add BW-6G
exit
edit policy-options policy-statement T2-IN
set term 4 then community add BW-1G
set term 6 then community add BW-1G
exit
set policy-options community BW-1G members bandwidth:16:1000
set policy-options community BW-6G members bandwidth:16:6000

R3
!
edit policy-options policy-statement P2-IN
set term 4 then community add BW-2G
set term 6 then community add BW-2G
exit
set policy-options community BW-2G members bandwidth:16:2000

R4
!
edit policy-options policy-statement T1-IN
set term 4 then community add BW-2.5G
set term 6 then community add BW-2.5G
exit

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
197
198 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set policy-options community BW-2.5G members bandwidth:16:2500

Task 6 (2 points). Announce the IPv4/IPv6 supernets of Service Provider Network 1 on R3 and R4 (2
static routes are allowed on each router).
R3
!
set routing-options aggregate route 150.1.0.0/16
set routing-options rib inet6.0 aggregate route 2016:150:1::/48
set protocols bgp group IBGP export AS-AGGREGATE
set protocols bgp group P2 export AS-AGGREGATE
edit policy-options policy-statement AS-AGGREGATE
set term 1 from protocol aggregate
set term 1 from route-filter 150.1.0.0/16 exact
set term 1 then accept
set term 2 from protocol aggregate
set term 2 from route-filter 2016:150:1::/48 exact
set term 2 then accept
exit

R4
!
set routing-options aggregate route 150.1.0.0/16
set routing-options rib inet6.0 aggregate route 2016:150:1::/48
set protocols bgp group IBGP export AS-AGGREGATE
set protocols bgp group T1 export AS-AGGREGATE
edit policy-options policy-statement AS-AGGREGATE
set term 1 from protocol aggregate
set term 1 from route-filter 150.1.0.0/16 exact
set term 1 then accept
set term 2 from protocol aggregate
set term 2 from route-filter 2016:150:1::/48 exact
set term 2 then accept
exit

Verification
Tasks 1 and 2. The first step is to ensure all iBGP neighbourships are Established for AS 1.57920 and
similarly for AS 78 plus the check that iBGP is installed as a client of BFD which verifies forwarding path
and liberates BGP from reliance upon OSPF for notification of device failure. BGP no longer needs to rely
on event-driven or periodic next-hop scanning. The ultimate outcome is to improve convergence by
rapidly detecting BGP neighbour failure.
lab@VMX-R3> show bgp summary | match 1.57920
150.1.1.1 1.57920 227 313 0 0 1:23:23 Establ

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

150.1.1.2 1.57920 154 237 0 0 53:35 Establ
150.1.1.4 1.57920 281 279 0 0 1:23:03 Establ
150.1.1.5 1.57920 188 341 0 0 1:23:43 Establ
150.1.1.6 1.57920 133 247 0 0 53:43 Establ

lab@VMX-R4> show bgp summary | match 150.1.1.[123456]

150.1.1.1 1.57920 162 241 0 0 53:31 Establ
150.1.1.2 1.57920 220 305 0 0 1:23:47 Establ
150.1.1.3 1.57920 279 280 0 0 1:23:03 Establ
150.1.1.5 1.57920 187 317 0 0 1:23:43 Establ
150.1.1.6 1.57920 199 311 0 0 1:23:39 Establ

lab@VMX-R7> show bgp summary | match 78

151.1.1.8 78 78 62 0 0 1:23:32 Establ

lab@VMX-R8> show bgp summary | match 78

151.1.1.7 78 64 77 0 0 1:23:24 Establ

lab@VMX-R7> show bfd session address 151.1.1.8 detail

Detect Transmit
Address State Interface Time Interval Multiplier
151.1.1.8 Up 2.000 0.500 4
Client BGP, TX interval 0.500, RX interval 0.500
Session up time 00:04:29
Local diagnostic None, remote diagnostic None
Remote state Up, version 1
Session type: Multi hop BFD

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
198
199 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

[edit]
lab@VMX-R6# deactivate protocols bgp group C4 neighbor 150.1.131.2 import

[edit]
lab@VMX-R6# deactivate protocols bgp group C4 neighbor 150.1.131.2 export

[edit]
lab@VMX-R6# commit
commit complete

[edit]
lab@VMX-R6# run show bgp summary
<snip>
150.1.131.2 65004 10 36 0 0 37 Establ
inet.0: 7/7/7/0
inet6.0: 0/0/0/0
<snip>

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

lab@VMX-VR# show interfaces ge-0/0/4.131
description C4-PE;
vlan-id 131;
family inet {
address 150.1.131.2/30;
}
family inet6 {
address ::150.1.131.2/126;
}

[edit]
lab@VMX-R6# commit
commit complete

[edit]
lab@VMX-R6# run clear bgp neighbor 150.1.131.2
Cleared 1 connections

lab@VMX-R6# run show bgp summary

<snip>
150.1.131.2 65004 32 84 0 3 2:26 Establ

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
199
200 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

inet.0: 7/7/7/0
inet6.0: 0/7/7/0
<snip>

[edit]
lab@VMX-R6# run show route receive-protocol bgp 150.1.131.2 table inet6.0 hidden

inet6.0: 60 destinations, 109 routes (53 active, 0 holddown, 7 hidden)

[edit]
lab@VMX-R6# run show route resolution unresolved
Tree Index 1
Tree Index 2
2016:170:1:244::/64
Protocol Nexthop: ::ffff:150.1.131.2
Indirect nexthop: 0 -
2016:170:1:243::/64
Protocol Nexthop: ::ffff:150.1.131.2
Indirect nexthop: 0 -
2016:170:1:242::/64
Protocol Nexthop: ::ffff:150.1.131.2
Indirect nexthop: 0 -
2016:170:1:241::/64
Protocol Nexthop: ::ffff:150.1.131.2
Indirect nexthop: 0 -
2016:170:1:240::/64
Protocol Nexthop: ::ffff:150.1.131.2
Indirect nexthop: 0 -
2016:170:1:246::1/128
Protocol Nexthop: ::ffff:150.1.131.2
Indirect nexthop: 0 -
2016:170:1:245::/64
Protocol Nexthop: ::ffff:150.1.131.2
Indirect nexthop: 0 -
Tree Index 3

Now let’s reactivate the corresponding policies which rewrite NEXT_HOP attribute and we should see
C4’s prefixes properly installed into BGP table on R6.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

lab@VMX-R6# activate protocols bgp group C4 neighbor 150.1.131.2 import

[edit]
lab@VMX-R6# activate protocols bgp group C4 neighbor 150.1.131.2 export

[edit]
lab@VMX-R6# commit
commit complete

[edit]
lab@VMX-R6# run clear bgp neighbor 150.1.131.2 soft

lab@VMX-R6# run show route receive-protocol bgp 150.1.131.2 table inet6.0

inet6.0: 60 destinations, 109 routes (60 active, 0 holddown, 0 hidden)

lab@VMX-R6# run show bgp summary

<snip>

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
200
201 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

150.1.131.2 65004 42 144 0 3 7:13 Establ

inet.0: 7/7/7/0
inet6.0: 7/7/7/0

[edit]
lab@VMX-R6# run show route resolution unresolved
Tree Index 1
Tree Index 2
Tree Index 3

• family inet6 labeled-unicast between iBGP neighbours to allocate labels for IPv6 prefixes over
IPv4 iBGP sessions so that we don't need to enable native IPv6 iBGP sessions in the core
network. This is followed by explicit-null keyword which will advertise MPLS label of "2"
indicating v6 in MPLS payload. Note: this keyword being set here is different from the same
keyword used in commands set protocols ldp explicit-null or set protocols mpls explicit-
null in which MPLS label will be advertised as "3" indicating PHP hop to not pop out the outer
label. Since our BGP implementation does require IPv4 routing/switching, we would need to
enable family inet unicast along family inet6 labeled-unicast, because without it only the
latter is activated between the routers.
• set protocols mpls ipv6-tunneling, we convert IPv4 next-hop being routers’ loopback address
in table inet.3 into IPv4-mapped IPv6 next-hop and install them into table inet6.3 for IPv6 label-
based forwarding.
• family inet6 on all core-facing interfaces, this is already configured as part of initial
configurations. There is no need for specific IPv6 address to be configured, but instead just the
activation of the IPv6 AFI on the interfaces.

By the end of task 2, we should test reachability of IPv4/IPv6 routing/switching between customers,
peers and transits. However let’s wait until policies from tasks 4,5 are in place to ensure we don’t
accidentally filter any test prefix.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

Task 3 requires some advanced tuning features with regard to BGP starting with the support of 32-bit
ASN on JUNOS, (routers negotiate the capability of 4-byte ASN via BGP Open messages). Using
statement asdot-notation we enable to display of the true 4-byte ASN, thus ASN 123456 is now shown
as 1.57920 as can be seen in the verification of task 1.

The next feature of task 3 is Path MTU discovery for BGP which enables the protocol to automatically
discover the best MTU for each session. PMTU discovery works by setting the Don’t Fragment (DF) bit in
the IP headers of outgoing packets. When an intermediate device along the path has MTU that is smaller
than the packet, it drops the packet and also sends back an ICMP Fragmentation Needed (Type 3, Code
4) message containing the smaller MTU. Upon receiving such ICMP message, the source host reduces its
path MTU appropriately.
lab@VMX-R7> show system connections extensive | find 151.1.1.8
tcp4 0 0 151.1.1.7.179 151.1.1.8.52228
ESTABLISHED
sndsbcc: 0 sndsbmbcnt: 0 sndsbmbmax: 131072
sndsblowat: 2048 sndsbhiwat: 16384
rcvsbcc: 0 rcvsbmbcnt: 0 rcvsbmbmax: 131072
rcvsblowat: 1 rcvsbhiwat: 16384
iss: 3268659223 sndup: 3268664176

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
201
202 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

snduna: 3268664176 sndnxt: 3268664176 sndwnd: 16384

sndmax: 3268664176 sndcwnd: 2896 sndssthresh: 2896
irs: 1937711298 rcvup: 1937718198
rcvnxt: 1937718198 rcvadv: 1937734582 rcvwnd: 16384
rtt: 0 srtt: 3190 rttv: 145
rxtcur: 1200 rxtshift: 0 rtseq: 3268664157
rttmin: 1000 mss: 1448
flags: REQ_SCALE RCVD_SCALE REQ_TSTMP RCVD_TSTMP SACK_PERMIT [0x20003e0]

The next feature of task 3 is Graceful Restart which allows a router undergoing a restart event, including
restart of the routing protocol daemon (rpd) to inform its adjacent neighbors and peers of its condition.
The restarting router requests a grace period from its neighbors or peers, which can then cooperate
with it. During restart event, the restarting router can still forward traffic and convergence in the
network is not disrupted. The neighbors or peers of the restarting router also known as helper routers
hide the restart event from other devices not directly connected to the restarting router. You can enable
GR globally for all protocols (OSPF, IS-IS, BGP) with statement routing-options graceful-restart or just
BGP via statement set protocols bgp graceful-restart.
lab@VMX-R7> show bgp neighbor 151.1.1.8 | match "restart|Table"
NLRI for restart configured on peer: inet-unicast inet-vpn-unicast inet-labeled-unicast
Peer does not support Restarter functionality
Restart flag received from the peer: Notification
NLRI that restart is negotiated for: inet-unicast inet-vpn-unicast inet-labeled-unicast
Peer does not support LLGR Restarter functionality
Table inet.0 Bit: 20001
RIB State: BGP restart is complete
Table inet.3 Bit: 30001
RIB State: BGP restart is complete
Table bgp.l3vpn.0
RIB State: BGP restart is complete
RIB State: VPN restart is complete
Table VPN1.inet.0 Bit: 50000
RIB State: BGP restart is complete
RIB State: VPN restart is complete

Service Providers could use Private ASN in the range of 64512-65534 to allocate to their customers,
however such ASN should not be in the AS_PATH of public Internet routes. We can use statement
remove-private all at protocol BGP level to do remove Private ASN for all routes, the keyword all tells
the router to not stop at the first Private ASN that it could find. As can be seen in the output below, R1
has removed AS 65001 in C1 prefixes when advertising to upstream transit T1.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

lab@VMX-R1> show bgp neighbor 111.1.120.2 | match Private
Options: <Preference RemovePrivateAS PeerAS Multipath Refresh>
Remove-private options: all

lab@VMX-R1> show route receive-protocol bgp 150.1.119.2 table inet.0

inet.0: 80 destinations, 163 routes (67 active, 0 holddown, 16 hidden)

Prefix Nexthop MED Lclpref AS path
* 170.1.210.0/24 150.1.119.2 65001 I
* 170.1.211.0/24 150.1.119.2 65001 I
* 170.1.212.0/24 150.1.119.2 65001 I
* 170.1.213.0/24 150.1.119.2 65001 I
* 170.1.214.0/24 150.1.119.2 65001 I
* 170.1.215.0/24 150.1.119.2 65001 I
* 170.1.216.1/32 150.1.119.2 65001 I

lab@VMX-R1> show route advertising-protocol bgp 111.1.120.2 table inet.0 | match

"170.1.21"
* 170.1.210.0/24 Self I
* 170.1.211.0/24 Self I
* 170.1.212.0/24 Self I
* 170.1.213.0/24 Self I
* 170.1.214.0/24 Self I
* 170.1.215.0/24 Self I
* 170.1.216.1/32 Self I

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
202
203 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Task 3 also demonstrates an important feature of BGP configured by statement prefix-limit where the
number of prefixes learnt via peers is limited to 1000, this is to protect from mistakes such as Internet
routing table is leaked via peers which could draw all traffic to peers’ networks. By default, violated BGP
session will stay down but we can allow for it to self-heal after a period.

Task 4 illustrates three basic Internet routing protections of any Service Provider network, starting with
filtering ‘bogon’ prefixes and also more-specific subnets. RFCs 1918, 3330, 5735, and 6598 define
specific IP address ranges which are used for special purpose rather than regular routing over the
Internet. Such ranges are referred as ‘bogon’ addresses. Best practices indicate that we not only should
drop Internet traffic sourcing from those ranges completely (as implemented by Practice Lab 2) but also
refuse to learn routing information about them on public Internet BGP session in this Practice Lab 3. We
simply create a prefix list containing all bogon prefixes and discard them via import policy statement. It
would be more flexible for us to have two import policies, one doing filtering and one tweaking BGP
attributes (if needed) in the future. The first import policy being EBGP-FILTER can be used on an AS-wide
basis as inbound filtering standard, allowed prefixes are then progressed to the next policy for other
attribute manipulation by statement then next policy, all unmatched prefixes are discarded using term
DENY-ALL at the end.

lab@VMX-R1> show route receive-protocol bgp 111.1.120.2 table inet.0

inet.0: 99 destinations, 285 routes (83 active, 0 holddown, 33 hidden)

Prefix Nexthop MED Lclpref AS path
6.0.0.0/8 111.1.120.2 111 123 12 47 591 412
551 267 6 I
7.0.0.0/8 111.1.120.2 111 123 235 1256 2356
9587 6834 1351 7 I
8.0.0.0/8 111.1.120.2 111 123 549 8973 2168
5488 2437 5489 6543 8 I
9.0.0.0/8 111.1.120.2 111 123 1125 2678 35122
42516 54754 6125 751 8623 9 I
12.0.0.0/24 111.1.120.2 111 I
* 23.0.0.0/24 111.1.120.2 111 123 I
30.1.0.0/16 111.1.120.2 111 123 301 I
30.2.0.0/16 111.1.120.2 111 123 302 I
30.3.0.0/16 111.1.120.2 111 123 303 I
30.4.0.0/16 111.1.120.2 111 123 304 I
100.0.0.0/24 111.1.120.2 111 100 I
100.5.0.0/21 111.1.120.2 111 100 I

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

* 111.0.0.0/24 111.1.120.2 111 I
* 111.3.0.0/23 111.1.120.2 111 I
* 111.4.0.0/22 111.1.120.2 111 I
* 111.5.0.0/21 111.1.120.2 111 I
123.0.0.0/24 111.1.120.2 111 123 I
123.0.1.0/24 111.1.120.2 111 123 I
123.0.2.0/24 111.1.120.2 111 123 I
123.0.3.0/24 111.1.120.2 111 123 I
123.0.4.0/24 111.1.120.2 111 123 I
123.3.0.0/23 111.1.120.2 111 123 I
123.4.0.0/22 111.1.120.2 111 123 I
123.5.0.0/21 111.1.120.2 111 123 I

lab@VMX-R1> show route receive-protocol bgp 111.1.120.2 table inet.0 hidden

inet.0: 99 destinations, 285 routes (83 active, 0 holddown, 33 hidden)

Prefix Nexthop MED Lclpref AS path
10.0.0.0/29 111.1.120.2 111 123 I
100.6.0.1/32 111.1.120.2 111 100 I
111.1.0.0/26 111.1.120.2 111 I
111.2.0.0/25 111.1.120.2 111 I
111.6.0.1/32 111.1.120.2 111 I
123.1.0.0/26 111.1.120.2 111 123 I
123.2.0.0/25 111.1.120.2 111 123 I
123.6.0.1/32 111.1.120.2 111 123 I
172.16.0.0/28 111.1.120.2 111 123 I
192.168.1.0/27 111.1.120.2 111 123 I

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
203
204 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

The Service Provider network does not provide transit services for its peer and in reality might even
charge the peers with lower rate. Therefore another basic filtering that task 4 discusses is to ensure
Internet routes are not leaked to peers and vice versa: peers’ routes are not leaked to Internet. To
achieve this goal, we simply tag Internet and peers’ routes with different BGP communities in the
inbound and filter them in the outbound. Task 4 also specifically requires that prefixes learnt via one
transit is not propagated to another and this is achieved in the same manner.
lab@VMX-R1> show route advertising-protocol bgp 150.1.100.2 aspath-regex ".* (111|222)
.*" | except destinations | count
Count: 0 lines

lab@VMX-R1> show route advertising-protocol bgp 111.1.120.2 aspath-regex ".* (100|200)

.*" | except destinations | count
Count: 0 lines

Task 5 discusses two advanced BGP features in relation to propagating multipath information across
route reflectors and proportional ECMP.

Firstly, with route reflection the scalability issue of full-mesh iBGP is resolved but another problem
arises, i.e. the route reflector(s) will only reflect one single best path in spite of the presence of multiple
best paths. From route reflectors’ perspectives, they still can use multiple best paths (ECMP) for
forwarding traffic but their clients won’t have the visibility into multiple best paths. In this topology,
with route reflectors R3 and R4, R5 and R6 will not be able to use both R1 and R2 at the same time as
egress hops to reach P1 prefixes because R3 and R4 will reflect only one best path, either via R1 or via
R2. Add-path feature will resolve this problem by allowing R3 and R4 to send multipath information up
to a configured number of such paths. The configuration is achieved by applying add-path send/receive
statement at the NLRI level. As you can see below, R5 receives multipath information from route
reflector R3 and could use it to load-share traffic between R1-P1 and R2-P1 connections (i.e. via LSPs to
R1 and R2).
lab@VMX-R5> show route receive-protocol bgp 150.1.1.3 table inet.0 aspath-regex ".* 100
.*"

inet.0: 87 destinations, 251 routes (83 active, 0 holddown, 4 hidden)

Prefix Nexthop MED Lclpref AS path
* 100.0.0.0/24 150.1.1.1 100 100 I

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

150.1.1.2 100 100 I
150.1.1.4 100 111 100 I
* 100.3.0.0/23 150.1.1.1 100 100 I
150.1.1.2 100 100 I
* 100.4.0.0/22 150.1.1.1 100 100 I
150.1.1.2 100 100 I
* 100.5.0.0/21 150.1.1.1 100 100 I
150.1.1.2 100 100 I
150.1.1.4 100 111 100 I

lab@VMX-R5> show route 100.0.0.0/24 active-path

inet.0: 87 destinations, 251 routes (83 active, 0 holddown, 4 hidden)

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

100.0.0.0/24 *[BGP/170] 01:37:00, localpref 100, from 150.1.1.3

AS path: 100 I, validation-state: unverified
> to 150.1.35.3 via ae7.0, label-switched-path R5-TO-R1
to 150.1.45.4 via ae8.0, label-switched-path R5-TO-R1
to 150.1.45.4 via ae8.0, label-switched-path Bypass->150.1.35.3
to 150.1.35.3 via ae7.0, label-switched-path Bypass->150.1.45.4
to 150.1.45.4 via ae8.0, label-switched-path R5-TO-R2
to 150.1.35.3 via ae7.0, label-switched-path R5-TO-R2
to 150.1.35.3 via ae7.0, label-switched-path Bypass->150.1.45.4
to 150.1.45.4 via ae8.0, label-switched-path Bypass->150.1.35.3

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
204
205 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Another interesting point is the ability for BGP to proportionally load-share traffic rate across multiple
best paths based on external bandwidth capacity. The table in task 2 provides capacity information of
external links, for example we can see that R1-P1 has got 5Gbps while R2-P1 only has got 1Gbps. It
would be great for R5 to load-share traffic with ratio 5:1 when sending traffic to R1-P1 and R2-P1. This is
achieved by using an extended community bandwidth:value1:value2 where value1 is arbitrary and value
2 is corresponding to bandwidth. The value2 does not need to be in an exact unit such as bps, Mbps or
Gbps, but instead it doesn’t have a unit. It is up to the Service Provider to specify it. The bandwidth
community is tagged to all prefixes on the inbound of the link and the BGP routers will be able to
calculate the ratio. As can be seen below, 83% : 17% is roughly equivalent to 5:1.
lab@VMX-R5> show route 100.0.0.0/24 active-path extensive | match "Source:|Protocol next
hop:|Multipath|Balance|AS path:|Comm"
Source: 150.1.1.3
Protocol next hop: 150.1.1.1 Balance: 83%
Protocol next hop: 150.1.1.2 Balance: 17%
AS path: 100 I (Originator) Cluster list: 150.1.1.3
AS path: Originator ID: 150.1.1.1
AS path:
AS path: Recorded
Communities: 16:2000 bandwidth:16:5000
Accepted Multipath
Protocol next hop: 150.1.1.1 Metric: 200
Protocol next hop: 150.1.1.2 Metric: 200

This extended community also has effect on BGP router has got multiple eBGP paths as well. We can see
that R1 can load-balance traffic in ratio 67% : 33% (2Gbps : 1Gbps) across both links via T1 and T2.
lab@VMX-R1> show route 123.0.0.1 active-path extensive
<snip>
Path 123.0.0.0 from 222.1.106.2 Vector len 4. Val: 0 3
*BGP Preference: 170/-101
Next hop type: Router, Next hop index: 262160
Address: 0x95a0558
Next-hop reference count: 15
Source: 222.1.106.2
Next hop: 222.1.106.2 via ge-0/0/4.106 balance 67%, selected
Next hop: 111.1.120.2 via ge-0/0/4.120 balance 33%
State: <Active Ext>
Local AS: 1.57920 Peer AS: 222
Age: 1:38:47
Task: BGP_222.222.1.106.2+51110
Announcement bits (4): 0-KRT 1-RT 5-BGP_RT_Background 6-Resolve tree 4

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

AS path: 222 123 I
AS path: Recorded
Communities: 16:1000 bandwidth:16:2000
Accepted Multipath
Localpref: 100
Router ID: 222.0.0.1

Now let’s test IPv4/v6 reachability between customers, peers and transits by issuing ping tests from
customer C1 for example:
IPv4:

lab@VMX-VR> ping rapid routing-instance C1 source 170.1.210.1 170.1.240.1

lab@VMX-VR> ping rapid routing-instance C1 source 170.1.210.1 100.0.0.1

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
205
206 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

lab@VMX-VR> ping rapid routing-instance C1 source 170.1.210.1 200.0.0.1

PING 200.0.0.1 (200.0.0.1): 56 data bytes
!!!!!
--- 200.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 19.865/20.960/24.461/1.755 ms

lab@VMX-VR> ping rapid routing-instance C1 source 170.1.210.1 111.0.0.1

lab@VMX-VR> ping rapid routing-instance C1 source 170.1.210.1 222.0.0.1

PING 222.0.0.1 (222.0.0.1): 56 data bytes
!!!!!
--- 222.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 14.822/14.953/15.035/0.076 ms

lab@VMX-VR> ping rapid routing-instance C1 source 170.1.210.1 12.0.0.1

PING 12.0.0.1 (12.0.0.1): 56 data bytes
!!!!!
--- 12.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 14.785/14.952/15.056/0.110 ms

lab@VMX-VR> ping rapid routing-instance C1 source 170.1.210.1 12.0.0.2

PING 12.0.0.2 (12.0.0.2): 56 data bytes
!!!!!
--- 12.0.0.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 13.094/15.040/17.323/1.347 ms

IPv6:

lab@VMX-VR> ping rapid routing-instance C1 source 2016:170:1:210::1 2016:170:1:240::1

lab@VMX-VR> ping rapid routing-instance C1 source 2016:170:1:210::1 2016:100::1

PING6(56=40+8+8 bytes) 2016:170:1:210::1 --> 2016:100::1
!!!!!
--- 2016:100::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

round-trip min/avg/max/std-dev = 19.666/19.920/20.127/0.160 ms

lab@VMX-VR> ping rapid routing-instance C1 source 2016:170:1:210::1 2016:200::1

lab@VMX-VR> ping rapid routing-instance C1 source 2016:170:1:210::1 2016:111::1

lab@VMX-VR> ping rapid routing-instance C1 source 2016:170:1:210::1 2016:222::1

lab@VMX-VR> ping rapid routing-instance C1 source 2016:170:1:210::1 2016:12::1

PING6(56=40+8+8 bytes) 2016:170:1:210::1 --> 2016:12::1
!!!!!
--- 2016:12::1 ping6 statistics ---

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
206
207 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

5 packets transmitted, 5 packets received, 0% packet loss

round-trip min/avg/max/std-dev = 19.462/19.873/20.262/0.279 ms

lab@VMX-VR> ping rapid routing-instance C1 source 2016:170:1:210::1 2016:12::2

Task 6 is really about announcing aggregated prefixes of Service Provider Network 1 on R3 and R4 with a
policy that is applied to their BGP sessions, matching on locally-generated supernets being 150.1.0.0/16
and 2016:150:1::/48.
lab@VMX-R3> show route advertising-protocol bgp 150.1.137.2 | match 150.1.0.0/16
* 150.1.0.0/16 Self I

lab@VMX-R3> show route advertising-protocol bgp 150.1.1.1 | match 150.1.0.0/16

* 150.1.0.0/16 Self 100 I

lab@VMX-R4> show route advertising-protocol bgp 111.1.105.2 | match 150.1.0.0/16

* 150.1.0.0/16 Self I

lab@VMX-R4> show route advertising-protocol bgp 150.1.1.1 | match 150.1.0.0/16

* 150.1.0.0/16 Self 100 I

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
207
208 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 5: VPN
Total Points: 20

• CE1-1: 172.30.1[0-9].1
• CE1-2: 172.30.2[0-9].1
• CE1-3: 172.30.3[0-9].1

R1,R3,R4,R5,R6
!
set routing-options autonomous-system loops 3
set protocols bgp group IBGP family inet-vpn unicast
set policy-options community VPN1-HUB-RT member target:16:3310
set policy-options community VPN1-HUB-SOO member origin:16:3310
set policy-options community VPN1-SPOKE-RT member target:16:3311
set policy-options community VPN1-SPOKE-SOO member origin:16:3311

R3,R4
!
set routing-options autonomous-system loops 3
set protocols bgp group IBGP-RR family inet-vpn unicast

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

set vrf-import VPN1-SPOKE-IMPORT
set vrf-export DENY-ALL
set interface ge-0/0/4.118
set protocols bgp group VPN1-SPOKE type external
set protocols bgp group VPN1-SPOKE peer-as 65501
set protocols bgp group VPN1-SPOKE as-override
set protocols bgp group VPN1-SPOKE neighbor 172.16.118.2
exit
set policy-options policy-statement DENY-ALL term DENY-ALL then reject
edit policy-options policy-statement VPN1-HUB-EXPORT
set term 1 from protocol [direct bgp]
set term 1 then community set VPN1-HUB-RT
set term 1 then community add VPN1-HUB-SOO
set term 1 then accept
exit
edit policy-options policy-statement VPN1-SPOKE-IMPORT
set term 1 from protocol bgp
set term 1 from community VPN1-HUB-SOO
set term 1 then reject
set term 2 from protocol bgp
set term 2 from community VPN1-SPOKE-RT
set term 2 then accept
exit
R3
!
set routing-options route-distinguisher-id 150.1.1.3
edit routing-instance VPN1-HUB

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
208
209 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set instance-type vrf

set vrf-import DENY-ALL
set vrf-export VPN1-HUB-EXPORT
set interface ge-0/0/4.132
set protocols bgp group VPN1-HUB type external
set protocols bgp group VPN1-HUB peer-as 65501
set protocols bgp group VPN1-HUB as-override
set protocols bgp group VPN1-HUB neighbor 172.16.132.2
exit
edit routing-instance VPN1-SPOKE
set instance-type vrf
set vrf-import VPN1-SPOKE-IMPORT
set vrf-export DENY-ALL
set interface ge-0/0/4.133
set protocols bgp group VPN1-SPOKE type external
set protocols bgp group VPN1-SPOKE peer-as 65501
set protocols bgp group VPN1-SPOKE as-override
set protocols bgp group VPN1-SPOKE neighbor 172.16.133.2
exit
set policy-options policy-statement DENY-ALL term DENY-ALL then reject
edit policy-options policy-statement VPN1-HUB-EXPORT
set term 1 from protocol [direct bgp]
set term 1 then community set VPN1-HUB-RT
set term 1 then community add VPN1-HUB-SOO
set term 1 then accept
exit
edit policy-options policy-statement VPN1-SPOKE-IMPORT
set term 1 from protocol bgp
set term 1 from community VPN1-HUB-SOO
set term 1 then reject
set term 2 from protocol bgp
set term 2 from community VPN1-SPOKE-RT
set term 2 then accept
exit

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

set term 1 then community add VPN1-SPOKE-RT
set term 1 then community add VPN1-SPOKE-SOO
set term 1 then accept
exit
edit policy-options policy-statement VPN1-SPOKE-IMPORT
set term 1 from protocol bgp
set term 1 from community VPN1-SPOKE-SOO
set term 1 then reject
set term 2 from protocol bgp
set term 2 from community VPN1-HUB-RT
set term 2 then accept
exit

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
209
210 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set term 1 from protocol [direct bgp]

set term 1 then community add VPN1-SPOKE-RT
set term 1 then accept
exit
edit policy-options policy-statement VPN1-SPOKE-IMPORT
set term 1 from protocol bgp
set term 1 from community VPN1-HUB-RT
set term 1 then accept
exit

R6
!
set routing-options route-distinguisher-id 150.1.1.6
edit routing-instance VPN1-SPOKE
set instance-type vrf
set vrf-import VPN1-SPOKE-IMPORT
set vrf-export VPN1-SPOKE-EXPORT
set interface ge-0/0/4.134
set protocols bgp group VPN1-SPOKE type external
set protocols bgp group VPN1-SPOKE peer-as 65501
set protocols bgp group VPN1-SPOKE as-override
set protocols bgp group VPN1-SPOKE neighbor 172.16.134.2
exit
edit policy-options policy-statement VPN1-SPOKE-EXPORT
set term 1 from protocol [direct bgp]
set term 1 then community add VPN1-SPOKE-RT
set term 1 then community add VPN1-SPOKE-SOO
set term 1 then accept
exit
edit policy-options policy-statement VPN1-SPOKE-IMPORT
set term 1 from protocol bgp
set term 1 from community VPN1-SPOKE-SOO
set term 1 then reject
set term 2 from protocol bgp
set term 2 from community VPN1-HUB-RT
set term 2 then accept
exit

• CE1-4: 172.30.13[0-9].1

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

• CE1-5: 172.30.11[0-9].1
R7
!
set routing-options route-distinguisher-id 151.1.1.7
set protocols bgp group IBGP family inet-vpn unicast
set interface lo0.1 family inet address 151.1.1.77/32
edit routing-instance VPN1
set instance-type vrf
set vrf-import VPN1-IMPORT
set vrf-export VPN1-EXPORT
set interface ge-0/0/4.138
set interface lo0.1
set protocols ospf sham-link local 151.1.1.77
set protocols ospf area 0.0.0.0 sham-link-remote 151.1.1.88 metric 10
set protocols ospf area 0.0.0.0 interface ge-0/0/4.138
set protocols ospf export BGP-TO-OSPF
exit
edit policy-options policy-statement VPN1-EXPORT
set term 1 from protocol [direct ospf]
set term 1 then community add VPN1-RT
set term 1 then accept
exit
edit policy-options policy-statement VPN1-IMPORT
set term 1 from protocol bgp
set term 1 from community VPN1-RT

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
210
211 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set term 1 then accept

exit
edit policy-options policy-statement BGP-TO-OSPF
set term 1 from protocol bgp
set term 1 then accept
exit
set policy-options community VPN1-RT members target:78:3311

R8
!
set routing-options route-distinguisher-id 151.1.1.8
set protocols bgp group IBGP family inet-vpn unicast
set interface lo0.1 family inet address 151.1.1.88/32
edit routing-instance VPN1
set instance-type vrf
set vrf-import VPN1-IMPORT
set vrf-export VPN1-EXPORT
set interface ge-0/0/4.129
set interface lo0.1
set protocols ospf sham-link local 151.1.1.88
set protocols ospf area 0.0.0.0 sham-link-remote 151.1.1.77 metric 10
set protocols ospf area 0.0.0.0 interface ge-0/0/4.129
set protocols ospf export BGP-TO-OSPF
exit
edit policy-options policy-statement VPN1-EXPORT
set term 1 from protocol [direct ospf]
set term 1 then community add VPN1-RT
set term 1 then accept
exit
edit policy-options policy-statement VPN1-IMPORT
set term 1 from protocol bgp
set term 1 from community VPN1-RT
set term 1 then accept
exit
edit policy-options policy-statement BGP-TO-OSPF
set term 1 from protocol bgp
set term 1 then accept
exit
set policy-options community VPN1-RT members target:78:3311

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

set protocols bgp group IBGP family inet labeled-unicast rib inet.3

R3
!
set protocols bgp group IBGP family inet labeled-unicast rib inet.3
set protocols bgp group IBGP-RR family inet labeled-unicast rib inet.3
edit protocols bgp group AS78-RR
set type external
set peer-as 78
set family inet-vpn unicast
set neighbor 151.1.1.8
set local-address 150.1.1.3
set import AS78-IN-VPN
set export AS78-OUT-VPN
set multihop no-nexthop-change
exit
edit policy-options policy-statement AS78-IN-VPN
set term 1 from family inet-vpn
set term 1 from protocol bgp
set term 1 from community VPN1-SPOKE-RT-EXTERNAL
set term 1 then community set VPN1-SPOKE-RT
set term 1 then accept
exit
edit policy-options policy-statement AS78-OUT-VPN
set term 1 from family inet-vpn
set term 1 from protocol bgp
set term 1 from community VPN1-HUB-RT

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
211
212 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set term 1 then community set VPN1-SPOKE-RT-EXTERNAL

R4
!
set protocols bgp group IBGP family inet labeled-unicast rib inet.3
set protocols bgp group IBGP-RR family inet labeled-unicast rib inet.3
edit protocols bgp group AS78-RR
set type external
set peer-as 78
set family inet-vpn unicast
set neighbor 151.1.1.8
set local-address 150.1.1.4
set import AS78-IN-VPN
set export AS78-OUT-VPN
set multihop no-nexthop-change
exit
edit policy-options policy-statement AS78-IN-VPN
set term 1 from family inet-vpn
set term 1 from protocol bgp
set term 1 from community VPN1-SPOKE-RT-EXTERNAL
set term 1 then community set VPN1-SPOKE-RT
set term 1 then accept
exit
edit policy-options policy-statement AS78-OUT-VPN
set term 1 from family inet-vpn
set term 1 from protocol bgp
set term 1 from community VPN1-HUB-RT
set term 1 then community set VPN1-SPOKE-RT-EXTERNAL
set term 1 then accept
exit
set policy-options community VPN1-HUB-RT member target:16:3310
set policy-options community VPN1-SPOKE-RT member target:16:3311
set policy-options community VPN1-SPOKE-RT-EXTERNAL member target:78:3311

R5
!
set protocols bgp group IBGP family inet labeled-unicast rib inet.3
set interface ge-0/0/6.0 family mpls
set protocol mpls interface all
edit protocols bgp group AS78-ASBR
set type external
set peer-as 78
set family inet unicast
set family inet labeled-unicast rib inet.3
set neighbor 150.1.57.7

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

set export AS78-ASBR-OUT
exit
edit policy-options policy-statement AS78-ASBR-OUT
set term INET0 from route-filter 150.1.1.0/24 prefix-length /32-/32
set term INET0 then accept
set term INET3 from rib inet.3
set term INET3 from route-filter 150.1.1.0/24 prefix-length /32-/32
set term INET3 then accept
exit
set routing-options rib-group INET0-TO-INET3 import-rib [inet.0 inet.3]
set routing-options rib-group INET0-TO-INET3 import-policy INET0-TO-INET3
set routing-options interface-routes rib-group INET0-TO-INET3
edit policy-options policy-statement INET0-TO-INET3
set term DIRECT from protocol direct
set term DIRECT from route-filter 150.1.1.5/32 exact
set term DIRECT then accept
set term DENY-ALL then reject
exit

R6
!
set protocols bgp group IBGP family inet labeled-unicast rib inet.3
set interface ge-0/0/6.0 family mpls
set protocol mpls interface all
edit protocols bgp group AS78-ASBR
set type external
set peer-as 78

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
212
213 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set family inet unicast

set family inet labeled-unicast rib inet.3
set neighbor 150.1.68.8
set export AS78-ASBR-OUT
exit
edit policy-options policy-statement AS78-ASBR-OUT
set term INET0 from route-filter 150.1.1.0/24 prefix-length /32-/32
set term INET0 then accept
set term INET3 from rib inet.3
set term INET3 from route-filter 150.1.1.0/24 prefix-length /32-/32
set term INET3 then accept
exit
set routing-options rib-group INET0-TO-INET3 import-rib [inet.0 inet.3]
set routing-options rib-group INET0-TO-INET3 import-policy INET0-TO-INET3
set routing-options interface-routes rib-group INET0-TO-INET3
edit policy-options policy-statement INET0-TO-INET3
set term DIRECT from protocol direct
set term DIRECT from route-filter 150.1.1.6/32 exact
set term DIRECT then accept
set term DENY-ALL then reject
exit

R7
!
set interface ge-0/0/6.0 family mpls
set protocols ospf area 0.0.0.0 interface ge-0/0/6.0 passive
edit protocols bgp group IBGP
set family inet unicast
set family inet labeled-unicast rib inet.3
exit
edit protocols bgp group AS123456-ASBR
set type external
set peer-as 123456
set family inet unicast
set family inet labeled-unicast rib inet.3
set neighbor 150.1.57.5
set export AS123456-ASBR-OUT
exit
edit policy-options policy-statement AS123456-ASBR-OUT
set term INET0 from route-filter 151.1.1.0/24 prefix-length /32-/32
set term INET0 then accept
set term INET3 from rib inet.3
set term INET3 from route-filter 151.1.1.0/24 prefix-length /32-/32
set term INET3 then accept
exit
set routing-options rib-group INET0-TO-INET3 import-rib [inet.0 inet.3]
set routing-options rib-group INET0-TO-INET3 import-policy INET0-TO-INET3
set routing-options interface-routes rib-group INET0-TO-INET3
edit policy-options policy-statement INET0-TO-INET3
set term DIRECT from protocol direct

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

set term DIRECT from route-filter 151.1.1.7/32 exact
set term DIRECT then accept
set term DENY-ALL then reject
exit

R8
!
set interface ge-0/0/6.0 family mpls
set protocols ospf area 0.0.0.0 interface ge-0/0/6.0 passive
edit protocols bgp group IBGP
set family inet unicast
set family inet labeled-unicast rib inet.3
exit
edit protocols bgp group AS123456-ASBR
set type external
set peer-as 123456
set family inet unicast
set family inet labeled-unicast rib inet.3
set neighbor 150.1.68.6
set export AS123456-ASBR-OUT
exit
edit policy-options policy-statement AS123456-ASBR-OUT
set term INET0 from route-filter 151.1.1.0/24 prefix-length /32-/32
set term INET0 then accept
set term INET3 from rib inet.3
set term INET3 from route-filter 151.1.1.0/24 prefix-length /32-/32
set term INET3 then accept

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
213
214 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

exit
edit protocols bgp group AS123456-RR
set type external
set peer-as 123456
set family inet-vpn unicast
set neighbor 150.1.1.3
set neighbor 150.1.1.4
set local-address 151.1.1.8
set multihop no-nexthop-change
exit
set routing-options rib-group INET0-TO-INET3 import-rib [inet.0 inet.3]
set routing-options rib-group INET0-TO-INET3 import-policy INET0-TO-INET3
set routing-options interface-routes rib-group INET0-TO-INET3
edit policy-options policy-statement INET0-TO-INET3
set term DIRECT from protocol direct
set term DIRECT from route-filter 151.1.1.8/32 exact
set term DIRECT then accept
set term DENY-ALL then reject
exit

Verification
Task 1. This task is quite similar to topic 5, task 1 of Practice Lab 1 where hub-spoke MPLS L3 VPN is
required with BGP as the PE-CE routing protocol. However the current task introduces the scenario of
dual uplinks for the hub CE1-1 and the spoke CE1-2 with a requirement of blocking routing loops. This is
simply achieved by adding an extended community BGP SoO (Site of Origin) when exporting prefixes
from PE routers and at the same time discarding prefixes tagged with the same BGP SoO value when
importing prefixes into the local Spoke VRF.

Firstly let’s ensure all BGP neighbourships with CE routers are now Established. And then we check
routing instance on spoke PE routers R4 and/or R6 to see whether they now have VPN routes advertised
by the hub PE routers being R1 and R3 as well as each other’s.
lab@VMX-R1> show bgp summary | match 65501
172.16.117.2 65501 1286 1310 0 0 9:56:16 Establ
172.16.118.2 65501 1262 1309 0 0 9:56:12 Establ

lab@VMX-R3> show bgp summary | match 65501

172.16.132.2 65501 1285 1315 0 0 9:56:44 Establ
172.16.133.2 65501 1261 1314 0 0 9:56:40 Establ

lab@VMX-R4> show bgp summary | match 65501

172.16.103.2 65501 1265 1315 0 0 9:56:28 Establ

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

lab@VMX-R5> show bgp summary | match 65501
172.16.112.2 65501 1272 1321 0 0 9:56:32 Establ

lab@VMX-R6> show bgp summary | match 65501

172.16.134.2 65501 1264 1323 0 0 9:56:29 Establ

lab@VMX-R4> show route table VPN1-SPOKE.inet.0 protocol bgp active-path | match 172.30
172.30.10.0/24 *[BGP/170] 09:57:56, localpref 100, from 150.1.1.3
172.30.11.0/24 *[BGP/170] 09:57:56, localpref 100, from 150.1.1.3
172.30.12.0/24 *[BGP/170] 09:57:56, localpref 100, from 150.1.1.3
172.30.13.0/24 *[BGP/170] 09:57:56, localpref 100, from 150.1.1.3
172.30.14.0/24 *[BGP/170] 09:57:56, localpref 100, from 150.1.1.3
172.30.15.0/24 *[BGP/170] 09:57:56, localpref 100, from 150.1.1.3
172.30.16.0/24 *[BGP/170] 09:57:56, localpref 100, from 150.1.1.3
172.30.17.0/24 *[BGP/170] 09:57:56, localpref 100, from 150.1.1.3
172.30.18.0/24 *[BGP/170] 09:57:56, localpref 100, from 150.1.1.3
172.30.19.0/24 *[BGP/170] 09:57:56, localpref 100, from 150.1.1.3
172.30.20.0/24 *[BGP/170] 09:57:51, localpref 100
172.30.21.0/24 *[BGP/170] 09:57:51, localpref 100
172.30.22.0/24 *[BGP/170] 09:57:51, localpref 100
172.30.23.0/24 *[BGP/170] 09:57:51, localpref 100
172.30.24.0/24 *[BGP/170] 09:57:51, localpref 100
172.30.25.0/24 *[BGP/170] 09:57:51, localpref 100
172.30.26.0/24 *[BGP/170] 09:57:51, localpref 100
172.30.27.0/24 *[BGP/170] 09:57:51, localpref 100
172.30.28.0/24 *[BGP/170] 09:57:51, localpref 100

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
214
215 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

172.30.29.0/24 *[BGP/170] 09:57:51, localpref 100

172.30.30.0/24 *[BGP/170] 09:57:47, localpref 100, from 150.1.1.3
172.30.31.0/24 *[BGP/170] 09:57:47, localpref 100, from 150.1.1.3
172.30.32.0/24 *[BGP/170] 09:57:47, localpref 100, from 150.1.1.3
172.30.33.0/24 *[BGP/170] 09:57:47, localpref 100, from 150.1.1.3
172.30.34.0/24 *[BGP/170] 09:57:47, localpref 100, from 150.1.1.3
172.30.35.0/24 *[BGP/170] 09:57:47, localpref 100, from 150.1.1.3
172.30.36.0/24 *[BGP/170] 09:57:47, localpref 100, from 150.1.1.3
172.30.37.0/24 *[BGP/170] 09:57:47, localpref 100, from 150.1.1.3
172.30.38.0/24 *[BGP/170] 09:57:47, localpref 100, from 150.1.1.3
172.30.39.0/24 *[BGP/170] 09:57:47, localpref 100, from 150.1.1.3
<snip routes from CE1-4 and CE1-5 if exist>

lab@VMX-R5> show route table VPN1-SPOKE.inet.0 protocol bgp active-path | match 172.30
172.30.10.0/24 *[BGP/170] 12:41:49, localpref 100, from 150.1.1.3
172.30.11.0/24 *[BGP/170] 12:41:49, localpref 100, from 150.1.1.3
172.30.12.0/24 *[BGP/170] 12:41:49, localpref 100, from 150.1.1.3
172.30.13.0/24 *[BGP/170] 12:41:49, localpref 100, from 150.1.1.3
172.30.14.0/24 *[BGP/170] 12:41:49, localpref 100, from 150.1.1.3
172.30.15.0/24 *[BGP/170] 12:41:49, localpref 100, from 150.1.1.3
172.30.16.0/24 *[BGP/170] 12:41:49, localpref 100, from 150.1.1.3
172.30.17.0/24 *[BGP/170] 12:41:49, localpref 100, from 150.1.1.3
172.30.18.0/24 *[BGP/170] 12:41:49, localpref 100, from 150.1.1.3
172.30.19.0/24 *[BGP/170] 12:41:49, localpref 100, from 150.1.1.3
172.30.20.0/24 *[BGP/170] 12:41:43, localpref 100, from 150.1.1.3
172.30.21.0/24 *[BGP/170] 12:41:43, localpref 100, from 150.1.1.3
172.30.22.0/24 *[BGP/170] 12:41:43, localpref 100, from 150.1.1.3
172.30.23.0/24 *[BGP/170] 12:41:43, localpref 100, from 150.1.1.3
172.30.24.0/24 *[BGP/170] 12:41:43, localpref 100, from 150.1.1.3
172.30.25.0/24 *[BGP/170] 12:41:43, localpref 100, from 150.1.1.3
172.30.26.0/24 *[BGP/170] 12:41:43, localpref 100, from 150.1.1.3
172.30.27.0/24 *[BGP/170] 12:41:43, localpref 100, from 150.1.1.3
172.30.28.0/24 *[BGP/170] 12:41:43, localpref 100, from 150.1.1.3
172.30.29.0/24 *[BGP/170] 12:41:43, localpref 100, from 150.1.1.3
172.30.30.0/24 *[BGP/170] 12:41:40, localpref 100
172.30.31.0/24 *[BGP/170] 12:41:40, localpref 100
172.30.32.0/24 *[BGP/170] 12:41:40, localpref 100
172.30.33.0/24 *[BGP/170] 12:41:40, localpref 100
172.30.34.0/24 *[BGP/170] 12:41:40, localpref 100
172.30.35.0/24 *[BGP/170] 12:41:40, localpref 100
172.30.36.0/24 *[BGP/170] 12:41:40, localpref 100
172.30.37.0/24 *[BGP/170] 12:41:40, localpref 100
172.30.38.0/24 *[BGP/170] 12:41:40, localpref 100
172.30.39.0/24 *[BGP/170] 12:41:40, localpref 100
<snip routes from CE1-4 and CE1-5 if exist>

We can see that routing information is propagated properly within VPN1 sites such that all hub and
spoke sites have learnt prefixes of each other. Now let’s check routing advertisement between PE

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

routers that connect to the same hub/spoke site. As can be seen below, R1 and R3 don’t accept CE1-1
routes from each other to prevent loops, thanks to BGP SoO. Likewise, R4 and R6 don’t accept CE1-2
routes from each other.
lab@VMX-R1> show route receive-protocol bgp 150.1.1.3 table VPN1 active-path | match
172.30.1[0-9].0 | count
Count: 0 lines

lab@VMX-R3> show route receive-protocol bgp 150.1.1.1 table VPN1 active-path | match
172.30.1[0-9].0 | count
Count: 0 lines

lab@VMX-R4> show route receive-protocol bgp 150.1.1.6 table VPN1 active-path | match
172.30.2[0-9].0 | count
Count: 0 lines

lab@VMX-R6> show route receive-protocol bgp 150.1.1.4 table VPN1 active-path | match
172.30.2[0-9].0 | count
Count: 0 lines

Now let’s ensure that the forwarding path between CE1-2 (connecting to R4 and R6) and CE1-3
(connecting to R5) actually is across CE1-1 (connecting to R1 and R4). And also we should verify full
connectivity between the CE routers as well.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
215
216 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

lab@VMX-VR> traceroute routing-instance CE1-2 source 172.30.20.1 172.30.30.1

traceroute to 172.30.30.1 (172.30.30.1) from 172.30.20.1, 30 hops max, 40 byte packets
1 172.16.103.1 (172.16.103.1) 9.830 ms 11.995 ms 10.111 ms
2 150.1.34.3 (150.1.34.3) 24.842 ms 24.608 ms 20.017 ms
MPLS Label=299936 CoS=0 TTL=1 S=1
3 172.16.132.2 (172.16.132.2) 24.801 ms 24.404 ms 25.033 ms
4 172.16.133.1 (172.16.133.1) 24.895 ms 24.518 ms 24.911 ms
5 150.1.35.5 (150.1.35.5) 35.113 ms 34.352 ms 34.930 ms
MPLS Label=300176 CoS=0 TTL=1 S=1
6 172.30.30.1 (172.30.30.1) 39.968 ms 34.671 ms 39.787 ms

lab@VMX-VR> ping rapid routing-instance CE1-1 source 172.30.10.1 172.30.20.1

lab@VMX-VR> ping rapid routing-instance CE1-1 source 172.30.10.1 172.30.30.1

lab@VMX-VR> ping rapid routing-instance CE1-2 source 172.30.20.1 172.30.30.1

PING 172.30.30.1 (172.30.30.1): 56 data bytes
!!!!!
--- 172.30.10.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 14.743/18.913/20.189/2.091 ms

Task 2 is really about the implementation of OSPF Sham-Link feature for MPLS L3 VPN. Without this
feature, the MPLS L3 VPN services provided by R7 and R8 within Service Provider Network 2 will not be
always preferred. OSPF LSA Types 1 and 2 (if any) propagated across MPLS L3 VPN network will be
converted into LSA Type 3 while they will remain in original form when propagated across the backdoor
link. Thus, the backdoor link will be preferred for such LSA Types. For OSPF LSA Type 5 and/or 7, the
chosen link comes down to the cost comparison between MPLS L3 VPN virtual link and backdoor link. In
order to always make sure that the MPLS L3 VPN link is the preferred one for all LSA Types, OSPF Sham-
Link is employed by establishing OSPF neighbourship across MPLS L3 VPN network and ensure that this
‘sham’ link has got a lower cost compared with the backdoor link.
lab@VMX-R7> show ospf neighbor instance VPN1

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

Address Interface State ID Pri Dead
172.16.138.2 ge-0/0/4.138 Full 172.30.130.1 128 35
151.1.1.88 shamlink.0 Full 151.1.1.88 0 33

lab@VMX-R8> show ospf neighbor instance VPN1

Address Interface State ID Pri Dead
172.16.129.2 ge-0/0/4.129 Full 172.30.110.1 128 31
151.1.1.77 shamlink.0 Full 151.1.1.77 0 35

lab@VMX-R7> show route table VPN1.inet.0 active-path | match 172.30.11[0-9].0

172.30.110.0/24 *[BGP/170] 00:00:52, MED 0, localpref 100, from 151.1.1.8
172.30.111.0/24 *[BGP/170] 00:00:52, MED 0, localpref 100, from 151.1.1.8
172.30.112.0/24 *[BGP/170] 00:00:52, MED 0, localpref 100, from 151.1.1.8
172.30.113.0/24 *[BGP/170] 00:00:52, MED 0, localpref 100, from 151.1.1.8
172.30.114.0/24 *[BGP/170] 00:00:52, MED 0, localpref 100, from 151.1.1.8
172.30.115.0/24 *[BGP/170] 00:00:52, MED 0, localpref 100, from 151.1.1.8
172.30.116.0/24 *[BGP/170] 00:00:52, MED 0, localpref 100, from 151.1.1.8
172.16.117.0/24 *[BGP/170] 00:00:52, MED 0, localpref 100, from 151.1.1.8
172.16.118.0/24 *[BGP/170] 00:00:52, MED 0, localpref 100, from 151.1.1.8
172.30.119.0/24 *[BGP/170] 00:00:52, MED 0, localpref 100, from 151.1.1.8

lab@VMX-R8> show route table VPN1.inet.0 active-path | match 172.30.13[0-9].0

172.30.130.0/24 *[BGP/170] 00:00:58, MED 0, localpref 100, from 151.1.1.7
172.30.131.0/24 *[BGP/170] 00:00:58, MED 0, localpref 100, from 151.1.1.7
172.30.132.0/24 *[BGP/170] 00:00:58, MED 0, localpref 100, from 151.1.1.7
172.30.133.0/24 *[BGP/170] 00:00:58, MED 0, localpref 100, from 151.1.1.7
172.30.134.0/24 *[BGP/170] 00:00:58, MED 0, localpref 100, from 151.1.1.7

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
216
217 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

172.30.135.0/24 *[BGP/170] 00:00:58, MED 0, localpref 100, from 151.1.1.7

172.30.136.0/24 *[BGP/170] 00:00:58, MED 0, localpref 100, from 151.1.1.7
172.30.137.0/24 *[BGP/170] 00:00:58, MED 0, localpref 100, from 151.1.1.7
172.30.138.0/24 *[BGP/170] 00:00:58, MED 0, localpref 100, from 151.1.1.7
172.30.139.0/24 *[BGP/170] 00:00:58, MED 0, localpref 100, from 151.1.1.7

lab@VMX-VR> traceroute routing-instance CE1-4 source 172.30.130.1 172.30.110.1

traceroute to 172.30.110.1 (172.30.110.1) from 172.30.130.1, 30 hops max, 40 byte packets
1 172.16.138.1 (172.16.138.1) 14.899 ms 14.709 ms 14.968 ms
2 151.1.78.8 (151.1.78.8) 19.961 ms 19.572 ms 20.032 ms
MPLS Label=300016 CoS=0 TTL=1 S=1
3 172.30.110.1 (172.30.110.1) 29.836 ms 24.529 ms 26.430 ms

Task 3 requires Inter-AS MPLS L3 VPN Option C to be implemented between Service Provider Networks
1 and 2. In summary, option C relies on the following components:

• ASBR routers to form regular eBGP session to exchange IP NLRI within inet.0 table (family inet
unicast) to allow for the establishment of multi-hop MP-eBGP session between PE routers
across AS boundary (or between Route Reflectors) as by default control-plane traffic generated
by routers is sent in form of pure IP packets.
• ASBR routers to form LU-eBGP session within inet.3 table (family inet labeled-unicast rib
inet.3) to exchange IP NLRI with label binding. This will help PE routers to build direct end-to-
end LSP towards PE routers of external AS using LU-eBGP as the signalling protocol, and also
resolve the transport route for VPN NLRI exchanged by the MP-eBGP session. Certainly, MPLS
functionality must be enabled across the ASBR-ASBR link such that it can accept labeled packets.
• PE routers to form LU-iBGP sessions within inet.3 table (family inet labeled-unicast rib
inet.3) with intra AS ASBR routers to exchange IP NLRI with label binding. This will help PE
routers to build direct end-to-end LSP towards PE routers of external AS using LU-iBGP as the
signalling protocol, and also resolve the transport route for VPN NLRI exchanged by the MP-
eBGP session.
• PE routers to form multi-hop MP-eBGP session to exchange VPN NLRI with label binding. This
will help PE routers to signal the labels they allocated for their local VRFs. If route reflectors are
in place, the multi-hop MP-eBGP session should be formed between route reflectors of the
ASNs with a notion of statement no-nexthop-change which ensures that the route reflectors do

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

not become the central forwarding points between the ASNs, instead it allows PE routers to
forward traffic on direct end-to-end LSP between each other.

As can be seen below, ASBR routers R5 and R6 advertise PE routers’ loopback0 addresses across both
tables inet.0 and inet.3. Strictly speaking, we will just need loopback0 addresses of Route Reflectors (R3
and R4) to be advertised via table inet.0 so that they can form multihop MP-eBGP with the
corresponding Route Reflector (R8) in Service Provider Network 2. However we should maintain a
consistent routing advertisement across the tables.
lab@VMX-R5> show route advertising-protocol bgp 150.1.57.7 | match "inet|150.1.1."

inet.0: 30 destinations, 33 routes (26 active, 0 holddown, 4 hidden)

* 150.1.1.1/32 Self 200 I
* 150.1.1.2/32 Self 200 I
* 150.1.1.3/32 Self 100 I
* 150.1.1.4/32 Self 100 I
* 150.1.1.5/32 Self I
* 150.1.1.6/32 Self 50 I

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

* 150.1.1.1/32 Self 200 I
* 150.1.1.2/32 Self 200 I

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
217
218 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

* 150.1.1.3/32 Self 100 I

* 150.1.1.4/32 Self 100 I
* 150.1.1.5/32 Self I
* 150.1.1.6/32 Self 50 I

lab@VMX-R6> show route advertising-protocol bgp 150.1.68.8 | match "inet|150.1.1."

inet.0: 74 destinations, 169 routes (70 active, 0 holddown, 4 hidden)

* 150.1.1.1/32 Self 250 I
* 150.1.1.2/32 Self 200 I
* 150.1.1.3/32 Self 150 I
* 150.1.1.4/32 Self 100 I
* 150.1.1.5/32 Self 50 I
* 150.1.1.6/32 Self I

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

* 150.1.1.1/32 Self 250 I
* 150.1.1.2/32 Self 200 I
* 150.1.1.3/32 Self 150 I
* 150.1.1.4/32 Self 100 I
* 150.1.1.5/32 Self 50 I
* 150.1.1.6/32 Self I

You may notice that each ASBR in this lab is actually a PE router as well, meaning that it has got local
VRF belonging to the Inter-AS MPLS L3 VPN. Because of this, each ASBR must advertise its own
loopback0 in the LU-eBGP sessions as there is a need for establishing end-to-end LSP with other PE
routers. In other words, ASBR’s loopback0 must be advertised via table inet.3. However JUNOS
architecture by default builds table inet.3 by RSVP or LDP. Therefore we have to import the loopback0
from table inet.0 into table inet.3 by rib-groups feature. You can see that in we used policy INET0-TO-
INET3 to limit just only the loopback address to be imported and this is the actual reason why 150.1.1.5
and 150.1.1.6 appear in table inet.3 and exchange via LU-eBGP sessions above.

The MP-eBGP sessions between R8 and R3,R4 should come up and exchange VPN NLRI. Meanwhile, the
LU-eBGP session between R8 and R6 should exchange NLRI via both tables inet.0 and inet.3.
lab@VMX-R8> show bgp summary
<snip>
150.1.1.3 123456 51 31 0 0 8:39 Establ
bgp.l3vpn.0: 68/101/101/0
VPN1.inet.0: 12/34/34/0
150.1.1.4 123456 50 29 0 0 8:35 Establ
bgp.l3vpn.0: 33/101/101/0

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

VPN1.inet.0: 23/68/68/0
150.1.68.6 123456 67 26 0 0 8:43 Establ
inet.0: 46/49/49/0
inet.3: 3/6/6/0
151.1.1.7 78 70 90 0 0 8:18 Establ
inet.0: 3/48/48/0
inet.3: 3/5/5/0
bgp.l3vpn.0: 13/13/13/0
VPN1.inet.0: 12/13/13/0

In the table inet.3 of R7 and R8, there should be transport IP NLRI (with label) for them to form end-to-
end LSPs with remote PE routers being R1, R3, R4 and R6. R7 should not need to traverse R8 to reach
the remote PE routers in Service Provider Network 1 unless its link with R5 fails.
lab@VMX-R7> show route table inet.3 active-path | match BGP
150.1.1.1/32 *[BGP/170] 00:07:35, MED 200, localpref 100
150.1.1.2/32 *[BGP/170] 00:07:07, MED 200, localpref 100
150.1.1.3/32 *[BGP/170] 00:07:04, MED 100, localpref 100
150.1.1.4/32 *[BGP/170] 00:07:02, MED 100, localpref 100
150.1.1.5/32 *[BGP/170] 00:08:17, localpref 100
150.1.1.6/32 *[BGP/170] 00:07:49, localpref 100, from 151.1.1.8

lab@VMX-R8> show route table inet.3 active-path | match BGP

150.1.1.1/32 *[BGP/170] 00:07:34, MED 200, localpref 100, from 151.1.1.7
150.1.1.2/32 *[BGP/170] 00:08:13, MED 200, localpref 100

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
218
219 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

150.1.1.3/32 *[BGP/170] 00:07:04, MED 100, localpref 100, from 151.1.1.7

150.1.1.4/32 *[BGP/170] 00:08:13, MED 100, localpref 100
150.1.1.5/32 *[BGP/170] 00:07:48, localpref 100, from 151.1.1.7
150.1.1.6/32 *[BGP/170] 00:08:13, localpref 100

Now let’s generate some ping/traceroute test traffic for Inter-AS MPLS L3 VPN Option C and observe the
forwarding path, particularly between CE1-[45] and spoke CE1-[23] which should be across hub CE1-1.
lab@VMX-VR> ping rapid routing-instance CE1-4 source 172.30.130.1 172.30.10.1
PING 172.30.10.1 (172.30.10.1): 56 data bytes
!!!!!
--- 172.30.10.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 29.780/29.971/30.154/0.163 ms

lab@VMX-VR> ping rapid routing-instance CE1-4 source 172.30.130.1 172.30.20.1

lab@VMX-VR> ping rapid routing-instance CE1-4 source 172.30.130.1 172.30.30.1

lab@VMX-VR> ping rapid routing-instance CE1-5 source 172.30.110.1 172.30.10.1

lab@VMX-VR> ping rapid routing-instance CE1-5 source 172.30.110.1 172.30.20.1

lab@VMX-VR> ping rapid routing-instance CE1-5 source 172.30.110.1 172.30.30.1

PING 172.30.30.1 (172.30.30.1): 56 data bytes
!!!!!
--- 172.30.30.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

round-trip min/avg/max/stddev = 54.958/57.981/60.025/2.408 ms

lab@VMX-VR> traceroute routing-instance CE1-4 source 172.30.130.1 172.30.10.1

traceroute to 172.30.10.1 (172.30.10.1) from 172.30.130.1, 30 hops max, 40 byte packets
1 172.16.138.1 (172.16.138.1) 14.532 ms 14.401 ms 14.919 ms
2 150.1.57.5 (150.1.57.5) 34.929 ms 34.194 ms 34.988 ms
MPLS Label=300288 CoS=0 TTL=1 S=0
MPLS Label=299776 CoS=0 TTL=1 S=1
3 150.1.35.3 (150.1.35.3) 35.221 ms 40.642 ms 33.194 ms
MPLS Label=299984 CoS=0 TTL=1 S=0
MPLS Label=299776 CoS=0 TTL=2 S=1
4 150.1.13.1 (150.1.13.1) 34.699 ms 34.043 ms 34.912 ms
MPLS Label=299776 CoS=0 TTL=1 S=1
5 172.30.10.1 (172.30.10.1) 35.180 ms 34.099 ms 34.859 ms

lab@VMX-VR> traceroute routing-instance CE1-4 source 172.30.130.1 172.30.20.1

traceroute to 172.30.20.1 (172.30.20.1) from 172.30.130.1, 30 hops max, 40 byte packets
1 172.16.138.1 (172.16.138.1) 9.701 ms 14.702 ms 14.952 ms
2 150.1.57.5 (150.1.57.5) 35.013 ms 34.341 ms 35.096 ms
MPLS Label=300288 CoS=0 TTL=1 S=0
MPLS Label=299776 CoS=0 TTL=1 S=1
3 150.1.35.3 (150.1.35.3) 35.146 ms 34.244 ms 34.974 ms
MPLS Label=299984 CoS=0 TTL=1 S=0
MPLS Label=299776 CoS=0 TTL=2 S=1
4 150.1.13.1 (150.1.13.1) 34.996 ms 34.563 ms 34.986 ms
MPLS Label=299776 CoS=0 TTL=1 S=1
5 172.16.117.2 (172.16.117.2) 34.882 ms 34.806 ms 34.670 ms

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
219
220 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

6 172.16.118.1 (172.16.118.1) 39.854 ms 39.510 ms 35.028 ms

7 150.1.12.2 (150.1.12.2) 50.000 ms 44.690 ms 54.705 ms
MPLS Label=299792 CoS=0 TTL=1 S=0
MPLS Label=300144 CoS=0 TTL=1 S=1
8 150.1.24.4 (150.1.24.4) 44.947 ms 49.425 ms 50.129 ms
MPLS Label=300144 CoS=0 TTL=1 S=1
9 172.30.20.1 (172.30.20.1) 44.940 ms 54.381 ms 50.077 ms

lab@VMX-VR> traceroute routing-instance CE1-4 source 172.30.130.1 172.30.30.1

traceroute to 172.30.30.1 (172.30.30.1) from 172.30.130.1, 30 hops max, 40 byte packets
1 172.16.138.1 (172.16.138.1) 14.946 ms 14.711 ms 15.151 ms
2 150.1.57.5 (150.1.57.5) 34.751 ms 34.209 ms 35.215 ms
MPLS Label=300288 CoS=0 TTL=1 S=0
MPLS Label=299776 CoS=0 TTL=1 S=1
3 150.1.35.3 (150.1.35.3) 34.658 ms 29.177 ms 35.242 ms
MPLS Label=299984 CoS=0 TTL=1 S=0
MPLS Label=299776 CoS=0 TTL=2 S=1
4 150.1.13.1 (150.1.13.1) 34.673 ms 34.140 ms 35.463 ms
MPLS Label=299776 CoS=0 TTL=1 S=1
5 172.16.117.2 (172.16.117.2) 34.370 ms 34.604 ms 34.546 ms
6 172.16.118.1 (172.16.118.1) 35.056 ms 34.137 ms 30.197 ms
7 150.1.13.3 (150.1.13.3) 44.979 ms 54.120 ms 45.007 ms
MPLS Label=299792 CoS=0 TTL=1 S=0
MPLS Label=300256 CoS=0 TTL=1 S=1
8 150.1.35.5 (150.1.35.5) 34.724 ms 49.222 ms 44.850 ms
MPLS Label=300256 CoS=0 TTL=1 S=1
9 172.30.30.1 (172.30.30.1) 55.030 ms 48.947 ms 44.921 ms

Topic 6: CoS
Total Points: 6

Task 1 (6 points). Configure 1-rate 2-colour policing filters to rate-limit customers in accordance with
policies below. Please note that for each customer, the policing policy should apply to both IPv4 and
IPv6 protocol families as the whole.

Customer Bandwidth Limit Burst Allowance Violation Policy

C1 100Mbps 5msec Medium-High Loss
Priority
C2 200Mbps 10msec High Loss Priority
C4 500Mbps 20msec Drop
R1
!

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

edit firewall policer 100M-5MSEC-MEDIUM-HIGH
set logical-interface-policer
set if-exceeding bandwidth-limit 100m burst 62500
set then loss-priority medium-high
exit
set interface ge-0/0/4.119 family inet policer input 100M-5MSEC-MEDIUM-HIGH
set interface ge-0/0/4.119 family inet6 policer input 100M-5MSEC-MEDIUM-HIGH

R2
!
edit firewall policer 200M-10MSEC-HIGH
set logical-interface-policer
set if-exceeding bandwidth-limit 200m burst 250k
set then loss-priority high
exit
set interface ge-0/0/4.102 family inet policer input 200M-10MSEC-HIGH
set interface ge-0/0/4.102 family inet6 policer input 200M-10MSEC-HIGH

R6
!
edit firewall policer 500M-20MSEC-DROP
set logical-interface-policer
set if-exceeding bandwidth-limit 500m burst 1250k
set then discard
exit
set interface ge-0/0/4.131 family inet policer input 500M-20MSEC-DROP
set interface ge-0/0/4.131 family inet6 policer input 500M-20MSEC-DROP

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
220
221 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Verification
Task 1. This task introduces single-rate two-colour policing in either hard or soft manner. This feature is
quite standard to most of Service Provider Networks where information rate is limited to certain speed
in accordance with contracts. Also to some extent, the Service Provider Networks need to protect their
medium against aggressive traffic and introduce sort of capacity control to avoid congestion. This task
applies firewall policers in the inbound direction of PE-C link. The policers define rates in unit megabit
per second with burst value calculated by multiplying the rates with the burst allowance times
respectively. Soft or Hard policing depends on the action of the policer upon violation. Hard policing
simply drops any exceeding packets while Soft policing marks down the loss priority. When congestion
happens, packets marked with higher loss priority will be discarded first before the ones with lower loss
priority. An interesting statement is logical-interface-policer which forms a logical policing policy for
all address families of the interface. Without this statement, each family is policed individually, e.g. on
R1’s interface ge-0/0/4.119, IPv4 and IPv6 will have limit-rate of 100Mbps individually, hence the total
rate is 200Mbps (but IPv4 or IPv6 traffic each cannot get over 100Mbps).
lab@VMX-R1> show interfaces policers ge-0/0/4.119
Interface Admin Link Proto Input Policer Output Policer
ge-0/0/4.119 up up
inet 100M-5MSEC-MEDIUM-HIGH-ge-0/0/4.119-log_int-i
inet6 100M-5MSEC-MEDIUM-HIGH-ge-0/0/4.119-log_int-i
multiservice __default_arp_policer__

lab@VMX-R1> show policer 100M-5MSEC-MEDIUM-HIGH-ge-0/0/4.119-log_int-i

Policers:
Name Bytes Packets
100M-5MSEC-MEDIUM-HIGH-ge-0/0/4.119-log_int-i 0 0

End of Practice Lab 3 Solutions!

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 3 Solutions

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
221
222 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Practice Lab 4 Solutions

Topic 1: Device Infrastructure

Total Points: 12

Task 2 (3 points). Configure all routers in Service Provider Network 1 such that for any locally-originated
traffic, they source from the primary address of interface loopback0. Deny SSH access with username
root, also limit the total of SSH/NETCONF sessions up to 10 at a given time and up to 5 per minute,
accept only SSHv2 sessions. Configure a timeout interval after which if no data is received from the
client, sshd will send a message through the encrypted channel to request a response from the client;
after 3 such messages and still no data is received from the client, sshd will terminate the session.
R1,R2,R3,R4,R5,R6,R7,R8
!
set system default-address-selection
edit system services
set ssh root-login deny
set ssh protocol-version v2
set ssh connection-limit 5
set ssh rate-limit 3
set ssh client-alive-interval 30
set ssh client-alive-count 3
set netconf ssh connection-limit 5
set netconf ssh rate-limit 3
exit

Task 3 (3 points). Configure the following RADIUS, NTP and SNMPv3 configurations:

• Use NTP server at address 172.16.1.77, password: juniper77.

• Use RADIUS server at address 172.16.1.66, password: juniper66.
• Use SNMPv3 security model USM with view parameters below:

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

o Username: juniper
o Authentication method: MD5
o Authentication password: juniper55
o Encryption method: 3DES
o Encryption password: juniper55@
o Security level: privacy
o Root OID: .1.3.6.1.4.1.2636
• Use SNMPv3 notification parameters below:
o Server at address 172.16.1.55
o Security model: USM
o Security level: privacy
o Notification Type: Trap
o Notification OIDs: snmpTraps, jnxTraps
R1,R2,R3,R4,R5,R6,R7,R8
!
set system ntp server 172.16.1.77 key 1

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
222
223 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set system ntp authentication-key 1 type md5 value juniper77

set system ntp trusted-key 1
set system radius-server 172.16.1.66 secret juniper66
set snmp view VIEW-RO oid .1.3.6.1.4.1.2636 include
edit snmp v3 usm local-engine user juniper
set authentication-md5 authentication-key juniper55
set privacy-3des privacy-key juniper55@
exit
edit snmp v3 vacm
set security security usm security juniper group SNMPV3-RO
set access group SNMPV3-RO default security usm security privacy read-view VIEW-RO
exit
edit snmp v3 target-address SNMPV3-SRV
set address 172.16.1.55
set target-para SNMPV3-SRV-PARA
set tag SNMPV3-SRV-TRAP
exit
edit snmp v3 target-para SNMPV3-SRV-PARA
set para message-processing-model v3
set para security-model usm
set para security-level privacy
set para security-name juniper
set notify-filter SNMPV3-SRV-TRAP-FILTER
exit
edit snmp v3 notify-filter SNMPV3-SRV-TRAP-FILTER
set oid snmpTraps include
set oid jnxTraps include
exit
set snmp v3 notify traps tag SNMPV3-SRV-TRAP type trap

Task 4 (3 points). Configure the following combinations of user and permission. The authentication
priority should be via RADIUS first and then local password database.

User Password Class Permissions

eng Eng123 super-user all
ops Ops123 operator clear, network, reset, trace, view
tac TAC123 TAC all except: clear, configure, edit, commit, start shell
R1,R2,R3,R4,R5,R6,R7,R8
!
set system authentication-order [ radius password ]
edit system login user eng
set class super-user
set authentication encrypted-password "$1$QWZ.mkxN$9/ezCxMT2EHfJWAaJeB8a1"
exit
edit system login user ops

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

set class operator
set authentication encrypted-password "$1$gEf0PU0S$rtSHWFf4KR/abf3kFlNs7."
exit
edit system login user tac
set class TAC
set authentication encrypted-password "$1$PrC2FJkm$x4Vhq7NtNfts0Rt6RVXmD1"
exit
edit system login class TAC
set permissions all
set deny-commands "(clear)|(configure)|(edit)|(commit)|(start shell)"
exit

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
223
224 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

R6
!
edit services rpm probe VIA-T1-R1 test ICMP
set target address 123.0.1.1
set probe-type icmp-ping
set probe-interval 10
set probe-count 10
set data-size 1400
set traps test-failure
set test-interval 5
exit
edit services rpm probe VIA-T1-R7 test ICMP
set target address 123.0.2.1
set probe-type icmp-ping
set probe-interval 10
set probe-count 10
set data-size 1400
set traps test-failure
set test-interval 5
exit
edit services rpm probe VIA-T2-R1 test ICMP
set target address 123.0.3.1
set probe-type icmp-ping
set probe-interval 10
set probe-count 10
set data-size 1400
set traps test-failure
set test-interval 5
exit
edit services rpm probe VIA-T2-R2 test ICMP
set target address 123.0.4.1
set probe-type icmp-ping
set probe-interval 10
set probe-count 10
set data-size 1400
set traps test-failure
set test-interval 5
exit

Verification
Task 1. System configuration should be annotated as below. Perform the same command on all routers
R1->R8 to ensure annotation is put in all routers’ configuration.
lab@VMX-R3> show configuration | find "Config made"
/* Config made by Tony Tuan Nguyen, 2017-01-16 */
system {
<snip-for-brevity>

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

}

Task 2. The default address that JUNOS uses as the source for all locally generated IP packets are the
primary address of outgoing interfaces. However we can generalise it to be loopback0 address with
statement default-address-selection. As can be seen from the SSH below from R2 to R1, the source
that R2 uses is its lo0.
lab@VMX-R2> ssh [email protected]
Password:
--- JUNOS 12.1X47-D20.7 built 2015-03-03 21:53:50 UTC
lab@VMX-R1> show system users
12:35AM up 3 days, 6:02, 1 user, load averages: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE WHAT
lab pts/0 10.10.1.254 12:30AM 1 -cli (cli)
lab p0 150.1.1.2 12:35AM - -cli (cli)

As a security best practice, we should not allow root access anywhere apart from the console. We can
test this out by using username root, the system should reject any non-console access using such
username.
lab@VMX-R2> ssh [email protected]
Password:

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
224
225 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Password:
Password:
Received disconnect from 150.1.12.1: 2: Too many password failures for root

By default, JUNOS routers do not actively verify the liveness of the SSH sessions which sometimes may
result in stale sessions including the ones in configuration mode. In order to increase security and
reduce the risk of configuration being modified incompletely, we can tune JUNOS routers to actively
probe the sources of the idle SSH clients such that after a configurable amount of probes, idle SSH
sessions will be terminated if no data is received.

Task 3. SNMPv3 configuration on JUNOS may look complex at first sight but it would be simple to
memorise the connection between the knobs. In this task there are two configuration portions: SNMPv3
query and SNMPv3 trap.

• The query portion is for any NMS to perform activities such as snmpwalk against the device
using a username/password (different from SNMPv2 which uses only community-string
password). Firstly we specify a username along with its parameters in the user-based security
model (USM) with statement snmp v3 usm local-engine user and then we assign it to a view-
based access control group (VACM) with statement snmp v3 vacm, from which we can specify the
read/write level.
• The trap portion is for devices to automatically send SNMPv3 trap messages based on
configurable conditions upon these are met or hit.

In order to view SNMPv3 settings we can use any extension of the command show snmp v3.

lab@VMX-R1> show snmp v3

Local engine ID: 80 00 0a 4c 01 96 01 01 01

Engine boots: 3
Engine time: 69475 seconds
Max msg size: 65507 bytes
<snip>

lab@VMX-R1> show snmp v3 users

Engine ID: local

User Auth/Priv Storage Status

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

juniper md5/3des nonvolatile active

lab@VMX-R1> show snmp v3 groups

Group name Security Security Storage Status

model name type
SNMPV3-RO usm juniper nonvolatile active

Task 4. In JUNOS, you can classify users into groups with different levels of authorisation with regard to
command executions. By default there are four preconfigured classes named operator, read-only, super-
user and unauthorised that you can easily find out their permission levels. However you also can specify
a named custom class with a variety of configurable permissions, then you can assign user to the class.
lab@VMX-R1# set system login user TEST class ?
Possible completions:
<class> Login class
TAC
operator permissions [ clear network reset trace view ]
read-only permissions [ view ]
super-user permissions [ all ]
unauthorized permissions [ none ]

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
225
226 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

By default JUNOS routers would match username/password and its privileges against local database on
the routers, however we can specify the use of RADIUS/TACACS servers. It is recommended to use a
fallback option of local database in case the servers are offline so that users can still gain access during
such circumstances.

Task 5. This task is quite interesting that: 1) It brings up an interesting feature of JUNOS called RPM
(Real-time Probe Monitoring) that is used for active monitoring of network health. It is quite similar to
IPSLA feature on Cisco IOS. We can use RPM feature to generate various synthetic traffic streams (TCP,
UDP, ICMP, etc) towards configurable destinations in order to simulate customer traffic and promptly
detect failures. And 2) the task requires a way of tracking health of different transit links separately,
which in turns requires a way to pin-point each synthetic probe to a specific path all the time regardless
of the change of regular routing calculation. For example, if a probe on R6 destined to 123.0.1.1 is used
for testing transit link via provider T1 out of R1, packets destined to 123.0.0.1 should always use that
transit link even if it is not the best path from R6’s perspectives.

Within the first topic, we would address point 1 (RPM) for now and we will come back to point 2 upon
the completion of topic BGP. RPM feature allows for configuring multiple probes independently under
services rpm probe stanza. There are a lot of configuration knobs that you may find, but for simplicity,
this task only uses ICMP ping probes (owners), each probe (owner) is associated with a group of tests
with the following settings:

• ICMP: the name of the test.

• test-interval 5: perform multiple tests, one test every 5 seconds.
• probe-type icmp-ping: perform ping.

• probe-count 10: perform 10 pings during one test period.

• probe-interval 10: perform one ping every 10 seconds.

• data-size 1400: payload is padded with 1400 bytes

• traps test-failure: send SNMP trap if test fails.

We have in total 4 probes (or 4 owners) and each of them is associated with a particular destination.
Later on in topic BGP, task 5, we would harden each probe (owner) to a particular transit link. Below is

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

the result of the RPM for one probe (owner) if basic BGP routing is ready:
lab@VMX-R6> show services rpm probe-results owner VIA-T1-R1 test ICMP
Owner: VIA-T1-R1, Test: ICMP
Target address: 123.0.1.1, Probe type: icmp-ping, Test size: 10 probes
Probe results:
Response received, Fri Dec 30 02:50:45 2016, No hardware timestamps
Rtt: 25496 usec
Results over current test:
Probes sent: 3, Probes received: 3, Loss percentage: 0
Measurement: Round trip time
Samples: 3, Minimum: 25128 usec, Maximum: 25496 usec, Average: 25293 usec, Peak
to peak: 368 usec,
Stddev: 153 usec, Sum: 75880 usec
Results over last test:
Probes sent: 10, Probes received: 10, Loss percentage: 0
Test completed on Fri Dec 30 02:50:20 2016
Measurement: Round trip time
Samples: 10, Minimum: 24790 usec, Maximum: 25292 usec, Average: 25140 usec, Peak
to peak: 502 usec,
Stddev: 138 usec, Sum: 251397 usec
Results over all tests:
Probes sent: 103, Probes received: 103, Loss percentage: 0
Measurement: Round trip time

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
226
227 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Samples: 103, Minimum: 15121 usec, Maximum: 25504 usec, Average: 21528 usec, Peak
to peak: 10383 usec,
Stddev: 2291 usec, Sum: 2217382 usec

Topic 2: IGP
Total Points: 14

• Area 0.0.0.0 is between R2, R3, R4, R5, R6 and R7.

• Area 0.0.0.1 is between R1 and R2, R1 and R3.
• Area 0.0.0.8 is between R8 and R6, R8 and R7.

/* Task 1’s answer includes Task 2’s */

R1,R2,R3,R4,R5,R6,R7,R8
!
edit security ipsec security-association SA-OSPF
set mode transport
set manual direction bidirectional
set manual direction bidirectional protocol ah
set manual direction bidirectional spi 256
set manual direction bidirectional authentication algorithm hmac-md5-96 key ascii-text
123456789012ospf
exit
edit groups CORE-INTERFACES
set protocols ospf area <*> interface <*> point-to-point
set protocols ospf area <*> interface <*> bfd minimum-interval 250 multiplier 4
set protocols ospf area <*> interface <*> ipsec-sa SA-OSPF
set protocols ospf3 area <*> interface <*> point-to-point
set protocols ospf3 area <*> interface <*> bfd minimum-interval 250 multiplier 4
set protocols ospf3 area <*> interface <*> ipsec-sa SA-OSPF
exit
set apply-groups CORE-INTERFACES
set policy-options policy-statement ECMP term ECMP then load-balance per-packet
set routing-options forwarding-table export ECMP

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

!
edit protocols ospf
set reference-bandwidth 100g
set area 0.0.0.1 nssa
set area 0.0.0.1 interface ge-0/0/2.0
set area 0.0.0.1 interface ge-0/0/6.0
set area 0.0.0.1 interface lo0.0 passive
exit
edit protocols ospf3
set reference-bandwidth 100g
set area 0.0.0.1 nssa
set area 0.0.0.1 interface ge-0/0/2.0
set area 0.0.0.1 interface ge-0/0/6.0
set area 0.0.0.1 interface lo0.0 passive
exit

R2
!
edit protocols ospf
set reference-bandwidth 100g
set area 0.0.0.1 nssa
set area 0.0.0.1 interface ge-0/0/2.0
set area 0.0.0.0 interface ge-0/0/6.0
set area 0.0.0.0 interface ge-0/0/8.0
set area 0.0.0.0 interface lo0.0 passive
exit
edit protocols ospf3

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
227
228 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set reference-bandwidth 100g

set area 0.0.0.1 nssa
set area 0.0.0.1 interface ge-0/0/2.0
set area 0.0.0.0 interface ge-0/0/6.0
set area 0.0.0.0 interface ge-0/0/8.0
set area 0.0.0.0 interface lo0.0 passive
exit

R3
!
edit protocols ospf
set reference-bandwidth 100g
set area 0.0.0.1 nssa
set area 0.0.0.1 interface ge-0/0/6.0
set area 0.0.0.0 interface ge-0/0/7.0
set area 0.0.0.0 interface ge-0/0/8.0
set area 0.0.0.0 interface lo0.0 passive
exit
edit protocols ospf3
set reference-bandwidth 100g
set area 0.0.0.1 nssa
set area 0.0.0.1 interface ge-0/0/6.0
set area 0.0.0.0 interface ge-0/0/7.0
set area 0.0.0.0 interface ge-0/0/8.0
set area 0.0.0.0 interface lo0.0 passive
exit

R4,R5
!
edit protocols ospf
set reference-bandwidth 100g
set area 0.0.0.0 interface ge-0/0/6.0
set area 0.0.0.0 interface ge-0/0/7.0
set area 0.0.0.0 interface ge-0/0/8.0
set area 0.0.0.0 interface lo0.0 passive
exit
edit protocols ospf3
set reference-bandwidth 100g
set area 0.0.0.0 interface ge-0/0/6.0
set area 0.0.0.0 interface ge-0/0/7.0
set area 0.0.0.0 interface ge-0/0/8.0
set area 0.0.0.0 interface lo0.0 passive
exit

R6
!
edit protocols ospf
set reference-bandwidth 100g
set area 0.0.0.8 interface ge-0/0/6.0
set area 0.0.0.0 interface ge-0/0/7.0

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

set area 0.0.0.0 interface ge-0/0/8.0
set area 0.0.0.0 interface lo0.0 passive
exit
edit protocols ospf3
set reference-bandwidth 100g
set area 0.0.0.8 interface ge-0/0/6.0
set area 0.0.0.0 interface ge-0/0/7.0
set area 0.0.0.0 interface ge-0/0/8.0
set area 0.0.0.0 interface lo0.0 passive
exit

R7
!
edit protocols ospf
set reference-bandwidth 100g
set area 0.0.0.8 interface ge-0/0/2.0
set area 0.0.0.0 interface ge-0/0/6.0
set area 0.0.0.0 interface ge-0/0/8.0
set area 0.0.0.0 interface lo0.0 passive
exit
edit protocols ospf3
set reference-bandwidth 100g
set area 0.0.0.8 interface ge-0/0/2.0
set area 0.0.0.0 interface ge-0/0/6.0
set area 0.0.0.0 interface ge-0/0/8.0
set area 0.0.0.0 interface lo0.0 passive
exit

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
228
229 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

R8
!
edit protocols ospf
set reference-bandwidth 100g
set area 0.0.0.8 interface ge-0/0/2.0
set area 0.0.0.8 interface ge-0/0/6.0
set area 0.0.0.8 interface lo0.0 passive
exit
edit protocols ospf3
set reference-bandwidth 100g
set area 0.0.0.8 interface ge-0/0/2.0
set area 0.0.0.8 interface ge-0/0/6.0
set area 0.0.0.8 interface lo0.0 passive
exit

At the end of this topic, all routers should have full IPv4 reachability with each other within their
respective Service Provider Networks.
R1
!
set routing-options rib-groups DC1INET0-TO-INET0 import-rib [DC1.inet.0 inet.0]
set routing-options rib-groups DC1INET60-TO-INET60 import-rib [DC1.inet6.0 inet6.0]
set routing-options rib-groups INET60-TO-DC1INET60 import-rib [inet6.0 DC1.inet6.0]
set routing-options interface-routes rib-group inet6 INET60-TO-DC1INET60
set routing-options route-distinguisher-id 150.1.1.1

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

edit routing-instance DC1
set instance-type vrf
set vrf-target target:18:13
set interface ge-0/0/4.116
set protocols ospf3 area 0.0.0.0 interface ge-0/0/4.116
set protocols ospf3 export FROM-CORE-TO-DC1
set protocols ospf3 import OSPF3-FILTER
set protocols ospf3 rib-group DC1INET60-TO-INET60
set routing-options interface-routes rib-group inet6 DC1INET60-TO-INET60
set protocols ospf3 realm ipv4-unicast area 0.0.0.0 interface ge-0/0/4.116
set protocols ospf3 realm ipv4-unicast export FROM-CORE-TO-DC1
set protocols ospf3 realm ipv4-unicast import OSPF3-FILTER
set protocols ospf3 realm ipv4-unicast rib-group DC1INET0-TO-INET0
set routing-options static route 150.1.0.0/16 next-table inet.0
exit
edit protocols ospf3
set rib-group INET60-TO-DC1INET60
set export FROM-DC1-TO-CORE
set import OSPF3-FILTER
exit
edit protocols ospf
set export FROM-DC1-TO-CORE
set import OSPF3-FILTER
exit
edit policy-options policy-statement OSPF2-FILTER
set term 1 from protocol ospf2
set term 1 from tag 13

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
229
230 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set term 1 then reject

exit
edit policy-options policy-statement OSPF3-FILTER
set term 1 from protocol ospf3
set term 1 from tag 13
set term 1 then reject
exit
edit policy-options policy-statement FROM-DC1-TO-CORE
set term 1 from protocol ospf3
set term 1 then tag 13
set term 1 then metric 10
set term 1 then accept
exit
edit policy-options policy-statement FROM-CORE-TO-DC1
set term 4 from family inet
set term 4 from protocol static
set term 4 from route-filter 150.1.0.0/16 exact
set term 4 then tag 13
set term 4 then metric 10
set term 4 then accept
set term 6-OSPF3 from family inet6
set term 6-OSPF3 from protocol ospf3
set term 6-OSPF3 then tag 13
set term 6-OSPF3 then metric 100
set term 6-OSPF3 then accept
set term 6-DIRECT from family inet6
set term 6-DIRECT from protocol direct
set term 6-DIRECT from route-filter 2016:150:1::1/128 exact
set term 6-DIRECT from route-filter 2016:150:1:12::/64 exact
set term 6-DIRECT from route-filter 2016:150:1:13::/64 exact
set term 6-DIRECT then tag 13
set term 6-DIRECT then metric 100
set term 6-DIRECT then accept
exit

R3
!
set routing-options rib-groups DC1INET0-TO-INET0 import-rib [DC1.inet.0 inet.0]
set routing-options rib-groups DC1INET60-TO-INET60 import-rib [DC1.inet6.0 inet6.0]
set routing-options rib-groups INET60-TO-DC1INET60 import-rib [inet6.0 DC1.inet6.0]
set routing-options interface-routes rib-group inet6 INET60-TO-DC1INET60
set routing-options route-distinguisher-id 150.1.1.3
edit routing-instance DC1
set instance-type vrf
set vrf-target target:18:13
set interface ge-0/0/4.115
set protocols ospf3 area 0.0.0.0 interface ge-0/0/4.115
set protocols ospf3 export FROM-CORE-TO-DC1
set protocols ospf3 import OSPF3-FILTER
set protocols ospf3 rib-group DC1INET60-TO-INET60

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

set routing-options interface-routes rib-group inet6 DC1INET60-TO-INET60
set protocols ospf3 realm ipv4-unicast area 0.0.0.0 interface ge-0/0/4.115
set protocols ospf3 realm ipv4-unicast export FROM-CORE-TO-DC1
set protocols ospf3 realm ipv4-unicast import OSPF3-FILTER
set protocols ospf3 realm ipv4-unicast rib-group DC1INET0-TO-INET0
set routing-options static route 150.1.0.0/16 next-table inet.0
exit
edit protocols ospf3
set rib-group INET60-TO-DC1INET60
set export FROM-DC1-TO-CORE
set import OSPF3-FILTER
exit
edit protocols ospf
set export FROM-DC1-TO-CORE
set import OSPF3-FILTER
exit
edit policy-options policy-statement OSPF2-FILTER
set term 1 from protocol ospf2
set term 1 from tag 13
set term 1 then reject
exit
edit policy-options policy-statement OSPF3-FILTER
set term 1 from protocol ospf3
set term 1 from tag 13
set term 1 then reject
exit
edit policy-options policy-statement FROM-DC1-TO-CORE

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
230
231 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set term 1 from protocol ospf3

set term 1 then tag 13
set term 1 then metric 10
set term 1 then accept
exit
edit policy-options policy-statement FROM-CORE-TO-DC1
set term 4 from family inet
set term 4 from protocol static
set term 4 from route-filter 150.1.0.0/16 exact
set term 4 then tag 13
set term 4 then metric 100
set term 4 then accept
set term 6-OSPF3 from family inet6
set term 6-OSPF3 from protocol ospf3
set term 6-OSPF3 then tag 13
set term 6-OSPF3 then metric 10
set term 6-OSPF3 then accept
set term 6-DIRECT from family inet6
set term 6-DIRECT from protocol direct
set term 6-DIRECT from route-filter 2016:150:1:1::3/128 exact
set term 6-DIRECT from route-filter 2016:150:1:13::/64 exact
set term 6-DIRECT from route-filter 2016:150:1:23::/64 exact
set term 6-DIRECT from route-filter 2016:150:1:35::/64 exact
set term 6-DIRECT then tag 13
set term 6-DIRECT then metric 10
set term 6-DIRECT then accept
exit

Verification
Tasks 1 and 2. Task 1 starts the IGP section with configuration of both OSPFv2 and OSPFv3 within the
Service Provider Network. You can start the task right away but if you take a step back and read through
the whole IGP section, you would notice that you can combine multiple tasks into one configuration
effort and also the best uniformed way to do it. Again, this book emphasises the implementation of
group-based configuration which not only saves work cycles but also ensures the consistency of your
configuration on a system-wide basis. As you can see, answer of this task uses group CORE-INTERFACES to
specify characteristics of any core interface that runs OSPFv2 and OSPFv3. We should start with verifying
OSPF adjacencies between routers, for example:
lab@VMX-R1> show ospf neighbor
Address Interface State ID Pri Dead
150.1.12.2 ge-0/0/2.0 Full 150.1.1.2 128 38
150.1.13.3 ge-0/0/6.0 Full 150.1.1.3 128 37

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

lab@VMX-R2> show ospf neighbor
Address Interface State ID Pri Dead
150.1.24.4 ge-0/0/6.0 Full 150.1.1.4 128 32
150.1.23.3 ge-0/0/8.0 Full 150.1.1.3 128 39
150.1.12.1 ge-0/0/2.0 Full 150.1.1.1 128 32

lab@VMX-R3> show ospf neighbor

Address Interface State ID Pri Dead
150.1.35.5 ge-0/0/7.0 Full 150.1.1.5 128 35
150.1.23.2 ge-0/0/8.0 Full 150.1.1.2 128 39
150.1.13.1 ge-0/0/6.0 Full 150.1.1.1 128 39

lab@VMX-R1> show ospf3 neighbor

ID Interface State Pri Dead
150.1.1.2 ge-0/0/2.0 Full 128 38
Neighbor-address fe80::205:86ff:fe71:2302
150.1.1.3 ge-0/0/6.0 Full 128 32
Neighbor-address fe80::205:86ff:fe71:d206

lab@VMX-R2> show ospf3 neighbor

ID Interface State Pri Dead
150.1.1.4 ge-0/0/6.0 Full 128 34
Neighbor-address fe80::205:86ff:fe71:d906
150.1.1.3 ge-0/0/8.0 Full 128 37
Neighbor-address fe80::205:86ff:fe71:d208
150.1.1.1 ge-0/0/2.0 Full 128 33
Neighbor-address fe80::205:86ff:fe71:8302

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
231
232 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

lab@VMX-R3> show ospf3 neighbor

ID Interface State Pri Dead
150.1.1.5 ge-0/0/7.0 Full 128 34
Neighbor-address fe80::205:86ff:fe71:7807
150.1.1.2 ge-0/0/8.0 Full 128 39
Neighbor-address fe80::205:86ff:fe71:2308
150.1.1.1 ge-0/0/6.0 Full 128 31
Neighbor-address fe80::205:86ff:fe71:8306

We know that for OSPFv2, we can have either clear-text or MD5-hashing authentication. However, task
2 introduces a different way for authenticating OSPF messages that can be applied to both OSPFv2 and
OSPFv3. This method relies on IPSec protocol to provide this functionality and only IPSec transport
mode is supported (not tunnel mode) where only the payload of the OSPF messages is encrypted and
authenticated.
lab@VMX-R1> show ospf interface ge-0/0/2.0 extensive
Interface State Area DR ID BDR ID Nbrs
ge-0/0/2.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1
Type: P2P, Address: 150.1.12.1, Mask: 255.255.255.0, MTU: 1500, Cost: 100
Adj count: 1
Hello: 10, Dead: 40, ReXmit: 5, Stub NSSA
IPSec SA name: SA-OSPF
Auth type: None
Protection type: None
Topology default (ID 0) -> Cost: 100

lab@VMX-R1> show ospf3 interface ge-0/0/2.0 extensive

Interface State Area DR ID BDR ID Nbrs
ge-0/0/2.0 PtToPt 0.0.0.1 0.0.0.0 0.0.0.0 1
Address fe80::5668:28ff:fe3e:ff78, Prefix-length 64
OSPF3-Intf-index 2, Type P2P, MTU 1500, Cost 100
Adj count: 1, Router LSA ID: 0
Hello 10, Dead 40, ReXmit 5, Stub NSSA
IPSec SA name: SA-OSPF
Protection type: None

We can capture the packets to verify that OSPF messages are indeed authenticated with IPSec AH
protocol, SPI 256 as configured. Since we are using hmac-md5-96 hasing method, the pre-shared key
needs to have 16 ASCII characters.
lab@VMX-R1> monitor traffic interface ge-0/0/2.0 matching "ip proto 51" size 1500 no-
resolve
verbose output suppressed, use <detail> or <extensive> for full protocol decode

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

Address resolution is OFF.
Listening on ge-0/0/2.0, capture size 1500 bytes

16:55:56.594834 Out IP 150.1.12.1 > 224.0.0.5: AH(spi=256,seq=0xd6bda4f2): OSPFv2, Hello,

length 60
16:55:57.279986 In IP 150.1.12.2 > 224.0.0.5: AH(spi=256,seq=0x5c21e9a1): OSPFv2, Hello,
length 60
16:56:05.540129 Out IP 150.1.12.1 > 224.0.0.5: AH(spi=256,seq=0x1e92303f): OSPFv2, Hello,
length 60
16:56:07.095092 In IP 150.1.12.2 > 224.0.0.5: AH(spi=256,seq=0x3f15fe56): OSPFv2, Hello,
length 60
16:56:13.200202 Out IP 150.1.12.1 > 224.0.0.5: AH(spi=256,seq=0x41629628): OSPFv2, Hello,
length 60
^C
706 packets received by filter
0 packets dropped by kernel

For the remaining points of task 2, the point-to-point interface type would remove uncessary DR/BDR
election on every Ethernet interface that has got only 2 neighbours, reducing establishment time for
OSPF neighbour establishment. Meanwhile the BFD would verify bidirectional connectivity and help
OSPF detect failure in a sub-second manner rather than relying on interface status. Another advantage
is that we won’t need to implement Fast-Hello feature for both OSPFv2 and OSPFv3 which may have

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
232
233 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

severe impact on CPU resources, rather we only need just one single BFD function for all routing
protocols including RSVP and BGP subsequently.
lab@VMX-R1> show bfd session detail
<snip>
Detect Transmit
Address State Interface Time Interval Multiplier
150.1.12.2 Up ge-0/0/2.0 1.000 0.250 4
Client OSPF realm ospf-v2 Area 0.0.0.1, TX interval 0.250, RX interval 0.250
Session up time 01:21:00
Local diagnostic None, remote diagnostic None
Remote state Up, version 1
Session type: Single hop BFD
<snip>
Detect Transmit
Address State Interface Time Interval Multiplier
fe80::5668:28ff:fe3e:ff6e Up ge-0/0/2.0 1.000 0.250 4
Client OSPF realm ipv6-unicast Area 0.0.0.1, TX interval 0.250, RX interval 0.250
Session up time 01:20:58, previous down time 00:00:09
Local diagnostic CtlExpire, remote diagnostic NbrSignal
Remote state Up, version 1
Session type: Single hop BFD
<snip>

Task 3. This task explicitly requires an OSPFv3 instance for DC1 that is separated from the OSPFv3
instance of the core networks. In JUNOS, you cannot run two parallel OSPFv3 instances that contribute
to the same routing table (in IPv6 routing context it is inet6.0 by default). Thus we have to spin up a new
routing table for links between R1, R3 and DC1, similarly to a MPLS L3 VPN scenario. Firstly let’s verify if
OSPFv3 neighbourships are up and running.
lab@VMX-R1> show ospf3 neighbor instance DC1
ID Interface State Pri Dead
150.1.1.10 ge-0/0/4.116 Full 128 37
Neighbor-address fe80::205:8600:7471:308

lab@VMX-R3> show ospf3 neighbor instance DC1

ID Interface State Pri Dead
150.1.1.10 ge-0/0/4.115 Full 128 37
Neighbor-address fe80::205:8600:7371:308

Now the task requires mutual redistribution between routing instances: inet.0 and DC1.inet.0 for IPv4,
inet6.0 and DC1.inet6.0 for IPv6. Therefore we need to import routes between them accordingly.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

• For IPv4, we only need to import for the direction from DC1.inet.0 to inet.0 because we already
create an IPv4 supernet that represents the core networks in accordance with the task’s
requirement.
• For IPv6, we need to import routes in both directions between DC1.inet6.0 and inet6.0.

We use statement routing-options rib-groups to specify the direction of route import. The statements
protocols ospf3 rib-group and protocols ospf3 realm ipv4-unicast rib-group under routing-instance
stanza are used to specify the source of OSPFv3 routes. Particularly, we need statement routing-options
interface-routes to specify the source of IPv6 directly connected routes as JUNOS routers do not treat
them as OSPFv3 routes even though the interfaces are OSPFv3 enabled. If you do not do this, DC1 will
prefer IPv6 routes corresponding to R3’s directly connected interfaces via R1 because R3 wouldn’t
advertise those, and hence the objective of all IPv6 routes to be following R3 would not be achieved. It is
also notable that the task does not require any traffic engineering for the direction from core networks
to DC1.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
233
234 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Verification for IPv4 routing: DC1 should prefer R1’s path (via ge-0/0/8.116) for the supernet of the core
networks even though it should receive the supernet prefix from both R1 and R3. The core networks
also should have IPv4 routing information from DC1.
lab@VMX-VR> show route table DC1.inet.0 protocol ospf3 active-path

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

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

150.1.0.0/16 *[OSPF3/150] 00:10:35, metric 10, tag 13

> to 150.1.116.1 via ge-0/0/8.116

lab@VMX-VR> show ospf3 database realm ipv4-unicast instance DC1 external extensive
<snip>
Extern 0.0.0.1 150.1.115.1 0x8000003a 686 0x5ab 36
Prefix 150.1.0.0/16
Prefix-options 0x0, Metric 100, Type 2,
Tag 0.0.0.13
Aging timer 00:48:34
Installed 00:11:23 ago, expires in 00:48:34, sent 00:11:21 ago
Last changed 1d 19:37:43 ago, Change count: 1
Extern 0.0.0.1 150.1.116.1 0x8000003b 1430 0xdd2b 36
Prefix 150.1.0.0/16
Prefix-options 0x0, Metric 10, Type 2,
Tag 0.0.0.13
Aging timer 00:36:10
Installed 00:23:47 ago, expires in 00:36:10, sent 00:23:45 ago
Last changed 1d 19:37:49 ago, Change count: 1
<snip>

lab@VMX-R8> show route table inet.0 protocol ospf active-path | match "OSPF/150"
150.1.1.10/32 *[OSPF/150] 00:04:44, metric 10, tag 13
150.1.2.0/24 *[OSPF/150] 00:04:44, metric 10, tag 13
150.1.3.0/24 *[OSPF/150] 00:04:44, metric 10, tag 13
150.1.4.0/24 *[OSPF/150] 00:04:44, metric 10, tag 13
150.1.5.0/24 *[OSPF/150] 00:04:44, metric 10, tag 13
150.1.6.0/24 *[OSPF/150] 00:04:44, metric 10, tag 13
150.1.7.0/24 *[OSPF/150] 00:04:44, metric 10, tag 13
150.1.8.0/24 *[OSPF/150] 00:04:44, metric 10, tag 13
150.1.9.0/24 *[OSPF/150] 00:04:44, metric 10, tag 13
150.1.115.0/30 *[OSPF/150] 00:04:52, metric 10, tag 13
150.1.116.0/30 *[OSPF/150] 00:04:49, metric 10, tag 13

Verification for IPv6 routing: DC1 should prefer R3’s path (via ge-0/0/4.115) for all IPv6 routes of the
core networks redistributed by both R1 and R3. The core networks also should have IPv6 routing
information from DC1.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

lab@VMX-VR> show route table DC1.inet6.0 protocol ospf3 active-path

DC1.inet6.0: 46 destinations, 47 routes (46 active, 0 holddown, 0 hidden)

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

2016:150:1:1::1/128*[OSPF3/150] 00:20:14, metric 10, tag 13

> to fe80::205:8600:7371:d204 via ge-0/0/8.115
2016:150:1:1::2/128*[OSPF3/150] 00:20:14, metric 10, tag 13
> to fe80::205:8600:7371:d204 via ge-0/0/8.115
2016:150:1:1::3/128*[OSPF3/150] 00:20:14, metric 10, tag 13
> to fe80::205:8600:7371:d204 via ge-0/0/8.115
2016:150:1:1::4/128*[OSPF3/150] 00:20:14, metric 10, tag 13
> to fe80::205:8600:7371:d204 via ge-0/0/8.115
2016:150:1:1::5/128*[OSPF3/150] 00:20:14, metric 10, tag 13
> to fe80::205:8600:7371:d204 via ge-0/0/8.115
2016:150:1:1::6/128*[OSPF3/150] 00:20:14, metric 10, tag 13
> to fe80::205:8600:7371:d204 via ge-0/0/8.115
2016:150:1:1::7/128*[OSPF3/150] 00:20:14, metric 10, tag 13
> to fe80::205:8600:7371:d204 via ge-0/0/8.115
2016:150:1:1::8/128*[OSPF3/150] 00:20:14, metric 10, tag 13
> to fe80::205:8600:7371:d204 via ge-0/0/8.115
2016:150:1:12::/64 *[OSPF3/150] 00:20:14, metric 10, tag 13
> to fe80::205:8600:7371:d204 via ge-0/0/8.115
2016:150:1:13::/64 *[OSPF3/150] 00:20:14, metric 10, tag 13
> to fe80::205:8600:7371:d204 via ge-0/0/8.115

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
234
235 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

2016:150:1:23::/64 *[OSPF3/150] 00:20:14, metric 10, tag 13

> to fe80::205:8600:7371:d204 via ge-0/0/8.115
2016:150:1:24::/64 *[OSPF3/150] 00:20:14, metric 10, tag 13
> to fe80::205:8600:7371:d204 via ge-0/0/8.115
2016:150:1:35::/64 *[OSPF3/150] 00:20:14, metric 10, tag 13
> to fe80::205:8600:7371:d204 via ge-0/0/8.115
2016:150:1:45::/64 *[OSPF3/150] 00:20:14, metric 10, tag 13
> to fe80::205:8600:7371:d204 via ge-0/0/8.115
2016:150:1:46::/64 *[OSPF3/150] 00:20:14, metric 10, tag 13
> to fe80::205:8600:7371:d204 via ge-0/0/8.115
2016:150:1:57::/64 *[OSPF3/150] 00:20:14, metric 10, tag 13
> to fe80::205:8600:7371:d204 via ge-0/0/8.115
2016:150:1:67::/64 *[OSPF3/150] 00:20:14, metric 10, tag 13
> to fe80::205:8600:7371:d204 via ge-0/0/8.115
2016:150:1:68::/64 *[OSPF3/150] 00:20:14, metric 10, tag 13
> to fe80::205:8600:7371:d204 via ge-0/0/8.115
2016:150:1:78::/64 *[OSPF3/150] 00:20:14, metric 10, tag 13
> to fe80::205:8600:7371:d204 via ge-0/0/8.115
2016:150:67::/64 *[OSPF3/150] 00:20:14, metric 10, tag 13
> to fe80::205:8600:7371:d204 via ge-0/0/8.115
ff02::5/128 *[OSPF3/10] 00:21:35, metric 1
MultiRecv

lab@VMX-R8> show route table inet6.0 protocol ospf3 active-path | match

"2016:150:1:1::10|2016:150:1:[2-9]::"
2016:150:1:1::10/128
2016:150:1:2::/64 *[OSPF3/150] 00:20:51, metric 10, tag 13
2016:150:1:3::/64 *[OSPF3/150] 00:20:51, metric 10, tag 13
2016:150:1:4::/64 *[OSPF3/150] 00:20:51, metric 10, tag 13
2016:150:1:5::/64 *[OSPF3/150] 00:20:51, metric 10, tag 13
2016:150:1:6::/64 *[OSPF3/150] 00:20:51, metric 10, tag 13
2016:150:1:7::/64 *[OSPF3/150] 00:20:51, metric 10, tag 13
2016:150:1:8::/64 *[OSPF3/150] 00:20:51, metric 10, tag 13
2016:150:1:9::/64 *[OSPF3/150] 00:20:51, metric 10, tag 13

Reachability between DC1 and core networks also should be achieved for both IPv4 and IPv6 with the
expected path preference, for example:
lab@VMX-VR> ping rapid routing-instance DC1 source 150.1.1.10 150.1.1.8
PING 150.1.1.8 (150.1.1.8): 56 data bytes
!!!!!
--- 150.1.1.8 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 24.805/28.959/30.219/2.081 ms

lab@VMX-VR> ping rapid routing-instance DC1 source 2016:150:1:1::10 2016:150:1:1::8

PING6(56=40+8+8 bytes) 2016:150:1:1::10 --> 2016:150:1:1::8
!!!!!

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

--- 2016:150:1:1::8 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 28.901/29.692/29.984/0.402 ms

lab@VMX-VR> traceroute routing-instance DC1 source 150.1.1.10 150.1.1.8

traceroute to 150.1.1.8 (150.1.1.8) from 150.1.1.10, 30 hops max, 40 byte packets
1 150.1.116.1 (150.1.116.1) 17.396 ms 17.714 ms 19.935 ms <-- via R1
2 150.1.12.2 (150.1.12.2) 25.049 ms 24.664 ms 14.754 ms
3 150.1.24.4 (150.1.24.4) 25.030 ms 29.660 ms 29.854 ms
4 150.1.46.6 (150.1.46.6) 35.092 ms 34.343 ms 35.034 ms
5 150.1.1.8 (150.1.1.8) 35.215 ms 29.231 ms 30.035 ms

lab@VMX-VR> traceroute routing-instance DC1 source 2016:150:1:1::10 2016:150:1:1::8

traceroute6 to 2016:150:1:1::8 (2016:150:1:1::8) from 2016:150:1:1::10, 64 hops max, 12
byte packets
1 2016:150:1:115::1 (2016:150:1:115::1) 14.284 ms 14.451 ms 14.923 ms <-- via R3
2 2016:150:1:35::5 (2016:150:1:35::5) 20.102 ms 19.668 ms 20.020 ms
3 2016:150:1:57::7 (2016:150:1:57::7) 24.940 ms 24.788 ms 24.887 ms
4 2016:150:1:1::8 (2016:150:1:1::8) 30.023 ms 29.729 ms 30.193 ms

Since this task presents a multi-point mutual redistribution scenario, a routing loop prevention
mechanism needs to be implemented. On R1 and R3, we simply tag a value (13) to any redistributed
route in export direction and reject any route tagged with value 13 in import direction. In order to
manipulate the preference path for IPv4/IPv6 traffic of either via R1 or via R3, we simply use metric to

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
235
236 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

specify preferred path accordingly. At the end of this topic, we should verify reachability within Service
Provider Network, particularly between loopback interfaces of the routers as it would be instrumental
for the upcoming tasks.
lab@VMX-R1> ping rapid source 150.1.1.1 150.1.1.2
PING 150.1.1.2 (150.1.1.2): 56 data bytes
!!!!!
--- 150.1.1.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 9.871/9.994/10.038/0.062 ms

lab@VMX-R1> ping rapid source 150.1.1.1 150.1.1.3

lab@VMX-R1> ping rapid source 150.1.1.1 150.1.1.4

lab@VMX-R1> ping rapid source 150.1.1.1 150.1.1.5

lab@VMX-R1> ping rapid source 150.1.1.1 150.1.1.6

lab@VMX-R1> ping rapid source 150.1.1.1 150.1.1.7

PING 150.1.1.7 (150.1.1.7): 56 data bytes
!!!!!
--- 150.1.1.7 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 19.674/20.038/20.300/0.221 ms

lab@VMX-R1> ping rapid source 150.1.1.1 150.1.1.8

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

PING 150.1.1.8 (150.1.1.8): 56 data bytes
!!!!!
--- 150.1.1.8 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 24.651/25.045/25.457/0.267 ms

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
236
237 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 3: MPLS
Total Points: 21

Task 1 (2 points). Configure OSPFv2 to build TE database for Service Provider Network; ensure the
tailend router is the one who removes MPLS stack instead of the penultimate router.
R1,R2,R3,R4,R5,R6,R7,R8
!
set protocols ospf traffic-engineering
set protocols mpls explicit-null
set protocols mpls interface all
set groups CORE-INTERFACES interfaces <ge-0/0/[2678]> unit 0 family mpls

Task 2 (8 points). Configure full-mesh RSVP-signaled LSPs between R2, R3, R4, R5, R6, R7 of the Service
Provider Network with the following characteristics.

• All LSPs should be bridged into detour LSPs within tens of milliseconds upon failure of any link
within the core network at the node that detects the failure.
• All LSPs should be monitored and optimised for better path every 1 hour and ensure that the
newly optimised path is established before old path is torn down for reoptimisation activities.
• All routers should wait for at least 30 seconds before using that newly optimised path and at the
same time: ensure that the old path is kept for at least 60 seconds after the newly optimised
path is in use to prevent stale MPLS label due to big churn of re-convergence that could drop
traffic.
• When equal cost paths exist, all LSPs should select the one that has got bandwidth filled most.
• Bidirectional forwarding capability of each LSP should be verified and signalled within 1 second.
• Please use the most efficient configuration method to group common attributes of LSPs.
R2,R3,R4,R5,R6,R7
!
set protocols rsvp interface all link-protection
set interface lo0 unit 0 family inet address 127.0.0.1/32
edit groups LSP-GROUP-CORE protocols mpls label-switched-path <*>
set fast-reroute
set optimize-timer 3600
set adaptive

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

set optimize-switchover-delay 30
set optimize-hold-dead-delay 60
set most-fill
set oam bfd minimum-interval 250 multiplier 4
exit
set apply-groups LSP-GROUP-CORE

R2
!
edit protocols mpls
set label-switched-path R2-TO-R3 to 150.1.1.3
set label-switched-path R2-TO-R4 to 150.1.1.4
set label-switched-path R2-TO-R5 to 150.1.1.5
set label-switched-path R2-TO-R6 to 150.1.1.6
set label-switched-path R2-TO-R7 to 150.1.1.7
exit
set interface lo0 unit 0 family inet address 150.1.1.2/32 primary

R3
!
edit protocols mpls
set label-switched-path R3-TO-R2 to 150.1.1.2
set label-switched-path R3-TO-R4 to 150.1.1.4
set label-switched-path R3-TO-R5 to 150.1.1.5
set label-switched-path R3-TO-R6 to 150.1.1.6
set label-switched-path R3-TO-R7 to 150.1.1.7
exit
set interface lo0 unit 0 family inet address 150.1.1.3/32 primary

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
237
238 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

R4
!
edit protocols mpls
set label-switched-path R4-TO-R2 to 150.1.1.2
set label-switched-path R4-TO-R3 to 150.1.1.3
set label-switched-path R4-TO-R5 to 150.1.1.5
set label-switched-path R4-TO-R6 to 150.1.1.6
set label-switched-path R4-TO-R7 to 150.1.1.7
exit
set interface lo0 unit 0 family inet address 150.1.1.4/32 primary

R5
!
edit protocols mpls
set label-switched-path R5-TO-R2 to 150.1.1.2
set label-switched-path R5-TO-R3 to 150.1.1.3
set label-switched-path R5-TO-R4 to 150.1.1.4
set label-switched-path R5-TO-R6 to 150.1.1.6
set label-switched-path R5-TO-R7 to 150.1.1.7
exit
set interface lo0 unit 0 family inet address 150.1.1.5/32 primary

R6
!
edit protocols mpls
set label-switched-path R6-TO-R2 to 150.1.1.2
set label-switched-path R6-TO-R3 to 150.1.1.3
set label-switched-path R6-TO-R4 to 150.1.1.4
set label-switched-path R6-TO-R5 to 150.1.1.5
set label-switched-path R6-TO-R7 to 150.1.1.7
exit
set interface lo0 unit 0 family inet address 150.1.1.6/32 primary

R7
!
edit protocols mpls
set label-switched-path R7-TO-R2 to 150.1.1.2
set label-switched-path R7-TO-R3 to 150.1.1.3
set label-switched-path R7-TO-R4 to 150.1.1.4
set label-switched-path R7-TO-R5 to 150.1.1.5
set label-switched-path R7-TO-R6 to 150.1.1.6
exit
set interface lo0 unit 0 family inet address 150.1.1.7/32 primary

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

have loopback0 addresses of R1 and R8 in their inet.3 table.
R1,R8
!
set protocols ldp interface all
set protocols ldp explicit-null

R2
!
edit protocols mpls
set label-switched-path R2-TO-R6 to 150.1.1.6 ldp-tunneling
set label-switched-path R2-TO-R7 to 150.1.1.7 ldp-tunneling
exit
set protocols ldp interface lo0.0
set protocols ldp interface ge-0/0/2
set protocols ldp explicit-null

R3
!
edit protocols mpls
set label-switched-path R3-TO-R6 to 150.1.1.6 ldp-tunneling
set label-switched-path R3-TO-R7 to 150.1.1.7 ldp-tunneling
exit
set protocols ldp interface lo0.0
set protocols ldp interface ge-0/0/6
set protocols ldp explicit-null

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
238
239 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

R6
!
edit protocols mpls
set label-switched-path R6-TO-R2 to 150.1.1.2 ldp-tunneling
set label-switched-path R6-TO-R3 to 150.1.1.3 ldp-tunneling
exit
set protocols ldp interface lo0.0
set protocols ldp interface ge-0/0/6
set protocols ldp explicit-null

R7
!
edit protocols mpls
set label-switched-path R7-TO-R2 to 150.1.1.2 ldp-tunneling
set label-switched-path R7-TO-R3 to 150.1.1.3 ldp-tunneling
exit
set protocols ldp interface lo0.0
set protocols ldp interface ge-0/0/2
set protocols ldp explicit-null

Task 4 (5 points). Information from optical/transport team shows that fibre connections between R3-R5
and R4-R5 are actually housed by the same WDM system. Ensure that this fact is taken into account by
CSPF calculation for the redundant LSP paths on R5. Do not use RFC 4202 standard in this task.
R5
!
set routing-options fate-sharing group PIPE-1 cost 1000
set routing-options fate-sharing group PIPE-1 from 150.1.35.3
set routing-options fate-sharing group PIPE-1 from 150.1.45.4
set routing-options fate-sharing group PIPE-2 cost 1000
set routing-options fate-sharing group PIPE-2 from 150.1.57.7
edit protocols mpls
set label-switched-path R5-TO-R2 to 150.1.1.2 primary A
set label-switched-path R5-TO-R3 to 150.1.1.3 primary A
set label-switched-path R5-TO-R4 to 150.1.1.4 primary A
set label-switched-path R5-TO-R6 to 150.1.1.6 primary A
set label-switched-path R5-TO-R7 to 150.1.1.7 primary A
set label-switched-path R5-TO-R2 to 150.1.1.2 secondary B standby
set label-switched-path R5-TO-R3 to 150.1.1.3 secondary B standby
set label-switched-path R5-TO-R4 to 150.1.1.4 secondary B standby
set label-switched-path R5-TO-R6 to 150.1.1.6 secondary B standby
set label-switched-path R5-TO-R7 to 150.1.1.7 secondary B standby
set path A
set path B
exit

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

Task 5 (1 point). Allow for customers or peers to see MPLS hops of the Service Provider Network when
performing ICMP ping and traceroute; Enable RSVP to signal MTU value along the path of all LSPs.
R1,R2,R3,R4,R5,R6,R7,R8
!
set protocols mpls icmp-tunneling
set protocols mpls path-mtu rsvp mtu-signaling

Verification
Task 1. Once OSPF is enabled with TE extension, it generates and propagates Opaque LSA to advertise
link attributes throughout the OSPF domain in addition to the regular cost value. The attributes include
values such as reservable bandwidth for RSVP, remaining bandwidth, etc. Another interesting part of
this practice lab is that there are multiple OSPF areas, hence there would be multiple TE databases (TE)
being created. And this behaviour does create some challenges for MPLS RSVP-signalled LSPs to be
formed which we will see in the upcoming task. As can be seen below, there are 3 TEDs for area 0.0.0.0,
area 0.0.0.1 and 0.0.0.8.
lab@VMX-R3> show ospf database opaque-area

OSPF database, Area 0.0.0.0

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
239
240 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Type ID Adv Rtr Seq Age Opt Cksum Len

OpaqArea 1.0.0.1 150.1.1.2 0x80000002 1760 0x22 0x7f1 28
OpaqArea*1.0.0.1 150.1.1.3 0x80000005 326 0x22 0x5ee 28
OpaqArea 1.0.0.1 150.1.1.4 0x80000002 1321 0x22 0xfe5 28
OpaqArea 1.0.0.1 150.1.1.5 0x80000002 1326 0x22 0x13df 28
OpaqArea 1.0.0.1 150.1.1.6 0x80000002 1774 0x22 0x17d9 28
OpaqArea 1.0.0.1 150.1.1.7 0x80000002 1774 0x22 0x1bd3 28
OpaqArea 1.0.0.3 150.1.1.2 0x80000002 811 0x22 0x481f 136
OpaqArea*1.0.0.3 150.1.1.3 0x80000005 135 0x22 0x86cc 136
OpaqArea 1.0.0.3 150.1.1.4 0x80000002 775 0x22 0x271e 136
OpaqArea 1.0.0.3 150.1.1.5 0x80000002 781 0x22 0xfd2b 136
OpaqArea 1.0.0.3 150.1.1.6 0x80000002 990 0x22 0x2be1 136
OpaqArea 1.0.0.3 150.1.1.7 0x80000002 990 0x22 0x9e83 136
OpaqArea 1.0.0.4 150.1.1.2 0x80000002 706 0x22 0x5211 136
OpaqArea*1.0.0.4 150.1.1.3 0x80000005 71 0x22 0x1758 136
OpaqArea 1.0.0.4 150.1.1.4 0x80000002 229 0x22 0x2452 136
OpaqArea 1.0.0.4 150.1.1.5 0x80000002 237 0x22 0xbb9f 136
OpaqArea 1.0.0.4 150.1.1.6 0x80000002 696 0x22 0x92aa 136
OpaqArea 1.0.0.4 150.1.1.7 0x80000002 696 0x22 0xd138 136
OpaqArea 1.0.0.5 150.1.1.4 0x80000001 2141 0x22 0x2918 136
OpaqArea 1.0.0.5 150.1.1.5 0x80000001 2148 0x22 0xf053 136

OSPF database, Area 0.0.0.1

Type ID Adv Rtr Seq Age Opt Cksum Len
OpaqArea 1.0.0.1 150.1.1.1 0x80000005 1307 0x20 0x1bde 28
OpaqArea 1.0.0.1 150.1.1.2 0x80000002 1656 0x20 0x25d5 28
OpaqArea*1.0.0.1 150.1.1.3 0x80000005 263 0x20 0x23d2 28
OpaqArea 1.0.0.3 150.1.1.2 0x80000002 1550 0x20 0x4045 136
OpaqArea*1.0.0.3 150.1.1.3 0x80000005 199 0x20 0x97f2 136

lab@VMX-R6> show ospf database opaque-area

<snip>
OSPF database, Area 0.0.0.8
Type ID Adv Rtr Seq Age Opt Cksum Len
OpaqArea*1.0.0.1 150.1.1.6 0x80000002 1737 0x22 0x17d9 28
OpaqArea 1.0.0.1 150.1.1.7 0x80000002 1740 0x22 0x1bd3 28
OpaqArea 1.0.0.1 150.1.1.8 0x80000001 2233 0x22 0x21cc 28
OpaqArea*1.0.0.3 150.1.1.6 0x80000002 1149 0x22 0xd436 136
OpaqArea 1.0.0.3 150.1.1.7 0x80000002 1251 0x22 0x589a 136

Furthermore, we need to enable MPLS and ensure PHP (penultimate-hop-popping) behaviour is disabled
where the last hop removes MPLS stack (or topmost label) instead of the hop before it. This design
facilitates certain MPLS QoS implementations where we would need to retain the MPLS stack until the
last hop for proper classification and/or queueing on the egress. In order to disable PHP behaviour, we
use explicit-null statement under protocols mpls stanza which has effect on RSVP-signaled LSP. Later
on in task 3, we will use explicit-null statement again but under protocols ldp stanza which has effect

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

on LDP-signaled LSP. According to RFC3032 when disabling PHP, label 0 is advertised by the last hop
instead of label 3 to signal the penultimate hop that it wishes to retain MPLS label stack. There is a
detailed explanation
http://www.juniper.net/documentation/en_US/junos12.3/topics/task/configuration/mpls-ultimate-
hop-popping-enabling.html for the the impact of disabling PHP in JUNOS.

Task 2. In terms of configuration efficiency and consistency, we should configure a class of LSP (group
LSP-GROUP-CORE in this case) that has got all common attributes and then let all LSPs to inherit from
those. This way we can ensure that all LSPs would have similar behaviours and there is no need to
maintain per-LSP configuration which is not scalable and raises risks such as a typo mistake or missing
attributes. Before discussing LSP’s attributes in detailed, let’s ensure that all LSPs are fully signalled and
in Up state.
lab@VMX-R2> show mpls lsp ingress
Ingress LSP: 5 sessions
To From State Rt P ActivePath LSPname
150.1.1.3 150.1.1.2 Up 0 * R2-TO-R3
150.1.1.4 150.1.1.2 Up 0 * R2-TO-R4

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
240
241 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

150.1.1.5 150.1.1.2 Up 0 * R2-TO-R5

150.1.1.6 150.1.1.2 Up 0 * R2-TO-R6
150.1.1.7 150.1.1.2 Up 0 * R2-TO-R7
Total 5 displayed, Up 5, Down 0

lab@VMX-R3> show mpls lsp ingress

Ingress LSP: 5 sessions
To From State Rt P ActivePath LSPname
150.1.1.2 150.1.1.3 Up 0 * R3-TO-R2
150.1.1.4 150.1.1.3 Up 0 * R3-TO-R4
150.1.1.5 150.1.1.3 Up 0 * R3-TO-R5
150.1.1.6 150.1.1.3 Up 0 * R3-TO-R6
150.1.1.7 150.1.1.3 Up 0 * R3-TO-R7
Total 5 displayed, Up 5, Down 0

lab@VMX-R4> show mpls lsp ingress

Ingress LSP: 5 sessions
To From State Rt P ActivePath LSPname
150.1.1.2 150.1.1.4 Up 0 * R4-TO-R2
150.1.1.3 150.1.1.4 Up 0 * R4-TO-R3
150.1.1.5 150.1.1.4 Up 0 * R4-TO-R5
150.1.1.6 150.1.1.4 Up 0 * R4-TO-R6
150.1.1.7 150.1.1.4 Up 0 * R4-TO-R7
Total 5 displayed, Up 5, Down 0

lab@VMX-R5> show mpls lsp ingress

Ingress LSP: 5 sessions
To From State Rt P ActivePath LSPname
150.1.1.2 150.1.1.5 Up 0 * A R5-TO-R2
150.1.1.3 150.1.1.5 Up 0 * A R5-TO-R3
150.1.1.4 150.1.1.5 Up 0 * A R5-TO-R4
150.1.1.6 150.1.1.5 Up 0 * A R5-TO-R6
150.1.1.7 150.1.1.5 Up 0 * A R5-TO-R7
Total 5 displayed, Up 5, Down 0

lab@VMX-R6> show mpls lsp ingress

Ingress LSP: 5 sessions
To From State Rt P ActivePath LSPname
150.1.1.2 150.1.1.6 Up 0 * R6-TO-R2
150.1.1.3 150.1.1.6 Up 0 * R6-TO-R3
150.1.1.4 150.1.1.6 Up 0 * R6-TO-R4
150.1.1.5 150.1.1.6 Up 0 * R6-TO-R5
150.1.1.7 150.1.1.6 Up 0 * R6-TO-R7
Total 5 displayed, Up 5, Down 0

lab@VMX-R7> show mpls lsp ingress

Ingress LSP: 5 sessions
To From State Rt P ActivePath LSPname
150.1.1.2 150.1.1.7 Up 0 * R7-TO-R2

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

150.1.1.3 150.1.1.7 Up 0 * R7-TO-R3
150.1.1.4 150.1.1.7 Up 0 * R7-TO-R4
150.1.1.5 150.1.1.7 Up 0 * R7-TO-R5
150.1.1.6 150.1.1.7 Up 0 * R7-TO-R6
Total 5 displayed, Up 5, Down 0

JUNOS offers full-blown of features to optimise RSVP-signalled LSPs. The use of these features requires
thorough understanding and must be prepared carefully as otherwise they might de-stablise the
networks.

• Let’s start with fast-reroute to enable Fast-Reroute feature which requires all nodes along the
LSP path except the egress node to signal a detour LSP across each link of the path and get the
detour LSP ready upon failure event of link. The difference between this method and the
Link/Node Protection is that the detour LSP cannot be shared between multiple LSPs traversing
the same failure link. Meanwhile the bypass LSP can be shared. Please refer to
https://www.juniper.net/documentation/en_US/junos12.3/topics/concept/mpls-fast-reroute-
node-protection-link-protection.html for more information.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
241
242 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

• Another important feature is the reoptimisation period, tuned by optimize-timer statement

which should be used with adaptive statement to ensure that the new more-optimised path is
fully signalled before the old less-optimised path is torn down.
• Another feature following reoptimisation period is controlled by statement optimize-
switchover-delay which tell the router to wait for some time (default is 1s) before switching
over LSPs to newly optimised paths. A related feature is somewhat called OHDD which is
controlled by statement optimize-hold-dead-delay which keeps the old less-optimised path for
some time to ensure all routes can switch over to the new path.
• If multiple paths are available upon completion of CSPF, a tie-breaking rule is applied to choose
the path for the LSP. The default tie-breaking method is random, intending to place an equal
number of LSPs on each link, regardless of the available bandwidth. This task uses method most-
fill which would try to package as many LSPs across links as possible.

lab@VMX-R6> show mpls lsp ingress name R6-TO-R2 extensive

Ingress LSP: 5 sessions

150.1.1.2
From: 150.1.1.6, State: Up, ActiveRoute: 0, LSPname: R6-TO-R2
ActivePath: (primary)
FastReroute desired
LSPtype: Static Configured
LoadBalance: Most-fill
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Priorities: 7 0
OptimizeTimer: 3600
SmartOptimizeTimer: 180
Reoptimization in 1296 second(s).
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 200)
150.1.46.4 S 150.1.24.2 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-
ID):
150.1.46.4(flag=1) 150.1.24.2
OAM state : BFD session up LSP-ping up
7 Dec 30 21:20:13.234 Fast-reroute Detour Up
6 Dec 30 21:20:07.293 Record Route: 150.1.46.4(flag=1) 150.1.24.2
5 Dec 30 21:20:04.234 Selected as active path
4 Dec 30 21:20:04.224 Record Route: 150.1.46.4 150.1.24.2
3 Dec 30 21:20:04.224 Up
2 Dec 30 21:20:04.138 Originate Call
1 Dec 30 21:20:04.138 CSPF: computation result accepted 150.1.46.4 150.1.24.2

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

Created: Fri Dec 30 21:19:34 2016
Total 1 displayed, Up 1, Down 0

With MPLS OAM, we can leverage BFD to actually check two-way forwarding capability between the
endpoint of the LSP. This requires the configuration of local address 127.0.0.1/32 on the loopback0
interfaces and the statement oam at LSP level. It is recommended to add primary statement to the actual
IP address on loopback0. BFD aids in the detection of link/node failures within MPLS domain and can
help accelerate the switchover to the backup paths. Note that when you enable MPLS OAM, BFD will
perform in multi-hop mode and it needs UDP ports 3503 and 4784 to be open at the local router, i.e.
COPP ACL may need to be updated (if any), and also IP address 127.0.0.1/32 to be configured at the
loopback0 interface. Best practices indicate that you should retain the current loopback0 IP address
with primary statement. Let’s verify this point as below. We can see that alongside the BFD sessions
enabled for OSPFv2 and OSPFv3 earlier at the physical interface level, there are now multihop BFD
sessions between loopback0 interfaces of MPLS nodes as the result of MPLS OAM.
lab@VMX-R6> show bfd session
Detect Transmit
Address State Interface Time Interval Multiplier
127.0.0.1 Up ge-0/0/7.0 0.750 0.250 4

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
242
243 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

127.0.0.1 Up ge-0/0/7.0 0.750 0.250 4

127.0.0.1 Up ge-0/0/8.0 0.750 0.250 4
127.0.0.1 Up ge-0/0/7.0 0.750 0.250 4
127.0.0.1 Up ge-0/0/8.0 0.750 0.250 4
150.1.1.2 Up 1.000 0.250 3
150.1.1.3 Up 1.000 0.250 3
150.1.1.4 Up 1.000 0.250 3
150.1.1.4 Up 1.000 0.250 4
150.1.1.5 Up 1.000 0.250 3
150.1.1.5 Up 1.000 0.250 3
150.1.1.5 Up 1.000 0.250 4
150.1.1.7 Up 1.000 0.250 3
150.1.46.4 Up ge-0/0/7.0 1.000 0.250 4
150.1.67.7 Up ge-0/0/8.0 1.000 0.250 4
150.1.68.8 Up ge-0/0/6.0 1.000 0.250 4
fe80::5668:28ff:fe3e:fe8a Up ge-0/0/7.0 1.000 0.250 4
fe80::5668:28ff:fe3f:c8 Up ge-0/0/6.0 1.000 0.250 4
fe80::5668:28ff:fe3f:c9 Up ge-0/0/8.0 1.000 0.250 4

19 sessions, 19 clients
Cumulative transmit rate 76.0 pps, cumulative receive rate 76.0 pps

lab@VMX-R6> show bfd session detail

Detect Transmit
Address State Interface Time Interval Multiplier
127.0.0.1 Up ge-0/0/7.0 0.750 0.250 4
Client RSVP-OAM, TX interval 0.250, RX interval 0.250
Session up time 00:02:53
Local diagnostic NbrSignal, remote diagnostic None
Remote state Up, version 1
Session type: Multi hop BFD
<snip>

Task 3. This task discusses the implementation of pure LDP networks and also LDP over RSVP technology
in order to interconnect two separated LDP islands (R1, R2, R3 and R6, R7, R8) across an RSVP domain.
The general idea behind this technology is scalability which helps reduce the scope of full-mesh RSVP
LSPs within service provider networks. In this task, we tunnel LDP signalling inside RSVP LSPs such that
R1 and R8 can send and receive LDP label binding information for the networks associated with them.
From configuration perspectives, we need to use statement ldp-tunneling on the RSVP LSPs and enable
LDP on the interface loopback0. The LSPs that we select need to satisfy the requirement that the
interconnect of LDP islands can sustain failure of either R2, R3, R6 or R7. Therefore we enable this
feature for RSVP LSPs between these routers which will then form targeted LDP neighbourship denoted
with interface lo0.0 as below alongside regular LDP neighbourship on R1 and R8.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

lab@VMX-R1> show ldp neighbor
Address Interface Label space ID Hold time
150.1.12.2 ge-0/0/2.0 150.1.1.2:0 11
150.1.13.3 ge-0/0/6.0 150.1.1.3:0 11

lab@VMX-R8> show ldp neighbor

Address Interface Label space ID Hold time
150.1.78.7 ge-0/0/2.0 150.1.1.7:0 13
150.1.68.6 ge-0/0/6.0 150.1.1.6:0 12

lab@VMX-R6> show ldp neighbor

Address Interface Label space ID Hold time
150.1.1.2 lo0.0 150.1.1.2:0 33
150.1.1.3 lo0.0 150.1.1.3:0 41
150.1.68.8 ge-0/0/6.0 150.1.1.8:0 12

lab@VMX-R7> show ldp neighbor

Address Interface Label space ID Hold time
150.1.1.2 lo0.0 150.1.1.2:0 39
150.1.1.3 lo0.0 150.1.1.3:0 37
150.1.78.8 ge-0/0/2.0 150.1.1.8:0 14

After that we should see LDP label binding for loopback0 network of R8 in table inet.3 of R1 and vice
versa, indicating the interconnect of LDP islands.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
243
244 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

lab@VMX-R1> show route table inet.3 protocol ldp 150.1.1.8/32

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

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

150.1.1.8/32 *[LDP/9] 01:46:01, metric 1

to 150.1.12.2 via ge-0/0/2.0, Push 299968
> to 150.1.13.3 via ge-0/0/6.0, Push 299920

lab@VMX-R8> show route table inet.3 protocol ldp 150.1.1.1/32

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

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

150.1.1.1/32 *[LDP/9] 01:46:15, metric 1

> to 150.1.78.7 via ge-0/0/2.0, Push 299904
to 150.1.68.6 via ge-0/0/6.0, Push 299968

Another note on this task is that since we have disabled PHP behaviour for RSVP-signalled LSPs in task 1,
we should do so for LDP-signalled LSPs for consistency even though it is not mandatory.

Task 3. This task discusses a feature that allows to take into account path information at layers 1, 2
when running CSPF. Most of the time, when it comes to path redundancy, we would want the paths to
be diverse across different physical failure domains. If both primary and backup paths of an LSP go in the
same fibre conduit or DWDM system, there is literally no redundancy at all because both paths are likely
to go down at the same time. RFCs 4203 and 5307 document extensions to OSPF and IS-IS respectively
to distribute SRLG (shared risk link group) value for TE-enabled links. This standard feature has been
examined in the previous pratice lab and in the current one we explore a JUNOS feature called Fate-
Sharing which has similar effect.

From configuration perspectives, with statement fate-sharing group under routing-options stanza, we
simply create a group of MPLS neighbours belonging to the same physical infrastructure that the local
router R5 reaches. In this case they are R3 and R4 as indicated: fibre connections between R3-R5 and
R4-R5 are actually housed by the same WDM system. We use R3 and R4’s IP addresses on the directly
connected interfaces instead of their Router-IDs. The same method is applied to R7 in a separate group.
We then assign a cost value to the groups, an arbitrary value of 1000 is selected. This cost value will be
taken into account of CSPF for secondary paths of LSPs sourced from the local router R5 to ensure that

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

they secondary paths will not traverse the same MPLS neighbours R3 and/or R4 if the primary paths
already have done so. As can be seen from the output below, primary path of LSP R5-TO-R3 is via R5-R3
direct path, while the backup path is via R5-R7-R6-R4-R2-R3. The other path R5-R4-R2-R3 is shorter than
path R5-R7-R6-R4-R2-R3 but not choosen as backup path because it contains one link in the same Fate-
Sharing group with the primary path. Note: if your output does not look like below, you may need to
clear the state of the LSP R5-TO-R3 with command clear mpls lsp name R5-TO-R3.
lab@VMX-R5> show mpls lsp ingress name R5-TO-R3 extensive
Ingress LSP: 5 sessions

150.1.1.3
From: 150.1.1.5, State: Up, ActiveRoute: 0, LSPname: R5-TO-R3
ActivePath: A (primary)
FastReroute desired
LSPtype: Static Configured, Penultimate hop popping
LoadBalance: Most-fill
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary A State: Up
Priorities: 7 0
OptimizeTimer: 3600
SmartOptimizeTimer: 180
Reoptimization in 1985 second(s).
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 100)

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
244
245 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

150.1.35.3 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-
ID):
150.1.35.3
OAM state : BFD session up LSP-ping up
6 Mar 26 05:31:35.736 Fast-reroute Detour Up
5 Mar 26 05:31:26.701 Selected as active path
4 Mar 26 05:31:26.700 Record Route: 150.1.35.3
3 Mar 26 05:31:26.700 Up
2 Mar 26 05:31:26.544 Originate Call
1 Mar 26 05:31:26.544 CSPF: computation result accepted 150.1.35.3
Standby B State: Up
Priorities: 7 0
OptimizeTimer: 3600
SmartOptimizeTimer: 180
Reoptimization in 2339 second(s).
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 500)
150.1.57.7 S 150.1.67.6 S 150.1.46.4 S 150.1.24.2 S 150.1.23.3 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-
ID):
150.1.57.7(flag=9) 150.1.67.6(flag=9) 150.1.46.4(flag=9) 150.1.24.2(flag=1)
150.1.23.3
OAM state : BFD session up LSP-ping up
9 Mar 26 05:33:43.007 Fast-reroute Detour Up
8 Mar 26 05:31:59.426 Record Route: 150.1.57.7(flag=9) 150.1.67.6(flag=9)
150.1.46.4(flag=9) 150.1.24.2(flag=1) 150.1.23.3
7 Mar 26 05:31:59.275 Record Route: 150.1.57.7(flag=9) 150.1.67.6(flag=9)
150.1.46.4(flag=9) 150.1.24.2 150.1.23.3
6 Mar 26 05:31:58.967 Record Route: 150.1.57.7(flag=9) 150.1.67.6(flag=9) 150.1.46.4
150.1.24.2 150.1.23.3
5 Mar 26 05:31:58.912 Record Route: 150.1.57.7(flag=9) 150.1.67.6 150.1.46.4
150.1.24.2 150.1.23.3
4 Mar 26 05:31:56.929 Record Route: 150.1.57.7 150.1.67.6 150.1.46.4 150.1.24.2
150.1.23.3
3 Mar 26 05:31:56.929 Up
2 Mar 26 05:31:55.364 Originate Call
1 Mar 26 05:31:55.364 CSPF: computation result accepted 150.1.57.7 150.1.67.6
150.1.46.4 150.1.24.2 150.1.23.3
Created: Sun Mar 26 05:30:57 2017
Total 1 displayed, Up 1, Down 0

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

--- lsping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

lab@VMX-R5> ping mpls rsvp R5-TO-R3

!!!!!
--- lsping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

lab@VMX-R5> ping mpls rsvp R5-TO-R4

!!!!!
--- lsping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

lab@VMX-R5> ping mpls rsvp R5-TO-R6

!!!!!
--- lsping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

lab@VMX-R5> ping mpls rsvp R5-TO-R7

!!!!!
--- lsping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
245
246 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

which the RSVP path message is sent and at each hop along the path, MTU in the Adspec object is
updated to the minimum of the received value and the value of the outgoing interfaces for both primary
and secondary LSPs.
lab@VMX-R6> show mpls lsp egress name R2-TO-R6 extensive
Egress LSP: 6 sessions, 6 detours

150.1.1.6
From: 150.1.1.2, LSPstate: Up, ActiveRoute: 0
LSPname: R2-TO-R6, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: -
Resv style: 1 SE, Label in: 0, Label out: -
Time left: 135, Since: Fri Dec 30 23:32:09 2016
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Port number: sender 1 receiver 39684 protocol 0
FastReroute desired
PATH rcvfrom: 150.1.46.4 (ge-0/0/7.0) 24 pkts
Adspec: received MTU 1500
PATH sentto: localclient
RESV rcvfrom: localclient
Record route: 150.1.24.2 150.1.46.4 <self>
Detour branch from 150.1.45.4, to skip 150.1.1.6, Up
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Adspec: received MTU 1500
Path MTU: received 0
Detour branch from 150.1.23.2, to skip 150.1.1.4, Up
Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
Adspec: received MTU 1500
Path MTU: received 0
PATH rcvfrom: 150.1.67.7 (ge-0/0/8.0) 20 pkts
Adspec: received MTU 1500
PATH sentto: localclient
RESV rcvfrom: localclient
Record route: 150.1.24.2 150.1.45.4 150.1.57.5 150.1.67.7 <self>
Label in: 0, Label out: -
Total 1 displayed, Up 1, Down 0

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
246
247 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Topic 4: BGP
Total Points: 20

Task 1 (4 points). Configure R4 and R5 as iBGP route reflectors for the Service Provider Network the
other routers as their clients. R4 and R5 should always advertise BGP best paths regardless of whether
they are active in the RIB or not. Ensure iBGP sessions are enabled with MD5 authentication and their
bidirectional forwarding capability is monitored through BFD. Announce the IPv4/IPv6 supernets of the
Service Provider Network on R4 and R5 (2 static routes are allowed on each router).
R1,R2,R3,R6,R7,R8
!
set routing-options autonomous-system 1.57920 asdot-notation
edit protocols bgp group IBGP
set type internal
set neighbor 150.1.1.4
set neighbor 150.1.1.5
set bfd minimum-interval 500 multiplier 4
set export NHS
exit
edit policy-options policy-statement NHS
set term 1 from protocol bgp
set term 1 from route-type external
set term 1 then next-hop self
set term 1 then accept
exit

R1
!
set protocols bgp group IBGP local-address 150.1.1.1

R2
!
set protocols bgp group IBGP local-address 150.1.1.2

R3
!
set protocols bgp group IBGP local-address 150.1.1.3

R6
!
set protocols bgp group IBGP local-address 150.1.1.6

R7
!

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

set protocols bgp group IBGP local-address 150.1.1.7

R8
!
set protocols bgp group IBGP local-address 150.1.1.8

R4
!
set routing-options autonomous-system 1.57920 asdot-notation
edit protocols bgp group IBGP
set type internal
set cluster 150.1.1.4
set local-address 150.1.1.4
set neighbor 150.1.1.1
set neighbor 150.1.1.2
set neighbor 150.1.1.3
set neighbor 150.1.1.6
set neighbor 150.1.1.7
set neighbor 150.1.1.8
set bfd minimum-interval 500 multiplier 4
set export AS-AGGREGATE
set advertise-inactive
exit
edit protocols bgp group IBGP-RR
set type internal
set local-address 150.1.1.4
set neighbor 150.1.1.5

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
247
248 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set bfd minimum-interval 500 multiplier 4

set export AS-AGGREGATE
set advertise-inactive
exit
edit policy-options policy-statement AS-AGGREGATE
set term 1 from protocol aggregate
set term 1 from route-filter 150.1.0.0/16 exact
set term 1 then accept
set term 2 from protocol aggregate
set term 2 from route-filter 2016:150:1::/48 exact
set term 2 then accept
exit
set routing-options aggregate route 150.1.0.0/16
set routing-options rib inet6.0 aggregate route 2016:150:1::/48

R5
!
set routing-options autonomous-system 1.57920 asdot-notation
edit protocols bgp group IBGP
set type internal
set cluster 150.1.1.5
set local-address 150.1.1.5
set neighbor 150.1.1.1
set neighbor 150.1.1.2
set neighbor 150.1.1.3
set neighbor 150.1.1.6
set neighbor 150.1.1.7
set neighbor 150.1.1.8
set bfd minimum-interval 500 multiplier 4
set export AS-AGGREGATE
set advertise-inactive
exit
edit protocols bgp group IBGP-RR
set type internal
set local-address 150.1.1.5
set neighbor 150.1.1.4
set bfd minimum-interval 500 multiplier 4
set export AS-AGGREGATE
set advertise-inactive
exit
edit policy-options policy-statement AS-AGGREGATE
set term 1 from protocol aggregate
set term 1 from route-filter 150.1.0.0/16 exact
set term 1 then accept
set term 2 from protocol aggregate
set term 2 from route-filter 2016:150:1::/48 exact
set term 2 then accept
exit
set routing-options aggregate route 150.1.0.0/16
set routing-options rib inet6.0 aggregate route 2016:150:1::/48

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
248
249 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

You can launch ping tests from any C/T/P routing-instance on VRF device with some test IPv4/IPv6
addresses below.

• C1: 170.1.210.1, 2016:170:1:210::1

• C4: 170.1.240.1, 2016:170:1:240::1
• P1: 100.0.0.1, 2016:100::1
• P2: 200.0.0.1, 2016:200::1
• T1: 111.0.0.1, 2016:111::1, 12.0.0.1, 2016:12::1
• T2: 222.0.0.1, 2016:222::1, 12.0.0.2, 2016:12::2
• T3 (behind T1, T2): 123.0.0.1, 2016:123::1
R1,R2,R3,R4,R5,R6,R7,R8
!
set protocols mpls ipv6-tunneling
set protocols bgp group IBGP family inet unicast
set protocols bgp group IBGP family inet6 labeled-unicast explicit-null

R4,R5
!
set protocols bgp group IBGP-RR family inet unicast
set protocols bgp group IBGP-RR family inet6 labeled-unicast explicit-null
edit policy-options policy-statement INET0-TO-INET3-INET63
set term LDP-ROUTERS-6PE from protocol ospf
set term LDP-ROUTERS-6PE from route-filter ::ffff:150.1.1.1/128 exact
set term LDP-ROUTERS-6PE from route-filter ::ffff:150.1.1.8/128 exact
set term LDP-ROUTERS-6PE to rib inet6.3
set term LDP-ROUTERS-6PE then accept
set term DENY-ALL then reject
exit
set routing-options rib-groups INET0-TO-INET3-INET63 import-rib [inet.0 inet.3 inet6.3]
set routing-options rib-groups INET0-TO-INET3-INET63 import-policy INET0-TO-INET3-INET63
set protocols ospf rib-group INET0-TO-INET3-INET63

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

set neighbor 2016:150:1:100::2 peer-as 100
exit
edit protocols bgp group TRANSIT
set type external
set neighbor 111.1.120.2 peer-as 111
set neighbor 2016:111:1:120::2 peer-as 111
set neighbor 222.1.106.2 peer-as 222
set neighbor 2016:222:1:106::2 peer-as 222
exit
edit policy-options policy-statement INET0-TO-INET3-INET63
set term RR-ROUTERS-6PE from protocol ospf
set term RR-ROUTERS-6PE from route-filter ::ffff:150.1.1.4/128 exact
set term RR-ROUTERS-6PE from route-filter ::ffff:150.1.1.5/128 exact
set term RR-ROUTERS-6PE to rib inet6.3
set term RR-ROUTERS-6PE then accept
set term DENY-ALL then reject
exit
set routing-options rib-groups INET0-TO-INET3-INET63 import-rib [inet.0 inet.3 inet6.3]
set routing-options rib-groups INET0-TO-INET3-INET63 import-policy INET0-TO-INET3-INET63
set protocols ospf rib-group INET0-TO-INET3-INET63

R2
!
edit protocols bgp group PEER
set type external
set neighbor 150.1.113.2 peer-as 100
set neighbor 2016:150:1:113::2 peer-as 100

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
249
250 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set neighbor 150.1.101.2 peer-as 200

set neighbor 2016:150:1:101::2 peer-as 200
exit
edit protocols bgp group TRANSIT
set type external
set neighbor 222.1.123.2 peer-as 222
set neighbor 2016:222:1:123::2 peer-as 222
exit
edit protocols bgp group CUSTOMER
set type external
set neighbor 150.1.102.2 peer-as 65002
set neighbor 2016:150:1:102::2 peer-as 65002
exit

R6
!
edit protocols bgp group CUSTOMER
set type external
set neighbor 150.1.107.2 peer-as 65004
set neighbor 150.1.107.2 family inet unicast
set neighbor 150.1.107.2 family inet6 unicast
exit

R7
!
edit protocols bgp group TRANSIT
set type external
set neighbor 111.1.105.2 peer-as 111
set neighbor 2016:111:1:105::2 peer-as 111
exit

R8
!
edit policy-options policy-statement INET0-TO-INET3-INET63
set term RR-ROUTERS-6PE from protocol ospf
set term RR-ROUTERS-6PE from route-filter ::ffff:150.1.1.4/128 exact
set term RR-ROUTERS-6PE from route-filter ::ffff:150.1.1.5/128 exact
set term RR-ROUTERS-6PE to rib inet6.3
set term RR-ROUTERS-6PE then accept
set term DENY-ALL then reject
exit
set routing-options rib-groups INET0-TO-INET3-INET63 import-rib [inet.0 inet.3 inet6.3]
set routing-options rib-groups INET0-TO-INET3-INET63 import-policy INET0-TO-INET3-INET63
set protocols ospf rib-group INET0-TO-INET3-INET63

Task 3 (8 points). Implement the following features/policies for the Service Provider Network:

• Ingress routing:

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

o Primary inbound locations of prefixes 150.1.0.0/18, 150.1.64.0/18 should be R7-T1 and
R1-T2
o Primary inbound locations of prefixes 150.1.128.0/18, 150.1.192.0/18 should be R1-T1
and R2-T2
• Egress routing:
o Primary outbound locations for all prefixes should be in order of customers, peers, and
transits.
o Primary outbound locations for prefixes of ASNs 301, 303 should be T1
o Primary outbound locations for prefixes of ASNs 302, 304 should be T2.
• For prefixes advertised by peers and customers, acccept only the ones which are locally
originated from within them invidually.
• Protect BGP routing table from T2’s advertisements by accepting only IPv4 and IPv6 prefixes
with AS-PATH length of less than or equal 10.
• Protect BGP routing table and stability of the routing domain by configuring a method that
suppress unstable prefixes from P1 and P2 until they become stable, perform suppression for
P2’s prefixes more aggressive than by default.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
250
251 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

/* ingress routing */

R1
!
set protocols bgp group TRANSIT neighbor 222.1.106.2 export T2-OUT
edit policy-options policy-statement T2-OUT
set term 1 from protocol bgp
set term 1 from route-filter 150.1.128.0/17 exact
set term 1 then metric 500
set term 1 then accept
set term 10 from protocol bgp
set term 10 then metric 1000
exit

R4,R5
!
edit policy-options policy-statement AS-AGGREGATE
set term 1 from route-filter 150.1.0.0/17 exact
set term 1 from route-filter 150.1.128.0/17 exact
exit
set routing-options aggregate route 150.1.0.0/17
set routing-options aggregate route 150.1.128.0/17

R7
!
set protocols bgp group TRANSIT neighbor 111.1.105.2 export T1-OUT
edit policy-options policy-statement T1-OUT
set term 1 from protocol bgp
set term 1 from route-filter 150.1.0.0/17 exact
set term 1 then metric 500
set term 1 then accept
set term 10 from protocol bgp
set term 10 then metric 1000
exit

/* egress routing, and protection */

R1,R2,R6,R7
!
set policy-options as-path LONGER-THAN-10AS ".{10,}"
set policy-options as-path P1-ORIGINATED "^100$"
set policy-options as-path P2-ORIGINATED "^200$"
set policy-options as-path C1-ORIGINATED "^65001$"
set policy-options as-path C2-ORIGINATED "^65002$"
set policy-options as-path C4-ORIGINATED "^65004$"
set policy-options as-path-group T1-PREFERRED-ASN as-path AS301 ".* 301 .*"
set policy-options as-path-group T1-PREFERRED-ASN as-path AS302 ".* 303 .*"
set policy-options as-path-group T2-PREFERRED-ASN as-path AS303 ".* 302 .*"
set policy-options as-path-group T2-PREFERRED-ASN as-path AS304 ".* 304 .*"
set policy-options as-path-group T2-PREFERRED-ASN as-path AS305 ".* 304 .*"

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

R1
!
edit policy-options policy-statement C1-IN
set term DEFAULT from protocol bgp
set term DEFAULT from as-path C1-ORIGINATED
set term DEFAULT then local-preference 3000
set term DEFAULT then accept
set term DENY-ALL then reject
exit
edit policy-options policy-statement P1-IN
set term DEFAULT from protocol bgp
set term DEFAULT from as-path P1-ORIGINATED
set term DEFAULT then local-preference 2000
set term DEFAULT then accept
set term DENY-ALL then reject
exit
edit policy-options policy-statement T1-IN
set term 1 from protocol bgp
set term 1 from as-path-group T1-PREFERRED-ASN
set term 1 then local-preference 1010
set term 1 then accept
set term DEFAULT from protocol bgp
set term DEFAULT then local-preference 1000
set term DEFAULT then accept
exit
edit policy-options policy-statement T2-IN

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
251
252 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set term 1 from protocol bgp

set term 1 from as-path LONGER-THAN-10AS
set term 1 then reject
set term 2 from protocol bgp
set term 2 from as-path-group T2-PREFERRED-ASN
set term 2 then local-preference 1010
set term 2 then accept
set term DEFAULT from protocol bgp
set term DEFAULT then local-preference 1000
set term DEFAULT then accept
exit
edit protocols bgp group CUSTOMER
set neighbor 150.1.119.2 import C1-IN
set neighbor 2016:150:1:119::2 import C1-IN
exit
edit protocols bgp group PEER
set neighbor 150.1.100.2 import P1-IN
set neighbor 2016:150:1:100::2 import P1-IN
exit
edit protocols bgp group TRANSIT
set neighbor 111.1.120.2 import T1-IN
set neighbor 2016:111:1:120::2 import T1-IN
set neighbor 222.1.106.2 import T2-IN
set neighbor 2016:222:1:106::2 import T2-IN
exit

R2
!
edit policy-options policy-statement C2-IN
set term DEFAULT from protocol bgp
set term DEFAULT from as-path C2-ORIGINATED
set term DEFAULT then local-preference 3000
set term DEFAULT then accept
set term DENY-ALL then reject
exit
edit policy-options policy-statement P1-IN
set term DEFAULT from protocol bgp
set term DEFAULT from as-path P1-ORIGINATED
set term DEFAULT then local-preference 2000
set term DEFAULT then accept
set term DENY-ALL then reject
exit
edit policy-options policy-statement P2-IN
set term DEFAULT from protocol bgp
set term DEFAULT from as-path P2-ORIGINATED
set term DEFAULT then local-preference 2000
set term DEFAULT then accept
set term DENY-ALL then reject
exit
edit policy-options policy-statement T2-IN

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

set term 1 from protocol bgp
set term 1 from as-path LONGER-THAN-10AS
set term 1 then reject
set term 2 from protocol bgp
set term 2 from as-path-group T2-PREFERRED-ASN
set term 2 then local-preference 1010
set term 2 then accept
set term DEFAULT from protocol bgp
set term DEFAULT then local-preference 1000
set term DEFAULT then accept
exit
edit protocols bgp group PEER
set neighbor 150.1.113.2 import P1-IN damping
set neighbor 2016:150:1:113::2 import P1-IN damping
set neighbor 150.1.101.2 import P2-IN
set neighbor 2016:150:1:101::2 import P2-IN
exit
edit protocols bgp group TRANSIT
set neighbor 222.1.123.2 import T2-IN
set neighbor 2016:222:1:123::2 import T2-IN
exit
edit protocols bgp group CUSTOMER
set neighbor 150.1.102.2 import C2-IN
set neighbor 2016:150:1:102::2 import C2-IN
exit

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
252
253 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

!
edit policy-options policy-statement C4-IN
set term DEFAULT from protocol bgp
set term DEFAULT from as-path C4-ORIGINATED
set term DEFAULT then local-preference 3000
set term DEFAULT then accept
set term DENY-ALL then reject
exit
edit protocols bgp group CUSTOMER
set neighbor 150.1.107.2 import C4-IN
exit

R7
!
edit policy-options policy-statement T1-IN
set term 1 from protocol bgp
set term 1 from as-path-group T1-PREFERRED-ASN
set term 1 then local-preference 1010
set term 1 then accept
set term DEFAULT from protocol bgp
set term DEFAULT then local-preference 1000
set term DEFAULT then accept
exit
edit protocols bgp group TRANSIT
set neighbor 111.1.105.2 import T1-IN
set neighbor 2016:111:1:105::2 import T1-IN
exit

/* BGP Flap Damping */

R1
!
edit protocols bgp group PEER
set neighbor 150.1.100.2 damping
set neighbor 2016:150:1:100::2 damping
exit

R2
!
edit policy-options policy-statement P2-DAMPING
set term 1 then damping AGGRESSIVE
exit
edit policy-options damping AGGRESSIVE
set suppress 2500
set half-life 30
set reuse 500
exit
edit protocols bgp group PEER
set neighbor 150.1.113.2 damping
set neighbor 2016:150:1:113::2 damping

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

delete neighbor 150.1.101.2 import
set neighbor 150.1.101.2 import [P2-DAMPING P2-IN]
delete neighbor 2016:150:1:101::2 import
set neighbor 2016:150:1:101::2 import [P2-DAMPING P2-IN]
exit

Task 4 (3 points). Implement iBGP routing policies to help pin-point synthetic test traffic flows generated
in task 5, topic 1 via transit links that the flows track individually. For example: if flow destined to
123.0.1.1 is intended to track Internet connectivity out of transit link R1-T1, the routing policies need to
ensure that the flow always goes via T1-R1 to reach the destination 123.0.1.1 regardless of whether via
R1-T1 is the best/shortest path or not.
R4,R5
!
edit routing-options static
set route 123.0.1.1/32 next-hop 111.1.120.2 resolve community no-export tag 999
set route 123.0.2.1/32 next-hop 111.1.105.2 resolve community no-export tag 999
set route 123.0.3.1/32 next-hop 222.1.106.2 resolve community no-export tag 999
set route 123.0.4.1/32 next-hop 222.1.123.2 resolve community no-export tag 999
exit
edit policy-options policy-statement MONITOR-ROUTES
set term 1 from protocol static
set term 1 from tag 999

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
253
254 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

set term 1 then accept

exit
set protocol bgp group IBGP export MONITOR-ROUTES
set protocol bgp group IBGP-RR export MONITOR-ROUTES

R1
!
edit policy-options policy-statement WAN-EXITS
set term 1 from protocol direct
set term 1 from route-filter 111.1.120.0/30 exact
set term 1 from route-filter 222.1.106.0/30 exact
set term 1 then accept
exit
set protocol bgp group IBGP export WAN-EXITS

R2
!
edit policy-options policy-statement WAN-EXITS
set term 1 from protocol direct
set term 1 from route-filter 222.1.123.0/30 exact
set term 1 then accept
exit
set protocol bgp group IBGP export WAN-EXITS

R7
!
edit policy-options policy-statement WAN-EXITS
set term 1 from protocol direct
set term 1 from route-filter 111.1.105.0/30 exact
set term 1 then accept
exit
set protocol bgp group IBGP export WAN-EXITS

Verification
Task 1. The first step is to ensure all iBGP neighbourships are Established and also iBGP is installed as a
client of BFD which verifies forwarding path and liberates BGP from reliance upon OSPF for notification
of device failure. BGP no longer needs to rely on event-driven or periodic next-hop scanning. The
ultimate outcome is to improve convergence of iBGP by rapidly detecting BGP neighbour failure. You
may notice that the expression of ASN is in 32-bit form: 1.57920, in order for this to be displayed
correctly we would need statement asdot-notation under routing-options stanza.
lab@VMX-R4> show bgp summary | match 1.57920
150.1.1.1 1.57920 310 333 0 0 1:57:41 Establ
150.1.1.2 1.57920 300 337 0 0 1:57:38 Establ
150.1.1.3 1.57920 263 353 0 0 1:57:40 Establ

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

150.1.1.5 1.57920 352 368 0 0 1:57:40 Establ
150.1.1.6 1.57920 275 354 0 0 1:57:46 Establ
150.1.1.7 1.57920 277 355 0 0 1:57:44 Establ
150.1.1.8 1.57920 270 381 0 0 1:57:53 Establ

lab@VMX-R5> show bgp summary | match 1.57920

150.1.1.1 1.57920 314 327 0 0 1:58:06 Establ
150.1.1.2 1.57920 298 332 0 0 1:57:59 Establ
150.1.1.3 1.57920 262 345 0 0 1:57:59 Establ
150.1.1.4 1.57920 371 349 0 0 1:58:03 Establ
150.1.1.6 1.57920 274 335 0 0 1:58:04 Establ
150.1.1.7 1.57920 278 341 0 0 1:58:23 Establ
150.1.1.8 1.57920 272 366 0 0 1:58:19 Establ

lab@VMX-R5> show bfd session address 150.1.1.2 detail

Detect Transmit
Address State Interface Time Interval Multiplier
150.1.1.2 Up 1.000 0.250 3
Client RSVP-OAM, TX interval 0.050, RX interval 0.050
Session up time 01:58:02
Local diagnostic None, remote diagnostic NbrSignal
Remote state Up, version 1
Session type: Multi hop BFD
Detect Transmit
Address State Interface Time Interval Multiplier
150.1.1.2 Up 1.000 0.250 4
Client BGP, TX interval 0.250, RX interval 0.250

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
254
255 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

Session up time 01:58:52

Local diagnostic None, remote diagnostic NbrSignal
Remote state Up, version 1
Session type: Multi hop BFD

This task presents redundant route reflection setup with two route reflectors R4, R5 configured with
different Cluster-IDs. The downside of that is the effect on other routers’ memory since other routers
would need to store double amount of routes. However nowadays memory is no longer a big problem
for carrier-grade routers, this disadvantage is becoming lesser. For the relationship between the two
route reflectors R4, R5, we simply configure them as non-client iBGP.

Another point is for iBGP route propagation, by default a BGP route will be suppressed from
propagation in the case it is not selected as the active route due to a better available IGP path even if
the BGP route is the best BGP path. In order to override this behaviour, we can use statement
advertise-inactive under protocols bgp stanza.

Task 2. Apart from regular IPv4 routing/switching between ASN 1.57920 and external ASNs, task 2
requires IPv6 routing/forwarding over MPLS domain to be configured so that customers can have IPv6
reachability to peers and transits. This refers to 6PE implementation for Service Provider Network which
requires the following:

• family inet6 labeled-unicast between iBGP neighbours to allocate labels for IPv6 prefixes over
IPv4 iBGP sessions so that we don't need to enable native IPv6 iBGP sessions in the core
network. This is followed by explicit-null keyword which will advertise MPLS label of "2"
indicating v6 in MPLS payload. Note: this keyword being set here is different from the same
keyword used in commands set protocols ldp explicit-null or set protocols mpls explicit-
null in which MPLS label will be advertised as "3" indicating PHP hop to not pop out the outer
label.
o Since our BGP implementation does require IPv4 routing/switching, we would need to
enable family inet unicast along family inet6 labeled-unicast, because without it
only the latter is activated between the routers.
• set protocols mpls ipv6-tunneling, we convert IPv4 next-hop being routers’ loopback address

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

in table inet.3 into IPv4-mapped IPv6 next-hop and install them into table inet6.3 to resolve and
forward label-switched MPLS frames which encapsulate IPv6 packets inside.
o But since the MPLS environment of this whole practice lab is constructed by two LDP
islands along an RSVP domain, there are some special configurations to make 6PE work
here.
o R4 and R5 in RSVP domain do not have direct LSPs with R1 in an LDP island so their
inet.3 tables do not directly have R1’s loopback0 and hence their inet6.3 tables do not
directly have IPv4-mapped IPv6 address version of R1’s loopback0. This will break BGP
resolution such that R4 and R5 will not accept IPv6 routes advertised by R1 through the
IPv4 iBGP sessions (remember that we do not configure native IPv6 peering to avoid
doubling the amount of BGP sessions).
o Therefore we need to artificially create such IPv4-mapped IPv6 address version of R1’s
loopback0 in R4 and R5’s table inet6.3 by using rib-group that seeds R1’s loopback0
from table inet.0 and import into table inet6.3. We do similarly for R8’s loopback0 even
though it is not required as R8 does not have any IPv6 peers.

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
255
256 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

o Vice versa, we would need to artificially create IPv4-mapped IPv6 address version of R4
and R5’s loopback0s in R1’s table inet6.3 by using rib-group that seeds R4 and R5’s
loopback0s from table inet.0 and import into table inet6.3. This is for the resolution of
the IPv6 supernet 2016:150:1::/48 that R4 and R5 originate. We do similarly on R8 even
though it is not required as R8 does not have any IPv6 peers.
• family inet6 on all core-facing interfaces, this is already configured as part of initial
configurations. There is no need for specific IPv6 address to be configured, but instead just the
activation of the IPv6 AFI on the interfaces.

By the end of task 2, we should test reachability of IPv4/IPv6 routing/switching between customers,
peers and transits. However remember to test it again after policies from tasks 4,5 are in place to ensure
we don’t accidentially filter any test prefix. Below are IPv4/IPv6 ping tests from C4 to other customers,
peers and upstream transit provider of the Service Provider Network:
lab@VMX-VR> ping rapid routing-instance C4 source 170.1.240.1 100.0.0.1
PING 100.0.0.1 (100.0.0.1): 56 data bytes
!!!!!
--- 100.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 29.682/29.967/30.265/0.191 ms

lab@VMX-VR> ping rapid routing-instance C4 source 170.1.240.1 111.0.0.1

PING 111.0.0.1 (111.0.0.1): 56 data bytes
!!!!!
--- 111.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 29.879/29.957/30.141/0.099 ms

lab@VMX-VR> ping rapid routing-instance C4 source 170.1.240.1 170.1.210.1

PING 170.1.210.1 (170.1.210.1): 56 data bytes
!!!!!
--- 170.1.210.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 29.794/29.945/30.122/0.109 ms

lab@VMX-VR> ping rapid routing-instance C4 source 170.1.240.1 200.0.0.1

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

lab@VMX-VR> ping rapid routing-instance C4 source 170.1.240.1 222.0.0.1
PING 222.0.0.1 (222.0.0.1): 56 data bytes
!!!!!
--- 222.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 24.650/25.924/30.018/2.052 ms

lab@VMX-VR> ping rapid routing-instance C4 source 2016:170:1:240::1 2016:100::1

PING6(56=40+8+8 bytes) 2016:170:1:240::1 --> 2016:100::1
!!!!!
--- 2016:100::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 34.746/34.914/35.110/0.117 ms

lab@VMX-VR> ping rapid routing-instance C4 source 2016:170:1:240::1 2016:111::1

PING6(56=40+8+8 bytes) 2016:170:1:240::1 --> 2016:111::1
!!!!!
--- 2016:111::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 29.786/29.909/30.009/0.073 ms

lab@VMX-VR> ping rapid routing-instance C4 source 2016:170:1:240::1 2016:170:1:210::1

PING6(56=40+8+8 bytes) 2016:170:1:240::1 --> 2016:170:1:210::1
!!!!!
--- 2016:170:1:210::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
256
257 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

round-trip min/avg/max/std-dev = 34.601/35.913/39.759/1.939 ms

lab@VMX-VR> ping rapid routing-instance C4 source 2016:170:1:240::1 2016:200::1

PING6(56=40+8+8 bytes) 2016:170:1:240::1 --> 2016:200::1
!!!!!
--- 2016:200::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 29.781/29.916/30.010/0.092 ms

lab@VMX-VR> ping rapid routing-instance C4 source 2016:170:1:240::1 2016:222::1

PING6(56=40+8+8 bytes) 2016:170:1:240::1 --> 2016:222::1
!!!!!
--- 2016:222::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 34.794/34.931/35.184/0.134 ms

Below are IPv4/IPv6 ping tests from C4 to the Service Provider Network:
lab@VMX-VR> ping rapid routing-instance C4 source 170.1.240.1 150.1.1.1
PING 150.1.1.1 (150.1.1.1): 56 data bytes
!!!!!
--- 150.1.1.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 24.802/24.934/25.007/0.071 ms

lab@VMX-VR> ping rapid routing-instance C4 source 170.1.240.1 150.1.1.2

PING 150.1.1.2 (150.1.1.2): 56 data bytes
!!!!!
--- 150.1.1.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 19.679/19.959/20.322/0.210 ms

lab@VMX-VR> ping rapid routing-instance C4 source 170.1.240.1 150.1.1.3

PING 150.1.1.3 (150.1.1.3): 56 data bytes
!!!!!
--- 150.1.1.3 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 24.800/24.936/25.013/0.073 ms

lab@VMX-VR> ping rapid routing-instance C4 source 170.1.240.1 150.1.1.4

lab@VMX-VR> ping rapid routing-instance C4 source 170.1.240.1 150.1.1.5

PING 150.1.1.5 (150.1.1.5): 56 data bytes
!!!!!

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

--- 150.1.1.5 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 17.946/19.951/21.984/1.281 ms

lab@VMX-VR> ping rapid routing-instance C4 source 170.1.240.1 150.1.1.6

PING 150.1.1.6 (150.1.1.6): 56 data bytes
!!!!!
--- 150.1.1.6 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 9.866/9.963/10.130/0.091 ms

lab@VMX-VR> ping rapid routing-instance C4 source 170.1.240.1 150.1.1.7

PING 150.1.1.7 (150.1.1.7): 56 data bytes
!!!!!
--- 150.1.1.7 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 14.665/14.956/15.243/0.209 ms

lab@VMX-VR> ping rapid routing-instance C4 source 170.1.240.1 150.1.1.8

PING 150.1.1.8 (150.1.1.8): 56 data bytes
!!!!!
--- 150.1.1.8 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 14.786/15.002/15.142/0.120 ms

lab@VMX-VR> ping rapid routing-instance C4 source 2016:170:1:240::1 2016:150:1:1::1

PING6(56=40+8+8 bytes) 2016:170:1:240::1 --> 2016:150:1:1::1

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
257
258 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

!!!!!
--- 2016:150:1:1::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 29.756/29.931/30.017/0.091 ms

lab@VMX-VR> ping rapid routing-instance C4 source 2016:170:1:240::1 2016:150:1:1::2

PING6(56=40+8+8 bytes) 2016:170:1:240::1 --> 2016:150:1:1::2
!!!!!
--- 2016:150:1:1::2 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 24.663/24.924/25.068/0.138 ms

lab@VMX-VR> ping rapid routing-instance C4 source 2016:170:1:240::1 2016:150:1:1::3

PING6(56=40+8+8 bytes) 2016:170:1:240::1 --> 2016:150:1:1::3
!!!!!
--- 2016:150:1:1::3 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 29.755/30.004/30.290/0.195 ms

lab@VMX-VR> ping rapid routing-instance C4 source 2016:170:1:240::1 2016:150:1:1::4

PING6(56=40+8+8 bytes) 2016:170:1:240::1 --> 2016:150:1:1::4
!!!!!
--- 2016:150:1:1::4 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 19.737/19.917/20.034/0.103 ms

lab@VMX-VR> ping rapid routing-instance C4 source 2016:170:1:240::1 2016:150:1:1::5

PING6(56=40+8+8 bytes) 2016:170:1:240::1 --> 2016:150:1:1::5
!!!!!
--- 2016:150:1:1::5 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 24.487/24.882/25.042/0.201 ms

lab@VMX-VR> ping rapid routing-instance C4 source 2016:170:1:240::1 2016:150:1:1::6

PING6(56=40+8+8 bytes) 2016:170:1:240::1 --> 2016:150:1:1::6
!!!!!
--- 2016:150:1:1::6 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 14.869/14.938/15.029/0.052 ms

lab@VMX-VR> ping rapid routing-instance C4 source 2016:170:1:240::1 2016:150:1:1::7

PING6(56=40+8+8 bytes) 2016:170:1:240::1 --> 2016:150:1:1::7
!!!!!
--- 2016:150:1:1::7 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 19.693/19.935/20.064/0.134 ms

lab@VMX-VR> ping rapid routing-instance C4 source 2016:170:1:240::1 2016:150:1:1::8

PING6(56=40+8+8 bytes) 2016:170:1:240::1 --> 2016:150:1:1::8
!!!!!

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

--- 2016:150:1:1::8 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 19.707/20.919/24.818/1.955 ms

Task 3. This task discusses BGP routing policies for both ingress and egress directions and stability
enhancement.

• For ingress direction, it’s easy to realise that the four prefixes mentioned in the question are
actually part of two subnets 150.1.0.0/17 and 150.1.128.0/17 derived from the supernet
150.1.0.0/16. To achieve the inbound preference, you can use either tuning MED value or
prepending AS_PATH accordingly. Since there is no preference requirement between T1 and
T2’s transit links, this task chooses tuning MED method with value of 500 for primary location
and 1000 for secondary location. Note that this method would not work between transit links
that belong to different ASNs. Also we would need to impose the two subnets 150.1.0.0/17 and
150.1.128.0/17 and the best locations to do so would be R4 and R5.
• For the first egress routing requirement, we simply create a system that has got the priorities of
customers > peers > transits with LOCAL_PREFERENCE ‘baseline’ values of 3000, 2000, 1000

http://www.inetzero.com - Copyright 2017 iNET ZERO, The Netherlands. All rights reserved
258
259 iNET ZERO – JNCIE-SP Full-Scale Labs, Volume 1 – Version 1.0

respectively and assign those values to routes learnt from customers, peers and transits
accordingly. For the second requirement we leverage feature policy-options as-path-group to
group multiple ASNs into a batch and tune the LOCAL_PREFERENCE to a value that is higher than
the baseline value of 1000 to indicate preferred exit transit points.
lab@VMX-R7> show route aspath-regex ".* 65001 .*"

inet.0: 160 destinations, 296 routes (159 active, 0 holddown, 1 hidden)

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

170.1.210.0/24 *[BGP/170] 01:44:50, localpref 3000, from 150.1.1.4

AS path: 65001 I
> to 150.1.57.5 via ge-0/0/6.0, label-switched-path R7-TO-R3
to 150.1.67.6 via ge-0/0/8.0, label-switched-path R7-TO-R3
[BGP/170] 01:44:56, localpref 3000, from 150.1.1.5
AS path: 65001 I
> to 150.1.57.5 via ge-0/0/6.0, label-switched-path R7-TO-R3
to 150.1.67.6 via ge-0/0/8.0, label-switched-path R7-TO-R3
[BGP/170] 00:11:36, localpref 1000
AS path: 111 65001 I
> to 111.1.105.2 via ge-0/0/4.105
<snip>

lab@VMX-R1> show route aspath-regex ".* (301|303) .*" table inet.0

inet.0: 163 destinations, 300 routes (163 active, 0 holddown, 1 hidden)

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

30.1.0.0/16 *[BGP/170] 00:48:49, localpref 1010

AS path: 111 123 301 I
> to 111.1.120.2 via ge-0/0/4.120
[BGP/170] 00:48:49, localpref 1010, from 150.1.1.5
AS path: 111 123 301 I
> to 150.1.13.3 via ge-0/0/6.0, Push 299904
[BGP/170] 00:48:50, localpref 1000
AS path: 222 123 301 I
> to 222.1.106.2 via ge-0/0/4.106
<snip>

lab@VMX-R1> show route aspath-regex ".* (302|304) .*" table inet.0

inet.0: 163 destinations, 300 routes (163 active, 0 holddown, 1 hidden)

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

30.2.0.0/16 *[BGP/170] 00:47:29, localpref 1010

AS path: 222 123 302 I
> to 222.1.106.2 via ge-0/0/4.106

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

[BGP/170] 00:47:28, localpref 1010, from 150.1.1.4
AS path: 222 123 302 I
> to 150.1.12.2 via ge-0/0/2.0, Push 0
[BGP/170] 00:47:28, localpref 1000
AS path: 111 123 302 I
> to 111.1.120.2 via ge-0/0/4.120
<snip>

• The next point is the use of BGP AS_PATH Regular Expression which you can find more details in
URL https://www.juniper.net/techpubs/en_US/junos/topics/usage-guidelines/policy-
configuring-as-path-regular-expressions-to-use-as-routing-policy-match-conditions.html. In
order to specify routes with or more than X occurences of ASN, we use the notion of “.{X,}”.
Let’s check to see if our regular expression could have caught any prefix with AS_PATH length
that is longer than 10:
lab@VMX-R1> show route receive-protocol bgp 222.1.106.2 table inet.0 hidden

inet.0: 164 destinations, 303 routes (164 active, 0 holddown, 2 hidden)

Prefix Nexthop MED Lclpref AS path
8.0.0.0/8 222.1.106.2 222 123 549 8973 2168
5488 2437 5489 6543 8 I

9.0.0.0/8 222.1.106.2 222 123 1125 2678 35122

42516 54754 6125 751 8623 9 I

• The next feature is called BGP Flap Damping and it is used for suppressing flapping BGP routes
until they become more stable, protecting the stability of BGP sessions and routing domain from
unnecessary excessive routing updates usually caused by BGP routes that are
added/removed/modified so frequently. BGP Flap Damping reduces the number of BGP updates
by marking routes as ineligible for selection as active or preferable routes. With such markings,
it could lead to some delay, or suppression, in the propagation of route information, but the
result is increased network stability.
o This feature can be simply turned on with keyword damping at the neighbor statement of
protocols bgp stanza. However this means all default values would be applied.
o In scenario like this task provides, we may want to do BGP Flap Damping more
aggressively. This is when we need an import policy-statement at the neighbor
statement of protocols bgp stanza, specifying the exact name of Damping setting.
o Note that best practices indicate that this import policy-statement should be the first
one before any other route manipulation import policies.
o The Damping setting can be configured with statement policy-options damping. There
are three main knobs: suppress (value): default is 3000; to dampen more aggressively
set this to be smaller than 3000 so that prefix is suppressed sooner; half-life (min):
default is 15min and to dampen more aggressively we need to set this value longer than
15min; reuse (value): default is 750; to dampen more aggressively set this to be smaller
than 750 so that prefix must stay stable for longer.

Task 4. This task facilitates the routing paths for the monitoring probes created in topic 1. The objective
is to ensure that each monitoring probe goes to the destination through the transit link that the probe
intends to track. Therefore we need to pin-point the path of the probe in a scalable way (on an AS-wide
basis). To achieve this we simply create static routes on route reflectors R4, R5 with next-hop addresses
being the provider routers’ on the other side of the transit links and at the same time we announce
transit links’ subnet into BGP on the edge routers accordingly. The static routes should be tagged with a
value (e.g. 999) to distinguish them from any regular destination paths. They also should have

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

community no-export to ensure that they’re not leaked outside the Service Provider network, otherwise
they have tamper with routing of other customers, peers or transits if such networks still accept /32
routes even though it’s unlikely.

Now let’s check to see if R6 has got the /32 static routes corresponding to probes’ destinations with the
statically configured next-hops, overriding the regular destination-based routing.
lab@VMX-R6> show route receive-protocol bgp 150.1.1.4 | match "Prefix|123.0.[1234].1"
Prefix Nexthop MED Lclpref AS path
* 123.0.1.1/32 111.1.120.2 100 I
* 123.0.2.1/32 111.1.105.2 100 I
* 123.0.3.1/32 222.1.106.2 100 I
* 123.0.4.1/32 222.1.123.2 100 I

We can see that the next-hops for the corresponding /24 subnets, which are calculated by normal BGP
best path selection, are different from the ones of the /32 routes that we programmed.
lab@VMX-R6> show route receive-protocol bgp 150.1.1.4 | match "Prefix|123.0.[1234].0"
Prefix Nexthop MED Lclpref AS path
123.0.1.0/24 150.1.1.2 1000 222 123 I
123.0.2.0/24 150.1.1.2 1000 222 123 I

123.0.3.0/24 150.1.1.2 1000 222 123 I

123.0.4.0/24 150.1.1.2 1000 222 123 I

lab@VMX-R6> show route receive-protocol bgp 150.1.1.5 | match "Prefix|123.0.[1234].0"

Prefix Nexthop MED Lclpref AS path
* 123.0.1.0/24 150.1.1.7 1000 111 123 I
* 123.0.2.0/24 150.1.1.7 1000 111 123 I
* 123.0.3.0/24 150.1.1.7 1000 111 123 I
* 123.0.4.0/24 150.1.1.7 1000 111 123 I

Now let’s ensure that the probes are actually going through the programmed next-hops (paths) to track
connectivity of each transit link as expected:
lab@VMX-R6> traceroute 123.0.1.1 source 150.1.1.6
traceroute to 123.0.1.1 (123.0.1.1) from 150.1.1.6, 30 hops max, 40 byte packets
1 150.1.46.4 (150.1.46.4) 106.991 ms 5.473 ms 3.811 ms
MPLS Label=299792 CoS=0 TTL=1 S=0
MPLS Label=299776 CoS=0 TTL=1 S=1
2 150.1.24.2 (150.1.24.2) 4.076 ms 4.531 ms 3.846 ms
MPLS Label=299776 CoS=0 TTL=1 S=1
3 150.1.12.1 (150.1.12.1) 4.413 ms 125.776 ms 83.609 ms
4 111.1.120.2 (111.1.120.2) 83.097 ms 13.046 ms 13.803 ms
5 123.0.1.1 (123.0.1.1) 14.118 ms 12.814 ms 13.064 ms

lab@VMX-R6> traceroute 123.0.2.1 source 150.1.1.6

traceroute to 123.0.2.1 (123.0.2.1) from 150.1.1.6, 30 hops max, 40 byte packets
1 150.1.67.7 (150.1.67.7) 14.880 ms 15.527 ms 14.573 ms
2 111.1.105.2 (111.1.105.2) 20.066 ms 20.150 ms 14.958 ms
3 123.0.2.1 (123.0.2.1) 20.070 ms 20.420 ms 20.333 ms

lab@VMX-R6> traceroute 123.0.3.1 source 150.1.1.6

traceroute to 123.0.3.1 (123.0.3.1) from 150.1.1.6, 30 hops max, 40 byte packets
1 150.1.46.4 (150.1.46.4) 4.378 ms 5.105 ms 4.631 ms
MPLS Label=299792 CoS=0 TTL=1 S=0
MPLS Label=299776 CoS=0 TTL=1 S=1
2 150.1.24.2 (150.1.24.2) 3.827 ms 113.946 ms 70.965 ms
MPLS Label=299776 CoS=0 TTL=1 S=1
3 150.1.12.1 (150.1.12.1) 94.904 ms 140.170 ms 72.992 ms
4 222.1.106.2 (222.1.106.2) 12.719 ms 10.932 ms 11.208 ms
5 123.0.3.1 (123.0.3.1) 8.728 ms 129.741 ms 92.543 ms

lab@VMX-R6> traceroute 123.0.4.1 source 150.1.1.6

traceroute to 123.0.4.1 (123.0.4.1) from 150.1.1.6, 30 hops max, 40 byte packets
1 150.1.46.4 (150.1.46.4) 5.662 ms 4.210 ms 2.835 ms
MPLS Label=299792 CoS=0 TTL=1 S=1
2 150.1.24.2 (150.1.24.2) 3.686 ms 84.850 ms 221.230 ms
3 222.1.123.2 (222.1.123.2) 10.309 ms 13.995 ms 12.163 ms
4 123.0.4.1 (123.0.4.1) 10.554 ms 10.009 ms 11.436 ms

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

Topic 5: VPN
Total Points: 30

• CE1-1: 172.30.1[0-9].1
• CE1-2: 172.30.2[0-9].1
• CE1-3: 172.30.3[0-9].1
• CE1-6: 172.30.15[0-9].1
R1,R2,R4,R5,R8
!
set protocols bgp group IBGP family inet-vpn unicast

R4,R5
!
set protocols bgp group IBGP-RR family inet-vpn unicast
edit policy-options policy-statement INET0-TO-INET3-INET63
set term LDP-ROUTERS-L3VPN from protocol ospf
set term LDP-ROUTERS-L3VPN from route-filter 150.1.1.1/32 exact
set term LDP-ROUTERS-L3VPN from route-filter 150.1.1.8/32 exact
set term LDP-ROUTERS-L3VPN to rib inet.3
set term LDP-ROUTERS-L3VPN then accept
insert term LDP-ROUTERS-L3VPN before term DENY-ALL
exit

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

exit
edit routing-instance VPN1-SPOKE
set instance-type vrf
set vrf-import VPN1-SPOKE-IMPORT
set vrf-export DENY-ALL
set interface ge-0/0/4.118
set interface lo0.1
set protocols ospf area 0.0.0.0 interface ge-0/0/4.118
set protocols ospf export BGP-TO-OSPF
set protocols ospf domain-vpn-tag 0
exit
edit policy-options policy-statement BGP-TO-OSPF
set term 1 from protocol bgp
set term 1 then accept
exit
edit policy-options policy-statement VPN1-HUB-EXPORT
set term 1 from protocol [direct ospf]
set term 1 then community set VPN1-HUB-RT
set term 1 then accept
exit
edit policy-options policy-statement VPN1-SPOKE-IMPORT
set term 1 from protocol bgp
set term 1 from community VPN1-SPOKE-RT
set term 1 then accept
exit
edit policy-options policy-statement DENY-ALL
set term DENY-ALL then reject
exit

edit policy-options policy-statement INET0-TO-INET3-INET63

set term RR-ROUTERS-L3VPN from protocol ospf
set term RR-ROUTERS-L3VPN from route-filter 150.1.1.4/32 exact
set term RR-ROUTERS-L3VPN from route-filter 150.1.1.5/32 exact
set term RR-ROUTERS-L3VPN to rib inet.3
set term RR-ROUTERS-L3VPN then accept
insert term RR-ROUTERS-L3VPN before term DENY-ALL
exit
set policy-options community VPN1-HUB-RT member target:18:3310
set policy-options community VPN1-SPOKE-RT member target:18:3311

R2
!
set routing-options route-distinguisher-id 150.1.1.2
edit routing-instance VPN1-SPOKE
set instance-type vrf
set vrf-import VPN1-SPOKE-IMPORT
set vrf-export VPN1-SPOKE-EXPORT
set interface ge-0/0/4.103
set interface lo0.1
set protocols ospf area 0.0.0.0 interface ge-0/0/4.103
set protocols ospf export BGP-TO-OSPF
exit
edit policy-options policy-statement BGP-TO-OSPF
set term 1 from protocol bgp
set term 1 then accept
exit
edit policy-options policy-statement VPN1-SPOKE-EXPORT
set term 1 from protocol [direct ospf]
set term 1 then community add VPN1-SPOKE-RT
set term 1 then accept
exit
edit policy-options policy-statement VPN1-SPOKE-IMPORT
set term 1 from protocol bgp
set term 1 from community VPN1-HUB-RT
set term 1 then accept
exit
set policy-options community VPN1-HUB-RT member target:18:3310
set policy-options community VPN1-SPOKE-RT member target:18:3311

R7
!
set routing-options route-distinguisher-id 150.1.1.7
set protocols bgp group IBGP family inet-vpn unicast
edit routing-instance VPN1-SPOKE
set instance-type vrf
set vrf-import VPN1-SPOKE-IMPORT
set vrf-export VPN1-SPOKE-EXPORT
set interface ge-0/0/4.140
set protocols ospf area 0.0.0.0 interface ge-0/0/4.140

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

set protocols ospf export BGP-TO-OSPF
set protocols ospf domain-vpn-tag 0
exit
edit policy-options policy-statement BGP-TO-OSPF
set term 1 from protocol bgp
set term 1 then accept
exit
edit policy-options policy-statement VPN1-SPOKE-EXPORT
set term 1 from protocol [direct ospf]
set term 1 then community add VPN1-SPOKE-RT
set term 1 then accept
exit
edit policy-options policy-statement VPN1-SPOKE-IMPORT
set term 1 from protocol bgp
set term 1 from community VPN1-HUB-RT
set term 1 then accept
exit
set policy-options community VPN1-HUB-RT member target:18:3310
set policy-options community VPN1-SPOKE-RT member target:18:3311

R8
!
set routing-options route-distinguisher-id 150.1.1.8
edit routing-instance VPN1-SPOKE
set instance-type vrf
set vrf-import VPN1-SPOKE-IMPORT
set vrf-export VPN1-SPOKE-EXPORT

set interface ge-0/0/4.112

set interface lo0.1
set protocols ospf area 0.0.0.0 interface ge-0/0/4.112
set protocols ospf export BGP-TO-OSPF
exit
edit policy-options policy-statement BGP-TO-OSPF
set term 1 from protocol bgp
set term 1 then accept
exit
edit policy-options policy-statement VPN1-SPOKE-EXPORT
set term 1 from protocol [direct ospf]
set term 1 then community add VPN1-SPOKE-RT
set term 1 then accept
exit
edit policy-options policy-statement VPN1-SPOKE-IMPORT
set term 1 from protocol bgp
set term 1 from community VPN1-HUB-RT
set term 1 then accept
exit
edit policy-options policy-statement INET0-TO-INET3-INET63
set term RR-ROUTERS-L3VPN from protocol ospf
set term RR-ROUTERS-L3VPN from route-filter 150.1.1.4/32 exact
set term RR-ROUTERS-L3VPN from route-filter 150.1.1.5/32 exact
set term RR-ROUTERS-L3VPN to rib inet.3
set term RR-ROUTERS-L3VPN then accept
insert term RR-ROUTERS-L3VPN before term DENY-ALL
exit
set policy-options community VPN1-HUB-RT member target:18:3310
set policy-options community VPN1-SPOKE-RT member target:18:3311

• CE2-2: 172.30.40.2
• CE2-3: 172.30.40.31
• CE2-4: 172.30.40.4
R2
!
set interface ge-0/0/3 vlan-tagging encapsulation flexible
set interface ge-0/0/3.104 vlan-id 104 encap vlan-vpls
edit routing-instance VPN2

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

set instance-type vpls
set interface ge-0/0/3.104
set protocol vpls encap ethernet-vlan
set protocol vpls vpls-id 200
set protocol vpls neighbor 150.1.1.3
set protocol vpls neighbor 150.1.1.8 backup 150.1.1.6
set protocol vpls no-tunnel-services
exit
set protocols ldp interface lo0.0

R3
!
set interface ge-0/0/3 vlan-tagging encapsulation flexible
set interface ge-0/0/3.104 vlan-id 104 encap vlan-vpls
edit routing-instance VPN2
set instance-type vpls
set interface ge-0/0/3.104
set protocol vpls encap ethernet-vlan
set protocol vpls vpls-id 200
set protocol vpls neighbor 150.1.1.2
set protocol vpls neighbor 150.1.1.8 backup 150.1.1.6
set protocol vpls no-tunnel-services
exit
set protocols ldp interface lo0.0

R6,R8
!

set interface ge-0/0/4 vlan-tagging encapsulation flexible

set interface ge-0/0/4.104 vlan-id 104 encap vlan-vpls
edit routing-instance VPN2
set instance-type vpls
set interface ge-0/0/4.104
set protocol vpls encap ethernet-vlan
set protocol vpls vpls-id 200
set protocol vpls neighbor 150.1.1.2
set protocol vpls neighbor 150.1.1.3
set protocol vpls no-tunnel-services
exit
set protocols ldp interface lo0.0

• CE4-1: 2016:172:30:9[0-9]::1
• CE4-2: 2016:172:30:10[0-9]::1
• CE4-3: 2016:172:30:11[0-9]::1

R4,R5
!
set protocols mpls ipv6-tunneling
set protocols bgp group IBGP family inet6-vpn unicast
set protocols bgp group IBGP-RR family inet6-vpn unicast

R2
!
set protocols mpls ipv6-tunneling
set protocols bgp group IBGP family inet6-vpn unicast
set routing-options route-distinguisher-id 150.1.1.2
edit routing-instance VPN4
set routing-options router-id 150.1.1.2
set instance-type vrf
set vrf-target target:16:3340
set interface ge-0/0/4.128
set protocols bgp group VPN4 type external
set protocols bgp group VPN4 peer-as 65504
set protocols bgp group VPN4 neighbor 2016:172:16:128::2
set protocols bgp group VPN4 as-override

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

exit

R7
!
set protocols mpls ipv6-tunneling
set protocols bgp group IBGP family inet6-vpn unicast
set routing-options route-distinguisher-id 150.1.1.7
edit routing-instance VPN4
set routing-options router-id 150.1.1.7
set instance-type vrf
set vrf-target target:16:3340
set interface ge-0/0/4.127
set interface ge-0/0/4.139
set protocols bgp group VPN4 type external
set protocols bgp group VPN4 peer-as 65504
set protocols bgp group VPN4 neighbor 2016:172:16:127::2
set protocols bgp group VPN4 as-override
set protocols bgp group P3 type external
set protocols bgp group P3 peer-as 300
set protocols bgp group P3 neighbor 2016:172:16:139::2
set protocols bgp group P3 as-override
exit

Task 4 (6 points). Provide Internet Access for VPN1 customer. You are not allowed to use any other
interface between R1 and CE1-1. Ensure that traffic from CE1-2 and CE1-3 to Internet traverse the hub

CE1-1. You can launch ping tests from any participating CE routing-instance on VRF device towards an
Internet address being 123.0.0.1.
R1
!
set routing-options rib-group VPN1-TO-INET0 import-rib [VPN1-HUB.inet.0 inet.0]
set routing-options rib-group VPN1-TO-INET0 import-policy VPN1-TO-INET0
edit routing-instance VPN1-SPOKE
set routing-options static route 0.0.0.0/0 next-table inet.0
set protocols ospf export STATIC-TO-OSPF
set vrf-table-label
exit
edit policy-options policy-statement STATIC-TO-OSPF
set term 1 from protocol static
set term 1 from route-filter 0.0.0.0/0 exact
set term 1 then accept
exit
edit routing-instance VPN1-HUB
set protocols ospf rib-group VPN1-TO-INET0
exit
edit policy-options policy-statement VPN1-TO-INET0
set term 1 from protocol ospf
set term 1 then tag 3310
set term 1 then accept
exit
edit policy-options policy-statement VPN1-TO-GLOBAL
set term 1 from protocol ospf
set term 1 from tag 3310
set term 1 then accept
exit
set protocols bgp group IBGP export VPN1-TO-GLOBAL
set protocols bgp group CUSTOMER export VPN1-TO-GLOBAL
set protocols bgp group PEER export VPN1-TO-GLOBAL
set protocols bgp group TRANSIT export VPN1-TO-GLOBAL
set protocols bgp group TRANSIT neighbor 222.1.106.2 export VPN1-TO-GLOBAL

Verification
Task 1. At first sight, this task looks quite similar to the scenario of MPLS L3VPN Hub-Spoke with OSPF as
PE-CE routing protocol in practice lab 2, topic 5. However the MPLS environment in this current practice
lab is different (with two LDP islands connected across one RSVP domain) so that we need to configure
additional things to make it work. But before we get into that, firstly let’s ensure all OSPF
neighbourships with CE routers are now Full. And then we check routing instance on spoke PE routers
R2 and R5 to see whether they now have VPN routes advertised by the hub PE router being R1 as well as

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

each other’s. Output on R5 is omitted for brevity.
lab@VMX-R1> show ospf neighbor instance VPN1-HUB
Address Interface State ID Pri Dead
172.16.117.2 ge-0/0/4.117 Full 172.30.10.1 128 33

lab@VMX-R1> show ospf neighbor instance VPN1-SPOKE

Address Interface State ID Pri Dead
172.16.118.2 ge-0/0/4.118 Full 172.30.10.1 128 33

lab@VMX-R2> show ospf neighbor instance VPN1-SPOKE

Address Interface State ID Pri Dead
172.16.103.2 ge-0/0/4.103 Full 172.30.20.1 128 36

lab@VMX-R8> show ospf neighbor instance VPN1-SPOKE

Address Interface State ID Pri Dead
172.16.112.2 ge-0/0/4.112 Full 172.30.30.1 128 38

lab@VMX-R8> show route table VPN1-SPOKE.inet.0 active-path | match 172.30

172.30.10.0/24 *[BGP/170] 00:56:44, MED 0, localpref 100, from 150.1.1.4
172.30.11.0/24 *[BGP/170] 00:56:44, MED 0, localpref 100, from 150.1.1.4
172.30.12.0/24 *[BGP/170] 00:56:44, MED 0, localpref 100, from 150.1.1.4
172.30.13.0/24 *[BGP/170] 00:56:44, MED 0, localpref 100, from 150.1.1.4
172.30.14.0/24 *[BGP/170] 00:56:44, MED 0, localpref 100, from 150.1.1.4
172.30.15.0/24 *[BGP/170] 00:56:44, MED 0, localpref 100, from 150.1.1.4
172.30.16.0/24 *[BGP/170] 00:56:44, MED 0, localpref 100, from 150.1.1.4

172.30.17.0/24 *[BGP/170] 00:56:44, MED 0, localpref 100, from 150.1.1.4

172.30.18.0/24 *[BGP/170] 00:56:44, MED 0, localpref 100, from 150.1.1.4
172.30.19.0/24 *[BGP/170] 00:56:44, MED 0, localpref 100, from 150.1.1.4
172.30.20.0/24 *[BGP/170] 00:56:44, MED 0, localpref 100, from 150.1.1.4
172.30.21.0/24 *[BGP/170] 00:56:44, MED 0, localpref 100, from 150.1.1.4
172.30.22.0/24 *[BGP/170] 00:56:44, MED 0, localpref 100, from 150.1.1.4
172.30.23.0/24 *[BGP/170] 00:56:44, MED 0, localpref 100, from 150.1.1.4
172.30.24.0/24 *[BGP/170] 00:56:44, MED 0, localpref 100, from 150.1.1.4
172.30.25.0/24 *[BGP/170] 00:56:44, MED 0, localpref 100, from 150.1.1.4
172.30.26.0/24 *[BGP/170] 00:56:44, MED 0, localpref 100, from 150.1.1.4
172.30.27.0/24 *[BGP/170] 00:56:44, MED 0, localpref 100, from 150.1.1.4
172.30.28.0/24 *[BGP/170] 00:56:44, MED 0, localpref 100, from 150.1.1.4
172.30.29.0/24 *[BGP/170] 00:56:44, MED 0, localpref 100, from 150.1.1.4
172.30.30.0/24 *[OSPF/150] 22:10:49, metric 0, tag 0
172.30.31.0/24 *[OSPF/150] 22:10:49, metric 0, tag 0
172.30.32.0/24 *[OSPF/150] 22:10:49, metric 0, tag 0
172.30.33.0/24 *[OSPF/150] 22:10:49, metric 0, tag 0
172.30.34.0/24 *[OSPF/150] 22:10:49, metric 0, tag 0
172.30.35.0/24 *[OSPF/150] 22:10:49, metric 0, tag 0
172.30.36.0/24 *[OSPF/150] 22:10:49, metric 0, tag 0
172.30.37.0/24 *[OSPF/150] 22:10:49, metric 0, tag 0
172.30.38.0/24 *[OSPF/150] 22:10:49, metric 0, tag 0
172.30.39.0/24 *[OSPF/150] 22:10:49, metric 0, tag 0
<snip>

You may scroll back to practice lab 2, topic 5, task 1 to check for the details of the scenario of MPLS
L3VPN Hub-Spoke with OSPF as PE-CE routing protocol but one important note to remember is we need
to erase domain value with statement domain-vpn-tag 0 at hub site when propagating routes from
Spoke VRF to Hub VRF. By default on PE router’s VRF when redistributing MP-BGP routes into OSPF, all
prefixes are tagged with a domain-tag value to prevent routing loops/feedback when such prefixes
arrive back at the PE router. However in this case, there is no routing loop/feedback, but the intention
to re-advertise back to PE router (Spoke VRF on PE --> Hub CE --> Hub VRF on PE) in order to create
indirect spoke-spoke connectivity across hub (rather than direct spoke-spoke).

Now for the interesting part of this task, you may recall that in topic 4, in order to make 6PE work, we
had to artificially create IPv4-mapped IPv6 address version of R1’s loopback0 in R4 and R5’s table inet6.3
by using rib-group that seeds R1’s loopback0 from table inet.0 and import into table inet6.3. And the
reason is that R4 and R5 in RSVP domain do not have direct LSPs with R1 (in an LDP island) so their inet.3
tables do not directly have R1’s loopback0 and hence their inet6.3 tables do not directly have IPv4-
mapped IPv6 address version of R1’s loopback0, breaking BGP resolution for 6PE prefixes. The same

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

concept applies here for L3VPN scenario but for table inet.3 (instead of table inet6.3 in 6PE scenario).
Since R4 and R5 in RSVP domain do not have direct LSPs with R1 (in an LDP island) so their inet.3 tables
do not directly have R1’s loopback0, breaking BGP resolution for L3VPN prefixes.

• Therefore we need to artificially create such IPv4 address of R1’s loopback0 in R4 and R5’s table
inet.3 by using rib-group that seeds R1’s loopback0 from table inet.0 and import into table
inet.3. We do similarly for R8’s loopback0 because R8 is a PE with both L3VPN and L2VPN
customers.
• Vice versa, we would need to artificially create IPv4 address of R4 and R5’s loopback0s in R1 and
R8’s tables inet.3 by using rib-group that seeds R4 and R5’s loopback0s from table inet.0 and
import into table inet.3.
lab@VMX-R1> show route table inet.3
<snip>
150.1.1.4/32 *[OSPF/10] 22:40:41, metric 200
> to 150.1.12.2 via ge-0/0/2.0
150.1.1.5/32 *[OSPF/10] 22:40:46, metric 200
> to 150.1.13.3 via ge-0/0/6.0
<snip>

lab@VMX-R4> show route table inet.3

<snip>
150.1.1.1/32 *[OSPF/10] 22:42:10, metric 200
> to 150.1.24.2 via ge-0/0/6.0
<snip>
150.1.1.8/32 *[OSPF/10] 01:28:29, metric 200
> to 150.1.46.6 via ge-0/0/7.0
<snip>

Now let’s ensure connectivity between all CE routers of VPN1 in AS 1.57920 is provided and also the
forwarding path between CE1-2 (connecting to R2) and CE1-3 (connecting to R5) actually is across CE1-1
(connecting to R1).
lab@VMX-VR> ping rapid routing-instance CE1-1 source 172.30.10.1 172.30.20.1
PING 172.30.20.1 (172.30.20.1): 56 data bytes
!!!!!
--- 172.30.20.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 19.838/19.962/20.118/0.109 ms

lab@VMX-VR> ping rapid routing-instance CE1-1 source 172.30.10.1 172.30.30.1

lab@VMX-VR> ping rapid routing-instance CE1-2 source 172.30.20.1 172.30.30.1

lab@VMX-VR> traceroute routing-instance CE1-2 source 172.30.20.1 172.30.30.1

traceroute to 172.30.30.1 (172.30.30.1) from 172.30.20.1, 30 hops max, 40 byte packets
1 172.16.103.1 (172.16.103.1) 14.872 ms 14.541 ms 15.844 ms
2 150.1.12.1 (150.1.12.1) 32.375 ms 21.271 ms 24.994 ms
MPLS Label=299824 CoS=0 TTL=1 S=1
3 172.16.117.2 (172.16.117.2) 25.094 ms 24.586 ms 24.769 ms
4 172.16.118.1 (172.16.118.1) 25.014 ms 24.532 ms 25.050 ms
5 150.1.12.2 (150.1.12.2) 54.957 ms 49.632 ms 54.860 ms
MPLS Label=299904 CoS=0 TTL=1 S=0
MPLS Label=16 CoS=0 TTL=1 S=1
6 150.1.24.4 (150.1.24.4) 54.982 ms 49.564 ms 54.953 ms
MPLS Label=301216 CoS=0 TTL=1 S=0

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

MPLS Label=299904 CoS=0 TTL=1 S=0
MPLS Label=16 CoS=0 TTL=2 S=1
7 150.1.46.6 (150.1.46.6) 55.086 ms 54.439 ms 54.917 ms
MPLS Label=299904 CoS=0 TTL=1 S=0
MPLS Label=16 CoS=0 TTL=3 S=1
8 172.30.30.1 (172.30.30.1) 64.958 ms 64.591 ms 54.977 ms

This task requires Inter-AS MPLS L3VPN Option A between AS 1.57920 and P3 to interconnect with CE1-
6. This option is the simplest one compared to other options B and C that practice labs 2 and 3
examined. Though option A is not a scalable solution as for each VPN it requires a dedicated interface
between participating providers. The interface can be either physical or logical (sub-interface). In this
task we use one of inter-AS interfaces between R7 and P3 for this purpose.

Both R7 and P3 would need to assign the inter-AS interface into VRF dedicated for VPN1 and then
exchange routing information. The protocol does not need to be OSPF that is used at other sites of
VPN1. However this task requires OSPF to be in place and thus we need to configure domain-vpn-tag 0
on both R7 and P3 (preconfigured). Reason being is that even though from R7’s perspectives, anything
that connects on the other side of the inter-AS interface is treated as a CE device and vice versa, P3
would treat R7 as if it is a CE, both R7 and P3 would by default set a non-zero value for the VPN tag field

in the OSPF LSAs sent out of VRF-enabled interface. This is a default loop prevention of OSPF as PE-CE
routing protocol for multi-PE scenario. Let’s check to ensure R7 receives routing updates from P3 for
routes from CE1-6, so as R1, R2 and R8.
lab@VMX-R7> show ospf neighbor instance VPN1-SPOKE
Address Interface State ID Pri Dead
172.16.140.2 ge-0/0/4.140 Full 172.16.16.1 128 35

lab@VMX-R7> show route table VPN1-SPOKE.inet.0 protocol ospf active-path

VPN1-SPOKE.inet.0: 53 destinations, 114 routes (53 active, 0 holddown, 0 hidden)

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

172.16.16.0/30 *[OSPF/10] 00:55:47, metric 2

> to 172.16.140.2 via ge-0/0/4.140
172.30.150.0/24 *[OSPF/150] 00:55:47, metric 0, tag 0
> to 172.16.140.2 via ge-0/0/4.140
172.30.151.0/24 *[OSPF/150] 00:55:47, metric 0, tag 0
> to 172.16.140.2 via ge-0/0/4.140
172.30.152.0/24 *[OSPF/150] 00:55:47, metric 0, tag 0
> to 172.16.140.2 via ge-0/0/4.140
172.30.153.0/24 *[OSPF/150] 00:55:47, metric 0, tag 0
> to 172.16.140.2 via ge-0/0/4.140
172.30.154.0/24 *[OSPF/150] 00:55:47, metric 0, tag 0
> to 172.16.140.2 via ge-0/0/4.140
172.30.155.0/24 *[OSPF/150] 00:55:47, metric 0, tag 0
> to 172.16.140.2 via ge-0/0/4.140
172.30.156.0/24 *[OSPF/150] 00:55:47, metric 0, tag 0
> to 172.16.140.2 via ge-0/0/4.140
172.30.157.0/24 *[OSPF/150] 00:55:47, metric 0, tag 0
> to 172.16.140.2 via ge-0/0/4.140
172.30.158.0/24 *[OSPF/150] 00:55:47, metric 0, tag 0
> to 172.16.140.2 via ge-0/0/4.140
172.30.159.0/24 *[OSPF/150] 00:55:47, metric 0, tag 0
> to 172.16.140.2 via ge-0/0/4.140
224.0.0.5/32 *[OSPF/10] 00:56:25, metric 1
MultiRecv

lab@VMX-R8> show route table VPN1-SPOKE.inet.0 active-path | match 172.30.15

172.30.15.0/24 *[BGP/170] 2d 19:24:38, MED 0, localpref 100, from 150.1.1.4
172.30.150.0/24 *[BGP/170] 05:38:28, MED 0, localpref 100, from 150.1.1.4
172.30.151.0/24 *[BGP/170] 05:38:28, MED 0, localpref 100, from 150.1.1.4
172.30.152.0/24 *[BGP/170] 05:38:28, MED 0, localpref 100, from 150.1.1.4
172.30.153.0/24 *[BGP/170] 05:38:28, MED 0, localpref 100, from 150.1.1.4
172.30.154.0/24 *[BGP/170] 05:38:28, MED 0, localpref 100, from 150.1.1.4
172.30.155.0/24 *[BGP/170] 05:38:28, MED 0, localpref 100, from 150.1.1.4
172.30.156.0/24 *[BGP/170] 05:38:28, MED 0, localpref 100, from 150.1.1.4

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

172.30.157.0/24 *[BGP/170] 05:38:28, MED 0, localpref 100, from 150.1.1.4
172.30.158.0/24 *[BGP/170] 05:38:28, MED 0, localpref 100, from 150.1.1.4
172.30.159.0/24 *[BGP/170] 05:38:28, MED 0, localpref 100, from 150.1.1.4

Now let’s ensure inter-AS MPLS L3VPN connectivity between all CE routers of VPN1 in AS 1.57920 and
CE1-6 in P3 is provided by issuing ping tests from CE1-1, CE1-2 and CE1-3 to CE1-6.
lab@VMX-VR> ping rapid routing-instance CE1-1 source 172.30.10.1 172.30.150.1
PING 172.30.150.1 (172.30.150.1): 56 data bytes
!!!!!
--- 172.30.150.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 29.255/29.787/30.102/0.284 ms

lab@VMX-VR> ping rapid routing-instance CE1-2 source 172.30.20.1 172.30.150.1

PING 172.30.150.1 (172.30.150.1): 56 data bytes
!!!!!
--- 172.30.150.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 44.811/45.013/45.194/0.134 ms

lab@VMX-VR> ping rapid routing-instance CE1-3 source 172.30.30.1 172.30.150.1

PING 172.30.150.1 (172.30.150.1): 56 data bytes
!!!!!
--- 172.30.150.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

round-trip min/avg/max/stddev = 59.987/61.961/64.836/2.309 ms

And also the forwarding path between CE1-6 (connecting via P3) and CE1-2, CE1-3 actually is across CE1-
1 (connecting to R1).
lab@VMX-VR> traceroute routing-instance CE1-6 source 172.30.150.1 172.30.20.1
traceroute to 172.30.20.1 (172.30.20.1) from 172.30.150.1, 30 hops max, 40 byte packets
1 172.16.16.1 (172.16.16.1) 9.867 ms 4.753 ms 10.153 ms
2 172.16.140.1 (172.16.140.1) 14.746 ms 14.481 ms 15.010 ms
3 150.1.57.5 (150.1.57.5) 34.903 ms 34.544 ms 34.993 ms
MPLS Label=299952 CoS=0 TTL=1 S=0
MPLS Label=299808 CoS=0 TTL=1 S=0
MPLS Label=299792 CoS=0 TTL=1 S=1
4 150.1.35.3 (150.1.35.3) 38.096 ms 31.338 ms 35.001 ms
MPLS Label=299808 CoS=0 TTL=1 S=0
MPLS Label=299792 CoS=0 TTL=2 S=1
5 150.1.13.1 (150.1.13.1) 35.026 ms 34.688 ms 34.725 ms
MPLS Label=299792 CoS=0 TTL=1 S=1
6 172.16.117.2 (172.16.117.2) 34.984 ms 34.489 ms 34.954 ms
7 172.16.118.1 (172.16.118.1) 34.903 ms 34.499 ms 34.953 ms
8 150.1.1.22 (150.1.1.22) 45.001 ms 44.500 ms 44.994 ms
9 172.30.20.1 (172.30.20.1) 54.934 ms 49.451 ms 49.937 ms

lab@VMX-VR> traceroute routing-instance CE1-6 source 172.30.150.1 172.30.30.1

traceroute to 172.30.30.1 (172.30.30.1) from 172.30.150.1, 30 hops max, 40 byte packets
1 172.16.16.1 (172.16.16.1) 9.609 ms 9.675 ms 9.982 ms
2 172.16.140.1 (172.16.140.1) 15.018 ms 9.462 ms 14.986 ms
3 150.1.57.5 (150.1.57.5) 35.103 ms 34.427 ms 34.862 ms
MPLS Label=299952 CoS=0 TTL=1 S=0
MPLS Label=299808 CoS=0 TTL=1 S=0
MPLS Label=299792 CoS=0 TTL=1 S=1
4 150.1.35.3 (150.1.35.3) 34.924 ms 34.539 ms 35.032 ms
MPLS Label=299808 CoS=0 TTL=1 S=0
MPLS Label=299792 CoS=0 TTL=2 S=1
5 150.1.13.1 (150.1.13.1) 34.946 ms 34.379 ms 35.006 ms
MPLS Label=299792 CoS=0 TTL=1 S=1
6 172.16.117.2 (172.16.117.2) 34.801 ms 34.667 ms 34.987 ms
7 172.16.118.1 (172.16.118.1) 35.613 ms 33.747 ms 30.139 ms
8 150.1.12.2 (150.1.12.2) 59.828 ms 59.604 ms 59.789 ms
MPLS Label=300032 CoS=0 TTL=1 S=0
MPLS Label=16 CoS=0 TTL=1 S=1
9 150.1.24.4 (150.1.24.4) 60.042 ms 59.727 ms 59.647 ms
MPLS Label=300192 CoS=0 TTL=1 S=0
MPLS Label=299776 CoS=0 TTL=1 S=0
MPLS Label=16 CoS=0 TTL=2 S=1
10 150.1.46.6 (150.1.46.6) 60.353 ms 59.117 ms 60.114 ms
MPLS Label=299776 CoS=0 TTL=1 S=0
MPLS Label=16 CoS=0 TTL=3 S=1

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

11 172.30.30.1 (172.30.30.1) 69.837 ms 69.356 ms 70.214 ms

Task 2. You may recall that in practice lab 1, topic 5, task 2 we have built MPLS L2VPN with VPLS
technology signalled by BGP. This task on the other hand examines VPLS that is signalled by LDP.

From protocol perspectives, the PE-CE links must have VPLS encapsulation, then all participating VRFs
will need to have an identical VPLS-ID. All participating PE routers need to be manually configured for
LDP neighbours with statement protocol vpls neighbor. After that LDP will signal targeted sessions for
the configured neighbours. Because of that, LDP needs to be activated for the loopback0 interface. For
site that has got redundant PE routers, we can specify which PE is primary and which PE is backup via
statement protocol vpls neighbor <primary-rid> backup <backup-rid>. In this task, since we are
bridging VLAN 104 across the VPLS domain, the encapsulation of the VRF needs to support that with
statement encapsulation ethernet-vlan at the protocol vpls stanza.

Now we should ensure that VPLS connections are Up for all sites. Particularly for CE2-1 with dual PE
routers, when the primary PE router R8 fails, the backup PE router R6 should be able to maintain the
VPLS connectivity for the site.

lab@VMX-R2> show vpls connections | find Instance:

Instance: VPN2
VPLS-id: 200
Neighbor Type St Time last up # Up trans
150.1.1.3(vpls-id 200) rmt Up Jan 2 02:38:47 2017 1
Remote PE: 150.1.1.3, Negotiated control-word: No
Incoming label: 262145, Outgoing label: 262149
Negotiated PW status TLV: No
Local interface: lsi.1048577, Status: Up, Encapsulation: VLAN
Description: Intf - vpls VPN2 neighbor 150.1.1.3 vpls-id 200
150.1.1.8(vpls-id 200) rmt Up Jan 2 02:40:48 2017 1
Remote PE: 150.1.1.8, Negotiated control-word: No
Incoming label: 262148, Outgoing label: 262145
Negotiated PW status TLV: No
Local interface: lsi.1048578, Status: Up, Encapsulation: VLAN
Description: Intf - vpls VPN2 neighbor 150.1.1.8 vpls-id 200
150.1.1.6(vpls-id 200) rmt BK

lab@VMX-R3> show vpls connections | find Instance:

Instance: VPN2
VPLS-id: 200
Neighbor Type St Time last up # Up trans
150.1.1.2(vpls-id 200) rmt Up Jan 2 02:38:39 2017 1
Remote PE: 150.1.1.2, Negotiated control-word: No
Incoming label: 262149, Outgoing label: 262145
Negotiated PW status TLV: No
Local interface: lsi.1048579, Status: Up, Encapsulation: VLAN
Description: Intf - vpls VPN2 neighbor 150.1.1.2 vpls-id 200
150.1.1.8(vpls-id 200) rmt Up Jan 2 02:37:45 2017 1
Remote PE: 150.1.1.8, Negotiated control-word: No
Incoming label: 262148, Outgoing label: 262146
Negotiated PW status TLV: No
Local interface: lsi.1048578, Status: Up, Encapsulation: VLAN
Description: Intf - vpls VPN2 neighbor 150.1.1.8 vpls-id 200
150.1.1.6(vpls-id 200) rmt BK

lab@VMX-R6> show vpls connections | find Instance:

Instance: VPN2
VPLS-id: 200
Neighbor Type St Time last up # Up trans
150.1.1.2(vpls-id 200) rmt OL
150.1.1.3(vpls-id 200) rmt OL

lab@VMX-R8> show vpls connections | find Instance:

Instance: VPN2
VPLS-id: 200

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

Neighbor Type St Time last up # Up trans
150.1.1.2(vpls-id 200) rmt Up Jan 2 02:40:53 2017 1
Remote PE: 150.1.1.2, Negotiated control-word: No
Incoming label: 262145, Outgoing label: 262148
Negotiated PW status TLV: No
Local interface: lsi.1048834, Status: Up, Encapsulation: VLAN
Description: Intf - vpls VPN2 neighbor 150.1.1.2 vpls-id 200
150.1.1.3(vpls-id 200) rmt Up Jan 2 02:37:54 2017 1
Remote PE: 150.1.1.3, Negotiated control-word: No
Incoming label: 262146, Outgoing label: 262148
Negotiated PW status TLV: No
Local interface: lsi.1048833, Status: Up, Encapsulation: VLAN
Description: Intf - vpls VPN2 neighbor 150.1.1.3 vpls-id 200

Now all CE routers should have reachability with each other via ping tests and MAC address tables on
the PE routers R2, R3, R6 and R8 should be populated accordingly.
lab@VMX-VR> ping rapid routing-instance CE2-4 172.30.40.2
PING 172.30.40.2 (172.30.40.2): 56 data bytes
!!!!!
--- 172.30.40.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 30.117/33.941/35.017/1.914 ms

lab@VMX-VR> ping rapid routing-instance CE2-4 172.30.40.31

PING 172.30.40.31 (172.30.40.31): 56 data bytes

!!!!!
--- 172.30.40.31 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 19.782/20.418/22.166/0.881 ms

lab@VMX-VR> ping rapid routing-instance CE2-3 172.30.40.2

lab@VMX-R2> show route forwarding-table family vpls

Routing table: VPN2.vpls
VPLS:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 dscd 682 1
00:05:86:71:b7:02/48 user 0 indr 1048609 5
ulst 1048608 2
150.1.23.3 Push 262145 825 1 ge-0/0/8.0
150.1.24.4 Push 262145, Push 300800(top) 826
1 ge-0/0/6.0
00:05:86:71:b7:08/48 user 0 indr 1048575 5
ulst 1048574 2
150.1.24.4 Push 262145, Push 300352, Push
300928(top) 787 1 ge-0/0/6.0
150.1.23.3 Push 262145, Push 300352, Push
300512(top) 793 1 ge-0/0/8.0
00:05:86:71:b7:09/48 user 0 ucst 778 5 ge-0/0/3.104
lsi.1048578 intf 0 indr 1048575 5
ulst 1048574 2
150.1.24.4 Push 262145, Push 300352, Push
300928(top) 787 1 ge-0/0/6.0
150.1.23.3 Push 262145, Push 300352, Push
300512(top) 793 1 ge-0/0/8.0
lsi.1048577 intf 0 indr 1048609 5
ulst 1048608 2
150.1.23.3 Push 262145 825 1 ge-0/0/8.0
150.1.24.4 Push 262145, Push 300800(top) 826
1 ge-0/0/6.0
0x30003/51 user 0 comp 817 2
ge-0/0/3.104 intf 0 ucst 778 5 ge-0/0/3.104
0x30002/51 user 0 comp 634 2
0x30001/51 user 0 comp 599 2

lab@VMX-R2> show vpls mac-table

MAC flags (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

Routing instance : VPN2
Bridging domain : __VPN2__, VLAN : NA
MAC MAC Logical NH RTR
address flags interface Index ID
00:05:86:71:b7:02 D lsi.1048577
00:05:86:71:b7:08 D lsi.1048578
00:05:86:71:b7:09 D ge-0/0/3.104

lab@VMX-R2> show vpls statistics

VPLS statistics:

Instance: VPN2
Local interface: ge-0/0/5.104, Index: 350
Broadcast packets: 2
Broadcast bytes : 120
Multicast packets: 0
Multicast bytes : 0
Flooded packets : 0
Flooded bytes : 0
Unicast packets : 10
Unicast bytes : 1020
Current MAC count: 1 (Limit 1024)
Local interface: lsi.1048578, Index: 353
Remote PE: 150.1.1.8
Broadcast packets: 0
Broadcast bytes : 0

Multicast packets: 0
Multicast bytes : 0
Flooded packets : 0
Flooded bytes : 0
Unicast packets : 6
Unicast bytes : 570
Current MAC count: 1
Local interface: lsi.1048577, Index: 354
Remote PE: 150.1.1.3
Broadcast packets: 1
Broadcast bytes : 46
Multicast packets: 0
Multicast bytes : 0
Flooded packets : 0
Flooded bytes : 0
Unicast packets : 6
Unicast bytes : 556
Current MAC count: 1

Task 3 requires IPv6 routing/forwarding over MPLS domain to be configured so that customers can have
IPv6 reachability in a virtual private network. This refers to 6VPE implementation for Service Provider
Network which requires the following:

• family inet6 unicast between PE and CE routers (if BGP is the selected routing protocol) to
exchange IPv6 routes. It is similar to family inet unicast which is for IPv4 stack. If the VRF is
IPv6-only, meaning that the virtual private network is IPv6, on the PE routers we would need to
statically configure BGP Router-ID, otherwise BGP session will not be able to form.
• family inet6-vpn unicast between iBGP neighbours to allocate labels for IPv6 prefixes over IPv4
iBGP sessions so that we don't need to enable native IPv6 iBGP sessions in the core network. It is
similar to family inet-vpn unicast which is for IPv4 stack.
• set protocols mpls ipv6-tunneling, we convert IPv4 next-hop being routers’ loopback address
in table inet.3 into IPv4-mapped IPv6 next-hop and install them into table inet6.3 for IPv6 label-
based forwarding.
o If you recall that in topic 4, task 2 where we implemented 6PE, we had to artificially
create IPv4-mapped IPv6 address version of R1’s loopback0 in R4 and R5’s table inet6.3
by using rib-group that seeds R1’s loopback0 from table inet.0 and import into table
inet6.3. And the reason is that R4 and R5 in RSVP domain do not have direct LSPs with

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

R1 (in an LDP island) so their inet.3 tables do not directly have R1’s loopback0 and hence
their inet6.3 tables do not directly have IPv4-mapped IPv6 address version of R1’s
loopback0, breaking BGP resolution for 6PE prefixes. The same concept does not here
for 6VPE because all the PE routers R2, R7 are in the same RSVP domain and they
directly have each other’s loopback0 address in table inet.3 and hence table inet6.3.
• family inet6 on all core-facing interfaces, this is already configured as part of initial
configurations. There is no need for specific IPv6 address to be configured, but instead just the
activation of the IPv6 AFI on the interfaces.

This task requires Inter-AS MPLS L3VPN Option A between AS 1.57920 and P3 to interconnect with CE4-
3. This option is the simplest one compared to other options B and C that practice labs 2 and 3
examined. Though option A is not a scalable solution as for each VPN it requires a dedicated interface
between participating providers. The inter-AS interface can be either physical or logical (sub-interface).
In this task we use the remaining interface between R7 and P3 for this purpose and add that interface
into the existing routing instance VPN4. BGP session with P3 should be Up and can receive routes
announced by CE4-3.

lab@VMX-R7> show bgp summary | find 2016:172:16:139::2

2016:172:16:139::2 300 183 193 0 0 1:26:00 Establ
VPN4.inet6.0: 12/12/12/0

lab@VMX-R7> show route receive-protocol bgp 2016:172:16:139::2 table VPN4.inet6.0

VPN4.inet6.0: 32 destinations, 40 routes (32 active, 0 holddown, 0 hidden)

Prefix Nexthop MED Lclpref AS path
2016:172:30:110::/64
* 2016:172:16:139::2 300 65504 I
2016:172:30:111::/64
* 2016:172:16:139::2 300 65504 I
2016:172:30:112::/64
* 2016:172:16:139::2 300 65504 I
2016:172:30:113::/64
* 2016:172:16:139::2 300 65504 I
2016:172:30:114::/64
* 2016:172:16:139::2 300 65504 I
2016:172:30:115::/64
* 2016:172:16:139::2 300 65504 I
2016:172:30:120::/64
* 2016:172:16:139::2 300 65504 I
2016:172:30:121::/64
* 2016:172:16:139::2 300 65504 I
2016:172:30:122::/64
* 2016:172:16:139::2 300 65504 I
2016:172:30:123::/64
* 2016:172:16:139::2 300 65504 I
2016:172:30:124::/64
* 2016:172:16:139::2 300 65504 I
2016:172:30:125::/64
* 2016:172:16:139::2 300 65504 I

Let’s ensure IPv6 BGP sessions are up between PE and CE routers and then verify IPv6 reachability
between CE4-1, CE4-2 and CE4-3 by generating some ping tests between them.
lab@VMX-R2> show bgp summary | match 65504
2016:172:16:128::2 65504 1953 2024 0 0 15:24:36 Establ

lab@VMX-R7> show bgp summary | match 65504

2016:172:16:127::2 65504 140 155 0 0 1:05:22 Establ

lab@VMX-VR> ping rapid routing-instance CE4-2 source 2016:172:30:100::1 2016:172:30:90::1

PING6(56=40+8+8 bytes) 2016:172:30:100::1 --> 2016:172:30:90::1
!!!!!
--- 2016:172:30:90::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 39.698/39.961/40.095/0.149 ms

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

lab@VMX-VR> ping rapid routing-instance CE4-2 source 2016:172:30:100::1
2016:172:30:110::1
PING6(56=40+8+8 bytes) 2016:172:30:100::1 --> 2016:172:30:110::1
!!!!!
--- 2016:172:30:110::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 39.781/39.925/40.083/0.118 ms

lab@VMX-VR> ping rapid routing-instance CE4-1 source 2016:172:30:90::1 2016:172:30:110::1

PING6(56=40+8+8 bytes) 2016:172:30:90::1 --> 2016:172:30:110::1
!!!!!
--- 2016:172:30:110::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 19.646/19.877/20.014/0.132 ms

Traceroute outputs:
lab@VMX-VR> traceroute routing-instance CE4-2 source 2016:172:30:100::1 2016:172:30:90::1
traceroute6 to 2016:172:30:90::1 (2016:172:30:90::1) from 2016:172:30:100::1, 64 hops
max, 12 byte packets
1 2016:172:16:128::1 (2016:172:16:128::1) 14.787 ms 14.992 ms 15.041 ms
2 2016:150:1:24::4 (2016:150:1:24::4) 39.937 ms 39.766 ms 39.974 ms
MPLS Label=302144 CoS=0 TTL=1 S=0
MPLS Label=302208 CoS=0 TTL=1 S=1
3 2016:150:1:45::5 (2016:150:1:45::5) 40.093 ms 39.565 ms 40.212 ms

MPLS Label=302080 CoS=0 TTL=1 S=0

MPLS Label=302208 CoS=0 TTL=2 S=1
4 2016:150:1:57::7 (2016:150:1:57::7) 34.763 ms 34.822 ms 34.887 ms
MPLS Label=302208 CoS=0 TTL=1 S=1
5 2016:172:30:90::1 (2016:172:30:90::1) 39.870 ms 34.815 ms 44.670 ms

lab@VMX-VR> traceroute routing-instance CE4-2 source 2016:172:30:100::1

2016:172:30:110::1
traceroute6 to 2016:172:30:110::1 (2016:172:30:110::1) from 2016:172:30:100::1, 64 hops
max, 12 byte packets
1 2016:172:16:128::1 (2016:172:16:128::1) 14.983 ms 15.038 ms 14.979 ms
2 2016:150:1:24::4 (2016:150:1:24::4) 39.968 ms 39.738 ms 40.052 ms
MPLS Label=302144 CoS=0 TTL=1 S=0
MPLS Label=302288 CoS=0 TTL=1 S=1
3 2016:150:1:45::5 (2016:150:1:45::5) 39.871 ms 39.767 ms 40.035 ms
MPLS Label=302080 CoS=0 TTL=1 S=0
MPLS Label=302288 CoS=0 TTL=2 S=1
4 2016:150:1:57::7 (2016:150:1:57::7) 34.856 ms 34.939 ms 34.814 ms
MPLS Label=302288 CoS=0 TTL=1 S=1
5 2016:172:16:139::2 (2016:172:16:139::2) 39.902 ms 39.848 ms 39.894 ms
6 2016:172:30:110::1 (2016:172:30:110::1) 40.129 ms 39.534 ms 39.946 ms

Task 4 examines the implementation of Internet Access for customer VPN1. It does not allow you to use
another interface dedicated for Internet purpose, but instead use the existing VPN interface on PE
router R1. In order to achieve this, there are two steps: 1) propagate VPN1 routes to the Internet and 2)
propagate Internet routes to VPN1.

• For the first step, we can simply achieve it by importing VPN1 routes from table VPN1-
HUB.inet.0 to the global routing table inet.0 with rib-group feature. Hub VRF is chosen as it
holds all routes advertised by the CE routers including the hub CE1-1, and those routes are
learnt via OSPF, advertised by hub CE1-1. The Spoke VRF also has got all the routes of VPN1 but
the ones advertised by remote CE routers are BGP routes. We then would need to announce
VPN1 routes out of all iBGP and eBGP sessions that R1 has got, it is because those routes are
OSPF and do not automatically get advertised straight away. Also, as a matter of safety, we
should tag the OSPF routes when importing (see tag 3310) and announce just the ones with
such tag to avoid any unexpected issue such as leaking the whole OSPF routes of the core
networks to the Internet. After that, VPN1 routes should be advertised via i/eBGP sessions.
lab@VMX-R1> show route advertising-protocol bgp 111.1.120.2 | match 172.30

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

* 172.30.10.0/24 Self 0 I
* 172.30.11.0/24 Self 0 I
* 172.30.12.0/24 Self 0 I
* 172.30.13.0/24 Self 0 I
* 172.30.14.0/24 Self 0 I
* 172.30.15.0/24 Self 0 I
* 172.30.16.0/24 Self 0 I
* 172.30.17.0/24 Self 0 I
* 172.30.18.0/24 Self 0 I
* 172.30.19.0/24 Self 0 I
* 172.30.20.0/24 Self 0 I
* 172.30.21.0/24 Self 0 I
* 172.30.22.0/24 Self 0 I
* 172.30.23.0/24 Self 0 I
* 172.30.24.0/24 Self 0 I
* 172.30.25.0/24 Self 0 I
* 172.30.26.0/24 Self 0 I
* 172.30.27.0/24 Self 0 I
* 172.30.28.0/24 Self 0 I
* 172.30.29.0/24 Self 0 I
* 172.30.30.0/24 Self 0 I
* 172.30.31.0/24 Self 0 I
* 172.30.32.0/24 Self 0 I
* 172.30.33.0/24 Self 0 I
* 172.30.34.0/24 Self 0 I
* 172.30.35.0/24 Self 0 I
* 172.30.36.0/24 Self 0 I
* 172.30.37.0/24 Self 0 I

* 172.30.38.0/24 Self 0 I
* 172.30.39.0/24 Self 0 I
* 172.30.150.0/24 Self 0 I
* 172.30.151.0/24 Self 0 I
* 172.30.152.0/24 Self 0 I
* 172.30.153.0/24 Self 0 I
* 172.30.154.0/24 Self 0 I
* 172.30.155.0/24 Self 0 I
* 172.30.156.0/24 Self 0 I
* 172.30.157.0/24 Self 0 I
* 172.30.158.0/24 Self 0 I
* 172.30.159.0/24 Self 0 I

lab@VMX-R1> show route advertising-protocol bgp 150.1.1.4 table inet.0 | match 172.30
* 172.30.10.0/24 Self 0 100 I
* 172.30.11.0/24 Self 0 100 I
* 172.30.12.0/24 Self 0 100 I
* 172.30.13.0/24 Self 0 100 I
* 172.30.14.0/24 Self 0 100 I
* 172.30.15.0/24 Self 0 100 I
* 172.30.16.0/24 Self 0 100 I
* 172.30.17.0/24 Self 0 100 I
* 172.30.18.0/24 Self 0 100 I
* 172.30.19.0/24 Self 0 100 I
* 172.30.20.0/24 Self 0 100 I
* 172.30.21.0/24 Self 0 100 I
* 172.30.22.0/24 Self 0 100 I
* 172.30.23.0/24 Self 0 100 I
* 172.30.24.0/24 Self 0 100 I
* 172.30.25.0/24 Self 0 100 I
* 172.30.26.0/24 Self 0 100 I
* 172.30.27.0/24 Self 0 100 I
* 172.30.28.0/24 Self 0 100 I
* 172.30.29.0/24 Self 0 100 I
* 172.30.30.0/24 Self 0 100 I
* 172.30.31.0/24 Self 0 100 I
* 172.30.32.0/24 Self 0 100 I
* 172.30.33.0/24 Self 0 100 I
* 172.30.34.0/24 Self 0 100 I
* 172.30.35.0/24 Self 0 100 I
* 172.30.36.0/24 Self 0 100 I
* 172.30.37.0/24 Self 0 100 I
* 172.30.38.0/24 Self 0 100 I
* 172.30.39.0/24 Self 0 100 I
* 172.30.150.0/24 Self 0 100 I
* 172.30.151.0/24 Self 0 100 I
* 172.30.152.0/24 Self 0 100 I
* 172.30.153.0/24 Self 0 100 I
* 172.30.154.0/24 Self 0 100 I
* 172.30.155.0/24 Self 0 100 I

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

* 172.30.156.0/24 Self 0 100 I
* 172.30.157.0/24 Self 0 100 I
* 172.30.158.0/24 Self 0 100 I
* 172.30.159.0/24 Self 0 100 I

• For the second step, we can simply announce a default route for the whole VPN1 out of table
VPN1-SPOKE.inet.0 with next-hop of the global table inet.0. Spoke VRF is chosen as it is where
all routes are advertised to the hub CE1-1. We certainly should not leak the whole Internet
routing table to VPN1 because it is unnecessary and may blow up CE routers’ tiny resources. We
need the knob vrf-table-label as the next-table inet.0 of the static default route does not
point to a local CE interface so a label is not allocated, hence remote PE routes do not receive a
label for this static default route so it will not get installed into VPN1 VRF.
lab@VMX-R1> show route advertising-protocol bgp 150.1.1.4 table VPN1-HUB.inet.0 | match
0.0.0.0
* 0.0.0.0/0 Self 0 100 I

lab@VMX-R2> show route table VPN1-SPOKE.inet.0 0.0.0.0/0 exact active-path

VPN1-SPOKE.inet.0: 44 destinations, 96 routes (44 active, 0 holddown, 0 hidden)

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

0.0.0.0/0 *[BGP/170] 18:00:07, MED 0, localpref 100, from 150.1.1.4

AS path: I
> to 150.1.12.1 via ge-0/0/2.0, Push 299792

lab@VMX-R2> show ospf database instance VPN1-SPOKE | match "\*0.0.0.0"

Extern *0.0.0.0 150.1.1.22 0x80000016 2945 0xa2 0x4238 36

lab@VMX-R8> show route table VPN1-SPOKE.inet.0 0.0.0.0/0 exact active-path

VPN1-SPOKE.inet.0: 44 destinations, 96 routes (44 active, 0 holddown, 0 hidden)

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

0.0.0.0/0 *[BGP/170] 18:00:25, MED 0, localpref 100, from 150.1.1.4

AS path: I
> to 150.1.78.7 via ge-0/0/2.0, Push 299792, Push 301056(top)
to 150.1.68.6 via ge-0/0/6.0, Push 299792, Push 300384(top)

lab@VMX-R8> show ospf database instance VPN1-SPOKE | match "\*0.0.0.0"

Extern *0.0.0.0 150.1.1.88 0x80000017 410 0xa2 0xb284 36

At the end of the task, Internet connectivity should be provided for all CE routers, including CE1-6
connected via P3 as per ping test outputs below:
lab@VMX-VR> ping rapid routing-instance CE1-1 source 172.30.10.1 123.0.0.1
PING 123.0.0.1 (123.0.0.1): 56 data bytes
!!!!!
--- 123.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 14.713/14.951/15.253/0.180 ms

lab@VMX-VR> ping rapid routing-instance CE1-2 source 172.30.20.1 123.0.0.1

PING 123.0.0.1 (123.0.0.1): 56 data bytes
!!!!!
--- 123.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 29.788/29.940/30.103/0.112 ms

lab@VMX-VR> ping rapid routing-instance CE1-3 source 172.30.30.1 123.0.0.1

PING 123.0.0.1 (123.0.0.1): 56 data bytes
!!!!!
--- 123.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 40.140/43.980/44.987/1.920 ms

lab@VMX-VR> ping rapid routing-instance CE1-6 source 172.30.150.1 123.0.0.1

PING 123.0.0.1 (123.0.0.1): 56 data bytes
!!!!!
--- 123.0.0.1 ping statistics ---

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 44.498/47.957/50.635/2.749 ms

Also, the Internet traffic from spoke CE routers CE1-2 and CE1-3 should still traverse the hub site as per
traceroute outputs below:
lab@VMX-VR> traceroute routing-instance CE1-2 source 172.30.20.1 123.0.0.1
traceroute to 123.0.0.1 (123.0.0.1) from 172.30.20.1, 30 hops max, 40 byte packets
1 172.16.103.1 (172.16.103.1) 14.993 ms 9.593 ms 14.984 ms
2 150.1.12.1 (150.1.12.1) 24.936 ms 24.518 ms 24.964 ms
MPLS Label=299792 CoS=0 TTL=1 S=1
3 172.16.117.2 (172.16.117.2) 24.947 ms 24.576 ms 24.920 ms
4 172.16.118.1 (172.16.118.1) 24.991 ms 24.533 ms 25.127 ms
5 111.1.120.2 (111.1.120.2) 34.925 ms 34.493 ms 35.057 ms
6 123.0.0.1 (123.0.0.1) 34.718 ms 34.536 ms 35.043 ms

lab@VMX-VR> traceroute routing-instance CE1-3 source 172.30.30.1 123.0.0.1

traceroute to 123.0.0.1 (123.0.0.1) from 172.30.30.1, 30 hops max, 40 byte packets
1 172.16.112.1 (172.16.112.1) 14.916 ms 14.792 ms 14.977 ms
2 150.1.78.7 (150.1.78.7) 44.935 ms 44.676 ms 44.801 ms
MPLS Label=301056 CoS=0 TTL=1 S=0
MPLS Label=299792 CoS=0 TTL=1 S=1
3 150.1.57.5 (150.1.57.5) 45.107 ms 44.316 ms 40.077 ms
MPLS Label=302944 CoS=0 TTL=1 S=0
MPLS Label=299936 CoS=0 TTL=1 S=0
MPLS Label=299792 CoS=0 TTL=2 S=1

4 150.1.35.3 (150.1.35.3) 45.318 ms 44.030 ms 44.996 ms

MPLS Label=299936 CoS=0 TTL=1 S=0
MPLS Label=299792 CoS=0 TTL=3 S=1
5 150.1.13.1 (150.1.13.1) 44.943 ms 44.596 ms 45.130 ms
MPLS Label=299792 CoS=0 TTL=1 S=1
6 172.16.117.2 (172.16.117.2) 44.946 ms 44.689 ms 44.587 ms
7 172.16.118.1 (172.16.118.1) 39.913 ms 39.457 ms 39.987 ms
8 111.1.120.2 (111.1.120.2) 54.851 ms 54.552 ms 54.987 ms
9 123.0.0.1 (123.0.0.1) 54.981 ms 54.549 ms 54.851 ms

lab@VMX-VR> traceroute routing-instance CE1-6 source 172.30.150.1 123.0.0.1

traceroute to 123.0.0.1 (123.0.0.1) from 172.30.150.1, 30 hops max, 40 byte packets
1 172.16.16.1 (172.16.16.1) 9.730 ms 9.874 ms 9.888 ms
2 172.16.140.1 (172.16.140.1) 14.918 ms 14.609 ms 14.860 ms
3 150.1.57.5 (150.1.57.5) 40.011 ms 39.638 ms 39.914 ms
MPLS Label=299952 CoS=0 TTL=1 S=0
MPLS Label=299808 CoS=0 TTL=1 S=0
MPLS Label=299792 CoS=0 TTL=1 S=1
4 150.1.35.3 (150.1.35.3) 40.128 ms 39.375 ms 40.010 ms
MPLS Label=299808 CoS=0 TTL=1 S=0
MPLS Label=299792 CoS=0 TTL=2 S=1
5 150.1.13.1 (150.1.13.1) 39.822 ms 34.186 ms 39.951 ms
MPLS Label=299792 CoS=0 TTL=1 S=1
6 172.16.117.2 (172.16.117.2) 39.979 ms 39.486 ms 39.972 ms
7 172.16.118.1 (172.16.118.1) 40.067 ms 40.080 ms 34.458 ms
8 111.1.120.2 (111.1.120.2) 44.950 ms 44.436 ms 54.055 ms
9 123.0.0.1 (123.0.0.1) 50.878 ms 54.935 ms 54.820 ms

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

Topic 6: Multicast
Total Points: 9

Task 1 (9 points). Configure a multicast solution for customer VPN1 with the following characteristics:

R3,R5,R7
!
set protocols ldp p2mp

R1
!

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

set chassis fpc 0 pic 0 tunnel-services bandwidth 10g
set protocols bgp group IBGP family inet-mvpn signaling
set protocols ldp p2mp
set interface lo0.1 family inet address 150.1.1.11/32 primary
set interface lo0.1 family inet address 150.1.1.253/32
edit routing-instances VPN1-SPOKE
set interface lo0.1
set proto pim interface all
set proto pim rp local family inet address 150.1.1.253
set proto ospf export DIRECT-TO-OSPF
set proto mvpn mvpn-mode spt-only
set proto mvpn sender-site
set proto mvpn route-target import target target:18:3320
set proto mvpn route-target export target target:18:3320
set provider-tunnel ldp-p2mp
set provider-tunnel selective group 232.0.0.2 source 172.30.10.1 ldp-p2mp
set provider-tunnel selective group 232.0.0.2 source 172.30.10.1 threshold-rate 15000
set provider-tunnel selective group 232.0.0.3 source 172.30.10.1 ldp-p2mp
set provider-tunnel selective group 232.0.0.3 source 172.30.10.1 threshold-rate 30000
set provider-tunnel selective tunnel-limit 10
set vrf-table-label
exit
edit policy-options policy-statement DIRECT-TO-OSPF
set term 1 from protocol direct
set term 1 from route-filter 150.1.1.11/32 exact
set term 1 from route-filter 150.1.1.253/32 exact
set term 1 then accept

exit
edit policy-options policy-statement VPN1-HUB-EXPORT
set term 1 then community add VPN1-HUB-RT-IMPORT
set term 1 then community add VPN1-HUB-SRC-AS
exit
set policy-options community VPN1-HUB-RT-IMPORT member rt-import:150.1.1.1:7
set policy-options community VPN1-HUB-SRC-AS member src-as:123456L:0

/* Note: the value for rt-import above varies across platforms and you need to find it in
the hidden policy __vrf-mvpn-import-cmcast-VPN1-SPOKE-internal__ */

R2
!
set chassis fpc 0 pic 0 tunnel-services bandwidth 10g
set protocols bgp group IBGP family inet-mvpn signaling
set protocols ldp p2mp
set interface lo0.1 family inet address 150.1.1.22/32 primary
set interface lo0.1 family inet address 150.1.1.253/32
edit routing-instances VPN1-SPOKE
set interface lo0.1
set proto pim interface all
set proto pim rp local family inet address 150.1.1.253
set proto ospf export DIRECT-TO-OSPF
set proto mvpn mvpn-mode spt-only
set proto mvpn receiver-site
set proto mvpn route-target import target target:18:3320
set proto mvpn route-target export target target:18:3320
set vrf-table-label
exit
edit policy-options policy-statement DIRECT-TO-OSPF
set term 1 from protocol direct
set term 1 from route-filter 150.1.1.22/32 exact
set term 1 from route-filter 150.1.1.253/32 exact
set term 1 then accept
exit

R8
!
set chassis fpc 0 pic 0 tunnel-services bandwidth 10g
set protocols bgp group IBGP family inet-mvpn signaling
set protocols ldp p2mp
set interface lo0.1 family inet address 150.1.1.88/32 primary
set interface lo0.1 family inet address 150.1.1.253/32
edit routing-instances VPN1-SPOKE
set interface lo0.1
set proto pim interface all
set proto pim rp local family inet address 150.1.1.253
set proto ospf export DIRECT-TO-OSPF
set proto mvpn mvpn-mode spt-only
set proto mvpn receiver-site

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

set proto mvpn route-target import target target:18:3320
set proto mvpn route-target export target target:18:3320
set vrf-table-label
exit
edit policy-options policy-statement DIRECT-TO-OSPF
set term 1 from protocol direct
set term 1 from route-filter 150.1.1.88/32 exact
set term 1 from route-filter 150.1.1.253/32 exact
set term 1 then accept
exit

Verification
Task 1. The task specifically prohibits native multicast routing protocol and GRE encapsulation inside
service provider core networks. This excludes Draft-Rosen MVPN from possible solutions. Also it
requires that multicast traffic to be transferred via point-to-multipoint LSPs , leaving us with the only
option: NG-MVPN. The concept of this technology is simple that it converts multicast join/leave
information from customer side (e.g. via PIM) to BGP NLRIs thanks to its stability and scalability. Hence,
there is no need for multicast routing protocol inside the core networks. Multicast traffic is transferred
inside ‘tunnels’ which are categorised into two types: 1) I-PMSI or Inclusive Tunnel that involves all PE
routers and is similar to the concept of the Default MDT in Draft-Rosen world; and 2) S-PMSI or Selective

Tunnel that will be brought up for certain configured (S,G) pairs upon a configured traffic rate, similar to
the concept of Data MDT. The first type I-PMSI is always up and can carry multicast traffic anytime, it
connects to all PEs configured with NG-MVPN even if they do not have any receiver. First verification
step is to ensure that the BGP sessions are established with the new AFI inet-mvpn signaling. This will
create a new table called bgp.mvpn.0 that stores the new NLRI.
lab@VMX-R4> show bgp summary
<snip>
150.1.1.1 123456 124 131 0 1 30:24 Establ
inet.0: 54/80/80/0
bgp.l3vpn.0: 50/50/50/0
inet6.0: 15/33/33/0
bgp.mvpn.0: 1/1/1/0
150.1.1.2 123456 111 129 0 1 30:24 Establ
inet.0: 41/41/41/0
bgp.l3vpn.0: 13/13/13/0
inet6.0: 32/32/32/0
bgp.l3vpn-inet6.0: 7/7/7/0
bgp.mvpn.0: 1/1/1/0
<snip>
150.1.1.8 123456 445 609 0 1 30:24 Establ
inet.0: 0/0/0/0
bgp.l3vpn.0: 13/13/13/0
inet6.0: 0/0/0/0
bgp.mvpn.0: 1/1/1/0

This new NLRI in this task includes Type 1 MVPN route which is for intra-AS I-PMSI. Each PE router
configured with MVPN would sends this route type noting its RD along with its loopback address to
announce its interest in participating into the I-PMSI Tunnel of the service provider core network.
lab@VMX-R1> show route table VPN1-SPOKE.mvpn.0 active-path

VPN1-SPOKE.mvpn.0: 3 destinations, 5 routes (3 active, 1 holddown, 0 hidden)

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

1:150.1.1.1:7:150.1.1.1/240
*[MVPN/70] 00:07:56, metric2 1
Indirect
1:150.1.1.2:4:150.1.1.2/240
*[BGP/170] 00:03:27, localpref 100, from 150.1.1.4
AS path: I
> to 150.1.12.2 via ge-0/0/2.0, Push 0
1:150.1.1.8:4:150.1.1.8/240
*[BGP/170] 00:03:24, localpref 100, from 150.1.1.4

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

AS path: I
to 150.1.12.2 via ge-0/0/2.0, Push 300240
> to 150.1.13.3 via ge-0/0/6.0, Push 300384

All the PE routers should also recognise each other as MVPN neighbours.
lab@VMX-R1> show mvpn neighbor inet
<snip>
Instance : VPN1-SPOKE
MVPN Mode : SPT-ONLY
Neighbor I-P-tnl
150.1.1.2
150.1.1.8

In this task, the participating PE routers are R1, R2, R8 which all position in LDP islands connected via a
RSVP domain. Thus the signalling method for point-to-multipoint LSPs would be LDP (P2MP mode) as we
are not allowed to implement RSVP on R1 and R8. In order to activate LDP P2MP, we would need
statement protocols ldp p2mp on all LDP routers (R1, R2, R3 and R6, R7, R8) as well as statement
provider-tunnel ldp-p2mp on the PE router facing multicast sources (R1). Let’s ensure that the P2MP LDP
LSP is signalled accordingly for the I-PMSI. Note that the label value is all the same indicating of a single
LSP instead of a collection of different P2P LDP LSPs.

lab@VMX-R1> show ldp database p2mp

<snip>
Input label database, 150.1.1.1:0--150.1.1.2:0
Label Prefix
16 P2MP root-addr 150.1.1.1, lsp-id 16777218
<snip>

lab@VMX-R2> show ldp database p2mp

<snip>
Output label database, 150.1.1.2:0--150.1.1.1:0
Label Prefix
16 P2MP root-addr 150.1.1.1, lsp-id 16777218
<snip>

lab@VMX-R8> show ldp database p2mp

<snip>
Output label database, 150.1.1.8:0--150.1.1.7:0
Label Prefix
16 P2MP root-addr 150.1.1.1, lsp-id 16777218
<snip>

On the receiving PE routers (R2, R8), we can see the status of the PIM conversion into the P2MP LDP
LSP. It is interesting to see that even though group 232.0.0.3 is configured to use a S-PMSI Tunnel but it
is currently using the same LSP of I-PMSI denoted by the lsp-id. It is because the configured threshold
for traffic rate has not been crossed yet.
lab@VMX-R2> show mvpn c-multicast inet | find "Instance :"

Instance : VPN1-SPOKE
MVPN Mode : SPT-ONLY
C-mcast IPv4 (S:G) Ptnl St
172.30.10.1/32:232.0.0.1/32 LDP-P2MP:150.1.1.1, lsp-id 16777218
172.30.10.1/32:232.0.0.2/32 LDP-P2MP:150.1.1.1, lsp-id 16777218

lab@VMX-R8> show mvpn c-multicast inet | find "Instance :"

Instance : VPN1-SPOKE
MVPN Mode : SPT-ONLY
C-mcast IPv4 (S:G) Ptnl St
172.30.10.1/32:232.0.0.1/32 LDP-P2MP:150.1.1.1, lsp-id 16777218
172.30.10.1/32:232.0.0.3/32 LDP-P2MP:150.1.1.1, lsp-id 16777218

In this task, you may notice that at the hub PE router R1 we only configure MVPN for the spoke VRF
where routes (or multicast joins) from spoke sites are learnt, while we leave hub VRF intact without
MVPN. Because of that when exporting source routes to the spoke sites from hub VRF, it does not

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

attach the two extended communities rt-import and src-as which are needed for MVPN Route Type 6
(Shared Tree Join) and MVPN Route Type 7 (Source Tree Join) at the receiving PE routers. The rt-import
extended community is a combination of loopback address and a randomly-generated value on PE
router, in this scenario we have MVPN on the spoke VRF, therefore we would need to use spoke VRF’s
value when exporting routes from hub VRF. This value can be seen from one of hidden policies below.
lab@VMX-R1> edit
Entering configuration mode

[edit]
lab@VMX-R1# run show policy
Configured policies:
<snip>
__vrf-export-DC1-internal__
__vrf-import-DC1-internal__
__vrf-mvpn-export-inet-VPN1-SPOKE-internal__
__vrf-mvpn-export-target-VPN1-SPOKE-internal__
__vrf-mvpn-import-cmcast-VPN1-SPOKE-internal__
__vrf-mvpn-import-cmcast-leafAD-global-internal__
__vrf-mvpn-import-target-VPN1-SPOKE-internal__

[edit]
lab@VMX-R1# run show policy __vrf-mvpn-import-cmcast-VPN1-SPOKE-internal__

Policy __vrf-mvpn-import-cmcast-VPN1-SPOKE-internal__:
Term unnamed:
from community __vrf-mvpn-community-rt_import-target-VPN1-SPOKE-internal__
[target:150.1.1.1:7 ]
then accept
Term unnamed:
then reject

This rt-import extended community is used by receiving PE router to select active sender PE router. On
the receiving PE routers (R2, R8), each of them generates a MVPN route Type 7 which stands for Source
Tree Join, created for local join message that the PE receives (in this case it is IGMP static configuration).
This route type’s communities includes the value of rt-import extended community that it receives. The
src-as community follows a standard of src-as:<ASN>:0, our ASN is 123456 so it’s necessary to mention
with letter L to indicate 4-byte ASN value.
lab@VMX-R2> show route table VPN1-SPOKE.mvpn.0 | find "^7:150.1.1.1"
7:150.1.1.1:5:123456:32:172.30.10.1:32:232.0.0.1/240
*[PIM/105] 00:44:30
Multicast (IPv4) Composite
7:150.1.1.1:5:123456:32:172.30.10.1:32:232.0.0.2/240
*[PIM/105] 00:44:30
Multicast (IPv4) Composite

lab@VMX-R2> show route table VPN1-SPOKE.mvpn.0 extensive | find "^7:150.1.1.1"

7:150.1.1.1:5:123456:32:172.30.10.1:32:232.0.0.1/240 (1 entry, 1 announced)
*PIM Preference: 105
Next hop type: Multicast (IPv4) Composite
Address: 0x8f102e4
Next-hop reference count: 37
State: <Active Int Ext>
Age: 54:21
Task: PIM.VPN1-SPOKE
Announcement bits (2): 0-PIM.VPN1-SPOKE 1-mvpn global task
AS path: I
Communities: no-advertise target:150.1.1.1:7

lab@VMX-R2> show route table VPN1-SPOKE.inet.0 172.30.10.0/24 active-path extensive |

match Comm
Communities: target:18:3310 rt-import:150.1.1.1:7 src-as:123456L:0
<snip>

CE1-2 and CE1-3 have been preconfigured with IGMPv3 to join multicast groups 232.0.0.1, .2 and .3
respectively. So on the control-plane for each multicast group, there should be PIM join messanges sent
from the receiving PE routers R2, R8 to the sender PE router R1.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

lab@VMX-R2> show pim join inet instance VPN1-SPOKE extensive 232.0.0.1
Instance: PIM.VPN1-SPOKE Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

Group: 232.0.0.1
Source: 172.30.10.1
Flags: sparse,spt
Upstream protcol: BGP
Upstream interface: Through BGP
Upstream neighbor: Through MVPN
Upstream state: Local RP, Join to Source
Keepalive timeout: 1
Uptime: 00:33:13
Downstream neighbors:
Interface: ge-0/0/4.103
172.16.103.2 State: Join Flags: S Timeout: 157
Uptime: 00:33:13 Time since last Join: 00:00:53
Number of downstream interfaces: 1

lab@VMX-R8> show pim join inet instance VPN1-SPOKE extensive 232.0.0.1

Instance: PIM.VPN1-SPOKE Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

Group: 232.0.0.1
Source: 172.30.10.1

Flags: sparse,spt
Upstream protocol: BGP
Upstream interface: Through BGP
Upstream neighbor: Through MVPN
Upstream state: Local RP, Join to Source
Keepalive timeout:
Uptime: 01:16:09
Downstream neighbors:
Interface: ge-0/0/4.112
172.16.112.2 State: Join Flags: S Timeout: 200
Uptime: 01:16:09 Time since last Join: 00:00:09
Number of downstream interfaces: 1

lab@VMX-R1> show pim join inet instance VPN1-SPOKE extensive 232.0.0.1

Instance: PIM.VPN1-SPOKE Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

Group: 232.0.0.1
Source: 172.30.10.1
Flags: sparse,spt
Upstream interface: ge-0/0/4.118
Upstream neighbor: 172.16.118.2
Upstream state: Local RP, Join to Source
Keepalive timeout: 0
Uptime: 00:25:01
Downstream neighbors:
Interface: Pseudo-MVPN
Uptime: 00:25:01 Time since last Join: 00:24:59

Now let’s generate some test multicast streams from the CE1-1, destined to the multicast groups. We
would need to tune TTL to be different from the default value of 1.
lab@VMX-VR> ping routing-instance CE1-1 bypass-routing interface ge-0/0/8.118 ttl 64
interval 0.1 232.0.0.1 source 172.30.10.1 size 1000
PING 232.0.0.1 (232.0.0.1): 1000 data bytes

lab@VMX-VR> ping routing-instance CE1-1 bypass-routing interface ge-0/0/8.118 ttl 64

interval 0.1 232.0.0.2 source 172.30.10.1 size 1000
PING 232.0.0.1 (232.0.0.1): 1000 data bytes

lab@VMX-VR> ping routing-instance CE1-1 bypass-routing interface ge-0/0/8.118 ttl 64

interval 0.1 232.0.0.3 source 172.30.10.1 size 1000
PING 232.0.0.1 (232.0.0.1): 1000 data bytes

On the PE facing sources we should see that the source routes have been registered for the groups and
in Forwarding state, and likewise on the receiving PE.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

lab@VMX-R1> show multicast route inet instance VPN1-SPOKE extensive group 232.0.0.1
<snip>
Group: 232.0.0.1
Source: 172.30.10.1/32
Upstream interface: ge-0/0/4.118
Downstream interface list:
ge-0/0/2.0 ge-0/0/6.0
Session description: Source specific multicast
Statistics: 10 kBps, 10 pps, 14064 packets
Next-hop ID: 262149
Upstream protocol: MVPN
Route state: Active
Forwarding state: Forwarding
Cache lifetime/timeout: forever
Wrong incoming interface notifications: 0
Uptime: 00:31:26

lab@VMX-R2> show multicast route inet instance VPN1-SPOKE extensive group 232.0.0.1
<snip>
Group: 232.0.0.1
Source: 172.30.10.1/32
Upstream interface: lsi.0
Downstream interface list:
ge-0/0/4.103
Session description: Source specific multicast
Statistics: 10 kBps, 9 pps, 15679 packets
Next-hop ID: 262153

Upstream protocol: MVPN

Route state: Active
Forwarding state: Forwarding
Cache lifetime/timeout: forever
Wrong incoming interface notifications: 0
Uptime: 00:35:07

lab@VMX-R8> show multicast route inet instance VPN1-SPOKE extensive group 232.0.0.1
<snip>
Group: 232.0.0.1
Source: 172.30.10.1/32
Upstream interface: lsi.0
Downstream interface list:
ge-0/0/4.112
Session description: Source specific multicast
Statistics: 10 kBps, 10 pps, 24151 packets
Next-hop ID: 1048591
Upstream protocol: MVPN
Route state: Active
Forwarding state: Forwarding
Cache lifetime/timeout: forever
Wrong incoming interface notifications: 0
Uptime: 02:06:04

Before we wrap up the task, there is one important note that we need the knob vrf-table-label for
proper forwarding of MVPN-enabled VRFs since there is a need for performing double lookups after the
decapsulation of the multicast traffic receiveid from the PMSI Tunnels. The double lookups come from
the fact that MVPN-enabled PE routers need to update multicast routing entries in accordance to the
liveness of the multicast sources.

End of Practice Lab 4 Solutions!

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 4 Solutions

Practice Lab 5 Solutions

Topic 1: Device Infrastructure

Total Points: 7

Task 2 (3 points). Configure all routers so that they can utilise equal-cost paths on the data plane and
can achieve the best granularity when hashing packets across ECMP paths for IP/MPLS traffic, the
assumption is that this Service Provider Networks 1 and 2 use MX-series routers with MPC linecards.
Ensure that the nexthop structure is a function of both hashing scheme and low-order bits of IP address.
R1,R2,R3,R4,R5,R6,R7,R8
!
set policy-options policy-statement ECMP term ECMP then load-balance per-packet
set routing-options forwarding-table export ECMP
edit forwarding-options
set hash-key family inet layer-3
set hash-key family inet layer-4
set hash-key family mpls label-1
set hash-key family mpls label-2
set hash-key family mpls label-3
set hash-key family mpls payload ether-pseudowire
set hash-key family mpls payload ip port-data
set hash-key family multiservice payload ip layer-3
set hash-key family multiservice payload ip layer-4
set enhanced-hash-key family inet incoming-interface-index
set enhanced-hash-key family mpls incoming-interface-index
set enhanced-hash-key family multiservice incoming-interface-index
set load-balance indexed-load-balance
exit

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

lab@VMX-R5> op lsp-info interface ge-0/0/6.0
LSP Name LSP Type LSP State RESV BW Path Status
R5-TO-R7 Ingress Up 100kbps Link protected LSP
R5-TO-R8 Ingress Up 100kbps Node/Link protected LSP
Bypass->150.1.78.7 Transit Up 0bps
Bypass->150.1.68.8->150.1.78.7 Transit Up 0bps
Bypass->150.1.68.8 Transit Up 0bps

Some additional information that may assist you in creating the script:

• Use the following environment variables for the boilerplate:

version 1.0;
ns junos = "http://xml.juniper.net/junos/*/junos";
ns xnm = "http://xml.juniper.net/xnm/1.1/xnm";
ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0";

• The script should load all the code from the /var/db/scripts/ import/junos.xsl script file which
contains default templates and parameters.
• The script should obtain RSVP-signalled LSP information via API element equivalent to the CLI
command show rsvp session detailed.
/* SLAX script: source code */

tonytuan$ cat -n lsp-info.slax

1 version 1.0;
2 ns junos = "http://xml.juniper.net/junos/*/junos";
3 ns xnm = "http://xml.juniper.net/xnm/1.1/xnm";
4 ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0";
5 import "../import/junos.xsl";
6
7 /*
8 * This is a simple script which outputs RSVP information of MPLS LSPs
9 * that are currently traversing a given interface to the console.
10 * Sample output:
11 *
12 *lab@VMX-R5> op lsp-info interface ge-0/0/6.0
13 *LSP Name LSP Type LSP State RESV BW Path Status
14 *R5-TO-R7 Ingress Up 100kbps Link protected LSP
15 *R5-TO-R8 Ingress Up 100kbps Node/Link protected LSP
16 *Bypass->150.1.78.7 Transit Up 0bps
17 *Bypass->150.1.68.8->150.1.78.7 Transit Up 0bps
18 *Bypass->150.1.68.8 Transit Up 0bps
19 *
20 */
21
22 var $arguments = {
23 <argument> {
24 <name> "interface";
25 <description> "Name of MPLS interface";
26 }
27 }
28 param $interface;
29 match / {
30 <op-script-results> {
31 var $rsvp-rpc = {
32 <get-rsvp-session-information> {
33 <interface> $interface;
34 <detail>;
35 }
36 };
37 var $rsvp = jcs:invoke($rsvp-rpc);
38 <output> jcs:printf("LSP Name LSP Type LSP State RESV
BW Path Status\n");
39 for-each ($rsvp/rsvp-session-data/rsvp-session) {
40 var $bw = jcs:regex("rate (.*) size (.*)", sender-tspec);
41 <output> jcs:printf("%-30s %10s %5s %15s %20s\n", name, ../session-type, lsp-
state, $bw[2], rsvp-path-status);
42 }
43 }
44 }

/* SLAX script: enablement */

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

R1,R2,R3,R4,R5,R6,R7,R8
!
set system scripts op file lsp-info.slax

Task 2. JUNOS uses hashing and load-balancing mechanisms to share packets over equal-cost paths or
member interfaces of a LAG. On Juniper MX platforms, DPC linecards’ factors can be tweaked under the
forwarding-options hash-key stanza as examined in Practice Lab 1, topic 1, task 5 while newer MPC
linecards add extra factors under forwarding-options enhanced-hash-key stanza. Some reference URLs
are below:

https://www.juniper.net/documentation/en_US/junos12.3/topics/reference/configuration-
statement/hash-key-edit-forwarding-options.html

http://www.juniper.net/documentation/en_US/junos12.3/topics/reference/configuration-
statement/enhanced-hash-key-edit-forwarding-options.html

By default By default, MPCs use the following parameters for the calculation of a hash value which
determines the outgoing ports:

• Source IP address
• Destination IP address
• Layer 3 protocol
• Source port
• Destination port
• Generic routing encapsulation (GRE) for GRE packets only.

To check the factors being used by JUNOS hashing mechanism, we can use command request pfe
execute command "show jnh lb" target tfeb0 (MX80 platform). For other MX platforms, the command is
slightly different (due to modular forwarding architecture as opposed to the built-in packet forwarding
engine of MX80) request pfe execute command "show jnh lb" target fpc0. Below is sample output of
the shell command on vMX platform which is slightly different since vMX does not allow for running the
command right away from CLI mode, you will need to log on to the actual FPC0 to issue the command.
lab@VMX-R1> start shell user root
Password:
root@VMX-R1% vty fpc0

BSD platform (Pentium processor, 512MB memory, 0KB flash)

VMX(VMX-R1 vty)# show jnh lb

Unilist Seed Configured 0x00000000 System Mac address 00:00:00:00:00:00
Hash Key Configuration: 0x0000000000eb0000 0xffffffffffffffff
IIF-V4: Yes
SPORT-V4: Yes
DPORT-V4: Yes
TOS: No

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

GTP-TEID-V4: No

IIF-V6: No
SPORT-V6: Yes
DPORT-V6: Yes
TRAFFIC_CLASS: No
GTP-TEID-V6: No

IIF-MPLS: Yes
MPLS_PAYLOAD: Yes
MPLS_EXP: No

IIF-BRIDGED: Yes
MAC ADDRESSES: Yes
ETHER_PAYLOAD: Yes
802.1P OUTER: No

Services Hash Key Configuration:

SADDR-V4: No
DADDR-V4: No
IIF-V4: No

SADDR-V6: No
DADDR-V6: No
IIF-V6: No

Verification of equal-cost paths being available on the data plane will be carried out in the IGP topic
where we would have a route towards a destination using multiple IGP paths.

The indexed-load-balance statement causes the creation of a nexthop structure that is not a function of
the hash mechanism and the low-order bits of the IP address.

Task 3 examines some basic SLAX scripting capabilities on JUNOS platform, which is one of the two
scripting languages that JUNOS supports for automating routers’ operations. The other language is XSLT
which is originally designed for document conversion and written in XML format making it not quite
convenient for network engineers who do not come from a coding/programming background. For
brevity, this book won’t discuss in detailed of how JUNOS platform processes XSLT/SLAX scripts but
instead the making of a simple script that provides outputs similar to show command but in a more
intuitive and concise way, making it easier for network operators. This way you can start writing your
own scripts and study more complex functions of SLAX scripting later. There are a couple of useful
resources that you may want to do some self-study:

https://www.juniper.net/uk/en/training/jnbooks/day-one/automation-series/applying-junos-
automation/

https://www.juniper.net/us/en/training/jnbooks/day-one/automation-series/mastering-junos-
automation/

Now with regard to JUNOS automation, there are 3 types of SLAX script that can be used:

• Operation (op) scripts signals JUNOS actions to take when the script is called/run through CLI or
by another script.
• Event scripts signals JUNOS actions to take in response to occurrence(s) of events captured via
Syslog for example.
• Commit scripts signals JUNOS actions to take during the commit process of activating
configuration changes, which may be to ensure certain conditions to be true.

You may notice from the sample output that the SLAX script is actually an operation one which would be

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

executed from CLI mode. Let’s start with writing the script: The first portion (lines 1-5) is the boilerplate
which provides standard name-space URLs via ns statement and also the import statement which loads
all the code from the /var/db/scripts/ import/junos.xsl script file which contains default templates
and parameters. The next part (lines 7-20) provides short description of the script and a sample output.
This is very useful and saves time when reviewing the script’s logic, particularly for first-time reader. The
script takes one input variable being the MPLS interface so we need to define it, see lines 22-27. The
argument value is then taken into a parameter, i.e line 28.
lab@VMX-R5> op lsp-info ?
Possible completions:
<[Enter]> Execute this command
<name> Argument name
detail Display detailed output
interface Name of MPLS interface
invoke-debugger Invoke script in debugger mode
| Pipe through a command

The main function of the script is actually from line 29 until the end of it where we define the RPC call
that obtains the LSP information for us, invoked by statement jcs:invoke($rsvp-rpc) in lines 32 and 37.

The combination of lines 32, 33, 34 can be compared to the CLI command show rsvp session $interface
detail. Being equivalent to that command, our RPC call uses API element <get-rsvp-session-
information>. Question is how do we know the name of such API element. It is actually quite easy to
figure that out with the knob display xml. You can see below that the highlighted lines correspond to
the data extraction of the script.
lab@VMX-R5> show rsvp session interface ge-0/0/6.0 detail | display xml
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/13.3I0/junos">
<rsvp-session-information xmlns="http://xml.juniper.net/junos/13.3I0/junos-routing">
<rsvp-session-data>
<session-type>Ingress</session-type>
<count>11</count>
<rsvp-session junos:style="detail">
<destination-address>150.1.1.7</destination-address>
<source-address>150.1.1.5</source-address>
<lsp-state>Up</lsp-state>
<route-count>0</route-count>
<name>R5-TO-R7</name>
<lsp-path-type>Primary</lsp-path-type>
<mpls-lsp-type>Static Configured</mpls-lsp-type>
<suggested-label-in>-</suggested-label-in>
<suggested-label-out>-</suggested-label-out>
<recovery-label-in>-</recovery-label-in>
<recovery-label-out>0</recovery-label-out>
<rsb-count>1</rsb-count>
<resv-style>SE</resv-style>
<label-in>-</label-in>
<label-out>0</label-out>
<psb-lifetime> -</psb-lifetime>
<psb-creation-time>Thu Feb 2 01:57:40 2017
</psb-creation-time>
<sender-tspec>rate 100kbps size 100kbps peak Infbps m 20 M 9192</sender-tspec>
<lsp-id>24</lsp-id>
<tunnel-id>44381</tunnel-id>
<proto-id>0</proto-id>
<lsp-attribute-flags>
</lsp-attribute-flags>
<is-nodeprotection/>
<is-soft-preemption/>
<rsvp-path-status>Link protected LSP</rsvp-path-status>
<packet-information heading=" PATH">
<previous-hop>localclient</previous-hop>
</packet-information>
<adspec>sent MTU 1986</adspec>
<path-mtu>1986</path-mtu>
<packet-information heading=" PATH">

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

<next-hop>150.1.57.7</next-hop>
<interface-name>ge-0/0/6.0</interface-name>
<count>110</count>
</packet-information>
<packet-information heading=" RESV">
<previous-hop>150.1.57.7</previous-hop>
<interface-name>ge-0/0/6.0</interface-name>
<count>88</count>
<entropy-label>No</entropy-label>
</packet-information>
<explicit-route heading=" Explct route: ">
<address>150.1.57.7</address>
</explicit-route>
<record-route heading=" Record route: ">
<self/>
<address>150.1.1.7 (node-id)</address>
<address>150.1.57.7</address>
</record-route>
</rsvp-session>
<omitted-for-brevity>

As you can see, the values in the row LSP Name is taken from element <name>R5-TO-R7</name>, LSP Type
is taken from element <session-type>Ingress</session-type> and so on. Particularly for the bandwidth
value, we do not want to capture the whole line, but instead just the number after keyword size, hence

we would need to leverage regular expression matching with statement jcs:regex and specifying the
second value (.*) with $bandwidth[2] in line 41. Now in order to print out the data collected from the
RPC call, we use statement jcs:printf in lines 38 and 41. Line 38 actually is just to print a string that
specifies column names. Line 41 is quite interesting with 5 placeholder starting with % sign. Each of them
specifies the position of the column in the output. The %-30s indicates that a string value is inserted in a
30 space column that is left justified. And because it is the first placeholder, it corresponds to the first
column being LSP Name. From here you can easily figure out that the next one being %10s indicates that
a string value is inserted in a 10 space column that is right justified and corresponds to column LSP Type.
The last part of the task is to declare the script in the configuration of the router with statement op file
under system scripts stanza. We also should randomly check the operation of the script on several
routers to ensure it is functioning properly.
lab@VMX-R2> op lsp-info interface ge-0/0/6.0
LSP Name LSP Type LSP State RESV BW Path Status
R2-TO-R1 Ingress Up 100kbps Node/Link protected LSP
R2-TO-R3 Ingress Up 100kbps Node/Link protected LSP
R2-TO-R4 Ingress Up 100kbps Link protected LSP
Bypass->150.1.13.3 Transit Up 0bps
Bypass->150.1.13.3->150.1.34.4 Transit Up 0bps

Topic 2: IGP
Total Points: 10

R1,R2,R3,R4,R5,R6,R7,R8
!
edit groups CORE-INTERFACES
set interfaces <ge-0/0/[2678]> unit 0 family iso
set protocols isis interface <ge-0/0/[2678].0> point-to-point
set protocols isis interface <ge-0/0/[2678].0> hello-authentication-type md5
set protocols isis interface <ge-0/0/[2678].0> hello-authentication-key JNCIE

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

set protocols isis interface <ge-0/0/[2678].0> bfd minimum-interval 250 multiplier 4
set protocols isis interface <ge-0/0/[2678].0> link-protection
exit
set apply-groups CORE-INTERFACES
set protocols isis reference-bandwidth 100g
set protocols isis interface lo0.0 passive
set policy-options policy-statement ECMP term ECMP then load-balance per-packet
set routing-options forwarding-table export ECMP

R3,R4,R5,R6
!
set protocols isis export L2-TO-L1
edit policy-options policy-statement L2-TO-L1
set term 4 from protocol isis
set term 4 from route-filter 150.1.1.0/24 prefix-length /32-/32
set term 4 to level 1
set term 4 then accept
set term 6 from protocol isis
set term 6 from route-filter 2016:150:1:1::/64 prefix-length /128-/128
set term 6 to level 1
set term 6 then accept
exit

R1
!
set interface lo0.0 family iso address 49.0018.1501.1000.0001.00
set protocols isis level 2 disable

set protocols isis interface ge-0/0/2.0

set protocols isis interface ge-0/0/6.0

R2
!
set interface lo0.0 family iso address 49.0018.1501.1000.0002.00
set protocols isis level 2 disable
set protocols isis interface ge-0/0/2.0
set protocols isis interface ge-0/0/6.0

R3
!
set interface lo0.0 family iso address 49.0018.1501.1000.0003.00
set protocols isis interface ge-0/0/2.0
set protocols isis interface ge-0/0/6.0 level 2 disable
set protocols isis interface ge-0/0/7.0 level 1 disable

R4
!
set interface lo0.0 family iso address 49.0018.1501.1000.0004.00
set protocols isis interface ge-0/0/2.0
set protocols isis interface ge-0/0/6.0 level 2 disable
set protocols isis interface ge-0/0/7.0 level 1 disable
set protocols isis interface ge-0/0/8.0 level 1 disable

R5
!
set interface lo0.0 family iso address 49.0018.1501.1000.0005.00
set protocols isis interface ge-0/0/2.0
set protocols isis interface ge-0/0/6.0 level 2 disable
set protocols isis interface ge-0/0/7.0 level 1 disable
set protocols isis interface ge-0/0/8.0 level 1 disable

R6
!
set interface lo0.0 family iso address 49.0018.1501.1000.0006.00
set protocols isis interface ge-0/0/2.0
set protocols isis interface ge-0/0/6.0 level 2 disable
set protocols isis interface ge-0/0/7.0 level 1 disable

R7
!
set interface lo0.0 family iso address 49.0018.1501.1000.0007.00
set protocols isis level 2 disable
set protocols isis interface ge-0/0/2.0
set protocols isis interface ge-0/0/6.0

R8
!
set interface lo0.0 family iso address 49.0018.1501.1000.0008.00

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

set protocols isis level 2 disable
set protocols isis interface ge-0/0/2.0
set protocols isis interface ge-0/0/6.0

Task 3 (4 points). Configure the following IS-IS features:

• Allow IS-IS path metric to scale over the value of 1023.

worked on will still be the last-resort device for traffic. Ensure that L1-L2 routing will still work
across the device.
• The Service Provider strictly controls MTU value across its core links, ensure that after
initialisation of IS-IS adjacency, IIH messages produced by IS-IS routers do not negatively strain
routers’ buffers.
• Maximally reduce the amount of control traffic generated by IS-IS.
• Create separate topologies for IPv4 and IPv6 routing information.

R1,R2,R3,R4,R5,R6,R7,R8
!
edit protocols isis
set level 1 wide-metrics-only
set level 2 wide-metrics-only
set overload timeout 1800
set overload advertise-high-metrics
set overload allow-route-leaking
set lsp-lifetime 65535
set topologies ipv6-unicast
exit
edit groups CORE-INTERFACES
set protocols isis interface <ge-0/0/[2678].0> hello-padding loose
exit

At the end of this topic, all routers should have full IPv4 and IPv6 reachability with each other’s
loopback0 networks.

Verification
Tasks 1 and 2. Before discussing details of the topic, please be advised that the idea of Practice Lab 5 is
to create a large-scale Service Provider Network spanning across multiple points of presence (POPs).
Each POP runs IS-IS level 1 and is interconnected with other POPs via IS-IS level 2. From design
perspectives, this isolates failures inside a POP from being flooded to other POPs, enhancing stability of
the network overall as level 2 routing information is not leaked to level 1 by default. In the current
Practice Lab 5, there are two POPs, one includes R1, R2, R3, R4 and the other includes R5, R6, R7, R8.

Task 1 starts the IGP section with configuration of multi-level IS-IS. You can start the task right away but
if you take a step back and read through the whole IGP section, you would notice that you can combine

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

multiple tasks into one configuration effort and also the best uniformed way to do it. Again, this book
emphasises the implementation of group-based configuration which not only saves work cycles but also
ensures the consistency of your configuration on a system-wide basis. We would use the group CORE-
INTERFACES to define IS-IS link attributes while still mention IS-IS interfaces under protocols isis
interface stanza.

Task 1 requires that IPv4 loopback addresses are embedded into the IS-IS NET address. This requirement
is actually one of best practices and only expects you to configure the System ID portion of the NET
address with the insertion of loopback address, e.g. 49.0018.1501.1000.0001.00 for 150.1.1.1 on R1.
Task 1 also requires that IS-IS should not attempt to establish neighbourship over loopback interfaces,
which is achieved by adding statement passive. Now we should start with verifying IS-IS adjacency.
lab@VMX-R1> show isis adjacency
Interface System L State Hold (secs) SNPA
ge-0/0/2.0 VMX-R2 1 Up 20
ge-0/0/6.0 VMX-R3 1 Up 26

lab@VMX-R2> show isis adjacency

Interface System L State Hold (secs) SNPA
ge-0/0/2.0 VMX-R1 1 Up 22

ge-0/0/6.0 VMX-R4 1 Up 23

lab@VMX-R3> show isis adjacency

Interface System L State Hold (secs) SNPA
ge-0/0/2.0 VMX-R4 3 Up 20
ge-0/0/6.0 VMX-R1 1 Up 21
ge-0/0/7.0 VMX-R5 2 Up 26

lab@VMX-R4> show isis adjacency

Interface System L State Hold (secs) SNPA
ge-0/0/2.0 VMX-R3 3 Up 25
ge-0/0/6.0 VMX-R2 1 Up 19
ge-0/0/7.0 VMX-R6 2 Up 24
ge-0/0/8.0 VMX-R5 2 Up 20

lab@VMX-R5> show isis adjacency

Interface System L State Hold (secs) SNPA
ge-0/0/2.0 VMX-R6 3 Up 25
ge-0/0/6.0 VMX-R7 1 Up 19
ge-0/0/7.0 VMX-R3 2 Up 25
ge-0/0/8.0 VMX-R4 2 Up 21

lab@VMX-R6> show isis adjacency

Interface System L State Hold (secs) SNPA
ge-0/0/2.0 VMX-R5 3 Up 22
ge-0/0/6.0 VMX-R8 1 Up 25
ge-0/0/7.0 VMX-R4 2 Up 26

lab@VMX-R7> show isis adjacency

Interface System L State Hold (secs) SNPA
ge-0/0/2.0 VMX-R8 1 Up 25
ge-0/0/6.0 VMX-R5 1 Up 22

lab@VMX-R8> show isis adjacency

Interface System L State Hold (secs) SNPA
ge-0/0/2.0 VMX-R7 1 Up 24
ge-0/0/6.0 VMX-R6 1 Up 25

You may notice four highlighted lines denoted with level ‘3’. However this is actually a combination of
both IS-IS levels 1 and 2 as the protocol does not have level 3 definition. By default when you enable an
interface in IS-IS, it will run in both levels. However since we actually define the level we want to run in
our network, we can simply disable level that is not needed with statement disable at the protocols
isis interface stanza. This also would help optimise routers’ resources.

By default across IS-IS level boundary, all IS-IS level 1 routing information is propagated into IS-IS level 2

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

but it is not the case on the way back (multilevel IS-IS works similarly to an OSPF NSSA area). IS-IS router
with level 2 adjacency would inject default route into its level 1 to provide inter-area reachability. IS-IS
implementation on JUNOS does not perform such injection by default, hence we may need to explicitly
configure default routes for level 1 injection with statement to level 1 in the policy statement, and
remember to do it for both IPv4 and IPv6 stacks as IS-IS in this task is used to do routing for both stacks.
That is exactly what we did in Practice Lab 3, topic 2. However the current topic does not allow for usage
of static route. Hence the only way to accommodate IS-IS level 1 routing is to create policies that leak
routes from level 2 to level 1 using statement to level 1 within policy-statement stanza. Obviously we
can leak all routes, however since the goal of the topic is to ensure routers have reachability ot each
other’s loopback0 and in the topic 3, MPLS, we do not have any LSP statically configured with ERO, we
can simply just leak loopback0 addresses, hence the prefix-length-range statement in the policies. We
should ensure the routes are leaked properly. As can be seen below, level 1 IS-IS routes have got
AD=15while level 2 IS-IS routes have got AD=18.
lab@VMX-R8> show route protocol isis table inet.0 active-path | match IS-IS
150.1.1.1/32 *[IS-IS/18] 00:25:54, metric 400
150.1.1.2/32 *[IS-IS/18] 01:24:15, metric 300
150.1.1.3/32 *[IS-IS/18] 00:25:54, metric 300

150.1.1.4/32 *[IS-IS/18] 01:24:15, metric 200

150.1.1.5/32 *[IS-IS/15] 00:28:53, metric 200
150.1.1.6/32 *[IS-IS/15] 01:24:15, metric 100
150.1.1.7/32 *[IS-IS/15] 01:59:22, metric 100
150.1.1.250/32 *[IS-IS/15] 01:24:15, metric 100
150.1.56.0/24 *[IS-IS/15] 01:24:15, metric 200
150.1.57.0/24 *[IS-IS/15] 00:28:53, metric 200

lab@VMX-R8> show route protocol isis table inet6.0 active-path | match IS-IS
2016:150:1:1::1/128*[IS-IS/18] 00:26:02, metric 400
2016:150:1:1::2/128*[IS-IS/18] 01:24:33, metric 300
2016:150:1:1::3/128*[IS-IS/18] 00:26:02, metric 300
2016:150:1:1::4/128*[IS-IS/18] 01:24:33, metric 200
2016:150:1:1::5/128*[IS-IS/15] 00:28:59, metric 200
2016:150:1:1::6/128*[IS-IS/15] 01:24:33, metric 100
2016:150:1:1::7/128*[IS-IS/15] 01:59:28, metric 100
2016:150:1:56::/64 *[IS-IS/15] 01:24:33, metric 200
2016:150:1:57::/64 *[IS-IS/15] 01:59:28, metric 200

For task 2, the point-to-point interface type would remove uncessary DIS election on every Ethernet
interface that has got only 2 neighbours, reducing establishment time for IS-IS adjacency. Meanwhile
the BFD would verify bidirectional connectivity and help IS-IS detect failure in a sub-second manner
rather than relying on interface status. Another advantage is that we won’t need to implement Fast-
Hello feature for IS-IS which may have severe impact on CPU resources, rather we only need just one
single BFD function for all routing protocols including RSVP and BGP subsequently.
lab@VMX-R5> show bfd session
Detect Transmit
Address State Interface Time Interval Multiplier
<snip>
150.1.35.3 Up ge-0/0/7.0 1.000 0.250 4
150.1.45.4 Up ge-0/0/8.0 1.000 0.250 4
150.1.56.6 Up ge-0/0/2.0 1.000 0.250 4
150.1.57.7 Up ge-0/0/6.0 1.000 0.250 4
<snip>

lab@VMX-R5> show bfd session detail

<snip>
Detect Transmit
Address State Interface Time Interval Multiplier
150.1.35.3 Up ge-0/0/7.0 1.000 0.250 4
Client ISIS L2, TX interval 0.250, RX interval 0.250
Session up time 00:29:27, previous down time 00:00:03
Local diagnostic None, remote diagnostic NbrSignal
Remote state Up, version 1

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

Session type: Single hop BFD
Detect Transmit
Address State Interface Time Interval Multiplier
150.1.45.4 Up ge-0/0/8.0 1.000 0.250 4
Client ISIS L2, TX interval 0.250, RX interval 0.250
Session up time 00:29:16, previous down time 00:00:00
Local diagnostic NbrSignal, remote diagnostic None
Remote state Up, version 1
Session type: Single hop BFD
Detect Transmit
Address State Interface Time Interval Multiplier
150.1.56.6 Up ge-0/0/2.0 1.000 0.250 4
Client ISIS L3, TX interval 0.250, RX interval 0.250
Session up time 00:29:30, previous down time 00:00:11
Local diagnostic NbrSignal, remote diagnostic NbrSignal
Remote state Up, version 1
Session type: Single hop BFD
Detect Transmit
Address State Interface Time Interval Multiplier
150.1.57.7 Up ge-0/0/6.0 1.000 0.250 4
Client ISIS L1, TX interval 0.250, RX interval 0.250
Session up time 02:08:27, previous down time 00:00:01
Local diagnostic None, remote diagnostic NbrSignal
Remote state Up, version 1
Session type: Single hop BFD
<snip>

An interesting part of task 2 is about enabling IS-IS LFA capability with statement link-protection which
activates the operation of a second SPF calculation which provides alternate paths for IS-IS routes. These
alternate paths are loop free and can be used immediately upon failure of the primary paths. The
concept of IS-IS LFA feature is somewhat similar to EIGRP feasible successor mechanism. IS-IS LFA will
build alternate paths for each IS-IS level individually just like SPF computation for different LSDBs. You
may notice there are two topologies for each level, denoted as IPV4/IPV6 Unicast, this is due to the fact
that IS-IS runs in multi-topology mode (discussed in task 4).
lab@VMX-R6> show isis backup coverage
Backup Coverage:
Topology Level Node IPv4 IPv6 CLNS
IPV4 Unicast 1 100.00% 66.67% 0.00% 0.00%
IPV4 Unicast 2 100.00% 100.00% 0.00% 0.00%
IPV6 Unicast 1 33.33% 0.00% 20.00% 0.00%
IPV6 Unicast 2 100.00% 0.00% 100.00% 0.00%

lab@VMX-R6> show isis backup spf results topology unicast

<snip>
VMX-R5.00
Primary next-hop: ge-0/0/2.0, IPV4, VMX-R5, SNPA: 00:05:86:71:3d:05
Primary next-hop: ge-0/0/7.0, LSP, R6-TO-R5
Primary next-hop: ge-0/0/2.0, LSP, R6-TO-R5
Root: VMX-R5, Root Metric: 100, Metric: 0, Root Preference: 0x0
Not eligible, IPV4, Reason: Primary next-hop link fate sharing
Not eligible, LSP, Reason: Primary next-hop multipath
Root: VMX-R4, Root Metric: 100, Metric: 100, Root Preference: 0x0
track-item: VMX-R5.00-00, neighbor: VMX-R4.00
Eligible, Backup next-hop: ge-0/0/7.0, IPV4, VMX-R4, SNPA: 00:05:86:71:33:07
Not eligible, LSP, Reason: Primary next-hop multipath
<snip>

A backup next-hop is considered to be loop-free if the result of the backup SPF calculation does not
point back to the node which performs the local repair upon network failure event. The following
formula is used to determine that condition: Distance(N,D) < Distance(N,S) + Distance(S,D) where S is
the node performing local repair, D is destination node and N is neighbor node that is examined to be
used as a potential backup next hop.

Best practices indicate that when configuring LFA, a “per-packet” load-balancing routing policy should
be configured to ensure that IS-IS process installs all next hops for a given route in the routing table.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

Task 3 examines advanced tuning features of IS-IS following industry best practices for MPLS-based
Service Providers. It starts with overload bit (OL) which is an important component of IS-IS allowing for
taking the router out of services or ensure it is not able to carry traffic. This is slightly different from
OSPF behaviour as an overloaded OSPF router may still carry traffic if it is the only option. However an
overloaded IS-IS router won’t carry traffic within IS-IS routing domain. Therefore to avoid blackholing
scenarios, we may want to allow overloaded IS-IS router to carry traffic with statement overload
advertise-high-metrics under protocols isis stanza. This way overloaded IS-IS router would advertise
maximum IS-IS cost towards all other routers in its advertisement instead of setting OL bit, signalling
that it does not wish to carry any traffic using IS-IS routes. Another point is that OL bit being set would
cause any route-leaking policies to cease. Because we want the overloaded IS-IS routers to be able to
carry traffic if they are the only option, we need to configure the knob overload allow-route-leaking as

well. In order to verify overload state, we can restart the RPD process on R3 and observe that a timeout
of 1800 seconds is counted down.
lab@VMX-R3> restart routing
Routing protocols process started, pid 24141

lab@VMX-R3> show isis overview

Instance: master
Router ID: 150.1.1.3
Adjacency holddown: enabled
Maximum Areas: 3
LSP life time: 65535
Reference bandwidth: 100000000000
Attached bit evaluation: enabled
SPF delay: 200 msec, SPF holddown: 5000 msec, SPF rapid runs: 3
Overload bit at startup is set
Overload high metrics: enabled
Allow route leaking: enabled
Overload timeout: 1800 sec, expires in 1795 seconds
IPv4 is enabled, IPv6 is enabled
Traffic engineering: enabled
IPv4 Traffic engineering shortcuts are enabled
Restart: Disabled
Helper mode: Enabled
Level 1
Internal route preference: 15
External route preference: 160
Wide metrics are enabled
Level 2
Internal route preference: 18
External route preference: 165
Wide metrics are enabled

By default IS-IS operates in narrow metric style which allows for interface cost to be within 1-63 range
which is not scalable for Service Provider networks today. Using wide style, IS-IS is allowed to grow
metric scale to 1- 16777215, and metric of a route can be higher than 1023. Next, using lsp-lifetime
statement, we can reduce the amount of LSP messages generated by allowing LSP to live longer, i.e.
from 1200sec by default to a higher value. Since the task requires maximal reduction, we configure the
highest possible value of 65535.

When there is a need to have separate topologies for IPv4 and IPv6, we can tune IS-IS with knob
topologies under protocols isis stanza. This would also increase the CPU utilisation to process IS-IS.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

Normally we should unify IPv4 and IPv6 topologies for consistency.

Default behaviour of IS-IS on JUNOS is that since it is an OSI layer 2 protocol, it does not support data
fragmentation, during IS-IS adjacency establishment, JUNOS makes sure the medium supports 1492
bytes packet-size by padding outgoing hello packets up to the maximum packet size of 1492 bytes.
However always doing so may strain huge buffers on high speed links or waste bandwidth of low speed
links. Nowadays Service Provider Networks strictly control MTU value in the core, it would be enough to
allow for hello-padding during initialisation of IS-IS adjacency, hence the statement hello-padding loose
under protocols isis interface stanza. Since we configure all attributes of IS-IS interfaces in the group
CORE-INTERFACES, we should continue to add the feature into that group accordingly rather than on a
per-link basis manually.

At the end of this topic, we should verify IPv4 and IPv6 reachability within Service Provider Network,
particularly between loopback interfaces of the routers as it would be instrumental for the upcoming
tasks.
lab@VMX-R1> ping rapid source 150.1.1.1 150.1.1.2
PING 150.1.1.2 (150.1.1.2): 56 data bytes

!!!!!
--- 150.1.1.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.662/2.017/2.572/0.343 ms

lab@VMX-R1> ping rapid source 150.1.1.1 150.1.1.3

PING 150.1.1.3 (150.1.1.3): 56 data bytes
!!!!!
--- 150.1.1.3 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.036/2.440/3.603/0.589 ms

lab@VMX-R1> ping rapid source 150.1.1.1 150.1.1.4

PING 150.1.1.4 (150.1.1.4): 56 data bytes
!!!!!
--- 150.1.1.4 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.468/2.930/3.240/0.310 ms

lab@VMX-R1> ping rapid source 150.1.1.1 150.1.1.5

PING 150.1.1.5 (150.1.1.5): 56 data bytes
!!!!!
--- 150.1.1.5 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.688/3.716/6.185/1.297 ms

lab@VMX-R1> ping rapid source 150.1.1.1 150.1.1.6

PING 150.1.1.6 (150.1.1.6): 56 data bytes
!!!!!
--- 150.1.1.6 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.579/4.359/5.888/0.795 ms

lab@VMX-R1> ping rapid source 150.1.1.1 150.1.1.7

PING 150.1.1.7 (150.1.1.7): 56 data bytes
!!!!!
--- 150.1.1.7 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.423/4.054/5.211/0.652 ms

lab@VMX-R1> ping rapid source 150.1.1.1 150.1.1.8

PING 150.1.1.8 (150.1.1.8): 56 data bytes
!!!!!
--- 150.1.1.8 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 4.541/5.169/5.953/0.525 ms

lab@VMX-R1> ping rapid source 2016:150:1:1::1 2016:150:1:1::2

PING6(56=40+8+8 bytes) 2016:150:1:1::1 --> 2016:150:1:1::2
!!!!!

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

--- 2016:150:1:1::2 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 1.501/1.999/3.565/0.798 ms

lab@VMX-R1> ping rapid source 2016:150:1:1::1 2016:150:1:1::3

PING6(56=40+8+8 bytes) 2016:150:1:1::1 --> 2016:150:1:1::3
!!!!!
--- 2016:150:1:1::3 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 1.832/2.615/4.086/0.817 ms

lab@VMX-R1> ping rapid source 2016:150:1:1::1 2016:150:1:1::4

PING6(56=40+8+8 bytes) 2016:150:1:1::1 --> 2016:150:1:1::4
!!!!!
--- 2016:150:1:1::4 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 2.177/2.766/3.923/0.625 ms

lab@VMX-R1> ping rapid source 2016:150:1:1::1 2016:150:1:1::5

PING6(56=40+8+8 bytes) 2016:150:1:1::1 --> 2016:150:1:1::5
!!!!!
--- 2016:150:1:1::5 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 2.737/2.918/3.189/0.196 ms

lab@VMX-R1> ping rapid source 2016:150:1:1::1 2016:150:1:1::6

PING6(56=40+8+8 bytes) 2016:150:1:1::1 --> 2016:150:1:1::6

!!!!!
--- 2016:150:1:1::6 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 3.296/3.613/4.296/0.367 ms

lab@VMX-R1> ping rapid source 2016:150:1:1::1 2016:150:1:1::7

PING6(56=40+8+8 bytes) 2016:150:1:1::1 --> 2016:150:1:1::7
!!!!!
--- 2016:150:1:1::7 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 3.281/4.069/5.809/1.022 ms

lab@VMX-R1> ping rapid source 2016:150:1:1::1 2016:150:1:1::8

PING6(56=40+8+8 bytes) 2016:150:1:1::1 --> 2016:150:1:1::8
!!!!!
--- 2016:150:1:1::8 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 4.627/5.676/6.703/0.843 ms

Topic 3: MPLS
Total Points: 14

Task 1 (2 points). Configure IS-IS to build TE database for the Service Provider Network; ensure the
tailend router is the one who removes MPLS stack instead of the penultimate router.
R1,R2,R3,R4,R5,R6,R7,R8
!
set groups CORE-INTERFACES interfaces <ge-0/0/[2678]> unit 0 family mpls
set protocols mpls interface all
set protocols mpls explicit-null

Task 2 (10 points). Configure two tiers of RSVP-signaled LSPs between routers of the Service Provider
Network with the following characteristics.

• Tier-1 LSP: full-mesh between R3, R4, R5, R6.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

it at least 30sec to find an alternative path before tearing it down.
• All LSPs’ bandwidth usage should be monitored and adjusted for better path every 1 hour and
ensure that the newly optimised path is established before old path is torn down for
reoptimisation activities.
o Bandwidth range is from 100Kbps to 10Gbps.
o Only update bandwidth usage only if the new figure is higher than the old one by 20%.
o Trigger an early bandwidth update if there are more than 2 consecutive overflow
samples.
o Trigger an early bandwidth update if there are more than 2 consecutive underflow
samples.
o Statistics of bandwidth usage should be recorded every 10 minutes into files called
autobw.log for diagnostic purpose. The biggest file size should be 1MB and the routers
should store up to 10 files. Please do not record statistics of transit LSPs.
• All LSPs should be re-routed within tens of milliseconds upon failure of any node within the core
network.
• Bidirectional forwarding capability of each LSP should be verified and signalled within 1 second.

• When equal cost paths exist, all LSPs should randomly select the best one to follow.
• Please use the most efficient configuration method to group common attributes of LSPs.
• Ensure that all MPLS-based services such as L3VPN, L2VPN, 6PE can function across the two tiers
of LSP.
R1,R2,R3,R4,R5,R6,R7,R8
!
set protocols rsvp interface all link-protection
set protocols isis traffic-engineering family inet shortcuts
edit groups LSP-GROUP-CORE protocols mpls label-switched-path <*>
set soft-preemption
set node-link-protection
set auto-bandwidth minimum-bandwidth 100k
set auto-bandwidth maximum-bandwidth 10g
set auto-bandwidth adjust-interval 3600
set auto-bandwidth adjust-threshold 15
set auto-bandwidth adjust-threshold-overflow-limit 2
set auto-bandwidth adjust-threshold-underflow-limit 2
set adaptive
set oam bfd minimum-interval 500 multiplier 4
set random
exit
edit protocols mpls statistics
set file autobw.log size 1m files 10
set interval 600
set auto-bandwidth
set no-transit-statistics
exit
set apply-groups LSP-GROUP-CORE
set interface lo0 unit 0 family inet address 127.0.0.1/32

R1
!
edit protocols mpls
set label-switched-path R1-TO-R2 to 150.1.1.2 desc LSP-TIER-2 priority 6 6
set label-switched-path R1-TO-R3 to 150.1.1.3 desc LSP-TIER-2 priority 6 6
set label-switched-path R1-TO-R4 to 150.1.1.4 desc LSP-TIER-2 priority 6 6
exit
set interface lo0 unit 0 family inet address 150.1.1.1/32 primary

R2
!
edit protocols mpls
set label-switched-path R2-TO-R1 to 150.1.1.1 desc LSP-TIER-2 priority 6 6
set label-switched-path R2-TO-R3 to 150.1.1.3 desc LSP-TIER-2 priority 6 6
set label-switched-path R2-TO-R4 to 150.1.1.4 desc LSP-TIER-2 priority 6 6

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

exit
set interface lo0 unit 0 family inet address 150.1.1.2/32 primary

R3
!
edit protocols mpls
set label-switched-path R3-TO-R1 to 150.1.1.1 desc LSP-TIER-2 priority 6 6
set label-switched-path R3-TO-R2 to 150.1.1.2 desc LSP-TIER-2 priority 6 6
set label-switched-path R3-TO-R4 to 150.1.1.4 desc LSP-TIER-1 priority 5 5
set label-switched-path R3-TO-R5 to 150.1.1.5 desc LSP-TIER-1 priority 5 5
set label-switched-path R3-TO-R6 to 150.1.1.6 desc LSP-TIER-1 priority 5 5
exit
set interface lo0 unit 0 family inet address 150.1.1.3/32 primary

R4
!
edit protocols mpls
set label-switched-path R4-TO-R1 to 150.1.1.1 desc LSP-TIER-2 priority 6 6
set label-switched-path R4-TO-R2 to 150.1.1.2 desc LSP-TIER-2 priority 6 6
set label-switched-path R4-TO-R3 to 150.1.1.3 desc LSP-TIER-1 priority 5 5
set label-switched-path R4-TO-R5 to 150.1.1.5 desc LSP-TIER-1 priority 5 5
set label-switched-path R4-TO-R6 to 150.1.1.6 desc LSP-TIER-1 priority 5 5
exit
set interface lo0 unit 0 family inet address 150.1.1.4/32 primary

R5
!
edit protocols mpls

set label-switched-path R5-TO-R7 to 150.1.1.7 desc LSP-TIER-2 priority 6 6

set label-switched-path R5-TO-R8 to 150.1.1.8 desc LSP-TIER-2 priority 6 6
set label-switched-path R5-TO-R3 to 150.1.1.3 desc LSP-TIER-1 priority 5 5
set label-switched-path R5-TO-R4 to 150.1.1.4 desc LSP-TIER-1 priority 5 5
set label-switched-path R5-TO-R6 to 150.1.1.6 desc LSP-TIER-1 priority 5 5
exit
set interface lo0 unit 0 family inet address 150.1.1.5/32 primary

R6
!
edit protocols mpls
set label-switched-path R6-TO-R7 to 150.1.1.7 desc LSP-TIER-2 priority 6 6
set label-switched-path R6-TO-R8 to 150.1.1.8 desc LSP-TIER-2 priority 6 6
set label-switched-path R6-TO-R3 to 150.1.1.3 desc LSP-TIER-1 priority 5 5
set label-switched-path R6-TO-R4 to 150.1.1.4 desc LSP-TIER-1 priority 5 5
set label-switched-path R6-TO-R5 to 150.1.1.5 desc LSP-TIER-1 priority 5 5
exit
set interface lo0 unit 0 family inet address 150.1.1.6/32 primary

R7
!
edit protocols mpls
set label-switched-path R7-TO-R8 to 150.1.1.8 desc LSP-TIER-2 priority 6 6
set label-switched-path R7-TO-R5 to 150.1.1.5 desc LSP-TIER-2 priority 6 6
set label-switched-path R7-TO-R6 to 150.1.1.6 desc LSP-TIER-2 priority 6 6
exit
set interface lo0 unit 0 family inet address 150.1.1.7/32 primary

R8
!
edit protocols mpls
set label-switched-path R8-TO-R7 to 150.1.1.7 desc LSP-TIER-2 priority 6 6
set label-switched-path R8-TO-R5 to 150.1.1.5 desc LSP-TIER-2 priority 6 6
set label-switched-path R8-TO-R6 to 150.1.1.6 desc LSP-TIER-2 priority 6 6
exit
set interface lo0 unit 0 family inet address 150.1.1.8/32 primary

/* transport aid-in */

R1,R2,R3,R4,R5,R6,R7,R8
!
set groups LSP-GROUP-CORE protocols mpls label-switched-path <*> ldp-tunneling
set protocols ldp interface lo0.0
set protocols ldp explicit-null
set protocols ldp track-igp-metric

Task 3 (2 points). Configure the following MPLS features for the Service Provider Network:

All routers can handle jumbo Ethernet frames as well as variable packets of MPLS L3/L2 VPN,

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

•
MPLS TE and FRR services without fragmentation.
• The Service Provider Network can support CSC services with Fast Reroute, the customer carrier
can run LDP with the provider carrier running RSVP.
• Also allow for customers or peers to see MPLS hops of Service Provider Networks 1 and 2 when
performing ICMP ping and traceroute; Enable RSVP to signal MTU value along the path of all
LSPs. In order to facilitate diagnostics and detecting loops, each LSP should actively record its
routes.

R1,R2,R3,R4,R5,R6,R7,R8
!
edit groups CORE-INTERFACES
set interfaces <ge-0/0/[2678]> mtu 2000
set interfaces <ge-0/0/[2678]> unit 0 family mpls maximum-labels 5
exit
set protocols mpls icmp-tunneling
set protocols mpls path-mtu rsvp mtu-signaling
set protocols mpls record

Verification
Task 1. IS-IS is enabled with TE extension by default, it automatically generates and propagates link
attributes throughout the IS-IS domain in addition to the regular metric value. The attributes include
values such as reservable bandwidth for RSVP, remaining bandwidth, etc. An interesting part of this
practice lab is that there are multiple IS-IS levels, hence there would be multiple TE databases (TE) being
created. As can be seen below, there are 2 TEDs for levels 1 and 2 on router R6.
lab@VMX-R6> show isis database
IS-IS level 1 link-state database:
LSP ID Sequence Checksum Lifetime Attributes
VMX-R5.00-00 0x36b 0x41c9 63958 L1 L2
VMX-R6.00-00 0x2c1 0x9f62 63963 L1 L2
VMX-R7.00-00 0x15a 0x8764 59427 L1
VMX-R8.00-00 0x12d 0xf2dd 63947 L1
4 LSPs

IS-IS level 2 link-state database:

LSP ID Sequence Checksum Lifetime Attributes
VMX-R3.00-00 0x26b 0xd15d 62401 L1 L2
VMX-R4.00-00 0x320 0x4dd9 64134 L1 L2
VMX-R5.00-00 0x3ad 0xade4 63961 L1 L2
VMX-R6.00-00 0x2f8 0xfb19 64138 L1 L2
4 LSPs

lab@VMX-R6> show ted database extensive

TED database: 6 ISIS nodes 6 INET nodes
NodeID: VMX-R3.00(150.1.1.3)
Type: Rtr, Age: 250 secs, LinkIn: 2, LinkOut: 2
Protocol: IS-IS(2)
150.1.1.3
To: VMX-R4.00(150.1.1.4), Local: 150.1.34.3, Remote: 150.1.34.4
Local interface index: 340, Remote interface index: 335
Color: 0 <none>
Metric: 100
Static BW: 1000Mbps
Reservable BW: 1000Mbps
Available BW [priority] bps:
[0] 999.8Mbps [1] 999.8Mbps [2] 999.8Mbps [3] 999.8Mbps
[4] 999.8Mbps [5] 999.8Mbps [6] 999.8Mbps [7] 999.8Mbps
Interface Switching Capability Descriptor(1):
Switching type: Packet
Encoding type: Packet
Maximum LSP BW [priority] bps:
[0] 999.8Mbps [1] 999.8Mbps [2] 999.8Mbps [3] 999.8Mbps
[4] 999.8Mbps [5] 999.8Mbps [6] 999.8Mbps [7] 999.8Mbps

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

<snip-for-brevity>

Task 2. Following up from task 1, multi-level IS-IS network normally would require MPLS RSVP-signalled
LSPs to be configured as inter-domain LSPs as they are to span across level boundaries. We have
examined such LSPs in Practice Lab 3, topic 3. However in the current Practice Lab 5, we resolve this
requirement through a different way, i.e. a multi-tiered MPLS LSP system with tier-2 LSPs running inside

each POP and tier-1 LSPs connecting POPs together. This method is often used to reduce full-mesh RSVP
requirement and brings about a great scalability for the network.

In order to ensure that without inter-domain LSPs, all MPLS-based services such as L3VPN, L2VPN, 6PE
to function across the two tiers of LSP, we would need to use LDP Tunneling over RSVP-signalled LSPs.
To illustrate this point better, let’s take L3VPN as an example. With L3VPN, any packets between
customer sites that traverse the MPLS network will have two labels, the inner label being allocated by
MP-BGP and the outer label (or transport label) being allocated by a signalling protocol, in this case it is
RSVP. When MPLS frames of VPN traffic reach the edge of the IS-IS level 1, the outer label is popped
leaving MPLS frames with the inner label which edge routers may not have any idea about because
inner label is allocated by the egress PE. With LDP Tunneling, another label will be allocated across the
RSVP-signalled LSPs. To validate this point, routers should have LDP targeted neighbourship over
loopback0 interfaces, for example:
lab@VMX-R1> show ldp neighbor
Address Interface Label space ID Hold time
150.1.1.2 lo0.0 150.1.1.2:0 33
150.1.1.3 lo0.0 150.1.1.3:0 39
150.1.1.4 lo0.0 150.1.1.4:0 35
lab@VMX-R3> show ldp neighbor
Address Interface Label space ID Hold time
150.1.1.1 lo0.0 150.1.1.1:0 39
150.1.1.2 lo0.0 150.1.1.2:0 43
150.1.1.4 lo0.0 150.1.1.4:0 32
150.1.1.5 lo0.0 150.1.1.5:0 43
150.1.1.6 lo0.0 150.1.1.6:0 38

lab@VMX-R5> show ldp neighbor

Address Interface Label space ID Hold time
150.1.1.3 lo0.0 150.1.1.3:0 32
150.1.1.4 lo0.0 150.1.1.4:0 33
150.1.1.6 lo0.0 150.1.1.6:0 44
150.1.1.7 lo0.0 150.1.1.7:0 44
150.1.1.8 lo0.0 150.1.1.8:0 37

lab@VMX-R7> show ldp neighbor

Address Interface Label space ID Hold time
150.1.1.5 lo0.0 150.1.1.5:0 44
150.1.1.6 lo0.0 150.1.1.6:0 43
150.1.1.8 lo0.0 150.1.1.8:0 36

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

R1, R2 now should have loopback0 addresses of R5, R6, R7 and R8 in its inet.3 table, signalled by LDP,
and vice versa, R7, R8 should also have loopback0 addresses of R1, R2, R3 and R4 in its inet.3 table,
signalled by LDP.
lab@VMX-R1> show route table inet.3 active-path | match "RSVP|LDP"
150.1.1.2/32 *[RSVP/7/1] 00:57:45, metric 100
150.1.1.3/32 *[RSVP/7/1] 00:57:32, metric 100
150.1.1.4/32 *[RSVP/7/1] 00:57:43, metric 200
150.1.1.5/32 *[LDP/9] 00:57:02, metric 200
150.1.1.6/32 *[LDP/9] 00:57:02, metric 300
150.1.1.7/32 *[LDP/9] 00:56:57, metric 300
150.1.1.8/32 *[LDP/9] 00:56:59, metric 400
150.1.1.24/32 *[LDP/9] 00:56:28, metric 101

lab@VMX-R2> show route table inet.3 active-path | match "RSVP|LDP"

150.1.1.1/32 *[RSVP/7/1] 00:58:28, metric 100
150.1.1.3/32 *[RSVP/7/1] 00:58:57, metric 200
150.1.1.4/32 *[RSVP/7/1] 00:58:58, metric 100
150.1.1.5/32 *[LDP/9] 00:58:02, metric 200
150.1.1.6/32 *[LDP/9] 00:57:58, metric 200
150.1.1.7/32 *[LDP/9] 00:57:44, metric 300
150.1.1.8/32 *[LDP/9] 00:57:47, metric 300

lab@VMX-R7> show route table inet.3 active-path | match "RSVP|LDP"

150.1.1.1/32 *[LDP/9] 00:57:09, metric 300

150.1.1.2/32 *[LDP/9] 00:57:09, metric 300

150.1.1.3/32 *[LDP/9] 00:57:09, metric 200
150.1.1.4/32 *[LDP/9] 00:57:09, metric 200
150.1.1.5/32 *[RSVP/7/1] 00:58:09, metric 100
150.1.1.6/32 *[RSVP/7/1] 00:58:08, metric 200
150.1.1.8/32 *[RSVP/7/1] 00:58:08, metric 100
150.1.1.24/32 *[LDP/9] 00:57:09, metric 401

lab@VMX-R8> show route table inet.3 active-path | match "RSVP|LDP"

150.1.1.1/32 *[LDP/9] 00:57:13, metric 400
150.1.1.2/32 *[LDP/9] 00:57:34, metric 300
150.1.1.3/32 *[LDP/9] 00:57:13, metric 300
150.1.1.4/32 *[LDP/9] 00:58:00, metric 200
150.1.1.5/32 *[RSVP/7/1] 00:58:07, metric 200
150.1.1.6/32 *[RSVP/7/1] 00:58:08, metric 100
150.1.1.7/32 *[RSVP/7/1] 00:58:08, metric 100
150.1.1.24/32 *[LDP/9] 00:57:13, metric 501

When tracing route using LDP between POP1 and POP2, we should see that RSVP-TE is being used in the
transit.
lab@VMX-R2> traceroute mpls ldp source 150.1.1.2 150.1.1.8
Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16
source 150.1.1.2

ttl Label Protocol Address Previous Hop Probe Status

1 302336 LDP 150.1.24.4 (null) Success
2 3 RSVP-TE 150.1.46.6 150.1.24.4 Success
3 3 RSVP-TE 150.1.68.8 150.1.46.6 Egress

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

When we enable LDP Tunneling over RSVP, we need to enable LDP on interface loopback0. And because
we are using explicit-null for RSVP-signalled LSPs, we should also do the same for LDP-signalled paths for
consistency. Best practices indiciate that we should configure LDP to use IGP metric instead of its default
value of 1 for MPLS interfaces. Those features are configure with statements explicit-null and track-
igp-metric at protocols ldp stanza.

Task 2. JUNOS offers full-blown of features to optimise RSVP-signalled LSPs. The use of these features
requires thorough understanding and must be prepared carefully as otherwise they might de-stablise
the networks.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

• Let’s start with LSP priorities, by default each LSP has a setup priority of 7 meaning it cannot
preempt any other LSPs and a reservation priority of 0 meaning other LSPs cannot preempt it.
Changing default values with priority statement allows us to distinguish between different
classes of LSPs where more important LSPs can overtake network resources from lower priority
LSPs. As best practices indicated, the setup priority should always be less than or equal to the
hold priority and also we should give lower priority some time to find a different path with soft-
preemption statement rather than introducing a hard touch which incurs sudden packet
dropping. This statement by default governs that the router will wait for 30sec before tearing
down pre-empted LSPs, having that said it cannot be enabled if the LSP is configured explicitly
with two distinctive primary and secondary paths.
• Next we use node-link-protection to enable Node Link Protection feature which requires all
nodes along the LSP path to signal bypass LSP across each node of the path and get the bypass
LSP ready upon failure event of node. Please refer to
https://www.juniper.net/documentation/en_US/junos12.3/topics/concept/mpls-fast-reroute-
node-protection-link-protection.html for more information.

• Auto-bandwidth is a feature that allows an MPLS LSP to automatically adjust its bandwidth
usage/reservation based on the volume of traffic flowing through it based on current traffic
patterns without any interruption. At each automatic bandwidth time interval, the current
maximum average bandwidth usage is compared with the currently allocated bandwidth of the
LSP. If the LSP needs more bandwidth, JUNOS will attempt to calculate and signal a new path to
meet the new demand. If the attempt is successful, traffic is routed through the new path and
the old path is revoked. Otherwise, the LSP continues to use its current path.
o Auto-bandwidth feature requires that statistics of the LSP are collected frequently,
configured with statement statistics under protocols mpls stanza. By now there
should be some logs in the file autobw.log which can be viewed by command show log
autobw.log.
o In order to make Auto-bandwidth being adaptive to the change of traffic pattern instead
of a statically periodic process, we can tune it to trigger early updates with statements
adjust-threshold-overflow-limit and adjust-threshold-underflow-limit under
protocols mpls auto-bandwidth stanza, which correspond to the consecutive
increase/decrease in the number of flows.
o Another knob to protect the stability of the feature is the define the range of minimum
and maximum bandwidth.
• If multiple paths are available upon completion of CSPF, a tie-breaking rule is applied to choose
the path for the LSP. The default tie-breaking method is random, intending to place an equal
number of LSPs on each link, regardless of the available bandwidth.
lab@VMX-R5> show mpls lsp ingress name R5-TO-R8 extensive
Ingress LSP: 5 sessions

150.1.1.8
From: 150.1.1.5, State: Up, ActiveRoute: 0, LSPname: R5-TO-R8
Description: LSP-TIER-2
ActivePath: (primary)
Node/Link protection desired
LSPtype: Static Configured, Penultimate hop popping
LoadBalance: Random
Autobandwidth
MinBW: 100kbps, MaxBW: 10Gbps
AdjustTimer: 3600 secs AdjustThreshold: 15%

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

Max AvgBW util: 0bps, Bandwidth Adjustment in 3055 second(s).
Overflow limit: 2, Overflow sample count: 0
Underflow limit: 2, Underflow sample count: 0, Underflow Max AvgBW: 0bps
Encoding type: Packet, Switching type: Packet, GPID: IPv4
*Primary State: Up
Priorities: 6 6
Bandwidth: 100kbps
SmartOptimizeTimer: 180
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 200)
150.1.56.6 S 150.1.68.8 S
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-
ID):
150.1.1.6(flag=0x21) 150.1.56.6(flag=1 Label=305264) 150.1.1.8(flag=0x20)
150.1.68.8(Label=0)
OAM state : BFD session up LSP-ping up
6 Feb 4 18:55:55.983 Link-protection Up
5 Feb 4 18:55:47.283 Selected as active path
4 Feb 4 18:55:47.271 Record Route: 150.1.1.6(flag=0x21) 150.1.56.6(flag=1
Label=305264) 150.1.1.8(flag=0x20) 150.1.68.8(Label=0)
3 Feb 4 18:55:47.271 Up
2 Feb 4 18:55:46.964 Originate Call
1 Feb 4 18:55:46.964 CSPF: computation result accepted 150.1.56.6 150.1.68.8
Created: Sat Feb 4 18:55:46 2017
Total 1 displayed, Up 1, Down 0

With MPLS OAM, we can leverage BFD to actually check two-way forwarding capability between the
endpoint of the LSP. This requires the configuration of local address 127.0.0.1/32 on the loopback0
interfaces and the statement oam at LSP level. It is recommended to add primary statement to the actual
IP address on loopback0. BFD aids in the detection of link/node failures within MPLS domain and can
help accelerate the switchover to the backup paths. Note that when you enable MPLS OAM, BFD will
perform in multi-hop mode and it needs UDP ports 3503 and 4784 to be open at the local router, i.e.
COPP ACL may need to be updated (if any), and also IP address 127.0.0.1/32 to be configured at the
loopback0 interface. Best practices indicate that you should retain the current loopback0 IP address
with primary statement. In terms of configuration efficiency and consistency, we should configure a class
of LSP (group LSP-GROUP-CORE in this case) that has got all common attributes and then let all LSPs to
inherit from those. This way we can ensure that all LSPs would have consistent behaviours and there is
no need to maintain per-LSP configuration which is not scalable and raises risks such as a typo mistake
or missing attributes. Let’s ensure that all LSPs are fully signalled and in Up state before moving on to
the next task.
lab@VMX-R1> show mpls lsp ingress
Ingress LSP: 3 sessions
To From State Rt P ActivePath LSPname
150.1.1.2 150.1.1.1 Up 0 * R1-TO-R2
150.1.1.3 150.1.1.1 Up 0 * R1-TO-R3
150.1.1.4 150.1.1.1 Up 0 * R1-TO-R4
Total 3 displayed, Up 3, Down 0

lab@VMX-R2> show mpls lsp ingress

Ingress LSP: 3 sessions
To From State Rt P ActivePath LSPname
150.1.1.1 150.1.1.2 Up 0 * R2-TO-R1
150.1.1.3 150.1.1.2 Up 0 * R2-TO-R3
150.1.1.4 150.1.1.2 Up 0 * R2-TO-R4
Total 3 displayed, Up 3, Down 0

lab@VMX-R3> show mpls lsp ingress

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

lab@VMX-R4> show mpls lsp ingress
Ingress LSP: 5 sessions
To From State Rt P ActivePath LSPname
150.1.1.1 150.1.1.4 Up 0 * R4-TO-R1
150.1.1.2 150.1.1.4 Up 0 * R4-TO-R2
150.1.1.3 150.1.1.4 Up 0 * R4-TO-R3
150.1.1.5 150.1.1.4 Up 0 * R4-TO-R5
150.1.1.6 150.1.1.4 Up 0 * R4-TO-R6
Total 5 displayed, Up 5, Down 0

lab@VMX-R5> show mpls lsp ingress

Ingress LSP: 5 sessions
To From State Rt P ActivePath LSPname
150.1.1.3 150.1.1.5 Up 0 * R5-TO-R3
150.1.1.4 150.1.1.5 Up 0 * R5-TO-R4
150.1.1.6 150.1.1.5 Up 0 * R5-TO-R6
150.1.1.7 150.1.1.5 Up 0 * R5-TO-R7
150.1.1.8 150.1.1.5 Up 0 * R5-TO-R8
Total 5 displayed, Up 5, Down 0

lab@VMX-R6> show mpls lsp ingress

Ingress LSP: 5 sessions
To From State Rt P ActivePath LSPname
150.1.1.3 150.1.1.6 Up 0 * R6-TO-R3
150.1.1.4 150.1.1.6 Up 0 * R6-TO-R4
150.1.1.5 150.1.1.6 Up 0 * R6-TO-R5

150.1.1.7 150.1.1.6 Up 0 * R6-TO-R7

150.1.1.8 150.1.1.6 Up 0 * R6-TO-R8
Total 5 displayed, Up 5, Down 0

lab@VMX-R7> show mpls lsp ingress

Ingress LSP: 3 sessions
To From State Rt P ActivePath LSPname
150.1.1.5 150.1.1.7 Up 0 * R7-TO-R5
150.1.1.6 150.1.1.7 Up 0 * R7-TO-R6
150.1.1.8 150.1.1.7 Up 0 * R7-TO-R8
Total 3 displayed, Up 3, Down 0

lab@VMX-R8> show mpls lsp ingress

Ingress LSP: 3 sessions
To From State Rt P ActivePath LSPname
150.1.1.5 150.1.1.8 Up 0 * R8-TO-R5
150.1.1.6 150.1.1.8 Up 0 * R8-TO-R6
150.1.1.7 150.1.1.8 Up 0 * R8-TO-R7
Total 3 displayed, Up 3, Down 0

Task 3. Verification for customers or peers performing ping/traceroute will be carried out in Topc 4:
BGP, tasks 1 and 2. For now, let’s test reachability via ping mpls rsvp which is part of MPLS OAM family
and uses UDP port 3503 as the underlying transport protocol, for example:
lab@VMX-R1> ping mpls rsvp R1-TO-R4
!!!!!
--- lsping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

lab@VMX-R1> traceroute mpls rsvp R1-TO-R4

Probe options: retries 3, exp 7

ttl Label Protocol Address Previous Hop Probe Status

1 302112 RSVP-TE 150.1.12.2 (null) Success
2 0 RSVP-TE 150.1.24.4 150.1.12.2 Egress

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

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

Egress LSP: 14 sessions

150.1.1.4
From: 150.1.1.1, LSPstate: Up, ActiveRoute: 0
LSPname: R1-TO-R4, LSPpath: Primary
Suggested label received: -, Suggested label sent: -
Recovery label received: -, Recovery label sent: -
Resv style: 1 SE, Label in: 0, Label out: -
Time left: 159, Since: Sat Feb 4 19:36:51 2017
Tspec: rate 100kbps size 100kbps peak Infbps m 20 M 9192
Port number: sender 6 receiver 39806 protocol 0
Node/Link protection desired
Soft preemption desired
Type: Protection down
PATH rcvfrom: 150.1.24.2 (ge-0/0/6.0) 10 pkts
Adspec: received MTU 1986
PATH sentto: localclient
RESV rcvfrom: localclient , Entropy label: No
Record route: 150.1.12.1 150.1.24.2 <self>
Total 1 displayed, Up 1, Down 0

In order to allow LSP to actively record its routes in the path, we can use statement record under
protocols mpls stanza. Also to allow the network to support CSC services with Customer Carrier running
LDP and Backbone Carrier running RSVP, we need to allow MPLS stack with up to 5 labels, configured
with statement maximum-labels under interface <*> family mpls stanza.

lab@VMX-R1> show mpls lsp ingress name R1-TO-R4 extensive | match "Record Route:"
81 Feb 4 19:39:07.109 Record Route: 150.1.1.2(flag=0x21) 150.1.12.2(flag=1
Label=302112) 150.1.1.4(flag=0x20) 150.1.24.4(Label=0)
79 Feb 4 19:39:04.100 Record Route: 150.1.1.2(flag=0x20) 150.1.12.2(Label=302112)
150.1.1.4(flag=0x20) 150.1.24.4(Label=0)
77 Feb 4 19:38:59.957 Record Route: 150.1.1.2(flag=0x21) 150.1.12.2(flag=1
Label=302112) 150.1.1.4(flag=0x20) 150.1.24.4(Label=0)

lab@VMX-R1> show interfaces ge-0/0/2.0 | match Max

Protocol mpls, MTU: 1966, Maximum labels: 5

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

Topic 4: BGP
Total Points: 21

Task 1 (5 points). Configure BGP confederation for the Service Provider Network with the following
characteristics:

• Display the true 4-byte ASN form of the actual ASN for the confederation.
• Sub-AS 64001 includes R1, R2, R3 and R4.
• Sub-AS 64002 includes R5, R6, R7 and R8.
• Create confederation eBGP peering sessions between the two Sub-ASes.
• Ensure all BGP sessions are enabled with MD5 authentication and their bidirectional forwarding
capability is monitored through BFD.
• Enable multipath capability inside the Service Provider Network.
• Announce the IPv4/IPv6 supernets of the Service Provider Network on R4 and R5 (2 static routes
are allowed on each router).
R1,R2,R3,R4,R5,R6,R7,R8
!
edit protocols bgp group IBGP-CONFED
set type internal
set bfd minimum-interval 500 multiplier 4
set multipath
set export NHS
exit
edit policy-options policy-statement NHS
set term 1 from protocol bgp
set term 1 from route-type external
set term 1 then next-hop self
set term 1 then accept
exit
set routing-options confed 1.57920 member [ 64001 64002 ]
set routing-options autonomous-system asdot-notation

R1,R2,R3,R4
!
set routing-options autonomous-system 64001

R5,R6,R7,R8
!

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

set routing-options autonomous-system 64002

R1
!
edit protocols bgp group IBGP-CONFED
set local-address 150.1.1.1
set neighbor 150.1.1.2
set neighbor 150.1.1.3
set neighbor 150.1.1.4
exit

R2
!
edit protocols bgp group IBGP-CONFED
set local-address 150.1.1.2
set neighbor 150.1.1.1
set neighbor 150.1.1.3
set neighbor 150.1.1.4
exit

R3
!
edit protocols bgp group IBGP-CONFED
set local-address 150.1.1.3
set neighbor 150.1.1.1
set neighbor 150.1.1.2
set neighbor 150.1.1.4

exit
edit protocols bgp group EBGP-CONFED
set bfd minimum-interval 500 multiplier 4
set local-address 150.1.1.3
set neighbor 150.1.1.5 peer-as 64002 multihop
set neighbor 150.1.1.6 peer-as 64002 multihop
set multipath
set export NHS
exit

R4
!
edit protocols bgp group IBGP-CONFED
set local-address 150.1.1.4
set neighbor 150.1.1.1
set neighbor 150.1.1.2
set neighbor 150.1.1.3
set export AS-AGGREGATE
exit
edit protocols bgp group EBGP-CONFED
set bfd minimum-interval 500 multiplier 4
set local-address 150.1.1.4
set neighbor 150.1.1.5 peer-as 64002 multihop
set neighbor 150.1.1.6 peer-as 64002 multihop
set multipath
set export NHS
set export AS-AGGREGATE
exit
edit policy-options policy-statement AS-AGGREGATE
set term 4 from protocol aggregate
set term 4 from route-filter 150.1.0.0/16 exact
set term 4 then accept
set term 6 from protocol aggregate
set term 6 from route-filter 2016:150:1::/48 exact
set term 6 then accept
exit
set routing-options aggregate route 150.1.0.0/16
set routing-options rib inet6.0 aggregate route 2016:150:1::/48

R5
!
edit protocols bgp group IBGP-CONFED
set local-address 150.1.1.5
set neighbor 150.1.1.6
set neighbor 150.1.1.7
set neighbor 150.1.1.8
set export AS-AGGREGATE
exit
edit protocols bgp group EBGP-CONFED
set bfd minimum-interval 500 multiplier 4

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

set local-address 150.1.1.5
set neighbor 150.1.1.3 peer-as 64001 multihop
set neighbor 150.1.1.4 peer-as 64001 multihop
set multipath
set export NHS
set export AS-AGGREGATE
exit
edit policy-options policy-statement AS-AGGREGATE
set term 4 from protocol aggregate
set term 4 from route-filter 150.1.0.0/16 exact
set term 4 then accept
set term 6 from protocol aggregate
set term 6 from route-filter 2016:150:1::/48 exact
set term 6 then accept
exit
set routing-options aggregate route 150.1.0.0/16
set routing-options rib inet6.0 aggregate route 2016:150:1::/48

R6
!
edit protocols bgp group IBGP-CONFED
set local-address 150.1.1.6
set neighbor 150.1.1.5
set neighbor 150.1.1.7
set neighbor 150.1.1.8
exit
edit protocols bgp group EBGP-CONFED

set bfd minimum-interval 500 multiplier 4

set local-address 150.1.1.6
set neighbor 150.1.1.3 peer-as 64001 multihop
set neighbor 150.1.1.4 peer-as 64001 multihop
set multipath
set export NHS
exit

R7
!
edit protocols bgp group IBGP-CONFED
set local-address 150.1.1.7
set neighbor 150.1.1.5
set neighbor 150.1.1.6
set neighbor 150.1.1.8
exit

R8
!
edit protocols bgp group IBGP-CONFED
set local-address 150.1.1.8
set neighbor 150.1.1.5
set neighbor 150.1.1.6
set neighbor 150.1.1.7
exit

Local Peer Router ASN of Peer Router IPv4 of Peer Router IPv6 of Peer Router
Router
R1 C1 65001 150.1.119.2 2016:150:1:119::2
P1 100 150.1.100.2 2016:150:1:100::2
T1 111 111.1.120.2 2016:111:1:120::2
R2 P1 100 150.1.113.2 2016:150:1:113::2
P2 200 150.1.101.2 2016:150:1::101::2
T2 222 222.1.123.2 2016:222:1:123::2
R5 P2 200 150.1.137.2 2016:150:1:137::2
C2 65002 150.1.102.2 2016:150:1:102::2
R6 C4 65004 150.1.107.2 ::ffff:150.1.107.2

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

T1 111 111.1.105.2 2016:111:1:105::2
R7 T2 222 222.1.106.2 2016:111:1:106::2

You can launch ping tests from any C/T/P routing-instance on VRF device with some test IPv4/IPv6
addresses below.

• C1: 170.1.210.1, 2016:170:1:210::1

set protocols bgp group IBGP-CONFED family inet6 labeled-unicast explicit-null

R3,R4,R5,R6
!
set protocols bgp group EBGP-CONFED family inet unicast
set protocols bgp group EBGP-CONFED family inet6 labeled-unicast explicit-null

R1
!
edit protocols bgp group CUSTOMER
set type external
set neighbor 150.1.119.2 peer-as 65001
set neighbor 2016:150:1:119::2 peer-as 65001
exit
edit protocols bgp group PEER
set type external
set neighbor 150.1.100.2 peer-as 100
set neighbor 2016:150:1:100::2 peer-as 100
exit
edit protocols bgp group TRANSIT
set type external
set neighbor 111.1.120.2 peer-as 111
set neighbor 2016:111:1:120::2 peer-as 111
exit

R2
!
edit protocols bgp group PEER
set type external
set neighbor 150.1.113.2 peer-as 100
set neighbor 2016:150:1:113::2 peer-as 100
set neighbor 150.1.101.2 peer-as 200
set neighbor 2016:150:1:101::2 peer-as 200
exit
edit protocols bgp group TRANSIT
set type external
set neighbor 222.1.123.2 peer-as 222
set neighbor 2016:222:1:123::2 peer-as 222
exit

R5
!
edit protocols bgp group CUSTOMER
set type external
set neighbor 150.1.102.2 peer-as 65002
set neighbor 2016:150:1:102::2 peer-as 65002
exit
edit protocols bgp group PEER
set type external
set neighbor 150.1.137.2 peer-as 200

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

set neighbor 2016:150:1:137::2 peer-as 200
exit

R6
!
edit protocols bgp group CUSTOMER
set type external
set neighbor 150.1.107.2 peer-as 65004
set neighbor 150.1.107.2 family inet unicast
set neighbor 150.1.107.2 family inet6 unicast
exit
edit protocols bgp group TRANSIT
set type external
set neighbor 111.1.105.2 peer-as 111
set neighbor 2016:111:1:105::2 peer-as 111
exit

R7
!
edit protocols bgp group TRANSIT
set type external
set neighbor 222.1.106.2 peer-as 222
set neighbor 2016:222:1:106::2 peer-as 222
exit

Task 3 (4 points). Implement the BGP Flowspec throughout the AS 1.57920. Use community 57920:6660
for local flow route definition. The Service Provider will be transitioning to a system of route-servers in
the near future, please allow for such systems to define flows and update the network with community
57920:6661. For testing BGP Flowspec, locally define two flows on R3 with the following characteristics.
Ensure they are blocked on an AS-wide basis as expected. Limit the maximum number of flows to be
5,000 and a warning will trigger once 80% of that limit is reached.

• Flow 1:
o Source: 123.0.0.1/32
o Destination: 150.1.1.30/32
o Protocol: ICMP
• Flow 2:
o Source: 123.0.1.1/32
o Destination: 150.1.1.60/32
o Protocol: UDP
R1,R2,R3,R4,R5,R6,R7,R8
!
set protocols bgp group IBGP-CONFED family inet flow no-validate RT-FLOWSPEC
set protocols bgp group IBGP-CONFED export LOCAL-FLOWSPEC
edit policy-options policy-statement LOCAL-FLOWSPEC
set term 1 from rib inetflow.0
set term 1 from route-filter 0.0.0.0/0 prefix-length /32-/32
set term 1 then community add LOCAL-FLOWSPEC
set term 1 then accept
set term DENY-ALL from rib inetflow.0
set term DENY-ALL then reject
exit
edit policy-options policy-statement RT-FLOWSPEC
set term 1 from protocol bgp
set term 1 from route-filter 0.0.0.0/0 prefix-length /32-/32
set term 1 from community RT-FLOWSPEC
set term 1 then accept
set term DENY-ALL then reject
exit
set policy-options community LOCAL-FLOWSPEC member 57920:6660
set policy-options community RT-FLOWSPEC member 57920:6661
set routing-options flow term-order standard
set routing-options rib inetflow.0 maximum-prefixes 5000 threshold 80

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

R3,R4,R5,R6
!
set protocols bgp group EBGP-CONFED family inet flow no-validate RT-FLOWSPEC
set protocols bgp group EBGP-CONFED export LOCAL-FLOWSPEC

R3
!
edit routing-options flow route TEST-FLOW1
set match source 123.0.0.1/32
set match destination 150.1.1.30/32
set match protocol icmp
set then discard
exit
edit routing-options flow route TEST-FLOW2
set match source 123.0.1.1/32
set match destination 150.1.1.60/32
set match protocol udp
set then discard
exit
edit policy-options policy-statement LOCAL-FLOWSPEC
set term 1 then community add RT-FLOWSPEC
exit

The peer P1 does not need to contact AS 1.57920 anytime they want to change the inbound preference.
The less-preferred PE-CE link should still be used as the backup path. P1 has already tagged its prefixes
with certain BGP community values. Optimise the routing domain inside the Service Provider Network
such that the switchover to the backup link is faster than regular iBGP convergence.
R1
!
edit protocols bgp group PEER
set neighbor 150.1.100.2 import P1-IN
set neighbor 2016:150:1:100::2 import P1-IN
exit
edit policy-options policy-statement P1-IN
set term PRIMARY from protocol bgp
set term PRIMARY from community AS-OUTBOUND-PRIMARY
set term PRIMARY then local-preference 2500
set term PRIMARY then accept
set term DEFAULT from protocol bgp
set term DEFAULT then local-preference 100
set term DEFAULT then accept
exit
set policy-options community AS-OUTBOUND-PRIMARY member 57920:2500
set protocols bgp group IBGP-CONFED advertise-external

R2
!
edit protocols bgp group PEER
set neighbor 150.1.113.2 import P1-IN
set neighbor 2016:150:1:113::2 import P1-IN
exit
edit policy-options policy-statement P1-IN
set term PRIMARY from protocol bgp
set term PRIMARY from community AS-OUTBOUND-PRIMARY
set term PRIMARY then local-preference 2500
set term PRIMARY then accept
set term DEFAULT from protocol bgp
set term DEFAULT then local-preference 100
set term DEFAULT then accept
exit
set policy-options community AS-OUTBOUND-PRIMARY member 57920:2500
set protocols bgp group IBGP-CONFED advertise-external

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

prefix 123.0.0.0/24 in its inet.0 table.
R6
!
set routing-options generate route 0.0.0.0/0 policy CONDITIONAL-V4-DEF
set routing-options rib inet6.0 generate route ::/0 policy CONDITIONAL-V6-DEF
edit policy-options policy-statement CONDITIONAL-V4-DEF
set term V4-TRACK-PREFIX from protocol bgp
set term V4-TRACK-PREFIX from route-filter 123.0.0.0/24 exact
set term V4-TRACK-PREFIX then accept
set term DENY-ALL then reject
exit
edit policy-options policy-statement CONDITIONAL-V6-DEF
set term V6-TRACK-PREFIX from protocol bgp
set term V6-TRACK-PREFIX from route-filter 2016:123::/64 exact
set term V6-TRACK-PREFIX then accept
set term DENY-ALL then reject
exit
edit policy-options policy-statement C4-OUT
set term V4-DEF from protocol aggregate
set term V4-DEF from route-filter 0.0.0.0/0 exact
set term V4-DEF then accept
set term V6-DEF from protocol aggregate
set term V6-DEF from route-filter ::/0 exact
set term V6-DEF then accept
set term DOMESTIC-PREFIXES from protocol bgp
set term DOMESTIC-PREFIXES from as-path DOMESTIC-INTERNET

set term DOMESTIC-PREFIXES then accept

set term DENY-ALL then reject
exit
set policy-options as-path DOMESTIC-INTERNET ".{0,2}"
set protocols bgp group CUSTOMER neighbor 150.1.107.2 export C4-OUT

Verification
Task 1. This task uses BGP Confederation feature which is another way to solve the scaling problems of
iBGP full mesh requirement by effectively dividing a large AS into smaller sub-ASes. Each sub-AS is
uniquely identified within the confederation AS by a sub-AS number, typically in the private range of
64,512-65,535. A router inside each sub-AS do not necessarily need to have iBGP peering sessions with
other routers in different sub-AS. And within each sub-AS, the requirement of iBGP full-mesh stays the
same. It is possible to deploy Route Reflection inside each sub-AS. In this case we have 1.57920 is the
confederation AS and 64001, 64002 are sub-ASes.

Now the first step is to ensure all iBGP neighbourships are Established and also iBGP is installed as a
client of BFD which verifies forwarding path and liberates BGP from reliance upon IS-IS for notification of
device failure. BGP no longer needs to rely on event-driven or periodic next-hop scanning. The ultimate
outcome is to improve convergence of iBGP by rapidly detecting BGP neighbour failure. You may notice
that the expression of ASN is in 32-bit form: 1.57920, in order for this to be displayed correctly we would
need statement asdot-notation under routing-options stanza.
lab@VMX-R3> show bgp summary | match 6400
150.1.1.1 64001 19 49 0 8 4:19 Establ
150.1.1.2 64001 19 56 0 7 4:48 Establ
150.1.1.4 64001 62 53 0 7 4:23 Establ
150.1.1.5 64002 29 26 0 7 3:57 Establ
150.1.1.6 64002 33 25 0 8 3:35 Establ

lab@VMX-R4> show bgp summary | match 6400

150.1.1.1 64001 21 54 0 7 4:24 Establ
150.1.1.2 64001 18 50 0 7 4:25 Establ
150.1.1.3 64001 58 58 0 7 4:20 Establ
150.1.1.5 64002 33 24 0 8 4:04 Establ
150.1.1.6 64002 37 26 0 8 3:36 Establ

lab@VMX-R5> show bgp summary | match 6400

150.1.1.3 64001 32 27 0 7 5:01 Establ
150.1.1.4 64001 30 30 0 8 5:11 Establ

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

150.1.1.6 64002 33 26 0 8 5:10 Establ
150.1.1.7 64002 18 16 0 7 4:47 Establ
150.1.1.8 64002 21 18 0 8 4:56 Establ

lab@VMX-R6> show bgp summary | match 6400

150.1.1.3 64001 33 31 0 8 4:35 Establ
150.1.1.4 64001 33 35 0 8 4:38 Establ
150.1.1.5 64002 30 28 0 8 5:05 Establ
150.1.1.7 64002 17 16 0 7 4:34 Establ
150.1.1.8 64002 20 20 0 8 4:39 Establ

lab@VMX-R4> show bfd session address 150.1.1.2 detail

Detect Transmit
Address State Interface Time Interval Multiplier
150.1.1.2 Up 1.000 0.250 3
Client RSVP-OAM, TX interval 0.050, RX interval 0.050
Session up time 00:02:05
Local diagnostic None, remote diagnostic None
Remote state Up, version 1
Session type: Multi hop BFD
Detect Transmit
Address State Interface Time Interval Multiplier
150.1.1.2 Up 1.000 0.250 4
Client BGP, TX interval 0.250, RX interval 0.250
Session up time 00:02:47
Local diagnostic None, remote diagnostic None
Remote state Up, version 1
Session type: Multi hop BFD

Between two Sub-ASes, we just need 3 confederation eBGP sessions, between R3 and R5, R4 and R5, R4
and R6. And also we should keep using the loopback0 as update-source for these sessions to enhance
the stability from link-flap events, hence keyword multihop is needed because those are not regular iBGP
sessions.

The iBGP multipath feature is enabled with keyword multipath under protocols bgp group stanza.
Without this knob, the route via the peer with lower Router-ID is likely to be selected.
lab@VMX-R3> show route 150.1.0.0/16 exact active-path

inet.0: 113 destinations, 188 routes (103 active, 0 holddown, 10 hidden)

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

150.1.0.0/16 *[BGP/170] 00:04:47, localpref 100, from 150.1.1.4

AS path: I, validation-state: unverified
> to 150.1.34.4 via ge-0/0/2.0, label-switched-path R3-TO-R4
to 150.1.35.5 via ge-0/0/7.0, label-switched-path Bypass-
>150.1.34.4
to 150.1.34.4 via ge-0/0/2.0, label-switched-path R3-TO-R5
to 150.1.35.5 via ge-0/0/7.0, label-switched-path Bypass-
>150.1.34.4->150.1.45.5

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

only the latter is activated between the routers.
o Because of how iBGP is designed in this lab, even though R3 and R4 do not have 6PE
clients, they still need to have the AFIs enabled to maintain the 6PE routing
advertisements.
• set protocols mpls ipv6-tunneling, we convert IPv4 next-hop being routers’ loopback address
in table inet.3 into IPv4-mapped IPv6 next-hop and install them into table inet6.3 to resolve and
forward label-switched MPLS frames which encapsulate IPv6 packets inside.
o But since the MPLS environment of this whole practice lab is constructed by two LSP
tiers, there are some special configurations to make 6PE work here.
o R1, R2 in POP1 do not have direct LSPs with R5 and R6 in POP2 so by default their inet.3
tables should not directly have R5’s and R6’s loopback0 IPv4. However, thanks to the
implementation of LDP-Tunneling in topic 3, task 2, all routers should have loopback0
networks of each other in table inet.3, label-binded by LDP. This applies to IPv4-mapped
IPv6 address in table inet6.3 as well.
lab@VMX-R1> show route table inet6.3 active-path

inet6.3: 8 destinations, 11 routes (8 active, 0 holddown, 0 hidden)

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

::ffff:150.1.1.2/128
*[RSVP/7/1] 00:31:03, metric 100
> to 150.1.12.2 via ge-0/0/2.0, label-switched-path R1-TO-R2
to 150.1.13.3 via ge-0/0/6.0, label-switched-path Bypass-
>150.1.12.2
::ffff:150.1.1.3/128
*[RSVP/7/1] 00:31:05, metric 100
> to 150.1.13.3 via ge-0/0/6.0, label-switched-path R1-TO-R3
to 150.1.12.2 via ge-0/0/2.0, label-switched-path Bypass-
>150.1.13.3
::ffff:150.1.1.4/128
*[RSVP/7/1] 00:31:27, metric 200
> to 150.1.12.2 via ge-0/0/2.0, label-switched-path R1-TO-R4
to 150.1.13.3 via ge-0/0/6.0, label-switched-path Bypass-
>150.1.12.2->150.1.24.4
::ffff:150.1.1.5/128
*[LDP/9] 00:04:27, metric 200
> to 150.1.13.3 via ge-0/0/6.0, label-switched-path R1-TO-R3
to 150.1.12.2 via ge-0/0/2.0, label-switched-path R1-TO-R3
::ffff:150.1.1.6/128
*[LDP/9] 00:04:27, metric 300
> to 150.1.13.3 via ge-0/0/6.0, label-switched-path R1-TO-R3
to 150.1.12.2 via ge-0/0/2.0, label-switched-path R1-TO-R4
to 150.1.12.2 via ge-0/0/2.0, label-switched-path R1-TO-R3
to 150.1.13.3 via ge-0/0/6.0, label-switched-path R1-TO-R4
::ffff:150.1.1.7/128
*[LDP/9] 00:04:27, metric 300
> to 150.1.13.3 via ge-0/0/6.0, label-switched-path R1-TO-R3
to 150.1.12.2 via ge-0/0/2.0, label-switched-path R1-TO-R3
::ffff:150.1.1.8/128
*[LDP/9] 00:04:27, metric 400
to 150.1.13.3 via ge-0/0/6.0, label-switched-path R1-TO-R3
> to 150.1.12.2 via ge-0/0/2.0, label-switched-path R1-TO-R4
to 150.1.12.2 via ge-0/0/2.0, label-switched-path R1-TO-R3
to 150.1.13.3 via ge-0/0/6.0, label-switched-path R1-TO-R4
::ffff:150.1.1.24/128
*[LDP/9] 00:04:32, metric 101
> to 150.1.12.2 via ge-0/0/2.0, label-switched-path R1-TO-R2
to 150.1.13.3 via ge-0/0/6.0, label-switched-path R1-TO-R2

• family inet6 on all core-facing interfaces, this is already configured as part of initial
configurations. There is no need for specific IPv6 address to be configured, but instead just the
activation of the IPv6 AFI on the interfaces.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

At the end of task 2, we should test reachability of IPv4/IPv6 routing/switching between customers,
peers and transits. Below are IPv4/IPv6 ping tests from C4 to other customers, peers and upstream
transit provider of the Service Provider Network:
lab@VMX-VR> ping rapid routing-instance C4 source 170.1.240.1 100.0.0.1
PING 100.0.0.1 (100.0.0.1): 56 data bytes
!!!!!
--- 100.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 4.825/5.634/6.286/0.511 ms

lab@VMX-VR> ping rapid routing-instance C4 source 170.1.240.1 111.0.0.1

PING 111.0.0.1 (111.0.0.1): 56 data bytes
!!!!!
--- 111.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 5.328/6.442/7.119/0.609 ms

lab@VMX-VR> ping rapid routing-instance C4 source 170.1.240.1 170.1.210.1

lab@VMX-VR> ping rapid routing-instance C4 source 170.1.240.1 170.1.220.1

PING 170.1.220.1 (170.1.220.1): 56 data bytes
!!!!!
--- 170.1.220.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 5.122/5.879/7.606/0.929 ms

lab@VMX-VR> ping rapid routing-instance C4 source 170.1.240.1 200.0.0.1

PING 200.0.0.1 (200.0.0.1): 56 data bytes
!!!!!
--- 200.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 4.053/4.848/6.076/0.728 ms

lab@VMX-VR> ping rapid routing-instance C4 source 170.1.240.1 222.0.0.1

PING 222.0.0.1 (222.0.0.1): 56 data bytes
!!!!!
--- 222.0.0.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.956/4.127/4.459/0.182 ms

lab@VMX-VR> ping rapid routing-instance C4 source 2016:170:1:240::1 2016:100::1

lab@VMX-VR> ping rapid routing-instance C4 source 2016:170:1:240::1 2016:111::1

lab@VMX-VR> ping rapid routing-instance C4 source 2016:170:1:240::1 2016:170:1:210::1

PING6(56=40+8+8 bytes) 2016:170:1:240::1 --> 2016:170:1:210::1
!!!!!
--- 2016:170:1:210::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 5.401/6.474/7.723/0.742 ms

lab@VMX-VR> ping rapid routing-instance C4 source 2016:170:1:240::1 2016:170:1:220::1

PING6(56=40+8+8 bytes) 2016:170:1:240::1 --> 2016:170:1:220::1
!!!!!
--- 2016:170:1:220::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 5.197/6.013/7.976/1.008 ms

lab@VMX-VR> ping rapid routing-instance C4 source 2016:170:1:240::1 2016:200::1

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

lab@VMX-VR> ping rapid routing-instance C4 source 2016:170:1:240::1 2016:222::1

lab@VMX-VR> ping rapid routing-instance C4 source 170.1.240.1 150.1.1.2

PING 150.1.1.2 (150.1.1.2): 56 data bytes
!!!!!
--- 150.1.1.2 ping statistics ---

5 packets transmitted, 5 packets received, 0% packet loss

round-trip min/avg/max/stddev = 3.457/4.264/5.407/0.893 ms

lab@VMX-VR> ping rapid routing-instance C4 source 170.1.240.1 150.1.1.3

PING 150.1.1.3 (150.1.1.3): 56 data bytes
!!!!!
--- 150.1.1.3 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.542/4.191/4.998/0.536 ms

lab@VMX-VR> ping rapid routing-instance C4 source 170.1.240.1 150.1.1.4

PING 150.1.1.4 (150.1.1.4): 56 data bytes
!!!!!
--- 150.1.1.4 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.715/3.172/4.474/0.656 ms

lab@VMX-VR> ping rapid routing-instance C4 source 170.1.240.1 150.1.1.5

PING 150.1.1.5 (150.1.1.5): 56 data bytes
!!!!!
--- 150.1.1.5 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.714/3.234/4.420/0.604 ms

lab@VMX-VR> ping rapid routing-instance C4 source 170.1.240.1 150.1.1.6

PING 150.1.1.6 (150.1.1.6): 56 data bytes
!!!!!
--- 150.1.1.6 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.672/2.033/2.697/0.356 ms

lab@VMX-VR> ping rapid routing-instance C4 source 170.1.240.1 150.1.1.7

PING 150.1.1.7 (150.1.1.7): 56 data bytes
!!!!!
--- 150.1.1.7 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.998/4.146/5.749/0.892 ms

lab@VMX-VR> ping rapid routing-instance C4 source 170.1.240.1 150.1.1.8

PING 150.1.1.8 (150.1.1.8): 56 data bytes
!!!!!
--- 150.1.1.8 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.782/3.496/4.793/0.686 ms

lab@VMX-VR> ping rapid routing-instance C4 source 2016:170:1:240::1 2016:150:1:1::1

PING6(56=40+8+8 bytes) 2016:170:1:240::1 --> 2016:150:1:1::1
!!!!!
--- 2016:150:1:1::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

round-trip min/avg/max/std-dev = 4.886/8.003/18.921/5.481 ms

lab@VMX-VR> ping rapid routing-instance C4 source 2016:170:1:240::1 2016:150:1:1::2

lab@VMX-VR> ping rapid routing-instance C4 source 2016:170:1:240::1 2016:150:1:1::3

lab@VMX-VR> ping rapid routing-instance C4 source 2016:170:1:240::1 2016:150:1:1::4

lab@VMX-VR> ping rapid routing-instance C4 source 2016:170:1:240::1 2016:150:1:1::5

PING6(56=40+8+8 bytes) 2016:170:1:240::1 --> 2016:150:1:1::5
!!!!!
--- 2016:150:1:1::5 ping6 statistics ---

5 packets transmitted, 5 packets received, 0% packet loss

round-trip min/avg/max/std-dev = 2.662/3.230/4.405/0.620 ms

lab@VMX-VR> ping rapid routing-instance C4 source 2016:170:1:240::1 2016:150:1:1::6

lab@VMX-VR> ping rapid routing-instance C4 source 2016:170:1:240::1 2016:150:1:1::7

lab@VMX-VR> ping rapid routing-instance C4 source 2016:170:1:240::1 2016:150:1:1::8

PING6(56=40+8+8 bytes) 2016:170:1:240::1 --> 2016:150:1:1::8
!!!!!
--- 2016:150:1:1::8 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 2.795/3.855/5.438/0.867 ms

We also test traceroute from customer perspectives as mentioned in topic 3 previously, for example:
lab@VMX-VR> traceroute routing-instance C4 source 170.1.240.1 170.1.210.1
traceroute to 170.1.210.1 (170.1.210.1) from 170.1.240.1, 30 hops max, 40 byte packets
1 150.1.107.1 (150.1.107.1) 4.262 ms 2.400 ms 2.588 ms
2 150.1.56.5 (150.1.56.5) 6.210 ms 3.242 ms 4.387 ms
MPLS Label=315552 CoS=0 TTL=1 S=1
3 150.1.35.3 (150.1.35.3) 4.034 ms 150.1.45.4 (150.1.45.4) 4.412 ms 5.305 ms
4 150.1.34.3 (150.1.34.3) 6.099 ms 150.1.34.4 (150.1.34.4) 8.906 ms 150.1.34.3
(150.1.34.3) 5.444 ms
MPLS Label=306096 CoS=0 TTL=1 S=1
5 150.1.13.1 (150.1.13.1) 7.860 ms 8.379 ms 6.602 ms
6 150.1.12.1 (150.1.12.1) 5.970 ms 170.1.210.1 (170.1.210.1) 7.437 ms 7.936 ms

lab@VMX-VR> traceroute routing-instance C4 source 2016:170:1:240::1 2016:170:1:210::1

traceroute6 to 2016:170:1:210::1 (2016:170:1:210::1) from 2016:170:1:240::1, 64 hops max,
12 byte packets
1 * * *
2 * * *
3 2016:150:1:34::3 (2016:150:1:34::3) 6.608 ms * 6.247 ms
MPLS Label=306096 CoS=0 TTL=1 S=0
MPLS Label=2 CoS=0 TTL=1 S=1
4 2016:150:1:34::4 (2016:150:1:34::4) 8.233 ms 2016:150:1:13::1 (2016:150:1:13::1)
5.900 ms 5.035 ms
MPLS Label=310864 CoS=0 TTL=1 S=0

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

MPLS Label=2 CoS=0 TTL=1 S=1
5 2016:170:1:210::1 (2016:170:1:210::1) 7.868 ms 2016:150:1:24::2 (2016:150:1:24::2)
6.655 ms 5.448 ms
MPLS Label=303136 CoS=0 TTL=1 S=0
MPLS Label=2 CoS=0 TTL=2 S=1

Task 3. This task examines BGP FlowSpec, a DDoS mitigation solution defined in RFC 5575. The idea
behind BGP FlowSpec is to rely on BGP scalability to advertise detailed information about the attack
vectors, called Flow Specifications that can be used in traffic filters of routers. The IETF’s RFC defines a
new class of NLRI that is used to carry information of flows with 12 types below and 4 actions of rate-
limiting, drop, redirect and marking:

• Source/Destination Prefix
• Source/Destination Port
• IP Protocol
• ICMP Type/Code
• TCP Flag
• Packet Length

• DSCP
• Fragment Encoding

From configuration perspectives, all routers within AS 1.57920 need to support the BGP FlowSpec AFI,
configured with statement family inet flow under protocols bgp group stanza. Each router can locally
originate a flow specification, hence the policy-statement LOCAL-FLOWSPEC. Also later on when the AS
switches to a route-server system, each router needs to accept flow specification originated by that
route-server, hence the policy-statement RT-FLOWSPEC. Each policy is featured with keywords prefix-
length /32-/32 to govern that only host routes are accepted.

RFC 5575 defines two criteria below for validating flow specification sent by a remote device:

1. The originator of the flow specification matches the originator of the best-match unicast route
for the destination prefix embedded in the flow specification.
2. There are no more specific unicast routes, when compared with the flow destination prefix, that
have been received from a different neighboring AS than the best-match unicast route, which
has been determined in step 1.

These validation rules may prevent a flow specification advertised by a remote device such as a route
reflector or a server, hence we would need to bypass these rules for such occasion with statement no-
validate at the statement family inet flow. Also the RFC standardises the term ordering algorithm, it is
recommended to change from JUNOS default to the standard with statement flow term-order standard
under routing-options stanza.

On R3, as required by the task we locally define the flow specifications with statement flow route under
routing-options stanza. These specifications should be able to propagate to other routers if the policy-
statement RT-FLOWSPEC is configured properly.
lab@VMX-R3> show route table inetflow.0

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

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

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

150.1.1.30,123.0.0.1,proto=1/term:1
*[Flow/5] 00:01:46
Fictitious
150.1.1.60,123.0.1.1,proto=17/term:2
*[Flow/5] 00:01:46
Fictitious

lab@VMX-R1> show route table inetflow.0

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

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

150.1.1.30,123.0.0.1,proto=1/term:1
*[BGP/170] 00:01:34, localpref 100, from 150.1.1.3
AS path: I, validation-state: unverified
Fictitious
150.1.1.60,123.0.1.1,proto=17/term:2
*[BGP/170] 00:01:34, localpref 100, from 150.1.1.3
AS path: I, validation-state: unverified
Fictitious

And the two specifications should be installed into the default system filter for BGP FlowSpec:
__flowspec_default_inet__ which is applied in the inbound direction at PFE level.

lab@VMX-R1> show firewall filter __flowspec_default_inet__

Filter: __flowspec_default_inet__
Counters:
Name Bytes Packets
150.1.1.30,123.0.0.1,proto=1 0 0
150.1.1.60,123.0.1.1,proto=17 0 0

Task 4. This task brings about a very common policy that ISPs offer to their customers or peers to
simplify the change of traffic-engineering that gives customers/peers to dynamically control traffic flows
in accordance with their needs instead of contacting the ISPs to make such change. From BGP
advertisements of P1 peers, we can easily figure out the BGP community value that should be used for
this task.
lab@VMX-R1> show route receive-protocol bgp 150.1.100.2 100.1.0.0/26 extensive | match
Comm
Communities: 57920:2500

lab@VMX-R1> show route receive-protocol bgp 150.1.100.2 100.2.0.0/25 extensive | match

Comm
Communities: 57920:2500

lab@VMX-R1> show route receive-protocol bgp 150.1.100.2 100.3.0.0/23 extensive | match

Comm

lab@VMX-R1> show route receive-protocol bgp 150.1.100.2 100.4.0.0/22 extensive | match

Comm

lab@VMX-R1>

lab@VMX-R2> show route receive-protocol bgp 150.1.113.2 100.1.0.0/26 extensive | match

Comm

lab@VMX-R2> show route receive-protocol bgp 150.1.113.2 100.2.0.0/25 extensive | match

Comm

lab@VMX-R2> show route receive-protocol bgp 150.1.113.2 100.3.0.0/23 extensive | match

Comm
Communities: 57920:2500

lab@VMX-R2> show route receive-protocol bgp 150.1.113.2 100.4.0.0/22 extensive | match

Comm
Communities: 57920:2500

lab@VMX-R2>

As can be seen above, the community value selectively attached to the prefixes is 57920:2500 and it

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

clearly indicates that P1 would like AS 1.57920 to send traffic to its prefixes 100.1.0.0/26 and
100.2.0.0/25 via link R1-P1 while the link R2-P1 is preferred for prefixes 100.3.0.0/23 and 100.4.0.0/22.
In order to satisfy this requirement and support changes in the future (if any) made by P1, we can use
the community value in policy-statements that apply local-preference value based on receiving
community value. The policy-statements have got default local preference of 100 and set a local
preference of 2500 upon receiving community 57920:2500 (default local preference value is 100 already
but it is explicitly configured here for clarity). This way we can still achieve the goal of having
primary/backup links.

This task requires that the switchover from primary to backup link is faster than iBGP re-convergence.
This is achieved with knob advertise-external under protocols bgp group stanza. This causes the
configured router to keep advertising the best external routes even if they are not the best paths. To
demonstrate this point, let’s temporarily disable the feature on R2. You can see that even though R2
receives prefix 100.1.0.0/26 from its own direct link with P1 (via ge-0/0/4.113), it still has to follow the
path via R1-P1 link simply because of higher local preference value of 2500 which has got AS-wide
enforcement.

lab@VMX-R2# deactivate protocols bgp group IBGP-CONFED advertise-external

[edit]
lab@VMX-R2# commit
commit complete

[edit]
lab@VMX-R2# run show route 100.1.0.0/26

inet.0: 105 destinations, 180 routes (101 active, 0 holddown, 4 hidden)

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

100.1.0.0/26 *[BGP/170] 00:10:39, localpref 2500, from 150.1.1.1

AS path: 100 I, validation-state: unverified
> to 150.1.12.1 via ge-0/0/2.0, label-switched-path R2-TO-R1
to 150.1.24.4 via ge-0/0/6.0, label-switched-path Bypass-
>150.1.12.1
[BGP/170] 19:28:23, localpref 100
AS path: 100 I, validation-state: unverified
> to 150.1.113.2 via ge-0/0/4.113

So far so good, everything goes normally as expected. Now from R3 or R4’s perspectives, the best path
towards prefix 100.1.0.0/26 is via R1 certainly because of local preference 2500. Even though we know
that R2 has got a backup path but it does not appear here because R2 does not advertise its route in lieu
of R1’s best route. When the link P1-R1 fails, it would take some time for R2 to realise it and start
advertising its route towards 100.1.0.0/26. During that time, traffic blackholing may happen.
lab@VMX-R3> show route 100.1.0.0/26

inet.0: 111 destinations, 267 routes (106 active, 0 holddown, 5 hidden)

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

100.1.0.0/26 *[BGP/170] 00:02:21, localpref 2500, from 150.1.1.1

AS path: 100 I, validation-state: unverified
> to 150.1.34.4 via ge-0/0/2.0, label-switched-path R3-TO-R1
to 150.1.13.1 via ge-0/0/6.0, label-switched-path Bypass-
>150.1.34.4->150.1.24.2

lab@VMX-R2# run show route advertising-protocol bgp 150.1.1.3 | match 100.1.0.0/26 |

count
Count: 0 lines

In order to make R2 keep advertising its route to R3 and R4, let’s re-activate the advertise-external
feature. As you can see below, the backup path from R2 is advertised along and when the primary path

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

fails, the router will switch over to the backup path in a faster manner.
lab@VMX-R2# rollback 1
load complete

[edit]
lab@VMX-R2# show | compare
[edit protocols bgp group IBGP-CONFED]
! active: advertise-external { ... }
co
[edit]
lab@VMX-R2# commit and-quit
commit complete

lab@VMX-R2# run show route advertising-protocol bgp 150.1.1.3 | match 100.1.0.0/26 |

count
Count: 1 lines

lab@VMX-R3> show route 100.1.0.0/26

inet.0: 112 destinations, 210 routes (103 active, 0 holddown, 9 hidden)

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

100.1.0.0/26 *[BGP/170] 16:04:21, localpref 2500, from 150.1.1.1

AS path: 100 I, validation-state: unverified
> to 150.1.13.1 via ge-0/0/6.0, label-switched-path R3-TO-R1

to 150.1.34.4 via ge-0/0/2.0, label-switched-path Bypass-

>150.1.13.1
[BGP/170] 00:00:17, localpref 100, from 150.1.1.2
AS path: 100 I, validation-state: unverified
> to 150.1.34.4 via ge-0/0/2.0, label-switched-path R3-TO-R2
to 150.1.13.1 via ge-0/0/6.0, label-switched-path Bypass-
>150.1.34.4->150.1.24.2

Task 5 examines the conditional default route generation with statement generate route under routing-
options stanza coupled with knob policy. We can use a tracking prefix (normally it would be a large
supernet on the Internet) in the policy such that upon the existence of it, the default route will be
generated.
lab@VMX-R6> show route 0.0.0.0/0 exact detail

inet.0: 111 destinations, 172 routes (106 active, 0 holddown, 5 hidden)

0.0.0.0/0 (1 entry, 1 announced)
*Aggregate Preference: 130
<snip>
Task: Aggregate
Announcement bits (3): 0-KRT 4-Resolve tree 2 6-BGP_RT_Background
AS path: I
Flags: Generate Resolve Depth: 0 Active
Contributing Routes (1):
123.0.0.0/24 proto BGP

lab@VMX-R6> show route ::/0 exact detail

inet6.0: 91 destinations, 140 routes (91 active, 0 holddown, 0 hidden)

::/0 (1 entry, 1 announced)
*Aggregate Preference: 130
<snip>
Task: Aggregate
Announcement bits (3): 0-KRT 4-BGP_RT_Background 5-Resolve tree 5
AS path: I
Flags: Generate Resolve Depth: 0 Active
Contributing Routes (1):
2016:123::/64 proto BGP

The next point is the use of BGP AS_PATH Regular Expression which you can find more details in URL
https://www.juniper.net/techpubs/en_US/junos/topics/usage-guidelines/policy-configuring-as-path-
regular-expressions-to-use-as-routing-policy-match-conditions.html. In order to specify routes with the
exact AS_PATH length of X occurences of ASN, we use the notion of “.{0,X}”. This includes the local ASN
that is tagged into all routes advertised towards an eBGP peer.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

lab@VMX-R6> show route advertising-protocol bgp 150.1.107.2

inet.0: 111 destinations, 172 routes (106 active, 0 holddown, 5 hidden)

Prefix Nexthop MED Lclpref AS path
* 0.0.0.0/0 Self I
* 12.0.0.0/24 Self 222 I
* 100.0.0.0/24 Self 100 I
* 100.1.0.0/26 Self 100 I
* 100.2.0.0/25 Self 100 I
* 100.3.0.0/23 Self 100 I
* 100.4.0.0/22 Self 100 I
* 100.5.0.0/21 Self 100 I
* 100.6.0.1/32 Self 100 I
<snip-for-brevity>

inet6.0: 91 destinations, 140 routes (91 active, 0 holddown, 0 hidden)

Prefix Nexthop MED Lclpref AS path
* ::/0 Self I
* 2016:12::/64 Self 222 I
* 2016:100::/64 Self 100 I
* 2016:100:1::/66 Self 100 I
* 2016:100:2::/65 Self 100 I
* 2016:100:3::/63 Self 100 I
* 2016:100:4::/62 Self 100 I
* 2016:100:5::/48 Self 100 I

* 2016:100:6::1/128 Self 100 I

<snip-for-brevity>

Topic 5: VPN
Total Points: 38

• CE1-1: 172.30.1[0-9].1
• CE1-2: 172.30.2[0-9].1
• CE1-3: 172.30.3[0-9].1
R1,R2,R3,R4,R6
!
set policy-options community VPN1-HUB-RT member target:57920:3310
set policy-options community VPN1-HUB-SOO member origin:57920:3310
set policy-options community VPN1-SPOKE-RT member target:57920:3311
set policy-options community VPN1-SPOKE-SOO member origin:57920:3311

R1,R2,R3,R4
!
set protocols bgp group IBGP-CONFED family inet-vpn unicast loops 3

R3,R4,R6
!
set protocols bgp group EBGP-CONFED family inet-vpn unicast loops 3

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

set protocols bgp group VPN1-HUB peer-as 65501
set protocols bgp group VPN1-HUB as-override
set protocols bgp group VPN1-HUB neighbor 172.16.117.2
set protocols bgp group VPN1-HUB family inet unicast loops 3
set vrf-table-label
exit
edit routing-instance VPN1-SPOKE
set instance-type vrf
set vrf-import VPN1-SPOKE-IMPORT
set vrf-export DENY-ALL
set interface ge-0/0/4.118
set protocols bgp group VPN1-SPOKE type external
set protocols bgp group VPN1-SPOKE peer-as 65501
set protocols bgp group VPN1-SPOKE as-override
set protocols bgp group VPN1-SPOKE neighbor 172.16.118.2
set vrf-table-label
exit
set policy-options policy-statement DENY-ALL term DENY-ALL then reject
edit policy-options policy-statement VPN1-HUB-EXPORT
set term 1 from protocol [direct bgp]
set term 1 then community set VPN1-HUB-RT
set term 1 then community add VPN1-HUB-SOO
set term 1 then accept
exit
edit policy-options policy-statement VPN1-SPOKE-IMPORT
set term 1 from protocol bgp
set term 1 from community VPN1-HUB-SOO

set term 1 then reject

set term 2 from protocol bgp
set term 2 from community VPN1-SPOKE-RT
set term 2 then accept
exit

R2
!
set routing-options route-distinguisher-id 150.1.1.2
edit routing-instance VPN1-SPOKE
set instance-type vrf
set vrf-import VPN1-SPOKE-IMPORT
set vrf-export VPN1-SPOKE-EXPORT
set interface ge-0/0/4.103
set protocols bgp group VPN1-SPOKE type external
set protocols bgp group VPN1-SPOKE peer-as 65501
set protocols bgp group VPN1-SPOKE as-override
set protocols bgp group VPN1-SPOKE neighbor 172.16.103.2
set vrf-table-label
exit
edit policy-options policy-statement VPN1-SPOKE-EXPORT
set term 1 from protocol [direct bgp]
set term 1 then community add VPN1-SPOKE-RT
set term 1 then community add VPN1-SPOKE-SOO
set term 1 then accept
exit
edit policy-options policy-statement VPN1-SPOKE-IMPORT
set term 1 from protocol bgp
set term 1 from community VPN1-SPOKE-SOO
set term 1 then reject
set term 2 from protocol bgp
set term 2 from community VPN1-HUB-RT
set term 2 then accept
exit

R3
!
set routing-options route-distinguisher-id 150.1.1.3
edit routing-instance VPN1-HUB
set instance-type vrf
set vrf-import DENY-ALL
set vrf-export VPN1-HUB-EXPORT
set interface ge-0/0/4.132
set protocols bgp group VPN1-HUB type external
set protocols bgp group VPN1-HUB peer-as 65501
set protocols bgp group VPN1-HUB as-override
set protocols bgp group VPN1-HUB neighbor 172.16.132.2
set protocols bgp group VPN1-HUB family inet unicast loops 3
set vrf-table-label
exit

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

edit routing-instance VPN1-SPOKE
set instance-type vrf
set vrf-import VPN1-SPOKE-IMPORT
set vrf-export DENY-ALL
set interface ge-0/0/4.133
set protocols bgp group VPN1-SPOKE type external
set protocols bgp group VPN1-SPOKE peer-as 65501
set protocols bgp group VPN1-SPOKE as-override
set protocols bgp group VPN1-SPOKE neighbor 172.16.133.2
set vrf-table-label
exit
set policy-options policy-statement DENY-ALL term DENY-ALL then reject
edit policy-options policy-statement VPN1-HUB-EXPORT
set term 1 from protocol [direct bgp]
set term 1 then community set VPN1-HUB-RT
set term 1 then community add VPN1-HUB-SOO
set term 1 then accept
exit
edit policy-options policy-statement VPN1-SPOKE-IMPORT
set term 1 from protocol bgp
set term 1 from community VPN1-HUB-SOO
set term 1 then reject
set term 2 from protocol bgp
set term 2 from community VPN1-SPOKE-RT
set term 2 then accept
exit

R4
!
set routing-options route-distinguisher-id 150.1.1.4
edit routing-instance VPN1-SPOKE
set instance-type vrf
set vrf-import VPN1-SPOKE-IMPORT
set vrf-export VPN1-SPOKE-EXPORT
set interface ge-0/0/4.134
set protocols bgp group VPN1-SPOKE type external
set protocols bgp group VPN1-SPOKE peer-as 65501
set protocols bgp group VPN1-SPOKE as-override
set protocols bgp group VPN1-SPOKE neighbor 172.16.134.2
set vrf-table-label
exit
edit policy-options policy-statement VPN1-SPOKE-EXPORT
set term 1 from protocol [direct bgp]
set term 1 then community add VPN1-SPOKE-RT
set term 1 then community add VPN1-SPOKE-SOO
set term 1 then accept
exit
edit policy-options policy-statement VPN1-SPOKE-IMPORT
set term 1 from protocol bgp
set term 1 from community VPN1-SPOKE-SOO
set term 1 then reject
set term 2 from protocol bgp
set term 2 from community VPN1-HUB-RT
set term 2 then accept
exit

R6
!
set routing-options route-distinguisher-id 150.1.1.6
edit routing-instance VPN1-SPOKE
set instance-type vrf
set vrf-import VPN1-SPOKE-IMPORT
set vrf-export VPN1-SPOKE-EXPORT
set interface ge-0/0/4.112
set protocols bgp group VPN1-SPOKE type external
set protocols bgp group VPN1-SPOKE peer-as 65501
set protocols bgp group VPN1-SPOKE as-override
set protocols bgp group VPN1-SPOKE neighbor 172.16.112.2
set vrf-table-label
exit
edit policy-options policy-statement VPN1-SPOKE-EXPORT
set term 1 from protocol [direct bgp]
set term 1 then community add VPN1-SPOKE-RT
set term 1 then accept
exit
edit policy-options policy-statement VPN1-SPOKE-IMPORT
set term 1 from protocol bgp

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

set term 1 from community VPN1-HUB-RT
set term 1 then accept
exit

set term PASSTHRU-SPOKE-PREFIXES then accept

set term PRIMARY from protocol bgp
set term PRIMARY from community AS-VPN-OUTBOUND-PRIMARY
set term PRIMARY then local-preference 500
set term PRIMARY then accept
set term DEFAULT from protocol bgp
set term DEFAULT then local-preference 100
set term DEFAULT then accept
exit
set policy-options community AS-VPN-OUTBOUND-PRIMARY member 57920:3500

R3
!
edit routing-instance VPN1-HUB
set protocols bgp group VPN1-HUB neighbor 172.16.132.2 import VPN1-HUB-CE-IN
exit
edit policy-options policy-statement VPN1-HUB-CE-IN
set term PASSTHRU-SPOKE-PREFIXES from protocol bgp
set term PASSTHRU-SPOKE-PREFIXES from community VPN1-SPOKE-RT
set term PASSTHRU-SPOKE-PREFIXES then accept
set term PRIMARY from protocol bgp
set term PRIMARY from community AS-VPN-OUTBOUND-PRIMARY
set term PRIMARY then local-preference 500
set term PRIMARY then accept
set term DEFAULT from protocol bgp
set term DEFAULT then local-preference 100
set term DEFAULT then accept
exit
set policy-options community AS-VPN-OUTBOUND-PRIMARY member 57920:3500

Task 3 (5 points). The spoke CE1-2 is multi-homed to R2 and R4 in a primary/backup scenario where R2
is the primary point for both inbound/outbound traffic while R4 is the backup point. Deploy L3VPN
Egress Protection on R2 and R4 such that one router is the Protected PE while the other is the Protector
PE, and to provide faster restoration for traffic going across R2 in the case R2 fails. You are allowed to
use IP address 150.1.1.24/32 for this purpose.
R1,R2,R3,R4,R5,R6,R7,R8
!
set protocols isis backup-spf-options per-prefix-calculation
set groups CORE-INTERFACES protocols isis interface "<ge-0/0/[2678].0>" node-link-
protection
set protocols bgp group IBGP-CONFED family inet-vpn unicast egress-protection

R2
!
set protocols mpls egress-protection context-identifier 150.1.1.24 primary

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

set routing-instance VPN1-SPOKE egress-protection context-identifier 150.1.1.24
set routing-instance VPN1-SPOKE protocols bgp group VPN1-SPOKE export CE1-2-OUT
edit protocols bgp group IBGP-CONFED
set family inet-vpn unicast egress-protection
delete export
set export [EP-SET-CONTEXT-ID NHS LOCAL-FLOWSPEC]
set vpn-apply-export
exit
edit policy-options policy-statement EP-SET-CONTEXT-ID
set term VPN1-SPOKE from tag2 3311
set term VPN1-SPOKE then next-hop 150.1.1.24
set term VPN1-SPOKE then accept
exit
edit policy-options policy-statement CE1-2-OUT
set term VPN1-SPOKE from protocol bgp
set term VPN1-SPOKE then metric 100
set term VPN1-SPOKE then accept
exit
set policy-options policy-statement VPN1-SPOKE-EXPORT term 1 then tag2 add 3311

R4
!
set protocols mpls egress-protection context-identifier 150.1.1.24 protector
set routing-instance VPN1-SPOKE protocols bgp group VPN1-SPOKE export CE1-2-OUT
edit protocols bgp group IBGP-CONFED
set family inet-vpn unicast egress-protection
delete export

set export [EP-SET-CONTEXT-ID AS-AGGREGATE NHS LOCAL-FLOWSPEC]

set vpn-apply-export
exit
edit policy-options policy-statement EP-SET-CONTEXT-ID
set term VPN1-SPOKE from tag2 3311
set term VPN1-SPOKE then next-hop 150.1.1.24
set term VPN1-SPOKE then accept
exit
edit policy-options policy-statement CE1-2-OUT
set term VPN1-SPOKE from protocol bgp
set term VPN1-SPOKE then metric 500
set term VPN1-SPOKE then accept
exit
set policy-options policy-statement VPN1-SPOKE-EXPORT term 1 then tag2 add 3311

• CE3-1: 172.30.70.1
• CE3-2: 172.30.80.1
• CE3-3: 172.30.170.1
R1
!
set routing-options route-distinguisher-id 150.1.1.1
edit routing-instance VPN3
set instance-type vrf
set vrf-target target:57920:3330
set interface ge-0/0/3.145
set protocols ospf area 0.0.0.0 interface ge-0/0/3.145
set protocols ospf export BGP-TO-OSPF
set vrf-table-label
exit
edit policy-options policy-statement BGP-TO-OSPF
set term 1 from protocol bgp
set term 1 then accept
exit

R2
!

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

set routing-options route-distinguisher-id 150.1.1.2
edit routing-instance VPN3
set instance-type vrf
set vrf-target target:57920:3330
set interface ge-0/0/4.144
set protocols ospf area 0.0.0.0 interface ge-0/0/4.144
set protocols ospf export BGP-TO-OSPF
set vrf-table-label
exit
edit policy-options policy-statement BGP-TO-OSPF
set term 1 from protocol bgp
set term 1 then accept
exit

R8
!
set routing-options route-distinguisher-id 150.1.1.8
edit routing-instance VPN3
set instance-type vrf
set vrf-target target:57920:3330
set interface ge-0/0/4.108
set protocols ospf area 0.0.0.1 interface ge-0/0/4.108
set protocols ospf export BGP-TO-OSPF
set protocols ospf traceoptions file vpn3.ospf.log
set protocols ospf traceoptions flag all
set vrf-table-label
exit
edit policy-options policy-statement BGP-TO-OSPF

set term 1 from protocol bgp

set term 1 then accept
exit

/* route leaking between VPN1 and VPN3 */

R1
!
edit routing-instances VPN1-HUB
set routing-options auto-export
exit
edit routing-instances VPN1-SPOKE
set routing-options auto-export
exit
edit policy-options policy-statement VPN1-HUB-EXPORT
set term 1 then community add VPN-RT-SHARING
exit
edit policy-options policy-statement VPN1-SPOKE-IMPORT
set term VPN1-VPN3 from community VPN-RT-SHARING
set term VPN1-VPN3 from route-filter 172.30.0.0/16 prefix-length-range /24-/24
set term VPN1-VPN3 then accept
exit
edit routing-instances VPN3
set routing-options auto-export
delete vrf-target
set vrf-import VPN3-IMPORT
set vrf-export VPN3-EXPORT
exit
edit policy-options policy-statement VPN3-IMPORT
set term 1 from protocol bgp
set term 1 from community VPN3-RT
set term 1 then accept
set term VPN1-VPN3 from community VPN-RT-SHARING
set term VPN1-VPN3 from route-filter 172.30.0.0/16 prefix-length-range /24-/24
set term VPN1-VPN3 then accept
exit
edit policy-options policy-statement VPN3-EXPORT
set term 1 from protocol [direct ospf]
set term 1 then community add VPN3-RT
set term 1 then community add VPN-RT-SHARING
set term 1 then accept
exit
set policy-options community VPN3-RT member target:57920:3330
set policy-options community VPN-RT-SHARING member target:57920:3000

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

routing-instance on VRF device with some test IPv4 addresses below.

• CE2-2: 172.30.40.2
• CE2-4: 172.30.40.4
• CE2-5: 172.30.40.5

R3,R4,R5,R6
!
set protocols bgp group IBGP-CONFED family l2vpn signaling
set protocols bgp group EBGP-CONFED family l2vpn signaling

R2
!
set interface ge-0/0/3 flexible-vlan-tagging encapsulation flexible-ethernet-services
set interface ge-0/0/3.104 vlan-id 104 encap vlan-vpls
edit routing-instance VPN2
set instance-type vpls
set interface ge-0/0/3.104
set protocol vpls encapsulation ethernet-vlan
set protocol vpls vpls-id 3220
set protocol vpls neighbor 150.1.1.6 backup 150.1.1.8
set protocol vpls neighbor 150.1.1.7
set protocol vpls no-tunnel-services

exit
set protocols ldp interface lo0.0

R6
!
set protocols bgp group IBGP-CONFED family l2vpn signaling
set routing-options route-distinguisher-id 150.1.1.6
set interface ge-0/0/4 flexible-vlan-tagging encapsulation flexible-ethernet-services
set interface ge-0/0/4.104 encapsulation vlan-vpls
edit routing-instances VPN2
set instance-type vpls
set vrf-target target:57920:3220
set interface ge-0/0/4.104
set protocol vpls site CE2-2 site-id 2 multi-homing
set protocol vpls site CE2-2 site-preference primary
set protocol vpls site CE2-2 mesh-group LDP-PE
set protocol vpls no-tunnel-services
set protocol vpls mesh-group LDP-PE vpls-id 3220
set protocol vpls mesh-group LDP-PE neighbor 150.1.1.2 encapsulation ethernet-vlan
exit
set protocols ldp interface lo0.0

R7
!
set protocols bgp group IBGP-CONFED family l2vpn signaling
set routing-options route-distinguisher-id 150.1.1.7
set interface ge-0/0/3 flexible-vlan-tagging encapsulation flexible-ethernet-services
set interface ge-0/0/3.104 encapsulation vlan-vpls
edit routing-instances VPN2
set instance-type vpls
set vrf-target target:57920:3220
set interface ge-0/0/3.104
set protocol vpls site CE2-5 site-id 5
set protocol vpls site CE2-5 mesh-group LDP-PE
set protocol vpls no-tunnel-services
set protocol vpls mesh-group LDP-PE vpls-id 3220
set protocol vpls mesh-group LDP-PE neighbor 150.1.1.2 encapsulation ethernet-vlan
exit
set protocols ldp interface lo0.0

R8
!
set protocols bgp group IBGP-CONFED family l2vpn signaling
set routing-options route-distinguisher-id 150.1.1.8
set interface ge-0/0/4 flexible-vlan-tagging encapsulation flexible-ethernet-services
set interface ge-0/0/4.104 encapsulation vlan-vpls
edit routing-instances VPN2
set instance-type vpls
set vrf-target target:57920:3220
set interface ge-0/0/4.104

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

set protocol vpls site CE2-2 site-id 2 multi-homing
set protocol vpls site CE2-2 site-preference backup
set protocol vpls site CE2-2 mesh-group LDP-PE
set protocol vpls no-tunnel-services
set protocol vpls mesh-group LDP-PE vpls-id 3220
set protocol vpls mesh-group LDP-PE neighbor 150.1.1.2 encapsulation ethernet-vlan
exit
set protocols ldp interface lo0.0

lab@VMX-VR> ping rapid routing-instance CE5-1 source 172.30.160.51 172.30.160.52 size

1402 do-not-fragment

PING 172.30.160.52 (172.30.160.52): 1402 data bytes

.....
--- 172.30.160.52 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

Bonus/homework question (not required): In the opposite way, think about a solution where CE5-1 and
CE5-2 need to send packets with per-packet size of 1501 bytes without any fragmentation.
R1
!
set interface ge-0/0/3 flexible-vlan-tagging encapsulation flexible-ethernet-services
set interface ge-0/0/3.143 vlan-id 143 encapsulation vlan-ccc
set protocols bgp group IBGP-CONFED family l2vpn signaling
edit routing-instances VPN5
set instance-type l2vpn
set vrf-target target:57920:3250
set interface ge-0/0/3.143
set protocols l2vpn encapsulation ethernet-vlan
set protocols l2vpn site CE5-1 site-id 1
set protocols l2vpn site CE5-1 interface ge-0/0/3.143
exit
set interface ge-0/0/3.143 family ccc mtu 1447

R5
!
set interface ge-0/0/3 flexible-vlan-tagging encapsulation flexible-ethernet-services
set interface ge-0/0/3.143 vlan-id 143 encapsulation vlan-ccc
set routing-options route-distinguisher-id 150.1.1.5
edit routing-instances VPN5
set instance-type l2vpn
set vrf-target target:57920:3250
set interface ge-0/0/3.143
set protocols l2vpn encapsulation ethernet-vlan
set protocols l2vpn site CE5-2 site-id 2
set protocols l2vpn site CE5-2 interface ge-0/0/3.143
exit
set interface ge-0/0/3.143 family ccc mtu 1447

Task 7 (6 points). Improve the scalability for L3VPN services and optimise routers’ resouces such that:

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

• Limit broadcast, unknown-unicast, multicast traffic of customer VPN2 to protect the VPLS core
network from floods or denial of services attacks.
R1,R2,R7,R8
!
set protocols bgp group IBGP-CONFED family route-target

R3,R4,R5,R6
!
set protocols bgp group IBGP-CONFED family route-target advertise-default
set protocols bgp group EBGP-CONFED family route-target advertise-default

\* Note: Layer 3 VPN localisation is discontinued in JUNOS release 12.3R7, in which the
command becomes hidden and it is likely to be removed in later releases. Please ignore
this point if your JUNOS version does not support it. */

R1,R3
!
set routing-instances VPN1-HUB routing-options localize
set routing-instances VPN1-HUB routing-options maximum-prefixes 5000 threshold 80
set routing-instances VPN1-SPOKE routing-options localize
set routing-instances VPN1-SPOKE routing-options maximum-prefixes 5000 threshold 80

R2,R4
!

set routing-instances VPN1-SPOKE routing-options localize

set routing-instances VPN1-SPOKE routing-options maximum-prefixes 5000 threshold 80

R1,R2,R8
!
set routing-instances VPN3 routing-options localize

R2,R6,R7,R8
!
edit firewall family vpls filter VPLS-BUM-FILTER
set term 1 from traffic-type [ broadcast unknown-unicast multicast ]
set term 1 then policer VPLS-BUM-POLICER-10M
set term 1 then accept
exit
edit firewall policer VPLS-BUM-POLICER-10M
set if-exceeding bandwidth-limit 10m burst 5m
set then discard
exit
set routing-instance VPN2 forwarding-options family vpls flood input VPLS-BUM-FILTER

Verification
Task 1. This task is quite similar to Practice Lab 1, topic 5, task 1 where hub-spoke MPLS L3 VPN is
required with BGP as the PE-CE routing protocol. However the current task introduces the scenario of
dual uplinks for the hub CE1-1 and the spoke CE1-2 with a requirement of blocking routing loops. This
task may look similar to Practice Lab 1, topic 5, task 1 but it has got a tricky part of multi-tiered LSPs
where all routers do not have direct LSPs to each other. If you cannot resolve the multi-tiered LSPs
challenge in topic 3, the whole VPN section will not work.

Now regarding the loop protection of dual uplinks, this is simply achieved by adding an extended
community BGP SoO (Site of Origin) when exporting prefixes from PE routers and at the same time
discarding prefixes tagged with the same BGP SoO value when importing prefixes into the local Spoke
VRF.

Let’s ensure all BGP neighbourships with CE routers are now Established. And then we check routing
instance on spoke PE routers R4 and/or R6 to see whether they now have VPN routes advertised by the
hub PE routers being R1 and R3 as well as each other’s.
lab@VMX-R1> show bgp summary | match 65501
172.16.117.2 65501 20 16 0 0 6:00 Establ

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

172.16.118.2 65501 12 19 0 0 5:44 Establ

lab@VMX-R2> show bgp summary | match 65501

172.16.103.2 65501 14 22 0 0 6:00 Establ

lab@VMX-R3> show bgp summary | match 65501

172.16.132.2 65501 20 16 0 0 6:01 Establ
172.16.133.2 65501 13 19 0 0 5:45 Establ

lab@VMX-R4> show bgp summary | match 65501

172.16.134.2 65501 15 21 0 0 6:00 Establ

lab@VMX-R6> show bgp summary | match 65501

172.16.112.2 65501 16 21 0 0 6:33 Establ

lab@VMX-R6> show route table VPN1-SPOKE.inet.0 protocol bgp active-path | match 172.30
172.30.10.0/24 *[BGP/170] 00:06:46, localpref 100, from 150.1.1.4
172.30.11.0/24 *[BGP/170] 00:06:46, localpref 100, from 150.1.1.4
172.30.12.0/24 *[BGP/170] 00:06:46, localpref 100, from 150.1.1.4
172.30.13.0/24 *[BGP/170] 00:06:46, localpref 100, from 150.1.1.4
172.30.14.0/24 *[BGP/170] 00:06:46, localpref 100, from 150.1.1.4
172.30.15.0/24 *[BGP/170] 00:06:46, localpref 100, from 150.1.1.4
172.30.16.0/24 *[BGP/170] 00:06:46, localpref 100, from 150.1.1.4
172.30.17.0/24 *[BGP/170] 00:06:46, localpref 100, from 150.1.1.4
172.30.18.0/24 *[BGP/170] 00:06:46, localpref 100, from 150.1.1.4
172.30.19.0/24 *[BGP/170] 00:06:46, localpref 100, from 150.1.1.4
172.30.20.0/24 *[BGP/170] 00:06:46, localpref 100, from 150.1.1.4
172.30.21.0/24 *[BGP/170] 00:06:46, localpref 100, from 150.1.1.4

172.30.22.0/24 *[BGP/170] 00:06:46, localpref 100, from 150.1.1.4

172.30.23.0/24 *[BGP/170] 00:06:46, localpref 100, from 150.1.1.4
172.30.24.0/24 *[BGP/170] 00:06:46, localpref 100, from 150.1.1.4
172.30.25.0/24 *[BGP/170] 00:06:46, localpref 100, from 150.1.1.4
172.30.26.0/24 *[BGP/170] 00:06:46, localpref 100, from 150.1.1.4
172.30.27.0/24 *[BGP/170] 00:06:46, localpref 100, from 150.1.1.4
172.30.28.0/24 *[BGP/170] 00:06:46, localpref 100, from 150.1.1.4
172.30.29.0/24 *[BGP/170] 00:06:46, localpref 100, from 150.1.1.4
172.30.30.0/24 *[BGP/170] 00:06:57, localpref 100
172.30.31.0/24 *[BGP/170] 00:06:57, localpref 100
172.30.32.0/24 *[BGP/170] 00:06:57, localpref 100
172.30.33.0/24 *[BGP/170] 00:06:57, localpref 100
172.30.34.0/24 *[BGP/170] 00:06:57, localpref 100
172.30.35.0/24 *[BGP/170] 00:06:57, localpref 100
172.30.36.0/24 *[BGP/170] 00:06:57, localpref 100
172.30.37.0/24 *[BGP/170] 00:06:57, localpref 100
172.30.38.0/24 *[BGP/170] 00:06:57, localpref 100
172.30.39.0/24 *[BGP/170] 00:06:57, localpref 100

We can see that routing information is propagated properly within VPN1 sites such that all hub and
spoke sites have learnt prefixes of each other. Now let’s check routing advertisement between PE
routers that connect to the same hub/spoke site. As can be seen below, R1 and R3 don’t accept CE1-1
routes from each other to prevent loops, thanks to BGP SoO. Likewise, R2 and R4 don’t accept CE1-2
routes from each other.
lab@VMX-R1> show route receive-protocol bgp 150.1.1.3 table VPN1 active-path | match
172.30.1[0-9].0 | count
Count: 0 lines

lab@VMX-R3> show route receive-protocol bgp 150.1.1.1 table VPN1 active-path | match
172.30.1[0-9].0 | count
Count: 0 lines

lab@VMX-R2> show route receive-protocol bgp 150.1.1.4 table VPN1 active-path | match
172.30.2[0-9].0 | count
Count: 0 lines

lab@VMX-R4> show route receive-protocol bgp 150.1.1.2 table VPN1 active-path | match
172.30.2[0-9].0 | count
Count: 0 lines

Now let’s ensure that the forwarding path between CE1-2 (connecting to R2 and R4) and CE1-3
(connecting to R6) actually is across CE1-1 (connecting to R1 and R3). And also we should verify full
connectivity between the CE routers as well.

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

lab@VMX-VR> traceroute routing-instance CE1-2 source 172.30.20.1 172.30.30.1
traceroute to 172.30.30.1 (172.30.30.1) from 172.30.20.1, 30 hops max, 40 byte packets
1 172.16.103.1 (172.16.103.1) 58.952 ms 3.134 ms 1.684 ms
2 172.16.117.1 (172.16.117.1) 3.646 ms 3.448 ms 3.959 ms
3 172.16.117.2 (172.16.117.2) 5.618 ms 4.576 ms 4.232 ms
4 172.16.133.1 (172.16.133.1) 5.418 ms 5.451 ms 5.054 ms
5 150.1.35.5 (150.1.35.5) 8.008 ms 8.322 ms 8.571 ms
MPLS Label=312592 CoS=0 TTL=1 S=0
MPLS Label=16 CoS=0 TTL=1 S=1
6 172.16.112.1 (172.16.112.1) 8.957 ms 8.396 ms 7.261 ms
7 172.30.30.1 (172.30.30.1) 12.803 ms 9.909 ms 9.273 ms

lab@VMX-VR> ping rapid routing-instance CE1-1 source 172.30.10.1 172.30.20.1

lab@VMX-VR> ping rapid routing-instance CE1-1 source 172.30.10.1 172.30.30.1

lab@VMX-VR> ping rapid routing-instance CE1-2 source 172.30.20.1 172.30.30.1

Task 2 first requires you to find the BGP community value that is tagged to the routing advertisement
from CE1-1.
lab@VMX-R1> show route receive-protocol bgp 172.16.117.2 extensive | match
"entry|Communities"
<snip>
* 172.30.10.0/24 (1 entry, 1 announced)
Communities: 57920:3500
* 172.30.11.0/24 (1 entry, 1 announced)
Communities: 57920:3500
* 172.30.12.0/24 (1 entry, 1 announced)
Communities: 57920:3500
* 172.30.13.0/24 (1 entry, 1 announced)
Communities: 57920:3500
* 172.30.14.0/24 (1 entry, 1 announced)
Communities: 57920:3500
* 172.30.15.0/24 (1 entry, 1 announced)
* 172.30.16.0/24 (1 entry, 1 announced)
* 172.30.17.0/24 (1 entry, 1 announced)
* 172.30.18.0/24 (1 entry, 1 announced)
* 172.30.19.0/24 (1 entry, 1 announced)
* 172.30.20.0/24 (1 entry, 1 announced)
<snip>

lab@VMX-R3> show route receive-protocol bgp 172.16.132.2 extensive | match

"entry|Communities"
<snip>
* 172.30.10.0/24 (1 entry, 1 announced)
* 172.30.11.0/24 (1 entry, 1 announced)
* 172.30.12.0/24 (1 entry, 1 announced)
* 172.30.13.0/24 (1 entry, 1 announced)
* 172.30.14.0/24 (1 entry, 1 announced)
* 172.30.15.0/24 (1 entry, 1 announced)
Communities: 57920:3500
* 172.30.16.0/24 (1 entry, 1 announced)
Communities: 57920:3500
* 172.30.17.0/24 (1 entry, 1 announced)
Communities: 57920:3500
* 172.30.18.0/24 (1 entry, 1 announced)
Communities: 57920:3500
* 172.30.19.0/24 (1 entry, 1 announced)

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

Communities: 57920:3500
<snip>

Now the task may look quite similar to task 4 of the topic BGP, however it differs in two points, one is
that we would need to ensure the configuration only affects prefixes advertised by the hub CE1-1
(remember that CE1-1 also re-advertises prefixes from spoke CE1-2 and CE1-3). Thus, we should have a
term in the policy-statement to just pass through such spoke prefixes intact. The other point is that we
do not need to configure the knob advertise-external under protocols bgp group stanza because VPNv4
prefixes are always advertised by R1 and R3 along since they are different with the Route Distinguisher
ID appended to the IPv4 prefixes.
lab@VMX-R2> show route 172.30.10.0/24 table bgp.l3vpn.0

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

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

150.1.1.1:13:172.30.10.0/24
*[BGP/170] 00:20:56, localpref 500, from 150.1.1.1
AS path: 65501 I, validation-state: unverified
> to 150.1.12.1 via ge-0/0/2.0, label-switched-path R2-TO-R1
to 150.1.24.4 via ge-0/0/6.0, label-switched-path Bypass-
>150.1.12.1

150.1.1.3:10:172.30.10.0/24
*[BGP/170] 00:20:57, localpref 100, from 150.1.1.3
AS path: 65501 I, validation-state: unverified
> to 150.1.12.1 via ge-0/0/2.0, label-switched-path R2-TO-R3
to 150.1.24.4 via ge-0/0/6.0, label-switched-path Bypass-
>150.1.12.1->150.1.13.3

Task 3. JUNOS routers support L3VPN Egress Protection mechanism which allows for fast restoration of
connectivity in multihomed CE scenarios. Link/Node-Link Protection or Fast Reroute mechanisms only
work well with the failure of the transit MPLS node but cannot help much with regard to the failure of
PE because it’s the PEs that store customer routing/forwarding information. L3VPN Egress Protection
involves two roles, Protected PE and Protector PE sharing an anycast IP address (called Context-ID) that
is announced via IGP TE. Upon the failure of Protected PE, any transit router can perform traffic
redirection towards the Protector PE. Such transit router is called PLR or Point of Local Repair. To
perform this function, the PLR must have a pre-calculated loop-free alternate path (LFA) to the Context-
ID. There are two protection models of L3VPN Egress Protection depending on how CEs connect to the
PEs.

• Co-located Protector—In this model, one router acts as both Protected PE and Protector PE at
the same time, when the CE dual-uplinks into it. In the event of failure of the primary link, the
Protector PE function receives traffic from the PLR and routes the traffic to the multihomed site.
• Centralized protector—In this model, one router acts as Protected PE and another router acts as
Protector PE which might not have a direct connection to the multihomed CE. In the event of an
egress PE link or node failure, the Centralized Protector reroutes the traffic to the backup egress
PE router with the VPN label advertised for the backup egress PE router that takes over the role
of sending traffic to the multihomed CE.

You can find more information about L3VPN Egress Protection in URL
http://www.juniper.net/documentation/en_US/junos/topics/topic-map/mpls-egress-protection-layer-3-
vpn-services-configuration.html.

From configuration perspectives, prerequisites are 1) to enable per-prefix LFA in Node-Link Protection
mode for the IGP, achieved by using statements backup-spf-options per-prefix-calculation and

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

interface <*> node-link-protection under protocols isis stanza and 2) to activate Egress Protection
capability in the VPNv4 BGP AFI. Then you would need to activate the Egress Protection globally on the
Protected/Protector PE being R2, R4 respectively with statement egress-protection context-identifier
under protocols mpls stanza, followed by keyword primary or protector. Now we would need to rewrite
the next-hop of VPN4 prefixes learnt from CE1-2 from the regular loopback0 addresses of R2 and R4,
into the anycast next-hop (or Context-ID) of 150.1.1.24 (you do not need to add this anycast address
into any interface on R2 or R4). The next-hop rewritten policies for VPN prefxies will only have effect
when you issue knob vpn-apply-export under protocols bgp group stanza. R2 also serves another VPN
customer being CE2-3 so we would want to limit the next-hop rewriting to only customer VPN1 by using
tag2 in the import policies to signify customer VPN1. This tag value is locally stored on the router and
will not be advertised outside. Also since R2 is the primary PE, we should signal CE1-2 of its preference
to be via R2 by using export policies setting MED value on R2 and R4 accordingly.

Now let’s verify the operation of L3VPN Egress Protection. As you can see below, any transit router such
as R1 is already having pre-calculated loop-free alternate path towards the anycast address 150.1.1.24
that can be reached via label-switched paths as can be seen in table inet.3

lab@VMX-R1> show isis database detail | match "VMX-R[24].00-00|150.1.1.24/32"

VMX-R2.00-00 Sequence: 0xa2, Checksum: 0x9787, Lifetime: 65239 secs
IP IPV4 Unicast prefix: 150.1.1.24/32 Metric: 1 Internal Up
VMX-R4.00-00 Sequence: 0x13e, Checksum: 0x4e06, Lifetime: 63668 secs
IP IPV4 Unicast prefix: 150.1.1.24/32 Metric: 16777214 Internal Up

lab@VMX-R1> show route 150.1.1.24

inet.0: 110 destinations, 218 routes (106 active, 2 holddown, 4 hidden)

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

150.1.1.24/32 *[IS-IS/15] 22:29:01, metric 101

> to 150.1.12.2 via ge-0/0/2.0

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

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

150.1.1.24/32 *[LDP/9] 22:27:39, metric 101

> to 150.1.12.2 via ge-0/0/2.0, label-switched-path R1-TO-R2
to 150.1.13.3 via ge-0/0/6.0, label-switched-path R1-TO-R2
[IS-IS/15] 22:28:25, metric 101
> to 150.1.12.2 via ge-0/0/2.0, label-switched-path R1-TO-R2
to 150.1.13.3 via ge-0/0/6.0, label-switched-path Bypass-
>150.1.12.2

R1 is also seeing VPNv4 prefixes announcement from R2 and R4 with next-hop being the anycast
address as expected. However the preference should be via R2 as IGP metric towards the anycast
address is lower via R2.
lab@VMX-R1> show route receive-protocol bgp 150.1.1.2 table VPN1-SPOKE.inet.0

VPN1-SPOKE.inet.0: 25 destinations, 46 routes (25 active, 0 holddown, 0 hidden)

Prefix Nexthop MED Lclpref AS path
* 172.16.103.0/30 150.1.1.24 100 I
* 172.30.20.0/24 150.1.1.24 100 65501 I
* 172.30.21.0/24 150.1.1.24 100 65501 I
* 172.30.22.0/24 150.1.1.24 100 65501 I
* 172.30.23.0/24 150.1.1.24 100 65501 I
* 172.30.24.0/24 150.1.1.24 100 65501 I
* 172.30.25.0/24 150.1.1.24 100 65501 I
* 172.30.26.0/24 150.1.1.24 100 65501 I
* 172.30.27.0/24 150.1.1.24 100 65501 I
* 172.30.28.0/24 150.1.1.24 100 65501 I
* 172.30.29.0/24 150.1.1.24 100 65501 I

lab@VMX-R1> show route receive-protocol bgp 150.1.1.4 table VPN1-SPOKE.inet.0

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

VPN1-SPOKE.inet.0: 25 destinations, 46 routes (25 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 172.16.112.0/30 150.1.1.6 100 (64002) I
* 172.16.134.0/30 150.1.1.24 100 I
172.30.20.0/24 150.1.1.24 100 65501 I
172.30.21.0/24 150.1.1.24 100 65501 I
172.30.22.0/24 150.1.1.24 100 65501 I
172.30.23.0/24 150.1.1.24 100 65501 I
172.30.24.0/24 150.1.1.24 100 65501 I
172.30.25.0/24 150.1.1.24 100 65501 I
172.30.26.0/24 150.1.1.24 100 65501 I
172.30.27.0/24 150.1.1.24 100 65501 I
172.30.28.0/24 150.1.1.24 100 65501 I
172.30.29.0/24 150.1.1.24 100 65501 I
<snip>

R2 is advertising VPNv4 prefixes with next-hop of Context-ID and an inner VPN label value 300528. It is
important for the Protector R4 to beware of this label so that it will be able to deal with protected traffic
(inner label 300528) during a failure.
lab@VMX-R2> show route advertising-protocol bgp 150.1.1.1 extensive 172.30.20.0/24

VPN1-SPOKE.inet.0: 36 destinations, 80 routes (36 active, 0 holddown, 0 hidden)

* 172.30.20.0/24 (3 entries, 1 announced)
BGP group IBGP-CONFED type Internal

Route Distinguisher: 150.1.1.2:4

VPN Label: 300528
Nexthop: 150.1.1.24
Flags: Nexthop Change
Localpref: 100
AS path: [64001] 65501 I
Communities: target:57920:3311 origin:57920:3311

Connectivity between CE1-1, CE1-2 and CE1-3 should still be maintained.

lab@VMX-VR> ping rapid routing-instance CE1-1 source 172.30.10.1 172.30.20.1
PING 172.30.20.1 (172.30.20.1): 56 data bytes
!!!!!
--- 172.30.20.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 5.334/6.203/8.217/1.045 ms

lab@VMX-VR> ping rapid routing-instance CE1-1 source 172.30.10.1 172.30.30.1

lab@VMX-VR> ping rapid routing-instance CE1-2 source 172.30.20.1 172.30.30.1

Task 4 starts with a regular L3VPN service to be provisioned to customer VPN3 using OSPF as PE-CE
routing protocol. The task does not provide OSPF Area-ID for the site CE3-2 and we would need to figure
it out with traceoptions statements.
lab@VMX-R8> show configuration | display set |match traceoptions
set routing-instances VPN3 protocols ospf traceoptions file vpn3.ospf.log
set routing-instances VPN3 protocols ospf traceoptions flag all

lab@VMX-R8> show log vpn3.ospf.log

Aug 26 19:32:04 trace_on: Tracing to "/var/log/vpn3.ospf.log" started
<snip-for-brevity>
Feb 6 19:32:08.347313 OSPF rcvd Hello 172.16.108.2 -> 224.0.0.5 (ge-0/0/4.108 IFL 76
area 0.0.0.1)
Feb 6 19:32:08.347327 Version 2, length 48, ID 172.30.80.1, area 0.0.0.1
Feb 6 19:32:08.347340 checksum 0x0, authtype 0

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

Feb 6 19:32:08.347353 mask 255.255.255.252, hello_ivl 10, opts 0x12, prio 128
Feb 6 19:32:08.347366 dead_ivl 40, DR 172.16.108.2, BDR 172.16.108.1
Feb 6 19:32:08.347379 neighbor 172.16.108.1
<snip-for-brevity>

Let’s verify PE-CE routing neighbourship and propagation between the three sites.
lab@VMX-R1> show ospf neighbor instance VPN3
Address Interface State ID Pri Dead
172.16.145.2 ge-0/0/2.145 Full 172.30.70.1 128 36

lab@VMX-R2> show ospf neighbor instance VPN3

Address Interface State ID Pri Dead
172.16.144.2 ge-0/0/4.144 Full 172.30.170.1 128 33

lab@VMX-R8> show ospf neighbor instance VPN3

Address Interface State ID Pri Dead
172.16.108.2 ge-0/0/4.108 Full 172.30.80.1 128 32

lab@VMX-R1> show route table VPN3.inet.0 active-path | match 172.30

<snip>
172.30.70.0/24 *[OSPF/150] 00:49:57, metric 0, tag 0
172.30.71.0/24 *[OSPF/150] 00:49:57, metric 0, tag 0
172.30.72.0/24 *[OSPF/150] 00:49:57, metric 0, tag 0
172.30.73.0/24 *[OSPF/150] 00:49:57, metric 0, tag 0
172.30.74.0/24 *[OSPF/150] 00:49:57, metric 0, tag 0
172.30.75.0/24 *[OSPF/150] 00:49:57, metric 0, tag 0

172.30.76.0/24 *[OSPF/150] 00:49:57, metric 0, tag 0

172.30.77.0/24 *[OSPF/150] 00:49:57, metric 0, tag 0
172.30.78.0/24 *[OSPF/150] 00:49:57, metric 0, tag 0
172.30.79.0/24 *[OSPF/150] 00:49:57, metric 0, tag 0
172.30.80.0/24 *[BGP/170] 00:04:16, MED 0, localpref 100, from 150.1.1.4
172.30.81.0/24 *[BGP/170] 00:04:16, MED 0, localpref 100, from 150.1.1.4
172.30.82.0/24 *[BGP/170] 00:04:16, MED 0, localpref 100, from 150.1.1.4
172.30.83.0/24 *[BGP/170] 00:04:16, MED 0, localpref 100, from 150.1.1.4
172.30.84.0/24 *[BGP/170] 00:04:16, MED 0, localpref 100, from 150.1.1.4
172.30.85.0/24 *[BGP/170] 00:04:16, MED 0, localpref 100, from 150.1.1.4
172.30.86.0/24 *[BGP/170] 00:04:16, MED 0, localpref 100, from 150.1.1.4
172.30.87.0/24 *[BGP/170] 00:04:16, MED 0, localpref 100, from 150.1.1.4
172.30.88.0/24 *[BGP/170] 00:04:16, MED 0, localpref 100, from 150.1.1.4
172.30.89.0/24 *[BGP/170] 00:04:16, MED 0, localpref 100, from 150.1.1.4
172.30.170.0/24 *[BGP/170] 00:49:09, MED 0, localpref 100, from 150.1.1.2
172.30.171.0/24 *[BGP/170] 00:49:09, MED 0, localpref 100, from 150.1.1.2
172.30.172.0/24 *[BGP/170] 00:49:09, MED 0, localpref 100, from 150.1.1.2
172.30.173.0/24 *[BGP/170] 00:49:09, MED 0, localpref 100, from 150.1.1.2
172.30.174.0/24 *[BGP/170] 00:49:09, MED 0, localpref 100, from 150.1.1.2
172.30.175.0/24 *[BGP/170] 00:49:09, MED 0, localpref 100, from 150.1.1.2
172.30.176.0/24 *[BGP/170] 00:49:09, MED 0, localpref 100, from 150.1.1.2
172.30.177.0/24 *[BGP/170] 00:49:09, MED 0, localpref 100, from 150.1.1.2
172.30.178.0/24 *[BGP/170] 00:49:09, MED 0, localpref 100, from 150.1.1.2
172.30.179.0/24 *[BGP/170] 00:49:09, MED 0, localpref 100, from 150.1.1.2

lab@VMX-R2> show route table VPN3.inet.0 active-path | match 172.30

172.30.70.0/24 *[BGP/170] 00:02:29, MED 0, localpref 100, from 150.1.1.1
172.30.71.0/24 *[BGP/170] 00:02:29, MED 0, localpref 100, from 150.1.1.1
172.30.72.0/24 *[BGP/170] 00:02:29, MED 0, localpref 100, from 150.1.1.1
172.30.73.0/24 *[BGP/170] 00:02:29, MED 0, localpref 100, from 150.1.1.1
172.30.74.0/24 *[BGP/170] 00:02:29, MED 0, localpref 100, from 150.1.1.1
172.30.75.0/24 *[BGP/170] 00:02:29, MED 0, localpref 100, from 150.1.1.1
172.30.76.0/24 *[BGP/170] 00:02:29, MED 0, localpref 100, from 150.1.1.1
172.30.77.0/24 *[BGP/170] 00:02:29, MED 0, localpref 100, from 150.1.1.1
172.30.78.0/24 *[BGP/170] 00:02:29, MED 0, localpref 100, from 150.1.1.1
172.30.79.0/24 *[BGP/170] 00:02:29, MED 0, localpref 100, from 150.1.1.1
172.30.80.0/24 *[BGP/170] 00:02:19, MED 0, localpref 100, from 150.1.1.3
172.30.81.0/24 *[BGP/170] 00:02:19, MED 0, localpref 100, from 150.1.1.3
172.30.82.0/24 *[BGP/170] 00:02:19, MED 0, localpref 100, from 150.1.1.3
172.30.83.0/24 *[BGP/170] 00:02:19, MED 0, localpref 100, from 150.1.1.3
172.30.84.0/24 *[BGP/170] 00:02:19, MED 0, localpref 100, from 150.1.1.3
172.30.85.0/24 *[BGP/170] 00:02:19, MED 0, localpref 100, from 150.1.1.3
172.30.86.0/24 *[BGP/170] 00:02:19, MED 0, localpref 100, from 150.1.1.3
172.30.87.0/24 *[BGP/170] 00:02:19, MED 0, localpref 100, from 150.1.1.3
172.30.88.0/24 *[BGP/170] 00:02:19, MED 0, localpref 100, from 150.1.1.3
172.30.89.0/24 *[BGP/170] 00:02:19, MED 0, localpref 100, from 150.1.1.3
172.30.170.0/24 *[OSPF/150] 00:02:41, metric 0, tag 0
172.30.171.0/24 *[OSPF/150] 00:02:41, metric 0, tag 0
172.30.172.0/24 *[OSPF/150] 00:02:41, metric 0, tag 0
172.30.173.0/24 *[OSPF/150] 00:02:41, metric 0, tag 0

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

172.30.174.0/24 *[OSPF/150] 00:02:41, metric 0, tag 0
172.30.175.0/24 *[OSPF/150] 00:02:41, metric 0, tag 0
172.30.176.0/24 *[OSPF/150] 00:02:41, metric 0, tag 0
172.30.177.0/24 *[OSPF/150] 00:02:41, metric 0, tag 0
172.30.178.0/24 *[OSPF/150] 00:02:41, metric 0, tag 0
172.30.179.0/24 *[OSPF/150] 00:02:41, metric 0, tag 0

lab@VMX-R8> show route table VPN3.inet.0 active-path | match 172.30

172.30.70.0/24 *[BGP/170] 00:05:01, MED 0, localpref 100, from 150.1.1.5
172.30.71.0/24 *[BGP/170] 00:05:01, MED 0, localpref 100, from 150.1.1.5
172.30.72.0/24 *[BGP/170] 00:05:01, MED 0, localpref 100, from 150.1.1.5
172.30.73.0/24 *[BGP/170] 00:05:01, MED 0, localpref 100, from 150.1.1.5
172.30.74.0/24 *[BGP/170] 00:05:01, MED 0, localpref 100, from 150.1.1.5
172.30.75.0/24 *[BGP/170] 00:05:01, MED 0, localpref 100, from 150.1.1.5
172.30.76.0/24 *[BGP/170] 00:05:01, MED 0, localpref 100, from 150.1.1.5
172.30.77.0/24 *[BGP/170] 00:05:01, MED 0, localpref 100, from 150.1.1.5
172.30.78.0/24 *[BGP/170] 00:05:01, MED 0, localpref 100, from 150.1.1.5
172.30.79.0/24 *[BGP/170] 00:05:01, MED 0, localpref 100, from 150.1.1.5
172.30.80.0/24 *[OSPF/150] 00:05:01, metric 0, tag 0
172.30.81.0/24 *[OSPF/150] 00:05:01, metric 0, tag 0
172.30.82.0/24 *[OSPF/150] 00:05:01, metric 0, tag 0
172.30.83.0/24 *[OSPF/150] 00:05:01, metric 0, tag 0
172.30.84.0/24 *[OSPF/150] 00:05:01, metric 0, tag 0
172.30.85.0/24 *[OSPF/150] 00:05:01, metric 0, tag 0
172.30.86.0/24 *[OSPF/150] 00:05:01, metric 0, tag 0
172.30.87.0/24 *[OSPF/150] 00:05:01, metric 0, tag 0
172.30.88.0/24 *[OSPF/150] 00:05:01, metric 0, tag 0

172.30.89.0/24 *[OSPF/150] 00:05:01, metric 0, tag 0

172.30.170.0/24 *[BGP/170] 00:03:08, MED 0, localpref 100, from 150.1.1.5
172.30.171.0/24 *[BGP/170] 00:03:08, MED 0, localpref 100, from 150.1.1.5
172.30.172.0/24 *[BGP/170] 00:03:08, MED 0, localpref 100, from 150.1.1.5
172.30.173.0/24 *[BGP/170] 00:03:08, MED 0, localpref 100, from 150.1.1.5
172.30.174.0/24 *[BGP/170] 00:03:08, MED 0, localpref 100, from 150.1.1.5
172.30.175.0/24 *[BGP/170] 00:03:08, MED 0, localpref 100, from 150.1.1.5
172.30.176.0/24 *[BGP/170] 00:03:08, MED 0, localpref 100, from 150.1.1.5
172.30.177.0/24 *[BGP/170] 00:03:08, MED 0, localpref 100, from 150.1.1.5
172.30.178.0/24 *[BGP/170] 00:03:08, MED 0, localpref 100, from 150.1.1.5
172.30.179.0/24 *[BGP/170] 00:03:08, MED 0, localpref 100, from 150.1.1.5

Now we are certain that routes of customer VPN3 are propagated properly between PE routers R1, R2
and R8, let’s verify the forwarding plane, all CE routers should have reachability with each other.
lab@VMX-VR> ping rapid routing-instance CE3-1 source 172.30.70.1 172.30.80.1
PING 172.30.80.1 (172.30.80.1): 56 data bytes
!!!!!
--- 172.30.80.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 14.528/14.865/14.975/0.169 ms

lab@VMX-VR> ping rapid routing-instance CE3-1 source 172.30.70.1 172.30.170.1

PING 172.30.170.1 (172.30.170.1): 56 data bytes
!!!!!
--- 172.30.170.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 14.599/14.889/14.996/0.147 ms

lab@VMX-VR> ping rapid routing-instance CE3-2 source 172.30.80.1 172.30.170.1

JUNOS offers Auto-Export feature which allows for sharing routes between multiple routing-instances.
This is normally required when customer wants to exchange routes with partners. From configuration
perspectives, we need to activate the feature with statement routing-options auto-export under
routing-instances stanza. Normally in the next step we need to define a common shared target BGP
community value between the two routing-instances and then within each VRF we rely on statements
vrf-import and vrf-export under routing-instances stanza to 1) allow for the import of routes tagged
with that common shared target BGP community value and 2) tag that value when exporting routes

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

from the VRFs to MP-BGP. Once the configuration is in place, we should see the routes are shared
across, for example:
lab@VMX-R1> show route table VPN1-SPOKE.inet.0 172.30.70.0/24 extensive

VPN1-SPOKE.inet.0: 35 destinations, 56 routes (35 active, 0 holddown, 0 hidden)

172.30.70.0/24 (1 entry, 1 announced)
TSI:
KRT in-kernel 172.30.70.0/24 -> {172.16.145.2}
*OSPF Preference: 150
Next hop type: Router, Next hop index: 743
Address: 0x99746e4
Next-hop reference count: 43
Next hop: 172.16.145.2 via ge-0/0/2.145, selected
Session Id: 0x32
State: <Secondary Active Int Ext>
Age: 12 Metric: 0
Validation State: unverified
Tag: 0
Task: VPN3-OSPF
Announcement bits (1): 0-KRT
AS path: I
Communities: target:57920:3000 target:57920:3330 rte-type:0.0.0.0:5:1
Primary Routing Table VPN3.inet.0

lab@VMX-R1> show route table VPN3.inet.0 172.30.10.0/24 extensive

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

172.30.10.0/24 (1 entry, 1 announced)
TSI:
OSPF area : 0.0.0.0, LSA ID : 172.30.10.0, LSA type : Extern
KRT in-kernel 172.30.10.0/24 -> {172.16.117.2}
*BGP Preference: 170/-501
Next hop type: Router, Next hop index: 744
Address: 0x94c795c
Next-hop reference count: 126
Source: 172.16.117.2
Next hop: 172.16.117.2 via ge-0/0/4.117, selected
Session Id: 0x3
State: <Secondary Active Ext>
Peer AS: 65501
Age: 20:53
Validation State: unverified
Task: BGP_65501.172.16.117.2
Announcement bits (2): 0-VPN3-OSPF 1-KRT
AS path: 65501 I
Communities: target:57920:3000 target:57920:3310 origin:57920:3310
Accepted
Localpref: 500
Router ID: 172.30.10.1
Primary Routing Table VPN1-HUB.inet.0

Task 5. With regard to VPLS, there are two main signalling protocols: BGP and LDP. You may recall that
we have deployed each of these protocols in VPN topic of Practice Labs 1 and 4 respectively. This task
however presents a scenario that mixes both of these protocols in a VPLS domain. Normally such
scenario happens during network mergers or due to capability mismatch between PE routers. In this
task, sites CE2-2 and CE2-5 use BGP as signalling protocol while site CE2-4 uses LDP. JUNOS allows for
using both protocols under a routing-instance with feature protocol vpls mesh-group under routing-
instance stanza. In this task we use the mest-group feature to define LDP-signalled site and link it with
BGP-signalled portion by associating the mesh-group with BGP site at statement protocol vpls site.
From configuration perspectives, best practices indicate that we should use flexible-vlan-tagging and
encapsulation flexible-ethernet-services for the PE-CE interface (on PE only) so that later on it is easy
to perform activities such as VLAN Normalisation or deploy different types of Ethernet services. Let’s
verify VPLS state on PE routers:

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

lab@VMX-R2> show vpls connections | find Instance:

Instance: VPN2
VPLS-id: 3220
Neighbor Type St Time last up # Up trans
150.1.1.6(vpls-id 3220) rmt Up Feb 7 15:43:52 2017 1
Remote PE: 150.1.1.6, Negotiated control-word: No
Incoming label: 262402, Outgoing label: 262402
Negotiated PW status TLV: No
Local interface: lsi.1048580, Status: Up, Encapsulation: VLAN
Description: Intf - vpls VPN2 neighbor 150.1.1.6 vpls-id 3220
Flow Label Transmit: No, Flow Label Receive: No
150.1.1.8(vpls-id 3220) rmt BK
150.1.1.7(vpls-id 3220) rmt Up Feb 7 15:43:54 2017 1
Remote PE: 150.1.1.7, Negotiated control-word: No
Incoming label: 262403, Outgoing label: 262147
Negotiated PW status TLV: No
Local interface: lsi.1048581, Status: Up, Encapsulation: VLAN
Description: Intf - vpls VPN2 neighbor 150.1.1.7 vpls-id 3220
Flow Label Transmit: No, Flow Label Receive: No

lab@VMX-R6> show vpls connections | find Instance:

Instance: VPN2
BGP-VPLS State
Local site: CE2-2 (2)

connection-site Type St Time last up # Up trans

2 rmt RN
5 rmt Up Feb 7 15:44:05 2017 1
Remote PE: 150.1.1.7, Negotiated control-word: No
Incoming label: 262147, Outgoing label: 262402
Local interface: lsi.1048578, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPN2 local site 2 remote site 5
Flow Label Transmit: No, Flow Label Receive: No
LDP-VPLS State
Mesh-group connections: LDP-PE
Neighbor Type St Time last up # Up trans
150.1.1.2(vpls-id 3220) rmt Up Feb 7 15:43:48 2017 1
Remote PE: 150.1.1.2, Negotiated control-word: No
Incoming label: 262402, Outgoing label: 262402
Negotiated PW status TLV: No
Local interface: lsi.1048577, Status: Up, Encapsulation: VLAN
Description: Intf - vpls VPN2 neighbor 150.1.1.2 vpls-id 3220
Flow Label Transmit: No, Flow Label Receive: No

lab@VMX-R7> show vpls connections | find Instance:

Instance: VPN2
BGP-VPLS State
Local site: CE2-5 (5)
connection-site Type St Time last up # Up trans
2 rmt Up Feb 7 15:44:09 2017 1
Remote PE: 150.1.1.6, Negotiated control-word: No
Incoming label: 262402, Outgoing label: 262147
Local interface: lsi.1048578, Status: Up, Encapsulation: VPLS
Description: Intf - vpls VPN2 local site 5 remote site 2
Flow Label Transmit: No, Flow Label Receive: No
LDP-VPLS State
Mesh-group connections: LDP-PE
Neighbor Type St Time last up # Up trans
150.1.1.2(vpls-id 3220) rmt Up Feb 7 15:43:53 2017 1
Remote PE: 150.1.1.2, Negotiated control-word: No
Incoming label: 262147, Outgoing label: 262403
Negotiated PW status TLV: No
Local interface: lsi.1048577, Status: Up, Encapsulation: VLAN
Description: Intf - vpls VPN2 neighbor 150.1.1.2 vpls-id 3220
Flow Label Transmit: No, Flow Label Receive: No

lab@VMX-R8> show vpls connections | find Instance:

Instance: VPN2
BGP-VPLS State
Local site: CE2-2 (2)
connection-site Type St Time last up # Up trans
2 rmt LN
5 rmt LN

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

LDP-VPLS State
Mesh-group connections: LDP-PE
Neighbor Type St Time last up # Up trans
150.1.1.2(vpls-id 3220) rmt OL

Once control-plane state is up and running, we should verify data-plane reachability between CE sites
and layer 2 learning on PE routers as well:
lab@VMX-VR> ping rapid routing-instance CE2-2 source 172.30.40.2 172.30.40.4
PING 172.30.40.4 (172.30.40.4): 56 data bytes
!!!!!
--- 172.30.40.4 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 14.877/14.946/15.021/0.053 ms

lab@VMX-VR> ping rapid routing-instance CE2-2 source 172.30.40.2 172.30.40.5

PING 172.30.40.5 (172.30.40.5): 56 data bytes
!!!!!
--- 172.30.40.5 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 14.841/14.951/15.009/0.062 ms

lab@VMX-VR> ping rapid routing-instance CE2-4 source 172.30.40.4 172.30.40.5

PING 172.30.40.5 (172.30.40.5): 56 data bytes
!!!!!

--- 172.30.40.5 ping statistics ---

5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 12.473/14.936/17.311/1.531 ms

lab@VMX-R2> show route forwarding-table family vpls

Routing table: VPN2.vpls
VPLS:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 dscd 516 1
00:05:86:71:39:06/48 user 0 indr 1048589 6
ulst 1048598 2
150.1.24.4 Push 262145, Push 299920(top) 756
1 ge-0/0/6.0
150.1.12.1 Push 262145, Push 299920, Push
300064(top) 766 1 ge-0/0/2.0
00:05:86:71:39:08/48 user 0 indr 1048589 6
ulst 1048598 2
150.1.24.4 Push 262145, Push 299920(top) 756
1 ge-0/0/6.0
150.1.12.1 Push 262145, Push 299920, Push
300064(top) 766 1 ge-0/0/2.0
00:05:86:71:39:09/48 user 0 ucst 677 5 ge-0/0/3.104
lsi.1048576 intf 0 indr 1048574 4
ulst 1048599 2
150.1.24.4 Push 262145, Push 299808(top) 723
1 ge-0/0/6.0
150.1.12.1 Push 262145, Push 299808, Push
300064(top) 767 1 ge-0/0/2.0
lsi.1048577 intf 0 indr 1048589 6
ulst 1048598 2
150.1.24.4 Push 262145, Push 299920(top) 756
1 ge-0/0/6.0
150.1.12.1 Push 262145, Push 299920, Push
300064(top) 766 1 ge-0/0/2.0
0x30003/51 user 0 comp 731 2
ge-0/0/3.104 intf 0 ucst 677 5 ge-0/0/3.104
0x30002/51 user 0 comp 705 2
0x30001/51 user 0 comp 702 2

lab@VMX-R2> show vpls mac-table | find VPN2

Routing instance : VPN2
Bridging domain : __VPN2__, VLAN : NA
MAC MAC Logical NH RTR
address flags interface Index ID
56:68:28:3f:66:4c D lsi.1048585
56:68:28:3f:66:56 D ge-0/0/2.104
56:68:28:3f:66:57 D lsi.1048585

lab@VMX-R2> show vpls statistics

VPLS statistics:

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

Instance: VPN2
Local interface: lsi.1048576, Index: 341
Remote PE: 150.1.1.7
Broadcast packets: 0
Broadcast bytes : 0
Multicast packets: 0
Multicast bytes : 0
Flooded packets : 2
Flooded bytes : 204
Unicast packets : 6
Unicast bytes : 612
Current MAC count: 1
Local interface: lsi.1048577, Index: 342
Remote PE: 150.1.1.6
Broadcast packets: 0
Broadcast bytes : 0
Multicast packets: 0
Multicast bytes : 0
Flooded packets : 1
Flooded bytes : 102
Unicast packets : 7
Unicast bytes : 714
Current MAC count: 1
Local interface: ge-0/0/2.104, Index: 351
Broadcast packets: 1
Broadcast bytes : 60

Multicast packets: 0
Multicast bytes : 0
Flooded packets : 2
Flooded bytes : 204
Unicast packets : 36
Unicast bytes : 3630
Current MAC count: 1 (Limit 1024)

Task 6 presents a BGP-based L2VPN (Kompella) which is a point-to-point virtual layer 2 connection
between attachment circuits of two remote PEs,it uses BGP NLRI family l2vpn under protocols bgp
group stanza (like VPLS) to signal VPN label information (VC-ID), this method allows for auto-discovery as
well, combining with route reflector, inter-AS solutions and hence it is scalable. From configuration
perspectives, the PE-CE link must have encapsulation type of either ethernet-ccc or vlan-ccc. And we
use a routing-instance with statements instance-type l2vpn and protocols l2vpn specifying site’s name
and ID which is unique per site. Once configuration is done, the BGP-based L2VPN state should come up:
lab@VMX-R1> show l2vpn connections | find Instance:

Instance: VPN5
Local site: CE5-1 (1)
connection-site Type St Time last up # Up trans
2 rmt Up Feb 7 17:29:53 2017 1
Remote PE: 150.1.1.5, Negotiated control-word: Yes (Null)
Incoming label: 800001, Outgoing label: 800000
Local interface: ge-0/0/2.143, Status: Up, Encapsulation: VLAN
Flow Label Transmit: No, Flow Label Receive: No

lab@VMX-R5> show l2vpn connections | find Instance:

Instance: VPN5
Local site: CE5-2 (2)
connection-site Type St Time last up # Up trans
1 rmt Up Feb 7 17:29:54 2017 1
Remote PE: 150.1.1.1, Negotiated control-word: Yes (Null)
Incoming label: 800000, Outgoing label: 800001
Local interface: ge-0/0/3.143, Status: Up, Encapsulation: VLAN
Flow Label Transmit: No, Flow Label Receive: No

Now the interesting part of this task is on the data-plane. The task requires that CE5-1 and CE5-2 should
be able to send frames with payload of up to 1401 bytes across the point-to-point BGP-signalled L2VPN
without fragmentation. We know that right now both CE5-1 and CE5-2 are connecting to PE routers R1
and R5 via IEEE 802.1Q encapsulation with default maximum MTU of 1500 bytes including headers:

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

Ethernet IEEE 802.3: 14 bytes, IEEE 802.1Q: 4 bytes, IPv4: 20 bytes. Thus the maximum payload by
default is only: 1500 – 14 – 4 – 20 = 1462 bytes. We would need to tune the MTU value lower to govern
payload size of 1401 bytes. With JUNOS’s ICMP ping test implementation, the size of the packet actually
does not take into account 8 bytes ICMP header. Therefore the value that we need on PE-CE links (ge-
0/0/3.143 on R1 and ge-0/0/3.143 on R5) will be 1447 bytes that is derived from:

• Ethernet IEEE 802.3: 14 bytes

• IEEE 802.1Q: 4 bytes
• IPv4: 20 bytes
• ICMP: 8 bytes
• Payload: 1401 bytes
lab@VMX-VR> ping rapid routing-instance CE5-1 source 172.30.160.51 172.30.160.52 size
1401 do-not-fragment
PING 172.30.160.52 (172.30.160.52): 1401 data bytes
!!!!!
--- 172.30.160.52 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 138.005/152.876/203.459/25.337 ms

lab@VMX-VR> ping rapid routing-instance CE5-1 source 172.30.160.51 172.30.160.52 size

1402 do-not-fragment
PING 172.30.160.52 (172.30.160.52): 1402 data bytes
.....
--- 172.30.160.52 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

We have two options when adjusting MTU value for the PE-CE links: 1) change MTU value of the physical
interface ge-0/0/3, or 2) change MTU value of just the particular L2VPN PE-CE links, i.e. ge-0/0/3.143. In
this task, option 2 is the right method because:

• We need to ensure that the sub-interface ge-0/0/3.145’s MTU value stays the same, otherwise
the OSPF neighbourship between CE3-1 and R1 will likely go into Exstart state due to MTU
mismatch because the MTU of sub-interfaces are auto-derived from the MTU of the physical
interface (changing MTU of physical interface by default will change MTU of its sub-interfaces).
This is the reason why we have to hard-code the MTU for sub-interface ge-0/0/3.143 with
statement family ccc mtu at the interface ge-0/0/3.143 level.
• If we change MTU value of physical interface down to 1447 bytes, we cannot enable the sub-
interface ge-0/0/3.145 with MTU of 1500 bytes with the statement family inet mtu at the
interface ge-0/0/3.145 level. It is because a sub-interface cannot have a larger MTU value
compared to the physical interface it belongs to. lab@VMX-R1> show interfaces ge-0/0/3 |
match "Physical|Logical|MTU:"
Physical interface: ge-0/0/3, Enabled, Physical link is Up
Link-level type: Flexible-Ethernet, MTU: 1518, MRU: 1526, Speed: 1000mbps, BPDU Error:
None,
Logical interface ge-0/0/3.143 (Index 350) (SNMP ifIndex 523)
Protocol ccc, MTU: 1447
Logical interface ge-0/0/3.145 (Index 349) (SNMP ifIndex 528)
Protocol inet, MTU: 1500
Protocol multiservice, MTU: Unlimited
Logical interface ge-0/0/3.32767 (Index 358) (SNMP ifIndex 526)
Protocol multiservice, MTU: Unlimited

lab@VMX-R1> show ospf neighbor instance VPN3

Address Interface State ID Pri Dead
172.16.145.2 ge-0/0/3.145 Full 172.30.70.1 128 32

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

For the bonus/homework question, the solution is also based on the same logic, requiring adjustment
for MTU value of interfaces. However there are several differences below. If your lab environment
supports jumbo Ethernet frames, we encourage you to test this out.

• Firstly we would need to tune the MTU value lower to govern payload size of 1501 bytes. With
JUNOS’s ICMP ping test implementation, the size of the packet actually does not take into
account 8 bytes ICMP header. Therefore the value that we need on PE-CE links (ge-0/0/3.143 on
R1 and ge-0/0/3.143 on R5) will be 1547 bytes that is derived from:
o Ethernet IEEE 802.3: 14 bytes
o IEEE 802.1Q: 4 bytes
o IPv4: 20 bytes
o ICMP: 8 bytes
o Payload: 1501 bytes
• Previously, we know that two options: 1) change MTU value of the physical interface ge-0/0/3,
or 2) change MTU value of just the particular L2VPN PE-CE links, i.e. ge-0/0/3.143. Now only

option 1 will work because we cannot adjust MTU value of only the particular L2VPN PE-CE links,
i.e. ge-0/0/3.143 to be higher than 1500 which is the physical interface’s value.
o When adjusting physical interface to 1547 bytes, one thing to watch out for is that on R1
we need to ensure that the sub-interface ge-0/0/3.145’s MTU value is still the same,
otherwise the OSPF neighbourship between CE3-1 and R1 will likely go into Exstart state
due to MTU mismatch. This is because the MTU of sub-interfaces are auto-derived from
the MTU of the physical interface, i.e. changing MTU of physical interface by default will
change MTU of its sub-interfaces. Thus we must hard-code the MTU for sub-interface
ge-0/0/3.145 with statement family inet mtu at the interface ge-0/0/3.145 level.
• In addition to adjusting MTU value for the PE-CE links, now we also need to do it in another
places: the MPLS networks. Because MPLS links in this Practice Lab are also based on Ethernet
medium which by default has got default MTU size of 1500 bytes. For this point, completion of
topic 3, task 3 addresses it.

Task 7 examines some advanced features that are used to improve scalability and optimise routers’
resources in an MPLS networks.

Let’s start with the BGP AFI family route-target configured under protocols bgp group stanza, this
feature provides scalability improvement for large L3VPN networks, that the PE routers send a list with
only BGP route-target values that they're interested in based on their locally configured VRFs, hence
their BGP peers will only reflect the VPN routes with the required BGP route-targets to the PEs. This way
PE routers will not receive VPN routes tagged with route-target values that they do not have locally. For
example, R8 has got local connection to VPN3 and VPN2 only, after the feature is enabled it should not
receive VPN routes from VPN1.
lab@VMX-R6> show route advertising-protocol bgp 150.1.1.8 community target:57920:3330
table bgp.l3vpn.0

bgp.l3vpn.0: 135 destinations, 213 routes (135 active, 0 holddown, 11 hidden)

Prefix Nexthop MED Lclpref AS path
150.1.1.1:15:172.16.109.0/30
* 150.1.1.1 2 100 (64001) I
150.1.1.1:15:172.16.145.0/30
* 150.1.1.1 100 (64001) I

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

150.1.1.1:15:172.30.70.0/24
* 150.1.1.1 0 100 (64001) I
150.1.1.1:15:172.30.71.0/24
* 150.1.1.1 0 100 (64001) I
150.1.1.1:15:172.30.72.0/24
* 150.1.1.1 0 100 (64001) I
150.1.1.1:15:172.30.73.0/24
* 150.1.1.1 0 100 (64001) I
150.1.1.1:15:172.30.74.0/24
* 150.1.1.1 0 100 (64001) I
<snip-for-brevity>

lab@VMX-R6> show route advertising-protocol bgp 150.1.1.8 community target:57920:3220

table bgp.l2vpn.0

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

Prefix Nexthop MED Lclpref AS path
150.1.1.6:4:2:1/96
* Self 65535 I

lab@VMX-R6> show route advertising-protocol bgp 150.1.1.8 community target:57920:3310

table bgp.l3vpn.0

bgp.l3vpn.0: 138 destinations, 368 routes (138 active, 0 holddown, 22 hidden)

lab@VMX-R6>

In order to achieve this, BGP routers with this AFI configured will create a new routing table called
bgp.rtarget.0 containing all BGP route target values within the L3VPN domain. As can be seen below, R8
only signals that it needs VPN routes with only two BGP route-target community values
target:57920:3220 and target:57920:3330.
lab@VMX-R8> show route table bgp.rtarget.0 protocol rtarget

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

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

64002:57920:3220/96
*[RTarget/5] 00:01:31
Type Default
Local
64002:57920:3330/96
*[RTarget/5] 00:01:31
Type Default
Local

For the border routers R3, R4, R5, R6 of sub-AS 64001 and sub-AS 64002, it is imperative to include
statement advertise-default at the family route-target stanza because they provide basic connectivity
between the two POPs of the whole AS 1.57920. If you do not include this statement, L3VPN services of
VPN1 and VPN3 are likely disrupted.

The next optimisation feature is L3VPN Route Localisation. Without this feature (by default), a copy of
all of the forwarding tables on the routers (inet.0, inet6.0, mpls.0, and all of the configured VRF tables)
will be replicated at all PFE linecards even if some of them may not have any VRF-enabled interface.
Since memory for forwarding table memory size is finite and can become exhausted as more and more
Internet and/or VPN routes increase. To help optimise memory scale on JUNOS routers, we can
configure the localize statement under the routing-instance level. This would cause the individual VRF
tables to only get stored on the PFE that houses the VRF’s interface and stop other PFE linecards from
storing unnecessary VRF routes.
lab@VMX-R1> show route table mpls.0
<snip-for-brevity>
299792 *[VPN/170] 00:27:18
to localized table VPN3.inet.0, Pop
299808 *[VPN/170] 00:27:18

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

to localized table VPN1-HUB.inet.0, Pop
<snip-for-brevity>

lab@VMX-R2> show route table mpls.0

<snip-for-brevity>
299808 *[VPN/170] 00:27:18
to localized table VPN3.inet.0, Pop
299824 *[VPN/170] 00:27:18
to localized table VPN1-SPOKE.inet.0, Pop
<snip-for-brevity>

The next feature is more like a regulation for VRF tables. We should limit the number of routes that CE
routers can send to PE routers to protect the latter’s resources from mistaken actions such as CE routers
were wrongly configured with leakage of Internet routing tables (~500,000 routes) into PE routers. We
can achieve this by configuring statement maximum-prefixes at routing-options stanza.
lab@VMX-R1> show route summary
<snip-for-brevity>
VPN1-HUB.inet.0: 35 destinations, 35 routes (35 active, 0 holddown, 0 hidden)
Limit/Threshold: 5000/4000 destinations
Direct: 1 routes, 1 active
Local: 1 routes, 1 active
BGP: 33 routes, 33 active

VPN1-SPOKE.inet.0: 35 destinations, 56 routes (35 active, 0 holddown, 0 hidden)

Limit/Threshold: 5000/4000 destinations
Direct: 1 routes, 1 active
Local: 1 routes, 1 active
OSPF: 10 routes, 10 active
BGP: 44 routes, 23 active

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

Direct: 1 routes, 1 active
Local: 1 routes, 1 active
OSPF: 12 routes, 12 active
BGP: 52 routes, 52 active
<snip-for-brevity>

The last feature is to protect VPLS domain from being flooded with BUM traffic (broadcast, unknown
unicast, multicast). We apply a VPLS filter by using statement forwarding-options family vpls flood
input at the routing-instance stanza. This filter matches BUM traffic with knob traffic-type and then
refers to a policer that limits the rate of matched traffic.
lab@VMX-R2> show firewall filter detail VPLS-BUM-FILTER

Filter: VPLS-BUM-FILTER
Policers:
Name Bytes Packets
VPLS-BUM-POLICER-10M-1 0 0

Topic 6: Multicast
Total Points: 9

Task 1 (4 points). Implement multicast routing in the Service Provider Network with the following
characteristics:

• Configure BSR to disseminate rendezvous point (RP) information with R4 and R6 being BSR/RP
candidates for IPv4 multicast with priorities in that order respectively, using loopback interfaces
as update-sources.
• RP information should not leak across AS boundaries with transit or peering.
• R4, R6 are Anycast RPs with address 150.1.1.250. Ensure the redundancy of the RPs through
MSDP.
Strictly control multicast traffic over the core network of the Service Provider such that there

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

•
should be only internal group 239.0.0.0/24 that can deliver traffic. You are allowed to add any
multicast group that is necessary for the basic multicast function of the Service Provider
Network.
/* PIM, Auto-RP, MSDP for SP Core */

R1,R2,R7,R8
!
edit protocols pim
set interface lo0.0
set interface ge-0/0/2 mode sparse version 2
set interface ge-0/0/6 mode sparse version 2
set rp bootstrap family inet import BSR-SCOPING
set rp bootstrap family inet export BSR-SCOPING
exit
edit policy-options policy-statement BSR-SCOPING
set term 1 from interface ge-0/0/2.0
set term 1 from interface ge-0/0/6.0
set term 1 then accept
set term DENY-ALL then reject
exit

R3
!

edit protocols pim

set interface lo0.0
set interface ge-0/0/2 mode sparse version 2
set interface ge-0/0/6 mode sparse version 2
set interface ge-0/0/7 mode sparse version 2
set rp bootstrap family inet import BSR-SCOPING
set rp bootstrap family inet export BSR-SCOPING
exit
edit policy-options policy-statement BSR-SCOPING
set term 1 from interface ge-0/0/2.0
set term 1 from interface ge-0/0/6.0
set term 1 from interface ge-0/0/7.0
set term 1 then accept
set term DENY-ALL then reject
exit

R4
!
set interface lo0.0 family inet address 150.1.1.250/32
edit protocols pim
set interface lo0.0
set interface ge-0/0/2 mode sparse version 2
set interface ge-0/0/6 mode sparse version 2
set interface ge-0/0/7 mode sparse version 2
set interface ge-0/0/8 mode sparse version 2
set rp local address 150.1.1.250
set rp bootstrap family inet priority 100
set rp bootstrap family inet import BSR-SCOPING
set rp bootstrap family inet export BSR-SCOPING
exit
edit protocols msdp group ANYCAST-RP
set mode mesh-group
set local-address 150.1.1.4
set peer 150.1.1.6
exit
edit policy-options policy-statement BSR-SCOPING
set term 1 from interface ge-0/0/2.0
set term 1 from interface ge-0/0/6.0
set term 1 from interface ge-0/0/7.0
set term 1 from interface ge-0/0/8.0
set term 1 then accept
set term DENY-ALL then reject
exit

R5
!
edit protocols pim
set interface lo0.0
set interface ge-0/0/2 mode sparse version 2
set interface ge-0/0/6 mode sparse version 2

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

set interface ge-0/0/7 mode sparse version 2
set interface ge-0/0/8 mode sparse version 2
set rp bootstrap family inet import BSR-SCOPING
set rp bootstrap family inet export BSR-SCOPING
exit
edit policy-options policy-statement BSR-SCOPING
set term 1 from interface ge-0/0/2.0
set term 1 from interface ge-0/0/6.0
set term 1 from interface ge-0/0/7.0
set term 1 from interface ge-0/0/8.0
set term 1 then accept
set term DENY-ALL then reject
exit

R6
!
set interface lo0.0 family inet address 150.1.1.250/32
edit protocols pim
set interface lo0.0
set interface ge-0/0/2 mode sparse version 2
set interface ge-0/0/6 mode sparse version 2
set interface ge-0/0/7 mode sparse version 2
set rp local family inet address 150.1.1.250
set rp bootstrap family inet priority 50
set rp bootstrap family inet import BSR-SCOPING
set rp bootstrap family inet export BSR-SCOPING
exit

edit protocols msdp group ANYCAST-RP

set mode mesh-group
set local-address 150.1.1.6
set peer 150.1.1.4
exit
edit policy-options policy-statement BSR-SCOPING
set term 1 from interface ge-0/0/2.0
set term 1 from interface ge-0/0/6.0
set term 1 from interface ge-0/0/7.0
set term 1 then accept
set term DENY-ALL then reject
exit

/* multicast scoping */

R1,R2,R3,R4,R5,R6,R7,R8
!
edit policy-options policy-statement MCAST-SP-CORE-SCOPING
set term ALLOWED-GROUPS from interface [ge-0/0/2.0 ge-0/0/6.0 ge-0/0/7.0 ge-0/0/8.0]
set term ALLOWED-GROUPS from route-filter 224.0.0.13/32 exact
set term ALLOWED-GROUPS from route-filter 239.0.0.0/24 exact
set term ALLOWED-GROUPS then accept
set term DENIED-GROUPS from interface [ge-0/0/2.0 ge-0/0/6.0 ge-0/0/7.0 ge-0/0/8.0]
set term DENIED-GROUPS from route-filter 224.0.0.0/8 orlonger
set term DENIED-GROUPS then reject
exit
set routing-options multicast scope-policy MCAST-SP-CORE-SCOPING

Task 2 (5 points). Implement Draft-Rosen MVPN for customer VPN3 with the following characteristics:

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

set chassis fpc 0 pic 0 tunnel-services bandwidth 10g
set interface lo0.1 family inet address 150.1.1.11/32
edit routing-instances VPN3
set interface lo0.1
set protocols ospf area 0.0.0.0 interface lo0.1 passive
set protocols pim interface all mode sparse version 2
set protocols pim rp static address 172.30.70.1
set protocols pim vpn-group-address 239.0.0.3
set protocols pim mdt group-range 239.1.1.0/24
set protocols pim mdt threshold group 239.1.1.31 source 0.0.0.0/0 rate 50000
set protocols pim mdt threshold group 239.1.1.32 source 0.0.0.0/0 rate 50000
set protocols pim mdt tunnel-limit 10
exit

R2
!
set chassis fpc 0 pic 0 tunnel-services bandwidth 10g
set interface lo0.1 family inet address 150.1.1.22/32
edit routing-instances VPN3
set interface lo0.1
set protocols ospf area 0.0.0.0 interface lo0.1 passive
set protocols pim interface all mode sparse version 2
set protocols pim rp static address 172.30.70.1
set protocols pim vpn-group-address 239.0.0.3
set protocols pim mdt group-range 239.1.1.0/24
exit

R4,R6
!
set chassis fpc 0 pic 0 tunnel-services bandwidth 10g

R8
!
set chassis fpc 0 pic 0 tunnel-services bandwidth 10g
set interface lo0.1 family inet address 150.1.1.88/32
edit routing-instances VPN3
set interface lo0.1
set protocols ospf area 0.0.0.1 interface lo0.1 passive
set protocols pim interface all mode sparse version 2
set protocols pim rp static address 172.30.70.1
set protocols pim vpn-group-address 239.0.0.3
set protocols pim mdt group-range 239.1.1.0/24
exit

Verification
Task 1. This task presents the intial components of a traditional way of delivering Multicast for MPLS
L3VPNs called Draft-Rosen, which requires the following:

• A multicast routing protocol inside Service Provider Network to facilitate customer multicast
routing. In this case, the protocol is PIM running in sparse mode which involves multicast roles
of sources, RP and receivers.
o Multicast routers running PIM establish neighbourship with each via PIM HELLO
messages destined to multicast address 224.0.0.2 (PIMv1) and 224.0.0.13 (PIMv2).
Compared to PIMv1, PIMv2 has a special message called State-Refresh which is sent
every 60sec to instruct the upstream router to ‘keep pruning’ for PIM-DM or ‘keep
forwarding’ for PIM-SM respectively. PIMv2 in SM mode has another special message
called Graft which is sent whenever the downstream router needs multicast traffic from
the upstream router. PIM Sparse Mode (PIM-SM) nominates Rendezvous Points (RPs) in
between multicast source(s) and destinations.
o RP is where source(s) and destinations meet up and get to know each other in order to
build a multicast forwarding tree from a particular source to all destinations of it for
multicast forwarding. RP can be statically configured on all multicast routers of the
network or can be disseminated by protocols BSR (Bootstrap Router), Auto-RP or by
using a slightly different method called Anycast-RP. While BSR/Auto-RP provides

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

flexibility to managing/controlling RPs within the network, Static RP is the simplest
method in terms of configuration. However, the disadvantage of Static RP is that if
configured RP fails, a manual reconfiguration will need to be carried out on every router
that uses Static RP.
• An RP dissemination protocol called Bootstrap Router protocol (BSR) defined in RFC 5059. BSR
propagates bootstrap messages hop-by-hop (TTL=1), destined to multicast address 224.0.0.13,
subject to be RPF checked. BSR is standardised but only works with PIM version 2. BSR defines
two groups within the multicast domain: Candidate-BSR routers and Candidate-RP routers:
o One main BSR router is elected from Candidate-BSR routers (highest Priority or highest
IP), collecting information about Candidate-RP routers and producing RP-Group
mapping sets. If the main BSR router fails to maintain its functionality, second best
Candidate-BSR router will take over.
o Candidate-RP routers send unicast Candidate-RP-advertisements to BSR Router after
they known about this router via bootstrap message, this message includes Priority, IP,
Groups that they are assigned/associated to.

o Main BSR router does not pick the best Candidate-RP, instead it sends them all in RP-
Group mapping sets and let multicast routers decide individually. However, the
selection is typically based on the lowest Priority, highest hashing result (ANDing
{Group,Hash-Length,C-RP-IP}), and highest IP. In fact, BSR not only allows for RP failover
but also automatic load sharing between Candidate-RPs for the same group range. For
each multicast address, there is still only one RP exists, but load sharing is possible on a
per-group basis, say this RP serves for a set of multicast groups, another RP serves for
another set of multicast groups.

Let’s first check PIM neighbourship and then RP information propagated by BSR protocol. You can see
that in the network we have two RP routers R4 and R6 advertised themselves throughout the domain as
BSR routers, denoted as ‘bootstrap’.

lab@VMX-R1> show pim neighbors | find Instance:

Instance: PIM.master
Interface IP V Mode Option Uptime Neighbor addr
ge-0/0/2.0 4 2 HPLGT 14:59:04 150.1.12.2
ge-0/0/6.0 4 2 HPLGT 14:59:04 150.1.13.3
ge-0/0/2.0 6 2 HPLGT 14:59:03 fe80::205:86ff:fe71:b505
ge-0/0/6.0 6 2 HPLGT 14:59:02 fe80::205:86ff:fe71:9a06

lab@VMX-R4> show pim neighbors | find Instance:

Instance: PIM.master
Interface IP V Mode Option Uptime Neighbor addr
ge-0/0/2.0 4 2 HPLGT 14:59:04 150.1.34.3
ge-0/0/6.0 4 2 HPLGT 14:59:03 150.1.24.2
ge-0/0/7.0 4 2 HPLGT 14:59:08 150.1.46.6
ge-0/0/8.0 4 2 HPLGT 14:59:07 150.1.45.5
ge-0/0/2.0 6 2 HPLGT 14:59:04 fe80::205:86ff:fe71:9a05
ge-0/0/6.0 6 2 HPLGT 14:59:03 fe80::205:86ff:fe71:b506
ge-0/0/7.0 6 2 HPLGT 14:59:06 fe80::205:86ff:fe71:6307
ge-0/0/8.0 6 2 HPLGT 14:59:07 fe80::205:86ff:fe71:3d08

lab@VMX-R6> show pim neighbors | find Instance:

Instance: PIM.master
Interface IP V Mode Option Uptime Neighbor addr
ge-0/0/2.0 4 2 HPLGT 15:04:15 150.1.56.5
ge-0/0/6.0 4 2 HPLGT 15:04:15 150.1.68.8
ge-0/0/7.0 4 2 HPLGT 15:04:13 150.1.46.4
ge-0/0/2.0 6 2 HPLGT 14:54:07 fe80::205:86ff:fe71:3d05
ge-0/0/6.0 6 2 HPLGT 15:04:16 fe80::205:86ff:fe71:f806
ge-0/0/7.0 6 2 HPLGT 15:04:13 fe80::205:86ff:fe71:3307

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

lab@VMX-R8> show pim neighbors | find Instance:
Instance: PIM.master
Interface IP V Mode Option Uptime Neighbor addr
ge-0/0/2.0 4 2 HPLGT 15:04:17 150.1.78.7
ge-0/0/6.0 4 2 HPLGT 15:04:16 150.1.68.6
ge-0/0/2.0 6 2 HPLGT 15:04:16 fe80::205:86ff:fe71:ff05
ge-0/0/6.0 6 2 HPLGT 15:04:16 fe80::205:86ff:fe71:6306

lab@VMX-R1> show pim rps inet

Instance: PIM.master

address-family INET
RP address Type Mode Holdtime Timeout Groups Group prefixes
150.1.1.250 bootstrap sparse 150 97 1 224.0.0.0/4

lab@VMX-R4> show pim rps inet

Instance: PIM.master

address-family INET
RP address Type Mode Holdtime Timeout Groups Group prefixes
150.1.1.250 bootstrap sparse 150 None 1 224.0.0.0/4
150.1.1.250 static sparse 150 None 1 224.0.0.0/4

lab@VMX-R6> show pim rps inet

Instance: PIM.master

address-family INET
RP address Type Mode Holdtime Timeout Groups Group prefixes
150.1.1.250 bootstrap sparse 150 98 1 224.0.0.0/4
150.1.1.250 static sparse 150 None 1 224.0.0.0/4

lab@VMX-R8> show pim rps inet

Instance: PIM.master

address-family INET
RP address Type Mode Holdtime Timeout Groups Group prefixes
150.1.1.250 bootstrap sparse 150 98 0 224.0.0.0/4

The two routers R4 and R6 actually formed a mesh group via MSDP protocol to provide both anycast
and redundancy for RP function of the network and to share information about multicast sources
between each other. Based on routing protocol, the PIM Register messages would be delivered to the
closest router.
lab@VMX-R4> show msdp brief
Peer address Local address State Last up/down Peer-Group SA Count
150.1.1.6 150.1.1.4 Established 00:20:26 ANYCAST-RP 1/1

lab@VMX-R4> show msdp source-active

Global active source limit exceeded: 0
Global active source limit maximum: 25000
Global active source limit threshold: 24000
Global active source limit log-warning: 100
Global active source limit log interval: 0

Group address Source address Peer address Originator Flags

239.0.0.3 150.1.1.1 local 150.1.1.4 Accept
239.0.0.3 150.1.1.2 local 150.1.1.4 Accept
239.0.0.3 150.1.1.8 150.1.1.8 150.1.1.8 Accept

lab@VMX-R1> traceroute 150.1.1.250 source 150.1.1.1

traceroute to 150.1.1.250 (150.1.1.250) from 150.1.1.1, 30 hops max, 40 byte packets
1 150.1.13.3 (150.1.13.3) 4.155 ms 2.853 ms 1.865 ms
2 150.1.1.250 (150.1.1.250) 3.194 ms 5.466 ms 3.458 ms

lab@VMX-R7> traceroute 150.1.1.250 source 150.1.1.7

traceroute to 150.1.1.250 (150.1.1.250) from 150.1.1.7, 30 hops max, 40 byte packets
1 150.1.57.5 (150.1.57.5) 2.752 ms 2.429 ms 150.1.78.8 (150.1.78.8) 3.522 ms
2 150.1.1.250 (150.1.1.250) 5.676 ms 3.379 ms 4.108 ms

You should govern the delivery of multicast stream within the Service Provider Network to avoid any
potential massive traffic flood or even malicious DoS attacks. In this task, there are two such features,

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

first is the use of statement rp bootstrap family inet import/export under protocols pim stanza which
specifies the allowed interfaces for BSR messages to be sent/received. This way the multicast domain is
protected such that illegitimate BSR messages sent from external networks (transit/peering/customer)
will be discarded. The other feature is even more stringent, using statement multicast scope-policy
under routing-options stanza, which specifies which groups can send/receive traffic through core
interface in the network so it affects not just BSR but all multicast delivery in general. This way the
multicast domain is protected such that there mostly would be no unwanted multicast traffic flowing in
the core networks either mistakenly or deliberately.
lab@VMX-R1> show multicast scope
Scope policy: [ MCAST-SP-CORE ]
Instance: master Family: INET
Interface Resolve rejects
lo0.0 0
vt-0/0/0.2097152 0
ge-0/0/2.0 0
ge-0/0/6.0 0
pe-0/0/0.32769 0

Instance: master Family: INET6

Interface Resolve rejects

lo0.0 0
ge-0/0/2.0 0
ge-0/0/6.0 0

Task 2 is the actual implementation of Draft-Rosen Multicast L3VPNs. We would need to activate the
Tunnel Services on the PIC of the FPC linecards that hold the PE-CE ports, using statement tunnel-
services bandwidth under chassis fpc 0 pic 0 stanza. PIM-SM implementation on JUNOS requires
Tunnel Services (TS) on the PIC card of the multicast routers which act as RPs or FHRs (those routers
with directly attached multicast sources). One pe interface is automatically created on the FHR (R1 in
this case) in order to encapsulate multicast packets, destined to the RP. One pd interface is also
automatically created on the RP (R4 or R6) in order to receive PIM_SOURCE_REGISTER messages and de-
encapsulates them in the hardware. The pe and pd interfaces appear only if a Tunnel Services PIC is
present.
lab@VMX-R1> show interfaces terse | match "(pd|pe)-"
pd-0/0/0 up up
pe-0/0/0 up up
pe-0/0/0.32769 up up inet
pe-0/0/0.32770 up up inet

lab@VMX-R4> show interfaces terse | match "(pd|pe)-"

pd-0/0/0 up up
pd-0/0/0.32769 up up inet
pe-0/0/0 up up

lab@VMX-R6> show interfaces terse | match "(pd|pe)-"

pd-0/0/0 up up
pd-0/0/0.32769 up up inet
pe-0/0/0 up up

Since we enable PIM inside routing-instances, you can see that there are two mt- interfaces which are
needed for PIM encapsulation/de-encapsulation of multicast traffic sent/received with CE routers into
mGRE tunnels spanning across the Service Provider Network towards involved PE routers. In order for
this to happen, we would need to create an additional loopback interfaces for these instances.
lab@VMX-R1> show pim interfaces instance VPN3 | find Name
Name Stat Mode IP V State NbrCnt JoinCnt(sg/*g) DR address
ge-0/0/3.145 Up S 4 2 NotDR,NotCap 1 0/2 172.16.145.2
lo0.1 Up S 4 2 DR,NotCap 0 0/0 150.1.1.11
lsi.2 Up SD 4 2 P2P,NotCap 0 0/0

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

mt-0/0/0.1081344 Up SD 4 2 P2P,NotCap 0 0/0
mt-0/0/0.32768 Up SD 4 2 P2P,NotCap 2 0/0
pe-0/0/0.32769 Up S 4 2 P2P,NotCap 0 0/0
lsi.2 Up SD 6 2 P2P,NotCap 0 0/0

lab@VMX-R1> show pim mdt instance VPN3

Instance: PIM.VPN3
Tunnel direction: Outgoing
Tunnel mode: None
Default group address: 239.0.0.3
Default source address: 0.0.0.0
Default tunnel interface: mt-0/0/0.32768
Default tunnel source: 0.0.0.0

Instance: PIM.VPN3
Tunnel direction: Incoming
Tunnel mode: None
Default group address: 239.0.0.3
Default source address: 0.0.0.0
Default tunnel interface: mt-0/0/0.1081344
Default tunnel source: 0.0.0.0

All involved PE routers within Draft-Rosen MVPN network, which attach either to the multicast sources
or receivers will join a shared tree associated with a multicast group dedicated for customer VPN3,
configured by statement protocols pim vpn-group-address under routing-instance stanza.

lab@VMX-R6> show pim join inet

Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

Group: 239.0.0.3
Source: *
RP: 150.1.1.250
Flags: sparse,rptree,wildcard
Upstream interface: Local

Group: 239.0.0.3
Source: 150.1.1.1
Flags: sparse,spt
Upstream interface: ge-0/0/2.0

Group: 239.0.0.3
Source: 150.1.1.2
Flags: sparse,spt
Upstream interface: ge-0/0/7.0

Group: 239.0.0.3
Source: 150.1.1.8
Flags: sparse,spt
Upstream interface: ge-0/0/6.0

Before moving to the next verification steps, let’s generate some multicast traffic stream from the CE3-1
using command below.
VR
!
ping routing-instance CE3-1 ttl 64 bypass-routing interface ge-0/0/0.145 239.1.1.31
ping routing-instance CE3-1 ttl 64 bypass-routing interface ge-0/0/0.145 239.1.1.32

Below is state on PE routers attached to multicast sources that receive traffic sent by multicast sources:
lab@VMX-R1> show pim join instance VPN3 extensive inet
Instance: PIM.VPN3 Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

Group: 239.1.1.31
Source: *
RP: 172.30.70.1
Flags: sparse,rptree,wildcard
Upstream interface: ge-0/0/3.145
Upstream neighbor: 172.16.145.2
Upstream state: Join to RP
Uptime: 00:12:12

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

Downstream neighbors:
Interface: mt-0/0/0.32768
150.1.1.88 State: Join Flags: SRW Timeout: 203
Uptime: 00:02:31 Time since last Join: 00:00:07
150.1.1.22 State: Join Flags: SRW Timeout: 171
Uptime: 00:12:12 Time since last Join: 00:00:38
Number of downstream interfaces: 1

Group: 239.1.1.31
Source: 172.16.145.2
Flags: sparse,spt
Upstream interface: ge-0/0/3.145
Upstream neighbor: Direct
Upstream state: Local Source, Prune to RP
Keepalive timeout: 304
Uptime: 00:12:07
Downstream neighbors:
Number of downstream interfaces: 0

Group: 239.1.1.32
Source: *
RP: 172.30.70.1
Flags: sparse,rptree,wildcard
Upstream interface: ge-0/0/3.145
Upstream neighbor: 172.16.145.2
Upstream state: Join to RP
Uptime: 00:12:12

PE routers attached to multicast receivers that receive either PIM JOIN or IGMP messages will in turn
join to the RP designated at CE3-1 through mGRE tunnels.
lab@VMX-R2> show pim join instance VPN3 extensive inet
Instance: PIM.VPN3 Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

Group: 239.1.1.31
Source: *
RP: 172.30.70.1
Flags: sparse,rptree,wildcard
Upstream interface: mt-0/0/0.32768
Upstream neighbor: 150.1.1.11
Upstream state: Join to RP
Uptime: 00:55:09
Downstream neighbors:
Interface: ge-0/0/4.144
172.16.144.2 State: Join Flags: SRW Timeout: 200
Uptime: 00:55:09 Time since last Join: 00:00:09
Number of downstream interfaces: 1

Group: 239.1.1.31
Source: 172.16.145.2
Flags: sparse,spt
Upstream interface: mt-0/0/0.32768
Upstream neighbor: 150.1.1.11
Upstream state: Join to Source, No Prune to RP
Keepalive timeout: 357
Uptime: 00:03:02
Downstream neighbors:
Interface: ge-0/0/4.144
172.16.144.2 State: Join Flags: S Timeout: 200
Uptime: 00:03:02 Time since last Join: 00:00:09
Number of downstream interfaces: 1

Group: 239.1.1.32
Source: *
RP: 172.30.70.1
Flags: sparse,rptree,wildcard
Upstream interface: mt-0/0/0.32768

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

Upstream neighbor: 150.1.1.11
Upstream state: Join to RP
Uptime: 00:55:09
Downstream neighbors:
Interface: ge-0/0/4.144
172.16.144.2 State: Join Flags: SRW Timeout: 200
Uptime: 00:55:09 Time since last Join: 00:00:09
Number of downstream interfaces: 1

Group: 239.1.1.32
Source: 172.16.145.2
Flags: sparse,spt
Upstream interface: mt-0/0/0.32768
Upstream neighbor: 150.1.1.11
Upstream state: Join to Source, No Prune to RP
Keepalive timeout: 357
Uptime: 00:03:02
Downstream neighbors:
Interface: ge-0/0/4.144
172.16.144.2 State: Join Flags: S Timeout: 200
Uptime: 00:03:02 Time since last Join: 00:00:09
Number of downstream interfaces: 1

lab@VMX-R8> show multicast route inet instance VPN3

Instance: VPN3 Family: INET

Group: 239.1.1.31

Source: 172.16.145.2/32
Upstream interface: mt-0/0/0.1081344
Downstream interface list:
ge-0/0/4.108

Group: 239.1.1.32
Source: 172.16.145.2/32
Upstream interface: mt-0/0/0.1081344
Downstream interface list:
ge-0/0/4.108

lab@VMX-R1> show multicast usage

Group Sources Packets Bytes
239.0.0.3 3 677 58888

Prefix /len Groups Packets Bytes

150.1.1.8 /32 1 330 31256
150.1.1.2 /32 1 307 27524
150.1.1.1 /32 1 40 108

lab@VMX-R1> show multicast usage instance VPN3

Group Sources Packets Bytes
239.1.1.31 1 1795 150780

Prefix /len Groups Packets Bytes

172.16.145.2 /32 1 1795 150780

End of Practice Lab 5 Solutions!

JNCIE-SP Full-Scale Labs, Volume 1 : Practice Lab 5 Solutions

Tutor Finder Mobile Application
No ratings yet
Tutor Finder Mobile Application
71 pages
CCIE SP v5 Lab Deploy Demo
No ratings yet
CCIE SP v5 Lab Deploy Demo
30 pages
OSPF Case Studies
0% (1)
OSPF Case Studies
37 pages
Implementing BGP EVPN On IOS-XR
No ratings yet
Implementing BGP EVPN On IOS-XR
16 pages
10.a-R LD
No ratings yet
10.a-R LD
14 pages
JNCIE-SP-12.a_LG_v2_
No ratings yet
JNCIE-SP-12.a_LG_v2_
296 pages
Iz HCIE RS v1.0 - Decrypted - Clean PDF
No ratings yet
Iz HCIE RS v1.0 - Decrypted - Clean PDF
384 pages
JNCIE Req
No ratings yet
JNCIE Req
3 pages
Junos Pyez Developer Guide PDF
No ratings yet
Junos Pyez Developer Guide PDF
314 pages
Website: Vce To PDF Converter: Facebook: Twitter:: Jn0-681.Vceplus - Premium.Exam.65Q
No ratings yet
Website: Vce To PDF Converter: Facebook: Twitter:: Jn0-681.Vceplus - Premium.Exam.65Q
35 pages
BLUE 1 BLUE 2: AS 11000 AS 1000 AS 2000 Vpls Vpls
No ratings yet
BLUE 1 BLUE 2: AS 11000 AS 1000 AS 2000 Vpls Vpls
1 page
CCIE Service Provider v5.1 Exam Topics v4 Edited-Kz
No ratings yet
CCIE Service Provider v5.1 Exam Topics v4 Edited-Kz
4 pages
Cisco - Himawan Nugroho CCIE 8171 - How To Pass CCIE Lab - Insider Tips
100% (1)
Cisco - Himawan Nugroho CCIE 8171 - How To Pass CCIE Lab - Insider Tips
116 pages
JMF 15.a SG
100% (1)
JMF 15.a SG
374 pages
SPRING - Advanced Use Cases: Aditya Kaul - Solution Architect
No ratings yet
SPRING - Advanced Use Cases: Aditya Kaul - Solution Architect
31 pages
Juniper InterAS OptionC
No ratings yet
Juniper InterAS OptionC
12 pages
JN0 660
No ratings yet
JN0 660
230 pages
Juniper Enterprise WAN Design
No ratings yet
Juniper Enterprise WAN Design
762 pages
Rapid Spanning-Tree (RSTP)
No ratings yet
Rapid Spanning-Tree (RSTP)
27 pages
Configuring VXLAN BGP EVPN 1638491341
No ratings yet
Configuring VXLAN BGP EVPN 1638491341
13 pages
JN0 643 Q&A Troytec
No ratings yet
JN0 643 Q&A Troytec
157 pages
3 - Advanced Junos Service Provider1
No ratings yet
3 - Advanced Junos Service Provider1
557 pages
Implementing VPLS
No ratings yet
Implementing VPLS
47 pages
A Dvanced Junos Security: Lab Diagrams
No ratings yet
A Dvanced Junos Security: Lab Diagrams
43 pages
Huawei DCN Design Guide
No ratings yet
Huawei DCN Design Guide
90 pages
LDP VPLS Using BGP-Auto Discovery
No ratings yet
LDP VPLS Using BGP-Auto Discovery
21 pages
BGP Mpls With Evpn 1677998611
No ratings yet
BGP Mpls With Evpn 1677998611
58 pages
CSPF
No ratings yet
CSPF
38 pages
Brkaci 1000
No ratings yet
Brkaci 1000
80 pages
JN0 360
No ratings yet
JN0 360
143 pages
JSEC 12.a-R LD PDF
No ratings yet
JSEC 12.a-R LD PDF
16 pages
Junos Enterprise Switching: Chapter 7: High Availability
No ratings yet
Junos Enterprise Switching: Chapter 7: High Availability
57 pages
Simplified: Why Evpn/vxlan?
No ratings yet
Simplified: Why Evpn/vxlan?
31 pages
Guide For Junos Upgrade
No ratings yet
Guide For Junos Upgrade
19 pages
Multilevel Is-Is Networks
No ratings yet
Multilevel Is-Is Networks
16 pages
CCNP SP Adv Route Configurations
No ratings yet
CCNP SP Adv Route Configurations
41 pages
VPLS Basics
No ratings yet
VPLS Basics
298 pages
VMX Up and Running: Day One
No ratings yet
VMX Up and Running: Day One
94 pages
HCIE R&S Day 01
No ratings yet
HCIE R&S Day 01
77 pages
IOS XR BGP Commands PDF
No ratings yet
IOS XR BGP Commands PDF
420 pages
Instant Access to MPLS in the SDN Era Interoperable Scenarios to Make Networks Scale to New Services 1st Edition Antonio Sanchez Monge ebook Full Chapters
100% (1)
Instant Access to MPLS in the SDN Era Interoperable Scenarios to Make Networks Scale to New Services 1st Edition Antonio Sanchez Monge ebook Full Chapters
65 pages
MPLS Tutorial Slides
100% (1)
MPLS Tutorial Slides
397 pages
USE Only
100% (1)
USE Only
57 pages
Config Guide Mpls Applications
No ratings yet
Config Guide Mpls Applications
3,064 pages
EVPN
No ratings yet
EVPN
10 pages
Using Rib-Groups or Auto-Export For Route Leaking - J-Net Community
No ratings yet
Using Rib-Groups or Auto-Export For Route Leaking - J-Net Community
8 pages
BRKMPL 2333
No ratings yet
BRKMPL 2333
98 pages
Juniper Networks - (M - MX - T-Series) Troubleshooting Checklist - Routing Engine High CPU
No ratings yet
Juniper Networks - (M - MX - T-Series) Troubleshooting Checklist - Routing Engine High CPU
5 pages
Cisco Catalyst 9300 Series Datasheet
No ratings yet
Cisco Catalyst 9300 Series Datasheet
74 pages
Advanced Junos Security Ajsec
No ratings yet
Advanced Junos Security Ajsec
3 pages
SG 010 Contrail Networking Arch Guide
No ratings yet
SG 010 Contrail Networking Arch Guide
53 pages
HCNP-R - S Fast Track Lab Guide V2.0
100% (1)
HCNP-R - S Fast Track Lab Guide V2.0
652 pages
Junos Pppoe X
100% (2)
Junos Pppoe X
22 pages
Advanced ISIS Operations
No ratings yet
Advanced ISIS Operations
36 pages
Ccie DC Agustus
No ratings yet
Ccie DC Agustus
43 pages
Devnet 2367
No ratings yet
Devnet 2367
24 pages
Border Gateway Protocol Second Edition
From Everand
Border Gateway Protocol Second Edition
Gerardus Blokdyk
No ratings yet
Mastering Netscaler VPX: Learn how to deploy and configure all the available Citrix NetScaler features with the best practices and techniques you need to know
From Everand
Mastering Netscaler VPX: Learn how to deploy and configure all the available Citrix NetScaler features with the best practices and techniques you need to know
Marius Sandbu
No ratings yet
Cacti 0.8 Beginner's Guide
From Everand
Cacti 0.8 Beginner's Guide
Thomas Urban
No ratings yet
SolarWinds Server & Application Monitor : Deployment and Administration
From Everand
SolarWinds Server & Application Monitor : Deployment and Administration
Justin M. Brant
No ratings yet
Implementing NetScaler VPX™ - Second Edition
From Everand
Implementing NetScaler VPX™ - Second Edition
Sandbu Marius
No ratings yet
Asansol Engineering College: Topic: PPT Assignment
No ratings yet
Asansol Engineering College: Topic: PPT Assignment
10 pages
Clock Gen CPU: LCD Board
No ratings yet
Clock Gen CPU: LCD Board
53 pages
Sarthak-Soti (2K21 BAE 134) Deepti-Khurana (2K21 BAE 46)
No ratings yet
Sarthak-Soti (2K21 BAE 134) Deepti-Khurana (2K21 BAE 46)
16 pages
Super Important Questions For BDA-18CS72: Module-1
No ratings yet
Super Important Questions For BDA-18CS72: Module-1
2 pages
How To Load A File Into A Stream On Android Knowing Its Jnet - Uri - Stack Overflow
No ratings yet
How To Load A File Into A Stream On Android Knowing Its Jnet - Uri - Stack Overflow
3 pages
Waterfall Model
No ratings yet
Waterfall Model
7 pages
The Little Book of Deep Learning
100% (1)
The Little Book of Deep Learning
140 pages
Introduction To SRAMS - Synchronous vs. Asynchronous
No ratings yet
Introduction To SRAMS - Synchronous vs. Asynchronous
4 pages
Line Commands
No ratings yet
Line Commands
6 pages
FortiOS 7.2 Exam Description
No ratings yet
FortiOS 7.2 Exam Description
3 pages
SCX 4321 - SCX 4321 Specs
No ratings yet
SCX 4321 - SCX 4321 Specs
4 pages
Introduction To Robotics and Robot Programming (Assignment)
No ratings yet
Introduction To Robotics and Robot Programming (Assignment)
5 pages
GeneralMath-MODULE 1 ACTIVITY-8112-1630290962
No ratings yet
GeneralMath-MODULE 1 ACTIVITY-8112-1630290962
5 pages
Qualys Network Passive Sensor Getting Started Guide
No ratings yet
Qualys Network Passive Sensor Getting Started Guide
28 pages
G6 PPT LESSON 6 hOW THE nET cONNECTS
100% (1)
G6 PPT LESSON 6 hOW THE nET cONNECTS
9 pages
Viva Questions
No ratings yet
Viva Questions
16 pages
What Is Java
No ratings yet
What Is Java
77 pages
04 Ip 4
No ratings yet
04 Ip 4
15 pages
Chap 1 Introduction To Emerging Technology
100% (1)
Chap 1 Introduction To Emerging Technology
26 pages
Professional Summary
No ratings yet
Professional Summary
6 pages
Baksmali - Jar Commands List
No ratings yet
Baksmali - Jar Commands List
2 pages
DC 2021 03 05
No ratings yet
DC 2021 03 05
13 pages
Lesson Plan in Computer
No ratings yet
Lesson Plan in Computer
2 pages
BOS Semi - AI Compiler Fresher-Intern (Automotive)
No ratings yet
BOS Semi - AI Compiler Fresher-Intern (Automotive)
3 pages
Summer Training Report
No ratings yet
Summer Training Report
49 pages
ECD Chapter 15 Active Filters
No ratings yet
ECD Chapter 15 Active Filters
46 pages
Netflix Product Analysis
No ratings yet
Netflix Product Analysis
11 pages
CSP 2021 Hackathon Project Planning Guide (Boucher)
No ratings yet
CSP 2021 Hackathon Project Planning Guide (Boucher)
7 pages
GPON Optical Line Terminal (OLT)_2020!05!26_v000
No ratings yet
GPON Optical Line Terminal (OLT)_2020!05!26_v000
5 pages