BGP aggregate

[Balajee Muggalla]

Hi,

    I have the following info on my router R2.

R1------R2

R2#show ip bgp

BGP table version is 14, local router ID is 20.1.1.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

*> 30.1.0.0/16      0.0.0.0                       100  32768 i ------ Created aggregate on this router

s>i30.1.1.0/24      10.1.1.1                 0    100      0 i ------ Received from R1

s>i30.1.2.0/24      10.1.1.1                 0    100      0 i ------ Received from R1

R2#

*Mar  6 12:11:53.911: %SYS-5-CONFIG_I: Configured from console by console

R2#

R2#show ip bgp community no-export

BGP table version is 14, local router ID is 20.1.1.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

*> 30.1.0.0/16      0.0.0.0                       100  32768 i   <<<<<<<<<<

s>i30.1.1.0/24      10.1.1.1                 0    100      0 i

R2#

router bgp 100

no synchronization

bgp log-neighbor-changes

aggregate-address 30.1.0.0 255.255.0.0 as-set summary-only

neighbor 10.1.1.1 remote-as 100

neighbor 20.1.1.2 remote-as 200

no auto-summary

!

R1 is sending 30.1.1.0/24 with community no-export".

When I configure the aggregate command without as-set like "aggregate-address 30.1.0.0 255.255.0.0 summary-only", "show ip bgp community no-export" is as shown below.

R2#show ip bgp community no-export

BGP table version is 14, local router ID is 20.1.1.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path

s>i30.1.1.0/24      10.1.1.1                 0    100      0 i

R2#

Here, aggregate route is missing from table. Could anyone explain why so?

Thanks,

Balajee

[Giuseppe Larosa]

Hello Balajee,

for the aggregate route to be generated a valid component route has to be present in the local node BGP table.

In your test the component route is flagged as suppressed as it has BGP community no-export, from the point of view of the node it is like no component route is present in the BGP table and  the aggregate route is not generated.

Try to repeat your test with a component route without BGP community no-export set and you will see a change

In other terms you are asking to generate an aggregate starting from a component route that cannot be advertised to any other node.

I think it is logically correct the result you see.

You can use the summary-only option to suppress valid component routes.

Hope to help

Giuseppe

[Balajee Muggalla]

Hi,

   Thanks for your response, but I don't think my question is answered. Let me elaborate my question.

Assume this topology : R1----R2----R3

      R1 is sending 30.1.1.0/24 with community "no-export" and 30.1.2.0/24 with community "none" to R2 via iBGP.

When I created aggregate route with command "aggregate-address 30.1.0.0 255.255.0.0 as-set summary-only" on R2, aggregate route is not being advertised to R3 which is expected because one of the component's route 30.1.1.0/24 has no-export attribute.

     But when I create aggregate without "as-set" like "aggregate-address 30.1.0.0 255.255.0.0 summary-only", aggregate is being to advertised to R3 which is not expected(atlas for me). Do you know why as-set is making difference here?

Thanks,

Balajee

[Giuseppe Larosa]

Hello Balajee,

I see your point now.

The as-set asks for the creation of an aggregate route with an AS set attribute that is the join of the BGP AS paths of component routes. We can see this as a merge of attributes of component routes.

Without the as-set keyword the aggregate route BGP attributes are generated on the fly and not inherited from the component routes.

More specifically it looks like that without the as-set keyword BGP communities of component routes are not inherited by the aggregate route.

I have found a note about this in the BGP command reference.

see

http://www.cisco.com/en/US/docs/ios-xml/ios/iproute_bgp/command/bgp-a1.html#GUID-D8ACCE05-4ACE-42D5-8EC6-9607FF7FA9FD

>> Using the                  attribute-map keyword allows attributes of the aggregate route to be changed. This form of the              aggregate-address command  is useful when one of the routes forming the AS_SET is configured with  an attribute such as the community no-export attribute, which would  prevent the aggregate route from being exported. An attribute map route  map can be created to change the aggregate attributes.

This sentence is a confirmation of the behaviour you see with as-set option set: one component route with BGP community no-export is enough for preventing advertisement of the aggregate route.

When the option as-set is not set, each component route contributes to the aggregate route in a more indirect way, so in your test you have a valid component route ( the one without BGP community no-export set) and this is enough to trigger advertisement of the aggregate route.

In other terms when as-set is not set each component route is examined indipendently in the check to decide if the aggregate route has to be advertised or not.

On the other hand, when as-set option is set we can think of a merge of component routes BGP communities to create the BGP communities associated to the aggregate route, and if one component route has BGP community no-export this is inherited by the aggregate route and applied preventing aggregate route advertisement.

This peculiar aspect of BGP aggregates is not well documented.

Hope to help

Giuseppe