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

[Steve Bertrand]

Oliver Boehmer (oboehmer) wrote:
> 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).

I'm not using next-hop-self. I've read that it is preferable to not use
it, but I will if I have to. My point was that when I remove .68 from
OSPF (which is my objective), the BGP learnt route automatically sets
the next-hop to .68 recursive via my null interface IP (192.168.222.1).
The next-hop really needs to be set to either 172.16.104.2 (lo), or
208.70.111.66 (ptp next-hop).

Is next-hop-self the only way around this behaviour (beside using a
static route)?

>> 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.

Indeed.

>> ...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..

What my goal is, is to have only loopbacks in OSPF, and nothing else.
I'll need to toy with next-hop-self to fix the issue.

Thanks for the feedback.

Steve