Route Aggregation Advertisement and Discard

[woogx]

Hi all,

I am going through one of the CCIE BGP lab practices for route aggregation (CCIE Enterprise Infrastructure Foundation by Narbik). There is one particular lab (under BGP lab 6 task 4). Basically, it asked to configure R2 such that only R1 and R4 can accept the aggregate, whereas R3 will receive the aggregate, but it shall discard it. What troubles me is that I do not believe there is any command under route aggregation for such activity. The only thing I can think of is BGP community no-export function. That said, I do not think EBGP neighbor will discard the prefix after receiving it. I'd appreciate some pointers on that. Many thanks.

 

[MHM Cisco World]

aggregate can config with set AS, this can config for aggregate to add the AS of R3 which is AS=300 and hence the R3 will discard it.  
I will try lab this case and share result with you 
Understanding Route Aggregation in BGP - Cisco

[MHM Cisco World]

R2# configure terminal
R2 (config)# route-map ATT_MAP permit 10
R2 (config-route-map)# set community 100:100
R2 (config)# router bgp 100
R2 (config-router)# neighbor x.x.x.1 send-community
R2 (config-router)# aggregate-address 50.0.0.0 255.255.0.0 summary-only as-set attribute-map ATT_MAP
R2 (config-router)# exit

R3 (config)#ip community-list 1 permit 100:100
R3 (config)#route-map IN deny 10
R3 (config)#match ip community-list 1
R3 (config)#route-map IN permit 20
R3 (config)# router bgp 200
R3 (config-router)# neigbhbor x.x.x.2 route-map IN in 
R3 (config-router)# exit

this can done to make R3 not accept the aggregate from R2

[woogx]

Thanks, MHM. This is the first time I used this. I will lab it up tonight and couple it with David's answer. Hopefully, I will seek out the proper answer. The journey to CCIE is interesting. Finding answers and solving problems are fascinating.

[MHM Cisco World]

regarding my answer the

attribute-map

can fine filter which prefix you want to deny and which you can permit. 
anyway lab yourself is better to understand how aggregate with attribute map work. 

[woogx]

Hi MHM,

Just spend some time to understand the BGP community a little better. I think your intention is for R2 (the aggregator) to send prefix with a community tag of 100:100. Then R3 with a specific denial statement to deny the incoming prefix with a specific BGP community tag of 100:100. In a general sense, this should work in principle. That said, this isn't quite necessary for this lab because both R3 and R4 deny the aggregate route from R2 largely due to routing loop prevention already. So I will not be able to tell if your code can actually work with this lab. Then I thought about it the other way around. The goal is to announce the aggregate route from R2 to R1 and R4. Since R3 and R4 are rejecting the routes after the aggregation (please see the pre-check result), and R1 is already receiving the aggregate route, what's left is to make sure the aggregate route will be announced back to R4. So instead of having a denial statement on R3, I tried a permit statement on R4 with the community 100:100 with the following;

R2# configure terminal
R2 (config)# route-map ATT_MAP permit 10
R2 (config-route-map)# set community 100:100
R2 (config)# router bgp 200
R2 (config-router)# neighbor 24.1.1.4 send-community
R2 (config-router)# aggregate-address 10.1.0.0 255.255.252.0 summary-only as-set attribute-map ATT_MAP
R2 (config-router)# exit

R4 (config)#ip community-list 1 permit 100:100
R4 (config)#route-map IN permit 10
R4(config-route-map)#match community 1

R4(config)# router bgp 400
R4(config-router)# neigbhbor 24.1.1.2 route-map IN in 
Still, R4 is not receiving the aggregate route of 10.1.0.0/22

R4(config)#do sh ip bgp
BGP table version is 15, local router ID is 10.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
*> 10.1.0.0/24 0.0.0.0 0 32768 i
*> 10.1.1.0/24 0.0.0.0 0 32768 i
*> 13.1.1.0/24 24.1.1.2 0 0 200 i
*> 23.1.1.0/24 24.1.1.2 0 200 300 i
* 24.1.1.0/24 24.1.1.2 0 0 200 i
*> 0.0.0.0 0 32768 i
R4(config)#do sh ip bgp 10.1.0.0/22
% Network not in table

I am not sure what caused this. But I guess I need more time to grasp how community information should be exchanged, and what really limits the aggregate route being sent back to R4.

