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 _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
