Sie sind auf Seite 1von 509
iNETZERO – JNCIE-SP Technology focused labs v1.1 For Juniper Networks, inc - JNCIE-SP Lab Exam
iNETZERO – JNCIE-SP
Technology focused labs
v1.1
For Juniper Networks, inc - JNCIE-SP Lab Exam 2016
1
JNCIE-SP workbook:
2 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
2
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook:

General information

Copyright and licensing information

This workbook is developed by iNET ZERO.

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.

3 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
3
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook:

About the authors:

Alexey Tolstenok

JNCIE-SP workbook: About the authors: Alexey Tolstenok Alexey has more then 12+ experience in the Telecom/IT
JNCIE-SP workbook: About the authors: Alexey Tolstenok Alexey has more then 12+ experience in the Telecom/IT
JNCIE-SP workbook: About the authors: Alexey Tolstenok Alexey has more then 12+ experience in the Telecom/IT
JNCIE-SP workbook: About the authors: Alexey Tolstenok Alexey has more then 12+ experience in the Telecom/IT

Alexey has more then 12+ experience in the Telecom/IT industry.He is a triple CCIE (R&S, SP, Sec) #17405 and JNCIE-SP#313, certified Cisco and Juniper instructor.

Ivan Ivanov

certified Cisco and Juniper instructor. Ivan Ivanov Ivan van lives in East Europe country of Bulgaria.
certified Cisco and Juniper instructor. Ivan Ivanov Ivan van lives in East Europe country of Bulgaria.

Ivan van lives in East Europe country of Bulgaria. He has more than 10 years experience with IP technologies, working at several Internet Service Providers, big enterprise companies and International system integrators. Throughout his career, Ivan gained extensive experience designing, implementing and supporting IP networks based mostly on Juniper Networks and Cisco Systems solutions and devices. Ivan worked on various international projects, designing, securing and implementing MPLS/IP backbone for multinational mobile operators. Ivan has the following certificates: JNCIE, JNCIP-SEC and various Cisco certificates.

Jörg Buesink

JNCIP-SEC and various Cisco certificates. Jörg Buesink Jörg lives in the Netherlands near Amsterdam and brings
JNCIP-SEC and various Cisco certificates. Jörg Buesink Jörg lives in the Netherlands near Amsterdam and brings
JNCIP-SEC and various Cisco certificates. Jörg Buesink Jörg lives in the Netherlands near Amsterdam and brings
JNCIP-SEC and various Cisco certificates. Jörg Buesink Jörg lives in the Netherlands near Amsterdam and brings
JNCIP-SEC and various Cisco certificates. Jörg Buesink Jörg lives in the Netherlands near Amsterdam and brings
JNCIP-SEC and various Cisco certificates. Jörg Buesink Jörg lives in the Netherlands near Amsterdam and brings
JNCIP-SEC and various Cisco certificates. Jörg Buesink Jörg lives in the Netherlands near Amsterdam and brings
JNCIP-SEC and various Cisco certificates. Jörg Buesink Jörg lives in the Netherlands near Amsterdam and brings

