From: gladston@br.ibm.com
Date: Fri Apr 22 2005 - 16:08:07 GMT-3
Hi,
Thanks for the replies.
The problem I faced seems to be the same as Pearson experimented. It does
occurs only after reloading the router R4.
No reload, no problem. OSPF adjacencies keep up, and if I configure the
new key (key2) on R1, the rollover process finishes succefully.
Sorry for the missing config parts. They are all there, layer 2/3 is
working (besides the problem with reload and rollover).
R4 is connected to R1 --> nbma frame-relay
Just R4 is configured with neighbor statement. (although after configuring
R1 with neighbor, the adjacency goes UP after reloading R4)
On real networks that would not be a problem, because it would be rarely
to reload the routers during rollover process.
But can you see the problem in the CCIE lab? or before lunch, when we
usually reload the routers.
====================================
quoted
Because you are using non-broadcast with frame relay it would
require one of the routers to have a neighbor statement to establish an
adjacency (typically the hub).
Regards,
George
==================================
R4 has the neighbor statement. There is just R1 and R4 on this particular
problem.
====================
Also I don't know if it was cut off in
the paste but I don't see your map statement on the S0/0 interface on
R4?
Regards,
George
==================================
It was cut off. Sorry.
==================================
Also I don't understand why on R1 you have two map statements on s
0/0.14 mult interface going to two different subnets? OSPF should try
and use the youngest key that is similar between the two routers.
Regards,
George
==================================
My mistake, probably typed wrongly during rack rental time. MAPs are on R4
and R1.
================================
OSPF should try
and use the youngest key that is similar between the two routers.
Regards,
George
==================================
And it does, the problem is just after reloading R4. It sends OSPF packets
with Key 1 and key 2 but OSPF adjacency stay DOWN. If I remove key 1 from
R4 or configure key 2 on R1 adjacency goes UP.
==================================
I'm somewhat confused by your explanation of the behavior. Can
you post the appropriate adj. debug?
HTH,
Alsontra
==================================
I will rent rack lab time next April 26th, so I can reproduce it again.
Cordially,
------------------------------------------------------------------
Gladston
Pearson John <jnhpearson@yahoo.co.jp>
21/04/2005 23:21
To
"George Cassels \(gcassels\)" <gcassels@cisco.com>, Alaerte Gladston
Vidali/Brazil/IBM@IBMBR, <ccielab@groupstudy.com>
cc
Subject
RE: OSPF MD5 - Rollover
George,
Many thanks for the comments concerning MD5 rollover with
OSPF. I've seen a case with an FR Hub&Spoke topology (OSPF
non-broadcast) - Hub and two spokes, where the DR Hub (say
R1) and one spoke (say R2) have been updated with new key
2 and the other spoke (say R3) has just the old key.
What was seen is that the neighboring between R1 and R2
use the younger key 2, and R1 and R3 use the older key1.
This is fine whilst the DR is still up and even after
clearing the OSPF process on the DR R1. However, once the
DR Hub R1 is reloaded, R1 and R2 can neighbor up, but R1
and R3 son't seem to be able to neighbor up with the older
key1.
Cisco documentation on OSPF rollover states that until a
router knows ALL neighbors have the new key configured, it
will still send packets with each key. This doesn't seem
to be the case in this scenario once R1 was reloaded.
What's your experience with an FR Hub&Spoke OSPF
non-broadcast topology where keys are updated on one spoke
and the DR Hub only? Shouldn't the DR Hub send both keys
whilst other spokes haven't been updated with the new key?
Any advice would be greatly appreciated.
Thanks in advance.
John
--- "George Cassels (gcassels)" <gcassels@cisco.com> $B$+(B
$B$i$N%a%C%;!<%8!'(B
> Gladston,
>
> Because you are using non-broadcast with frame
> relay it would
> require one of the routers to have a neighbor
> statement to establish an
> adjacency (typically the hub). Also I don't know if
> it was cut off in
> the paste but I don't see your map statement on the
> S0/0 interface on
> R4? Also I don't understand why on R1 you have two
> map statements on s
> 0/0.14 mult interface going to two different
> subnets? OSPF should try
> and use the youngest key that is similar between the
> two routers.
>
> Regards,
> George
>
>
> -----Original Message-----
> From: nobody@groupstudy.com
> [mailto:nobody@groupstudy.com] On Behalf Of
> gladston@br.ibm.com
> Sent: Thursday, April 21, 2005 1:07 PM
> To: ccielab@groupstudy.com
> Subject: OSPF MD5 - Rollover
>
> Rollover key works fine before reloading. After
> reloading R4 tries to
> authenticate using key 1 and 2 but adjacency does
> not go up. If I remove
> the second key, it establishes the adjacency.
>
> If I configure neighbor statement on R1, adjacency
> goes up.
> Network type is non-broadcast.
>
> Have you seem this behavior?
>
> R4
> interface Serial0/0
> ip address 142.20.14.4 255.255.255.0
> ip pim sparse-dense-mode
> encapsulation frame-relay
> ip ospf message-digest-key 1 md5 cisco
> ip ospf message-digest-key 2 md5 ccie
>
> R4
> router-id 142.20.4.1
> log-adjacency-changes
> area 112 authentication message-digest
> area 113 authentication message-digest
> redistribute connected subnets route-map
> connected->ospf network
> 142.20.4.0 0.0.0.255 area 112 network 142.20.14.0
> 0.0.0.255 area 112
> network 142.20.45.4 0.0.0.3 area 113 neighbor
> 142.20.14.1
>
>
>
> R1
> router ospf 1
> router-id 142.20.1.1
> log-adjacency-changes
> area 0 authentication
> area 112 authentication message-digest
> redistribute rip subnets
> network 142.20.1.0 0.0.0.255 area 0
> network 142.20.14.0 0.0.0.255 area 112
> network 142.20.125.0 0.0.0.31 area 0
>
> R1
> interface Serial0/0.14 multipoint
> ip address 142.20.14.1 255.255.255.0
> ip pim sparse-dense-mode
> ip ospf message-digest-key 1 md5 cisco
> ip ospf priority 0
> ipv6 address 2001::1/64
> frame-relay map ip 142.20.1.4 104 broadcast
> frame-relay map ip
> 142.20.14.4 104 broadcast
>
>
> Rack2R4#sh ver
> Cisco Internetwork Operating System Software IOS
> (tm) C2600 Software
> (C2600-J1S3-M), Version 12.2(15)T5
>
>
This archive was generated by hypermail 2.1.4 : Tue May 03 2005 - 07:55:07 GMT-3