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.

 

[woogx]

I will try yours tomorrow morning. I only got limited time everyday for the study. I am sure your solution will work as well. It is just that the task itself just wanted R2 to be configured only. I only have a redacted version of the book, hence, I have to make quite a bit of assumption. Hopefully, I can have this book purchase sorted out with CiscoPress tomorrow. The payment didn't go through, unfortunately. 

[David Ruess]

As far as the intention I wouldn't say its so much as to prevent a loop. Its just the author wanted to present a unique problem and as a CCIE "in training" when you are presented with a problem that has restrictions or multiple steps and involve multiple devices you have to use critical thinking to figure out a solution to the problem. I have not labbed the BGP part of this book unfortunately so I am not as well versed.

@MHM Cisco World I pulled this answer from the book the OP referenced so this is the EXACT answer to the problem according to the book. While there may be other ways to solve it the author wants it done a certain way. I pulled the answer from a screenshot of the lab manual being used by the OP.

-David

[MHM Cisco World]

I read all reply and now let start deep dive, and I explain why this solution is far away (may be I am better than the writer of Book LoL... )
the aggregate is method BGP use to summary some prefixs into one large prefix prefix and advertise to other routers with and without summary the original prefix before aggregate it (no-summary keyword). 
NOW 
R2 receives prefix from 
R3 10.1.2.0/24 
R3 10.1.3.0/24 
R4 10.1.1.0/24 
R4 10.1.0.0/24 

and we config aggregate 10.1.0.0/22 this large prefix will make R2 aggregate the four into one large prefix but Here the point 
the AS-PATH for four prefix is different, so the R2 can not add AS-PATH correctly to aggregate prefix. 
what that meaning 
R2 can not make AS-PATH of aggregate be 200 300 or 200 300 or 200 300 400 
what solution ??
solution what @David Ruess  mention, using as-path list and only the prefix with 300 will aggregate and  hence the R2 can advertise now large aggregate prefix with 200 300

why aggregate appear in R4 not in R3 
this simply because we in advertise-map accept only  as-path 300 and hence R2 aggregate the prefix from R3  and send to R4 and not aggregate and not advertise the prefix from R4 to R3. 

there is no loop prevent there is logic why prefix appear in R4 with as-path 300. 

we can make so sure by change the

advertise-map

to permit ^400$ and see result which must be the prefix appear in R3 with as-path 200 400 
thanks 
MHM 

[Harold Ritter]

Hi @MHM Cisco World ,

This is a CCIE lab preparation scenario. What they want in this case is to test your deep knowledge on each and every feature. They normally give you clues on what exact feature or technique they want you to use. In this specific scenario, they want to test you on the as-set functionality and how it can be used to exclude the aggregate from certain AS.

Of course in a real life scenario you might want to use some other features or techniques to accomplish what needs to be accomplished, but if you walk into the CCIE lab ignoring the clues they give you for a specific scenario, chances are you are not going to walk away with the coveted certification.

Regards,

[MHM Cisco World]

Yes  @Harold Ritter 
you  are totally right but I want from him to get idea about using as-path with as-set with aggregate.
thanks a lot for your Support  

[MHM Cisco World]

R2 receives prefix from 
R3 10.1.2.0/24 AS-Path 300
R3 10.1.3.0/24 AS-Path 300
R4 10.1.1.0/24 AS-Path 400
R4 10.1.0.0/24 AS-Path 400

R2 will advertise 10.1.0.0/22 AS-PATH as I mention before can not add to aggregate so  AS-PATH is none (before it advertise and add 200 to AS-Path)
R2 will use AS-SET, meaning list all AS-PATH from all AS-PATH the prefix receive 

here R3 and R4 can not accept the aggregate because it AS-SET list the AS of own and refuse it, 
how can we make it accept ? try remove AS-SET from aggregate command this make both R3 and R4 accept the aggregate large prefix. 

and for more about using AS-PATH list, I hope I explain it above. 
thanks 
MHM 

note:- try remove summary-only to see R4 prefix in R3. 

[woogx]

@MHM Cisco World Thanks for the help. You are right that I do not fully comprehend how attributes work entirely. Like Harold said, the lab is designed with a specific purpose. Given my insufficient knowledge on the technology itself, it does take time. So right now, instead of just focusing on this part, I am fast-forwarding to the next chapter on applying ACL

prefix-list route-map

etc.. to get a better idea. Hopefully, this may help me understand this a little better soon.

@Harold Ritter Thanks for clearing out some of the concept behind.

[MHM Cisco World]

You are so so so welcome friend anytime 

Have a nice day 

[woogx]

@MHM Cisco World 

This is very interesting, and certainly a great journey. Although I haven't got your solution worked out yet, I think I understand what you try to explain to me.