Jörg lives in the Netherlands near Amsterdam and brings more than 10 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 triple JNCIE certified (JNCIE-ENT#21, JNCIE-SP#284 and JNCIE-SEC#30) as well as triple CCIE#15032 (Routing/ Switching, Service provider and Security), Cisco CCDE#20110002 and Huawei HCIE#2188 Routing and Switching certified.

3

4 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
4
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook:

Reviewer:

Said van de Klundert

Netherlands based networking enthusiast and Juniper Networks ambassador. Has spent most of his career on the service-providers’ side of things. Known to lab up and write about whatever sparked his interest networking wise. Other than that, he is a father to his son, husband to his wife and he enjoys long dinners with friends.

5 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
5
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook:

iNET ZERO Rack rental service

Did you know that this workbook could be used in combination with our premium JNCIE rack rental service? Take a look on our website for more information www.inetzero.com

Warning:

Please do NOT change the root account password for any of our devices to prevent unnecessary password recovery. Thank you for your cooperation

Target audience

This workbook is developed for experienced network engineers who are preparing for the Juniper Networks JNCIE-SP lab exam. Although not required it is highly recommended that you have passed the JNCIP-SP written exam.

How to use this workbook

We recommend that you start your JNCIE lab preparation by completing the first 7 chapters only. Always take a note on the time spent for each chapter/ task to see if you improved once you go over the chapters again. Ensure that at least you perform the first 7 chapters twice before you start with final chapter (the super lab). You are ready to try the 8-hour super Lab if you are able to configure the chapter’s tasks without the need to look at the answers presented in the appendix. The superlab must be completed within 8 hours as it simulates a full day JNCIE lab experience.Good luck!

iNET ZERO support

Always feel free to ask us questions regarding the workbook or JNCIE rack rental. You can reach us at info@inetzero.com . We love to hear from you regarding your preparation progress. Your feedback regarding our products is also very appreciated!

6 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
6
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Table of contents

Table of contents

General information

2

Copyright and licensing information

2

About the authors:

3

Target audience

5

How to use this workbook

5

iNET ZERO support

5

Table of contents

6

Chapter 1: System Features

14

Task 1.1:Primary hostname and user configuration

16

Task 1.2: Aggregated interface configuration

16

Task 1.3: Advanced aggregated interface configuration

16

Task 1.4: Network integration - NTP

16

Task 1.5: Network Integration - Configuration archival

17

Task 1.6: Network Integration - Syslog

17

Task 1.7: Static routing and jumbo frames support

17

Task 1.8:

SNMPv2 Configuration

17

Task 1.9:

Basic RE Protection

17

Task 1.10: Advanced RE Protection

17

Chapter 2: IGP

Part 1: IS-IS Troubleshooting Part 2: Single-area OSPFv2 Task 2.1 Single-area OSPFv2 baseline Task 2.2 OSPFv2 Network Types Task 2.3 OSPFv2: DR/BDR election Task 2.4 OSPFv2: Authentication Task 2.5 OSPFv2: Timers Task 2.6 OSPFv2: BFD Task 2.7 OSPFv2: Passive interfaces Task 2.8 OSPFv2: Load-balancing Task 2.9 OSPFv2: Cost tuning Task 2.10: OSPFv2: Miscellaneous features Part 3: Multi-area OSPFv2 Task 2.11 OSPFv2: Multi-area baseline Task 2.12 OSPFv2: Redistribution Task 2.13 OSPFv2: NSSA Task 2.14 OSPFv2: Summarization Part 4: Multi-level IS-IS Task 2.15: IS-IS Baseline Task 2.16: IS-IS Authentication Task 2.17: IS-IS Timers Task 2.18: IS-IS Route Leaking Part 5: OSPFv3 and IS-IS (IPv6)

19

21

24

25

25

25

25

25

25

25

26

26

26

27

27

27

27

28

29

29

29

29

29

30

6

7 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
7
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Table of contents

Task 2.19

30

Task 2.20

30

Task 2.21

30

Task 2.22

30

Chapter 3: MPLS

31

Part 1. RSVP

34

Task 3.1: MPLS and RSVP baseline

35

Task 3.2: RSVP Refresh Reduction and Authentication

35

Task 3.3: RSVP LSP without CSPF

35

Task 3.4: RSVP ERO

35

Task 3.5. RSVP Load-Balancing

35

Task 3.6: RSVP LSP Policy Selection

35

Task 3.7: RSVP LSP Primary and Secondary Paths

35

Task 3.8: RSVP LSP Policing and Timers

36

Task 3.9: RSVP LSP Usage for Internal Traffic

36

Task 3.10: RSVP LSP

36

Task 3.11: RSVP Node/Link Protection

36

Task 3.12: Fast Reroute for RSVP LSP

36

Task 3.13: RSVP Link Coloring

36

Task 3.14: RSVP Link Coloring (cont.)

36

Task 3.15: RSVP LSP Auto-Bandwidth

36

Task 3.16:RSVP LSP TTL Handling

37

Part 2. LDP

38

Task 3.17: LDP Baseline

39

Task 3.18: LDP Tunneling

39

Task 3.19: LDP Policies

39

Chapter 4: BGP

Part 1. Basic BGP Task 4.1: iBGP Full Mesh Task 4.2: eBGP Neighborship and Task 4.3: Enabling BFD for Task 4.4: BGP Route Injection and AS Path Task 4.5: Destination-based Remote-Triggered Blackhole (RTBH) Filtering Task 4.6: Source-based RTBH Filtering Part 2. BGP Policies Task 4.8: BGP Prefix Propagation and BGP Task 4.9: BGP Prefix Task 4.10: BGP Prefix Origination and Filtering Task 4.11: BGP Conditional Route Advertising Task 4.12: BGP Attributes Manipulation Task 4.13: BGP Scaling Part 3. IPv6 Tunneling Initial configurations: Part 3 Task 4.14: IPv6 Tunneling through IPv4/MPLS Cloud

40

43

44

44

44

44

44

44

45

46

46

46

46

46

46

47

47

8 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
8
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Table of contents

Chapter 5: VPNs

48

Part 1. L3VPN

50

Task 5.1: L3VPN with BGP as PE-CE protocol

51

Task 5.2:

L3VPN

51

Task 5.3: Hub and Spoke VPN (BGP-based)

51

Task 5.4: VPN Route Leaking

51

Task 5.5: VPN Internet Access

51

Part 2. L3VPN PE-CE OSPF

52

Task 5.6: OSPF Sham Link

53

Task 5.7: Hub and Spoke L3VPN (OSPF)

53

Part 3. L3VPN

54

5.8: BGP based Hub and spoke VPN with 1 interface

55

5.9: BGP based MPLS VPN and 6VPE

55

5.10: Inter provider VPN option B

55

Chapter 6: Layer 2 VPN

56

Task 6.1: Kompella L2VPN (VC Type 5)

59

Task 6.2: Martini L2VPN

59

Task 6.3: Kompella L2VPN (VC Type 4)

59

Task 6.4: Basic LDP-based VPLS

59

Task 6.5: LDP-based VPLS and multihoming

59

Task 6.6: Basic BGP signaled VPLS

59

Task 6.7: BGP signaled VPLS with a multihomed site

60

Task 6.8: BGP signaled VPLS features

60

Task 6.9: BGP signaled VPLS and VLAN normalization

60

Task 6.10:BGP signaled VPLS and VLAN normalization

60

Task 6.11: BGP signaled VPLS feature

60

Task 6.12: Stitching together an L2VPN and a VPLS

61

Task 6.13: VPLS and BUM replication with P2MP LSP

61

Chapter 7: Multicast VPN

Part 1:

Task 7.1: Configuring PIM with auto-rp Task 7.2: PIM filtering Task 7.3: Configuring PIM with BSR Task 7.4: Configuring PIM with a static RP Task 7.5: Configuring PIM with any-cast RP Task 7.6: Configuring PIM with any-cast RP Part 2:

Task 7.7: Configure an MVPN part 1: configuring P-PIM Task 7.8: Configure an MVPN part 2: configuring C-PIM Task 7.9: Configure an NG MVPN part 1 Task 7.10: Configure an NG MVPN part 2 Task 7.11: Configure an NG MVPN part 3

Chapter 8: Class of Service

62

64

66

66

66

66

66

66

67

67

67

67

67

67

69

9 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
9
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Table of contents

Task 8.1: Multi-field classification

73

Task 8.2: BA classification

73

Task 8.3: Policing

73

Task 8.4: Scheduling

73

Task 8.5: WRED drop profiles

74

Task 8.6: Rewrite rules

74

Task 8.7: Class-based forwarding (CBF)

74

Task 8.8: LSP policing

74

Full day lab challenge

75

Part 1: System Features

79

Task 1.1: Services configuration

79

Task 1.2:Centralized authentication management

79

Task 1.3: Local user configuration

79

Task 1.4: Active configuration archival

79

Task 1.5: Interface configuration

80

Task 1.6:

RE Protection

80

Task 1.7: Advanced prefix matching

80

Task 1.8: Advanced RE protection

80

Part 2: IGP

81

Task 2.1:

Troubleshooting

81

Task 2.2: Multiple IP addresses on OSPF interface

81

Task 2.3:

RIP

81

Task 2.4: IS-IS authentication

81

Task 2.5: IS-IS and OSPF Redistribution

82

Task 2.6:

IPv6 routing

82

Task 2.7 General requirements

82

Task 3.1: MPLS and RSVP configuration

83

Task 3.2: LSPs between SRX2 and SRX7

83

Task 3.3: LSPs between SRX1 and SRX6

83

Task 3.4: LSP protection

84

Task 3.5: LSPs between SRX6 to SRX3

84

Task 3.6: LDP configuration

84

Task 3.7: LSP forwarding based on CoS

84

Part 4: BGP

85

Task 4.1: iBGP configuration

85

Task 4.2: eBGP configuration

85

Task 4.3:

Customer BGP policy

85

Task 4.4:

Upstream BGP policy

86

Task 4.5:

Partner BGP policy

86

Task 4.6: IPv6 tunneling

86

Task 4.7: BGP general requirements

86

Part 5: VPN

87

Task 5.1: VPN Infrastructure

87

Task 5.2: OSPF-based L3VPN

87

9

10 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
10
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Table of contents

Task 5.3: BGP-based L3VPN

87

Task 5.4: L2circuit VPN configuration

87

Task 5.5: BGP VPLS configuration

88

Task 5.6: VPLS transport

88

Appendix Chapter 1: System Features

89

Task 1.1: Primary hostname and user configuration

90

Task 1.2: Aggregated interface configuration

91

Task 1.3: Advanced aggregated interface configuration

92

Task 1.4: Network integration - NTP

95

Task 1.5: Network Integration - Configuration archival

96

Task 1.6: Network Integration - Syslog

97

Task 1.7: Static routing and jumbo frames support

98

Task 1.8:

SNMPv2 Configuration

99

Task 1.9:

Basic RE Protection

100

Task 1.10: Advanced RE Protection

103

Appendix: Chapter 2 - IGP

Part 1: IS-IS Troubleshooting Part 2: Single-area OSPFv2 Task 2.1 Single-area OSPFv2 baseline Task 2.2 OSPFv2 Network Types Task 2.3 OSPFv2: DR/BDR election Task 2.4 OSPFv2: Authentication Task 2.5 OSPFv2: Timers Task 2.6 OSPFv2: BFD Task 2.7 OSPFv2: Passive interfaces Task 2.8 OSPFv2: Load-balancing Task 2.9 OSPFv2: Cost tuning Task 2.10: OSPFv2: Miscellaneous features Part 3: Multi-area OSPFv2 Task 2.11 OSPFv2: Multi-area baseline Task 2.12 OSPFv2: Redistribution Task 2.13 OSPFv2: NSSA Task 2.14 OSPFv2: Summarization Part 4: Multi-level IS-IS Task 2.15: IS-IS Baseline Task 2.16: IS-IS Authentication Task 2.17: IS-IS Timers Task 2.18: IS-IS Route Leaking Part 5: OSPFv3 and IS-IS (IPv6) Task 2.19 Task 2.20 Task 2.21 Task 2.22

107

107

118

119

121

122

123

124

125

126

127

128

129

131

132

134

136

138

140

141

143

145

147

149

150

152

153

155

10

11 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
11
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Table of contents

Appendix: Chapter 3 - MPLS

156

Part 1. RSVP

156

Task 3.1: MPLS and RSVP baseline

157

Task 3.2: RSVP Refresh Reduction and Authentication

160

Task 3.3: RSVP LSP without CSPF

162

Task 3.4: RSVP ERO

164

Task 3.5. RSVP Load-Balancing

166

Task 3.6: RSVP LSP Policy Selection

167

Task 3.7: RSVP LSP Primary and Secondary Paths

169

Task 3.8: RSVP LSP Policing and Timers

170

Task 3.9: RSVP LSP Usage for Internal Traffic

172

Task 3.10: RSVP LSP

173

Task 3.11: RSVP Node/Link Protection

176

Task 3.12: Fast Reroute for RSVP LSP

179

Task 3.13: RSVP Link Coloring

181

Task 3.14: RSVP Link Coloring (cont.)

183

Task 3.15: RSVP LSP Auto-Bandwidth

185

Task 3.16: RSVP LSP TTL Handling

187

Part 2. LDP

189

Task 3.17: LDP Baseline

190

Task 3.18: LDP Tunneling

192

Task 3.19: LDP Policies

195

Appendix: Chapter 4 - BGP

Part 1. Basic BGP Task 4.1: iBGP full mesh Task 4.2: eBGP Neighborship and Task 4.3: Enabling BFD for Task 4.4: BGP Route Injection and AS Path Task 4.5: Destination-based Remote-Triggered Blackhole (RTBH) Filtering Task 4.6: Source-based RTBH Filtering Part 2. BGP Policies Task 4.8: BGP Prefix Propagation and BGP Task 4.9: BGP Prefix Task 4.10: BGP Prefix Origination and Filtering Task 4.11: BGP Conditional Route Advertising Task 4.12: BGP Attributes Manipulation Task 4.13: BGP Scaling Part 3. IPv6 Tunneling Task 4.14: IPv6 Tunneling through IPv4/MPLS Cloud

Appendix: Chapter 5 - VPN

Part 1. L3VPN

Task 5.1: L3VPN with BGP as PE-CE protocol

Task 5.2: L3VPN

Task 5.3: Hub and Spoke VPN (BGP-based)

197

197

198

200

202

204

206

209

211

212

216

218

221

224

227

229

230

234

234

235

239

241

11

12 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
12
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Table of contents

Task 5.4: VPN Route Leaking

245

Task 5.5: VPN Internet Access

248

Part 2. L3VPN PE-CE OSPF

250

Task 5.6: OSPF Sham Link

251

Task 5.7: Hub and Spoke L3VPN (OSPF)

255

Part 3. L3VPN

259

5.8: BGP based Hub and spoke VPN with 1 interface

260

5.9: BGP based MPLS VPN and 6VPE

269

5.10: Inter provider VPN option B

282

Appendix: Chapter 6 - Layer 2 VPN

287

Task 6.1: Kompella L2VPN (VC Type 5)

288

Task 6.3: Kompella L2VPN (VC Type 4)

294

Task 6.4: Basic LDP-based VPLS

296

Task 6.5: LDP-based VPLS and multihoming

300

Task 6.6: Basic BGP signaled VPLS

305

Task 6.7: BGP signaled VPLS with a multihomed site

309

Task 6.8: BGP signaled VPLS features

315

Task 6.9: BGP signaled VPLS and VLAN normalization

320

Task 6.10: BGP signaled VPLS and VLAN normalization

322

Task 6.11: BGP signaled VPLS feature

325

Task 6.12: Stitching together an L2VPN and a VPLS

327

Task 6.13: VPLS and BUM replication with P2MP LSP

333

Appendix: Chapter 7 - Multicast

Part 1:

Task 7.1: Configuring PIM with auto-rp Task 7.2: PIM filtering Task 7.3: Configuring PIM with BSR Task 7.4: Configuring PIM with a static RP Task 7.5: Configuring PIM with any-cast RP Task 7.6: Configuring PIM with any-cast RP Part 2:

Task 7.7: Configure an MVPN part 1: configuring P-PIM Task 7.8: Configure an MVPN part 2: configuring C-PIM Task 7.9: Configure an NG MVPN part 1 Task 7.10: Configure an NG MVPN part 2 Task 7.11: Configure an NG MVPN part 3

Appendix: Chapter 8 - Class of Service

337

337

339

343

345

349

351

354

357

360

363

370

372

379

382

Task 8.1: Multi-field classification

383

Task 8.2:

BA classification

386

Task 8.3:

Policing

389

Task 8.4:

Scheduling

395

Task 8.5:

WRED drop profiles

400

Task 8.6: Rewrite rules

402

12

13 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
13
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Table of contents

Task 8.7: Class-based forwarding (CBF)

405

Task 8.8:

LSP policing

408

Appendix – Full day lab challenge

410

Part 1: System Features

410

Task 1.1: Services configuration

410

Task 1.2:Centralized authentication management

411

Task 1.3: Local user configuration

412

Task 1.4: Active configuration archival

413

Task 1.5: Interface configuration

413

Task 1.6:

RE Protection

416

Task 1.7: Advanced prefix matching

418

Task 1.8: Advanced RE protection

419

Part 2: IGP

420

Task 2.1:

Troubleshooting

420

Task 2.2: Multiple IP addresses on OSPF interface

424

Task 2.3:

RIP

425

Task 2.4: IS-IS authentication

431

Task 2.5: IS-IS and OSPF Redistribution

431

Task 2.6:

IPv6 routing

436

Task 2.7 General requirements

440

Part 3: MPLS

442

Task 3.1: MPLS and RSVP configuration

442

Task 3.2: LSPs between SRX2 and SRX7

446

Task 3.3: LSPs between SRX1 and SRX6

449

Task 3.4: LSP protection

452

Task 3.5: LSPs between SRX6 to SRX3

454

Task 3.6: LDP configuration

455

Task 3.7: LSP forwarding based on CoS

457

Part 4: BGP

459

Task 4.1: iBGP configuration

459

Task 4.2:

eBGP configuration

464

Task 4.3:

Customer BGP policy

470

Task 4.4:

Upstream BGP policy

472

Task 4.5:

Partner BGP policy

477

Task 4.6:

IPv6 tunneling

479

Task 4.7:

BGP general requirements

481

Part 5: VPN

483

Task 5.1: VPN Infrastructure

483

Task 5.2: OSPF-based L3VPN

483

Task 5.3: BGP-based L3VPN

494

Task 5.4: L2circuit VPN configuration

499

Task 5.5: BGP VPLS configuration

502

Task 5.6: VPLS transport

508

14 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
14
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 1: System Features

Chapter 1: System Features

Introduction:

JUNOS offers support for many features commonly used within networks. The supported features are (mostly) consistent across the different device types that Juniper has to offer.

By default, there is one super user in the system, this is the “root” user. Any additional users and passwords have to be added manually. In JUNOS, every user has to belong to a class. A class can contain multiple users and these classes define what privileges are granted to every user that is a member of the class. Administrators can define their own custom classes. By default, there are four pre-defined classes.

Inside every JUNOS class, so-called permission-flags can be set. These permission flags indicate what commands are available to the users belonging to the class. There are permissions granting the users access to operational mode commands and there are permissions granting the users access to configuration commands.

Apart from local password authentication, JUNOS also supports remote authentication methods such as TACACs+ and RADIUS. Remote authentication methods can be combined with local password authentication. Local password authentication usually serves as a last resort, authenticating locally configured users only when IP connectivity with the remote authentication system is lost.

JUNOS also supports physical interface bundling, or link aggregation. This enables the grouping of multiple physical interfaces with the same properties (media, speed, duplex mode) into one logical interface called an aggregated interface, or AE. The use of link aggregation allows for increased redundancy and throughput. In general, AE interfaces can be used in the same way regular interfaces are used (as a Layer 3 interface, as an interface in an L2VPNs, etc.). The members of the AE interface can be a statically configured to participate in the LAG or they can use the LACP protocol . The LACP protocol allows for the automatic detection and deletion of member links. In addition to his, LACP also has certain link monitoring capabilities that can check whether both ends of the link belong to the same AE bundle. The LACP protocol can be configured to operate in different modes and send messages at different intervals.

15 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
15
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 1: System Features

configuring the same NTP server(s) on all JUNOS devices, troubleshooting can become a lot easier. JUNOS also offers a standard UNIX syslog service, which supports eight levels of message severities. These messages can be stored locally, sent to a remote syslog server and/or to all users that are currently logged in. On JUNOS systems, the SNMP agent is disabled by default. All existing SNMP versions up to version 3 are supported.

Another integral part of JUNOS images are basic security features such as stateless firewall filters, control plane protection mechanisms and anti-spoofing mechanisms.

A standard firewall filter can be applied to JUNOS device’s loopback interface and by doing so, all traffic to and from the routing-engine can be controlled. This helps to provide basic protection from potentially malicious traffic that is aimed at the routing-engine.

The uRPF feature works by comparing the source IP of each incoming IP packet against the routing table. The route towards the source IP of the packet has to correspond to the interface on which the packet was received. If this is not the case, the packet is dropped. In general, uRPF is enabled on interfaces facing to the “outside” of the AS and the feature can eliminate the need to configure long and error-prone anti-spoofing firewall filters.

Do’s and Dont’s

When listing separate allowed/denied commands in the user class configuration, always enclose them in double quotes “…”

By default, the number of supported AE interfaces is 0. Don’t forget to enable the ‘aggregated-devices’ in the [ chassis ] configuration hierarchy.

If the NTP ‘show ntp associations’ command does not show an NTP server selected for synchronization (indicated by the “*”), try running the operational mode command “set date ntp <NTP server IP>”. This runs the BSD ntpdate utility, which queries the NTP server and sets the local time.

16 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
16
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 1: System Features

Initial configuration: sys-start

Chapter 1: System Features Initial configuration: sys-start Task 1.1:Primary hostname and user configuration • Apply

Task 1.1:Primary hostname and user configuration

Apply the new hostnames R1 and R2 to the srx1 and srx2 routers respectively.

Create a custom login class “supervisor” and assign all permissions to it except for the ability to start a BSD shell from CLI.

Configure a local user “inetzero” with password “InetZero” as a member of this class.

Task 1.2: Aggregated interface configuration

Create an aggregated Ethernet interface and statically assign ge-0/0/1 and ge-0/0/2 on R1 and R2 to this bundle.

Assign IP addresses on both ends according to diagram.

Task 1.3: Advanced aggregated interface configuration

Enable LACP on both sides of bundle. Only R1 should initiate exchange of LACP PDUs.

Tune the bundle so that the aggregated interface is operational only when both links are in the “up” state.

Adjust the configuration so that R2 sends LACP PDUs every 30 seconds.

Task 1.4: Network integration - NTP

Configure an NTPv3 client on R1 and R2. Configure the routers to synchronize with the server IP address 10.10.1.100.

Modify the R1 and R2 configuration so that initial NTP sync with this server is performed at boot time. All NTP messages should be authenticated using MD5 authentication. Use the password “workbook”.

17 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
17
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 1: System Features

Task 1.5: Network Integration - Configuration archival

Make sure the active configuration is transferred to and FTP server with IP address 10.10.1.100 every 15 minutes.

Specify “lab” as username and “lab123” as the password to access the FTP server.

Task 1.6: Network Integration - Syslog

Log all messages from any facility and for all levelsto host 10.10.1.100.

Configure local logging and have all ‘error’ messages saved to a file called “error- messages”. Set the maximum file size to 1Mb and increase the number of files to 20. All users should be able to see the content of these log files. Also make sure that priority information is included in the messages.

Make sure messages with a critical severity are logged to all users currently logged in.

Remove all other default syslog settings.

Task 1.7: Static routing and jumbo frames support

Establish IP connectivity between the R1 and R2 loopbacks by configuring static routes.

Make sure that R1 and R2 are able to exchange jumbo frames of up to 9192 bytes.

Task 1.8: SNMPv2 Configuration

Enable an SNMP agent on R1 and limit access to host 10.10.1.100. Use the community string “inetzero” and allow read/write NMS access.

Configure R2 to send traps to 10.10.1.100 in case of environment, link transition events and authentication failures.

Task 1.9: Basic RE Protection

Configure a firewall filter for R1 and apply it in the input direction of the loopback interface.

Make sure that previously configured services (NTP, FTP and SNMP) keep on working as before.

Restrict telnet access to packets originating from the 10.10.1.0/24 network.

Accept only ICMP types required for the ping utility to function properly.

Discard and count all other traffic.

Task 1.10: Advanced RE Protection

Configure a BFD protected iBGP session between the loopback IP addresses of both R1 and R2. Use AS65000.

Enable OSPF for the AE interface on both routers.

Alter the firewall filter in such a way that BGP, BFD and OSPF can function.

Permit OSPF in the firewall filter for locally configured subnets. Make sure that all the addresses configured on the router are automatically added to the list.

Make sure that all configured BGP peers are automatically added to the firewall filter.

17

18 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
18
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 1: System Features

Change the end-term to not only discard and count, but to log and syslog as well.

19 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
19
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 2: IGP

Chapter 2: IGP

Introduction:

The IGP is one of the most important parts in any SP network design. All other protocols required by any of the SP services rely either directly or indirectly on the IGP. Some of the IGPs most critical tasks are the fast and correct distribution of internal prefix information. The IGPs most commonly deployed by SPs are IS-IS and OSPF.

Both of these IGPs use a link-state database (LSDB) to store routing information and both OSPF and IS-IS use the Dijkstra algorithm to calculate the best paths. Each protocol uses specific packets to distribute the routing information stored in the LSDB. In OSPF, these packets are called LSAs. In IS-IS, these packets are called LSPs.

One of the main differences between OSPF LSAs and IS-IS LSPs is the way in which IS-IS LSPs use TLV tuples to describe prefix information. New TLV tuples are easily added to carry additional or different information. So even though IS-IS was not initially developed for IP, this concept has made it possible to extend IS-IS and rely on only 1 instance of the protocol to distribute information for both IPv4 and IPv6.

OSPF is transported in IP (protocol number 89) and has 2 versions. OSPFv2 was designed for IPv4 and, later on, OSPFv3 was developed to support IPv6. Since both versions work independently from each other, IS-IS is generally considered the most attractive IGP for SP environments.

Both IGPs establish and maintain neighbor adjacencies. These neighbor adjacencies are a pre-requisite for the exchange of routing-information. Neighbor adjacencies are built automatically by having routers exchange Hello packets. These same Hello packets are also used to maintain the neighbor adjacency.

Even though both IGPs need the MTU size to match on both sides of the link for successful adjacency formation, there is a difference in MTU mismatch discovery. IS-IS uses hello packets while OSPF can discover an MTU mismatch only during the exchange of database description packets. Both IGPs also handle fragmentation in a different way. OSPF routers rely on IP to handle fragmentation. IS-IS routers don’t rely on IP, but have packets fragmented at the originating router instead.

Both protocols organize the network into areas. However, there are some differences in the way OSPF and IS-IS do this. In OSPF, all areas must to be connected to area 0 (the backbone area). The reason for this is that OSPF behaves as a distant vector protocol for inter-area routing. In OSPF, all the routers within an area have an identical LSDB.

IS-IS does not share the concept of a backbone area. Instead, it requires a logical topology of contiguously connected Level 2 routers with (possible) branches of Level 1-2 and Level 1

19

20 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
20
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 2: IGP

routers. Another difference is that in IS-IS, the entire router resides within a single area while in OSPF, the individual links of a router can be placed into different areas. In IS-IS, routers have a per level LSDB. In OSPF, routers have a per area LSDB.

Do’s and Dont’s

OSPF:

Always pay attention to which logical interface number should be put into an area. In case you omit a unit number, unit 0 will be added automatically.

Don’t forget to add loopback interface lo0.x to the OSPF configuration because other protocols like internal BGP rely on loopback IP reachability.

Check that IP addresses on both sieds of the link belong to the same subnet and that they are using the same subnet. Also make sure that the following parameters are identical: OSPF interface network type, area number, area type, hello and dead intervals, MTU, authentication type and passwords (if any).

Don’t forget to write and add an export policy to the forwarding table if you’re asked to enable load-balancing across several equal-cost paths.

IS-IS:

Take care when you are deciding on which level logical interfaces need to operate. In case you omit a unit number, unit 0 will be added automatically.

Make sure that the ISO protocol family is on every logical interface that should run IS- IS.

Add at least one NET address to the interface configuration under the “family iso” hierarchy (generally it is configured on the loopback interface).

By default, levels 1 and 2 are enabled on the IS-IS interface. Disable the unwanted level to prevent undesirable level adjacencies to be established.

Make sure that IP addresses are from the same subnet on both ends of the link. Also make sure that the following parameters are identical: IS-IS interface network type, MTU, area IDs (for level-1 only adjacencies), authentication parameters (if any).

21 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
21
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 2: IGP

Part 1: IS-IS Troubleshooting

Initial configs : IS-IS-TShoot

Objective: Troubleshoot IS-IS adjacencies in the following topology. They should form across logical connections between the routers according to the diagram. All neighbors should have no more than one adjacency across each logical interface.

22 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
22
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 2: IGP

22 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016) JNCIE-SP workbook: Chapter 2:
23 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
23
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 2: IGP

