JNCIE-SP v1.1 Walkthrough guide (2017) - iNETZERO

JNCIE-SP v1.1 Walkthrough guide (2017) Demo workbook

Why this demo workbook?

This workbook is intended to give you an idea of what the

purched workbook looks like, and the way the original workbook

teaches you the curriculum.

Due to this, we hope you will understand that

some content will be covered.

If you have any questions, please don’t hesitate to contact me.

Jörg Buesink

[email protected]

Owner iNET ZERO

About the authors

About meIvan lives in East Europe country of Bulgaria. He has more than 10 years ex-

perience 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 Sys-

tems solutions and devices. Ivan worked on various international projects,

designing, securing and implementing MPLS/IP backbones for multinational

mobile operators. Ivan has the following certificates: JNCIE-SP#987, JN-

CIP-SEC and various Cisco certificates.

About meJö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 extensiveexperience in network implementation,

design and architecture and teached several networking classes.

CertificationsQuadruple JNCIE certified

(JNCIE-DC#007,JNCIE-ENT#21,JNCIE-SP#284 and JNCIE-SEC#30)

Triple CCIE #15032

(Routing/Switching, Service provider and Security),

Cisco CCDE#20110002 certified,

Huawei HCIE#2188 Routing and Switching.

General information

iNET ZERO Rack rental service

Did you know that this walkthrough guide can be used in combination with iNET ZERO’s JNCIE rack rental

service? For more information check: www.inetzero.com

Target audience

This walkthrough guide is developed for experienced network engineers who are preparing for the Juni-

per Networks JNCIE-SP lab exam. Although not required it is highly recommended that you have passed

the JNCIS-SP written exam. iNET ZERO’s JNCIE-SP walkthrough guide is targeted at JNCIS-SP/ JNCIP-SP

certified engineers who are studying for the JNCIE-SP certification and need a little bit of extra help. This

JNCIE-SP volume 1 walkthrough guide is a very detailed walkthrough of iNET ZERO’s JNCIE-SP volume 1

v1.1 workbook tasks, including additional theory sections and step-by-step explanations.

This walkthrough guide must be used in combination with iNET ZERO’s JNCIE-SP volume 1.1 workbook, as

it is an add-on product. This product will not be sold separately.

How to use this walkthrough guide

We recommend that you start your JNCIE lab preparation by completing the first 8 workbook 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 have performed the workbook 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 config-

ure the workbook chapter’s tasks without the need to look at the answers presented in this guide. 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, walkthrough guides or our JNCIE rack rent-

al. You can reach us at [email protected]. We love to hear from you regarding your study progress. Your

feedback regarding our products is also very appreciated!

Table of ContentsChapter One: General System Features

Task 1: Initial System Configuration

Task 2: SNMP Configuration.

Task 3: Firewall filters

Task 4: Interface Configuration.

Task 5: Scripting.

Chapter Two: IGP Configuration and Troubleshooting

Task 1: OSPF Troubleshooting

Task 2: IS-IS Troubleshooting

Task 3: IGP Rollout

Chapter Three: BGP and Routing policy

Task 1: IBGP and Confederation

Task Two: EBGP Configuration.

Task 3: Routing Policies

Task 4: IBGP and Route Reflection

Chapter Four: MPLS configuration

MPLS Overview

LDP Overview

Task 1: LDP Configuration

Task 2: RSVP Configuration

Task 3: RSVP Protection

Task 4: IPv6 tunneling with 6PE

Chapter Five: L3VPN Configuration

Task 1: L3VPN configuration

Task 2: Multicast in L3VPNs

Task 3: IPv6 Tunneling with 6VPE

Chapter Six: L2VPN and VPLS configuration

Task 1: L2VPN Configuration

Task 2: VPLS Configuration

Chapter Seven: Inter-provider VPN Configuration

Task 1: Inter-provider VPN Option B

Task 2: Inter-provider VPN Option C

Chapter Eight: Class of Service

Task 1: Forwarding Classes, Queues and Schedulers

Task 2: Classification, Policing and Marking

Chapter Nine: A Full Day Lab Challenge

Task 1: Initial System Configuration

Task 2: Building the network

Task 3: IGP Configuration

Task 4: BGP Configuration

Task 5: MPLS configuration

Task 6: VPN configuration

Task 7: Class of Service Configuration

Task 2: IS-IS Troubleshooting

In the previous step you saw that R3 has one established adjacency with R2, however according to Figure

5 and the loaded configuration it’s clear that there should also be two adjacencies, with R4 and R6.

Activating IS-IS traceoptions on R4 to collecting debug informations generated by the ISIS protocol.

[edit]

lab@Arcturus# set protocols isis traceoptions flag error detail

lab@Arcturus# set protocols isis traceoptions file isis-debug

[edit]

lab@Arcturus# commit

commit complete

Analyzing the output from the file.

lab@Arcturus# run show log isis-debug

Jun 29 14:27:28 trace_on: Tracing to “/var/log/isis-debug” started

Jun 29 14:27:30.315972 ERROR: IIH from 1720.3000.5005 without matching

addresses, interface ge-0/0/4.145

Jun 29 14:27:30.316452 Notification not sent due to 5-second throttle

as per rfc4444: isisRejectedAdjacency

Jun 29 14:27:33.902046 ERROR: IIH from Canopus with no matching areas,

interface ge-0/0/4.134

Jun 29 14:27:33.902458 local area 49.0002





Jun 29 14:27:40.973357 ERROR: IIH from Canopus with no matching areas, interface ge-0/0/4.134

Jun 29 14:27:40.973976 local area 49.0002





Configure the same traceoptions on R6.

[edit]

lab@Vega# set protocols isis traceoptions flag error detail

lab@Vega# set protocols isis traceoptions file isis-debug

[edit]

lab@Vega# commit

commit complete

Analyze the output from the file.

lab@Vega# run show log isis-debug

Jul 8 21:10:23.310252 ERROR: IIH from 1720.3000.5003 with no matching

areas, interface ge-0/0/4.136

Jul 8 21:10:23.310304 local area 49.0002

Jul 8 21:10:23.310421 area address 49.0001 (3 bytes)

It is obvious that R3 is configured with the Area ID 49.0001, but R4 and R6 with Area ID 49.0002. Accord-

ing to Figure 5 the adjacencies between R3 with R4 and R6 should be establish as Level 1 adjacencies. To

form a Level 1 adjacency the area IDs should match, as it was stated in the overview.

Change the Area ID with the rename command.

lab@Canopus# show interfaces lo0.0

family inet {

filter {

input protect-re;

}

address 172.30.5.3/32;

}

family iso {

address 49.0001.1720.3000.5003.00;

}

family inet6 {

address fd17:f0f4:f691:5::3/128;

}

[edit]

lab@Canopus# rename interface lo0.0 family iso address 49.0001.1720.3000.5003.00 to address

49.0002.1720.3000.5003.00

[edit]

lab@Canopus# commit

commit complete

Verify the adjacency table reveals that R3 has established adjacencies with R4 and R7.

[edit]

lab@Canopus# run show isis adjacency

Interface System L State Hold (secs) SNPA

ge-0/0/4.123 Sirius 2 Up 25

ge-0/0/4.134 Arcturus 1 Up 6 f8:c0:1:dc:31:84

ge-0/0/4.136 Vega 1 Up 7 f8:c0:1:dc:2c:4

a. R4 – R5 adjacency.

[edit]

lab@Arcturus# run show isis adjacencyInterface System L State Hold (secs) SNPA

ge-0/0/4.134 Canopus 1 Up 24 2c:21:72:cd:26:84

R4 has only one established adjacency, the one fixed in the previous step with R3.

Looking at the traceoptions file configured you can see the problem with the adjacency with R5 also.

lab@Arcturus# run show log isis-debug

Jun 29 14:27:28 trace_on: Tracing to “/var/log/isis-debug” started







Jun 29 14:27:33.902458 local area 49.0002







Jun 29 14:27:40.973976 local area 49.0002





There is an address mismatch on interface ge-0/0/4.145. Verify the interface configuration on both rout-

ers reveals the mistake.

[edit]

lab@Arcturus# show interface ge-0/0/4.145

description “R5 connection”;

vlan-id 145;

family inet {

address 172.30.0.29/30;

}

family iso;

family inet6;

[edit]

lab@A-Centauri# show interface ge-0/0/4.145

description “R4 connection”;

vlan-id 145;

family inet {

address 172.30.1.30/30;

}

family iso;

family inet6;

Indeed both interfaces are configured with IP addresses in different subnets. Let’s change the IP address

on R5 with command rename.

[edit]

lab@A-Centauri# edit interfaces ge-0/0/4.145

[edit interfaces ge-0/0/4 unit 145]

lab@A-Centauri# rename family inet address 172.30.1.30/30 to address 172.30.0.30/30

[edit interfaces ge-0/0/4 unit 145]

lab@A-Centauri# commit

commit complete

After this change, R4 has established an adjacency with R5 also.

[edit]

lab@Arcturus# run show isis adjacency

Interface System L State Hold (secs) SNPA

ge-0/0/4.134 Canopus 1 Up 23 2c:21:72:cd:26:84

ge-0/0/4.145 A-Centauri 1 Up 8 f8:c0:1:dd:3:84

b. R6 – R7 adjacency.

Activate traceoptions on R6 and R7 with the flag hello.

[edit]

lab@Vega# set protocols isis traceoptions file isis.log

[edit]

lab@Vega# set protocols isis traceoptions flag hello detail

[edit]

lab@Vega# commit

commit complete

[edit]

lab@Rigel# set protocols isis traceoptions file isis.log

[edit]

lab@Rigel# set protocols isis traceoptions flag hello detail

[edit]

lab@Rigel# commit

commit complete

Look at the debug info on both routers.

[edit]

lab@Vega# run show log isis.log

Jul 8 21:16:26 trace_on: Tracing to “/var/log/isis.log” started

Jul 8 21:16:26.889460 Sending L2 LAN IIH on ge-0/0/4.167

Jul 8 21:16:26.889576 max area 0, circuit type l2

Jul 8 21:16:26.889647 hold time 27, priority 64, circuit id Vega.00

Jul 8 21:16:26.889698 speaks IP

Jul 8 21:16:26.889780 speaks IPv6

Jul 8 21:16:26.890048 IP address 172.30.0.41

Jul 8 21:16:26.890419 IPv6 address fe80::fac0:100:a7dc:2c04

Jul 8 21:16:26.890546 area address 49.0001 (3)

Jul 8 21:16:26.890600 restart RR reset RA reset holdtime 0

Jul 8 21:16:26.890708 packet length 85

Jul 8 21:16:26.890831 Sending L1 LAN IIH on ge-0/0/4.136


Jul 8 21:16:26.890957 hold time 9, priority 64, circuit id Vega.02

Jul 8 21:16:26.891043 neighbor 2c:21:72:cd:26:84

Jul 8 21:16:26.891091 speaks IP

Jul 8 21:16:26.891151 speaks IPv6

Jul 8 21:16:26.891343 IP address 172.30.0.26

Jul 8 21:16:26.891647 area address 49.0001 (3)



[edit]

lab@Rigel# run show log isis.log

Jul 8 21:24:08 trace_on: Tracing to “/var/log/isis.log” started

Jul 8 21:24:08.780722 Sending PTP IIH on ge-0/0/4.178


Jul 8 21:24:08.780905 ptp adjacency tlv length 5

Jul 8 21:24:08.780956 neighbor state down

Jul 8 21:24:08.781037 our extended local circuit id 72

Jul 8 21:24:08.781089 speaks IP

Jul 8 21:24:08.781150 speaks IPv6

Jul 8 21:24:08.781422 IP address 172.30.0.45

Jul 8 21:24:08.781818 IPv6 address fe80::fac0:100:b2dc:3204

Jul 8 21:24:08.781925 area address 49.0002 (3)



Jul 8 21:24:08.782213 Sending PTP IIH on ge-0/0/4.167


Jul 8 21:24:08.782350 ptp adjacency tlv length 5

Jul 8 21:24:08.782413 neighbor state down

Chapter Four: MPLS configuration

This chapter contains tasks that require you to configure advanced transport LSPs

for the provider network.

MPLS Overview

Multiprotocol Protocol Label Switching (MPLS) uses labels to forward traffic through the network. The

concatenation of one hop labels define a Label Switched Paths (LSPs) through the network. This creates

a clean separation between the control and data plain and provides the ability to multiplex different

services over the network. The MPLS Shim header, which contains the label, is inserted between the

Layer 2 and Layer 3 headers when packets enters the MPLS network. Based on this label, the packet label

switched through the network. At egress point of the MPLS network this header is removed and the origi-

nal packet is forwarded to the destination in its native form.

The following terminology is used in MPLS networks:

• Label Switch Router (LSR) – every router in the MPLS network configured for MPLS

forwarding and participates in the creation of LSPs.

• Ingress LSR – the router where the packet enters the MPLS network. The packets

enter a LSP based on the destination. This is the head-end of the LSP. This router

performs push label operation.

• Transit LSR – this LSR forwards the labeled packet to the next hop of the LSP.

It performs a MPLS swap operation.

• Penultimate Hop – second last router. It is upstream to the egress router. By default JUNOS

pops the upper label in the stack on this router. If the label stack consists of just one label it is

popped at this LSR and a pure IP packet is send to the egress LSR. The egress LSR should

perform pure IP lookup to forward the packet to the next hop.

• Egress LSR – here the packets exits the LSP and MPLS network. This is the tail-end of the

LSP. This LSR performs a MPLS pop operation and forwards the packet based on an IP

forwarding lookup.

THe MPLS shim header is 32 bits. It consists of the following four fields:

• Label -20 bits containing the label of the packet. The field specifies to which LSP the packet

is assigned. It changes from hop to hop while the packet is transported through the network.

• Traffic Class Bits (TC) – 3 bits field used for quality of service. Previous these bits where

called EXP (experimental).

• Bottom of the stack – 1 bit field known as ‘S’ bit is used to indicated if more than one label

is used. MPLS supports the use of more than one label. If this bit is set to 1 it means that this

is the last label in the stack and an unlabeled packet is following.

• Time to live – 8 bits TTL field has the same function as with IP packets. It is used to drop the

packet when TTL value reaches 0.

...DEMO...

Enter this temporary vouchercode within 1 week to get

10% off your purchase! ( workbooks only ) Go to:

www.inetzero.com/product-category/juniper/service-provid-

er/jncie-sp-workbooks/

H2993DJAutomatically expires within one week of downloading this demo workbook

Task 1: LDP Configuration

1) Configure family mpls and enable the mpls protocol on the interfaces.

