From: Carlos G Mendioroz (tron@xxxxxxxxxxx)
Date: Thu Jun 06 2002 - 22:22:43 GMT-3
Actually I found another way to do it, and though it may sound
complicated,
I think it's elegant in some sense.
(Confeds are ok but kind of overkill, playing with router ids seems
to me risky to say the least, and doing a network on a foreign network
also seems to me to be wrong)
So here: we have
R1 -- R2 -- R3
\ |
\ |
- R4 -- R5
R1 (AS1) talks eBGP/RIP to R2
R2 (AS2) talks eBGP/OSPF to R3 and also OSPF to R4
R3, R4 & R5 (AS3) talk OSPF and iBGP with R4 being a RR.
and the problem is that R4 does not sync a route coming from R1 because
it learns it via iBGP from R3 but via OSPF from R2.
Well, as I see it, the problem lies in using a IGP for two things: IGP
and
EGP. And there we break some hypothesis and the whole thing.
Solution: break the OSPF into two unrelated routing domains.
Make one domain for IGP (R3 - R4 - R5) and another for EGP
(R2 - R3 - R4). The later running only in R2-R3 and R2-R4 links.
This implies running two copies of OSPF at R2 and R3. First time
in my life I actually see some application for that! (other than
route crunching for VLSM/FLSM tricks)
Also, at R2, redistribute the "external" OSPF into the "internal",
or better yet, redistribute BGP into the internal OSPF. Then you'll get
the R1 network known at R4 via the internal OSPF process.
This is the tricky part. I tried lowering the admin distance of this
OSPF process at R4 and it did not work. You have to have the internal
OSPF process with a lower process number. Doing the same thing at R3
will take care of the OSPF/BGP router ids being also in sync.
Hope someone tries it :-)
Sandro Ciffali wrote:
>
> There are two ways you can tackle this issue, One way
> is as you said use confed. instead of route reflector.
> Second way i have not tried myself but I think it will
> work is to add network statement under bgp on R4 and
> use proper filtering so that it does not go back.
>
> Let me know if you have tried any of this or need more
> explanation on this.
>
> Sandeep
> 8988
>
> --- Jun Jia <ellenjjl@rogers.com> wrote:
> > Hi,
> >
> > From your discription of the problem,
> > 200.100.100.0/24 is not synchronized
> > at R4. The reason is that for IGP (ospf), this
> > network is learned from
> > Router 2 (it is an ASBR) (not Router 3), while for
> > BGP, it is learned from
> > Router 3 not Router2. So according to BGP/IGP
> > synchronization rules for
> > OSPF/BGP, the network should be learned from the
> > some Router, otherwise it
> > says not synchronization.
> >
> > Exception for configuring R3, R4,R5 as BGP
> > Confederations, actually I don't
> > know what is the solution of this problem.
> > If someone knows any other ways, please tell me as
> > well.
> >
> > refer: http://www.cisco.com/warp/public/459/25.shtml
> >
> >
> > Regards,
> >
> > Joe
> >
> > ----- Original Message -----
> > From: "Paul" <p_chopin@yahoo.com>
> > To: <ccielab@groupstudy.com>
> > Sent: Wednesday, June 05, 2002 10:58 PM
> >
> >
> > > Hi group,
> > > I just run into another interesting little
> > problem.
> > > I have R1-R2---R3
> > > | |
> > > \ /
> > > R4---R5
> > > R1 is running RiP. R2,R3,R4,R5 are running ospf.
> > R2 is
> > > redistributing rip into ospf domain.R1 is
> > inserting
> > > route 200.100.100.0/24 to BGP through network
> > > statement and Redistributing this route into Rip
> > as
> > > well. R1 is in AS1 , R2 in AS3, and R5,R4,R5 in As
> > > 3.EBGP sessions R1-R2, R2-R3. IBGP sesions R3-R4,
> > > R4-R5. R4 is route reflector.Synch is enable on
> > all
> > > the routers.Question is why on R4 BGP table says,
> > that
> > > route 200.100.100.0/24 is not synchronized even
> > it's
> > > known through ospf and is not being pushed to R5.
> > > All routers have hard coded identical routers id
> > in
> > > ospf and BGP.
> > > I've been struggling almost a week with this one.I
> > > searched and read white papers on CCO - I still
> > don't
> > > understand.I'm missing really something
> > important.
> > > Can you help?
> > > Paul
> > >
> > >
> > >
> > >
> > >
This archive was generated by hypermail 2.1.4 : Tue Jul 02 2002 - 08:12:27 GMT-3