[c-nsp] One more issue regarding iBGP-OSPF

[Oliver Boehmer (oboehmer)]

Steve Bertrand <> wrote on Thursday, February 05, 2009 15:26:

> I'm having a little more trouble trying to put my finger on why a PtP
> address block, announced successfully via iBGP is improperly routed
> recursively if I don't put it into my OSPF config.
> 
> Right off the bat, I know that having the 111.x space on both sides of
> rtrB is completely breaking aggregation, but I really want to
> understand the problem before I look further at that:
> 
> rtrA-111.65/30---111.66/30-rtrB-111.69/30---111.70/30-rtrC
> 
> rtrA lo10 = 172.16.104.1/32
> rtrB lo10 = 172.16.104.2/32
> rtrC == client with eBGP peering to rtrB
> 
> In order for things to work as expected, I have to have the 111.68 and
> 111.64 in OSPF on rtrB, and the 111.64 on rtrA
> 
>  network 172.16.104.x 0.0.0.0 area 0
>  network 208.70.111.64 0.0.0.3 area 0
>  network 208.70.111.68 0.0.0.3 area 0

well, this sounds logical to me as you want to run OSPF between rtrA and
rtrB, don't you? So you have to enable OSPF on the interface.
There shouldn't be a reason to put .68 into OSPF as you seem to be using
next-hop-self on rtrB, so the next-hop is the loopback (advertised via
OSPF).

> Both of these routes are already in iBGP, but not used with OSPF
> running: 
>
> B   208.70.111.68/30 [200/0] via 172.16.104.2, 1d11h35m

this is expected as OSPF has a lower admin distance.
 
> ...but if I take them out of OSPF, then rtrA inserts the BGP learnt
> route into the table, and makes it recursive via 192.168.222.1/32,
> which is my null interface.
> 
> That then immediately breaks the route to the client as well, as .70
> is null-routed.

Well, see above: With OSPF not enabled between rtrA and B, rtrA cannot
resolve the next-hop loopback..

> Have I described my issue clearly enough for someone to see what I am
> missing?

Not sure, I might also be missing something obvious, and possibly also
missing what you're trying to achieve..

	oli