24 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
24
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 2: IGP

Part 2: Single-area OSPFv2

Initial configs : IPv4-basic

– version 1.1 (2016) JNCIE-SP workbook: Chapter 2: IGP Part 2: Single-area OSPFv2 Initial configs :
25 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
25
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 2: IGP

Task 2.1 Single-area OSPFv2 baseline

Configure OSPFv2 area 0 on the interface of every router according to the diagram.

Task 2.2 OSPFv2 Network Types

Reconfigure R3 and R4 so that there will be no DR/BDR election on the links between R3 and R4.

Task 2.3 OSPFv2: DR/BDR election

Reconfigure the R1-R3 and the R2-R4 OSPF adjacencies so that R3 and R4 will always be the DRs on their respective segments.

You are allowed to configure the R1 and R2 routers only.

Task 2.4 OSPFv2: Authentication

Configure clear text authentication between R1 and R3 using password "R1R3CLR"

Configure MD5 authentication between R2 and R4 using password "R2R4MD5"

Task 2.5 OSPFv2: Timers

Adjust OSPF hello and dead timers on R1-R3 and R2-R4 links to the values 1 and 4 seconds respectively.

Modify the amount of time during which the local device waits for acknowledgement from a neighboring device before retransmitting a previously sent LSA. Do this on all routers.

Task 2.6 OSPFv2: BFD

Enable the BFD protocol on the upper R3-R4 link connecting the G0/0/1 interfaces. Specify a minimum transmit and receive interval of 400 ms.

Make sure that the detection time is 2 seconds.

Make sure that BFD is enabled only for those OSPF neighbors which are in the "Full" state.

Task 2.7 OSPFv2: Passive interfaces

Assign the addresses 11.11.11.11/24 and 22.22.22.22/24 on the G0/0/1 interfaces of R1 and R2 respectively.

Advertise these interface addresses to OSPF without actually running OSPF on them. Do not use a policy to perform this task.

26 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
26
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 2: IGP

Task 2.8 OSPFv2: Load-balancing

Make sure that both equal cost OSPF paths between R3 and R4 are installed into their respective forwarding tables.

