From: Sila Moni (silamoni@yahoo.com)
Date: Thu Jun 30 2005 - 10:21:13 GMT-3
Excellent comment on distance and metric, George. If
I may, let me get everyone's view on the following
scenerio.
(EIGRP 1)R1--(EIGRP 2)--R2--R3&R4==(ospf)==R5--R6
1) Mutually redistribute EIGRP on R1
1a) In R2's routing table, it'll see EIGRP and OSPF
routes as external 170.
b) R2 sees two paths to each OSPF route be default
2) Mutually redistribute EIGRP and OSPF on both R2 &
R3
2a) After R3&R4 mutually redistribute between OSPF and
EIGRP, we have a problem. The EIGRP external routes
learned from R1 are now preferred via the OSPF side.
Normally, when you only deal with one EIGRP AS, you
don't have this problem. Using distance won't work
here. I don't believe tagging will help either.
If I were to use distibute-list, it might work.
That'll only filter out routes from the routing table,
not the LSA dB. LSA filter might be most preferred in
this case. You thought?
My brain is mushed while doing the redistribution
exercises between distance vector and link state. Oh
btw, ISIS is a fun one as well. It uses a metric of
10 for everything. That'll mess up the ISDN part for
sure.
--- CCIE Group Study <ccie@madisonsolutions.net>
wrote:
> Good morning:
>
> When you build the tunnel the virtual path metric
> over the tunnel in OSPF is
> better than the physical OSPF metric path. So OSPF
> will use the virtual
> path. When it loads the virtual path into the
> routing table and removes the
> physical path; the tunnel goes down because the
> destination end is no longer
> reachable.
>
> Your tunnel will go up-down-up-down-up-down forever.
> The answer is to make
> sure that the physical path has a better OSPF metric
> than the tunel OSPF
> metric. You can do this by changing the bandwidth
> of the tunnel to 9k; for
> example.
>
> Now the tunnel will stay up as a direct connection
> that is unique in the
> routing table, but the physical path will remain the
> best path. Now if I
> was a proctor I would have EIGRP and OSPF in the
> mesh to make the tunnel and
> throw ISDN in the mix to mush your brain.
>
> So create a lab with ISDN running EIGRP. OSPF needs
> a tunnel for Area 0, if
> the frame link goes down the tunnel must travers the
> EIGRP ISDN. The Frame
> OSPF path must be the best path if the frame is up.
> 2 Points.
>
> On the CCIE look for metric and distance problems.
> Now if the lab says to
> build the tunnel and the OSPF metric needs to be 1
> for your tunnel you have
> a new problem. Then you would change the
> Administrative Distance on each
> router for the tunnel path on each router to be 115.
> Now the OSPF AD of 110
> is better than the OSPF AD of 115, both stay up and
> work the way you want
> them to.
>
> George Morton, Ph. D.
> Madison Solutions
>
>
> ----- Original Message -----
> From: "Schulz, Dave" <DSchulz@dpsciences.com>
> To: "Larry Roberts" <groupstudy@american-hero.com>;
> "Gustavo Novais"
> <gustavo.novais@novabase.pt>
> Cc: <ccielab@groupstudy.com>
> Sent: Thursday, June 30, 2005 7:19 AM
> Subject: RE: OSPF Virtual Link and GRE tunnel.
>
>
> > If you are addressing the interfaces at both ends
> of your tunnel and
> > putting them in area 0, then you are not violating
> OSPF. You have to
> > remember to do it on both ends of the tunnels (R2
> and R7, R2 and R7, R2
> > and R9). In this way, you are truly extending OSPF
> area 0. Hope this
> > helps.
> >
> >
> > Dave
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com
> [mailto:nobody@groupstudy.com] On Behalf Of
> > Larry Roberts
> > Sent: Thursday, June 30, 2005 12:28 AM
> > To: Gustavo Novais
> > Cc: ccielab@groupstudy.com
> > Subject: Re: OSPF Virtual Link and GRE tunnel.
> >
> > Somebody please correct me if Im wrong on my
> understanding of
> > Virtual-links, but I believe the virtual link
> configuration mentioned
> > below is invalid.
> >
> > I was under the understanding that Virtual links
> require that one router
> >
> > be an ABR to area 0 (R2). This virtual link
> provides backbone
> > connectivity to area 0 for the ABR (R5) but it
> doesn't *extend* the
> > backbone to R5 ( R5 doesn't have an interface in
> Area 0). When you
> > create your second virtual link from R5 to R7,
> neither of these routers
> > have an interface in Area 0.
> >
> > If you do a "show ip ospf interface" on R5, you
> will see that none of
> > the interfaces are listed as in area 0. While this
> configuration seems
> > to work fine, It appears to me that it is in
> violation of OSPF
> > configuration guidelines.
> >
> > Can anyone correct my understanding on this?
> >
> >
> > Gustavo Novais wrote:
> >> Apparently I had a dumb config problem on R7...
> Duhhh... It's working
> >> now.
> >> Either way, any way how to solve recursive
> routing situation I
> >> presented?
> >> Thanks
> >>
> >> -----Original Message-----
> >> From: nobody@groupstudy.com
> [mailto:nobody@groupstudy.com] On Behalf
> > Of
> >> Gustavo Novais
> >> Sent: quarta-feira, 29 de Junho de 2005 19:33
> >> To: ccielab@groupstudy.com
> >> Subject: OSPF Virtual Link and GRE tunnel.
> >>
> >> Hello group
> >>
> >> I have a topology like this.
> >>
> >>
>
Area0--(R2)---Area25---(R5)---Area57----(R7)----Area78----(R9)
> >>
> >> It showed up on a exercise in order to test
> Virtual-links etc.
> >> I did it using vlink between R5 and R2 for area
> 57 reachability and a
> >> vlink between R7 and R5 for area 78 reachability.
> >>
> >> But I'd like to try the same topology using GRE
> tunnel between R7 and
> >> R2.
> >> If I extend Area 0 onto interface tunnel on R7, I
> get recursive
> > routing
> >> and the tunnel goes down. (OSPF will prefer intra
> area routes vs extra
> >> area routes, so the preferred path to the tunnel
> destination is
> > through
> >> the tunnel itself, which shuts it down.
> >>
> >> If I extend area 78 to R2 Tunnel, apparently all
> is well, but the
> >> problem is that R5 starts complaining that
> Received invalid packet:
> >> mismatch area ID, from backbone area must be
> virtual-link but not
> > found
> >> from 150.50.57.7, Ethernet0/0, even now that area
> 78 is connected
> >> directly to area 0, and area 57 still has its
> vlink on R5 to Area 0.
> >>
> >> Any ideas why is the router R5 showing this
> behaviour? Any suggestions
> >> how to correct it?
> >>
> >> Thanks
> >>
> >>
> >
>
This archive was generated by hypermail 2.1.4 : Wed Jul 06 2005 - 14:43:46 GMT-3