|
|
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.
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
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; }
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
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.
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
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
|
|