Task 2.9 OSPFv2: Cost tuning

By changing the OSPF costs make sure that traffic between R1 and R2 in both directions prefers the link connecting R3 and R4 G0/0/1 interfaces.

Task 2.10: OSPFv2: Miscellaneous features

Change the automatically calculated OSPF metric to a value of 10 on GigabitEthernet interfaces on all routers.

Make sure that the LSAs routers orignate have the DoNotAge bit set.

Configure OSPF database protection for all routers so that only a warning message is generated when the maximum number of LSAs generated by other routers exceeds 500. Generate the first warning after exceeding a value of 400.

27 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
27
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 2: IGP

Part 3: Multi-area OSPFv2

Initial configs : IPv4-basic

IGP Part 3: Multi-area OSPFv2 Initial configs : IPv4-basic Task 2.11 OSPFv2: Multi-area baseline • Configure

Task 2.11 OSPFv2: Multi-area baseline

Configure OSPF area 0 between R3 and R4. Advertise the loopbacks of R3 and R4 to this area.

Configure OSPF area 13 between R1 and R3 and OSPF area 24 between R2 and R4. Advertise the loopbacks of R1 and R2 to OSPF.

Task 2.12 OSPFv2: Redistribution

Configure static routes 172.16.0.0/24 through 172.16.3.0/24 on R1 and 172.16.4.0/24 through 172.16.7.0/24 on R2 respectively. Enable generation of ICMP unreachables when traffic is send to these destinations.

Redistribute these static routes into OSPF on R1 and R2.

Make sure these routes appear in routing tables marked as Type 1 externals.

Limit the number of the prefixes that can be exported to OSPF to 10 both on R1 and

R2.

Task 2.13 OSPFv2: NSSA

Convert regular areas 13 and 24 into NSSAs. Do not allow OSPF inter-area LSAs to leak into areas 13 and 24.

Make sure you still have IP reachability between prefixes originated at R1 and R2.

28 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
28
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 2: IGP

Task 2.14 OSPFv2: Summarization

Summarize the redistributed static routes from task 2.12 so that each range appears as a single prefix in area 0 and specific prefixes are suppressed.

29 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
29
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 2: IGP

Part 4: Multi-level IS-IS

Initial configs : IPv6-basic

IGP Part 4: Multi-level IS-IS Initial configs : IPv6-basic Task 2.15: IS-IS Baseline • Configure a

Task 2.15: IS-IS Baseline

Configure a multi-level IS-IS basline according to the diagram.

Use xxxx.xxxx.xxxx as system-id, where x is the router number.

Task 2.16: IS-IS Authentication

Enable hello authentication only within L1 areas. Use MD5 as the authentication type and R1R3 as a password for the R1-R3 connection and R2R4 for the R2-R4 one.

Disable the DIS election on the links as shown in the diagram.

Enable both hello and LSP authentication between R3 and R4. Use MD5 and password R3R4.

Task 2.17: IS-IS Timers

Change the CSNP interval on the R3-R4 links to the value of 5 seconds.

Change the transmission frequency to 1 LSP per second on the links R1-R3 and R2-R4.

Task 2.18: IS-IS Route Leaking

Disable the installation of a default route on R1 and R2

Change the configuration so that there still is full IPv6 reachability after that.

30 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
30
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 2: IGP

Part 5: OSPFv3 and IS-IS (IPv6)

Initial configs : OSPFv3-IS-IS- IPv6

and IS-IS (IPv6) Initial configs : OSPFv3-IS-IS- IPv6 Task 2.19 • Configure the IS-IS and OSPFv3

Task 2.19

Configure the IS-IS and OSPFv3 baseline according to the diagram.

Task 2.20

Configure 4 static IPv6 routes on R1 according to the diagram. Use “reject” keyword as a next-hop value.

Redistribute these routes to IS-IS.

Task 2.21

Enable redistribution between OSPFv3 and IS-IS on R3 and R5.

Make sure you have full IP reachability between all existing prefixes.

Make sure that there are no routing loops and that there is no suboptimal routing.

Task 2.22

Enable OSPFv3 authentication between R3 and R4.

Use protocol esp, spi 256, the hmac-sha1-96 algorithm and key ' inetzero-jncie-inet0'

31 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
31
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 3: MPLS

Chapter 3: MPLS

Introduction:

MPLS is a technology that is playing an invaluable role in any modern SP network. MPLS is not just another way of switching packets across a SP network, but it’s a different approach to building a scalable universal infrastructure that can support a variety of services.

In MPLS, Label Switched Paths (LSPs) are signaled between MPLS nodes, called LSRs. These LSPs are unidirectional and they are used by LSRs to switch traffic across the network. LSRs perform an exact-match label lookup to determine which interface is to be used as an outgoing interface. This as opposed to the traditional longest-match lookup of the destination IP address against the routing table.

Labels are pushed onto IP packets between its Layer 2 and Layer 3 header on the edge of the MPLS network by edge routers. These router are commonly referred to as PE (Provider Edge) routers. The operation wherein a label is added to the stack is called a “push” operation. This operation is mostly performed on ingress. On intermediate MPLS nodes, the MPLS label is changed. This is called a “swap” operation. On egress, the MPLS label is removed from the packet in an operation referred to as “pop”. This can be performed by an egress PE or, as is the case most often, the penultimate hop MPLS node. The scenario wherein the penultimate hop pops the label is called Penultimate Hop Popping (PHP). PHP behavior optimizes label operations by avoiding a double lookup on the egress PE. By popping the label, the egress PE only has to do an IP lookup. If the label were not popped, the egress PE would have to examine both a label and an IP address.

Label distribution can be provided by means of the label distribution protocols LDP and RSVP. The main difference between them is the traffic engineering (TE) capabilities offered by RSVP. LDP relies upon the underlying IGP and LDP signaled LSPs always follow the best paths chosen by the IGP. RSVP allows for administrators to define what path an LSP should take, offering a more equal and efficient utilization of network resources. RSVP was originally designed as a signaling protocol for resource reservations between hosts. By creating extensions for RSVP, it was made suitable to serve as a label distribution protocol. Through these extensions, support for labels, hello packets, path protection and other features were made possible.

RSVP can also track the amount of currently used and available bandwidth together with other TE specific parameters inside a database called the TED (traffic engineering database). This is a more detailed version of the link-state LSDB and both IS-IS and OSPF support TED and TE capabilities.

32 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
32
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 3: MPLS

One of the things the TED can contain is information about link colors. These can offer additional flexibility for the creation of LSPs. Link colors make it possible to easily include or exclude colored links from path computation.

CSPF is an advanced version of SPF algorithm used in link-state protocols. Its additional capabilities include taking user-defined constraints (such as link colors) into consideration when creating an ERO (explicit route object) – a list of hops that should be visited during the creation of an LSP. This ERO list is used by RSVP for LSP signaling.

An ERO list can be defined by explicitly specifying hop sequences from the ingress LSR to the egress LSR. Two types of hops can be defined in these ordered sequences; strict hops and loose hops. A strict hop has to be an IP address of a directly connected neighbor interface. A loose hop can be anywhere between the ingress and egress point of the LSP. The actual path between the local node and the loose hop is calculated by the IGP.

By default, only the loopback IP addresses for routers will be present in the inet.3 table. This is because with RSVP signaled LSPs, only the /32 that corresponds to the egress point of the LSP is placed into the inet.3 table. And with LDP, only the label binding for the loopback IP is advertised to other routers.

Furthermore, by default, the routing information in the inet.3 table is usable only by the BGP protocol. If for some prefix the BGP next-hop can be resolved in this table, then the corresponding LSP will be used to forward traffic. This default behavior can be changed and LSPs can also be used to forward to non BGP destinations.

33 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
33
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 3: MPLS

Do’s and Don’ts

Enable MPLS processing by adding “family mpls” on all core-facing logical interfaces on every PE and P router. Also configure the same logical interfaces in the “protocols mpls” stanza. Verify that all the necessary interfaces are MPLS enabled by analyzing the output of the “show mpls interfaces” operational mode command.

Enable RSVP and/or LDP on every logical interface that any MPLS LSP might cross. Generally, these are core-facing interfaces. Be careful with logical interface numbers and always double-check them to prevent troubleshooting due to typos.

Always use the “show mpls lsp extensive” command when troubleshooting unsuccessful LSP setup. This is because the output of this command contains the LSP’s recent events. The reasons for any LSP setup failure can be found there as well.

Be aware that, by default, only BGP uses the inet.3 table for route resolution. The options under “set protocols mpls traffic-engineering” can change this behavior.

When using link colors, take into account that links with no color assigned are not considered. They are purged from calculation when “include” is used and considered when “exclude” is used.

When working with ERO lists, be careful to visit nodes only once and avoid loops when defining a path.

34 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
34
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 3: MPLS

Part 1. RSVP

Initial configurations: OSPFv2-baseline

– version 1.1 (2016) JNCIE-SP workbook: Chapter 3: MPLS Part 1. RSVP Initial configurations: OSPFv2-baseline 34
35 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
35
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 3: MPLS

Task 3.1: MPLS and RSVP baseline

Enable MPLS processing and RSVP signaling on all interfaces from the diagram on all routers.

Task 3.2: RSVP Refresh Reduction and Authentication

Enable RSVP message bundling features on the R3-R4 sessions.

Enable reliable message delivery and RSVP message ID on the R1-R3 and R2-R4 sessions.

Authenticate R3-R5 and R4-R5 RSVP sessions with the key "RsvP".

Task 3.3: RSVP LSP without CSPF

Create 2 RSVP LSPs from R1 to R2 named Red and Blue respectively.

Request 1Mb of bandwidth for Red and 2Mb for Blue and turn the CSPF off on both LSPs.

Task 3.4: RSVP ERO

Create primary explicit paths for the LSPs from previous task.

Red LSP should go strictly through the upper physical path between R3 and R4, Blue LSP - through the lower one.

Don’t use loose hops in ERO list.

Task 3.5. RSVP Load-Balancing

On R1, enable traffic distribution between Red and Blue LSP proportionally to theirbandwidth assigned.

Task 3.6: RSVP LSP Policy Selection

Create 2 RSVP LSPs from R2 to R1 named Orange and Green and disable CSPF for both LSPs.

Make both LSPs visible for internal traffic going to the R1 loopback address. At the same time, the OSPF route to 1.1.1.1/32 should be active.

Make sure that the Orange LSP is preferred for internal traffic going to 1.1.1.1/32. Use a policy for performing this task.

Task 3.7: RSVP LSP Primary and Secondary Paths

Create an RSVP LSP from R1 to R2 named Brown and turn off CSPF for the LSP.

Enable a primary path that visits R5 and don’t use more than one ERO.

Enable the use of a secondary path which is fully calculated by the IGP and have this path ready to accept traffic in case of primary path failure.

36 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
36
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 3: MPLS

Task 3.8: RSVP LSP Policing and Timers

Assign 40K of RSVP bandwidth to LSP Brown and enable the policing of traffic going through this LSP equal to the configured value.

Change the time between the attempts of bringing up a failed primary path of LSP Brown to 10 seconds and number of these attempts to 10. Also configure a hold- down window for switching traffic back to the restored primary to 30 seconds.

Task 3.9: RSVP LSP Usage for Internal Traffic

Enable the use of LSP Brown for traffic from R1 to IP address 22.22.22.22 on R2.

Task 3.10: RSVP LSP Optimization.

Change the configuration of your routers so that each router can report the current bandwidth reservations to OSPF.

Within Brown LSP configuration, turn the LSP optimization on with the optimize- timer set to 60 seconds.

Task 3.11: RSVP Node/Link Protection

