IS-IS Authentication

The IS-IS implementation offered in JUNOS software supports both simple password and HMAC-MD5–based authentication mechanisms. One key difference between OSPF and IS-IS authentication support relates to the ability to configure authentication for IS-IS hellos, LSP exchanges, or both.

Your next assignment is to add IS-IS authentication according to the criteria listed next. You should refer back to Figure 4.1 for topology details.

• Backbone area authenticates both hello and LSP exchanges using MD5 with a key value of jni.

• Area 49.0002 uses a plain text password of jnx for hello authentication only.

• No routing disruption can occur in the backbone when adding authentication.

Configure Authentication on r5

The following commands correctly configure the authentication parameters for area 49.0001. Note that the inclusion of the no-authentication-check option is required to ensure that adjacencies are not disrupted by the addition of authentication to the IS-IS level 2 backbone:

[edit protocols isis] lab@r5# set no-authentication-check [edit protocols isis] lab@r5# set level 2 authentication-type md5 authentication-key jni 

The next set of commands adds the required hello authentication to each of r5’s level 2 interfaces. Authentication is not configured on interface lo0 because LSP flooding and adjacency formation do not occur on this virtual interface:

[edit protocols isis] lab@r5# set interface as1.0 hello-authentication-type md5 [edit protocols isis] lab@r5# set interface as1.0 hello-authentication-key jni [edit protocols isis] lab@r5# set interface at-0/2/1.35 hello-authentication-type md5 [edit protocols isis] lab@r5# set interface at-0/2/1.35 hello-authentication-key jni 

Next, simple password authentication, as required for area 49.0002 hello exchanges, is configured on r5:

[edit protocols isis] lab@r5# set interface fe-0/0/0 hello-authentication-type simple [edit protocols isis] lab@r5# set interface fe-0/0/0 hello-authentication-key jnx [edit protocols isis] lab@r5# set interface fe-0/0/1 hello-authentication-type simple [edit protocols isis] lab@r5# set interface fe-0/0/1 hello-authentication-key jnx 

The modified configuration for r5 is shown next with the newly added authentication configuration highlighted:

[edit protocols isis] lab@r5# show no-authentication-check; level 2 {    authentication-key "$9$iqPQB1hSrv"; # SECRET-DATA    authentication-type md5; # SECRET-DATA  }  interface fe-0/0/0.0 {    hello-authentication-key "$9$VhsgJTQn6A0"; # SECRET-DATA    hello-authentication-type simple; # SECRET-DATA    level 2 disable; } interface fe-0/0/1.0 {    hello-authentication-key "$9$iqPQB1hclM"; # SECRET-DATA    hello-authentication-type simple; # SECRET-DATA    level 2 disable;  }  interface at-0/2/1.35 {    hello-authentication-key "$9$p-XmOIcN-wYgJ"; # SECRET-DATA    hello-authentication-type md5; # SECRET-DATA    level 1 disable;  }  interface as1.0 {    hello-authentication-key "$9$gXaGi6/tuOR"; # SECRET-DATA    hello-authentication-type md5; # SECRET-DATA    level 1 disable;  }  interface lo0.0 {    level 1 disable;  } 

After committing the authentication changes on r5, we confirm that all level 2 adjacencies remain in place, despite the absence of compatible authentication settings on the remaining routers that make up the test bed:

[edit] lab@r5# commit and-quit commit complete Exiting configuration mode lab@r5> show isis adjacency Interface             System         L State        Hold (secs) SNPA as1.0                 r4             2 Up                   19 at-0/2/1.35           r3             2 Up                   21 fe-0/0/0.0            r6             1 Up                    8  0:a0:c9:69:c5:27 fe-0/0/1.0            r7             1 Up                   23  0:60:94:51:c4:27

Configure Authentication on r3 and r4

The authentication configuration for r3 and r4 is similar to that of r5. The only difference is the lack of area 49.0002 and level 1–related authentication, which is not required because these routers are only level 2–attached. The completed configuration for the remaining level 2 routers is shown here, starting with r3:

[edit protocols isis] lab@r3# show no-authentication-check; level 2 {     authentication-key "$9$nhTp9tOMWxNds"; # SECRET-DATA     authentication-type md5; # SECRET-DATA } interface fe-0/0/2.0 {     passive;      level 1 disable; } interface at-0/1/0.35 {     hello-authentication-key "$9$wx2oGzF/CtO"; # SECRET-DATA      hello-authentication-type md5; # SECRET-DATA      level 1 disable; } interface so-0/2/0.100 {     hello-authentication-key "$9$yuZeMXaJDikP"; # SECRET-DATA      hello-authentication-type md5; # SECRET-DATA      level 1 disable; } interface lo0.0 {      level 1 disable; }

r4’s configuration is very similar to that of r3:

[edit protocols isis] lab@r4# show no-authentication-check; level 2 {     authentication-key "$9$XX4NVYq.5QF/"; # SECRET-DATA     authentication-type md5; # SECRET-DATA } interface so-0/1/0.100 {     hello-authentication-key "$9$OQpxIhrVb24aU"; # SECRET-DATA      hello-authentication-type md5; # SECRET-DATA      level 1 disable; } interface as0.0 {     hello-authentication-key "$9$SCLlvLoaUjHm"; # SECRET-DATA      hello-authentication-type md5; # SECRET-DATA      level 1 disable; } interface lo0.0 {     level 1 disable; } 

Configure Authentication in Area 49.0002

The following commands correctly configure r7 for simple password-based authentication of hello messages. The use of no-authentication-check is not required in this area, so we expect to see the loss of adjacency to r6 when the changes are committed. The adjacency to r5, however, should remain operational because it’s already being configured with compatible authentication parameters:

[edit protocols isis] lab@r7# set interface all hello-authentication-type simple [edit protocols isis] lab@r7# set interface all hello-authentication-key jnx [edit protocols isis] lab@r7# commit commit complete [edit protocols isis] lab@r7# run show isis adjacency Interface             System         L State        Hold (secs) SNPA fe-0/3/0.0            r6             1 Rejected             16  0:a0:c9:69:c1:e4 fe-0/3/1.0            r5             1 Up                    7  0:90:69:69:70:1

Just as predicted, the lack of compatible hello authentication in r6 results in the rejection of its hello packets. This situation will clear up when r6 is compatibly configured, as shown next:

[edit protocols isis] lab@r6# show level 2 disable; interface all {    hello-authentication-key "$9$RTtcrvY2aJDk"; # SECRET-DATA    hello-authentication-type simple; # SECRET-DATA  }

The authentication changes are committed on r6, and the results are confirmed:

[edit protocols isis] lab@r6# commit commit complete [edit protocols isis] lab@r6# run show isis adjacency Interface            System        L State       Hold (secs) SNPA fe-0/1/0.0           r5            1 Up                   21  0:90:69:69:70:0 fe-0/1/1.0           r7            1 Initializing         22  0:a0:c9:6f:7b:1a [edit protocols isis] lab@r6#  run show isis adjacency Interface           System       L State      Hold (secs) SNPA fe-0/1/0.0              r5          1 Up                  22  0:90:69:69:70:0 fe-0/1/1.0              r7          1 Up                  26  0:a0:c9:6f:7b:1a 

Troubleshoot IS-IS Authentication

IS-IS authentication problems often result in the same types of neighbor detection and adjacency failures that can also be attributed to numerous problems at the IS-IS, link, or physical layers. The operator can quickly isolate physical and link layer problems through ping testing to a directly connected router. Authentication-related problems should be suspected when ping testing succeeds in the face of IS-IS adjacency failures. Adding the no-authentication-check option can quickly confirm if authentication is causing an adjacency problem because this causes the receiving router to ignore the authentication parameters (or lack thereof) in the IS-IS PDUs it receives.

Often, the use of monitor traffic will make authentication problems obvious. The following example shows a capture taken from r7’s fe-0/3/0 interface before r6 has been correctly configured for hello authentication:

