[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