cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1837
Views
10
Helpful
10
Replies

BGP Sending Community Value

rakeshvelagala
Level 3
Level 3

Hi All,

Just very simple config as below.

For the command "aggregate-address 153.153.153.0 255.255.255.0 attribute-map ATTR_SET", the network is loopback and is also  /24. I just want to send the community "no-export" using the aggregate command. When I check the sh ip bgp for this route, the community value is not shown. 

Instead of applying the ATTR_SET on the aggregate-command, if I use it on neighbor 10.1.1.1 route-map ATTR_SET, then I can see it is advertising the community value correctly. Can someone please advise what is wrong with the first way using aggregate?

r1(10.1.1.1) ----- (10.1.1.2)r2

R1#sh run | s router
router bgp 1
bgp log-neighbor-changes
neighbor 10.1.1.2 remote-as 2

R2#sh run | s router

router bgp 2
bgp log-neighbor-changes
network 153.153.153.0 mask 255.255.255.0
aggregate-address 153.153.153.0 255.255.255.0 attribute-map ATTR_SET
neighbor 10.1.1.1 remote-as 1

neighbor 10.1.1.1 send-community

R2#sh run int lo 1
Building configuration...

Current configuration : 69 bytes
!
interface Loopback1
ip address 153.153.153.153 255.255.255.0

R2#sh route-map

route-map ATTR_SET, permit, sequence 10
Match clauses:
Set clauses:
community no-export
Policy routing matches: 0 packets, 0 bytes

R1#sh ip bgp 153.153.153.0/24

BGP routing table entry for 153.153.153.0/24, version 4
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
2
10.1.1.2 from 10.1.1.2 (153.154.154.153)
Origin IGP, metric 0, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0

Thanks

10 Replies 10

Philip D'Ath
VIP Alumni
VIP Alumni

This is a little outside my knowledge, but I believe the "no-export" community attribute is set in inbound routes (aka routes you are learning) - you don't set it outbound (aka routes you are sending to an external AS).

And the whole point of it is to prevent your AS sending routes learned from another AS outside of your own AS.

Sakthi Malli
Cisco Employee
Cisco Employee

Can you try remove/re-add "aggregate-address" statement or hard-reset BGP session to see if it helps

Thanks

Hi Samallis,

Still the same. Thanks

The reason is conceptual. When you use no-export, it means you are telling your neighbor to stop advertising some routes so you need to add no export to the neighbor.

With attribute-map you can only modify properties of aggregated routes advertising to neighbors.

Masoud

Hi Masuod,

aggregate-address 153.153.153.0 255.255.255.0 attribute-map ATTR_SET

Is this not advertising to the neighbors? Please advise

Hello Rakesh,

Masoud is right, it is a conceptual question if you set no-export BGP community on an aggregate address you should not be able  to advertise it to an eBGP neighbor like in your example, because no-export means that the prefix is limited within your own AS. But this is not true as your tests show, the prefix is advertised to R1, but it looks like it is missing the BGP community attribute.

Look at the output you have provided in first post:

R1#sh ip bgp 153.153.153.0/24

BGP routing table entry for 153.153.153.0/24, version 4
Paths: (1 available, best #1, table default)
>>>>>Not advertised to any peer
Refresh Epoch 1
2
10.1.1.2 from 10.1.1.2 (153.154.154.153)
Origin IGP, metric 0, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0

Hope to help

Giuseppe

Edit: R1 is the receiving router and it receives the prefix but does not show the BGP community no-export, now I see the point.

I would have expected R1 to not receive the prefix at all, but I'm wrong.

Hi Giuseppe,

Many thanks for your reply. 

So if we use the route-map to the neighbor, then it will be advertised first to the neighbor and that neighbor will not export to others? Is my understanding right?

But if we use on the aggregate, it will not even advertise as the condition is checked first? Please advise.

Thanks

 

Hello Rakesh,

I have just modified my previous post, because I hadn't understood that R1 is the receiving router in your case.

I'm sorry I have given you misleading information.

The setting of BGP community no-export at the aggregate-address level looks like to have no effect on the propagation of the route to the eBGP neighbor.

I agree that the BGP community is missing in the output of R1 as you show.

Edit:

no-export means do not advertise to another BGP AS the prefix and causes this behaviour on the receiving side. The receiving router can advertise the prefix to other iBGP peers in the same AS but not to other eBGP peers.

Hope to help

Giuseppe

Hi Giuseppe,

No problem. Thanks for your reply.

To start with, I am not sure if the aggregate command has any effect. The route in the BGP table is already /24 and I am not aggregating anything. I just used the aggregate so that I can send the community value. I will check and post here if I find anything.

Thanks

Hello Rakesh,

>> To start with, I am not sure if the aggregate command has any effect. The route in the BGP table is already /24 and I am not aggregating anything. I just used the aggregate so that I can send the community value

This may explain what you see: it is component route /24 without any BGP community attached that is the only one advertised to the eBGP neighbor R1.

The aggregate-address is not advertised at all (as expected for the no-export set value).

This would explain why on R1 you see the route without the BGP community.

Hint: the BGP network command supports the calling of a route-map as an option.

You can try to use the network command with the route-map option with the same route-map used in the aggregated-address command.

Hope to help

Giuseppe

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card