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

Steve Bertrand steve at ibctech.ca
Thu Feb 5 09:25:32 EST 2009


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

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

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

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

Thanks,

Steve


More information about the cisco-nsp mailing list