Protect both Red and Blue LSPs with the link protection mechanism.

Protect LSP Brown from the whole failure of R5.

Task 3.12: Fast Reroute for RSVP LSP

Reconfigure Orange LSP so that it visits R5 and order Fast Reroute for this LSP.

Task 3.13: RSVP Link Coloring

Assign link colors Red, Blue and Green to R4 ge-0/0/1.0, R4 ge-0/0/2.0 and R4 ge- 0/0/4.45 interfaces respectively.

Also assign Green color to R2 ge-0/0/4.24, R5 ge-0/0/4.35 and R3 ge-0/0/4.13

Task 3.14: RSVP Link Coloring (cont.)

Create an LSP from R2 to R1 named “AG1” which includes links only with Green color while building LSP.

Create another LSP to the same direction named “AG2” which excludes links with colors Red or Blue.

Task 3.15: RSVP LSP Auto-Bandwidth

Enable auto-bandwidth on LSP Orange with the bandwidth reallocation interval set to 300 seconds.

Adjust the auto-bandwidth statistics interval to 30 seconds and use the name “mpls- stat” for the statistics file.

37 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
37
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 3: MPLS

Task 3.16:RSVP LSP TTL Handling

On the Orange LSP, enable the Juniper proprietary mechanism that disables normal TTL decrementing.

38 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
38
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 3: MPLS

Part 2. LDP

Initial configurations: OSPFv2-baseline

– version 1.1 (2016) JNCIE-SP workbook: Chapter 3: MPLS Part 2. LDP Initial configurations: OSPFv2-baseline 38
39 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
39
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 3: MPLS

Task 3.17: LDP Baseline

Enable LDP on the R1-R3 and R2-R4 links and on the loopback interfaces of the routers involved.

LDP sessions should be extended and authenticated with MD5 hashes using the R1R3 and R2R4 passwords respectively.

On both pairs enable, the mode that prevents LDP sessions from being established with non-configured LDP peers.

Task 3.18: LDP Tunneling

Configure 2 RSVP LSPs between R3 and R4 and have them transit R5.

Enable the RSVP signaled LSPs for LDP LSPs.

Make sure that internal traffic between the R1 and R2 loopback addresses make use of the LDP LSPs and make sure that the LDP metric on both R1 and R2 is derived from the IGP.

Task 3.19: LDP Policies

In addition to the loopback interface, have R2 announce prefix 22.22.22.0/24 into LDP.

Make sure that only /32 prefixes are installed in the inet.3 table of R1 and R3. Configure only the R3 router to achieve this.

40 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
40
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 4: BGP

Chapter 4: BGP

Introduction:

BGP is a protocol that performs different tasks in a SP environment. One of the primary tasks is to allow for the exchange of prefix information between different autonomous systems. Apart from that, BGP can also play an important role in the signaling of other services. This is made possible by using the modified version of BGP, called MP-BGP. This version of BGP is capable of carrying more than just IPv4 prefixes. It allows for the distribution of routing- information for a number of different address families, such as the ‘inet-vpn’ and ‘l2vpn signaling’ address families for example. These last two enable services such as BGP signaled MPLS Layer 3 and Layer 2 VPNs.

Unlike other routing-protocols, there is no auto-discovery procedure defined for BGP. All BGP neighbors need to be configured explicitly. Another factor that sets BGP apart from other routing-protocols is the use of TCP as a (reliable) transport protocol.

We can distinguish two types of BGP sessions: iBGP (used within an AS) and eBGP (used between different ASes). In general, iBGP sessions are sourced from the loopback addresses of peering routers while eBGP sessions are sourced using the address configured on the physical interface that connects the peering routers to each other.

BGP relies on the AS path for loop prevention. The AS path is prepended to prefixes when they are advertised across an eBGP session. Since the AS path is not prepended to prefixes exchanged across an iBGP session, this mechanism would not work for iBGP. Therefore, iBGP learned prefixes are never forwarded across an iBGP session. This leads to the requirement of a full-mesh of iBGP sessions within an AS.

Since the full-mesh requirement does not scale well, 2 different scaling mechanisms were developed for BGP: BGP confederation and route-reflection. The BGP confederation mechanism allows for the AS to be broken up into smaller sub-ASes called confederations. Only within these sub-ASes is a full mesh of iBGP sessions required. Prefix exchange between sub-AS’es is provided by eBGP-like sessions called confederation BGP sessions.

The other BGP scaling mechanism is called Route-Reflection. The Route-Reflection approach relaxes the iBGP rule which states that iBGP learned routing information cannot be advertised to other iBGP peers across an iBGP session. This applies to routers that serve as a Route-Reflector (RR). Instead of a full mesh, all BGP speaking routers have an iBGP session with one or more RRs. These RRs can reflect iBGP learned routes between the different RR- clients. For very large networks, it is even possible to define a hierarchy of RR-clusters that serve different parts of the network or specific address-families.

40

41 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
41
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 4: BGP

Another point worth mentioning is that the two BGP scaling mechanisms are not mutually exclusive. A RR can be configured to relax the iBGP full-mesh requirement within a BGP sub- AS.

All prefix information carried by BGP has so-called PATH attributes attached to it. These PATH attributes make BGP the most flexible routing-protocol to date. In combination with routing-policies, these PATH attributes can be used to manipulate routing-information in an endless number of ways.

For example, the local preference attribute can be used to manipulate the exit point for outgoing traffic towards another AS while attributes AS-PATH and MED can be used to manipulate entry points for incoming traffic into the AS.

Another BGP attribute worth mentioning is the BGP community. Communities are often used to tag or mark traffic at a certain point in the network. The administrator of the AS can easily identify these routes anywhere in the AS by referencing these communities in policies. By doing so, it becomes possible to manipulatie traffic and routing information in a very concise way.

42 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
42
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 4: BGP

Do’s and Dont’s:

Make sure there is IP reachability between BGP speakers before setting up the BGP sessions. You can use the ping utility with the ‘source’ option for this.

To prevent BGP routes from being marked as hidden, make sure that the next-hop of the route (by default the IP address of the last eBGP peer) can be resolved in the inet.0 table on every BGP peer. This can be done by injecting the eBGP peer facing interface into the IGP or through the use of a routing policy that rewrites the next- hop.

The first step in configuring RTBH is to configure a static route for an unused prefix that has it’s next-hop set to discard on every iBGP router within the AS. Then, on a signaling router, an export policy should be configured to redistribute static routes into BGP. A policy that takes care of the redistribution should set the next-hop of the route to match the discard route. This will make all iBGP speaking peers install the route into the forwarding table with a next-hop that corresponds to a discard route. Furthermore, the policy on the signaling router should also set the local preference to the highest value within the AS and attach the no-export community. This way the route will be active and it will never be (accidentally) advertised towards any other AS. Another good idea is to make the signaling router trigger RTBH only for static routes configured with a specific tag or community.

While configuring IPv6 tunneling, don’t forget to enable “family inet6” support not only on PE interfaces connected to CE but also on core-facing interfaces.

43 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
43
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 4: BGP

Part 1. Basic BGP

Initial configurations: Part 1

WORKBOOK – version 1.1 (2016) JNCIE-SP workbook: Chapter 4: BGP Part 1. Basic BGP Initial configurations:
44 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
44
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 4: BGP

Task 4.1: iBGP Full Mesh

Configure a full-mesh of iBGP sessions between R3, R4 and R5 according to the diagram.

Use the asdot notation format when configuring the AS number.

Task 4.2: eBGP Neighborship and Authentication.

Configure the eBGP sessions between R1,R3 and R2,R4.

AS65565 should be configured as though it is connected to AS 65444 which was recently assimilated by AS 65555.

Authenticate these sessions with the MD5-hashed passwords ‘R1R3’ and ‘R2R4’ respectively.

Task 4.3: Enabling BFD for BGP.

Enable BFD on the iBGP session between R3 and R4.

Specify 1 second as the minimum transmit and receive interval for failure detection and 5 lost consecutive hellos before declaring down the session.

Task 4.4: BGP Route Injection and AS Path Manipulation.

Inject prefixes 11.11.11.0/24 and 22.22.22.0/24 into BGP within their respective AS according to the diagram.

Make sure AS 65560 and AS 65565 see each other’s prefixes through BGP. Don’t enable OSPF on the links connecting the ASes.

Tune R4 to prevent the 65555 AS number from being added to the AS path when prefixes are sent to AS 65565.

Tune R4 to prevent the 65444 AS number from being added to the AS path of prefixes sent to AS 65560.

Task 4.5: Destination-based Remote-Triggered Blackhole (RTBH) Filtering

Setup destination-based RTBH filtering in AS 65555.

The protected resource is the R1 address 11.11.11.11/24 and the attack is coming from subnet 22.22.22.22/24, a subnet that is configured on the R2 router.

Use R5 as a signaling router and 6.6.6.0/24 as a prefix that is not used in the network.

Task 4.6: Source-based RTBH Filtering

Setup source-based RTBH filtering in AS 65555.

The protected resource is the R1 address 11.11.11.11/24 and the attack is coming from subnet 22.22.22.22/24, a subnet that is configured on the R2 router.

Use R5 as a signaling router and 6.6.6.0/24 as a prefix that is not used in the network. Activate strict uRPF on the R4 interface that connect the router to R2.

45 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
45
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 4: BGP

Part 2. BGP Policies Initial configuration: Part 2

WORKBOOK – version 1.1 (2016) JNCIE-SP workbook: Chapter 4: BGP Part 2. BGP Policies Initial configuration:
46 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
46
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 4: BGP

Task 4.8: BGP Prefix Propagation and BGP Multipath.

Configure eBGP sessions between AS65555 and its uplink ISP routers: R1 and R2.

Configure eBGP sessions between AS65555 and its customers: R6 and R7. Also make sure that customer prefixes from the diagram are propagated to AS65666.

In AS 65007, enable load-balancing across its two external eBGP connections.

Task 4.9: BGP Prefix Filtering.

In AS65555, do not accept prefixes from customers R6 and R7 with a mask length greater than /24.

Clear any communities that may be attached to customer prefixes received from AS65006 and AS65007.

Prevent the announcement of specific customer prefixes to any other AS. Achieve this through the use of communities.

Task 4.10: BGP Prefix Origination and Filtering

In AS 65555, configure and advertise 1 prefix that summarizes all customer prefixes (from AS 65006 and 65007) and advertise that prefix to AS 65666.

As an additional security measure, configure AS65666 so that it only accepts prefixes originated in AS65555.

Task 4.11: BGP Conditional Route Advertising

Have the AS 65666 routers announce their loopback IP addresses to AS65555

Make AS 65555 announce a default route to AS 65006 and 65007.

To prevent traffic black holing, modify the configuration so that the default route will not be announced when the two /32 routes that originated in AS65666 disappear from the routing tables.

Task 4.12: BGP Attributes Manipulation

Fix the configuration of AS65555 so that R1 and R2 announce their /32 prefixes through both iBGP and eBGP.

Configure AS 65555 so that outgoing traffic to AS 65666 is sent via R3 and all incoming traffic from AS 65666 enters the AS via R4.

Don’t use AS Path manipulation for this task.

Task 4.13: BGP Scaling

Reconfigure AS 65555 from a full-mesh iBGP to a setup wherein R5 serves as a route reflector and R3 and R4 are its clients.

47 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
47
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 4: BGP

Part 3. IPv6 Tunneling

Initial configurations: Part 3

BGP Part 3. IPv6 Tunneling Initial configurations: Part 3 Task 4.14: IPv6 Tunneling through IPv4/MPLS Cloud