You have to configure LDP as shown in Figure 8. Not all interfaces are enabled for LDP. At a later stage

both LDP islands in the network will be connected with RSVP tunnels.

As with IS-IS you have to enable the interfaces to accept labeled packets.

[edit]

lab@Sun# set groups if-families interfaces ge-0/0/4 unit <*> family mpls

[edit]

lab@Sun# set groups if-families interfaces <ae*> unit <*> family mpls

An apply-group is already present and can be used to enable family mpls on all core interfaces.

Next the interfaces should be specified under the protocols mpls stanza. This way MPLS will know which

interfaces it can use to forward traffic. You can use the option all to add all interfaces with family mpls

support. If the device has a dedicated management interface (fxp0) it is good practices to disable it under

protocols mpls.

[edit]

lab@Sun# set protocols mpls interface all

[edit]

lab@Sun# commit

commit complete

This step is performed on all routers in the network.

Verify if the interfaces are enabled for MPLS.

[edit]

lab@Sun# run show mpls interface

Interface State Administrative groups (x: extended)

ae0.0 Up <none>

ge-0/0/4.114 Up <none>

ge-0/0/4.118 Up <none>

ge-0/0/4.206 Up <none>

Four interfaces on R1 are enabled for MPLS.

2) Configure LDP according Table 8.

