Using suppress-map and attribute-map together on same aggregate

[j.a.m.e.s]

All,

I understand that an attribute-map can be applied to an BGP aggregate-address statement to set certain attributes such as community. However, if I also use a suppress-map on the same statement, will the attribute-map also get applied to routes which leak through the aggregate?

In the example below, will 10.0.1.0/24 get the 65000:1 community?

router bgp 65000
 [...]
 address-family ipv4 unicast
  redistribute eigrp X route-map RM-REDIST-EIGRP-BGP
  aggregate-address 10.0.0.0/8 suppress-map RM-CONDLEAK-BGP attribute-map RM-ATTR-DATACENTRE1
 exit
exit

! Negative Supress-Map. ie. If leaking, only leak these prefixes and suppress everything else:
route-map RM-CONDLEAK-BGP deny 10
 description Only leak when tagged with DATACENTRE1 backdoor tag:
 match ip address prefix-list BPFX-CONDLEAK
exit
ip prefix-list BPFX-CONDLEAK seq 10 permit 10.0.1.0/24

! Set BGP community, but will this also apply to leaking (non-suppressed) routes?
route-map RM-ATTR-DATACENTRE1 permit 10
 set community 65000:1 additive
exit

Kind regards

James.

[Giuseppe Larosa]

Hello @j.a.m.e.s ,

according to BGP command reference the attribute-map applies only to the aggregate route see

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/command/irg-cr-book/bgp-a1.html#wp2343576123

You can emulate the desired effect by adding a set community 65000:1 additive in the suppress-map.

However, your suppress-map should have at least one permit statement otherwise no component routes are allowed.

with a negative logic you will need

route-map RM-CONDLEAK-BGP deny 10
 description Only leak when tagged with DATACENTRE1 backdoor tag:
 match ip address prefix-list BPFX-CONDLEAK
route-map RM-CONDLEAK-BGP permit 20
set community 65000:1 additive

Hope to help
Giuseppe

[j.a.m.e.s]

@Giuseppe Larosa 

Thanks for pointing out that I missed the "permit all" route-map statement 20 - that is definitely needed to make sure most the component routes are suppressed!

The trouble is that I'm not sure your suggestion would work because it applies a community on the component routes to be suppressed, rather than the component routes to be announced.

Perhaps the attribute-map would simply apply to both the summary-only route and 10.0.1.0/24?

[Giuseppe Larosa · Accepted solution]

Hello @j.a.m.e.s ,

you are right I was thinking of the unsuppress-map feature that likely can be used in combination with summary-only option.

At this point I agree I don't see an easy way to set the BGP community on component routes that are denied from suppression = allowed

The set community should appear in the first deny block but I am afraid it will not be effective (to be tested but little hope)

Hope to help

Giuseppe

[j.a.m.e.s]

I think perhaps an unsuppress-map could be used and the logic could be swapped around (which would allow the set community to be placed in the permit statement) but I should have mentioned that I'm using nx-os and I think the unsuppress-map is only available to IOS (and cousins).

[j.a.m.e.s]

I realise this is a couple of years on, but I've since read in the nx-os configuration guide that a community can be set on the component routes leaked through the supress-map:

---

 If you specify the suppress-map option while performing a BGP route aggregation, you can set the community attribute for a BGP route update. This option enables you to set community attributes on the more-specific routes.

---

Presumably this means a "set" statement within the "deny" clause of the route-map, which is a bit odd. If anyone has tested this, please let me know.

---

[j.a.m.e.s]

Just tested on nxos 7.x and it's not working as documented.

[Giuseppe Larosa]

Hello @j.a.m.e.s ,

thanks for your feedback 

I agree that with an unsupress-map and permit statement it would be more logical

Hope to help

Giuseppe

[j.a.m.e.s]

TAC have opened bug CSCwc91318 with the development team to investigate.

[j.a.m.e.s]

I have good news. This turned out to be a documentation bug. It's possible to set communities on components leaked through the aggregate in nx-os. It's an arcane syntax and the documentation is too brief to understand what's actually required, so let me explain by example here:

router bgp 65000
 router-id 10.0.0.1
  address-family ipv4 unicast
   network 2.0.0.1/32 <- Will get the "Green" community
   network 2.0.0.2/32 <- Will get the "Blue" community
   network 2.0.0.3/32 <- Will be supressed
   aggregate-address 2.0.0.0/8 suppress-map RM-SUP-TEST
  exit
 exit
ip route 2.0.0.1/32 Null0 name Test1
ip route 2.0.0.2/32 Null0 name Test2
ip route 2.0.0.3/32 Null0 name Test3

The outcome we want is that .1 and .2 are leaked with the appropriate communities, but .3 is supressed (aggregated into 2.0.0.0/8). To achieve this, use the following route-map:

route-map RM-SUP-TEST permit 10
  description Leak these prefixes with a certain community
  match ip address prefix-list PL-SUP-TEST
  set community 65000:10
route-map RM-SUP-TEST permit 20
description Leak these prefixes with another community
  match ip address prefix-list PL-SUP-TEST-2
  set community 65000:20
route-map RM-SUP-TEST permit 30
  description Supress All Other prefixes
exit
ip prefix-list PL-SUP-TEST seq 10 permit 2.0.0.1/32
ip prefix-list PL-SUP-TEST-2 seq 10 permit 2.0.0.2/32

So basically a permit statement with both a match and a set clause will act like a "deny" and therefore allow the prefix to leak through with a certain BGP community appended.

[Giuseppe Larosa]

Hello @j.a.m.e.s ,

thanks for your feedback.

The working configuration is a little strange at first sight as the permit statement would mean to suppress the matching component route(s). However, the set action with setting BGP community attribute make the device to understand your intent that is advertise the matched component route(s) with the changed BGP community attribute.

It looks like a workaround for the lack of support of the unsupress-map option.

Hope to help

Giuseppe