Task 4.14: IPv6 Tunneling through IPv4/MPLS Cloud

Setup BGP sessions across the IPv6 links between R1-R3 and R2-R4.

Enable the exchange of IPv6 traffic between R1 and R2 (IPv6-only routers) across the IPv4 MPLS infrastructure (R3, R4, R5).

You should be able to send pings between the R1 and R2 loopbacks.

48 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
48
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 5: VPNs

Chapter 5: VPNs

Introduction:

By leveraging their MPLS infrastructure, most of today’s SP networks are able to support different types of VPNs. VPN traffic for different customers and services is switched across a common MPLS infrastructure by making use of 2 labels, a bottom label and a top label.

The bottom (or inner) label is sometimes called the VRF label. This label defines the VPN membership of the packet. An ingress PE pushes this label onto packets on ingress so that an egress PE router knows what VPN to associate the traffic with.

Another label, the top (or outer) label, is also pushed onto packets by an ingress PE. This label is used by MPLS routers to forward traffic towards the correct MPLS router. For VPN traffic, this means that the top label corresponds to the egress PE router.

The routers in between the PE routers, if any, are the P routers. These routers only look at the top label, switching traffic towards the destination PE router. The P routers have no knowledge of any VPN or customer routing information. Exchanging routing information with the customer and propagating customer routing information across the SP network is strictly the PE routers’ responsibility.

To exchange this customer routing information across the SP network, a modified version of the BGP protocol is used. This Multi-Protocol BGP (MP-BGP) is used to exchange customer prefix information for L3VPNs across the SP network. The two most important concepts that are added in this MP-BGP prefix exchange are the Route-Distinguisher (RD) and the Route- Target (RT).

The SP network can serve as a common infrastructure to many L3VPNs and all of the customers using an L3VPN can use their own IP space. This is possible because routing information for every customer is made unique. This is done by prepending a RD to every customer prefix. To exchange these routes, the “inet-vpn unicast” address family has to be enabled for BGP sessions between the PE routers.

The second important concept in L3VPNs is the RT. The RT is an extended BGP community that defines VPN membership. PE routers attach these RT communities when routing- information is exported to other PE routers. On import, the remote PE router uses the RT to determine in which VPN routing table the received prefixes should be installed.

In L3VPNs, the PE routers are involved in customer routing. Between the PE and the CE, the following routing protocols are supported: OSPF, RIP and BGP. It is also possible to use static routes on the PE routers involved in with VPN.

Different routing-protocols come with different caveats. For example, with BGP, a customer may be inclined to use the same AS everywhere. In this case, it is mandatory for the SP to change the default BGP loop prevention mechanism. This can be done by modifying the AS- path and/or by looping the SP AS several times.

48

49 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
49
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 5: VPNs

The most interesting L3VPN scenario is a hub-and-spoke VPN. In this scenario, any inter- spoke traffic must be forwarded through the hub site first. This is achieved by using different RTs for the hub and spoke sites and by selectively importing and exporting these RTs. The hub sites imports routes with the spoke RT and exports routes with the hub RT. The spoke sites only import routes with the hub RT and export routes with the spoke RT.

Do’s and Dont’s

If there are no restrictions, use an IP-address-based route distinguisher value. This can save time during troubleshooting.

In hub-and-spoke scenarios, consider the default loop-prevention mechanisms and modify them as needed.

When using VPN route reflectors that are placed out of the forwarding path, make sure that the BGP next-hops are resolved in inet.3, else the RR will not accept the routes.

To make an OSPF sham link more preferable over a legacy OSPF backbone, it may be necessary to tune OSPF metrics on the interfaces of the CE devices.

50 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
50
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 5: VPNs

Part 1. L3VPN Initial configuration: Part 1

LABS WORKBOOK – version 1.1 (2016) JNCIE-SP workbook: Chapter 5: VPNs Part 1. L3VPN Initial configuration:
51 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
51
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 5: VPNs

Task 5.1: L3VPN with BGP as PE-CE protocol

Configure VPN B using the interfaces and addresses from the diagram.

Use BGP as PE-CE routing protocol.

Modify configuration so that PE routers receive only the VPNv4 prefixes that have locally configured route-targets.

RDs and RTs can be any values of your choice.

Task 5.2: L3VPN transparency.

Reconfigure VPN B from the previous task in such a way so that AS 65555 is not added to the AS Path after prefix exchange between sites.

Task 5.3: Hub and Spoke VPN (BGP-based)

Configure VPN A as a hub and spoke VPN using the interfaces and addresses from the diagram.

Use BGP as PE-CE routing protocol.

Make sure CE spokes (R1 and R2) communicate through central hub (R6) only.

RDs and RTs can be any values of your choice.

Task 5.4: VPN Route Leaking

Enable remote and local leaking of routes between VPN A and VPN B on R3. Perform local leaking using the auto-export feature.

Enable local leaking of routes between VPN A and VPN B on R4 using the RIB groups approach.

Task 5.5: VPN Internet Access

Provide Internet access for Site 1 of VPN B. Use the same interface for VPN and Internet traffic and assume that the VPN B addresses are public.

Restrict internet access for the IP address of the R7 loopback only. Don’t use firewall filters for this.

52 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
52
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 5: VPNs

Part 2. L3VPN PE-CE OSPF Initial configurations: Part 2

– version 1.1 (2016) JNCIE-SP workbook: Chapter 5: VPNs Part 2. L3VPN PE-CE OSPF Initial configurations:
53 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
53
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 5: VPNs

Task 5.6: OSPF Sham Link

Configure VPN B between R7 and R8 using OSPF as PE-CE protocol.

Make sure that the L3VPN is the primary path between R7 and R8 and that the legacy OSPF backbone is used for backup purposes only.

Task 5.7: Hub and Spoke L3VPN (OSPF)

Configure VPN A as a hub and spoke VPN using OSPF as PE-CE protocol.

Make sure that the CE spokes (R1 and R2) can communicate through the central site only.

RDs and RTs can be any values of your choice.

54 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
54
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 5: VPNs

Part 3. L3VPN

Initial configurations: L3VPN part3

WORKBOOK – version 1.1 (2016) JNCIE-SP workbook: Chapter 5: VPNs Part 3. L3VPN Initial configurations: L3VPN
55 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
55
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 5: VPNs

5.8: BGP based Hub and spoke VPN with 1 interface

Configure VPNA in AS65001, use BGP as a routing protocol.

Make VPNA-S1 act as the hub site and connect it to the SP network using only 1 interface.

Spoke sites should receive a default route, not the routes towards the other spokes.

Make the PE routers peer with the out-of-path route-reflector and do not enable the route-reflector for MPLS.

5.9: BGP based MPLS VPN and 6VPE

Configure VPNB in AS65500, use BGP as a routing protocol.

Use IPv4 BGP sessions between the CE and PE and use that session to exchange IPv4 and IPv6 prefix information.

Make sure all sites can reach both the IPv4 and IPv6 addresses that are advertised by the CEs.

Make sure that VPNB-S1 is the preferred link for IPv4 traffic and that VPNB-S2 is the preferred link for IPv6 traffic.

On R3, configure one set of LSPs that carry only IPv4 traffic and another set of LSPs that carry only IPv6 traffic towards R1, R2 and R4.

5 .10: Inter provider VPN option B

Configure an EBGP session with the ISP router and connect both VPNA as well as VPNB to AS64098 on R4.

For VPNA, the other ISP is using target:64098:1 and for VPNB, the other ISP is using

target:64098:2.

56 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
56
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 6: Layer 2 VPN

Chapter 6: Layer 2 VPN

Introduction:

Same as with MPLS layer 3 VPNs, an MPLS layer 2 VPN uses 2 labels. The bottom or inner label (VRF label) encapsulates the packet that is send from one site to another. This label defines the VPN membership. The second label is the outer or top label. This label is used to tunnel the VPN traffic across the backbone to the egress PE. The JNCIE-SP exam covers four types of layer 2 VPNs. These are the following:

LDP based layer 2 circuit:

Covered in RFC 4447, the LDP Layer 2 Circuit allows for connectivity between dissimilar media. An LDP layer 2 circuit is always a point-to-point connection between two devices and both of these devices have to be configured manually. The LDP based layer 2 circuit is the only layer 2 VPN that is not configured within a routing-instance. Martini style encapsulation is used, this goes for the other three layer 2 VPNs as well.

BGP signaled L2VPN :

The BGP Layer 2 VPN (L2VPN) is also referred to as the Kompella-draft. It can be used to provide for connectivity between dissimilar media. The L2VPN connections are always point- to-point. L2VPN connections are signaled by the PE routers using MP-BGP.The fact that PE routers use BGP to signal VPN membership is a quality often described as auto-discovery. Similar mechanics used in MPLS L3VPNs (route-target, route-distinguisher, vrf) are used for L2VPN as well.

57 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
57
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 6: Layer 2 VPN

BGP signaled VPLS :

Defined in RFC 4761, VPLS connections are signaled using MP-BGP. VPLS uses the same address family as an L2VPN. This allows for auto-discovery of PE VPN membership. Similar mechanics used in MPLS L3VPNs (route-target, route-distinguisher, vrf) are used for BGP signaled VPLS as well.

There are two key differences between a VPLS and an L2VPN. The first is that a VPLS is an Ethernet-only VPN and an L2VPN is not. The second is that a VPLS allows for point-to- multipoint connections and an L2VPN does not. A VPLS connects CE devices together in a way a common L2 switch would.

LDP signaled VPLS:

Defined in RFC 4762, the VachKompella VPLS uses LDP to signal connections. As opposed to the BGP signaled VPLS, an LDP signaled VPLS does not offer any auto-discovery. This means that each VPN member has to be specified on every PE involved in the VPLS. The LDP signaled VPLS is configured in a routing-instance. Since BGP is not used to signal the VPLS, there is no need for a route-distinguisher or a route-target. A unique VPLS ID has to be defined for each VPLS.

Do’s and don’ts :

- When LDP is used as a signaling protocol, make sure that the loopback interface is configured in the [protocols ldp] stanza

- some encapsulations (vlan-ccc, vlan-vpls) only work for a certain vlan-range

- the forwarding behavior is configured on the interfaces. Be sure to specify the proper encapsulation on the physical interface level as well as on the logical unit level.

- BGP signaled L2VPNs and both flavors of VPLS require a routing-instance

- route-reflectors will only reflect the routes that it can resolve

- IP-address-based route-distinguisher values can save time during configuration and troubleshooting

58 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
58
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 6: Layer 2 VPN

Initial configuration: L2VPN start

LABS WORKBOOK – version 1.1 (2016) JNCIE-SP workbook: Chapter 6: Layer 2 VPN Initial configuration: L2VPN
59 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
59
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 6: Layer 2 VPN

Task 6.1: Kompella L2VPN (VC Type 5)

Configure a Kompella L2VPN (VC Type 5) between R1 and R7.

Use interface ge-0/0/1 on all PE routers.

Task 6.2: Martini L2VPN

Remove the VPN configuration from the previous task.

Configure a VPN for VLAN 10 between R1 and R7.

Use interface ge-0/0/1 on all PE routers.

Use LDP as a signaling protocol.

Task 6.3: Kompella L2VPN (VC Type 4)

Configure vpn ‘circuit-b’ for VLAN 11 between R1 and R7.

Use interface ge-0/0/1 on all PE routers.

Use BGP as a signaling protocol.

Use VC-type 4.

Task 6.4: Basic LDP-based VPLS

Configure VPLS ‘vpn-a’ on all PE routers for vlan 50.

Use interface ge-0/0/1 on all PE routers.

Use LDP as a signaling protocol.