Next you have to enable LDP as label distribution protocol according Figure 8. Some additional features

like authentication should be enabled on the sessions. Configurations are the same on all routers.

[edit]

lab@Sun# set protocols ldp interface ae0.0

[edit]

lab@Sun# set protocols ldp interface ge-0/0/4.114

Adding both interfaces to LDP protocol.

[edit]

lab@Sun# set protocols ldp session 172.30.5.2 authentication-key workbook

[edit]

lab@Sun# set protocols ldp session 172.30.5.4 authentication-key workbook

LDP authentication is configured for the transport session. Because a Router ID is configured, the ses-

sions are established using Loopback IP addresses.

[edit]

lab@Sun# set protocols ldp track-igp-metric

By default the LDP metric is 1, with a route preference of 9. If you configure this option it will instruct LDP

to use the IGP metric for the routes.

[edit]

lab@Sun# set protocols ldp explicit-null

[edit]

lab@Sun# commit

commit complete

The explicit-null knob forces LDP to not advertise label value 3 for FECs which this LSR is the egress node

for. LDP advertises a label value 0 (IPv4 explicit null) instead, which forces the penultimate-hop router to

not pop the upper label.

After committing and adding the necessary LDP configuration to all routers you can verify the LDP ses-

sions.

[edit]

lab@Sun# run show ldp neighbor

