Re: BGP and RR problem

From: Yagnesh Patel (Yagnesh.Patel@xxxxxxxxxxx)
Date: Sun Jun 09 2002 - 22:42:36 GMT-3


   
This is a known limitation of using RR and OSPF as your IGP. What i am
looking for is possible solutions.

Here is a good explanation given by someone in this groupstudy.

R1, R2, and R3 are in AS1, R4 in AS 4. R1,R2, and R3 are OSPF backbone
routers (all in area 0). In this case, R4 advertises a prefix into AS1 to
R1. R1 peers with R3, which in turn reflects toward R2. All routers in
AS1 are running BGP in synchronized mode. Of note, R1 resets the BGP
next_hop to self (this is not necessary, however in my lab I didn't place
the R3-R4 link in OSPF). Finally, R1 also redistributes BGP into OSPF.

As most have seen, in this case, R3 has no problems synchronizing the
route. That is to say that the OSPF RID and BGP RID seem to match. Note
the route is 100/8

r3#show ip bgp 100.0.0.0
BGP routing table entry for 100.0.0.0/8, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x208
   Advertised to non peer-group peers:
   10.0.0.2
   4
     10.0.0.1 (metric 782) from 10.0.0.1 (10.0.0.1)
       Origin incomplete, metric 0, localpref 100, valid, internal,
synchronized, best

However, R3 then reflects the route toward R2 which is unalbe to
synchronize the route.

r2#show ip bgp 100.0.0.0
BGP routing table entry for 100.0.0.0/8, version 0
Paths: (1 available, no best path)
   Not advertised to any peer
   4
     10.0.0.1 (metric 830) from 10.0.0.3 (10.0.0.1)
       Origin incomplete, metric 0, localpref 100, valid, internal, not
synchronized
       Originator: 10.0.0.1, Cluster list: 10.0.0.3

Yet, the route is in the routing table:

r2#show ip route 100.0.0.0
Routing entry for 100.0.0.0/8
   Known via "ospf 1", distance 110, metric 1
   Tag 4, type extern 2, forward metric 829
   Last update from 10.1.0.6 on Serial1/1, 00:01:49 ago
   Routing Descriptor Blocks:
   * 10.1.0.6, from 10.0.0.1, 00:01:49 ago, via Serial1/1
       Route metric is 1, traffic share count is 1

Nothing new here, however I figured it was worth illustrating the operation
for those who hadn't seen it. Per the original and now discontinued
specification, R2 needs to match the BGP RID to the OSPF RID for the
route. As seen above, the OSPF route is sourced from 10.0.0.1, and the BGP
originator is 10.0.0.1 which should mean that the route would
synchronize. I expect that the problem lies with how Cisco implemented
Synchronization in the first place. I don't believe the algorithm looks at
the BGP originator, but at the peer ID of the router that sent it the
route. In this case, it would compare 10.0.0.1 in OSPF (R1) to 10.0.0.3 in
BGP (R3) and thus decides the route doesn't synchronize. This behavior
would in fact not be in keeping with the original specifications, however
these specifications were not designed for use in networks where route
reflection played.

Treptow, Georg wrote:

>If you were to do a show ip bgp x.x.x.x on R1 for on of the received routes
>from R4, what do you see? Advertised to ..... or Not advertised to any
>peers...
>
>-----Original Message-----
>From: Yagnesh Patel [mailto:Yagnesh.Patel@verizon.net]
>Sent: Sunday, June 09, 2002 8:15 PM
>To: Treptow, Georg
>Cc: ccielab@groupstudy.com
>Subject: Re: BGP and RR problem
>
>
>No, Let me make it clear.
>
>R2(RRClient_2)------IBGP-----R3(RR)--------IBGP--------(RRClient_1)R1-----<E
>BGP>---------R4
>
>Thanks
>
>
>
>
>Treptow, Georg wrote:
>
>
>
>>Does R1 peer with R3 and R2?
>>
>>-----Original Message-----
>>From: Yagnesh Patel [mailto:Yagnesh.Patel@verizon.net]
>>Sent: Sunday, June 09, 2002 7:20 PM
>>To: ccielab@groupstudy.com
>>Subject: BGP and RR problem
>>
>>
>>Hi,
>>I know the following problem is frequently discussed in the group study
>>but couldn't find any definite answers. Can someone please direct me to
>>the possible solutions to this problem
>>
>>R2 ------IBGP-----R3 (RR)--------IBGP-------- R1 -----<EBGP>---------R4
>>
>>
>>Sync is enabled in all router. R1's reflected routes are not sync in R2
>>router.
>>
>>Thanks



This archive was generated by hypermail 2.1.4 : Tue Jul 02 2002 - 08:12:30 GMT-3