From: Alexander Arsenyev (GU/ETL) (alexander.arsenyev@ericsson.com)
Date: Sun Aug 22 2004 - 04:13:23 GMT-3
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