[Harold Ritter]

Hi @woogx ,

> The goal is to announce the aggregate route from R2 to R1 and R4. Since R3 and R4 are

> rejecting the routes after the aggregation (please see the pre-check result)

We can see the aggregate (10.1.0.0/22) on R4 and not on R3 in the post implementation verification. So the solution provided by @David Ruess is the right one and complies with the requirements.

Regards,

[woogx]

Thanks, Harold. Just out of curiosity, other than David's solution, is there anything else can be done to resolve this? I guess this goes back to the original question, what really caused the block of the aggregate route on R3 and R4 in the first place (routing loops prevention perhaps?). Most of the example on the Internet shows quite a lot pushing and manipute the aggregate route towards R1 direction instead of going backwards R3 or R4.Hence, much of the confusion by me.

[Harold Ritter]

Hi @woogx ,

As per @David Ruess 's previous message.

"In the earlier task we saw how R3 and R4 both reject the aggregate route they receive from R2 because their own AS numbers are listed in the AS_SET segment of the AS_PATH attribute."

Regards,

[MHM Cisco World]

ip bgp-community new-format

add this in routers and try again 

[David Ruess · Accepted solution]

Hello,

With the book you should also have the answer key. Below is the solution for your task:

Task 4
Configure R2 such that only R1 in AS 100 and R4 in AS 400 accept the aggregate. The
other AS(es) in this topology (such as AS 300) should receive the aggregate route, but
they should discard it.
In the earlier task we saw how R3 and R4 both reject the aggregate route they receive from R2 because their
own AS numbers are listed in the AS_SET segment of the AS_PATH attribute. This task requires that both R1
and R4 accept the aggregate route from R2 and inject it in their BGP tables. R3 should, however, receive the
aggregate, but should discard the update.
This can be achieved using an

 advertise-map 

appended to the

aggregate-address

command. When an

aggregate-address

command includes an

advertise-map

the router will only copy attributes from component paths matched by the

advertise-map

Attributes from component paths that are not matched
by the

 advertise-map

are not copied over. In this case, R3 should not accept the path but R1 and R4 should.
If the aggregate path only copied path attribute information from R3’s paths, originating in AS 300, then
only AS 300 will appear in the AS_PATH attribute. This means R3 would block the path and R1 and R4 would
accept the path. The basic process is as follows:
1. R2 will be configured with an as-path

access-list

that permits AS 300
2. R2 will be configured with a

 route-map

that matches the as-path

access-list

3. The

advertisem-map

command appended to the

aggregate-address

command references this

routemap

The result of this configuration is only paths that originated and were advertised to R2 directly from AS 300
will have their attributes copied to the new aggregate path. This means only AS 300’s ASN will be added to
the AS_PATH attribute, leading to the desired result.
The following implements the above:

On R2:
R2(config)#ip as-path access-list 1 permit ^300$
R2(config)#route-map Task4 permit 10
R2(config-route-map)#match as-path 1
R2(config-route-map)#router bgp 200
R2(config-router)#aggregate-address 10.1.0.0 255.255.252.0 as-set summary-only
attribute-map TST advertise-map Task4

-David

[woogx]

Thanks, David. I believe I have got a redacted version of the book. It didn't have any answers or the initial config. I just thought to try to build everything from scratch to see how far I can go with the Youtube and Internet. Admittedly, I think I have reached my limit, which requires a bit of help and guidance externally. Anyway, just placed an order online to acquire the actual book to help me speed up the study. Also, I really appreciate the guidance provided, the explanation did point out thatI did not quite catch everything in the earlier task (Hence, the importance of a proper book，no more rogue study.). Anyway, I will lab it up later to explore your answers. Again, thank you.

[David Ruess]

No problem.

Glad I was able to assist. The book is a great resource (as I have it myself).

If the post helped you with your issue, please mark this post as solved so it can help others in the community as well.

Thank you

-David

[woogx]

Hi David,

One last question though, can I assume that the reason for both R3 and R4 to reject aggregate is to prevent the routing loop? If that is the case, how can the implementation of task 4 prevent it?

[MHM Cisco World]

that far far away from your original post, 
the ANSWER  from Mr. @David Ruess  is prevent the route learn from R3 to advertise, (I will run lab to be so sure), it not prevent the aggregate to send to R3. 
try my way and see result.