jncie-sp v1.1 walkthrough guide (2017) - inetzero
TRANSCRIPT
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
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:37.416246 ERROR: IIH from 1720.3000.5005 without matching
addresses, interface ge-0/0/4.145
Jun 29 14:27:37.416691 Notification not sent due to 5-second throttle
as per rfc4444: isisRejectedAdjacency
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
Jun 29 14:27:45.462672 ERROR: IIH from 1720.3000.5005 without matching
addresses, interface ge-0/0/4.145
Jun 29 14:27:45.463302 Notification not sent due to 5-second throttle
as per rfc4444: isisRejectedAdjacency
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: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:37.416246 ERROR: IIH from 1720.3000.5005 without matching
addresses, interface ge-0/0/4.145
Jun 29 14:27:37.416691 Notification not sent due to 5-second throttle
as per rfc4444: isisRejectedAdjacency
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
Jun 29 14:27:45.462672 ERROR: IIH from 1720.3000.5005 without matching
addresses, interface ge-0/0/4.145
Jun 29 14:27:45.463302 Notification not sent due to 5-second throttle
as per rfc4444: isisRejectedAdjacency
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.890898 max area 0, circuit type l1
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)
Jul 8 21:16:26.891700 restart RR reset RA reset holdtime 0
Jul 8 21:16:26.891814 packet length 75
[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.780840 max area 0, circuit type l2
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.781980 restart RR reset RA reset holdtime 0
Jul 8 21:24:08.782106 packet length 85
Jul 8 21:24:08.782213 Sending PTP IIH on ge-0/0/4.167
Jul 8 21:24:08.782300 max area 0, circuit type l2
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
Address Interface Label space ID Hold time
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
Address Interface Label space ID Hold time
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
Input label database, 172.30.5.1:0--172.30.5.4:0
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
Output label database, 172.30.5.1:0--172.30.5.4: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
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]
lab@Sun# run show ldp database
Input label database, 172.30.5.1:0--172.30.5.2:0
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
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
Input label database, 172.30.5.1:0--172.30.5.4:0
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
Output label database, 172.30.5.1:0--172.30.5.4: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
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)
+ = Active Route, - = Last Active, * = Both
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.
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
Verify the result of the policy.
[edit]
lab@Sun# run show ldp database
Input label database, 172.30.5.1:0--172.30.5.2:0
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
Output label database, 172.30.5.1:0--172.30.5.2:0
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
Input label database, 172.30.5.1:0--172.30.5.4:0
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
Output label database, 172.30.5.1:0--172.30.5.4:0
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
Input label database, 172.30.5.4:0--172.30.5.1:0
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
Output label database, 172.30.5.4:0--172.30.5.1:0
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
Input label database, 172.30.5.4:0--172.30.5.3:0
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
Output label database, 172.30.5.4:0--172.30.5.3:0
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
Input label database, 172.30.5.4:0--172.30.5.1:0
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
Output label database, 172.30.5.4:0--172.30.5.1:0
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
Input label database, 172.30.5.4:0--172.30.5.3:0
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
Output label database, 172.30.5.4:0--172.30.5.3:0
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)
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
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
bgp.l3vpn.0: 34 destinations, 34 routes (34 active, 0 holddown, 0 hidden)
* 172.30.5.3:4:0.0.0.0/0 (1 entry, 1 announced)
BGP group P3-1 type External
Route Distinguisher: 172.30.5.3:4
VPN Label: 16
Nexthop: Self
Flags: Nexthop Change
AS path: [54591] I
Communities: target:43208:200
* 172.30.5.3:4:172.30.5.17/32 (1 entry, 1 announced)
BGP group P3-1 type External
Route Distinguisher: 172.30.5.3:4
VPN Label: 16
Nexthop: Self
Flags: Nexthop Change
AS path: [54591] I
Communities: target:43208:200
* 172.30.5.3:4:172.31.48.0/30 (1 entry, 1 announced)
BGP group P3-1 type External
Route Distinguisher: 172.30.5.3:4
VPN Label: 16
Nexthop: Self
Flags: Nexthop Change
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)
BGP group P3-1 type External
Route Distinguisher: 172.30.5.3:4
VPN Label: 16
Nexthop: Self
Flags: Nexthop Change
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
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)
Accepted
Route Distinguisher: 172.17.47.2:200
VPN Label: 299792
Nexthop: 192.168.0.6
AS path: 2831679853 64600 I
Communities: target:43208:200
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
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: 314208
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [54591] 2831679853 64600 I
Communities: target:54591:201
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)
+ = Active Route, - = Last Active, * = Both
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
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
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.
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