From: Steven Weber (itweber@xxxxxxxxxxx)
Date: Sun Feb 04 2001 - 17:32:44 GMT-3
I'm not exactly sure on how your scenario is working but when you have a DR/BDR
election only these two routers will be in the FULL state with each of the othe
r
routers but all of the other routers will be in the 2WAY state with each other
and only have a FULL connection to the DR/BDR.
Hope I helped : )
Steve
Nigel Taylor wrote:
> Frank,
> I noticed this... but I was under the impression that this was a
> typo... Based on the topology map I see that the drawing has R2 connecting
> to each spoke. But, looking at config for R1 in the solution it makes use
> of the full mesh. In my config I'm using frame mappings from r3 to r2 and
> r3 to r4. So with the config as they have it you cannot loose the frame
> conn. from R2 to the cloud or R2 and R3 is isolated from the network.......
>
> What I'm also trying to work out is the reasoning behind not using the full
> mesh to provide connectivity in the event that r2 looses the frame circuit.
> Also why make it the hub..? Wouldn't R4 be a better choice for being a hub
> since it physically connected to the rest of the network....?
>
> Another thing I observed was the frame cloud is configured as a broadcast
> cloud but the "ip ospf priority" assigned to r3 and r4 uses a value of "0".
> This is doesn't allow a DR to elected on the segment when r2 lost it's frame
> connection to the cloud.....
>
> Well, I think these labs are a good resource but I must remember they are
> "FREE". I'm I thinking to much here or does the lab requirements not
> provide a clear outline as to the requirements....? Can someone read the
> Lab sheet and tell me if it's clear as to how the solution provided makes
> sense and completes the requirements..
>
> Nigel..
>
> ----- Original Message -----
> From: Frank Liang <liangfrank@hotmail.com>
> To: <nigel_taylor@hotmail.com>; <Justin.Menga@computerland.co.nz>;
> <fwells12@hotmail.com>; <ccielab@groupstudy.com>
> Sent: Sunday, February 04, 2001 1:51 PM
> Subject: Re: ISDN questions ...!
>
> > Nigel,
> > by looking at the fatkid 401 diagram, the frame cloud is hub and spoke. If
> you look at the solution, on R3, it maps r2 and r4 ip address to the same
> dlci 102. R2 is a hub!
> >
> > FL
> >
> > >From: "Nigel Taylor" <nigel_taylor@hotmail.com>
> > >Reply-To: "Nigel Taylor" <nigel_taylor@hotmail.com>
> > >To: "Justin Menga" <Justin.Menga@computerland.co.nz>, "fwells12"
> <fwells12@hotmail.com>, <ccielab@groupstudy.com>
> > >Subject: Re: ISDN questions ...!
> > >Date: Sun, 4 Feb 2001 08:35:28 -0500
> > >
> > >Justin,
> > > I'm using OSPF demand circuit and seeing the results I
> > >described... I'm still trying to work through why R3 stays in a 2WAY
> > >neighbor state with R4. In this scenario the frame cloud is full mesh.
> > >
> > >Any thoughts....
> > >
> > >Thanks
> > >Nigel..
> > >
> > >----- Original Message -----
> > >From: Justin Menga <Justin.Menga@computerland.co.nz>
> > >To: 'Nigel Taylor' <nigel_taylor@hotmail.com>; fwells12
> > ><fwells12@hotmail.com>; <ccielab@groupstudy.com>
> > >Sent: Sunday, February 04, 2001 6:07 AM
> > >Subject: RE: ISDN questions ...!
> > >
> > >
> > > > Well that just leaves OSPF demand circuit....
> > > >
> > > > Regards,
> > > >
> > > > Justin Menga CCIE #6640 MCSE+I CCSE
> > > > WAN Specialist
> > > > Computerland New Zealand
> > > > PO Box 3631, Auckland
> > > > DDI: (+64) 9 360 4864 Mobile: (+64) 25 349 599
> > > > mailto: justin.menga@computerland.co.nz
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Nigel Taylor [mailto:nigel_taylor@hotmail.com]
> > > > Sent: Sunday, February 04, 2001 8:58 PM
> > > > To: fwells12; ccielab@groupstudy.com
> > > > Subject: Re: ISDN questions ...!
> > > >
> > > >
> > > > fwells12,
> > > > The lab says I cannot use the backup interface
> command,
> > > > floating static's or watch groups....
> > > >
> > > > For more detail info.. it the 401 Adv. OSPF lab on www.fatkid.com.
> > > >
> > > > Nigel..
> > > > ----- Original Message -----
> > > > From: fwells12 <fwells12@hotmail.com>
> > > > To: <ccielab@groupstudy.com>
> > > > Sent: Sunday, February 04, 2001 2:42 AM
> > > > Subject: Re: ISDN questions ...!
> > > >
> > > >
> > > > > Make sure your idle-timeout is at least a minute, and that you have
> the
> > > > > backup command on the serial interface that is being backed up. Set
> the
> > > > > backup delay to be short coming up so routes start propagating
> > > > immediately.
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > From: Nigel Taylor <nigel_taylor@hotmail.com>
> > > > > To: Price, Jamie <JPrice@isgteam.com>; Cisco Group Study
> > > > > <cisco@groupstudy.com>; CCIE_Lab Group Study
> <ccielab@groupstudy.com>
> > > > > Cc: Bryant Andrews <Bryant_Andrews@hotmail.com>
> > > > > Sent: Saturday, February 03, 2001 11:25 PM
> > > > > Subject: Re: ISDN questions ...!
> > > > >
> > > > >
> > > > > > jamie,
> > > > > > Ok, did some more testing and this thing will work
> without
> > >a
> > > > > > name. I also changed the dialer idle-time-out value. The one
> problem
> > > > I'm
> > > > > > seeing now is on router 2. When I pull the serial conn. from
> router 3
> > > > to
> > > > > > the frame switch the bri line kick in and passes all the routes.
> > >However
> > > > > > when I break the link from r2 to the frame switch, nothing.....
> R3
> > > > never
> > > > > > forms a full state with R4 and r2 and R3 doesn't pass routes even
> > >though
> > > > > the
> > > > > > bri line is up....
> > > > > >
> > > > > > Any thoughts..
> > > > > >
> > > > > > Nigel...
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: Price, Jamie <JPrice@isgteam.com>
> > > > > > To: 'Nigel Taylor' <nigel_taylor@hotmail.com>; Cisco Group Study
> > > > > > <cisco@groupstudy.com>; CCIE_Lab Group Study
> <ccielab@groupstudy.com>
> > > > > > Cc: Bryant Andrews <Bryant_Andrews@hotmail.com>
> > > > > > Sent: Sunday, February 04, 2001 1:49 AM
> > > > > > Subject: RE: ISDN questions ...!
> > > > > >
> > > > > >
> > > > > > > Just an FYI/gotcha
> > > > > > >
> > > > > > > I think setting the dialer idle-timeout to 1 causes problems.
> > > > > > >
> > > > > > > We're all impatient and want the line to come down quickly so we
> can
> > > > > prove
> > > > > > > the solution but I've noticed that when the "dialer
> idle-timeout" is
> > > > > less
> > > > > > > than the "dialer wait-for-carrier-time" then behaviour that is
> > > > > comparable
> > > > > > to
> > > > > > > what you mention here (flapping line) occurs.
> > > > > > >
> > > > > > > Jamie
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Nigel Taylor [mailto:nigel_taylor@hotmail.com]
> > > > > > > Sent: Sunday, February 04, 2001 12:38 AM
> > > > > > > To: Cisco Group Study; CCIE_Lab Group Study
> > > > > > > Cc: Bryant Andrews
> > > > > > > Subject: ISDN questions ...!
> > > > > > >
> > > > > > >
> > > > > > > I'm working through one of the labs at fatkid(401, Advanced
> OSPF)
> > >and
> > > > =
> > > > > > > have a couple of questions. The one part of the configuration I
> > >can't
> > > > =
> > > > > > > understand is the BRI's on R2 and R3. There is no
> configuration
> > >for
> > > > =
> > > > > > > the name of the calling device or called device. when I tried
> this
> > > > the
> > > > > =
> > > > > > > routers would no connect, well at least not for more than a
> second.
> > >=
> > > > > > > "debug ppp nego" showed called from <unknown> hang-up. Most
> > >examples
> > > > =
> > > > > > > I've worked with makes use of the name option on the "dialer
> map" =
> > > > > > > command?
> > > > > > >
> > > > > > > My other question is specific to the "dialer idle-timeout 1
> either".
> > > > I
> > > > > =
> > > > > > > know what the command does but with one second.
> > > > > > >
> > > > > > >
> > > > > > > Has anyone worked through this lab and got it working with the
> > > > solution
> > > > > =
> > > > > > > on the site... What was your observations on the bri line.
> > > > > > > Mines keep bouncing up and down...
> > > > > > >
> > > > > > > TIA
> > > > > > >
> > > > > > > Nigel..
> > > > > > >
> > > > > > >
> > > > > > >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:28:36 GMT-3