Address Interface Label space ID Hold time

172.30.0.2 ae0.0 172.30.5.2:0 13

172.30.0.6 ge-0/0/4.114 172.30.5.4:0 14

Execute the above command with the extensive option reveals more detail.

[edit]

lab@Sun# run show ldp neighbor extensive


172.30.0.2 ae0.0 172.30.5.2:0 11

Transport address: 172.30.5.2, Configuration sequence: 1

Up for 00:52:41

Reference count: 1

Hold time: 15, Proposed local/peer: 15/15

Hello flags: none

Neighbor types: discovered


172.30.0.6 ge-0/0/4.114 172.30.5.4:0 11

Transport address: 172.30.5.4, Configuration sequence: 1

Up for 00:35:40

Reference count: 1

Hold time: 15, Proposed local/peer: 15/15

Hello flags: none

Neighbor types: discovered

You can see the Transport address used for each session.

The LDP label database displays the label received and send to the neighbors.

[edit]

lab@Sun# run show ldp database

Input label database, 172.30.5.1:0--172.30.5.2:0

Label Prefix

299824 172.30.5.1/32

3 172.30.5.2/32

299840 172.30.5.3/32

299856 172.30.5.4/32

Output label database, 172.30.5.1:0--172.30.5.2:0

Label Prefix

0 172.30.5.1/32

299776 172.30.5.2/32

299792 172.30.5.3/32

299808 172.30.5.4/32


Label Prefix

299792 172.30.5.1/32

299808 172.30.5.2/32

299776 172.30.5.3/32

0 172.30.5.4/32


Label Prefix

0 172.30.5.1/32

299776 172.30.5.2/32

299792 172.30.5.3/32

299808 172.30.5.4/32

From the above output you can see the assigned labels for all Loopback IP addresses that are in the

network. Label 0 is advertised for the local routes because of the explicit-null configuration. Only R2’s

Loopback IP address is advertised with label value 3. Please note that this output is taken before the ldp

explicit-null command was enabled.

[edit]

lab@Sirius# show protocols ldp

track-igp-metric;

interface ge-0/0/4.123;

interface ae0.0;

session 172.30.5.1 {

authentication-key “$9$mT6AleWXNbEcrvLNY2mfT3/t”; ## SECRET-DATA

}

session 172.30.5.3 {

authentication-key “$9$wzgGi/9pOIcQF6A0IrlwYgJUH”; ## SECRET-DATA

}

