From: Dennis J. Hartmann (dennisjhartmann@hotmail.com)
Date: Wed Apr 27 2005 - 13:31:42 GMT-3
The non-broadcast network type is not the issue because I recreated
this yesterday over NB frame-relay and it worked without a problem.
I did notice this though:
While playing, I configured clear text authentication on the
interface with the ip ospf authentication command. I then upgraded the area
to message-digest authentication and upgraded the interface to
message-digest authentication while leaving the ip ospf authentication
command under the interface. With that command on the interface, the MD5
worked, but the keys never upgraded. I took out the command, refreshed the
interface (shut, no shut) and things worked correctly after that.
It might be an IOS bug. I'm done with this topic though. Good
luck.
-Dennis Hartmann
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
George Cassels (gcassels)
Sent: Wednesday, April 27, 2005 11:34 AM
To: Sean C; gladston@br.ibm.com
Cc: Alsontra Daniels; ccielab@groupstudy.com; Pearson John
Subject: RE: OSPF MD5 - Rollover
Ok Sean to be honest I can not be sure, but I think that it is because of
the non-broadcast network type. If you did this same config with
point-to-point or point to multipoint network type I think it would work
without any issues. I have not verified this though. So because of the
non-broadcast nature of the frame-relay interface with the neighbor
statement being on the router with both keys the router with only one key
transmissions are never received at the router with two keys. By putting the
neighbor statement on the router with only one key it allows that routers
transmissions to be received by the router with two keys allowing it to see
that its neighbor only has the capability to use key
1 and not its youngest key which in this case is key 2. Lots of theory here
and no real hard facts though.
Anyone else have any theories?
George
This archive was generated by hypermail 2.1.4 : Tue May 03 2005 - 07:55:09 GMT-3