From: marc van hoof (mvh@marcvanhoof.com)
Date: Sun Aug 22 2004 - 04:40:11 GMT-3
Yep - all good - Regarding the explanation of concurrent LSA's irrespective
of route-map, that's the solution I was beginning to suspect.
Thanks for the clarification.
Regards,
-marc.
> -----Original Message-----
> From: Alexander Arsenyev (GU/ETL) [mailto:alexander.arsenyev@ericsson.com]
> Sent: Sunday, 22 August 2004 5:13 PM
> To: 'marc van hoof'; ccielab@groupstudy.com
> Subject: RE: dialer watch-list - please help !!
>
> Marc,
>
> OSPF InTRA-area route is always preferred (to avoid routing loops) over
> OSPF inTER-area route,
> this is by design, see RFC2328 section 11 paragraph "Path-type".
> <quote>
> Also, this doesn't explain why the route doesn't reappear even when I've
> applied a route-map that is blocking the 150.2.5.5/32 route from bri 0/0.
> </quote>
> I don't quite understand Your above statement. What is happening with Your
> route-map is that
> 150.2.5.5/32 gets blocked just before entering the routing table, when
> prefix/netmask/next-hop/metric/metric-type
> are calculated and route selected as "the best" by OSPF. It is not
> possible to block the OSPF LSA with
> route-map, route-map blocks the route as combination of
> prefix/netmask/next-hop/metric/metric-type.
> Therefore R4 most probably is getting 2 OSPF LSAs for 150.2.5.5/32 when
> both S0/0 and BRI0/0 are UP: Type 3 summary LSA via Serial0/0 and Type 1
> router LSA via BRI0/0. OSPF calculates the route to 150.2.5.5/32 and finds
> that 150.2.5.5/32 via BRI0/0 beats 150.2.5.5/32 via S0/0 due to route-type
> (OSPF inTRA-area vs OSPF inTER-area). Then OSPF tries to "upload"/insert
> this route into routing table and route-map blocks this "upload". However,
> OSPF is not aware that 150.2.5.5/32 has not made it into routing table,
> there is no feedback to OSPF daemon from routing table maintenance daemon
> (or whatever they are called in Cisco IOS) and no request either to force
> OSPF to select second best route.
> When You shut down R4' BRI0/0 then Type 1 router LSA for 150.2.5.5/32 gets
> flushed from OSPF database and OSPF recalculates the best route for
> 150.2.5.5/32. This time it points to S0/0 and route-map does not block it,
> route makes it into routing table and everything is back to normal.
> My suggestion to fix Your problem is to eliminate this inherent prevalence
> of OSPF Type 1 vs Type 3 and make 150.2.5.5/32 always appear in R4 as "O
> IA" route by placing R5 Lo0 into separate OSPF area (unless prohibited by
> scenario).
> Makes sense?
> HTH,
> Cheers
> Alex
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> marc van hoof
> Sent: 22 August 2004 07:47
> To: Alexander Arsenyev (GU/ETL); 'marc van hoof'; ccielab@groupstudy.com
> Subject: RE: dialer watch-list - please help !!
>
>
> Sh*t - you're right - Lo 0 of R5 is being advertised into area 45, not
> area
> 345.
>
> This means that it's receiving an inter-area route over serial 0/0 and an
> intra-area route over bri 0/0.
>
> I'm guessing that regardless of admin distance, the intra-area route is
> going to win ?
>
> Also, this doesn't explain why the route doesn't reappear even when I've
> applied a route-map that is blocking the 150.2.5.5/32 route from bri 0/0.
>
> Regards,
> -marc.
>
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> > Alexander Arsenyev (GU/ETL)
> > Sent: Sunday, 22 August 2004 4:16 PM
> > To: 'marc van hoof'; ccielab@groupstudy.com
> > Subject: RE: dialer watch-list - please help !!
> >
> > Marc,
> >
> > <quote>
> > So, basically, when the router boots, R4 gets the route via the frame
> > relay cloud (area 345) as an inTRA-area route.
> > </quote>
> > Your above statement contradicts Your own "sh ip route 150.2.5.5"
> printout
> > from Your email dd 20 Aug 2004 (scroll further down or or see clip
> below):
> > <quote>
> > > > So R4 is watching for 150.2.5.5 in the routing table, which is
> there:
> > > >
> > > > Rack2R4#show ip route 150.2.5.5
> > > >
> > > > Routing entry for 150.2.5.5/32
> > > >
> > > > Known via "ospf 1", distance 110, metric 65, type inter area <===I
> > can clearly see inTER
> > > >
> > > > Last update from 142.2.0.5 on Serial0/0, 01:28:52 ago
> > > >
> > > > Routing Descriptor Blocks:
> > > >
> > > > * 142.2.0.5, from 150.2.5.5, 01:28:52 ago, via Serial0/0
> > > >
> > > > Route metric is 65, traffic share count is 1
> > </quote>
> > Therefore, I would like to see "sh ip route 150.2.5.5" printout from R4
> at
> > every step (BEFORE enabling dialer-watch, after shutting down S0/0,
> after
> > re-enabling S0/0 and after shutting down BRI0/0) as well as full configs
> > on R4 and R5.
> > Having said that, I have a better idea of how to spend Your time before
> > lab - don't put R5' Lo0 into areas 45 or 345, put it into OSPF area,
> say,
> > 1 and see 150.2.5.5/32 route always come to R4 as "O IA", no matter via
> > S0/0 or BRI0/0.
> > Good luck!
> > HTH,
> > Cheers
> > Alex
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> > marc van hoof
> > Sent: 22 August 2004 01:13
> > To: Alexander Arsenyev (GU/ETL); ccielab@groupstudy.com
> > Subject: RE: dialer watch-list - please help !!
> >
> >
> > Alex,
> >
> > The Lo 0 interface of R5 is actually in OSPF area 345.
> >
> > So, basically, when the router boots, R4 gets the route via the frame
> > relay
> > cloud (area 345) as an inTRA-area route.
> >
> > Consequently dialer-watch registers the primary route as UP.
> >
> > Serial 0/0 gets shut down and the isdn circuit comes up.
> >
> > There is a route-map BLOCKING the inTER-area route by matching ip prefix
> > 150.2.5.5 and interface BRI 0/0
> >
> > At this point, NO ROUTE for 150.2.5.5 is present in the routing table.
> >
> > If I re-enable Serial 0/0, the OSPF sessions come back up, but the
> > non-blocked inTRA-area 150.2.5.5 route STILL doesn't appear in the
> routing
> > table. If I shut down BRI 0/0 manually, the 150.2.5.5 inTRA-area route
> > appears again.
> >
> > It's almost as if there is a table of OSPF routes BEFORE they enter the
> > routing table, and before the distribute-list gets applied. So basically
> > R4
> > is obviously still receiving the 150.2.5.5 route over both the frame-
> relay
> > cloud AND the isdn, but the distribute list is just stopping it going
> from
> > the OSPF LSA database into the real routing table.
> >
> > And because they're both present in the OSPF LSA database, the inTER
> area
> > route will ALWAYS take precedence over the inTRA area route, regardless
> of
> > admin distance.
> >
> > It's kind of like how the router builds a main bgp table and then puts
> > stuff
> > in the real routing table and RIB from there...
> >
> > My lab exam is in 4 days, but if I get a chance I'll try filtering the
> > 150.2.5.5 route OUTBOUND from R5 so that R4 is never receiving the
> > inTER-area LSA over the ISDN (area 45). I'm guessing that will solve the
> > problem.
> >
> > -marc.
> >
> >
> > > -----Original Message-----
> > > From: Alexander Arsenyev (GU/ETL)
> > [mailto:alexander.arsenyev@ericsson.com]
> > > Sent: Sunday, 22 August 2004 12:23 AM
> > > To: 'marc van hoof'; ccielab@groupstudy.com
> > > Subject: RE: dialer watch-list - please help !!
> > >
> > > Marc,
> > >
> > > The sequence of events You descibe below fits well into my theory -
> > until
> > > a router LSA/OSPF inTRA area route to 150.2.5.5/32 exists on R4 and is
> > > selected as "best" by OSPF then OSPF IA route cannot enter routing
> > table.
> > > It does not matter that this OSPF inTRA area is blocked by route map
> at
> > > final stage just before being input/fed into routing table, it still
> is
> > > "the best" OSPF route.
> > > When You shut down R4' BRI0/0 then this OSPF inTRA area route
> disappears
> > > because R4 no longer connected to R5 via area 45 and cannot receive
> > router
> > > LSA for 150.2.5.5/32 from R5 over BRI0/0. Then OSPF re-selects best
> > route
> > > for 150.2.5.5/32 on R4 and then it becomes "O IA" route via Serial0/0
> > and
> > > R4' route map no longer blocks it as it does NOT match clause "match
> > > interface BRI0/0".
> > > I think that all these problems exist because You most probably have a
> > > loopback interface on R5 with IP address 150.2.5.5/32 and it belongs
> to
> > > OSPF area 45. Is it a part of scenario to put this loopback in area
> 45?
> > > Could You assign this loopback to a different OSPF area? I believe
> this
> > > problem will go away if You put 150.2.5.5/32 loopback on R5 into area
> 0,
> > > for instance.
> > > HTH,
> > > Cheers
> > > Alex
> > >
> > >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> > > marc van hoof
> > > Sent: 21 August 2004 01:11
> > > To: Alexander Arsenyev (GU/ETL); ccielab@groupstudy.com
> > > Subject: RE: dialer watch-list - please help !!
> > >
> > >
> > > Alex,
> > >
> > > That makes complete sense - thanks for that.
> > >
> > > The thing I don't understand now is why the route does not re-appear
> > when
> > > it's being blocked over the BRI 0/0 and Serial 0/0 comes back up.
> > >
> > > So:
> > > 1) Serial 0/0 is up. 150.2.5.5 is in routing table as intra-area route
> > > 2) Serial 0/0 gets shut down
> > > 3) Dialer watch connects isdn on BRI 0/0
> > > 4) Adjacency and Virtual Link on BRI go to FULL state
> > > 5) 150.2.5.5 route does not enter the routing table as it's being
> > blocked
> > > by
> > > a route-map
> > > 6) Serial 0/0 gets re-enabled
> > > 7) OSPF sessions over Serial 0/0 go to FULL state
> > > 8) 150.2.5.5 route still does not enter the routing table, even though
> > the
> > > only route-map blocking it is trying to 'match interface BRI 0/0'
> > > 9) 150.2.5.5 gets installed in the routing table when BRI 0/0 gets
> shut
> > > down
> > > and hence disconnected.
> > >
> > > In this situation there is no inter-area route installed to take
> > > precedence
> > > - there is NO route in the routing table and it's STILL not being
> > > installed.
> > >
> > > Very weird !!!
> > >
> > > -marc.
> > >
> > > > -----Original Message-----
> > > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> > Of
> > > > Alexander Arsenyev (GU/ETL)
> > > > Sent: Friday, 20 August 2004 11:53 PM
> > > > To: 'marc van hoof'; ccielab@groupstudy.com
> > > > Subject: RE: dialer watch-list - please help !!
> > > >
> > > > Hello,
> > > >
> > > > When Serial0/0 is UP and BRI0/0 is DOWN (initial state) You are
> > getting
> > > > 150.2.5.5/32 as OSPF inter-area route (O IA).
> > > > When Serial0/0 and BRI0/0 are both UP (after You re-enable
> Serial0/0)
> > > You
> > > > are getting 150.2.5.5/32
> > > > as OSPF intra-area route :
> > > > O 150.2.8.8/32 [110/1573] via 142.2.45.5, 00:04:08, BRI0/0
> > > > There is no way OSPF inTRA-area route could be displaced/superceded
> by
> > > > OSPF inTER-area route, You have to rethink
> > > > the solution.
> > > > HTH,
> > > > Cheers
> > > > Alex
> > > >
> > > > -----Original Message-----
> > > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf
> Of
> > > > marc van hoof
> > > > Sent: 20 August 2004 13:44
> > > > To: ccielab@groupstudy.com
> > > > Subject: dialer watch-list - please help !!
> > > >
> > > >
> > > > Hey all,
> > > >
> > > >
> > > >
> > > > I'm having immense problems with a dialer watch list. R4 and R5 are
> > > > connected via ISDN and are both on a frame-relay cloud. R4 is
> watching
> > > > R5's
> > > > loopback address in the routing table with dialer watch.
> > > >
> > > >
> > > >
> > > > So R4 is watching for 150.2.5.5 in the routing table, which is
> there:
> > > >
> > > > Rack2R4#show ip route 150.2.5.5
> > > >
> > > > Routing entry for 150.2.5.5/32
> > > >
> > > > Known via "ospf 1", distance 110, metric 65, type inter area
> > > >
> > > > Last update from 142.2.0.5 on Serial0/0, 01:28:52 ago
> > > >
> > > > Routing Descriptor Blocks:
> > > >
> > > > * 142.2.0.5, from 150.2.5.5, 01:28:52 ago, via Serial0/0
> > > >
> > > > Route metric is 65, traffic share count is 1
> > > >
> > > >
> > > >
> > > > Rack2R4#
> > > >
> > > >
> > > >
> > > > Then I shut down the serial 0/0 interface to get rid of the route
> and
> > > > induce
> > > > the dialer to become active:
> > > >
> > > >
> > > >
> > > > Rack2R4#conf t
> > > >
> > > > Enter configuration commands, one per line. End with CNTL/Z.
> > > >
> > > > Rack2R4(config)#int serial 0/0
> > > >
> > > > Rack2R4(config-if)#shut
> > > >
> > > > Rack2R4(config-if)#
> > > >
> > > > *Mar 1 02:31:16.955: %OSPF-5-ADJCHG: Process 1, Nbr 150.2.5.5 on
> > > > Serial0/0
> > > > from FULL to DOWN, Neighbor Down: Interface down or detached
> > > >
> > > > *Mar 1 02:31:16.955: %OSPF-5-ADJCHG: Process 1, Nbr 150.2.3.3 on
> > > > Serial0/0
> > > > from FULL to DOWN, Neighbor Down: Interface down or detached
> > > >
> > > > *Mar 1 02:31:16.963: DDR: Dialer Watch: watch-group = 1
> > > >
> > > > *Mar 1 02:31:16.963: DDR: network 150.2.5.5/255.255.255.255
> > > DOWN,
> > > >
> > > > *Mar 1 02:31:16.963: DDR: primary DOWN
> > > >
> > > > *Mar 1 02:31:16.963: DDR: Dialer Watch: Dial Reason: Primary of
> group
> > 1
> > > > DOWN
> > > >
> > > > *Mar 1 02:31:16.963: DDR: Dialer Watch: watch-group = 1,
> > > >
> > > > *Mar 1 02:31:16.963: DDR: dialing secondary by dialer map
> > > > 150.2.5.5
> > > > on BR0/0
> > > >
> > > > *Mar 1 02:31:16.963: BR0/0 DDR: Attempting to dial 8358662
> > > >
> > > > *Mar 1 02:31:17.311: %LINK-3-UPDOWN: Interface BRI0/0:1, changed
> > state
> > > to
> > > > up
> > > >
> > > > *Mar 1 02:31:17.311: BR0/0:1 DDR: Dialer Watch: resetting call in
> > > > progress
> > > >
> > > > *Mar 1 02:31:17.375: BR0/0:1 DDR: dialer protocol up
> > > >
> > > > *Mar 1 02:31:18.363: %LINEPROTO-5-UPDOWN: Line protocol on
> Interface
> > > > BRI0/0:1, changed state to up
> > > >
> > > > *Mar 1 02:31:18.955: %LINK-5-CHANGED: Interface Serial0/0, changed
> > > state
> > > > to
> > > > administratively down
> > > >
> > > > *Mar 1 02:31:19.955: %LINEPROTO-5-UPDOWN: Line protocol on
> Interface
> > > > Serial0/0, changed state to down
> > > >
> > > > *Mar 1 02:31:23.311: %ISDN-6-CONNECT: Interface BRI0/0:1 is now
> > > connected
> > > > to 8358662 ROUTER5
> > > >
> > > > *Mar 1 02:31:26.379: %OSPF-5-ADJCHG: Process 1, Nbr 150.2.5.5 on
> > BRI0/0
> > > > from LOADING to FULL, Loading Done
> > > >
> > > > Rack2R4(config-if)#exit
> > > >
> > > > Rack2R4(config)#exit
> > > >
> > > > Rack2R4#show ip
> > > >
> > > > *Mar 1 02:31:33.019: %SYS-5-CONFIG_I: Configured from console by
> > > console
> > > >
> > > > Rack2R4#show ip route 150.2.5.5
> > > >
> > > > % Subnet not in table
> > > >
> > > > *Mar 1 02:31:42.671: %OSPF-5-ADJCHG: Process 1, Nbr 150.2.5.5 on
> > > OSPF_VL1
> > > > from LOADING to FULL, Loading Done
> > > >
> > > > !
> > > >
> > > >
> > > >
> > > > There is an ospf virtual-link set up over the dialer, to ensure that
> > R4
> > > > maintains a connection to area 0 (the area of the isdn connection is
> > > area
> > > > 45), and there is a distribute-list route-map applied to the ospf
> > > instance
> > > > on R4 inbound to ensure that R4 doesn't receive the "watched route"
> > over
> > > > the
> > > > isdn circuit.
> > > >
> > > >
> > > >
> > > > Rack2R4#show ip route 150.2.5.5
> > > >
> > > > % Subnet not in table
> > > >
> > > > Rack2R4#
> > > >
> > > >
> > > >
> > > > So far so good.
> > > >
> > > >
> > > >
> > > > Now watch this. I re-enable the serial 0/0 interface and the ospf
> > > sessions
> > > > across it come back up... but no route to 150.2.5.5
> > > >
> > > >
> > > >
> > > > Rack2R4#conf t
> > > >
> > > > Enter configuration commands, one per line. End with CNTL/Z.
> > > >
> > > > Rack2R4(config)#int serial 0/0
> > > >
> > > > Rack2R4(config-if)#no shut
> > > >
> > > > Rack2R4(config-if)#
> > > >
> > > > *Mar 1 02:34:45.287: %LINK-3-UPDOWN: Interface Serial0/0, changed
> > state
> > > > to
> > > > up
> > > >
> > > > *Mar 1 02:34:46.287: %LINEPROTO-5-UPDOWN: Line protocol on
> Interface
> > > > Serial0/0, changed state to up
> > > >
> > > > Rack2R4(config-if)#
> > > >
> > > > *Mar 1 02:35:17.311: BR0/0:1 DDR: idle timeout
> > > >
> > > > *Mar 1 02:35:17.311: DDR: Dialer Watch: watch-group = 1
> > > >
> > > > *Mar 1 02:35:17.311: DDR: network 150.2.5.5/255.255.255.255
> > > DOWN,
> > > >
> > > > *Mar 1 02:35:17.311: DDR: primary DOWN
> > > >
> > > > Rack2R4(config-if)#
> > > >
> > > > *Mar 1 02:35:24.315: %OSPF-5-ADJCHG: Process 1, Nbr 150.2.3.3 on
> > > > Serial0/0
> > > > from LOADING to FULL, Loading Done
> > > >
> > > > Rack2R4(config-if)#
> > > >
> > > > *Mar 1 02:35:35.163: %OSPF-5-ADJCHG: Process 1, Nbr 150.2.5.5 on
> > > > Serial0/0
> > > > from LOADING to FULL, Loading Done
> > > >
> > > > Rack2R4(config-if)#do show ip route ospf
> > > >
> > > > 142.2.0.0/16 is variably subnetted, 9 subnets, 2 masks
> > > >
> > > > O IA 142.2.5.0/24 [110/1572] via 142.2.45.5, 00:00:26, BRI0/0
> > > >
> > > > O 142.2.0.5/32 [110/64] via 142.2.0.5, 00:00:26, Serial0/0
> > > >
> > > > O 142.2.0.3/32 [110/64] via 142.2.0.3, 00:00:26, Serial0/0
> > > >
> > > > O 142.2.58.0/24 [110/1572] via 142.2.45.5, 00:04:08, BRI0/0
> > > >
> > > > 150.2.0.0/16 is variably subnetted, 2 subnets, 2 masks
> > > >
> > > > O 150.2.8.8/32 [110/1573] via 142.2.45.5, 00:04:08, BRI0/0
> > > >
> > > > Rack2R4(config-if)#
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > It stays like this and consequently doesn't shut down the isdn link
> > due
> > > to
> > > > the dialer watch still being active. if I manually shutdown the bri
> > > > interface, the route entry appears again.
> > > >
> > > >
> > > >
> > > > Rack2R4(config-if)#int bri 0/0
> > > >
> > > > Rack2R4(config-if)#shut
> > > >
> > > > Rack2R4(config-if)#
> > > >
> > > > *Mar 1 02:37:33.447: %LINK-3-UPDOWN: Interface BRI0/0:1, changed
> > state
> > > to
> > > > down
> > > >
> > > > *Mar 1 02:37:33.447: %ISDN-6-LAYER2DOWN: Layer 2 for Interface
> BR0/0,
> > > TEI
> > > > 120 changed to down
> > > >
> > > > *Mar 1 02:37:33.447: %ISDN-6-LAYER2DOWN: Layer 2 for Interface
> BR0/0,
> > > TEI
> > > > 121 changed to down
> > > >
> > > > *Mar 1 02:37:33.451: BR0/0:1 DDR: disconnecting call
> > > >
> > > > *Mar 1 02:37:33.451: BR0/0:1 DDR: Dialer Watch: resetting call in
> > > > progress
> > > >
> > > > *Mar 1 02:37:33.451: DDR: Dialer Watch: watch-group = 1
> > > >
> > > > *Mar 1 02:37:33.451: DDR: network 150.2.5.5/255.255.255.255
> > > DOWN,
> > > >
> > > > *Mar 1 02:37:33.451: DDR: primary DOWN
> > > >
> > > > *Mar 1 02:37:33.451: DDR: Dialer Watch: Dial Reason: Secondary of
> > group
> > > 1
> > > > DOWN
> > > >
> > > > *Mar 1 02:37:33.451: DDR: Dialer Watch: watch-group = 1,
> > > >
> > > > *Mar 1 02:37:33.451: DDR: Dialer Watch: No free dialer on BR0/0
> > > >
> > > > *Mar 1 02:37:33.451: %OSPF-5-ADJCHG: Process 1, Nbr 150.2.5.5 on
> > BRI0/0
> > > > from FULL to DOWN, Neighbor Down: Interface down or detached
> > > >
> > > > *Mar 1 02:37:33.463: %LINK-3-UPDOWN: Interface BRI0/0:1, changed
> > state
> > > to
> > > > do
> > > >
> > > > Rack2R4(configwn
> > > >
> > > > *Mar 1 02:37:33.467: BR0/0:1 DDR: disconnecting call
> > > >
> > > > *Mar 1 02:37:33.467: DDR: Dialer Watch: watch-group = 1
> > > >
> > > > *Mar 1 02:37:33.467: DDR: network 150.2.5.5/255.255.255.255
> > > DOWN,
> > > >
> > > > *Mar 1 02:37:33.467: DDR: primary DOWN
> > > >
> > > > *Mar 1 02:37:33.467: DDR: Dialer Watch: Dial Reason: Secondary of
> > group
> > > 1
> > > > DOWN
> > > >
> > > > *Mar 1 02:37:33.467: DDR: Dialer Watch: watch-group = 1,
> > > >
> > > > *Mar 1 02:37:33.467: DDR: Dialer Watch: No free dialer on BR0/0
> > > >
> > > > *Mar 1 02:37:33.499: %LINK-5-CHANGED: Interface BRI0/0, changed
> state
> > > to
> > > > administratively down
> > > >
> > > > *Mar 1 02:37:33.499: %LINK-3-UPDOWN: Interface BRI0/0:2, changed
> > state
> > > to
> > > > down
> > > >
> > > > *Mar 1 02:37:33.499: BR0/0:2 DDR: disconnecting call
> > > >
> > > > *Mar 1 02:37:33.499: DDR: Dialer Watch: watch-group = 1
> > > >
> > > > *Mar 1 02:37:33.499: DDR: network 150.2.5.5/255.255.255.255
> > > DOWN,
> > > >
> > > > *Mar 1 02:37:33.499: DDR: primary DOWN
> > > >
> > > > *Mar 1 02:37:33.499: DDR: Dialer Watch: Dial Reason: Secondary of
> > group
> > > 1
> > > > DOWN
> > > >
> > > > *Mar 1 02:37:33.499: DDR: Dialer Watch: watch-group = 1,
> > > >
> > > > *Mar 1 02:37:33.499: DDR: Dialer Watch: No free dialer on BR0/0
> > > >
> > > > *Mar 1 02:37:34.447: %LINEPROTO-5-UPDOWN: Line protocol on
> Interface
> > > > BRI0/0:1, changed state to down-if)#
> > > >
> > > > Rack2R4(config-if)#do show ip r
> > > >
> > > > *Mar 1 02:37:38.951: %OSPF-5-ADJCHG: Process 1, Nbr 150.2.5.5 on
> > > OSPF_VL1
> > > > from FULL to DOWN, Neighbor Down: Interface down or detached
> > > >
> > > > Rack2R4(config-if)#do show ip route 150.2.5.5
> > > >
> > > > Routing entry for 150.2.5.5/32
> > > >
> > > > Known via "ospf 1", distance 110, metric 65, type inter area
> > > >
> > > > Last update from 142.2.0.5 on Serial0/0, 00:00:06 ago
> > > >
> > > > Routing Descriptor Blocks:
> > > >
> > > > * 142.2.0.5, from 150.2.5.5, 00:00:06 ago, via Serial0/0
> > > >
> > > > Route metric is 65, traffic share count is 1
> > > >
> > > >
> > > >
> > > > Rack2R4(config-if)#
> > > >
> > > > *Mar 1 02:37:48.959: DDR: Dialer Watch: watch-group = 1
> > > >
> > > > *Mar 1 02:37:48.959: DDR: network 150.2.5.5/255.255.255.255
> > UP,
> > > >
> > > > *Mar 1 02:37:48.963: DDR: primary UP
> > > >
> > > > Rack2R4(config-if)#
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Configs are attached below.
> > > >
> > > >
> > > >
> > > > Thanks heaps for any help,
> > > >
> > > >
> > > >
> > > > -marc.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > !
> > > >
> > > > interface Serial0/0
> > > >
> > > > ip address 142.2.0.4 255.255.255.0
> > > >
> > > > encapsulation frame-relay
> > > >
> > > > ip ospf authentication
> > > >
> > > > ip ospf authentication-key CISCO
> > > >
> > > > ip ospf network point-to-multipoint
> > > >
> > > > ip ospf flood-reduction
> > > >
> > > > frame-relay map ip 142.2.0.3 413 broadcast
> > > >
> > > > frame-relay map ip 142.2.0.5 405 broadcast
> > > >
> > > > no frame-relay inverse-arp
> > > >
> > > > frame-relay lmi-type cisco
> > > >
> > > > !
> > > >
> > > > interface BRI0/0
> > > >
> > > > ip address 142.2.45.4 255.255.255.0
> > > >
> > > > encapsulation ppp
> > > >
> > > > dialer map ip 142.2.45.5 name ROUTER5 broadcast 8358662
> > > >
> > > > dialer map ip 150.2.5.5 name ROUTER5 broadcast 8358662
> > > >
> > > > dialer watch-group 1
> > > >
> > > > isdn switch-type basic-ni
> > > >
> > > > isdn spid1 .
> > > >
> > > > isdn spid2 .
> > > >
> > > > ppp authentication eap callin
> > > >
> > > > ppp eap identity ROUTER4
> > > >
> > > > ppp eap password 0 CISCO
> > > >
> > > > ppp eap local
> > > >
> > > > !
> > > >
> > > >
> > > >
> > > > router ospf 1
> > > >
> > > > router-id 150.2.4.4
> > > >
> > > > max-metric router-lsa on-startup 600
> > > >
> > > > log-adjacency-changes
> > > >
> > > > area 45 virtual-link 150.2.5.5 authentication message-digest
> > > >
> > > > area 45 virtual-link 150.2.5.5 message-digest-key 1 md5 CISCO
> > > >
> > > > area 45 virtual-link 150.1.5.5
> > > >
> > > > network 142.2.0.4 0.0.0.0 area 345
> > > >
> > > > network 142.2.45.4 0.0.0.0 area 45
> > > >
> > > > network 150.2.4.4 0.0.0.0 area 45
> > > >
> > > > distribute-list route-map FILTER_R5_LOOPBACK in
> > > >
> > > > !
> > > >
> > > >
> > > >
> > > > ip prefix-list R5_LOOPBACK seq 5 permit 150.2.5.5/32
> > > >
> > > > !
> > > >
> > > > dialer watch-list 1 ip 150.2.5.5 255.255.255.255
> > > >
> > > > dialer-list 1 protocol ip permit
> > > >
> > > > !
> > > >
> > > > route-map FILTER_R5_LOOPBACK deny 10
> > > >
> > > > match ip address prefix-list R5_LOOPBACK
> > > >
> > > > match interface BRI0/0
> > > >
> > > > !
> > > >
> > > > route-map FILTER_R5_LOOPBACK permit 20
> > > >
> > > > !
> > > >
> > > > !
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:47 GMT-3