Task 6.5: LDP-based VPLS and multihoming

Configure VPLS ‘vpn-b’ on all PE routers for vlan 60.

Use interface ge-0/0/1 on all PE routers.

Use LDP as a signaling protocol.

One of the locations is multihomed to R5 and R7.

Make sure that R7 is the backup connection and R5 is the primary connection.

Task 6.6: Basic BGP signaled VPLS

Configure VPLS ‘vpn-c’ on all PE routers for VLAN 70.

Use interface ge-0/0/1 on all PE routers.

Use BGP as a signaling protocol.

60 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
60
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 6: Layer 2 VPN

Task 6.7: BGP signaled VPLS with a multihomed site

Configure VPLS ‘vpn-d’ on all PE routers for VLAN 80.

Use interface ge-0/0/1 on all PE routers.

Use BGP as a signaling protocol.

The site connected to R5 and R7 is multihomed.

The R5 connection to the VPLS should be the primary connection.

Task 6.8: BGP signaled VPLS features

Configure VPLS ‘vpn-e’ on all PE routers for VLAN 90.

Use interface ge-0/0/1 on all PE routers.

Use BGP as a signaling protocol.

Make sure that all BUM traffic is subjected to a 10K policer.

Configure the lowest MAC limit possible on all sites except for the site connected to R7. There, the MAC limit should be 100.

If a MAC limit is crossed anywhere, the packet should be dropped.

Task 6.9: BGP signaled VPLS and VLAN normalization

Configure VPLS ‘vpn-f’ on R1 and on R5.

Use interface ge-0/0/2 on all PE routers.

Use BGP as a signaling protocol.

On R1, the customer is using VLAN 513.

On R5, the customer is using VLAN 514.

Normalize the VLAN through routing-instance configuration.

Task 6.10:BGP signaled VPLS and VLAN normalization

Configure VPLS ‘vpn-g’ on R1 and R5.

Use interface ge-0/0/2 on all PE routers.

Use BGP as a signaling protocol.

On R1, the customer is using VLAN 700.

On R5, the customer is using VLAN 600.

Normalize the VLAN to 520 through interface configuration.

Task 6.11: BGP signaled VPLS feature

Configure an additional interface in 'vpn-g' on R1.

On R1, use interface ge-0/0/1 and VLAN 520.

Make sure that only the newly configured interface is active.

61 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
61
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 6: Layer 2 VPN

Task 6.12: Stitching together an L2VPN and a VPLS

Configure VPLS ‘vpn-h’ on R1, R3 and R5.

Use interface ge-0/0/1 on all PE routers.

Use BGP as a signaling protocol.

Also configure a BGP based L2VPN, ‘vpn-h-stitched-l2vpn’ between R5 and R7.

Stitch these Layer 2 VPNs together into a single layer 2 broadcast domain.

Task 6.13: VPLS and BUM replication with P2MP LSP

Make sure that the R5 PE distributes BUM traffic towards the other PE routers for ‘vpn-h’.

Do this by using an RSVP-signaled P2MP tunnel.

62 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
62
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 7: Multicast VPN

Chapter 7: Multicast VPN

Introduction:

There are two implementations that enable multicast transmission for MPLS VPNs; these are the draft-Rosen and the Next-Generation Multicast VPNs (NG MVPN) implementations.

In the draft-Rosen model, a PE router has to be a part of the customer PIM domain and a separate instance of PIM must be run in the SP network. Any PIM signaling or customer multicast traffic traversing the backbone is encapsulated in multicast GRE tunnels. The main drawback of this traditional approach is the limited scalability. Draft-Rosen used to be the only possibility until P2MP LSPs were adopted for transport purposes.

The NG MVPN approach replaces PIM in the core. The approach uses MP-BGP for signaling and the MPLS infrastructure for forwarding. This removes the need to use multicast GRE tunnels that are used in draft Rosen. Seven new NLRI types were introduced to support NG MVPN. These new NLRIs carry the information and attributes needed to build and support the "tunnels" across the MPLS infrastructure. As with draft-Rosen, the PE routers still need to be part of the customer PIM domains. The PE routers can also, optionally, serve as the customer RP(s).

Like other MPLS VPN services, packet transmission occurs by using two labels: the top label is used as the packet traverses the core, the bottom label is used to define VPN membership. NG MVPN uses a special type of LSP called Point-To-Multipoint LSP (P2MP), which is an LSP that is suitable for multicast packet delivery. Both LDP and RSVP can be used to create P2MP LSPs. Traffic protection mechanisms like FRR and Link Protection can be used for RSVP signaled LSPs as well as for RSVP signaled P2MP LSPs.

In NG MVPN, two different provider tunnels can be used for multicast traffic delivery. The simplest one is the Inclusive P-tunnel. With this tunnel, an inclusive tree (I-PMSI) is built once on a per-MVPN basis. Using I-PMSI, multicast traffic from the ingress PE will be send to all the other PEs. This is regardless of whether or not there are any receivers requesting multicast traffic (similar to the default MDT in draft Rosen).

This can be undesirable if only a few PEs in the MVPN have subscribers that are interested in the multicast traffic. In such cases, the other type of provider tunnel called Selective P- tunnel (S-PMSI) can be used. With this approach, a selective tree is build and the PE will be able to send multicast traffic to interested receivers only. In other words, only those receivers that specifically send IGMP joins will receive multicast traffic (more or less similar to the DATA MDT in Draft Rosen).

63 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
63
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 7: Multicast VPN

PE routers work as converters for signaling multicast state between PIM and MP-BGP in both directions. When the source starts broadcasting to a multicast group, it sends PIM register messages to the RP (often, this role is performed by a PE router). This PE then announces the active source, using a Type 5 MVPN NLRI, to all other PEs. PIM register messages on remote PEs are converted to Type 7 NLRIs and sent towards the PE with an active source. After building the multicast forwarding tree, multicast traffic will start to flow from the source to the receivers.

Do’s and Dont’s

Make sure that MP-BGP sessions support and negotiate the additional MVPN address family.

Don’t forget to enable PIM on CE-facing interfaces within the L3VPN routing-instance and specify the customer RP address when using PIM sparse-mode.

Make sure that multiple operations (MPLS pop, RPF check etc.) can be performed on egress packets. This can be achieved by activating the “vrf-table-label” VPN option.

Pay attention to the task requirements for MVPN sites (sender/receiver only) because by default, a site is enabled as a sender and a receiver site.

64 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
64
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 7: Multicast VPN

Part 1:

Initial configuration: MULTICAST part 1

– version 1.1 (2016) JNCIE-SP workbook: Chapter 7: Multicast VPN Part 1: Initial configuration : MULTICAST
65 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
65
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 7: Multicast VPN

Lab introduction:

The R6 router is functioning as a multicast source in this lab. No multicast configuration has to be performed on this router in any of the tasks. At the end of each task, you can verify the lab by having the R6 router send multicast traffic to the multicast group address 239.0.0.1.

R1 and R5 are configured to send join messages for group 239.0.0.1. Additionally, they will also reply to multicast traffic, making it easy for you to test your configuration.

At the end of each task, you can verify the configuration by sending a multicast ping from R6 to the multicast addresses that R1 and R5 are willing to join. To verify the configuration tasks, you can issue the following command on the R6 router:

ping bypass-routing interface ge-0/0/4.14 ttl 10 239.0.0.1

All routers are using the ge-0/0/0 interface as their out-of-band management interface. Treat these interfaces as though they are the management, or fxp0 interfaces, of the routers in the lab.

The lab exercises may require configuration on any of the routers except for R6.

66 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
66
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 7: Multicast VPN

Task 7.1: Configuring PIM with auto-rp

Configure all routers for PIM.

Configure R3 to be the RP, use the 10.0.0.255 address.

Use the auto-rp mechanism.

Task 7.2: PIM filtering

Filter incoming join messages for group 224.2.127.254 on R2.

Filter outgoing join messages for group 224.2.127.254 on R5.

Task 7.3: Configuring PIM with BSR

Reconfigure R3 and have the router announce the RP using the BSR mechanism.

Configure R8 to announce itself as an RP as well. Use the 10.0.0.254 address and the BSR mechanism.

Make sure R3 will be the active RP.

Use PIM SM everywhere.

Task 7.4: Configuring PIM with a static RP

Configure R3 to be the RP using the 10.0.0.255 address.

Use static RP configuration.

Task 7.5: Configuring PIM with any-cast RP

Configure R3 and R8 to be the RP.

Use the any-cast RP mechanism.

Use the MSDP protocol.

Use 10.0.0.255 as the RP address.

Task 7.6: Configuring PIM with any-cast RP

Change the any-cast RP mechanism into the PIM any-cast mechanism.

67 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
67
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 7: Multicast VPN

Part 2:

Initial configuration: MULTICAST part 2

VPN Part 2: Initial configuration : MULTICAST part 2 Task 7.7: Configure an MVPN part 1:

Task 7.7: Configure an MVPN part 1: configuring P-PIM

Configure PIM for the core.

Use the PIM anycast RP mechanism.

Configure R7 and R8 to be the RP, use 172.16.1.254 as the RP address.

Task 7.8: Configure an MVPN part 2: configuring C-PIM

Configure PIM for the customer using VPN c1.

Use the PIM BSR RP mechanism.

Configure R4 to be the RP for the customer, using address 10.4.4.4.

Task 7.9: Configure an NG MVPN part 1

Enable PIM-SM on al CE-facing interfaces for VPN c2.

Configure R4 to be the RP using address 10.4.4.4.

Task 7.10: Configure an NG MVPN part 2

Configure a NG MVPN for customer 2.

For the NG MVPN, use a P2MP LDP inclusive provider tunnel.

Setup the MVPN to operate in RPT-SPT mode.

Task 7.11: Configure an NG MVPN part 3

Reconfigure the provider tunnel to be RSVP-based.

67

68 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
68
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 7: Multicast VPN

Set the bandwidth of the P2MP LSP to 10m.

Specify the R2 and R6 sites as receivers and the R4 site as sender only.

69 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
69
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 8: Class of Service

Chapter 8: Class of Service

Introduction:

In today’s SP environment, numerous applications are using the same packet switched network. These applications and/or protocols are very different in nature and they have to share a common SP IP/MPLS infrastructure.

Applications can be very severely impacted by packet loss, delay and/or jitter. Because of this, QoS can be very important to an SP. A set of QoS mechanisms can be used to give preferential treatment to sensitive applications and/or protocols. To be able to use the different QoS mechanisms on Juniper devices, we use the class of service configuration.

The first CoS processing task that is performed on every router in the network is input traffic classification. By distributing packets in different virtual containers called Forwarding Classes (FC), we define the order in which packets leave the router at a later stage. Packet classification is performed by means of a BA classifier or multi-field (MF) classifier which is applied on an input interface. A BA classifier examines the headers of incoming packet and defines the Forwarding Class of a packet. This can be based on the value of any of the following fields: DSCP, EXP, IP Precedence and 802.1p. You can also define one more locally significant parameter called Packet Loss Priority (PLP) for a packet. There are 4 possible values: high, medium-high, medium-low and low. PLP only comes into play during times of congestion. The PLP defines which packets will be dropped first – these are packets with high PLP and so on.

By default, a BA classifier called ipprec-compatibility, is applied to every logical interface configured. This can be changed by configuring another BA classifier. MF classifiers can use numerous firewall filter parameters as match criteria. These MF classifiers are commonly used on edge devices or on customer-facing interfaces. They can also perform the assignment of packets into different Forwarding Classes and they can also set PLP values. MF classifiers are processed after BA classifiers, and can be used to overwrite any previous classifications.