[edit protocols isis] lab@r7# run monitor traffic interface fe-0/3/0 Listening on fe-0/3/0 19:55:18.586402 Out iso isis  0:a0:c9:6f:7b:1a > 1:80:c2:0:0:14 len=49                           L1 lan iih, circuit l1 only, holding time 27                          source 1:0:0:0:90:7, length 49                          lan id 1:0:0:0:90:7(2)                          Supports protocols are CC 8E                          IP address: 10.0.8.2                          area addresses                          49.0002 (3)                          authentication data                          016a 6e78 19:55:20.195900  In iso isis 0:a0:c9:69:c1:e4 > 1:80:c2:0:0:14 len=1492                          L1 lan iih, circuit l1 only, holding time 27                          source 1:0:0:0:90:6, length 1492                          lan id 1:0:0:0:90:6(3)                          neighbor addresses                          0:a0:c9:6f:7b:1a                          Supports protocols are CC 8E                          IP address: 10.0.8.1                          area addresses                          49.0002 (3)                          padding for 255 bytes                          packet exceeded snapshot 

This decode clearly shows that simple password authentication is present in the hello packets sent out r7’s fe-0/3/0 interface. The plain text password value of jnx is displayed in hexadecimal form with 6a 6e 78 being ASCII code for the configured jnx key. In contrast, the hello packets received by r7 clearly lack the authentication field.

The following capture, taken from r5’s aggregated SONET interface, illustrates the difference between the simple password and MD5-based hello packet authentication approaches:

[edit protocols isis] lab@r5# run monitor traffic interface as1 Listening on as1 . . . 05:03:53.746131  In iso isis len=72                          PTP iih, circuit l2 only, holding time 27                          source 1:0:0:0:30:4, length 72                          PTP adjacency status UP                          Supports protocols are CC 8E                          IP address: 10.0.2.10                          area addresses                          49.0001 (3)                          authentication data                          3661 755c 5532 ce85 645f a7d0 8b92 8934 69 

Once again, it is clear that the received hello packet is carrying some type of authentication information. However, it is not obvious whether the packets are using simple password or MD5-based secrets. If you suspect that mismatched MD5 secrets have been configured, you will need to reset the MD5 key in all routers. Reverse engineering the MD5 hash is not possible, even with an ASCII code chart.

Protocol Tracing

While monitoring traffic has the benefit of being fast and dirty, the output will often leave much to the operator’s interpretation, which is in stark contrast to the overt error messages that are sometimes seen with protocol tracing. The following tracing configuration has been added to r7:

[edit protocols isis] lab@r7# show traceoptions file isis; flag error detail; flag hello detail;

This tracing configuration produced the following output, which makes it hard to miss the authentication-related nature of the problem:

[edit] lab@r7# run monitor start isis lab@r7# May 17 20:08:57 Received L1 LAN IIH, source id r6 on fe-0/3/0.0 May 17 20:08:57     intf index 2 addr 0.a0.c9.69.c1.e4, snpa 0:a0:c9:69:c1:e4 May 17 20:08:57     max area 0, circuit type l1, packet length 1492 May 17 20:08:57     hold time 27, priority 64, circuit id r6.03 May 17 20:08:57     neighbor 0:a0:c9:6f:7b:1a (ourselves) May 17 20:08:57     speaks IP May 17 20:08:57     speaks IPV6 May 17 20:08:57     IP address 10.0.8.1 May 17 20:08:57     area address 49.0002 (3) May 17 20:08:57 ERROR: IIH from r6 without authentication May 17 20:08:57 ERROR: previous error from L1, source r6 on fe-0/3/0.0 

How Can You Confirm Area 49.0001 Authentication Settings?

The presence of the no-authentication-check option in the backbone routers can cause incompatible or incorrect authentication parameters to go undetected. Before moving on, you should temporarily delete this option on a backbone router and verify that all level 2 adjacencies are maintained. After confirming that all is well, this option should be reinstated, as its presence is needed to show compliance with the specified configuration requirements.

[edit protocols isis] lab@r5# delete no-authentication-check [edit protocols isis] lab@r5# commit commit complete [edit protocols isis] lab@r5# run show isis adjacency Interface            System        L State       Hold (secs) SNPA as1.0                r4            2 Up                  23 at-0/2/1.35          r3            2 Up                  23 fe-0/0/0.0           r6            1 Up                    8  0:a0:c9:69:c5:27 fe-0/0/1.0           r7            1 Up                   20  0:60:94:51:c4:27 [edit protocols isis] lab@r5# set no-authentication-check [edit protocols isis] lab@r5#  commit commit complete