BGP Deaggregation with Conditional Route Injection

Whenever there’s a weird request to do something totally illogical with BGP, there’s a knob in Cisco IOS to get it done (and increase the heartburn of CCIE candidates). Conditional Route Injection (the ability to insert more specific prefixes into BGP without having them in the IP routing table) is one of them.

Keep in mind: being a MacGyver is not a long-term strategy. Just because you can doesn’t mean that you should.

What is Conditional Route Injection? A feature that allows you to insert more-specific prefixes into the BGP table of a router (to have them advertised to its peers) without having them in the IP routing table.

Why would you need it? Traffic engineering (splitting inbound traffic by advertising more-specific prefixes over individual uplinks) immediately comes to mind, and I’m positive there are other creative uses tied to well-known mobility myths. Anything else? Please write a comment – I would really love to know who uses this feature and why.

Configuring Conditional Route Injection

The configuration seems easy:

  • Configure a prefix-list listing all more-specific prefixes you want to insert;
  • Configure a route-map using the above prefix-list in set ip address statement;
  • Configure another prefix list matching the less-specific aggregate prefix;

The prefixes you want to insert into the BGP table MUST be more specific prefixes of the one(s) matched by this prefix list.

  • Configure a third prefix list matching the source (advertising router) of the less-specific aggregate prefix;
  • Configure a second route map that matches the aggregate IP prefix with match ip address prefix-list statement and originating router with match ip route-source prefix-list statement;

The route map matching the aggregate prefix MUST have the match ip route-source statement; without it, the more-specific prefixes are not inserted.

  • Use both route maps in bgp inject-map router configuration command.

The requirement to match on IP route source seems annoying, but is actually quite cool. It allows you (for example) to advertise more specific prefixes for locally-advertised aggregates, but not for aggregates received from other locations (see this video for more details).

Here’s a working configuration that inserts two hosts routes ( and when the router receives from BGP neighbor

router bgp 65001
bgp inject-map HOSTS exist-map SUBNET copy-attributes
ip prefix-list HOSTS seq 5 permit
ip prefix-list HOSTS seq 10 permit
ip prefix-list RRC seq 5 permit
ip prefix-list SUBNET seq 5 permit
route-map SUBNET permit 10
match ip address prefix-list SUBNET
match ip route-source prefix-list RRC
route-map HOSTS permit 10
set ip address prefix-list HOSTS

The aggregate (less-specific) prefix MUST come from a BGP neighbor. Whoever designed this feature had enough common sense not to allow insertion of more-specific prefixes of a locally-originated prefix.


  1. On an unrelated topic..apologies for the question...why would a Cisco router display this message on a telnet session.

    "due to lack of security on this device, Anonymous has taken over the administration of this device"
    1. If I had to venture a guess, I would say someone else accessed the device and then did a 'send' to your session. Otherwise, they modified the 'motd'.
      I once did that to a Windows login for a home user on my cable network, over a decade ago, to just tell them they needed to set an administrator password (back then, you could see NetBIOS broadcasts from other hosts on your cable-provider's network).
  2. Ivan - Wouldn't this also be useful in the event that another AS accidentally hijacks your aggregated prefix? You would see your prefix advertised back to you via another AS, and conditionally inject de-aggregated prefixes so that you don't end up routing requests for cat videos to pakistan.
    1. Potentially, but I don't think the de-aggregation could be triggered automatically.
  3. I'm probably wrong, but I think I've seen this used to assist in split brain scenario for a hosting environment.

    One AS with a /21 prefix, Two sites, DC1 and DC2.

    When the internal interconnect fails and DC2 can't see the /21 prefix (via IBGP) then DC2 advertises its more specific /22. With default routes (solves issues with same AS) from upstream it provides connectivity between DC1 and DC2.

    Not saying its nice, pretty or appropriate as the AS is split. There are probably logic holes in it. Like why don't you advert the split subnet range from DC2, I think it was a billing issue (i.e DC2 links are only for DR situations).
    1. I'm not sure it is working in a split-brain scenario. Or maybe it does in a specific one, but as in DC2, you have to get the subnet via ibgp from your DC1 to possibly do this deaggregation. So I assume that in a case of DC1-2 Link failure, you don't get the subnet anymore, so your deaggregation does not work anymore. So your more-specific prefixes will not be advertised, so you cannot go from DC1 to DC2.

      Ivan could you clarify things for us? Thanks
    2. I did a crazy design once where I'd run an extra IBGP session across the public WAN (example: encrypted over Internet) to detect split-brain scenario. I think it's even documented in one of the DC case studies.

      Short summary: just because you can doesn't mean that you should ;))
    3. I see, it's like the eternal question in IT (or life): there is a way here, but is it the right way to arrive where I want to go?
  4. Could it be used in this context. We have a subnet for a DMZ where we have 2 types of customer facing servers, voip and web servers. Now the voip and web servers are randomly assigned static IP addresses. We would typically advertise the entire subnet to our BGP peer over a private line. But the customer wants the web traffic to use the internet reserving thw private line only for Voip. In this situation we can only use host routes to advestise the individual voip servers using BGP.
  5. Thanks for this, Ivan. This comes in really handy. I think it's important to note this is only available on Cisco gear. I have four different vendors in my lab, and only Cisco provides this feature.
  6. could it be used if the router recieves /16 from OSPF neighbor and we need to advertise only /24 inside this /16 to an EBGP neighbor?

    i'm able to configure this feature if we recieve the /16 from another BGP neigbor but not able to do if the prefix /16 if recieved from an OSPF neighbor.

  7. I haven't labbed it up yet, but can it inject host routes based on the existence of a default route (the ultimate aggregate)?
    1. How about labbing it and reporting the results? ;)
  8. I tested it ... it works fine with the default route (as I expected it to).
    1. Awesome. Thanks for confirming it (and it's nice to see default route doesn't get a special treatment like it does sometimes).
  9. Hello Ivan,
    I would like to do something similar but without addition BGP peering.
    I have a single upstream BGP connection and an interface with /24 mask.
    Due to some special requirements I would need to advertise the interface IP address as /32 if the interface itself is up and reachable remotely.
    And no matter how I try the automatically generated /32 Local route prevents me to achieve this. I also tried conditional advertisement and this inject-map stuff as well (with as the source...) but no luck.
    Do you have any idea maybe?
    1. I haven't touched this stuff in years (more than 3 years to be precise). I could find someone to help you in an ExpertExpress session ( if you'd be interested - please contact us through the "About / Contact" in top menu.
  10. Anyone know if this feature can be used if the less specific route comes from an IGP? I'm guessing no, since, from BGP perspective, it will be locally originated. This feature was almost a homerun for my corner case.
    1. I'll answer my own question. I labbed it up and you CANNOT use a route source from IGP. But, if you redis that IGP into BGP and can receive the prefix from an IBGP neighbor (think dual cores that are IBGP neighbors), that WILL work.
Add comment