Activating the explicit-null will instruct LDP on R2 to announce a label value 0 for its Loopback IP address/

FEC.

[edit]

lab@Sirius# set protocols ldp explicit-null

[edit]

lab@Sirius# commit

commit complete

Verify the LDP database on R1 again.

[edit]



Label Prefix

299776 172.30.5.1/32

0 172.30.5.2/32

299792 172.30.5.3/32

299808 172.30.5.4/32


Label Prefix

0 172.30.5.1/32

299776 172.30.5.2/32

299792 172.30.5.3/32

299808 172.30.5.4/32


Label Prefix

299792 172.30.5.1/32

299808 172.30.5.2/32

299776 172.30.5.3/32

0 172.30.5.4/32


Label Prefix

0 172.30.5.1/32

299776 172.30.5.2/32

299792 172.30.5.3/32

299808 172.30.5.4/32

By default, Label distribution protocols insert routes in the inet.3 table.

[edit]

lab@Sun# run show route table inet.3

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

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

172.30.5.2/32 *[LDP/9] 00:04:07, metric 5

> to 172.30.0.2 via ae0.0

172.30.5.3/32 *[LDP/9] 00:04:07, metric 15

> to 172.30.0.2 via ae0.0, Push 299840

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

> to 172.30.0.6 via ge-0/0/4.114, Push 0

Three LDP routes are present in the inet.3 table and the metric is taken from the IGP route. The label

operation and the labels for the LSP are also displayed. The output displayed is before the explicit-null

option was enabled on R2. This is the reason why for R2’s Loopback IP address no label will be pushed.

R2 sends label value 3 for its Loopback IP address. An Implicit Null label (3) is used for signaling purposes

only, no real label is attached. Like R2, R4 is also directly connected to R1, but has explicit-null enabled.

You can see that R1 will push label 0 for packets destined to R4 Loopback IP address. Packets destined

towards R3 Loopback IP address will be labeled with label value 299840 and send to R2. R2 will swap it

the incoming label value 299840 with outgoing label value 0 and sends it to R3.

Label information base / label switching table is stored in mpls.0 routing table.

[edit]

lab@Sun# run show route table mpls.0

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


0 *[MPLS/0] 02:55:28, metric 1

Receive

1 *[MPLS/0] 02:55:28, metric 1

Receive

2 *[MPLS/0] 02:55:28, metric 1

Receive

299776 *[LDP/9] 00:04:29, metric 1

> to 172.30.0.2 via ae0.0, Pop

299776(S=0) *[LDP/9] 00:04:29, metric 1

> to 172.30.0.2 via ae0.0, Pop

299792 *[LDP/9] 00:04:29, metric 1

> to 172.30.0.2 via ae0.0, Swap 299840

299808 *[LDP/9] 00:04:32, metric 1

> to 172.30.0.6 via ge-0/0/4.114, Swap 0

299808(S=0) *[LDP/9] 00:04:32, metric 1

> to 172.30.0.6 via ge-0/0/4.114, Pop

The first three labels are automatically added when you enable MPLS on the router. These are the IPv4

router Alert and IPv6 explicit null labels. The Incoming label 299792 will be swapped with label 299840

and send via interface ae0.0 to next-hop 172.30.0.2. The other two labels have entries with (S=0). This LSR

is the penultimate-hop router for these two label entries.

3) Configure IS-IS LDP synchronization.

This step requires to configure the LDP IGP synchronization feature. In this network ISIS is used as the

IGP. Enabling the synchronization feature ensures that LDP neighborsships must be fully established be-

fore IS-IS paths over the specified interface can be used. This feature avoids traffic black holing.

Enable LDP synchronization for IS-IS on all interfaces running LDP.

IS-IS configuration is applied to interfaces all from previous chapters. The exception are the interfaces to

IX on R1 and R2.

[edit]

lab@Sun# show protocols isis

reference-bandwidth 10g;

topologies ipv6-unicast;

level 2 disable;

level 1 {

authentication-key “$9$BpLElMg4ZDHmVw2aUH5TBIEyeW”; ## SECRET-DATA

authentication-type md5;

wide-metrics-only;

}

interface ge-0/0/5.300 {

passive;

}

interface all {

point-to-point;

bfd-liveness-detection {

minimum-interval 150;

multiplier 3;

}

}

Adding LDP synchronization only to the LDP enabled interfaces requires specific configuration for each in-

terface. Also add the other IS-IS configuration. In this particular case BFD and the ISIS interface type must

be set to point-to-point.

NOTE: LDP synchronization is only supported on point-to-point interfaces.

[edit]

lab@Sun# set protocols isis interface ge-0/0/4.114 point-to-point

[edit]

lab@Sun# set protocols isis interface ge-0/0/4.114 bfd-liveness-detection minimum-interval 150

[edit]

lab@Sun# set protocols isis interface ge-0/0/4.114 bfd-liveness-detection multiplier 3

[edit]

