From: Nick Shah (nshah@xxxxxxxxxxxxxx)
Date: Tue Aug 27 2002 - 20:41:54 GMT-3
Dmitry
The only sure shot way to avoid the 'ugliness' of manipulating the BGP &
OSPF RID's is to get away and not use the Route reflectors at all.
Instead, use Confeds, you will not have synch issues then. That way you can
have the best of both the worlds and you can easily satisfy the condition of
not having to full mesh them, by making only one 'confed AS' neighbor with
the other 2 confed AS (dont create the peership between the 2 confed AS's,
just like you would do in RRc's)
rgds
Nick
----- Original Message -----
From: "Mingzhou Nie" <mnie@yahoo.com>
To: "Volkov, Dmitry (Toronto - BCE)" <dmitry_volkov@ca.ml.com>;
<ccielab@groupstudy.com>
Sent: Wednesday, August 28, 2002 8:58 AM
Subject: RE: Again BGP sync/rid problem
> Dmitry,
>
> Here are the things that I tried when working on this kind of scenario.
>
> - change ospf to bgp redistribution from r1 to r2
>
> this won't work because you can only redistribute EBGP into igrp
>
> - turn off sync on r6
>
> this will work, but may not be allowed.
>
> - change bgp route-id on r2 the same as ospf route-id on r1, then you
> have to either update r1's bgp id or r2's ospf id, or it will break
> either ospf or bgp. However, now r2, the RR gets bgp routes from r1
> with different ospf and bgp id(because on r1, their id are different
> now), so you have to turn off sync on RR
>
> this will work too, but you have to turn off sync on RR, plus route-id
> on r1 and r1 are really ugly
>
> - if both r2 and r6 are not allowed "no sync", and "r1 and r6 can only
> have one neibough"(basically you have to use RR), then there's no way
> to make it work
>
> maybe other people have more thoughts?
>
> ming
> --- "Volkov, Dmitry (Toronto - BCE)" <dmitry_volkov@ca.ml.com> wrote:
> > Hello group,
> >
> > Nobody answered yet !!!
> > Is this absolutely no real life case ???
> >
> > Shortly again :) - When we redistr BGP into OSPF, OSPF creates LSA 5
> > flooded
> > anywhere (with except stubs)
> > These LSAs have ADV Router (in ospf DB) with RID of redistr router.
> > When Route reflector gets BGP route from redistr router - OSPF RID
> > and BGP
> > RID of route learned via OSPF and via BGP are equal. So route is
> > "synchronized, best"
> > When BGP route is reflected from RR to internal peers - OSPF RID of
> > Originator of route is still the same ("from RID of redist router" -
> > LSA 5
> > are not changed), but route learned via BGP shows "from RID of RR",
> > despite
> > that Originator of route is still the same and because, I guess, OSPF
> > RID
> > doesn't match BGP RID where route learned from - route "not
> > synchronized"
> > http://www.cisco.com/warp/public/459/25.shtml
> >
> > What to do ?? if Sync must be enabled and IBGP full mesh is not
> > allowed.
> >
> > Can we say that if Sync enabled with OSPF - IBGP has to be full
> > meshed ???
> > R2 -is RR, R1 - redistr point from BGP to OSPF, R6 - RR client (R1,
> > R2 and
> > R6 in the same AS)
> > route 160.100.100.0/24 - learned by R1 via EBGP:
> >
> > r2#sh ip bgp 160.100.100.0
> > BGP routing table entry for 160.100.100.0/24, version 10
> > Paths: (1 available, best #1, table Default-IP-Routing-Table)
> > Advertised to non peer-group peers:
> > 133.7.4.4 133.7.6.6
> > 2001, (Received from a RR-client)
> > 133.7.1.1 (metric 75) from 133.7.1.1 (133.7.1.1) <-----------
> > DIFFERENCE !!!
> > Origin IGP, metric 0, localpref 100, valid, internal,
> > synchronized,
> > best
> >
> > r2#sh ip ro 160.100.100.0
> > Routing entry for 160.100.100.0/24
> > Known via "ospf 1", distance 110, metric 1
> > Tag 2, type extern 2, forward metric 74
> > Last update from 133.7.28.3 on Ethernet0/0, 02:28:36 ago
> > Routing Descriptor Blocks:
> > * 133.7.28.3, from 133.7.1.1, 02:28:36 ago, via Ethernet0/0
> > Route metric is 1, traffic share count is 1
> > ====================================================================
> > r6#sh ip bgp 160.100.100.0
> > BGP routing table entry for 160.100.100.0/24, version 0
> > Paths: (1 available, no best path)
> > Not advertised to any peer
> > 2001
> > 133.7.1.1 (metric 75) from 133.7.2.2 (133.7.2.2) <-------------
> > DIFFERENCE !!!
> > Origin IGP, metric 0, localpref 100, valid, internal, not
> > synchronized
> > Originator: 133.7.1.1, Cluster list: 133.7.2.2
> >
> > r6#sh ip ro 160.100.100.0
> > Routing entry for 160.100.100.0/24
> > Known via "ospf 1", distance 110, metric 1
> > Tag 2, type extern 2, forward metric 74
> > Last update from 133.7.28.3 on Ethernet0, 02:29:31 ago
> > Routing Descriptor Blocks:
> > * 133.7.28.3, from 133.7.1.1, 02:29:31 ago, via Ethernet0
> > Route metric is 1, traffic share count is 1
> >
> >
> > Dmitry
> >
> > -----Original Message-----
> > From: Volkov, Dmitry (Toronto - BCE) [mailto:dmitry_volkov@ca.ml.com]
> > Sent: Monday, August 26, 2002 11:14 AM
> > To: 'ccielab@groupstudy.com'
> > Subject: Again BGP sync/rid problem
> >
> >
> > Hello,
> >
> > Well, now I'm also stacked with this Sysnc/RID problem.
> > I'm doing Solie's "Unnamed Lab". The requirement : Syncronize BGP
> > with OSPF.
> >
> > R1 (rid 133.7.1.1) runs BGP AS 2010 and peering with backbone router
> > AS
> > 2001.
> > R1 gets 4 EBGP routes from Backbone.
> > R1 runs IBGP with R2 (rid 133.7.2.2), R2 runs IBGP with R6 (rid
> > 133.7.6.6).
> > There is OSPF between R1, R2, R6.
> > R2, R3 and R6 on common ethernet segment. R2 and R6 connected to R1
> > via R3
> > (which runs OSPF only, NO BGP)
> > R1----R3----R2
> > |
> > R6
> > So
> > 1)I redistributed BGP to OSPF on R1 with next-hop-self , R2 is OK -
> > all BGP
> > routes from Backbone are valid:
> >
> > Network Next Hop Metric LocPrf Weight Path
> > *>i160.100.100.0/24 133.7.1.1 0 100 0 2001 i
> > *>i160.100.128.0/24 133.7.1.1 0 100 0 2001 i
> > *>i160.100.129.0/24 133.7.1.1 0 100 0 2001 i
> > *>i160.100.130.0/24 133.7.1.1 0 100 0 2001 i
> > r2#
> >
> > 2) made R2 as Route reflector.
> > R6 gets BGP routes from backbone via R2. But these routes are not
> > synchronized.
> > I guess this is because route 160.100.100.0/24 is learned via BGP
> > from R2
> > (133.7.2.2),
> > but it's also known via IGP (OSPF) from R3 (133.7.28.3 - R3's IP on
> > common
> > ethernet segment)
> >
> > My question is : WHAT TO DO IN SUCH SITUATION. I don't see any
> > workaround
> > without violating Lab requirements.
> >
> > r6#sh ip ro 160.100.100.0
> > Routing entry for 160.100.100.0/24
> > Known via "ospf 1", distance 110, metric 1
> > Tag 2, type extern 2, forward metric 74
> > Last update from 133.7.28.3 on Ethernet0, 02:58:43 ago
> > Routing Descriptor Blocks:
> > * 133.7.28.3, from 133.7.1.1, 02:58:43 ago, via Ethernet0
> > Route metric is 1, traffic share count is 1
> >
> > r6#sh ip bgp 160.100.100.0
> > BGP routing table entry for 160.100.100.0/24, version 0
> > Paths: (1 available, no best path)
> > Not advertised to any peer
> > 2001
> > 133.7.1.1 (metric 75) from 133.7.2.2 (133.7.2.2)
> > Origin IGP, metric 0, localpref 100, valid, internal, not
> > synchronized
> > Originator: 133.7.1.1, Cluster list: 133.7.1.1
> > r6#
> >
> > Thanks,
> >
> > Dmitry
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:48:39 GMT-3