Hi Alex,
I do have a good understanding of BGP and its operation and maybe this is some other issue. To simplify matters I have made a very, very basic configuration (it did seem to work above - but now I am seeing something weird:
Firstly, the main reason for a route-reflector is to get around the need for a full mesh and it is obviously more scaleable. This is in place to stop loops forming and basically means that an iBGP router that receives a route from a neighbor is not allowed to pass that route on (hence the requirement of a full mesh). So, here is my very basic topology (again, using the Juniper recommendations to test why this is happening):
lon-prouter (192.168.1.254 lo0) <--> RR (192.168.50.250 lo0) <--> Swin-prouter (192.168.10.252)
So, I have only, as an initial test, configured the lon-prouter as a bgp neighbor to the RR. The RR does not yet have a cluster command and so therefore is acting as a normal iBGP router. I have OSPF configured to include the loopback addresses and the lo interface is also the RID for the three systems. Here are the very basic configs:
lon-prouter:
set interfaces ge-0/0/0 unit 0 description to-rr
set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.1/30
set interfaces ge-0/0/1 unit 0 description to-dummy
set interfaces ge-0/0/1 unit 0 family inet address 172.16.10.2/24
set interfaces lo0 unit 0 family inet address 192.168.1.254/32
set routing-options router-id 192.168.1.254
set routing-options autonomous-system 44009
set protocols bgp group internal-peers type internal
set protocols bgp group internal-peers local-address 192.168.1.254
set protocols bgp group internal-peers log-updown
set protocols bgp group internal-peers export export-route
set protocols bgp group internal-peers peer-as 44009
set protocols bgp group internal-peers neighbor 192.168.50.250
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set policy-options policy-statement export-route term 1 from protocol ospf
set policy-options policy-statement export-route term 1 then accept
Route-Reflector:
set interfaces ge-0/0/0 unit 0 description to-london-pr1
set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.2/30
set interfaces ge-0/0/1 unit 0 description to-swindon-pr1
set interfaces ge-0/0/1 unit 0 family inet address 192.168.1.6/30
set interfaces ge-0/0/2 unit 0 description to-london-pr2
set interfaces ge-0/0/2 unit 0 family inet address 192.168.1.10/30
set interfaces ge-0/0/3 unit 0 description to-swindon-pr2
set interfaces ge-0/0/3 unit 0 family inet address 192.168.1.14/30
set interfaces lo0 unit 0 family inet address 192.168.50.250/32
set routing-options router-id 192.168.50.250
set routing-options autonomous-system 44009
set protocols bgp group internal-peers type internal
set protocols bgp group internal-peers local-address 192.168.50.250
set protocols bgp group internal-peers log-updown
set protocols bgp group internal-peers export export-route
set protocols bgp group internal-peers peer-as 44009
set protocols bgp group internal-peers neighbor 192.168.1.254
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set policy-options policy-statement export-route term 1 from protocol ospf
set policy-options policy-statement export-route term 1 then accept
Swin-prouter:
set interfaces ge-0/0/1 unit 0 description to-rr
set interfaces ge-0/0/1 unit 0 family inet address 192.168.1.5/30
set interfaces lo0 unit 0 family inet address 192.168.10.252/32
set routing-options router-id 192.168.10.252
set routing-options autonomous-system 44009
set protocols bgp group internal-peers type internal
set protocols bgp group internal-peers local-address 192.168.10.252
set protocols bgp group internal-peers log-updown
set protocols bgp group internal-peers export export-route
set protocols bgp group internal-peers peer-as 44009
set protocols bgp group internal-peers neighbor 192.168.50.250
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set policy-options policy-statement export-route term 1 from protocol ospf
set policy-options policy-statement export-route term 1 then accept
Why am I seeing the loopback address for the swi-prouter in the bgp forwarding table on lon-prouter when:
1: swi-prouter is not even peer'd with the RR?
2: The RR is not yet even configured as an RR?
So the RR (normal router currently) is forwarding the loopback address anyway, thus ignoring all the BGP full mesh rules, as shown below (with the above config):
root@london-prouter-1# run show route 192.168.10.252
inet.0: 9 destinations, 12 routes (9 active, 0 holddown, 2 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.10.252/32 *[OSPF/10] 00:02:57, metric 2
> to 192.168.1.2 via ge-0/0/0.0
[BGP/170] 00:02:14, MED 1, localpref 100, from 192.168.50.250
AS path: I, validation-state: unverified
> to 192.168.1.2 via ge-0/0/0.0
This seems strange. It is as though the RR is getting the route from OSPF, which is being injected into BGP but even though the reflector rule states:
A prefix advertised by a client is advertised to all peers - but, in this case the RR is not even configured yet as an RR but as an iBGP router with 2 peers.
Maybe I am missing something silly, but this seems to be going against the rules unless OSPF is causing some fundamental issue.
As an add on, I have also tested by adding "swin-prouter" to the neighbor list on the RR so there is a peering there just in case the RR was seeing the route from swi-prouter via OSPF and injecting it into BGP and therefore seeing lon-prouter as its neighbor. So now it should 100% not be passing it on as it is NOT an RR yet.