lab@Sun# set protocols isis interface ge-0/0/4.114 ldp-synchronization

[edit]

lab@Sun# set protocols isis interface ae0.0 point-to-point

[edit]

lab@Sun# set protocols isis interface ae0.0 bfd-liveness-detection minimum-interval 150

[edit]

lab@Sun# set protocols isis interface ae0.0 bfd-liveness-detection multiplier 3

[edit]

lab@Sun# set protocols isis interface ae0.0 ldp-synchronization

[edit]

lab@Sun# commit

commit complete

Display the IS-IS interface details.

[edit]

lab@Sun# run show isis interface ae0.0 extensive

IS-IS interface database:

ae0.0

Index: 69, State: 0x6, Circuit id: 0x1, Circuit type: 1

LSP interval: 100 ms, CSNP interval: 20 s, Loose Hello padding

Adjacency advertisement: Advertise

LDP sync state: in sync, for: 00:00:18, reason: LDP up during config

config holdtime: infinity

Level 1

Adjacencies: 1, Priority: 64, Metric: 5

Hello Interval: 9.000 s, Hold Time: 27 s

IPV6 UnicastMetric: 5

R1 is in Sync on interface ae0.0

4) Configure R1 and R2 to inject the IX facing subnet to LDP.

As it was stated in the overview, by default LDP only announces /32 routes Loopback IP addresses.

To accomplish this you have to use an LDP egress policy, where you will match the routes from inet.0 for

which you want to build LSP.

NOTE: LDP has a capability to filter label bindings between LDP neighbors. This can be achieved with

import and export policies. The difference is that with export policy you can control which label bindings

are advertised to a specific LDP neighbors, whereas with ingress policy you can specify which routes have

label bindings but not be considered as part of an LSP. You can have egress and export policy at the same

time.

Creating egress policy on R1 and R2.

[edit]

lab@Sun# set policy-options policy-statement ldp-routes term 1 from route-filter 192.168.1.0/24 exact

[edit]

lab@Sun# set policy-options policy-statement ldp-routes term 1 from route-filter 172.30.5.1/32 exact

[edit]

lab@Sun# set policy-options policy-statement ldp-routes term 1 then accept

[edit]

lab@Sun# set protocols ldp egress-policy ldp-routes

[edit]

lab@Sun# commit

commit complete

You have to include the Loopback IP address in the match statement of the policy, otherwise only the

direct subnet to IX will be advertised with a label.






Verify the result of the policy.

[edit]



Label Prefix

299968 172.30.5.1/32

0 172.30.5.2/32

299936 172.30.5.3/32

299952 172.30.5.4/32

0 192.168.1.0/24


Label Prefix

0 172.30.5.1/32

299824 172.30.5.2/32

299840 172.30.5.3/32

299856 172.30.5.4/32

0 192.168.1.0/24


Label Prefix

299840 172.30.5.1/32

299808 172.30.5.2/32

299776 172.30.5.3/32

0 172.30.5.4/32

299840 192.168.1.0/24


Label Prefix

0 172.30.5.1/32

299824 172.30.5.2/32

299840 172.30.5.3/32

299856 172.30.5.4/32

0 192.168.1.0/24

The direct subnet 192.168.1.0/24 is advertised as labeled to the LDP neighbors. Also the same route is

received with a label value 0 from R2 as well.

5) You have to make sure that each FEC advertised by R1 and R2 is reachable

by a separate LSP.

By default JUNOS advertises the same label for all prefixes with the same next hop and/or label adver-

tised from the next-hop router.

To change the default behavior you have configure all routers in the network with ldp deaggregate to

signal different labels for these prefixes. This helps with load-balancing of the MPLS packets.

Before we activate LDP deaggregate we first check the label advertised to R4.

[edit]

lab@Arcturus# run show ldp database


Label Prefix

0 172.30.5.1/32

299824 172.30.5.2/32

299840 172.30.5.3/32

299856 172.30.5.4/32

0 192.168.1.0/24


Label Prefix

299840 172.30.5.1/32

299808 172.30.5.2/32

299776 172.30.5.3/32

0 172.30.5.4/32

299840 192.168.1.0/24


Label Prefix

299824 172.30.5.1/32

299776 172.30.5.2/32

0 172.30.5.3/32

299808 172.30.5.4/32

299776 192.168.1.0/24


Label Prefix

299840 172.30.5.1/32

299808 172.30.5.2/32

299776 172.30.5.3/32

0 172.30.5.4/32

299840 192.168.1.0/24

You can see that R3 uses the same label for both prefixes advertised by R2 to R3.

Activate the LDP deaggregate feature on all routers in the network.

[edit]

lab@Sun# set protocols ldp deaggregate

[edit]

lab@Sun# commit

commit complete

Verify again the LDP database on R4.

[edit]

lab@Arcturus# run show ldp database


Label Prefix

0 172.30.5.1/32

299824 172.30.5.2/32

299840 172.30.5.3/32

299856 172.30.5.4/32

0 192.168.1.0/24


Label Prefix

