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
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=45150&t=45150
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
