From: marvin greenlee (marvin@ccbootcamp.com)
Date: Tue Jan 11 2005 - 14:15:43 GMT-3
Lee,
Having the wrong name in the dialer map doesn't necessarily prevent the
connection from coming up.
Tim,
Your dead time shows as '-'. Are you also running an OSPF demand circuit?
The neighbor statement will INITIATE the connection. If the side WITHOUT
the neighbor statement had it's process cleared, it would not initiate
traffic (with that network type for OSPF). The side with the neighbor
statement may think that everything is fine because of the demand circuit,
and show a 'full' adjacency.
I don't have that workbook, so I don't know if the demand circuit is part of
a requirement for the same section, or a different section.
- Marvin Greenlee, CCIE#12237, CCSI# 30483
Network Learning Inc
marvin@ccbootcamp.com
www.ccbootcamp.com (Cisco Training)
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: Tuesday, January 11, 2005 4:41 AM
To: marvin greenlee; ccielab@groupstudy.com
Subject: Re: osfp over isdn using unicasts - Problem solved
Hi Marvin,
This morning I discovered some strange but interesting things.
Last night, after I gave up on this, I left the configs as they were, ie,
no adjacency between R4 and R5 and with the isdn link flapping up & down.
This morning, when I checked, R4 and R5 had become adjacent.
So, I wondered if maybe the problem was that I had set the idle-timeouts too
short at 25 seconds. After removing the idle-timeouts from both sides and
shutting and then no shutting the bri interface, the adjacency came up.
Then I did an experiment.
I changed the config which had the neighbor command on both sides
so that the neighbor command was on only one side - R5.
On the side without the neighbor command, on R4, it showed no neighbors:
Rack1R4#sh ip os n
Rack1R4#
While at the same time, R5 showed R4 as a neighbor:
Rack1R5#sh ip os n
Neighbor ID Pri State Dead Time Address Interface
150.1.4.4 0 FULL/ - - 130.1.45.4 BRI0/0
150.1.3.3 0 FULL/ - 00:00:36 130.1.35.3 Serial0/0
Rack1R5#
After about 10 minutes, R5 stilled showed R4 as adjacent and had R4 routes
in it's route table while R4 showed no ospf adjacencies and didn't have any
ospf routes:
Rack1R5#sir os
130.1.0.0/16 is variably subnetted, 5 subnets, 3 masks
O IA 130.1.33.0/24 [110/74] via 130.1.35.3, 00:17:10, Serial0/0
O 130.1.45.4/32 [110/1562] via 130.1.45.4, 00:16:47, BRI0/0
150.1.0.0/16 is variably subnetted, 3 subnets, 2 masks
O IA 150.1.4.4/32 [110/2562] via 130.1.45.4, 00:17:10, BRI0/0 <-- R4's
Lo0
O IA 150.1.3.3/32 [110/65] via 130.1.35.3, 00:17:10, Serial0/0
Rack1R5#sh ip os n
Neighbor ID Pri State Dead Time Address Interface
150.1.4.4 0 FULL/ - - 130.1.45.4 BRI0/0
150.1.3.3 0 FULL/ - 00:00:39 130.1.35.3 Serial0/0
Rack1R5#
Rack1R4#sh ip os n
Rack1R4#sir os
Rack1R4#sh ip rout ospf
Rack1R4#
How is it that R5 can think it's adjacent with R4 while R4
is NOT adjacent to R5?
After reconfiguring the neighbor on R4, the adjacency from R4's
point of view comes back.
Rack1R4#c
Enter configuration commands, one per line. End with CNTL/Z.
Rack1R4(config)#router os 1
Rack1R4(config-router)#nei 130.1.45.5
Rack1R4(config-router)#
Rack1R4#
*Mar 6 11:07:04.251: %SYS-5-CONFIG_I: Configured from console by console
Rack1R4#sh ip os n
Neighbor ID Pri State Dead Time Address Interface
N/A 0 DOWN/ - - 130.1.45.5 BRI0/0
Rack1R4#
*Mar 6 11:07:21.515: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to
up
Rack1R4#
*Mar 6 11:07:22.555: %LINEPROTO-5-UPDOWN: Line protocol on Interface
BRI0/0:1,
changed state to up
Rack1R4#
*Mar 6 11:07:27.519: %ISDN-6-CONNECT: Interface BRI0/0:1 is now connected
to 22
21 ROUTER5
Rack1R4#sh ip os n
Neighbor ID Pri State Dead Time Address Interface
N/A 0 DOWN/ - - 130.1.45.5 BRI0/0
Rack1R4#
*Mar 6 11:08:11.003: %OSPF-5-ADJCHG: Process 1, Nbr 150.1.5.5 on BRI0/0
from LO
ADING to FULL, Loading Done
Rack1R4#sh ip os n
Neighbor ID Pri State Dead Time Address Interface
150.1.5.5 0 FULL/ - 00:01:52 130.1.45.5 BRI0/0
Rack1R4#
Strange, isn't it?
My conclusion: the neighbor statement is required on both sides of the link.
Do you agree?
Thanks, Tim
----- Original Message -----
From: "marvin greenlee" <marvin@ccbootcamp.com>
To: "'ccie2be'" <ccie2be@nyc.rr.com>; <ccielab@groupstudy.com>
Sent: Tuesday, January 11, 2005 12:16 AM
Subject: RE: osfp over isdn using unicasts [bcc][faked-from][bayes]
> Works fine for me. What do 'debug ip ospf adj' and 'debug ip packet
detail'
> show you? Did you try saving configs and reloading your routers?
>
> - Marvin Greenlee, CCIE#12237, CCSI# 30483
> Network Learning Inc
> marvin@ccbootcamp.com
> www.ccbootcamp.com (Cisco Training)
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> ccie2be
> Sent: Monday, January 10, 2005 8:14 PM
> To: Group Study
> Subject: osfp over isdn using unicasts [bcc][faked-from][bayes]
> Importance: Low
>
> Hi guys,
>
> Has anyone gotten this to work?
>
> This is from IEWB lab 15, task 5.21.
>
> According to IE, the config should be fairly simple and like this:
>
>
> R4
> int bri 0/0
> ip ospf network point-to-multipoint non-broadcast
> dialer map ip 130.1.45.5 name ROUTER5 5555
>
> ROUTER OSPF 1
> net 130.1.45.0 0.0.0.255 area 345
> neighbor 130.1.45.5
>
> R5
>
> int bri 0/0
> ip ospf network point-to-multipoint non-broadcast
> dialer map ip 130.1.45.4 name ROUTER5 4444
>
> ROUTER OSPF 1
> net 130.1.45.0 0.0.0.255 area 345
>
>
> Before changing to the above the config, I had established an ospf
adjacency
>
> between R4 and R5. But, once I changed the config to the above,
>
> the ospf adjacency flapped between down and init.
>
> Any one have any ideas on what is needed to make this work.
>
> TIA, Tim
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Wed Feb 02 2005 - 22:10:21 GMT-3