299904 172.30.5.1/32

299872 172.30.5.2/32

299856 172.30.5.3/32

0 172.30.5.4/32

299888 192.168.1.0/24


Label Prefix

299872 172.30.5.1/32

299888 172.30.5.2/32

0 172.30.5.3/32

299856 172.30.5.4/32

299840 192.168.1.0/24


Label Prefix

299904 172.30.5.1/32

299872 172.30.5.2/32

299856 172.30.5.3/32

0 172.30.5.4/32

299888 192.168.1.0/24

After this change R3 is advertising a different label for the prefixes received from R2.

Chapter Seven: Inter-provider VPN Configuration

Inter-provider VPN overview

Task 1: Inter-provider VPN Option B

Customer C2 has a remote site attached the neighboring AS 43208.365. The requirement is to connect

that site to your AS with Inter-Provider VPN option B.

Neighbor P3-1 is the AS border router for AS 43208.365. It is connected to R3 in AS 54591. an EBGP ses-

sion with family inet-vpn unicast is needed between P3-1 and R3.

1) Configure family MPLS on the P3-1 facing interface on R3.

Traffic between both AS border routers will be label switched. On the AS borders, the transport label will

be popped, but the VPN label will flow between both ASs.

[edit]

lab@Canopus# set interfaces ge-0/0/5.302 family mpls

2) Configure the P3-1 facing interface under the protocols mpls stanza.

[edit]

lab@Canopus# set protocols mpls interface ge-0/0/5.302

3) Configure family inet-vpn unicast on P3-1 EBGP session.

[edit]

lab@Canopus# set protocols bgp group P3-1 family inet-vpn unicast

[edit]

lab@Canopus# commit

Verify the BGP session table.

[edit]

lab@Canopus# run show bgp summary

Groups: 5 Peers: 5 Down peers: 0

Table Tot Paths Act Paths Suppressed History Damp State

Pending

inet.0

546 518 0 0 0

0

bgp.l3vpn.0

22 21 0 0 0

0

inet6.0

48 48 0 0 0

0

bgp.l2vpn.0

6 6 0 0 0

0

Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn

State|#Active/Received/Accepted/Damped...

192.168.0.2 3521382357 129 428 0 0

22:50 Establ

inet.0: 69/97/69/0

192.168.0.6 2831679853 5 36 0 0

45 Establ

bgp.l3vpn.0: 2/3/2/0

fc09:c0:ffee::a 64601 52 100 0 0

22:38 Establ

C3.inet6.0: 8/8/8/0

fe80::223:9c01:2d8b:6c81 3521382357 52 60 0

0 22:27 Establ

inet6.0: 16/16/16/0

The bgp.l3vpn.0 routing table receives routes from neighbor R3, however family inet unicast is missing.

Remember that family inet unicast is enabled by default, but adding other families disables the default

behavior and family inet unicast must be enabled explicitly.

[edit]

lab@Canopus# set protocols bgp group P3-1 family inet unicast

[edit]

lab@Canopus# commit

commit complete

[edit]

lab@Canopus# run show bgp summary

Groups: 5 Peers: 5 Down peers: 0

Table Tot Paths Act Paths Suppressed History Damp State

Pending

inet.0

660 598 0 0 0

0

bgp.l3vpn.0

22 21 0 0 0

0

inet6.0

48 48 0 0 0

0

bgp.l2vpn.0

6 6 0 0 0

0

Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn

State|#Active/Received/Accepted/Damped...

192.168.0.2 3521382357 135 852 0 0

25:17 Establ

inet.0: 69/97/69/0

192.168.0.6 2831679853 92 431 0 0

15 Establ

inet.0: 82/116/82/0

bgp.l3vpn.0: 2/3/2/0

fc09:c0:ffee::a 64601 57 113 0 0

25:05 Establ

C3.inet6.0: 8/8/8/0

fe80::223:9c01:2d8b:6c81 3521382357 57 71 0

0 24:54 Establ

inet6.0: 16/16/16/0

4) Modify the BGP import policy for neighbor P3-1.

So far the policy is only taking the family inet unicast prefixes into account. Now you have to modify the

policy to also allow the family inet-vpn unicast prefixes.

lab@Canopus# show policy-options policy-statement P3-filter

term 1 {

from {

route-filter 0.0.0.0/0 prefix-length-range /8-/24;

}

then {

local-preference 200;

community set P3;

accept;

}

}

term 2 {

then reject;

}

See above how the current import policy looks. You have to restrict both existing terms only for family

inet. For security reasons only accept /32 prefixes from the strictly defined AS path.

[edit]

lab@Canopus# set policy-options policy-statement P3-filter term 1 from family inet

[edit]

lab@Canopus# rename policy-options policy-statement P3-filter term 2 to term 3

[edit]

lab@Canopus# rename policy-options policy-statement P3-filter term 1 to term 2

Renaming the existing rules, so that you can create new term 1 and inserts it before existing terms.

[edit]

