It is expected that a JNCIP candidate will be able to complete this case study in approximately one hour, with the result being an IS-IS IGP that exhibits no serious operational problems. Sample IS-IS configurations from all seven routers are provided at the end of the case study for comparison with your own configurations. Multiple solutions are sometimes possible, so differences between the provided examples and your own configurations do not always indicate that mistakes have been made. Because you are graded on the overall functionality of your IGP and its conformance to the specified configuration criteria, various operational mode commands are included so that you may compare the behavior of your network to a known good example.
To complete this case study, your IS-IS configuration must meet the following criteria:
-
lo0 addresses are reachable through IS-IS for all routers with an IS-IS SysID based on the lo0 address. Backbone router lo0 addresses must not be injected into area 49.0002 or 49.0001.
-
Backbone area routes must be summarized into area 49.0001.
-
The subnet between r3 and T1 must appear in area 49.0003 as an internal route. Ensure that no adjacencies can be established on this subnet.
-
Redistribute the 10.0.5/24 route into the backbone such that area 49.0002-attached routers see a metric of at least 100.
-
r5 and r6 must use a level 1 priority of 0.
-
Ensure that r7 never functions as a pseudonode when its adjacencies are up.
-
Summarize all routes (internal and external) into the backbone area.
-
You may not modify or view the OSPF router's configuration.
-
All areas must use hello authentication based on md5 with a secret of jnx. The backbone area must also authenticate LSPs using a simple password of jnx.
-
Configure r6 and r7 to advertise the IS-IS default route to the OSPF router. Ensure that the OSPF router can load balance over the default route.
-
Configure r6 and r7 to redistribute OSPF routes learned from the OSPF router into IS-IS.
-
Except for r5, ensure that no single router or link failure will isolate r1, r2, or the OSPF router.
-
Optimize routing based on bandwidth, and ensure that all Fast Ethernet interfaces are automatically assigned a metric of 5.
-
No static routes and no loops.
-
Set the level 1 preference in area 49.0001 to 155.
-
You must not have suboptimal routing between r6, r7, and the OSPF router.
-
Configure the network to keep LSPs that are up to 3600 seconds old.
In this case study, the OSPF router is preconfigured and its configuration cannot be modified or viewed. You may assume, however, that it is configured to run OSPF, and that it has the policy statements needed to redistribute the 192.168.0-3/24 static routes into OSPF should an adjacency be formed.
IS-IS Case Study Analysis
Each configuration requirement for the case study will now be matched to one or more valid router configurations and the commands that can be used to confirm that the router is operating within all specified case study guidelines. We begin with these four criteria, as they serve to establish baseline IS-IS operation in each area:
-
lo0 addresses are reachable through IS-IS for all routers with an IS-IS SysID based on the lo0 address. Backbone router lo0 addresses must not be injected into area 49.0002 or 49.0001.
-
Optimize routing based on bandwidth, and ensure that all Fast Ethernet interfaces are automatically assigned a metric of 5.
-
Configure the network to keep LSPs that are up to 3600 seconds old.
-
Only one adjacency is permitted between any two routers.
To get basic IS-IS connectivity going, you must add the iso family to the correct logical units on all IS-IS interfaces, assign the router's NET to its lo0 address, and correctly configure the interface to level associations so that no interfaces are running at both levels 1 and 2. The following captures show typical IS-IS configurations from key routers throughout the network, starting with r4:
[edit]
lab@r4# run show interfaces terse
Interface Admin Link Proto Local Remote
fe-0/0/0 up down
fe-0/0/1 up up
fe-0/0/1.0 up up inet 10.0.4.9/30
iso
. . .
so-0/1/0 up up
so-0/1/0.100 up up inet 10.0.2.6/30
iso
so-0/1/1 up up
so-0/1/1.0 up up soagg --> as0.0
so-0/1/2 up up
so-0/1/2.0 up up soagg --> as0.0
so-0/1/3 up down
as0 up up
as0.0 up up inet 10.0.2.10/30
iso
fxp0 up up
fxp0.0 up up inet 10.0.1.4/24
fxp1 up up
fxp1.0 up up tnp 4
lo0 up up
lo0.0 up up inet 10.0.3.4 --> 0/0
iso 49.0002.0100.0000.3004.00
. . .
The IS-IS routing instance for r4 is shown next:
[edit]
lab@r4# show protocols isis
reference-bandwidth 500m;
lsp-lifetime 3600;
interface fe-0/0/1.0 {
level 2 disable;
}
interface all {
level 1 disable;
}
r4ís configuration has the required iso family interface assignments, NET, and the correct
interface-to-level associations, which in this case was achieved by disabling level 1 on all inter-
faces with the exception of interface fe-0/0/1. Care must be taken to ensure that you do not con-
figure backbone router lo0 interfaces to operate at level 1 in order to meet the requirement that
backbone lo0 addresses are not to be injected into area 49.0002 or 49.0001. The automatic
metric requirement is achieved by assigning reference bandwidth of 500Mbps, and the default
LSP lifetime is set to 3600 seconds as required. Correct interface-to-level mapping and the auto-
matically calculated metric values are confirmed by displaying IS-IS interface status:
[edit]
lab@r4# run show isis interface
IS-IS interface database:
Interface L CirID Level 1 DR Level 2 DR L1/L2 Metric
as0.0 2 0x1 Disabled Point to Point 1/1
fe-0/0/1.0 1 0x2 r2.02 Disabled 5/5
lo0.0 0 0x1 Disabled Passive 0/0
so-0/1/0.100 2 0x1 Disabled Point to Point 3/3
The configuration of routers in level 1 areas will be similar to the example shown next, which
is taken from r7:
[edit]
lab@r7# run show interfaces terse
Interface Admin Link Proto Local Remote
fe-0/3/0 up up
fe-0/3/0.0 up up inet 10.0.8.2/30
iso
fe-0/3/1 up up
fe-0/3/1.0 up up inet 10.0.8.10/30
iso
. . .
lo0 up up
lo0.0 up up inet 10.0.9.7 --> 0/0
iso 49.0001.0100.0000.9007.00
. . .
The routing instance for a level 1 router r7 is configured as shown next:
[edit]
lab@r7# show protocols isis
reference-bandwidth 500m;
lsp-lifetime 3600;
interface all {
level 2 disable;
}
The correct interface-to-level mappings are now confirmed on r7:
[edit]
lab@r7# run show isis interface
IS-IS interface database:
Interface L CirID Level 1 DR Level 2 DR L1/L2 Metric
fe-0/3/0.0 1 0x2 r7.02 Disabled 5/5
fe-0/3/1.0 1 0x3 r5.03 Disabled 5/5
lo0.0 0 0x1 Passive Disabled 0/0
At this stage, you should have the required number and type (either level 1 or level 2) of adja-
cencies between all seven routers. To quickly confirm, we verify that we have the expected number
of SysIDs on a few strategic routers:
[edit]
lab@r3# run show isis hostname
IS-IS hostname database:
System Id Hostname Type
0100.0000.3003 r3 Static
0100.0000.3004 r4 Dynamic
0100.0000.3005 r5 Dynamic
0100.0000.6001 r1 Dynamic
0100.0000.6002 r2 Dynamic
r3 has hostname entries that correctly reflect area 49.0003 and 49.0002 routers, as expected.
We confirm area 49.0001 by performing the same command on r6:
[edit]
lab@r6# run show isis hostname
IS-IS hostname database:
System Id Hostname Type
0100.0000.3005 r5 Dynamic
0100.0000.9006 r6 Static
0100.0000.9007 r7 Dynamic
A test to confirm that backbone routers see IS-IS routes to all loopback addresses is now
performed:
[edit protocols isis]
lab@r3# run show route protocol isis | match /32
10.0.3.4/32 *[IS-IS/18] 00:39:09, metric 3, tag 2
10.0.3.5/32 *[IS-IS/18] 00:39:09, metric 3, tag 2
10.0.6.1/32 *[IS-IS/15] 00:39:09, metric 5, tag 1
10.0.6.2/32 *[IS-IS/15] 00:39:09, metric 5, tag 1
10.0.9.6/32 *[IS-IS/18] 00:37:32, metric 8, tag 2
10.0.9.7/32 *[IS-IS/18] 00:36:27, metric 8, tag 2
As expected, there are six IS-IS routes on r3 that represent the loopback addresses of all
remote routers. These results indicate that baseline IS-IS functionality is working as needed for
the remaining configuration tasks. You will now add authentication as per this requirement:
All areas must use hello authentication based on md5 with a secret of jnx. The backbone
area must also authenticate LSPs using a simple password of jnx.
Backbone authentication is now added and confirmed. The authentication-related additions
to a typical backbone router configuration are highlighted next:
[edit protocols isis]
lab@r5# show
reference-bandwidth 500m;
level 2 {
authentication-key "$9$jEkmTOBEhrv"; # SECRET-DATA
authentication-type simple; # SECRET-DATA
}
interface fe-0/0/0.0 {
level 2 disable;
level 1 {
hello-authentication-key "$9$H.fz1IcSeW"; # SECRET-DATA
hello-authentication-type md5; # SECRET-DATA
}
}
interface fe-0/0/1.0 {
level 2 disable;
level 1 {
hello-authentication-key "$9$EORSlM2gJZjq"; # SECRET-DATA
hello-authentication-type md5; # SECRET-DATA
}
}
interface all {
level 1 disable;
level 2 {
hello-authentication-key "$9$5znCyrvMX-"; # SECRET-DATA
hello-authentication-type md5; # SECRET-DATA
}
}
Backbone authentication is confirmed by verifying the status of adjacencies (hello authenti-
cation) and the presence of IS-IS routes (LSP authentication):
[edit protocols isis]
lab@r4# run show isis adjacency
Interface System L State Hold (secs) SNPA
as0.0 r5 2 Up 20
fe-0/0/1.0 0100.0000.6002 1 Down 24 0:a0:c9:b2:f8:cb
so-0/1/0.100 r3 2 Up 25
[edit protocols isis]
lab@r4# run show isis route | match /32
10.0.3.3/32 2 55 3 int so-0/1/0.100 r3
10.0.3.5/32 2 55 1 int as0.0 r5
A working authentication configuration for a typical level 1 router is shown here with
authentication-related additions highlighted:
[edit protocols isis]
lab@r1# show
reference-bandwidth 500m;
interface all {
hello-authentication-key "$9$MexL7Vji.mT3"; # SECRET-DATA
hello-authentication-type md5; # SECRET-DATA
level 2 disable;
}
Hello authentication in level 1 areas can be confirmed by verifying the correct adjacency status:
[edit]
lab@r2# run show isis adjacency
Interface System L State Hold (secs) SNPA
fe-0/0/1.0 r4 1 Up 25 0:90:69:6b:30:1
fe-0/0/2.0 r3 1 Up 19 0:90:69:6d:98:1
fe-0/0/3.0 r1 1 Up 25 0:a0:c9:6f:7b:84
Results such as these indicate that hello authentication has been correctly configured in level 1
areas. We next examine a working configuration example for the following case study requirements:
Backbone area routes must be summarized into area 49.0001.
The subnet between r3 and T1 must appear in area 49.0003 as an internal route. Ensure
that no adjacencies can be established on this subnet.
The summarization and leaking of routes into area 49.0001 requires the use of policy and the
definition of an aggregate route, as shown next in the configuration of r5, which highlights the
configuration additions needed for this task:
[edit]
lab@r5# show routing-options
static {
route 10.0.200.0/24 next-hop 10.0.1.102;
}
aggregate {
route 10.0.2.0/23;
}
The policy needed to advertise an aggregate route into a level 1 area is shown here:
[edit]
lab@r5# show policy-options
policy-statement summ {
term 1 {
from {
protocol aggregate;
route-filter 10.0.2.0/23 exact;
}
to level 1;
then accept;
}
}
The export policy must be applied to IS-IS as export for it to have any effect:
[edit]
lab@r5# show protocols isis export
export summ;
The correct operation of route summarization and leaking is easily confirmed on area
49.0001 routers:
[edit]
lab@r6# run show route 10.0.2/23
inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.2.0/23 *[IS-IS/160] 00:02:56, metric 15, tag 1
> to 10.0.8.6 via fe-0/1/0.0
Setting r3ís fe-0/0/2 interface to passive ensures the 172.16.0.12/30 prefix is advertised into
the backbone area as an internal route while also guarding against IS-IS adjacency formation:
[edit protocols isis]
lab@r3# show interface fe-0/0/2
passive;
level 1 disable;
It is a good idea to explicitly disable level 1 operation on this interface because its specific
mention in the configuration results in its not being affected by the presence of the interface all
level 1 disable clause. To confirm proper behavior, we verify that the route to 172.16.0.12/
30 is present in the backbone as an IS-IS internal level 2 route:
[edit]
lab@r5# run show route 172/8
inet.0: 26 destinations, 26 routes (26 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.0.12/30 *[IS-IS/18] 02:10:36, metric 8, tag 2
> to 10.0.2.2 via at-0/2/1.35
