OK, the thread's a bit dead now, but for anyone who's interested, Rick and I had
a bit of an offline discussion on this one. Thought it might be of interest to
some (possibly even the original poster...)
JMcL
>
>
> Rick Burts <[EMAIL PROTECTED]> on 20/07/2000 15:40:25
>
>
> To: JENNY MCLEOD/NSO/CSDA@NOTES
> cc:
> Subject: RE: OSPF On Demand Circuit
>
>
>
> One of the requirements/assumptions of OSPF Demand Circuit is that the
> routers can bring up the circuit to form a neighbor relationship, bring
> up the circuit to transmit state change LSAs (but not Hellos or periodic
> refresh) and bring up the circuit to transmit data as needed.
>
> I think that may make it less desirable as a backup strategy, though lots
> of people keep talking about Demand Circuit as a backup strategy. If you
> want the ISDN as strictly backup and want to really minimize how often it
> is brought up, I think floating statics and a good dialer list would be
> better.
>
> Rick
>
> On Thu, 20 Jul 2000 [EMAIL PROTECTED] wrote:
>
> >
> >
> > I had missed that bit of the config. However, in my suggested solution, it
is
> > assumed that the link will come up more or less straight away anyway when
the
> > frame relay link dies due to other traffic triggering the ISDN link. The
link
> > is only being used as a backup to the FR, according to the original post, so
I
> > don't think you'd want it triggered every time there is a topology change -
> the
> > other router should generally know about the change via the FR link anyway.
> >
> > I haven't dealt with OSPF demand circuits much, but perhaps it would be
better
> > to not make the ISDN link a demand circuit? If the ISDN is only a backup to
> the
> > FR, does demand circuit gain anything over a well-constructed dialer list?
> >
> > JMcL
> >
> >
> >
> >
> > Rick Burts <[EMAIL PROTECTED]> on 20/07/2000 11:19:55
> >
> >
> > To: JENNY MCLEOD/NSO/CSDA@NOTES
> > cc:
> > Subject: RE: OSPF On Demand Circuit
> >
> >
> >
> > One of the requirements of OSPF Demand Circuit is that any real LSA update
> > must be able to bring up the connection and transmit the update to the
> > neighbor. (Hellos and periodic refresh are suppressed) In your
> > suggested solution, how will a real state change LSA bring up the link
> > when you deny ospf any any ?
> >
> > Rick
> >
> > On Thu, 20 Jul 2000 [EMAIL PROTECTED] wrote:
> >
> > >
> > >
> > > If we go right back to the question of 'what problem are you trying to
> solve'
> > (I
> > > think this has become the official groupstudy motto :-), everything is
> working
> > > fine except that the dialup link is triggering when it's not supposed to.
> > > So, following the other useful principle of KISS (Keep It Simple, S*****),
> we
> > > shouldn't need to muck around with the routing protocols themselves.
> Passive
> > > interfaces and snapshot routing protocols are both (probably) overkill.
> > >
> > > How do you specify what brings up the link? A dialer-list statement. The
> > > original post didn't show what dialer-list is configured, and I haven't
seen
> > any
> > > posts stating the outcome of a 'dialer debug' or 'show dialer' (show
dialer
> > when
> > > the call is up will show what triggered the call), but OSPF updates do
sound
> > > like a likely candidate for what is triggering the link.
> > >
> > > So, assuming that investigation shows that it really is OSPF that's
causing
> > the
> > > ISDN to dial, we want the solution that will cause the least side effects
-
> > > don't forget that everything else is working fine now.
> > >
> > > Making a passive interface or introducing snapshot routing will stop (or
at
> > > least change) routing across the dialup link, which could cause other
> > problems.
> > > But if the dialer-list statement excludes OSPF, it won't stop OSPF across
> the
> > > link, it'll just stop it triggering dialup.
> > >
> > > Something like the following should help. It may need changes depending
on
> > what
> > > the existing dialer-list is.
> > >
> > > access-list 101 deny ospf any any
> > > access-list 101 permit ip any any
> > > dialer-list 1 protocol ip list 101
> > >
> > > JMcL
> > >
> > > ---------------------- Forwarded by Jenny Mcleod/NSO/CSDA on 20/07/2000
> 08:49
> > > ---------------------------
> > >
> > >
> > > "Ruslan S Tchinyakov" <[EMAIL PROTECTED]> on 19/07/2000
19:12:04
> > >
> > > Please respond to "Ruslan S Tchinyakov" <[EMAIL PROTECTED]>
> > >
> > >
> > > To: "'McCallum, Robert'" <[EMAIL PROTECTED]>
> > > "'Ruslan S Tchinyakov'" <[EMAIL PROTECTED]>
> > > "'Olden Pieterse'" <[EMAIL PROTECTED]>
> > > "'Evan You'" <[EMAIL PROTECTED]>
> > > cc: [EMAIL PROTECTED] (bcc: JENNY MCLEOD/NSO/CSDA)
> > > Subject: RE: OSPF On Demand Circuit
> > >
> > >
> > >
> > > Shapshot Routing is for DV protocols only!!
> > > It breaks OSPF and others LS protocols.
> > >
> > > Ruslan Tchinyakov,
> > > CCNP+Security, CCDP, MCSE
> > >
> > >
> > > -----Original Message-----
> > > From: McCallum, Robert [mailto:[EMAIL PROTECTED]]
> > > Sent: Wednesday, July 19, 2000 12:47 PM
> > > To: 'Ruslan S Tchinyakov'; 'Olden Pieterse'; 'Evan You'
> > > Cc: [EMAIL PROTECTED]
> > > Subject: RE: OSPF On Demand Circuit
> > >
> > >
> > > Also if you make your interface a passive interface then you will NOT pass
> > > routing updates across the link. What you should do is Snapshot Routing.
> > > Put in a static route across this line and give it a higher admin distance
> > > i.e. 180. Then when the primary link fails the static route will takeover
> > > and your backup timers will bring up the link.
> > >
> > > -----Original Message-----
> > > From: Ruslan S Tchinyakov [mailto:[EMAIL PROTECTED]]
> > > Sent: 19 July 2000 09:00
> > > To: 'Olden Pieterse'; 'Evan You'
> > > Cc: [EMAIL PROTECTED]
> > > Subject: RE: OSPF On Demand Circuit
> > >
> > >
> > > In OSPF unlike DV protocols (including EIGRP) the router should have
> > > COMPLETE vision of the network. So distribute-lists and passive interfaces
> > > can breake all routing at once.
> > >
> > > Regards, Ruslan Tchinyakov,
> > > CCNP, CCDP,MCSE
> > >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Olden
> > > Pieterse
> > > Sent: Tuesday, July 18, 2000 7:55 PM
> > > To: 'Evan You'
> > > Cc: '[EMAIL PROTECTED]'
> > > Subject: RE: OSPF On Demand Circuit
> > >
> > >
> > > Hi there
> > > My 2 cents ...
> > > Try and put passive interface on your bri0 so it doesnt send out routing
> > > updates .
> > > Some updates (routing ???) is bringing up that line .
> > >
> > > Hope it helps
> > > Cheers
> > > Olden
> > >
> > > -----Original Message-----
> > > From: Evan You [mailto:[EMAIL PROTECTED]]
> > > Sent: Tuesday, July 18, 2000 5:33 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: OSPF On Demand Circuit
> > >
> > >
> > > Hey all,
> > >
> > > I have two routers in OSPF Area 0 that have ISDN backup connections from
one
> > > to the other.
> > >
> > > The ISDN config is working great. When the primary FR link goes down, the
> > > ISDN kicks in instantly and it dies when the primary link goes back up. My
> > > dilemma is that even though the primary FR link is up, the ISDN link goes
up
> > > every few minutes.
> > >
> > > I've configured EIGRP DDR scenarios and had to use Access-list to control
> > > EIGRP traffic over the BRI interface. Is it the same with OSPF? What can
be
> > > causing the ISDN BRI to go up every few minutes?
> > >
> > > The routers are currently running:
> > > OSPF
> > > IP
> > > Frame Relay
> > > And nothing else!
> > >
> > > interface BRI0
> > > ip address 212.1.22.34 255.255.255.240
> > > encapsulation ppp
> > > ip ospf cost 200
> > > ip ospf demand-circuit
> > > bandwidth 64000
> > > isdn spid1 xxxxxxxxx xxxxx
> > > dialer idle-timeout 180
> > > dialer map ip 212.1.22.33 name R2 broadcast xxxxxxx
> > > dialer hold-queue 75
> > > dialer-group 1
> > > no cdp enable
> > > ppp authentication chap
> > >
> > >
> > > Thanks,
> > >
> > > Evan You - CCNA
> > >
> > > ___________________________________
> > >
> >
> > Rick Burts, CCSI CCIE 4615 [EMAIL PROTECTED]
> > Mentor Technologies 410-280-8840 ex 3015
> > 275 West Street 410-280-8859 fax
> > Plaza 70
> > Annapolis, Md 21401
> >
> > Chesapeake Network Solutions has now become Mentor Technologies.
> > Mentor Technologies is a certified Cisco Training Partner and also
> > a Cisco Professional Services partner.
> > We offer most of the Cisco training courses.
> > We also offer training in Checkpoint Firewall software and
> > Fore Systems (now Marconi) and MicroMuse.
> > We also provide network consulting services including
> > design, management, and problem solving.
> > We have 28 CCIEs on our staff.
> >
> >
> >
> >
>
>
>
___________________________________
UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
FAQ, list archives, and subscription info: http://www.groupstudy.com
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