lab@Canopus# set policy-options policy-statement P3-filter term 1 from protocol bgp

[edit]

lab@Canopus# set policy-options policy-statement P3-filter term 1 from route-filter 0/0 prefix-length-

range /32-/32

[edit]

lab@Canopus# set policy-options policy-statement P3-filter term 1 from as-path P3-local-routes

[edit]

lab@Canopus# set policy-options policy-statement P3-filter term 1 then accept

[edit]

lab@Canopus# insert policy-options policy-statement P3-filter term 1 before term 2

Insert the new term 1 before term 2 (old term 1).

[edit]

lab@Canopus# set policy-options as-path P3-local-routes “2831679853 64600”

Let’s verify the routes received from neighbor 192.168.0.6

[edit]

lab@Canopus# run show route received-protocol bgp 192.168.0.6 table bgp.l3vpn.0

bgp.l3vpn.0: 34 destinations, 34 routes (34 active, 0 holddown,

0 hidden)

Prefix Nexthop MED Lclpref AS

path

172.17.47.2:200:172.31.78.0/24

* 192.168.0.6

2831679853 64600 I

172.17.47.2:200:172.31.79.0/24

* 192.168.0.6

2831679853 64600 I

Two prefixes are received and accepted from neighbor P3-1 in the bgp.l3vpn.0 table.

Verify the normalization of the route targets.

[edit]

lab@Canopus# run show route advertising-protocol bgp 172.30.5.41 table bgp.l3vpn.0 extensive

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

* 172.17.47.2:200:172.31.78.0/24 (1 entry, 1 announced)

BGP group ibgp type Internal

Route Distinguisher: 172.17.47.2:200

VPN Label: 314128

Nexthop: Self

Flags: Nexthop Change

Localpref: 100

AS path: [54591] 2831679853 64600 I

Communities: target:54591:201

* 172.17.47.2:200:172.31.79.0/24 (1 entry, 1 announced)



VPN Label: 314128

Nexthop: Self


Localpref: 100

AS path: [54591] 2831679853 64600 I


The routes received from P3-1 and sent to the Route Reflector are normalized with the spoke site route

target.

[edit]

lab@Canopus# run show route advertising-protocol bgp 192.168.0.6 table bgp.l3vpn.0


* 172.30.5.3:4:0.0.0.0/0 (1 entry, 1 announced)

BGP group P3-1 type External


VPN Label: 16

Nexthop: Self


AS path: [54591] I


* 172.30.5.3:4:172.30.5.17/32 (1 entry, 1 announced)



VPN Label: 16

Nexthop: Self


AS path: [54591] I


* 172.30.5.3:4:172.31.48.0/30 (1 entry, 1 announced)



VPN Label: 16

Nexthop: Self


MED: 6

AS path: [54591] I

Communities: target:43208:200 rte-type:0.0.0.0:1:0

* 172.30.5.3:4:172.31.48.4/30 (1 entry, 1 announced)



VPN Label: 16

Nexthop: Self


MED: 2

AS path: [54591] I

Communities: target:43208:200 rte-type:0.0.0.0:1:0

--- (more) ---

The remote route target is replaced on the advertised routes to P3-1.

5) Verify the operation of the Inter-provider VPN - Option B.

The routes received from P3-1 are received with a VPN label of 299792.

[edit]

lab@Canopus# run show route received-protocol bgp 192.168.0.6 table bgp.l3vpn.0 extensive


* 172.17.47.2:200:172.31.78.0/24 (1 entry, 1 announced)

Accepted


VPN Label: 299792

Nexthop: 192.168.0.6

AS path: 2831679853 64600 I


Because the session is EBGP, the next-hop is changed. When the next-hop is changed the label will also

change.

Verify the label advertised to the route reflector.

[edit]

lab@Canopus# run show route advertising-protocol bgp 172.30.5.41 table bgp.l3vpn.0 extensive


* 172.17.47.2:200:172.31.78.0/24 (1 entry, 1 announced)



VPN Label: 314208

Nexthop: Self


Localpref: 100

AS path: [54591] 2831679853 64600 I


Label 314208 is advertised to the AS 54591 PE routers.

[edit]

lab@Canopus# run show route table mpls.0 label 314208

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


314208 *[VPN/170] 00:00:39

> to 192.168.0.6 via ge-0/0/5.302, Swap 299792

When traffic with VPN label 314208 arrives at R3 it is swapped with label 299792 and send to P3-1.

DEMO END950+ pages






This workbook was 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 or

distribute this workbook 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. Juniper (c), Juniper Networks

inc, JNCIE, JNCIP, JNCIS, JNCIA, Juniper Networks Certified Internet Expert, are registered

trademarks of Juniper Networks, Inc.

This original workbook helped over more than 340+ people achieve the expert certification

Unfortunately you have reached the end of this demo workbook.






Date post:	16-Mar-2022
Category:	Documents
Upload:	others
View:	26 times
Download:	0 times

JNCIE-SP v1.1 Walkthrough guide (2017) - iNETZERO

Documents