OSPF Authentication

The OSPF protocol can support the authentication of packet exchanges to ensure that adjacencies and LSA flooding are confined to a set of trusted nodes. Authentication options include the default setting of none, the use of a simple password, or a Message Digest 5 (MD5) encoded checksum. Authentication support is configured at the OSPF area-level hierarchy. The individual authentication passwords (or keys) are then specified on a per-interface basis within that area's configuration stanza.

Tip 

MD5 authentication requires that communicating stations share both the key value and a corresponding key-id. Specifying the same secret with two different key-ids will result in authentication failures.

Your next assignment is to add OSPF authentication according to the criteria listed next. You should refer back to Figure 3.1 as needed for topology details:

  • Backbone area uses MD5 key = jni, key-id = 10.

  • Area 1 uses a plain-text password of jnx.

The following commands correctly configure the authentication type for area 0 and area 1:

[edit protocols ospf] lab@r5# set area 0 authentication-type md5 [edit protocols ospf] lab@r5# set area 1 authentication-type simple 

The next set of commands configure the MD5 specifics for all backbone area interfaces:

[edit protocols ospf area 0.0.0.0] lab@r5# set interface at-0/2/1.35 authentication-key jni key-id 10 [edit protocols ospf area 0.0.0.0] lab@r5# set interface as1.0 authentication-key jni key-id 10 

Authentication parameters are not needed on the router's lo0 interface because adjacencies and LSP flooding will not occur over this interface. The next set of commands configure the simple password authentication that is required for area 1:

[edit protocols ospf area 0.0.0.1] lab@r5# set authentication-type simple [edit protocols ospf area 0.0.0.1] lab@r5# set interface fe-0/0/0 authentication-key jnx [edit protocols ospf area 0.0.0.1] lab@r5# set interface fe-0/0/1.0 authentication-key jnx 

The modified OSPF configuration for r5 is shown next. The newly added authentication- related entries are highlighted:

lab@r5# show protocols ospf {      area 0.0.0.0 {         authentication-type md5; # SECRET-DATA          interface lo0.0 {             passive;         }         interface at-0/2/1.35 {             authentication-key "$9$QgSo3/tleWLxd" key-id 10; # SECRET-DATA         }          interface as1.0 {             authentication-key "$9$WjsXNbiHmfT3" key-id 10; # SECRET-DATA         }      }      area 0.0.0.1 {         authentication-type simple; # SECRET-DATA          interface fe-0/0/0.0 {             authentication-key "$9$Kw2WX-UDkqfz"; # SECRET-DATA         }          interface fe-0/0/1.0 {             authentication-key "$9$32M9/A0vMXxds"; # SECRET-DATA         }      } }

After committing the authentication changes on r5, we expect to see the loss of all adjacencies until compatible authentication settings are put into place on the remaining routers. The lack of detected neighbors in the following display confirms these expectations:

[edit protocols ospf area 0.0.0.1] lab@r5# run show ospf interface Interface              State     Area            DR ID           BDR ID       Nbrs as1.0                  PtToPt   0.0.0.0         0.0.0.0         0.0.0.0         0 at-0/2/1.35            PtToPt   0.0.0.0         0.0.0.0         0.0.0.0         0 lo0.0                  DR       0.0.0.0         10.0.3.5        0.0.0.0         0 fe-0/0/0.0             DR       0.0.0.1         10.0.3.5        0.0.0.0         0 fe-0/0/1.0             DR       0.0.0.1         10.0.3.5        0.0.0.0         0 

Verify OSPF Authentication

OSPF authentication problems normally result in the same types of neighbor detection and adjacency failures that could also be attributed to numerous problems at the OSPF, IP, link, or physical layers. The operator can quickly isolate physical, link, and IP layer problems through ping testing to a directly connected OSPF router. You should suspect authentication-related problems when ping testing succeeds in the face of OSPF neighbor discovery failures.

Sometimes, the use of monitor traffic will make authentication problems obvious. The following example shows a capture taken from r5's fe-0/0/0 interface:

[edit] lab@r5# run monitor traffic interface fe-0/0/0 extensive Listening on fe-0/0/0 08:34:44.426378 Out 0:90:69:69:70:0 1:0:5e:0:0:5 ip 78: 10.0.8.6 > 224.0.0.5:   OSPFv2-hello 44: rtrid 10.0.3.5 area 0.0.0.1 auth "jnx^@^@^@^@^@" E mask  255.255.255.252 int 10 pri 128 dead 40 dr 10.0.8.6 nbrs [tos 0xc0]  [ttl 1] (id  48338) 08:34:48.854579  In 10.0.8.5 > 224.0.0.5:  OSPFv2-hello 44: rtrid 10.0.9.6 area  0.0.0.1 E mask 255.255.255.252 int 10 pri 128 dead 40 dr 10.0.8.5 nbrs [tos  0xc0]  [ttl 1] (id 32032)

This output clearly shows that simple password authentication is present in the hello packets sent out r5's fe-0/0/0 interface. The plain text password value of jnx, which has been padded to the required 8 bytes, is clearly displayed in this output. In contrast, the hello packets received by r5 lack any authentication fields.

The following capture, taken from r5's ATM interface, illustrates the difference between the simple password and MD5-based authentication techniques:

