BGP policy, outbound route injection to specific peer?

[Shawn Kleinart]

I am using BGP conditional route injection, so am familiar with it...

http://www.cisco.com/c/en/us/td/docs/ios/12_2s/feature/guide/fsbgpri.html

http://blog.ipspace.net/2015/01/bgp-deaggregation-with-conditional.html

I am using it as an inbound policy from a peer that could not modify their prefixes.  They were sending us a few /19 - /20 prefixes, and we had specific traffic engineering needs that we only needed a few /27 networks within those.  We match the aggregate (/19), we then 'inject' a few specific routes (/27) into our BGP table (and propagate via iBGP).  This worked well for that need.

Problem:  I am now presented with a new situation/scenario; We have "application specific" /25 networks that exist in our RIB (OSPF and iBGP).  However, I have two eBGP peers who have a design requirement that require advertisements that do not overlap (are unique).  Meaning, I need to send peer A a few /32's within the /25 and peer B a few different /32's within the same /25.  Is that possible?
(I wish the application/platform allowed some level of virtualization, secondary or virtual interfaces - so we could create a new subnet per vendor.  But it doesn't.)

Obviously the /32's don't exist in our RIB; I am unsure how to originate anything that is not in our RIB.  More importantly, I don't want them to exist in our RIB (be in the iBGP table), I just want to "originate" the BGP advertisement to our two neighbors.  Basically, I want to generate "phantom" BGP advertisements (dynamically, based on a match in the RIB).  Possible?

(Or, is the only solution to require they do "injection" on their end (inbound))?

Thanks much, Shawn.

[Richard Burts]

Shawn

With your restriction of not having the /32 entries in your RIB I am not sure there is any solution other than trying to do "injection" on their end. If you would allow the entries in the RIB then the solution becomes fairly straightforward. If the /32 entry is in the RIB then you configure BGP network statements with mask for the /32 entries. Then you configure outbound route filtering to permit those network entries to the specific neighbors who you want to receive them and to deny those network entries to all other neighbors.

HTH

Rick

[Shawn Kleinart]

Is there a good way to dynamically 'inject' a /32 (or anything more specific) than a "connected" /25 subnet (vlan/SVI) into the RIB?

Clearly I want the more specific prefix to route back to the origination/source.  I also understand that the Cisco BGP conditional route injection will  not work on the same router that originates the "aggregate" prefix; it needs to receive the matching prefix from a matching/defined next hop/host address.  Therefore, if I have an access/aggregation router with the /25, and I have a core/edge router do the injection... that is likely to cause a routing loop.  We run OSPF as our IGP.  So if I can get the /32 into OSPF (idealy without static redist), that provides what I need.

I am trying to avoid static routes.  If I did a static route (on the connected routers), I presume the next hop wouldn't be relevant; I would add the static route /32 on the same routers (2) that have the VRRP vlan (/25 subnet) interface.  The next hop could probably just be the interface alone (with no NH address), else the VRRP VIP (the router itself) for configuration readability/clarity.  I'll have to lab it up... my mind is just not clicking on how the router would see the /32 RIB entry, and a /25 FIB... so I hope/presume it would just switch the traffic (layer 2) vs try to route it (layer 3).  I haven't done anything that ugly in a while.  Then it's just a matter of 'leaking' the BGP route to the neighbors I want.  We're only talking 20 ish total /32's... so I am not worried about routing table size of our internal table.

[paul driver]

Hello

how about static routes to the null interface 0  and then advertise via bgp either via redistrubute static or network command

res

paul

[Peter Koltl]

I'm afraid a static Null0 route would result in packets dropped due to longest match rule. I'd rather add /32 routes with correct next hop.