Mathias,
This is correct! When you configure the "demand-circuit"
after the ISDN circuit goes down you should see "DNA"
noted in the ospf database which suppresses the need for hello's to be sent.
Since both R1, R2, and R4 are a part
of area1, when the frame circuit between R2-R4 go down this will trigger the
database recalculation and bring the
ISDN link up. This would be fine since it will be how all connectivity
would be maintained. This is why I suggested that
the requirement calls for two "virtual links" or tunnels. You might want to
brush up on your understanding of "demand-circuit".
Here are some really good links to explaining how effective "demand-circuit"
can be while using the necessary filtering.
http://www.cisco.com/warp/public/104/dc.html
http://www.cisco.com/warp/public/104/dcprob.html
What a great link.. I used this one when I prepared for the lab. It pays to
browse this stuff once in a while.
http://www.cisco.com/warp/public/104/index.shtml
Nigel
----- Original Message -----
From: "Spoerr, Mathias"
To: "Nigel Taylor" ; "cebuano"
; "Jan Gunnik Hope"
Cc: ;
Sent: Monday, May 27, 2002 2:55 PM
Subject: AW: Revised: OSPF problem - 2nd try
> Nigel,
>
> I forgot to tell you that the second task is that the ISDN must not be up
until the FR R4-R2 fails.
> R3 has to initiate the call and R1 must call back.
> There is another exercise regarding to this layout, where a backup link
must exist for the area 2 connection.
>
> ---------10.x.x.x/24-------Ethernet OSPF Area0
> | |
> R1---Lo0 R2---Lo0
> | |
> ISDN Area1 FR Area1
> | |
> Lo0--R3----------FR-------R4--Lo0
> | Area1 |
> ---------E0 FR Area2
> |
> R5
> (I hope this "drawing" can be identified)
>
>
> > Although your most recent solution may work try to think
> > of a solution around the ISDN link remaining up in this configuration
and what you could
> > do to avid this problem. there is a very popular way of avoiding this
> > occurrence.
>
> Which solution do you mean?
> When you think about the "demand circuit feature" - it doesn't work with
Virtual links, because R4 is sending hellos destined for the bri address of
R1 when you configure a virtual link to R1.
>
> Thank's for responding,
> Mathias
>
>
> -----Urspr|ngliche Nachricht-----
> Von: Nigel Taylor [mailto:[EMAIL PROTECTED]]
> Gesendet: Montag, 27. Mai 2002 12:59
> An: cebuano; Jan Gunnik Hope; Spoerr, Mathias
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Betreff: Revised: OSPF problem - 2nd try
>
>
> Mathias,
> I think your you're trying to hard and possibly reading too
much
> into the requirements.
> I personally agreed with Jan's #1 option in which the "area x range
> not-advertise" command is used
> on R1, R2, and R4. Although your most recent solution may work try to
think
> of a solution
> around the ISDN link remaining up in this configuration and what you could
> do
> to avid this problem. there is a very popular way of avoiding this
> occurrence.
>
> I think the emphasis here is the requirement which reads,
> "The exercise is that the 10.x network must not be advertised into the
> Frame Relay network."
>
> As Jan noted when using the virtual links between R1-R4 and R2-R4 this
will
> logically place R4
> into area0, which is fine. This is fine because look at the logical
drawing
> below once the virtual
> links are configured.
>
> 10.x..x.x/24
> ---------------------------------------------Area0
> | | |
> | | |
> lo0--(R1) (R2)--lo0 (R4)--lo0
> | | |
> | area1 | area1 |
> lo0--(R3)---------////(frame)/////
> | | area2
> (E0) (R5)
>
> Using the #1 option allows use to clearly understand and meet the
> requirements in that although R1, R2, and R4 does have the 10.x.x.x
> network route in their RIBs, that route is not being advertised into the
> frame-relay network. Yes, I know that the R2-R4 connection is part
> of the frame connection, but the key word here is advertised. With the
> current logical design R4 as if it were connected to the backbone
> segment(10.x.x.x/24). If you had to go one step further which I don't
> think is necessary, a "distribute-list x in" on the R4 process would
> eliminate
> the 10.x.x.x from R4's RIB, to complete the illusion that the route was
not
> being advertised across the R2-R4 or R1-R4 virtual links.
>
>
> HTH
> Nigel
>
> P.S. Elmer what do you think about this thread and which solution meets
the
> requirement?
>
> ----- Original Message -----
> From: "Spoerr, Mathias"
> To: "Jan Gunnik Hope"
> Cc: ; "Nigel Taylor" ;
>
> Sent: Monday, May 27, 2002 4:41 AM
> Subject: AW: OSPF problem - 2nd try
>
>
> > Hello!
> >
> > I think I found the Solution for the wrxkrmpf OSPF problem.
> > I configured tunnel interfaces at R1, R2 and R4 and bound the interfaces
> to OSPF area 2. I configured no virtual link. Now only R1 and R2 are in
Area
> 0.
> > Another advantage is the backup for Area 2. In the original setup I had
> the problem that after a link-down of FR R2-R4 Area 2 is no more
reachable.
> When you want to configure a virtual link between R4 and R1 you will have
> the problem that the ISDN link is up the whole time.
> >
> > Any comments?
> >
> >
> > Mathias
> >
> > -----Urspr|ngliche Nachricht-----
> > Von: Jan Gunnik Hope [mailto:[EMAIL PROTECTED]]
> > Gesendet: Samstag, 25. Mai 2002 23:12
> > An: Spoerr, Mathias
> > Cc: [EMAIL PROTECTED]; Nigel Taylor; [EMAIL PROTECTED]
> > Betreff: SV: OSPF problem - 2nd try
> >
> >
> > Hello Mathias !
> >
> > In my opinion these are the possible (elegant :-) solutions,
> > in preferred order :
> > 1. Use
> > "area 0 range 10.0.0.0 255.0.0.0 not-advertise"
> > on routers R1/R2/R4, virtual link R2/R4.
> > You need it on R4 as well, because as you said yourself,
> > R4 becomes member of area 0 when you add the virtual link.
> >
> > This removes 10.x.x.x from R3 and R5, and they are both
> > connected thru F/R, in different areas.
> >
> > 2. Use
> > "area area-id filter-list prefix prefix-list-name out"
> > with prefix-list-name filtering net 10.0.0.0.
> > Use it on R1/R2/R4, virtual link R2/R4
> > This command was introduced in 12.0(15)S, but unfortunately
> > does not seem to be part of the main IOS train yet.
> > I haven't been able to test this one, but it looks "dead-on".
> >
> > We still see 10.x.x.x in R4 though, because of the virtual link.
> >
> > 3. Use a tunnel between r2/r4, totally stub areas 1 and 2.
> > Tunnel endpoints in area 2.
> > This is really a lab-only solution, as Nigel also remarked.
> > But it works, and does not show the 10.x.x.x on R4...
> >
> > I clearly prefer #1, because I interpret your requirement :
> > "The exercise is that the 10.x network must not be advertised into the
> Frame Relay network."
> > to mean that R3 and R5 should not see 10.x.x.x. R4 sees it as soon as
we
> > configure a virtual-link or a tunnel, because we then make R4 area 0
> member.
> >
> > If you were to use no tunnels and have different OSPF processes, you
> > could use one process per area, and do redistribution between them.
> > That would make the filtering really easy, but you would essentially
> change
> > your OSPF-execise to a redistribution exercise :-)
> >
> > My two cents...
> >
> > Jan Gunnik Hope
> > CCIE # 8221
> >
> >
> >
> >
> > -----Opprinnelig melding-----
> > Fra: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Pe vegne av
> > Nigel Taylor
> > Sendt: 25. mai 2002 15:42
> > Til: [EMAIL PROTECTED]
> > Kopi: [EMAIL PROTECTED]; Spoerr, Mathias
> > Emne: Re: OSPF problem - 2nd try
> >
> >
> > MAthais,
> >
> > I'm not sure if the ASCII art made the journey. but based
on
> > what I believe you're trying to accomplish see Inline...
> >
> > Note: Questions like this you should post to the main
> > ist( [EMAIL PROTECTED] ). You'll get a better response.
> >
> > .
> > ----- Original Message -----
> > From: "Spoerr, Mathias"
> > To:
> > Sent: Saturday, May 25, 2002 7:38 AM
> > Subject: OSPF problem - 2nd try
> >
> >
> > > Hi all,
> > > I have a little OSPF configuration question. The last time nobody was
> > responding. Maybe this time I will get some answers.
> > > I added a few new thoughts to my problem.
> > >
> > > My setup:
> > >
> > >
> > > ---------------10.x.x.x/24-------------------Ethernet OSPF Area0
> > > | |
> > > R1---Lo0 R2---Lo0
> > > | |
> > > ISDN Area1 FR Area1
> > > | |
> > > Lo0--R3----------FR--------------R4--Lo0
> > > | Area1 |
> > > ---------E0 FR Area2
> > > |
> > > R5
> > >
> > >
> > > Between R2 and R4 has to be a Virtual link. Therefor R4 is in Area0.
> >
> > Nigel: Here is a thought. Yes, there has to be a virtual-link but I
> > think there should be configurations for another virtual-link(R4-R1).
> > Without it there's no way to
> > avoid having a partioned area. Yes R4 will logically be place
> > into area0 .
> >
> > > The exercise is that the 10.x network must not be advertised into the
> > Frame Relay network.
> >
> > Nigel: I understand that the 10.x.x.x network must not be advertised
> into
> > the frame, which I think is ok based on the requirement. But Why?
> >
> > >
> > > My collegues and me had a few thoughts:
> > > * Configure Area 1 as stub or totally stubby: Drawback: no Virtual
link
> is
> > allowed in a totally stubby area.
> >
> > Nigel: Since I'm under the impression thatthis is not a production
> network
> > I believe the extra overhead caused be the encapsulation
> > through the tunnel won't be a problem. This is something we sometimes
> > forget is another option to "Virtual-links"
> > You could also attempt to filter the 10.x.x.x network through the
> tunnel(s)
> > since filtering is implied to avoid "recursive routing"
> >
> > http://www.cisco.com/warp/public/104/ospfdb7.html
> >
> >
> > > * Route-map configuration on all routers in FR: Drawback: The
route-map
> > does not prevent advertising the 10.x routes.
> > > * I found the command "area 0 range 10.0.0.0 255.0.0.0 not-advertise".
> > With command configured on R2,R1 and R4, the 10.x addresses are no more
> > advertised. The only problem is that R4 knows whre to find 10.x.
> > > * Configuration of two OSPF Processes on R1 and R2 and Redistribution
> > between them by filtering the 10.x addresses:
> > > - Process 1, Router 2: Lo0: Area0; WAN: Area1
> > > - Process 2, Router 2, Router 1: E0: Area0
> > > - Process 1, Router 1: Lo0: Area1; WAN: Area1
> > > - Drawback: suboptimal routing, no backup for FR from R2-R4
> > > * No OSPF on the 10.x network -> Virtual link R1-R2 for a contiguous
> Area0
> >
> > Nigel: Removing the 10.x.x.x network from the frame could does present
a
> > problem. In order to maintain reachability to R2 during the loss of the
> > R2-R4 frame connection, packet must use the 10.x.x.x (backbone link). I
> > think the work around for this would be some type of 0/0(default) route
to
> > provide a path for unknown destination networks(namely the 10.x.x.x).
The
> > emphasis here being if no requirement exist for R3, R4, and R5 to have
> > reachabilty to the ten network, then this should work fine without any
> > default route.
> >
> > I don't believe your last suggestion will make a differnecemainly
because,
> > although you could have two partioned area 0's and then use a
virtual-link
> > to remedy
> > the configuration flaw, the resaoning behind the orignal requirement is
> > based on the "virtual link" required to connect "area2" to the
backbone.
> >
> > I think by simply using "distribute-list x" under the OSPF process in R1
> and
> > R2 outbound should eliminate the 10.x.x.x route from
> > ever making it to the frame cloud
> >
> > >
> > >
> > > Please provide your thoughts to this issue.
> > >
> > >
> > > Thank's
> > > Mathias
> >
> > Nigel
> > __________________________________________________________________
> > To unsubscribe from the SECURITY list, send a message to
> > [EMAIL PROTECTED] with the body containing:
> > unsubscribe SECURITY
> >
> >
>
> --------------------------------------------------------------------------
> -----
> > This verifies that this e-mail has been scanned for virus and deemed
> virus-free
> > according to F-secure Content Scanner 5.0
> > Sat, 25 May 2002 09:41:34 -0400 GMT
>
> --------------------------------------------------------------------------
> -----
> > __________________________________________________________________
> > To unsubscribe from the SECURITY list, send a message to
> > [EMAIL PROTECTED] with the body containing:
> > unsubscribe SECURITY
> > __________________________________________________________________
> > To unsubscribe from the SECURITY list, send a message to
> > [EMAIL PROTECTED] with the body containing:
> > unsubscribe SECURITY
> __________________________________________________________________
> To unsubscribe from the SECURITY list, send a message to
> [EMAIL PROTECTED] with the body containing:
> unsubscribe SECURITY
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=45154&t=45154
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