lab@r5# run monitor traffic interface at-0/2/1 extensive Listening on at-0/2/1 08:47:43.044735  In 10.0.2.2 > 224.0.0.5:  OSPFv2-hello 44: rtrid 10.0.3.3  backbone E mask 255.255.255.252 int 10 pri 128 dead 40 nbrs [tos 0xc0]  [ttl 1]  (id 22522) 08:47:47.948227 Out aa aa 03 00-00-00 0800: 10.0.2.1 > 224.0.0.5:  OSPFv2-hello  44: rtrid 10.0.3.5 backbone auth MD5 E mask 255.255.255.252 int 10 pri 128 dead  40 nbrs [tos 0xc0]  [ttl 1] (id 48763) 

Once again, it is clear that received packets have no authentication information while the packets being sent by r5 carry an MD5-based hash. In contrast to the simple password example, it is impossible to ascertain the MD5 secret that is being used to produce the MD5 hash. You will therefore need to reset the MD5 hash in all routers if you suspect that mismatched MD5 secrets have been configured.

Protocol Tracing

While monitoring traffic has the benefit of being 'quick and dirty,' the more or less raw output pales in comparison to the well-cooked information provided by JUNOS software protocol tracing. The following tracing configuration has been added to r5, which is still the only router configured for authentication at this stage of the configuration example:

[edit] lab@r5# show protocols ospf traceoptions {    file ospf;    flag error detail;    flag hello detail;  } 

This tracing configuration produced the following output, which makes the nature of the problem obvious to even a casual observer:

[edit] lab@r5# run monitor start ospf *** ospf *** Apr 25 08:51:11 OSPF packet ignored: authentication type mismatch (0) from  10.0.8.10 Apr 25 08:51:11 OSPF rcvd Hello 10.0.8.10 -> 224.0.0.5 (fe-0/0/1.0) Apr 25 08:51:11   Version 2, length 44, ID 10.0.9.7, area 0.0.0.1 Apr 25 08:51:11   checksum 0xd611, authtype 0 Apr 25 08:51:11   mask 255.255.255.252, hello_ivl 10, opts 0x2, prio 128 Apr 25 08:51:11   dead_ivl 40, DR 10.0.8.10, BDR 0.0.0.0 Apr 25 08:51:11 OSPF packet ignored: authentication type mismatch (0) from  10.0.2.10 Apr 25 08:51:11 OSPF rcvd Hello 10.0.2.10 -> 224.0.0.5 (as1.0) . . .

After adding the appropriate authentication settings to the remaining routers in area 0 and area 1, we once again have a functional IGP as indicated by the following operational mode commands:

 [edit] lab@r5# run show ospf interface Interface              State     Area            DR ID           BDR ID       Nbrs as1.0                  PtToPt   0.0.0.0         0.0.0.0         0.0.0.0         1 at-0/2/1.35            PtToPt   0.0.0.0         0.0.0.0         0.0.0.0         1 lo0.0                  DR       0.0.0.0         10.0.3.5        0.0.0.0         0 fe-0/0/0.0             BDR      0.0.0.1         10.0.9.6        10.0.3.5        1 fe-0/0/1.0             BDR      0.0.0.1         10.0.9.7        10.0.3.5        1 

As shown previously, neighbors have once again been detected on r5's interfaces. We will now confirm adjacency status for r5's neighbors:

[edit] lab@r5# run show ospf neighbor   Address         Interface             State      ID              Pri  Dead 10.0.2.10        as1.0                  Full      10.0.3.4         128    34 10.0.2.2         at-0/2/1.35            Full      10.0.3.3         128    35 10.0.8.5         fe-0/0/0.0             Full      10.0.9.6         128    32 10.0.8.10        fe-0/0/1.0             Full      10.0.9.7         128    32

Excellent! These results indicate that all of r5's adjacencies have been correctly established. The next command quickly assesses the overall state of the OSPF routing domain by confirming that all routers have flooded a router LSA within their respective areas:

[edit] lab@r5# run show ospf database router      OSPF link state database, area 0.0.0.0  Type       ID               Adv Rtr           Seq       Age  Opt  Cksum  Len Router   10.0.3.3         10.0.3.3         0x8000000d    169  0x2  0xa7fb  96 Router   10.0.3.4         10.0.3.4         0x80000017   166  0x2  0xf52   84 Router  *10.0.3.5         10.0.3.5         0x80000013    173  0x2  0x1854  84      OSPF link state database, area 0.0.0.1  Type       ID               Adv Rtr           Seq       Age  Opt  Cksum  Len Router  *10.0.3.5         10.0.3.5         0x80000043     31  0x2  0x264f  48 Router   10.0.9.6         10.0.9.6         0x8000006c     59  0x2  0x70b7  60 Router   10.0.9.7         10.0.9.7         0x8000003f     35  0x2  0x3c0b  60

The OSPF database on r5 indicates that router LSAs (type 1 LSAs) have been generated by each of the five routers in this topology. While these results do not prove that all routers have the expected number of adjacencies, the results do indicate that every router in the network has at least one functional adjacency as evidenced by the successful flooding of router LSAs.




JNCIP. Juniper Networks Certified Internet Professional Study Guide Exam CERT-JNCIP-M
JNCIP: Juniper Networks Certified Internet Professional Study Guide
ISBN: 0782140734
EAN: 2147483647
Year: 2003
Pages: 132

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net