BGP Community No Advertise

Hello,

Just a question (haven’t tried the topology yet):

I can see in R2 configuration that next-hop-self is used for R4 neighbor.

The “show ip bgp | include 1.1.1.1” on R4 shows R1 as next-hop (not R2) and not in the routing table. In R3 case R2 is seen as next-hop (default behavior for eBGP).

The output of “show ip bgp | include 1.1.1.1” on R4 should include R2 (192.168.24.2) as next-hop and the > mark.

Thank you,
Stefanita

Hi Stefanita,

You are correct, it should show 192.168.24.2 (the IP address of R2) because of next-hop self. I just fixed this and also added the complete configuration files.

Thanks for letting us know!

Rene

1 Like

Hi

If “BGP router will use and store the prefix in its BGP table but it won’t advertise the prefix to any other neighbors” so what is the point of advertising a prefix.

Hello Card

The point of the No Advertise community is that you can advertise a prefix to you iBGP neighbor, but you can instruct that neighbor not to advertise it to any other neighbors downstream. The result is that R1’s neighbor (R2) learns of the prefix but R3 and R4 don’t.

If the prefix was not advertised in the first place, R2 would not know the prefix either. This is a different result than when the No Advertise option is used.

I hope this has been helpful!

Laz

1 Like

Thanks

This website is REALLY REALLY good to understand basic to advance level!

1 Like

@ReneMolenaar @lagapidis @andrew
I fully understood how this community work ( my nei just rcv the prefix and not adv it to any bgp i or e)
but in real life where and when i need this community type?
please give me a real example.

BR,

Hello Ali

That’s a good question. The only reason I can think of to employ this community is to keep BGP tables small by eliminating the need for internal routers of other ASes to maintain BGP prefixes that are unnecessary. By using this community, you can limit the prefixes that neighboring ASes need to maintain in the BGP tables, and thus you can make BGP tables more manageable.

Beyond that, you may also want to disallow hosts in a neighboring AS from accessing specific addresses in your own AS. Say you have a lab on a LAN in your enterprise that you want to keep highly secure, and you don’t want to share routing information with neighboring BGP ASes in your organization. You can limit the extent to which these prefixes are propagated throughout the network.

I hope this has been helpful!

Laz

Thx for your reply
But why other As’s advertise their transit prefixes to me? (Prefix between two routers to establish ibgp)
As i know they adv just what they need, in another hand they will filter it using prefix list and from my side also.
I didn’t get the advantage of this community type.
@lagapidis

Hello Ali

That depends upon how that other AS is configured. Remember that the No Advertise community plays a role in outgoing BGP updates. It does not affect the way your neighboring AS will advertise its prefixes to you. That will have to be configured within that AS itself for their outgoing (from the point of view of the other AS) BGP advertisements.

The no advertise community is a way to tell your neighboring AS about a prefix you have, but not to advertise it any further. You may simply not want other ASes to know about your prefixes, except for that one eBGP router in the neighboring AS.

Yes, you can achieve similar results with prefix lists, but only if you have access to that neighboring eBGP router in the next AS. I guess it’s used for very specific purposes that are not always readily perceivable.

I hope this has been helpful!

Laz

Hi
But rene in this lesson have a note says u can configure it with in direction from R2 also”
So can i apply it ?

Also if i used it with OUT direction, why i am care about minimizing my nei routing table? he has to do it from his side by using any technic that’s he want.

If i don’t want my nei to advertise my prefix to another AS’s, i can use NO-Export community, Why i am care about my nei ibgp routers?

Hello Ali

Yes you are correct, you can apply it in an inbound direction, thus limiting the advertising of the neighboring prefixes into your AS and beyond.

If the neighboring AS belongs to someone else, of course they are responsible for minimizing their routing tables. However, there are cases where you have to consider this. For example, AS owners have contracts that they agree upon, and they require each other to configure their ASes in specific ways. If you are obligated to do so, then you would indeed configure your AS as required by the other AS owner. Another case would be if the neighboring AS actually belongs to you, then you are responsible for that and you can choose how to minimize the routing table sizes. One way would be to use the no advertising community in an outward direction.

Yes, you can use the no-export community, but that would cause the eBGP router in the neighboring AS to share those routes with the iBGP peers in that AS. If you want that, then it’s OK. If not, then you must use the no advertise community.

I hope this has been helpful!

Laz

Hello, everyone!

If I do something random like add 3 well-known community values to a BGP advertisement


Which one of them will… be used? :smile:

One says not to advertise the prefix at all, the other one says to only advertise it to iBGP neighbors and the last one includes confederations :smile:

That’s all. thank you.

Kind regards,
David

Hello David

In BGP, when multiple well-known communities are applied to a single route, they all can have their effects simultaneously. The BGP protocol does not prioritize one community over another. Instead, it applies all the community values to the route. When you have seemingly contradictory communities, then the rule is that the most restrictive one is applied.

In your case, you have three communities:

NO_EXPORT: This community instructs the router not to advertise this route to eBGP peers.
NO_ADVERTISE: This community instructs the router not to advertise this route to any peer, neither iBGP nor eBGP.
NO_EXPORT_SUBCONFED: This community instructs the router not to advertise this route to eBGP peers or any peers outside the local confederation.

So, if you apply all these three communities to a route, the NO_ADVERTISE will take effect, which is the most restrictive one. This means the route will not be advertised to any peers, whether iBGP, eBGP, or confederation peers.

I hope this has been helpful!

Laz