From: Peter van Oene (pvo@xxxxxxxxxxxx)
Date: Wed Apr 03 2002 - 13:29:50 GMT-3
It pains me to write this email as I have tremendous disdain for this topic
:-) However, the question keeps coming up so I thought I would spend some
time with it. I mocked the topology up using the labs at Gett Labs
(www.gettcomm.com) The scenario presented is as follows:
R2 -----------R3---------------- R1 -----<EBGP>---------R4
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.
Assuming I'm correct (which I can't verify without bothering the folks who
coded it in the first place) This means that this situational cannot be
resolved. That is to say that so long as a route is reflected, it will not
synchronize for route reflector clients. This assumes a single area OSPF
network. I imagine if R3 where an NSSA ABR and the route was brought into
the network as a type 7, the route might synchronize given the Type 5 will
be sourced from the ABR thereby making the Peer ID match the OSPF
Advertising Router. This also makes me wonder if you run into similar
issues if R3 is an NSSA ABR, and not a route reflector (that is, R1 peers
directly with R2). However, I'm about finished wasting my time on this
ridiculous configuration :)
The underlying point is that these technologies were not designed to work
together as they solve different problems. Hence, making them work might
be problematic to the point of being impossible. Further, testing on it
would seem unfair in my opinion. I further should note that I have no idea
if this is a test topic or not, however has simply seen a lot of traffic on
this list related to it. Running confed's or changing OSPF topologies in
my opinion change the topology too dramatically to be considered a valid
answer to the question.
Pete
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:57:52 GMT-3