Policing is a mechanism that can be used to limit the amount of traffic (mostly incoming) for a configured bandwidth value. Policing uses a token bucket algorithm which allows for traffic bursts as long as there are enough tokens in the bucket. Tokens are accumulated during physical interface silence and spent when the interface transmits packets at wire speed. Policers can be set to a hard-limit, which means that out-of-profile traffic is dropped. You can also configure soft-limit Policers. When a soft-limit Policer is used, out-of-profile traffic is assigned to a different (or worse) forwarding class and it is given a higher PLP.

70 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
70
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 8: Class of Service

Before transit traffic is sent through the fabric, it can be subjected to class-based forwarding. This mechanism changes the way in which the outgoing interface is identified. Instead of a traditional destination IP lookup, the router uses class-to-next-hop mappings to forward traffic destined to a configured prefix. By using this approach, you can push traffic across a more "reliable" and "faster" path.

Schedulers define how outgoing interface queues will be serviced. Every physical interface has 4 or 8 hardware queues that are mapped to forwarding classes. Every scheduler has a priority, interface bandwidth and buffer size configured. Each queue is serviced on a round- robin basis (from the highest priority to the lowest) according to its configured weight. That means that every Forwarding Class has a guaranteed rate (CIR) while unallocated bandwidth can be shared equally between other queues. You can also reference drop profiles in the JUNOS scheduler configuration, which can be used to enable the TCP congestion avoidance mechanism called WRED.

As packets leave the interface of the device, the rewrite rule is the last mechanism applied during CoS processing. The rewrite rule can be used to set/ change different CoS field values according to the packet’s forwarding class and PLP. By default, only an MPLS EXP rewrite- rule is applied to MPLS-enabled interfaces while logical IP interfaces don’t have any.

71 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
71
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 8: Class of Service

Do’s and Dont’s

Keep in mind that forwarding class and/or loss priority can be set at several places:

BA classifiers, ingress policer, MF classifier (and they are processed in this order). This makes it possible to overwrite values in different stages.

Don’t forget to add last a term to a firewall filter when using it for MF classification, otherwise any unmatched traffic will be dropped (implicit discard rule).

To provide end-to-end QoS, apply input MF classifiers on all input or CE-facing interfaces on every PE.

When configuring custom BA classifiers and/or rewrite-rules, which differ from the JUNOS defaults, it’s common to use the default values as template with the keyword “import” and then override only corresponding entries that need to be changed.

Checking the result of your CoS configuration can be done by examining the interface counters. These can be shown by issuing commands such as “show interfaces extensive” or “show interfaces queue”. Another method can be the use of counters in firewall filters. During your testing, consider the use of the “rapid” option for the “ping” command when sending ICMP echoes.

If you plan to invoke a policer several times in the configuration and want it to have a “shared” limitation, use the appropriate keywords. The options are: physical- interface-policer, logical-interface-policer and filter-specific. By using them in the policer configuration, only one policer instance per specified entity will be created.

When appropriate, use the “rate-limit” option or “transmit-rate” command while configuring schedulers with strict-high priority. This prevents the highest priority queue from starving other queues. This is because by default, there is no upper limit on the bandwidth that can be used by this queue.

When configuring CBF with L3VPN, keep in mind that you have to match against records in the bgp.l3vpn.0 table. This is why it's important to use specific match criteria like protocol bgp, family inet-vpn and/or community value with CBF configurations.

By default, traffic which is flowing across LSPs is not policed. Configure and apply a firewall filter with a policer attached to it or consider using the auto-policing feature for this.

72 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
72
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 8: Class of Service

Initial configuration: CoS-start

LABS WORKBOOK – version 1.1 (2016) JNCIE-SP workbook: Chapter 8: Class of Service Initial configuration: CoS-start
73 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
73
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 8: Class of Service

Task 8.1: Multi-field classification

Configure R3 so that ICMP packets originated from R1 lo0 and ge-0/0/4.13 interface IP addresses are assigned to the forwarding classes “gold” and “silver”.

Configure R4 so that ICMP packets originated from R2 lo0 and the ge-0/0/4.24 interface IP addresses are assigned to the forwarding classes “gold” and “silver”.

Use queue 1 and queue 2 to process traffic of these forwarding classes.

Task 8.2: BA classification

Configure a custom MPLS EXP-based BA classifier using a default classifier as a template.

Assign forwarding classes “gold” and “silver” and also “low” and “high” PLP to packets with EXP values of 101 and 010 respectively.

Apply this BA on the appropriate router interfaces.

Task 8.3: Policing

Configure a single-rate soft policer on R3 and invoke it twice in the firewall filter that is already applied to interface ge-0/0/4.13.

Use the lowest bandwidth-limit and burst size possible. Make sure that this is a total limit for both gold and silver classes.

Out-of-profile traffic should be mapped to the “best-effort” forwarding class.

Task 8.4: Scheduling

Assign the following priorities to the schedulers: scheduler for best-effort traffic – low, gold traffic – high, silver – medium-high, network-control – medium-low.

Assign 20% of the interface bandwidth to the scheduler that processes “gold” traffic. Assign 10% to the “silver” and 10% to the “network-control” scheduler. Assign the remaining bandwidth to best-effort traffic. Use the same values for the buffer-size parameter.

Configure the scheduler map and apply it to the appropriate interfaces.

74 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
74
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Chapter 8: Class of Service

Task 8.5: WRED drop profiles

Configure an interpolated aggressive drop profile. When the buffer is at 50% utilization, the drop probability should be 75%. When the buffer utilization is 75%, the drop probability should be 95%.

Configure an interpolated non-aggressive drop profile. When the buffer is at 50% utilization, the drop probability should be 30%. When the buffer utilization is 75%, the drop probability should be 50%.

Apply these profiles to the “silver” scheduler. Apply the drop profiles to any traffic with high and low PLPs respectively.

Task 8.6: Rewrite rules

Configure a custom EXP-based rewrite rule using the default one as a template.

Assign EXP values 101 and 010 to packets from forwarding classes “gold” with low PLP and “silver” with “high” PLP.

Apply this rewrite rule on the appropriate router interfaces to support end-to-end QoS for customer transit traffic.

Task 8.7: Class-based forwarding (CBF)

Configure R3 so that “gold” traffic is forwarded across the RSVP LSP named “R3-R4”. The “silver” traffic should be forwarded across the RSVP LSP named “R3-R5-R4”.

This CBF should only be valid for traffic that is destined to IP address 2.2.2.2.

Task 8.8: LSP policing

Configure a hard-limit policer on R3 with a bandwidth-limit of 50Kb/s and burst-size of 15Kbytes. Apply it on ingress for the RSVP LSPs “R3-R4” and “R3-R5-R4”.

75 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
75
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Full day lab challenge

Full day lab challenge

GE-0/0/4.460 GE-0/0/5.78 AS 5678 BGP VPLS-2 AS 1516 VPNA-S1 BGP AS? VPNC-S1 VPNA-H BGP U1
GE-0/0/4.460
GE-0/0/5.78
AS 5678
BGP
VPLS-2
AS 1516
VPNA-S1
BGP
AS?
VPNC-S1
VPNA-H
BGP
U1
U2
AS 3456
C2
GE-0/0/4.56
GE-0/0/4.35
P1
GE-0/0/4.542
GE-0/0/4.400
GE-0/0/4.532
VPNB-1
GE-0/0/4.200
GE-0/0/4.13
GE-0/0/4.37
SRX1
SRX3
SRX7
OSPF Area 0
GE-0/0/4.822
IS-IS L1
IS-IS L2
SRX8
RIP
RIP
SRX5
GE-0/0/4.49
GE-0/0/4.220
GE-0/0/4.14
C1
GE-0/0/4.24
GE-0/0/4.46
SRX2
SRX4
SRX6
GE-0/0/4.200
BGP
AS 65020
GE-0/0/4.450
RR
VPLS-1
GE-0/0/4.833
VPNC-S2
VPNA-S2
VPNB-2
U3
BGP
GE-0/0/4.603
AS 43.356
GE-0/0/4.57
GE-0/0/4.45
GE-0/0/4.230
GE-0/0/4.23
GE-0/0/3.522
GE-0/0/4.69
GE-0/0/4.68
GE-0/0/4.604
GE-0/0/4.532
GE-0/0/1
GE-0/0/2
GE-0/0/4.310
GE-0/0/4.601
GE-0/0/4.67
GE-0/0/4.320
GE-0/0/4.602
GE-0/0/4.522

Physical topology diagram

76 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
76
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Full day lab challenge

172.16.220.0/30 172.16.46.0/30 172.30.1.8/30 AS 5678 BGP VLAN 532 VPLS-2 AS 1516 VPNA-S1 BGP AS? IPv4
172.16.220.0/30
172.16.46.0/30
172.30.1.8/30
AS 5678
BGP
VLAN 532
VPLS-2
AS 1516
VPNA-S1
BGP
AS?
IPv4
VPNC-S1
VPNA-H
.2
BGP
U1
U2
172.30.0.40/30
.1
AS 3456
.2
.2
VLAN 542
172.30.0.28/30
C2
IPv4
.1
.2
IPv6
P1
172.16.40.0/30
.1
.1
.1
.1
.2
.2
.1
.2
.1
.2
172.30.0.0/29
.25
172.30.0.24/30
.26
VPNB-1
SRX1
SRX3
SRX7
.9
.1
.29
.46
.2
.9
.14
OSPF Area 0
172.30.0.48/30
IS-IS L1
.2
.21
.45
.30
.1
172.30.0.8/30
.10
IS-IS L2
172.16.45.0/30
SRX8
RIP
RIP
SRX5
.6
.1
.34
.41
.22
.13
.1
.5
.10
.2
.33
.42
.2
.17
.18
C1
SRX2
SRX4
SRX6
172.30.0.16/30
.37
172.30.0.36/30
.38
IPv4
.53
192.168.83.0/30
.49
.1
BGP
.1
.1
.1
AS 65020
192.168.63.0/30
.50
RR
.54
VPLS-1
.2
.2
.2
.2
IPv4
VPNC-S2
VPNA-S2
VPNB-2
IPv6
U3
lo0.0
BGP
172.30.30.6/32
::172.30.30.6/128
AS 43.356
172.30.0.44/30
172.30.0.32/30
172.16.230.0/30
172.30.0.12/30
192.168.82.0/30
VLAN 522
192.168.64.0/30
172.30.0.52/30
172.30.1.4/30
172.30.80.0/24
VLAN 532
172.30.0.20/30
fd17:172:16:231::/64
172.16.231.0/30
192.168.61.0/30
172.30.1.0/30
172.16.232.0/30
192.168.62.0/30
fd17:172:16:232::/64
522LANV
77 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
77
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Full day lab challenge

L3 address topology diagram

78 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
78
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Full day lab challenge

Lab introduction:

Load the initial configuration on all devices using the files provided with this INETZERO workbook. You are allowed to perform configuration changes only on devices SRX1 to SRX8 and the RR. To verify the results of your work, you can use operational commands on the VR device.

You can use username lab with password lab123 to access all the devices. Please, do not change the password for users lab and root !

To load the initial configuration on all the devices, issue the ‘ load override terminal’ command

[edit] lab@srx1# load override terminal [Type ^D at a new line to end input]

79 iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)
79
iNET ZERO – JNCIE-SP TECHNOLOGY LABS WORKBOOK – version 1.1 (2016)

JNCIE-SP workbook: Full day lab challenge

Part 1: System Features

Task 1.1: Services configuration

Make sure that only SSH and Telnet service are enabled for remote management. Configure only SSHv2 to be a