BGP Suppress Aggregate

[joshuacmoore]

Hello, is there any way with either IOS or IOS-XR (route policy language) to suppress an aggregate with BGP? For instance if I receive a longer prefix that's part of an aggregate with a certain tag or community, is there a way to tell BGP "don't advertise the aggregate"?

[Peter Paluch]

Hi Joshua,

For instance if I receive a longer prefix that's part of an aggregate with a certain tag or community, is there a way to tell BGP "don't advertise the aggregate"?

I may be avoiding a direct answer but let me ask you a counterquestion: What if you consistently advertised the aggregate route along with the more specific prefix? Any peer that would learn both of them would, by the virtue of longest prefix match, use the more specific prefix to route packets toward respective destinations, so in the end, the effect would be similar to stopping the aggregate from being advertised.

Perhaps you could explain why you want to achieve this behavior.

Best regards,
Peter

[joshuacmoore]

The objective is to cause a more specific prefix that is part of an aggregate to suppress the aggregate announcement.

This is in reaction to a BGP blackhole server. For example, I have 1.1.1.0/24 advertised to my upstream ISP. I will receive an advertisement for 1.1.1.1/32 into BGP. I want my router to react to that 1.1.1.1/32 by dropping the 1.1.1.0/24 advertisement.

[Peter Paluch]

Hi Joshua,

I have been looking at the common forms of suppressing/unsuppresing networks in BGP but none of them appears to do exactly what you are trying to accomplish.

You had an example of advertising 1.1.1.0/24, and upon receiving 1.1.1.1/32, stopping the advertisement of 1.1.1.0/24. I have the following questions:

1. How many networks of the "1.1.1.0/24"-type you need to handle this way?
2. Is it safe to assume that for a particular "1.1.1.0/24"-type network, only a single, constant subnet of the "1.1.1.1/32" type will always be used as an indicator of stopping the summary advertisemet?

Best regards,
Peter

[joshuacmoore]

I performed a maintenance last night that pulled out the manual summarized aggregates. So now the only BGP routes that exist are the originals learned from iBGP.

Regarding your question, there could be several more-specifc-prefixes generated by the blackhole server. Some may come simultaneously some may come at different times. The point is that while a host route exists I don't want to advertise the host route or the corresponding subnet to the ISP.

The logic would be like this:

while exists more-specific-prefix (

if more-specific-prefix has less-specific-prefix then suppress more-specific-prefix and less-specific-prefix)

I'm also looking into changing the behavior of the blackhole server to simply advertise whole networks instead of host routes. This way I can set the blackhole routes to more preferred and then filter them at the edge to the ISP based off of community/tag.

Quick sanity check: If two routes exists for a BGP network in the BGP table; one preferred (>best), one not preferred and I filter the preferred (>best) route to the ISP provider, the less preferred route will not be advertised, correct?

[Peter Paluch]

Hi Joshua,

Unfortunately, I am at a loss here - I do not currently see any easy way of implementing this. Perhaps some EEM script could be written that would react to changes in the routing table and do some changes to the configuration on the fly but I am not strong in this area. BGP itself does not appear to have any tools helpful to accomplish what you need, and I haven't come across any smart kludge that we could use to make this work.

EDIT: I was way wrong. See Jose Jara's response below. The neighbor advertise-map is the tool of choice.

Quick sanity check: If two routes exists for a BGP network in the BGP table; one preferred (>best), one not preferred and I filter the preferred (>best) route to the ISP provider, the less preferred route will not be advertised, correct?

Correct.

Best regards,
Peter

[Jose Jara · Accepted solution]

Hi Joshua,

you could use conditional advertisement feature in this case. It could be done like this:

1. Route-map ADVERTISE ------ to match the aggregate, via an ACL

2. Route-map NON-EXIST ------- to match the specific prefixes.

3. Applying it to a neighbor:

neighbor x.x.x.x advertise-map ADVERTISE non-exist-map NON-EXIST 

It will advertise the aggregate as long as it does not have the specific prefixes that you specify in the Route-map NON-EXIST.

Best Regards,

Jose.

[Peter Paluch]

Jose,

I must have been blind or something! What was I thinking when I skipped the neighbor advertise-map? Aaah... one never stops learning, right? :) Rated as deserved, and thank you very much for joining!

Joshua, Jose is right - the conditional advertisement in BGP should actually do the trick. Read more here:

http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/16137-cond-adv.html

Best regards,
Peter

[milan.kulik]

Hi Jose,

are you sure this will work?

a) the specific prefixes that you specify in the Route-map NON-EXIST will still be advertised to the neighbor,

b) you need to explicitely specify each of them within the NON-EXIST route-map to get a match.

But my understandig of the original request is:

There is a blackhole server advertising host routes within the aggregate subnet range. But you don't know which host route will be used in advance. So for a /24 aggregate subnet, e.g.,  you would have to specify 255 host routes within the NON-EXIST route-map, I'm afraid?

Best regards,

Milan

[Jose Jara]

Hi Milan,

yes, this will work but you´re right, you need to specify manually the host routes.

Best Regards,

Jose.

[joshuacmoore]

Shouldn't we be able to overcome this easily with a prefix list instead of ACL? Just do "eq 32"?

[Jose Jara]

Joshua,

I am afraid but this, with a prefix-list specifiying an eq 32 or something to track a bunch of prefixes, won´t work. I´ve tested it and you must specify the exact prefixes.

Best Regards,

Jose.

[joshuacmoore]

Could we match local pref or MED or even a tag?

[Jose Jara]

No, with conditional advertisement you need to specify the prefixes.

I have thought in a different way of implementation that can meet the dynamic behavior you are looking for. It will use BGP aggregation:

aggregate-address 1.0.0.0 255.0.0.0 summary-only attribute-map ATT

route-map ATT

set community no-advertise

First, with BGP aggregation by default the aggregate will be generated as long as there are more specific prefixes, so with the /32 will be generated.

Secondly, I have specified summary-only to "advertise" just the aggregate and suppress the specifics.

Then, to filter the aggregate when it receives one or more host routes, I have added a route-map setting the community no-advertise.

Finally, see Milan's post about making this prefix better.

Finally, take into account that you should make this locally generated aggregate better by changing the AD if needed. Let's say it is generated by a static route pointing to null 0, change the AD of the static making it worse, the same if you're receiving it by eBGP. 

Best Regards,

Jose.

[milan.kulik]

Hi Jose,

yes, I believe this should work.

You just don't need to change the AD but BGP attributes, I believe?

So to use

route-map ATT

set community no-advertise

set weight 50000

e.g.?

Best regards,

Milan