From: Carlos G Mendioroz (tron@xxxxxxxxxxx)
Date: Mon Jun 10 2002 - 10:45:35 GMT-3
Is there any place where one can find WHAT is IOS doing in order
to consider a route synch'ed ? (OSPF/BGP)
I've fallen into a trap :-) because it is not the same in IOS 11.3
and in IOS 12.1.
I thought that originator (BGP) equals originator (OSPF) should do,
and it does in 11.3, but it does not in 12.1.
E.g.:
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
10.0.0.0 192.168.2.1 1623 0x80000002 0x6672 0
BGP routing table entry for 10.0.0.0/8, version 0
Paths: (1 available, no best path)
Not advertised to any peer
2 1
192.168.2.1 (metric 74) from 192.168.4.1 (192.168.4.1)
Origin IGP, metric 1, localpref 100, valid, internal, not
synchronized
Originator: 192.168.2.1, Cluster list: 192.168.4.1
Peter van Oene wrote:
>
> Not sure entirely what you are trying to do here, but first of all, one
> would not extends ones IGP between providers. In this case, R2 and R3
> would never share routes via OSPF due to their being members of different
> AS's. I'm really quite confused about the role of R2 in this case as you
> seem to have it ebgp peering between AS2 and AS's 1/3, but also sharing IGP
> domains which again would not be an accurate topology.
>
> Assuming a properly configured topology, R3 would originate the BGP and
> OSPF route into AS3 and R4/R5 would synchronize properly (though why one
> runs synch in a full mesh environment baffles me) Were R4 to reflect
> toward R5, you would have synch issues on R5 but again, synch would be
> fully irrelevant in this case due to the full mesh (simulated)
> characteristics of the network.
>
> At 10:22 PM 6/6/2002 -0300, Carlos G Mendioroz wrote:
> >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:30 GMT-3