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