""Spoerr, Mathias"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > 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? >
CL: I've only glanced through this thread, but I have to ask - is the purpose of the exercise to try things until you find something - any old thing -that works, or is it to learn something specific about how OSPF works? CL: If it is the former, fine. If it is the latter, what have you learned? > > 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. > > FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=45139&t=45124 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
