From: Richard Dumoulin (Richard.Dumoulin@vanco.fr)
Date: Wed Sep 08 2004 - 16:31:29 GMT-3
James, R5's Fast0/0 could be down but R3's Fast 0/0 not. How could R3 know
if R5's Ethernet is down ?
We have ISIS already. A pity that ISIS on demand does not exists :)
--Richard
-----Message d'origine-----
De : James [mailto:james@towardex.com]
Envoyi : Wednesday, September 08, 2004 9:08 PM
@ : Richard Dumoulin
Cc : Kenneth Wygand; john matijevic; ccielab@groupstudy.com
Objet : Re: RE : RE : RE : Lab6 Cisco r&s Prac Labs ISDN wording
On Wed, Sep 08, 2004 at 08:01:14PM +0100, Richard Dumoulin wrote:
> The requirement is "...when R5 fast0/0 goes down...".
> R3 is connected to the same Ethernet segment as R5 so R3 won't be able to
> know if R5 Fast is down because it can learn R5's routes via another frame
> relay interface.
The fa0/0 of R5 is also fa0/0 of R3, both sitting on the same ethernet
network
with ISDN circuit suppose to be "backup."
>
> I still don't like watching a connected interface but I don't see any
reason
> to not use it ! Is there any one ? If not then we only need the
equivalent
> commands of backup delay to fulfill the same requirements as the backup
> command and even more !!!
I think this question is just a little bit messy in the wording :P
But, since we like challenges however..
The dialer-watch idea I think is shot down upon realization that both
routers
share the same connected network.
How about running OSPF w/ demand circuit in between, in a totally seperate
process and its own area 0 accross the ISDN, so that topology changes on the
primary ospf network in R3 won't trigger the ISDN activation. But FA0/0
outage on R5 would, which would then cause CLNS to establish adjacency..?
Thanks again!
-J
>
> --Richard
>
> -----Message d'origine-----
> De : Kenneth Wygand [mailto:KWygand@customonline.com]
> Envoy? : Wednesday, September 08, 2004 8:54 PM
> ? : Richard Dumoulin; James
> Cc : john matijevic; ccielab@groupstudy.com
> Objet : RE: RE : RE : Lab6 Cisco r&s Prac Labs ISDN wording
>
> Since I don't have the lab in front of me (but I did buy the book and
> studied from it and liked it), does it say which side has to do the
dialing?
> Otherwise, you could have the other side watch the network so you don't
have
> to watch a directly-connected network.
>
> Kenneth E. Wygand
> Systems Engineer, Project Services
> CCIE #13720, CISSP #37102, CCNP/DP, ACSP,
> Cisco IPT Design Specialist, MCP, CNA, Network+, A+
> Custom Computer Specialists, Inc.
> "Failure only occurs at the point in which one stops trying."
> -Anonymous
>
> Custom Computer Specialists, Inc.
> "Celebrating 25 Years of Excellence"
>
> -----Original Message-----
> From: Richard Dumoulin [mailto:Richard.Dumoulin@vanco.fr]
> Sent: Wednesday, September 08, 2004 2:51 PM
> To: Kenneth Wygand; James
> Cc: john matijevic; ccielab@groupstudy.com
> Subject: RE : RE : Lab6 Cisco r&s Prac Labs ISDN wording
>
> Kenneth, you passed before the book was edited I think :)
> "CCIE Routing and Switching Practice Labs".
> James,
> it does not say "must" but "should only pass a routing protocol if
fast0/0
> is down".
> But yes, I think you are right and dialer watch should do the job.
Although
> I find it weird to watch a directly connected interface. Is this good
> practice ?
> --Richard
> -----Message d'origine-----
> De : Kenneth Wygand [mailto:KWygand@customonline.com
> <mailto:KWygand@customonline.com> ]
> Envoy? : Wednesday, September 08, 2004 8:44 PM
> ? : James; Richard Dumoulin
> Cc : john matijevic; ccielab@groupstudy.com
> Objet : RE: RE : Lab6 Cisco r&s Prac Labs ISDN wording
> James,
> Which practice lab workbook is this from? I've purchased almost all of
> them so I should be able to reference the diagram to answer your
> question.
> Thanks! :)
> Kenneth E. Wygand
> Systems Engineer, Project Services
> CCIE #13720, CISSP #37102, CCNP/DP, ACSP,
> Cisco IPT Design Specialist, MCP, CNA, Network+, A+
> Custom Computer Specialists, Inc.
> "Failure only occurs at the point in which one stops trying."
> -Anonymous
> Custom Computer Specialists, Inc.
> "Celebrating 25 Years of Excellence"
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com
> <mailto:nobody@groupstudy.com> ] On Behalf Of
> James
> Sent: Wednesday, September 08, 2004 2:38 PM
> To: Richard Dumoulin
> Cc: john matijevic; ccielab@groupstudy.com
> Subject: Re: RE : Lab6 Cisco r&s Prac Labs ISDN wording
> On Wed, Sep 08, 2004 at 07:32:17PM +0100, Richard Dumoulin wrote:
> > Hi John, the problem with using the backup command is you are breaking
> the
> > requirement "...R3 and R5 should be able to ping each other..."
> >
> > After reading his explanation I have come to the conclusion that it is
> not
> > really a backup solution the author is asking for, nor is there a
> > requirement for it. We can see in the breakdown solution that ISIS
> only goes
> > through the isdn line once he pings through the bri interfaces so he
> is
> > effectively fulfilling all his requirements.
> But ISIS must activate when fa0/0 goes down? :P
> I am pretty new in the ISDN field as my experience never used it in the
> past. So I ask -- would using dialer-watch also prevent pinging accross
> the
> ISDN circuit when fa0/0 is up and running, like backup command does?
> Thanks for all the good replies!
> -J
> >
> > --Richard
> >
> > -----Message d'origine-----
> > De : john matijevic [mailto:matijevi@bellsouth.net
> <mailto:matijevi@bellsouth.net> ]
> > Envoyi : Wednesday, September 08, 2004 6:00 PM
> > @ : 'James'; ccielab@groupstudy.com
> > Objet : RE: Lab6 Cisco r&s Prac Labs ISDN wording
> >
> > Hello James,
> > Yes this is an error in the book, please visit my forum, as there are
> > many errors already pointed out there, already. Backup interface is
> the
> > solution I used as well.
> >
> > Sincerely,
> >
> > John Matijevic, CCIE #13254, MCSE, CNE, CCEA
> > CEO
> > IgorTek Inc.
> > 151 Crandon Blvd. #402
> > Key Biscayne, FL 33149
> > Hablo Espanol
> > 305-321-6232
> > http://home.bellsouth.net/p/PWP-CCIE
> <http://home.bellsouth.net/p/PWP-CCIE>
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com
> <mailto:nobody@groupstudy.com> ] On Behalf
> Of
> > James
> > Sent: Wednesday, September 08, 2004 3:23 AM
> > To: ccielab@groupstudy.com
> > Subject: Lab6 Cisco r&s Prac Labs ISDN wording
> >
> > In Lab 6 on practice labs , under ISDN, we see the following:
> >
> > "Make sure that yourrouting proto is passed accross the isdn link only
> > when
> > the connectivity is established"
> >
> > In order to accomplish the above, we simply make sure 'dialer-list 1
> > proto
> > clns permit', and ensure that "clns_is" is not included -- thereby
> > making
> > ISIS establish adjacency only when ISDN circuit is already up and
> > running.
> > So far so good. (well also ensuring dialer map clns yadda yadda..)
> >
> > "The ISDN link should only pass a routing protocol if R5-fa0/0 is
> down."
> >
> > Now.. it says ISDN should pass routing protocol when fa0/0 on R5 is
> > down.
> > That is good and all when FA0/0 sudden goes down while ISDN is already
> > dialed
> > and running. But what happens when ISDN is NOT dialed and turned off
> > (due to
> > idle traffic)?? The previous requirement says that isdn must only
> > establish
> > ISIS protocol when the circuit is already dialed and running.
> >
> > So the thought process here in my head is to use 'backup interface' on
> > fa0/0
> > or another mechanism that will trigger ISDN to dial itself during
> fa0/0
> > outage.
> > This will ensure ISIS will establish adjacency then, after fa0/0
> outage,
> > since backup interface brought up the ISDN circuit physically.
> >
> > But the solution in the book made no configuration changes for this
> > requirement.
> >
> > Well, not making any config changes for this requirement works well
> when
> > the
> > isdn is already dialed and up and running, but guarantees nothing when
> > proctor
> > reboots your routers and isdn is shut down at boot time :(
> >
> > Any ideas, clues?
> >
> > Thanks,
> > -J
> > --
> > James Jun TowardEX
> > Technologies, Inc.
> > Technical Lead Network Design, Consulting, IT
> > Outsourcing
> > james@towardex.com Boston-based Colocation &
> Bandwidth
> > Services
> > cell: 1(978)-394-2867 web: http://www.towardex.com
> <http://www.towardex.com> , noc:
> > www.twdx.net
> >
> >
> _______________________________________________________________________
> > Please help support GroupStudy by purchasing your study materials
> from:
> > http://shop.groupstudy.com <http://shop.groupstudy.com>
> >
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> <http://www.groupstudy.com/list/CCIELab.html>
> >
> >
> _______________________________________________________________________
> > Please help support GroupStudy by purchasing your study materials
> from:
> > http://shop.groupstudy.com <http://shop.groupstudy.com>
> >
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> <http://www.groupstudy.com/list/CCIELab.html>
> >
> >
> > **********************************************************************
> > Any opinions expressed in the email are those of the individual and
> not
> > necessarily the company. This email and any files transmitted with it
> are
> > confidential and solely for the use of the intended recipient. If you
> are not
> > the intended recipient or the person responsible for delivering it to
> the
> > intended recipient, be advised that you have received this email in
> error and
> > that any dissemination, distribution, copying or use is strictly
> prohibited.
> >
> > If you have received this email in error, or if you are concerned with
> the
> > content of this email please e-mail to: e-security.support@vanco.info
> >
> > The contents of an attachment to this e-mail may contain software
> viruses
> > which could damage your own computer system. While the sender has
> taken every
> > reasonable precaution to minimise this risk, we cannot accept
> liability for
> > any damage which you sustain as a result of software viruses. You
> should carry
> > out your own virus checks before opening any attachments to this
> e-mail.
> > **********************************************************************
> >
> >
> _______________________________________________________________________
> > Please help support GroupStudy by purchasing your study materials
> from:
> > http://shop.groupstudy.com <http://shop.groupstudy.com>
> >
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> <http://www.groupstudy.com/list/CCIELab.html>
> --
> James Jun TowardEX
> Technologies, Inc.
> Technical Lead Network Design, Consulting, IT
> Outsourcing
> james@towardex.com Boston-based Colocation & Bandwidth
> Services
> cell: 1(978)-394-2867 web: http://www.towardex.com
> <http://www.towardex.com> , noc:
> www.twdx.net
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com <http://shop.groupstudy.com>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
> <http://www.groupstudy.com/list/CCIELab.html>
-- James Jun TowardEX Technologies, Inc. Technical Lead Network Design, Consulting, IT Outsourcing james@towardex.com Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
This archive was generated by hypermail 2.1.4 : Fri Oct 01 2004 - 15:00:40 GMT-3