Understanding communities

Can someone tell me this about the community-list below. I'm just interested to know if it works similar to an ACL, where it exits the community once it finds the first match? So for the example below. If the community we were checking agianst this community-list was 200:4, would this be matched? I think it wouldn't as it needs to match all 3 of the communities.


Also what about if it was for community 200:2? Does it exist the community-list here, or does it mean all of the community values below must also match?


R2#sh ip community-list

Community standard list 1

     deny 200:1

     permit 200:2

     permit 200:3

     permit 200:4 200:5 200:6


  • Hi Martinl and All,

    Here with yet another explanation on how Standard Community Lists work:

    A global knowledge BGP course slide says that, for standard community lists, they work like ACLs!

    With "internet" as a substitute for ACL's "any".  <rb:  Implied deny any at end of list.>

    I'm going with ACL behavior; only for standard community lists.  

    Using just permit statements (no denies), the overall behavior of "OR" and "AND" appears to apply.  So, that statement is true when using permit statements exclusively.  Not to say that it is not also true when using deny statements.  Just that I don't follow the logic as I'm not a boolean guru.

    Community list types are not the same animal.  Expanded community lists use regexp.

  • Hi All,

    Here with results from quick study using IOS 12.4 and GNS3




  • I don't understand something. In trial 3, on the last line it says 

    ip community-list 3 permit 100:1 200:1 300:1, but your prefix was denied using these communities??? Why?


    I also don't understand your results from trial 2 at all.

  • Hi SG and All,

    Sorry about explanation.  After looking at my list of rules, appears to be more of a 

    quick-recall-list rather than an explanation.


    "ip community-list 3 permit 100:1 200:1 300:1, but your prefix was denied 

    using these communities??? Why?"


    Trial 3

    BGP router receives with a community string.

    I look at standard communities as an unordered set of community numbers; {x,y,z} is same as {y,z,x}  community set {100:1, 200:1, 300:1}

    Standard community-list have same unordered set structure, where each ACL entry has 

    its own set.

    1 ip community-list 3 deny 100:1  |

    2 ip community-list 3 permit 200:1 |

    3 ip community-list 3 permit 300:1 |

    4 ip community-list 3 permit 400:1 500:1 600:1 |

    5 ip community-list 3 permit 100:1 200:1 300:1 V

    <6 ip community-list 3 deny Internet> -- implied deny any


    Line 1 {100:1}

    Line 2 {200:1}

    Line 3 {300:1}

    Line 4 {400:1, 500:1, 600:1}

    Line 5 {100:1, 200:1, 300:1} 


    Top down, first match.  

    Using top ACL entry set, search update's set.

    For a match:  update's set must contain all the numbers contained in ACL's set

    IF match


    ELSE go to next line of community list and perform same comparsion.

    bottom ACL entry:  deny Internet -- matches all previously unmatched community strings

    Wheh! {100:1, 200:1, 300:1} is compared against "1 ip community-list 3 deny 100:1";

    {100:1} is contained in {100:1, 200:1, 300:1}.  

    It is a match, and action is deny.

    Trial 2

    ip community-list 2 deny 300:1

    ip community-list 2 permit internet

    ip community-list 2 deny 100:1 200:1

  {100:1} {200:1} {200:1, 100:1}

    Note:  "internet" community is a null set community --no elements

    BGP Update      Community-List    Result                       Action

    {100:1}           {300:1}                no match

                             internet                 match                       permit END


    {200:1}           {300:1}                no match

                             internet                 match                       permit END


    {200:1, 100:1}    {300:1}           no match

                                  internet            match                       permit END


  • Hi All,

    More concise description would be  

    community lists follow ACL top-down behavior, where a match occurs whenever a community list entry is entirely contained within an update's community list.

    But there is more to it than above.  Behavior is dependent on how the list is called within a route map.

    1) What I've said to this point about Standard Community Lists looks to be true only when called by 

    match community <list name|number>


    2) Behaves differently when called by a set command:

    set comm-list <list name/number> delete

    Where it appears to examine the entire list and to not follow "first match, then quit rule."


Sign In or Register to comment.