As suggested by you, when I use aggregate-address ... summary-only, surprisingly, I can see 10.1.0.0/22 on both R3 and R4 bgp table. But if I put as-set in the previous command, 10.1.0.0/22 disappeared from bgp routing table. Initially, I thought as-set will only track the aggregate route to its origin instead of just it as the aggregator. But after that, coupled with the following from Cisco website and your explanation

"In any closed network, this aggregate information propagates through BGP and back to one of the ASs that the as-set lists. This propagation creates the possibility of a loop. The loop detection behavior of BGP notes its own AS number in the as-set of the aggregate update and drops the aggregate. This action prevents a loop."

I arrived that as-set actually made R3 and R4 reject the aggregate route. It acts like loop prevention guard in some senses (at least to me, like boolean control element in coding).

Going back to your original solution with slight modifications to suit our task.

R2(config)#ip bgp-community new-format

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 23.1.1.3 send-community

R2 (config-router)# aggregate-address 10.1.0.0 255.255.252.0 summary-only attribute-map ATT_MAP

!--- I intentionally left out as-set so that I can see the 10.1.0.0/22 disappear off R3, whereas it will still appear on R4.




R3(config)#ip bgp-community new-format

R3 (config)#ip community-list 1 permit 100:100

R3 (config)#route-map IN deny 10

R3 (config-route-map)#match community 1

R3 (config)#route-map IN permit 20

R3 (config)# router bgp 300

R3 (config-router)# neigbhbor 23.1.1.2 route-map IN in




This will still have 10.1.0.0/22 on R1, R3 and R4 (Output below).




R3#sh ip bgp 10.1.0.0/22

BGP routing table entry for 10.1.0.0/22, version 9

Paths: (1 available, best #1, table default)

Not advertised to any peer

Refresh Epoch 3

200, (aggregated by 200 24.1.1.2)

23.1.1.2 from 23.1.1.2 (24.1.1.2)

Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate, best

Community: 100:100

rx pathid: 0, tx pathid: 0x0




R3#sh ip bgp 13.1.1.0/24

BGP routing table entry for 13.1.1.0/24, version 4

Paths: (1 available, best #1, table default)

Not advertised to any peer

Refresh Epoch 3

200

23.1.1.2 from 23.1.1.2 (24.1.1.2)

Origin IGP, metric 0, localpref 100, valid, external, best

rx pathid: 0, tx pathid: 0x0




R4#sh ip bgp 10.1.0.0/22

BGP routing table entry for 10.1.0.0/22, version 9

Paths: (1 available, best #1, table default)

Not advertised to any peer

Refresh Epoch 2

200, (aggregated by 200 24.1.1.2)

24.1.1.2 from 24.1.1.2 (24.1.1.2)

Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate, best

rx pathid: 0, tx pathid: 0x0

Then I added as-set to the

aggregate-address 

command in R2, 10.1.0.0/22 disappeared off R3 and R4 -> still no good.

So I started to interpret your config. Initially, I thought you were trying to send all prefix on R2 to R3 with community tag. But with that, it lacks a control element like ACL or ip prefix list to deny a specific route of 10.1.0.0/22, which I think is very weird. Then after I compared the ip bgp output from both 10.1.0.0/22 and 13.1.1.0/24 from AS 200. I quickly realized that the community tag only appled to 10.1.0.0/22 because the

attribute-map/route-map

applied on the aggregate-address. Therefore, none other prefix from R2 will be sent with a community tag except 10.1.0.0/22.

With R3, the config applies a

route-map

on the neighborship between R2 and R3 denying only 10.1.0.0/22 prefix. So ideally I cannot see anything wrong.

Any chance you point me a direction? Thanks.

[MHM Cisco World]

How can I see the AS-SET that the router add to prefix 
in R1 which do the aggregation
do

show ip bgp 10.0.0.0 255.0.0.0 

in may lab I will use this prefix as aggregate
{200,300}  

[MHM Cisco World]

the aggregate with AS-SET (no summary-only)
this make both R2 and R3 refuse the aggregate prefix  

[MHM Cisco World]

aggregate with no-summary (no as-set)
the aggregate ONLY advertise from R1 to R2 and R3 and any prefix that within the aggregate prefix in R1 will not advertise to R2 and R3

[MHM Cisco World]

the aggregate with summary-only with as-set 
this will make R2 and R3 refuse the aggregate prefix 
this will R1 will not advertise any prefix that within the aggregate prefix (i.e. the prefix that is seed of aggregate prefix) 

[woogx]

@MHM Cisco World I think your intention is to send 10.1.0.0/22 to R3 with summary-only and as-set, whereas to send 10.1.0.0/22 to R4 with only summary-only by applying control mechanism of the

route-map

If that is the case, then I need to find out a way to use aggregate-address function to send this to different peers. Let me think of this a little bit more tomorrow. My brain is half fried.

[MHM Cisco World]

Until now I dont know method can use to advertise aggregate to specific neighbor'

But you can use way I mention above'

Add community to aggregate and use summary-only 

Then use this community value to deny aggregate in any router recieve it.