BGP basics: BGP communities propagation

I’ve got this question from Pete:

Which community will be sent if only "neighbor {ip-address} send-community" is configured?

Quick answer: only the standard BGP communities are propagated.

More details

The neighbor send-community enables the community propagation. Without this option, no BGP communities will be sent to the BGP neighbor, even if they are attached to entries in the local BGP table. After the neighbor send-community has been configured, the router will start propagating the communities attached to BGP entries in its BGP table to the neighbor.

BGP has two community attributes: the standard BGP communities (defined in RFC 1997) and extended BGP communities (defined in RFC 4360). You can control which communities are sent to a BGP neighbor with the (very obvious) standard, extended or both options of the neighbor send-community router configuration command. If you use neighbor send-community with no extra options, only the standard BGP communities are propagated to preserve backward compatibility.

This article is part of You've asked for it series.

9 comments:

  1. says under vpnv4 family, if configured send-community both, does the PE routers sent standard community as well?

    ReplyDelete
  2. I tried to redistribute eigrp and bgp into each other. After redistribution both eigrp and bgp routers are getting routes of each other but bgp router cannot ping any ip from eigrp router at same time eigrp router can ping any ip from bgp router.

    Please find the attached configuration for the same. Could anyone tell me what is the problem?

    Router A

    router eigrp 1
    network 172.16.252.32 0.0.0.31
    network 200.200.200.0 0.0.0.3
    no auto-summary

    Router B

    router eigrp 1
    redistribute bgp 2 route-map check
    network 116.214.28.0 0.0.0.255
    network 200.200.200.0 0.0.0.3
    no auto-summary

    router bgp 2
    no synchronization
    bgp log-neighbor-changes
    bgp redistribute-internal
    network 116.214.28.0 mask 255.255.255.0
    network 200.200.200.0 mask 255.255.255.252
    redistribute eigrp 1
    neighbor 17.17.17.2 remote-as 2
    neighbor 17.17.17.2 update-source Loopback200
    no auto-summary

    route-map check permit 10
    match ip address prefix-list bgp-routes
    set metric 100000 10 255 1 1500

    ip prefix-list bgp-routes seq 5 permit 0.0.0.0/0
    ip prefix-list bgp-routes seq 6 permit 172.16.46.224/27
    ip prefix-list bgp-routes seq 7 permit 172.16.252.32/27



    Router C


    router bgp 2
    no synchronization
    bgp log-neighbor-changes
    network 172.16.46.224 mask 255.255.255.224
    neighbor 17.17.17.1 remote-as 2
    neighbor 17.17.17.1 update-source Loopback1
    no auto-summary


    Network Next Hop Metric LocPrf Weight Path
    *>i116.214.28.0/24 17.17.17.1 0 100 0 i
    *> 172.16.46.224/27 0.0.0.0 0 32768 i
    *>i172.16.252.32/27 200.200.200.1 297246976 100 0 ?
    *>i200.200.200.0/30 17.17.17.1 0 100 0 i



    C#ping 17.17.17.1

    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 17.17.17.1, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 16/32/92 ms

    C#ping 200.200.200.1

    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 200.200.200.1, timeout is 2 seconds:
    .....
    Success rate is 0 percent (0/5)

    ReplyDelete
  3. This bothers me a lot.

    Say I decided to use communities and, god forbid, stumbled upon some cisco routers on my way in some transit AS, those routers must be configured to relay community attributes. Otherwise I'm busted.

    Doesn't look like following RFC logic at all, if you ask me.


    cheers

    ReplyDelete
  4. Communities were never intended to have global reach (and most of them have local significance anyway), so it's not necessarily a bad idea that they're filtered by default.

    BTW, the RFC logic is not violated. Communities are optional transitive attributes, which means you should pass them on IF YOU DON'T KNOW WHAT TO DO WITH THEM. If you do, you're free to do whatever you wish.

    ReplyDelete
  5. Hello,

    I noticed I can insert more than one community value per line in a route-map:

    route-map stanga permit 10
    match ip address prefix-list six
    set community 100:70 100:1300

    The two values are reaching the other neighbor:

    10.0.20.2 from 10.0.20.2 (10.0.24.1)
    Origin IGP, metric 0, localpref 130, valid, external, best
    Community: 100:70 100:1300

    But only one action is performed on the prefix, although route-map should modify both MED and LOCAL PREF:

    ip bgp-community new-format
    ip community-list 1 permit 100:1300
    ip community-list 2 permit 100:1250
    ip community-list 3 permit 100:80
    ip community-list 4 permit 100:70
    !
    !
    route-map Clienti permit 10
    match community 1
    set local-preference 130
    !
    route-map Clienti permit 20
    match community 2
    set local-preference 125
    !
    route-map Clienti permit 30
    match community 3
    set metric 80
    !
    route-map Clienti permit 40
    match community 4
    set metric 70

    Can you tell me why MED is not modified?

    ReplyDelete
  6. Ivan Pepelnjak30 March, 2011 14:23

    Route-map processing stops after the first match. You need "route-map continue" functionality.

    ReplyDelete
  7. What are the equivalent commands in XR for Send-community both and send-community extended.

    Does these commands are required only for EBGP peers or they also require for iBGP peers.

    Please explain the above condition for both IOS and IOS XR

    ReplyDelete
    Replies
    1. On Cisco IOS (classic) you have to configure community propagation on both IBGP and EBGP peers (if that's what you want to do). I'm not an IOS XR person, so you'll have to ask that question somewhere else.

      Delete
  8. Thanks for your properly response, I have found it, as you said for IOS we must configure for both IBGP and EBGP neighbors, Whereas In IOS XR, by default it propagates to IBGP neighbors and we must configure for EBGP neighbors.

    Thanks once again.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.