Sample
www.prote
us.ne
t
Copyright © 2011 Proteus Networks, All Rights Reserved
JNCIE-SP:Preparation Workbook
www.proteus.net
Sample
www.prote
us.ne
t
Proteus Press JNCIE-SP Workbook
ii
© 2011 by Proteus Networks, Inc.
All rights reserved.
Proteus Networks, the Proteus Networks logo,
are registered trademarks ofProteus Networks, Inc.
in the United States and other countries.
All other trademarks, service marks, registered
trademarks, or registered service marks are the property
of their respective owners.
Proteus Networks assumes no responsibility for any
inaccuracies in this document. Proteus Networks reserves
the right to change, modify, transfer, or otherwise revise
this publication without notice.
Published by Proteus Press
Authors: Peter V Southwick Joseph Soricelli
Technical Reviewers: John Hammond, Rick Schenderlein,
Editor in Chief: Peter Southwick
Copyeditor and Proofer: Shannon Wisdom
ISBN: 978-1-936779-28-4 (print)
Printed in the USA by Hill Associates Inc.
ISBN: 978-1-936779-29-1 (ebook)
Version History: v1 November 2011
This book is available at: www.Proteus.net/
Send your suggestions, comments, and critiques by email
Sample
www.prote
us.ne
t
Proteus Press JNCIE-SP Workbook
iii
!"#$% &' (&)*%)*+
Credits ........................................................................................................................................................... iv
Preface ........................................................................................................................................................... 2
Chapter 1 Administration and HA .............................................................................................................. 9
Chapter 2 Class of Service .......................................................................................................................... 31
Chapter 3 Interior Gateway Protocols ...................................................................................................... 51
Chapter 4 Internet Protocol Version 6 ...................................................................................................... 87
Chapter 5 Border Gateway Protocol ....................................................................................................... 103
Chapter 6 Multicast Protocols .................................................................................................................. 129
Chapter 7 Multiprotocol Label Switching ............................................................................................... 143
Chapter 8 Layer 3 VPNs ........................................................................................................................... 165
Chapter 9 Layer 2 VPNs ........................................................................................................................... 193
Chapter 10 Virtual Private LAN Service ................................................................................................ 211
Chapter 11 Multicast VPNs ...................................................................................................................... 223
Appendix A Chapter Practice Tests ......................................................................................................... 237
Appendix B Practice Exam ....................................................................................................................... 253
Appendix C Acronym List ........................................................................................................................ 267
Index ........................................................................................................................................................... 281
Sample
www.prote
us.ne
t
Proteus Press JNCIE-SP Workbook
iv
Credits
Authors Peter V Southwick
Peter V. Southwick For the past 35 years, Peter has been in telecommunications – designing, implementing and training on voice, data and security systems. He is a Proteus Networks professional services senior engineer specializing in the deployment of high end Juniper routers and service gateways. He has led deployments of SRXs, MXs and J-series routers for major enterprise and carrier customers. He is as also a veteran Juniper Networks Certified Instructor, and has developed multiple courses for the various Juniper product lines. Peter has Juniper Certifications to include: JNCIS-FWV, JNCIA-SSL, JNCIE-M/T, JNCIS-ER, JNCIP-SEC. Peter is a co-author for Junos Enterprise Routing 2nd Edition. In his free time Peter is an avid snow ski instructor, sailor and full time dad.
Joseph M. Soricelli
Joseph M. Soricelli (JNCIE #14, CCIE #4803) is the Chief Executive Officer of Proteus Networks. He joined Proteus in 2008 and has 20 years of experience in network design, network implementation, classroom instruction, and curriculum development. In his current position, he is responsible for the overall operations of the company while paying special attention to marketing and new product development. As an educator, Joe has trained hundreds of network engineers in various network technologies throughout his career. He is responsible for building and creating several training classes still in use by Juniper Networks today. He was also instrumental in the creation and maintenance of the Juniper Networks technical certification program. He is a prolific author and writer focused on high-end engineering and network topics. In addition to writing two certification study guides for the Juniper JNCIA-M and JNCIS-M certification levels, he has also presented multiple seminars and tutorials for the North America Network Operators Group (NANOG) meetings. He has also written technology white papers on topics including EIGRP, OSPF, BGP, MPLS, and VPNs.
Reviewers Rick Schenderlein
Rick Schenderlein is a senior network engineer and lead instructor at Proteus Networks. He is a retired network engineer from a major teleco. Rick is the lead certification guru for Proteus. All of his students LOVE him! Certifications: NCIE-M #157, JNCIE-ER #38, JNCI, CCIE #1042 (retired)
Sample
www.prote
us.ne
t
Proteus Press JNCIE-SP Workbook
v
John Hammond
John is a 20-year industry veteran. He held several positions including Education Services Engineer, Resident Engineer and System Engineer with Juniper Networks before joining Proteus. He has trained hundreds of network engineers in various network technologies and has created training classes in use by Juniper Networks today. He is a Juniper Networks Certified Internet Professional (JNCIP-M), and is also a Juniper Networks Certified Instructor (JNCI).
Technical Editor Shannon Wisdom
Shannon Wisdom is the managing technical editor for Hill Associates in Colchester, Vermont. As a freelance editor, she has edited Network Perimeter Security: Building Defense In-Depth, Auerbach Publications, 2003 and Fit Family, Vitesse Press, 2008. Her professional interests include technical editing and professional writing. For fun, she enjoys hanging out with her family and reading, powerlifting, skiing, snowshoeing, biking, and hiking.
Sample
www.prote
us.ne
t
Proteus Press JNCIE-SP Workbook
Chapter 1 Admin and HA 9
1 Administration and HA
This chapter looks at the tasks that could be covered in the JNCIE-SP exam that include the configuration of the device for administrative purposes and high availability. The topics covered include:
Administrative Tasks Login Syslog Annotating Configurations Scripting
High Availability Nonstop Active Routing Graceful Restart Virtual Router Redundancy Protocol
Sample
www.prote
us.ne
t
Proteus Press JNCIE-SP Workbook
Chapter 1 Admin and HA 10
Exam Objectives Covered The topics covered in this chapter prepare the participant to meet the exam objectives of:
Sample
www.prote
us.ne
t
Proteus Press JNCIE-SP Workbook
Chapter 1 Admin and HA 11
Administrative Tasks The administrative tasks show that a candidate can secure the devices and provide controlled access to the device. Most likely a candidate will be asked to perform these tasks on all routers.
This is a prime opportunity to use notepad to cut and paste between devices.
Login
The login stanza controls the user’s environment on the router. This is where solutions for the following types of test steps would be found:
1. Create a login user with view rights and limited configuration capabilities. 2. Create a login banner that notifies users of the owner of the router. 3. Add the tip of the day to the login. 4. Require that all passwords meet minimum standards.
The stanza has six subsections. The following paragraphs provide a short description of each.
system login announcement “place announcement here”;
The login announcement is text displayed to the user after the user has logged in to the system. This is typically used to provide information about procedures. If spaces are to be used in the announcement, the text must be bracketed by quotes (e.g., “Use commit comment and include the change notice number in the comment”).
The announcement shown upon login looks like:
Amnesiac (ttyd0) login: lab Password: --- JUNOS 10.4R1.9 built 2010-12-04 09:16:15 UTC Use commit comment and include the change notice number in the comment lab>
system login class custom_class_name
The login classes define the rights and permissions for users logging into the router. A set of predefined classes are typically used. In the exam the candidate might be asked to create a custom class with permissions that are defined as part of the task.
The class stanza has additional parameters that limit access to the router based on time of day and day of the week. These parameters are:
system login class
access-end <HH:MM>;
access-start <HH:MM>;
allowed-days [monday …..friday];
These commands use the system clock of the router. The days of the week are not shown in the CLI, but a look at the Unix prompt (% date) shows that the day of the week is displayed as well as the date and year.
Sample
www.prote
us.ne
t
Proteus Press JNCIE-SP Workbook
Chapter 1 Admin and HA 12
In this example, members of the class “test” are allowed to access the device between 8 AM and 8 PM, Monday through Friday.
[edit] lab# show system login class test allowed-days [ monday tuesday wednesday thursday friday ]; access-start "08:00:00 +0000"; access-end "20:00:00 +0000";
The principal purpose of this stanza is to permit or deny commands from the CLI. The permissions command permits wholesale commands to be used by the class members. The allow-commands, allow-configuration, deny-commands, and deny-configuration commands are used to modify the permissions stanza.
system login class
allow-commands “regular-expression”;
allow-configuration “regular expression 1” “regular expression 2”;
deny-commands “regular-expression”;
deny-configuration “regular expression 1” “regular expression 2”;
permissions [ permissions ];
If the same commands are allowed and denied, the allowed wins. If multiple commands are allowed or denied, they need to be separated by a |. The following configuration permits class members to use the show command for operational functions (via the permissions view) and adds the ping and traceroute commands to the mix.
[edit] lab# show system login class test permissions view; allow-commands "(ping)|(traceroute)";
Regular expressions can be used to further limit or expand the commands. The command string “s.*” would specify all commands that start with “s” (e.g., show, ssh, save). A full explanation of regular expressions is beyond the scope of the course but a few of the more common ones are:
| - The pipe symbol is a separator. Each term must be a complete, standalone expression enclosed in parentheses ( ), with no spaces between the pipe and the adjacent parentheses. For example, (show system alarms)|(show system software).
^ - Character at the beginning of an expression, used to denote where the command begins, and where there might be some ambiguity.
$ - Character at the end of a command. Used to denote where the command ends. For example, allow-command “show interfaces$” means that the user can issue the show interfaces command but cannot issue the show interfaces detail or show interfaces extensive command.
[ ] - Indicates a range of letters or digits. To separate the start and end of a range, use a hyphen ( - ).
( ) - Indicates a complete group of commands, each a standalone expression to be evaluated; the result is then evaluated as part of the overall expression. Parentheses must always be used in conjunction with pipe operators, as explained previously.
* - Zero or more terms.
+ - One or more terms.
. - Any character except for a space “ “.
The final two options on the class stanza are:
Sample
www.prote
us.ne
t
Proteus Press JNCIE-SP Workbook
Chapter 6 Multicast Protocols 132
All the other knobs for MLD are the same as those defined for IGMP and for IGMP interfaces.
It is not expected that IPv6 multicast is a required topic in the exam. However, the base configuration for MLD is shown below for an interface using the default features of MLD and accounting.
[edit] lab@JNCIE-R4# show | find pro protocols { mld { accounting; interface ge-0/0/0.0 { version 2; } } }
Once the host-to-router interface is completed the router-to-router interface must be created. This is the realm of the multicast routing protocols defined in the next section.
Multicast Routing Protocols What separates a broadcast from a multicast is the selective nature of the transmission. In a broadcast transmission every host is offered the content, where as in a multicast transmission only those hosts that request the content are offered it. This distinction has a great impact on the network resources. If a true broadcast transmission happened, then each and every segment of the network would see the transmission for the entire duration of the session. By pruning the network to only those segments that actually want the transmission, the network resources are spared this potentially high utilization. Pruning is performed by the network routers and is the responsibility of the multicast routing protocols.
Unlike the unicast routing protocols the primary function of the multicast routing protocols is to create a path from the destination back to the source of the traffic (i.e., a reverse path). The responsibility of IGPs is to create a path for traffic to the destination.
Multicast routing protocols operate between routers, using the group addresses requested by clients and the source IP addresses of the multicast servers to form a tree structure that connects all the clients to the servers. This is where solutions for the following types of test steps would be found:
1. Ensure that PIM is enabled on all core facing interfaces. 2. Ensure that EBGP peering to the customers can receive multicast NLRI. 3. Use Auto-RP to make router R3 an RP. 4. Use Bootstrap-RP to make routers R5 and R6 RPs. 5. Ensure that the RPs do not leak across transit EBGP boundaries. 6. Establish an MSDP peering between R4 and C1 and R7 and C2.
The multicast routing protocol of choice today is the Protocol Independent Multicast (PIM) protocol. While others are possible, PIM provides scalability and reliability in multicast networking. The Junos OS Multicast Protocols Configuration Guide in the techpubs section of the Juniper.net site has a full list of Junos-supported multicast routing protocols (along with full configurations and explanations).
Protocol Independent Multicast
Protocol Independent Multicast (PIM) supports three operational modes: sparse mode, dense mode, and sparse-dense mode. The difference among these modes is how the network is pruned for multicast traffic. In the dense mode a spanning tree is created with the root at the source of the traffic. Traffic is offered to all segments and pruned when segments do not have active users. Sparse mode identifies a rendezvous point (RP) that parses traffic to users wishing to receive the multicast source. It then prunes the path to the
Sample
www.prote
us.ne
t
Proteus Press JNCIE-SP Workbook
Chapter 6 Multicast Protocols 133
shortest between the destination(s) and the source using a shortest reverse path mechanism. Sparse-dense mode uses dense mode to find and communicate between rendezvous points, and uses sparse mode for multicast traffic.
The most common implementation of PIM is sparse mode. There are four methods of identifying RPs in sparse mode, static configuration, Anycast, Auto-RP and Bootstrap. Each of these mechanisms is defined in the following paragraphs.
Designated Router
In PIM-SM, traffic from a source is tunneled to the RP. The router interfacing the multicast source is considered the designated router and performs the tunneling of the multicast traffic in a unicast tunnel. If multiple routers are present, an election is performed to pick the designated router; the election can be predetermined by setting designated router (DR) priorities at the protocol PIM interface ge-0/0/0.0 priority commands.
The router that responds to IGMP messages from clients is also called a designated router.
The DR and the RP must have tunneling capabilities. For the M and T routers a tunnel services physical interface connector (PIC) is needed for the DR and the RP. For the MX the tunneling is configured by setting the tunnel services on a PIC:
[edit] lab@JNCIE-R4# show | find chass chassis { fpc 0 { pic 0 { tunnel-services; } } }
Basic PIM-SM Configuration
The basic PIM configuration runs PIM on all interfaces and sets the version to PIMv2 for the protocol and interfaces. It shows a static RP configuration for the devices and no filtering of traffic.
All routers in one subnet are required to run a single version of PIM. Junos defaults to either v1 or v2 depending on the operating mode. It is best practice to set the version as part of the base configuration.
The basic PIM configuration for the non-RP is:
[edit] lab@JNCIE-R4# show | find pro protocols { pim { rp { static { address 10.0.3.5 { version 2; } } } interface all { version 2; }
Sample
www.prote
us.ne
t
Proteus Press JNCIE-SP Workbook
Chapter 6 Multicast Protocols 134
interface fxp0.0 { disable; } } }
The basic configuration for the statically configured RP is:
[edit] lab@JNCIE-R5# show | find pro protocols { pim { rp { local { family inet { address 10.0.3.5; } } } interface all { version 2; } interface fxp0.0 { disable; } } }
Verify the proper operation of the system by using the operational commands:
lab@JNCIE-R4> show pim interfaces Instance: PIM.master Name Stat Mode IP V State NbrCnt JoinCnt(sg) JoinCnt(*g) DR address ge-0/0/0.0 Up Sparse 4 2 DR 1 0 1 172.16.0.22 lo0.0 Up Sparse 4 2 DR 0 0 0 10.0.3.4 ppe0.32769 Up Sparse 4 2 P2P 0 0 0 sp-0/0/0.0 Up Sparse 4 2 P2P 0 0 0 lab@JNCIE-R4> show pim neighbors Instance: PIM.master B = Bidirectional Capable, G = Generation Identifier, H = Hello Option Holdtime, L = Hello Option LAN Prune Delay, P = Hello Option DR Priority Interface IP V Mode Option Uptime Neighbor addr ge-0/0/0.0 4 2 HPLG 00:09:03 172.16.0.21 lab@JNCIE-R4> show pim rps Instance: PIM.master Address family INET RP address Type Holdtime Timeout Groups Group prefixes 10.0.3.5 static 0 None 1 224.0.0.0/4 Address family INET6 lab@JNCIE-R4> show pim join
Sample
www.prote
us.ne
t
Proteus Press JNCIE-SP Workbook
Chapter 9 Layer 2 VPNs 195
Layer 2 VPNs Layer 2 VPNs (L2VPN) are configured in a point-to-point fashion on an MPLS backbone. They offer Layer 2 transport for non-IP traffic over an IP infrastructure. They offer minimal translational support for IP-only traffic (e.g., in ATM- out Frame Relay). The configuration of L2VPNs depends on what flavor of L2VPN is required. The three L2VPNs are:
Draft-Kompella Layer 2 VPN – BGP-Based L2VPN – VPN signaling is performed using BGP. Transport is a stacked label MPLS (Martini tunnel).
Draft-Martini Layer 2 VPN – LDP-Based L2VPN – Signaling is performed by LDP and transport by Martini tunneling.
CCC-L2 Connection – Unidirectional LSP point-to-point connections over an MPLS network.
The following sections detail each of these technologies’ configurations and tuning opportunities.
BGP-Based L2VPN The BGP-based Kompella draft L2VPN is built in the same fashion as the L3VPNs covered in the last chapter. A BGP/MPLS backbone provides the signaling and transport for Layer 2 frames. This is where solutions for the following types of test steps would be found:
1. All VPNs will use BGP for signaling between PEs. 2. Ensure that VPNc can exchange non-IPv4 packets. 3. Ensure that VPNn uses auto-provisioning.
Topology and Basics Refer to the Border Gateway Protocol (BGP) chapter for the basics of BGP configuration. Shown here are the extras that are needed specifically for the internal operation of a Kompella BGP-based L2VPN. The same infrastructure defined for the L3VPN can be used for this L2VPN. In addition to the IPv4 and L3VPN NLRIs, an additional NLRI for L2VPN signaling is added.
The topology for this chapter focuses on two routers, R6 and R7, as PE routers. Each of these internal routers is connected to a CE router, C3 and C4 respectively. The topology and interface assignments are shown in Figure 9-9. There is a notable difference between this topology and the one used in the last chapter: the absence of addresses on the CE-PE links. These links are Layer 2 links and are transparent to routing. The next hop for C3 is C4 and vice versa. The MPLS network looks like an Ethernet link between these two routers. These links could be any layer 2 protocol Ethernet, Ethernet VLANs, Frame Relay, PPP, etc. For the purposes of this chapter and the exam, Ethernet interfaces are going to be used.
Sample
www.prote
us.ne
t
Proteus Press JNCIE-SP Workbook
Chapter 11 Multicast VPNs 225
Base Configuration and Topology Multicast VPNs (MVPN) provide the signaling and transport of customer multicast traffic over an L3VPN network. BGP provides the control plane functions and provider tunnels (P-tunnels) provide the data connectivity for multicast traffic. The Junos implementation for MVPN is based on the next generation MVPN IETF drafts. These automate the signaling and data plane operations to the extent that the configuration steps are minimized. This is where solutions for the following types of test steps would be found:
1. VPNc has a multicast source using 229.1.1.1. Ensure that the other sites of this VPN can receive this traffic.
2. VPNc has a rendezvous point (RP) that is contained in the VPNc networks.
Refer to the L3VPN and BGP chapters for the basics of the BGP configuration. MVPNs require an additional Network Layer Reachability Information (NLRI) for the multicast routes. This NLRI transports the auto-discovery messages and well as the multicast join messages over the BGP infrastructure.
The topology for this chapter focuses on two routers, R6 and R7, as PE routers. Each of these internal routers is connected to two CE routers: C1 and C2 to PE R6 and C3 and C4 to PE R7. The topology and interface assignments are shown in Figure 11-11. Router C1 is the RP for the Protocol Independent Multicast (PIM) network, and all the other customer routers have static entries for the RP. The customer routers C2, C3, and C4 are receiver routers for the multicast traffic. The multicast source uses multicast group address 239.1.2.3. For the purposes of the chapter all the receiver routers will have a permanent join for the group.
PE-R6 PE-R7
se-1/0/1Lo0.010.0.9.6
Lo0.010.0.9.7
10.0.8.8/30
10.0.8.0/30 se-1/0/1
se-1/0/0se-1/0/0.10.9
.2.1
Customer C1 Customer C4ge-0/0/0
t1-2/0/0
ge-0/0/3
ge-0/0/3
Lo0.010.1.3.1 Lo0.0
10.4.3.4
10.0.2.12/3010.0.2.0/30
Customer C2
t1-2/0/1
t1-2/0/1
Lo0.010.2.3.2
10.0.2.4/30
Customer C3
ge-0/0/2
ge-0/0/2
Lo0.010.3.3.3
10.0.2.8/30
Source 10.1.3.10/24
t1-2/0/0
ge-0/0/1
Receiver 10.2.3.10/24
ge-0/0/0
Receiver 10.3.3.10/24
ge-0/0/1
Receiver 10.4.3.10/24
.1 .5
.6
.2
.9
.10
.13
.14
.1 .1.1
.1
Figure 11-11. MVPN Topology
The base configuration for an MVPN is the same as that for an L3VPN: an IGP with traffic engineering, BGP with additional NLRI, RSVP for LSP generation, and MPLS on all interfaces.
OSPF with traffic engineering to allow the specification of constraint-based paths
RSVP LSPs for unicast traffic, can also be used to create the point-to-multipoint (P2MP) LSPs used for multicast traffic
Sample
www.prote
us.ne
t
Proteus Press JNCIE-SP Workbook
Appendix A Chapter Practice Tests 247
Chapter 8 L3VPN Practice Test The time limit for this test is 1 hours. The point assignment for this test is:10
This exam must be completed on the full network.
PE routers are R1, R2, R6, and R7. You may not establish a full mesh between these devices. Ensure that all PE use MPLS to talk to all other PEs. All VPNs will use BGP for signaling purposes. Ensure a minimum number of BGP sessions while providing reliability and survivability for links and
nodes. Configure your router to automatically assign route-distinguishers. Ensure that the site of origin is included in the routes for VPNa (R1, R2, R6) VPNa uses OSPF for route advertisement between the CEs and the PEs Ensure that a backdoor route between the CEs (CE1 and CE2) for VPNa is not preferred over the direct
VPN connection. VPNb is between R6 and R7 and uses EBGP for route advertisement between the CEs and the PEs. Ensure that routes received by the CEs for VPNb are not rejected due to path loops Customers at VPNa wishes to receive Internet access, ensure that all sites can send traffic to the
Internet. Ensure that all traffic from the Internet destined to the VPNa address (208.112.45.0/24) reaches its
destination.. Ensure that VPNd (R7 to T2) uses a single label for crossing AS boundaries. Use route target
target:65001:200 and OSPF between the CE and R7
Sample
www.prote
us.ne
t
Proteus Press JNCIE-SP Workbook
Appendix B Practice Exam 262
Multiprotocol Label Switching 1) Points 3 – Deploy a MPLS network that supports traffic engineering for LSPs.
2) Points 3 – Create a full mesh of paths between the PEs (R1, R2, R3, R4 and R7) with the following attributes.
Ingress Egress Attributes R1 R7 100 Mbps via R6 R2 R7 50 Mbps R3 R4 Via R1 and R2 not direct R7 R1 100 Mbps via R4
3) Points 3 – Tunnel LDP over the MPLS network between nodes R4 and R6.
4) Point 3 – Assure that all tunnels will recover from a node or a link failure.
Sample
www.prote
us.ne
t
Proteus Press JNCIE-SP Workbook
Index 281
Index
administrative tasks ........... 11
AFI ...................... 70, 72, 267
aggregated route .......... 92, 98
allow-commands ............... 12
Annotating ..................... 9, 19
announcement .................... 11
any source multicast ........ 232
Anycast ............ 133, 135, 136
archive ......................... 17, 18
AS path79, 98, 107, 108, 110, 111, 112, 115, 116, 118, 119, 122, 123, 169, 170, 171, 172, 174, 175, 176, 177, 178, 189, 201, 230, 233, 234
as-override122, 173, 174, 187
authentication15, 16, 27, 28, 55, 56, 68, 74, 75, 76, 77, 113, 149
autonomous system72, 103, 185
Auto-RP132, 133, 135, 136, 137, 138, 231
banner .......................... 11, 13
behavior aggregators38, 39, 40
BFD22, 68, 69, 74, 76, 79, 106, 113, 146, 268
Bootstrap132, 133, 135, 136, 137, 231, 245, 268
Bootstrap RP135, 136, 137, 231
CCC5, 195, 199, 203, 205, 206, 207, 208, 214, 217, 268
Circuit Cross-Connect ..... 205
class of service4, 31, 33, 34, 36, 38, 39, 41, 42, 44, 46, 48, 198, 241, 257
commit script ..................... 20
Commit Scripts .................. 20
complete sequence number ................................. 76, 79
Constrained Paths ............ 152
control word..................... 198
damping ................... 106, 117
dense mode .............. 132, 137
deny-commands ................. 12
designated router55, 73, 133, 219
domain-id ......... 179, 180, 181
drop profile42, 43, 44, 45, 257
drop profiles........... 43, 44, 45
EBGP110, 113, 114, 119, 122, 132, 185, 186, 187, 244, 245, 247, 269, 273
ERO151, 152, 153, 154, 155, 156, 157, 158, 159, 269
ethernet-ccc...... 197, 202, 206
event scripts ....................... 21
Event Scripts ................ 20, 21
exp field ........................... 144
EXP field ........................... 41
external border gateway protocol ........................ 113
family mpls72, 143, 144, 145, 202, 205, 206, 215
fast reroute . 22, 158, 159, 160
firewall filter ................ 34, 36
forwarding classes33, 36, 40, 42, 46, 47, 241, 257
fxp022, 23, 54, 56, 57, 58, 61, 62, 69, 104, 134, 136, 145, 167, 196, 240
graceful restart22, 58, 77, 113
Graceful Restart . 9, 24, 25, 26
Graceful Routing Engine Switchover .................... 22
GRES ..................... 22, 23, 24
IGMP129, 130, 131, 132, 133, 139, 270
independent-domain 176, 177
Intermediate System-Intermediate System 51, 70
Internet access58, 181, 182, 184, 185, 242, 247, 263
IPv64, 34, 38, 39, 70, 78, 85, 87, 89, 90, 91, 93, 95, 96, 97, 98, 104, 111, 112, 131, 132, 163, 243, 259
IS-IS2, 3, 4, 25, 51, 58, 70, 71, 72, 73, 74, 76, 77, 78, 79, 80, 81, 82, 83, 85, 91, 95, 96, 97, 104, 113, 150, 160, 242, 270, 271
ISO address ....................... 71
Juniper Networks Certification Program (JNCP). ........................... 2
Kompella .........................195
L2VPN5, 98, 193, 195, 196, 197, 198, 199, 200, 201, 202, 203, 205, 206, 213, 214, 228, 248, 271
L3VPN98, 163, 165, 166, 167, 168, 169, 170, 171, 172, 173, 189, 195, 197, 215, 223, 225, 226, 247, 271
Label Distribution Protocol 5, 141, 148, 160, 163
label switched path143, 146, 151
LDP5, 25, 78, 143, 146, 148, 149, 150, 160, 161, 163, 165, 167, 188, 193, 195,
Sample
www.prote
us.ne
t
Proteus Press JNCIE-SP Workbook
Index 282
201, 202, 204, 205, 226, 262, 272
ldp-tunneling ........... 161, 167
Link protection ........ 159, 160
local preference110, 112, 114, 117, 123
Login ....................... 9, 11, 15
login classes ................. 11, 18
Martini ..................... 195, 201
MED98, 107, 110, 111, 112, 113, 114, 116, 118, 121, 122, 123, 124, 172, 174, 175, 230, 233, 244, 272
mGRE .............. 226, 227, 231
MSDP132, 135, 228, 229, 245, 273
multicast addresses .. 129, 261
Multicast Listener Discovery ............. 129, 130, 131, 272
Multicast Source Discovery Protocol 135, 228, 229, 273
multifield classifier ............ 38
Multifield classifiers .......... 34
MVPN111, 223, 225, 226, 227, 228, 229, 230, 231, 232, 233, 234, 273
next-hop self .... 114, 116, 185
Next-Table ....................... 184
NLRI85, 91, 97, 106, 111, 112, 132, 165, 166, 168, 170, 171, 172, 195, 196, 200, 205, 213, 214, 225, 226, 230, 245, 273
Node Protection ............... 160
Nonstop Active Routing ..... 9, 22, 24
Non-stop routing ................ 22
NSAP ......................... 70, 273
NSR ..................... 22, 24, 273
op script ............................. 21
Open Shortest Path First ..... 4, 51, 53, 150, 163, 274
Operational Scripts ............ 21
OSPF4, 2, 4, 25, 51, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 66, 67, 68, 69, 70, 81, 82, 83, 93, 94, 97, 104, 113, 116, 129, 147, 149, 150, 155, 160, 163, 167, 172, 173, 178, 179, 180, 181, 183, 185, 186, 189, 193, 196, 213, 215, 219, 225, 227, 228, 242, 247, 258, 263, 274
OSPF3 ....... 85, 91, 93, 94, 95
overload59, 64, 66, 77, 80, 81
partial sequence number .... 76
password .......... 14, 16, 18, 27
PIM129, 130, 131, 132, 133, 134, 135, 137, 138, 139, 225, 227, 228, 229, 230, 231, 232, 233, 234, 245, 271, 274
policer .... 36, 37, 38, 144, 145
Proteus Elite......................... 2
Protocol Independent Multicast131, 132, 225, 231, 274
Q-in-Q ............................. 214
reference-bandwidth59, 64, 65, 81
regular expressions ...... 12, 18
remove-private ......... 124, 176
rendezvous point132, 225, 231
Resource Reservation Protocol57, 141, 145, 149, 150, 163
rewrite rules ........... 39, 41, 42
rib-group ........ 59, 66, 67, 184
route reflector103, 108, 109, 110, 111
route target169, 170, 171, 172, 197, 198, 215, 228, 247
route-distinguisher168, 169, 170, 171, 174, 175, 177, 180, 183, 185, 186, 197, 198, 200
routing engines ................. 20
routing instance26, 36, 66, 67, 165, 168, 170, 173, 179, 181, 184, 185, 197, 198, 200, 202, 206, 215, 216, 227, 229, 248, 264
scheduler-map ........ 44, 45, 46
schedulers .. 42, 43, 44, 45, 46
Scripting ........................ 9, 20
sham link ................. 179, 180
SLAAC ................ 89, 90, 276
SNMP20, 23, 146, 233, 256, 276
source-specific multicast .232
Stateless Address Auto-Configuration ... 85, 89, 276
static RPs .........................136
syslog ............... 16, 17, 18, 19
TPID ........................ 214, 277
traffic engineering57, 58, 59, 70, 77, 82, 146, 147, 148, 150, 152, 196, 201, 213, 225, 228, 262
virtual private LAN service 5, 197, 211
Virtual router redundancy protocol ......................... 22
Virtual Router Redundancy Protocol ......................... 26
Virtual Routing and Forwarding ..................165
VRRP22, 26, 27, 28, 135, 240, 256, 277