COMMUNITIES/Tags and route-maps are killing me - Help please

I am getting my butt kicked by route-maps and communities. This is from CCIE-SP Lab 4. Would anybody who has an understanding of Communities/tags and route-maps please explain to me what is this config doing. The config is going on a router that has an EBGP peering with another, but really I just want to understand What exactly is this config accomplishing. Please help...I'm hurting on this one.

 

router bgp 1000
 address-family ipv4
  neighbor 10.0.35.3 route-map RFC_1998 in 
  neighbor 10.0.0.2  send-community
  neighbor 10.0.35.3 send-community 
 exit-address-family
!
ip bgp-community new-format
!
ip community-list standard 1000:80 permit 1000:80
ip community-list standard 1000:90 permit 1000:90
ip community-list standard 1000:110 permit 1000:110
ip community-list standard 1000:120 permit 1000:120
!
route-map RFC_1998 permit 10
 match community 1000:80
 set local-preference 80
route-map RFC_1998 permit 20 
 match community 1000:90
 set local-preference 90 
route-map RFC_1998 permit 30
 match community 1000:110
 set local-preference 110 
route-map RFC_1998 permit 40
 match community 1000:120
 set local-preference 120
route-map RFC_1998 permit 1000

Regards,


Jesse

Comments

  • Hi,

    As BGP prefixes are received INBOUND, different local-preference values are assigned . Community values are one of the many attributes prefixes can have so basically the router is saying that, for example, all prefixes received inbound from this specific eBGP neighbor that have community value of 1000:80, set local-preference to 80, and so on. If the prefixes have no community value assigned or a different value than the ones specified in the route-map, then do nothing, treat them as default - local-preference 100 (if this hasn't been globally changed in the BGP process).

     

     

  • Let take a stab at it.

    It is allowing a set of communities inbound and at same time assigning different local preference as they come.

    For instance the first list called 1000:80 (call it first-list) matches communities with "1000:80" AND setting this list to local-presence to 80. The confusion is with list name which is also the actual community list. 

    Hope it helps,

    Sincerely,

    TF

    Sent from my iPhone

    On Jul 27, 2014, at 12:47 AM, "[email protected]" <[email protected]> wrote:

    I am getting my butt kicked by route-maps and communities. This is from CCIE-SP Lab 4. Would anybody who has an understanding of Communities/tags and route-maps please explain to me what is this config doing. The config is going on a router that has an EBGP peering with another, but really I just want to understand What exactly is this config accomplishing. Please help...I'm hurting on this one.

     

    router bgp 1000
     address-family ipv4
      neighbor 10.0.35.3 route-map RFC_1998 in 
      neighbor 10.0.0.2  send-community
      neighbor 10.0.35.3 send-community 
     exit-address-family
    !
    ip bgp-community new-format
    !
    ip community-list standard 1000:80 permit 1000:80
    ip community-list standard 1000:90 permit 1000:90
    ip community-list standard 1000:110 permit 1000:110
    ip community-list standard 1000:120 permit 1000:120
    !
    route-map RFC_1998 permit 10
     match community 1000:80
     set local-preference 80
    route-map RFC_1998 permit 20 
     match community 1000:90
     set local-preference 90 
    route-map RFC_1998 permit 30
     match community 1000:110
     set local-preference 110 
    route-map RFC_1998 permit 40
     match community 1000:120
     set local-preference 120
    route-map RFC_1998 permit 1000
    

    Regards,


    Jesse



    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx
  • Hello, thanks for responding. So for the config the changes are occuring only to the internal routes before being advertised to it's EBGP neighbors?


    R5 Config:
    router bgp 1000
     address-family ipv4
      neighbor 10.0.35.3 route-map RFC_1998 in 
      neighbor 10.0.0.2  send-community
      neighbor 10.0.35.3 send-community 
     exit-address-family
    !
    ip bgp-community new-format
    !
    ip community-list standard 1000:80 permit 1000:80
    ip community-list standard 1000:90 permit 1000:90
    ip community-list standard 1000:110 permit 1000:110
    ip community-list standard 1000:120 permit 1000:120
    !
    route-map RFC_1998 permit 10
     match community 1000:80
     set local-preference 80
    route-map RFC_1998 permit 20 
     match community 1000:90
     set local-preference 90 
    route-map RFC_1998 permit 30
     match community 1000:110
     set local-preference 110 
    route-map RFC_1998 permit 40
     match community 1000:120
     set local-preference 120
    route-map RFC_1998 permit 1000
    
  • JoeMJoeM ✭✭✭

    Hello, thanks for responding. So for the config the changes are occuring only to the internal routes before being advertised to it's EBGP neighbors?

    Something important.   Local Preference is only valid for the "local" AS.  It can set the local-preference for prefixes received from an eBGP  neighbor.  But, it would not be advertised to an eBGP neighbor.  

    But yes, it would change the local-preference for the given prefixes (according to matches) from  10.0.35.3, and then pass it on to any other neighbors in the same AS.


  • No, it's the
    other way around ... As prefixes are received INBOUND from its eBGP neighbors,
    that means as prefixes are received not sent, specific local-preference
    attribute is set.

    Let's take a look
    at a shorter config and go through it for a better understanding

     

    Step
    1
    - define
    matching expression for prefixes RECEIVED from out neighbor 10.0.35.3

    ip community-list
    standard 1000:80 permit 1000:80



    Step 2
    - define
    route-map to be used in neighbor peering statement

       

    route-map RFC_1998 permit 10

     match community 1000:80         >>> matches prefixes that
    have a community attribute of 1000:80

     set local-preference 80         >>> prefixes that are matched
    will be set local preference of 80



    route-map RFC_1998 permit 1000  
    >>> all other prefixes not matched by sequence 10 of the route-map
    will be processed without further attributes changes





    Step 3 - apply route-map (and functionality) to neighbor peer address



    router bgp 1000

     address-family ipv4

     
    neighbor 10.0.35.3 route-map RFC_1998 in

     

    Very important to note here is that
    the route-map is applied INBOUND and will affect traffic OUTBOUND, as it leaves
    the AS.

     

     

  • JoeMJoeM ✭✭✭

    I sent this 14 hours ago.  I did not see that anyone had responded yesterday.   

    This sub-forum seems to be moderated a day later.   That kind of makes conversations go in slow-motion.  ;-)

  • Same here Joe. My response was put in "waiting for approval" INE queue that long :(

    Sincerely,

    TF

    Sent from my iPhone

    On Jul 28, 2014, at 12:22 PM, JoeM <[email protected]> wrote:

    I sent this 14 hours ago.  I did not see that anyone had responded yesterday.   

    This sub-forum is always moderated a day later.   That kind of makes conversations go in slow-motion.  ;-)




    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx
  • peetypeety ✭✭✭

    Think of communities as post-it-notes that you stick onto a route announcement.  Each router has its own secret decoder ring for what communities it recognizes and what each them will do.  For many networks, it's a way to get past the rules of transitive/non-transitive attributes.

    In this particular example, you can remotely control the LP of routes in the next ASN.  This is quite useful in a typical provider/customer scenario, as providers usually give customer routes higher LP than their peers or transits (better to get paid by the customer for routing to a prefix than sending it for free to a peer or paying to send it to a transit).  That's all well and good for a multi-homed customer, unless they want to steer their inbound traffic over to one link (for example).  Whatever they announce on the other link is learned by the provider, and even with 22 prepends the provider will still prefer the path because of the higher LP (earlier in the PSA so LP wins).  Slap on a 1000:80 to that provider and bingo the prefix is now given a lower-than-peer LP so the other path wins.

  • I sent this 14 hours ago.  I did not see that anyone had responded yesterday.   

    This sub-forum seems to be moderated a day later.   That kind of makes conversations go in slow-motion.  ;-)

    I've had that issue several times recently over multiple sections of the forums.

  • Hi Jmills - what portion of this exactly is confusing you?  Is it how communities work, how route maps work, or how BGP works?  This is fairly straightforward config, so it should be fairly easy to get things straightened out for you (and there's obviously a lot of really smart people looking to help) but understanding where your knowledge breaks down would probably assist with getting you a solution.

  • Same here, but this did happen on a subsection of the IEOC, I didn't see it happen like ... as a general rule.

     

  • EDIT - well that formatting sucked.  Let's try that again.Actually, to heck with it, here's a breakdown of what I think - a sanity check would probably be worthwhile, but IMO I'm pretty OK at BGP:

    router bgp 1000
     address-family ipv4
      neighbor 10.0.35.3 route-map RFC_1998 in
      neighbor 10.0.0.2  send-community
      neighbor 10.0.35.3 send-community
     exit-address-family

    This section defines the BGP AS as well as some IPv4 neighbors.  Since this section does not include the neighbor ASes it's impossible to tell whether the neighbors are iBGP or eBGP, though.  10.0.35.3 is having a route map "RFC_1998" applied to routes we're learning from them - the "in" keyword


    ip bgp-community new-format


    New format just means the NNN:NNN format - looks nicer in config.


    ip community-list standard 1000:80 permit 1000:80
    ip community-list standard 1000:90 permit 1000:90
    ip community-list standard 1000:110 permit 1000:110
    ip community-list standard 1000:120 permit 1000:120


    The community lists here are named the same as the communities they match, pretty straightforward - 1000 followed by the local pref that the routes are being set to.  Communities are part of a bgp advertisement, just like tags are for IGP routes.  Usually just a way to match certain routes and apply some sort of treatment to those routes.


    route-map RFC_1998 permit 10
     match community 1000:80
     set local-preference 80
    route-map RFC_1998 permit 20
     match community 1000:90
     set local-preference 90
    route-map RFC_1998 permit 30
     match community 1000:110
     set local-preference 110
    route-map RFC_1998 permit 40
     match community 1000:120
     set local-preference 120
    route-map RFC_1998 permit 1000


    Here, finally, the route map is matching the communities referenced above, and setting a local preference for each match.  Local preference is one of the route attributes that BGP uses to make best-path routing decisions with.  When set, it's often the only one.  The final empty "permit 1000" line just permits everything else that's not matched, sort of like a permit all line in an ACL.  This is so we don't filter all non-community tagged routes out of our BGP database.


     

  • I guess the purpose of this config would be useful :-P

     

    This config is fairly standard for a transit provider.  This is setup so that an eBGP neighbor can send you their networks tagged with the specified communities in order to steer traffic.  A transit provider is generally going to want to send traffic to bound for your networks directly to you, but they allow you to change their localpref for your routes via communities.  This is so that traffic can be sent to you via other transit peers rather than directly.  Generally this is to allow you to move traffic off of congested links or to load balance or this kind of stuff.

  • Thanks to everyone for responding. I believe I finally got it. I'm not sure why this particular subject matter was difficult but I believe I'm finally there due to all of your responses. Again, Thanks.

  • The community-list is throwing me right now and when to use it. Why not just match and set the communities directly from the route-map?

  • Hi,

    So think of it like this ... what would be the real use case for this to set and match the community attribute on the same device, as per our example ? I see none and here's how I think of it.

    Imagine that communities are just like tags, used to tag that is to identify prefixes in a more manageable way. The example presented by the original poster is similar to how QoS marking is done. You mark the traffic at the access layer so that, later, you can define how you want to process it, give it preference, limit it, whatever you need to implement in your design.

    In the same way, communities are used in Service Provider environment. So routes have been "coloured" by your provider, tagged, and based on the tag you can take any decision that you like, specifically in this case to determine what will be the exit point to the specific prefix out of your AS.

    So this would be the case if for example you are a "stub" provider, meaning that you don't advertise the prefixes received inbound further. If you do advertise the prefixes further, than yes, maybe you need to set communities for further labelling and further use.

    Also, setting the communities would make sense for prefixes that you advertise, outbound.

    Does this make anymore sense to you ? Let me know if you need further information on the topic.

  • The community-list is throwing me right now and when to use it. Why not just match and set the communities directly from the route-map?

    I don't know why, but unless I'm mistaken, it seems like route maps generally want/need to match other lists rather than directly matching items inside the route map.  ACLs or prefix lists, etc.  Can you just tell a route map "match ip address 10.10.10.10/32" or something like that?  I haven't tried to verify that it can't be done, but I usually reference a prefix list.

  • The community-list is throwing me right now and when to use it. Why not just match and set the communities directly from the route-map?

    I don't know why, but unless I'm mistaken, it seems like route maps generally want/need to match other lists rather than directly matching items inside the route map.  ACLs or prefix lists, etc.  Can you just tell a route map "match ip address 10.10.10.10/32" or something like that?  I haven't tried to verify that it can't be done, but I usually reference a prefix list.

    Hell you're right. I was under the impression you could just match communities directly but this shows otherwise.

    R7(config-route-map)#match community ?

      <1-99>     Community-list number (standard)

      <100-500>  Community-list number (expanded)

      WORD       Community-list name

     

    R7(config-route-map)#match community 

  • peetypeety ✭✭✭

    So think of it like this ... what would be the real use case for this to set and match the community attribute on the same device, as per our example ? I see none and here's how I think of it.

    I don't the original example was matching and setting COMMUNITIES.  It was matching communities and setting local pref.  However, there are plenty of times where I match on one community and set another.  Imagine creating a community that means "set local-pref to lowest-possible in all upstreams": you'll need to translate that community to each provider's standard community for this behavior.

    In the same way, communities are used in Service Provider environment. So routes have been "coloured" by your provider, tagged, and based on the tag you can take any decision that you like, specifically in this case to determine what will be the exit point to the specific prefix out of your AS.

    Yes, except that the tags have to be swapped at the edge, as propagating a route with community 123:456 probably won't get any special behavior in the next network, but translating that to "one prepend" will.

    Real-world example: having learned this from others, I've had fantastic success applying a community to EVERY route in BGP at the point where the route came into BGP (whether thats via redistribution, network statement, or EBGP neighbor) of the form ASN:ABC, where ASN is our ASN, :A is :1 for customer routes, :2 for our routes, and :3 for upstream routes, and BC is a two-digit code to indicate which POP the route came in through.  At upstream connections, it becomes really easy to allow ASN:1.. and ASN:2.. out while denying ASN:3..; now all of a sudden you don't have to edit a prefix list on EVERY upstreamed router when you add a new netblock or customer.  Just allow the netblock on a couple of key core routers, or allow the netblock from your customer, and tag it appropriately, and your routes go everywhere they should.

  • Hi peety,

    As you are a respected member on IEOC community, I'm really process switching through your post right now :). There are some things that I don't understand, so please bear with me.

     

    •  

     

    So think of it like this ... what would be the real use case for this to set and match the community attribute on the same device, as per our example ? I see none and here's how I think of it.

    I don't the original example was matching and setting COMMUNITIES.  It was matching communities and setting local pref.  However, there are plenty of times where I match on one community and set another.  Imagine creating a community that means "set local-pref to lowest-possible in all upstreams": you'll need to translate that community to each provider's standard community for this behavior.

     

    - "as per our example" - I was referring to the fact that the route-map ONLY matches commnunity and sets LP, and doesn't set community as well, just performs matching.

    - " However, there are plenty of times where I match on one community and set another." - I do explain that there's no real use for setting the comm value if being a "stub" AS, meaning that you don't advertise prefixes to other ASes AND the fact that there are specific use cases for this (if not being stub) - "If you do advertise the prefixes further, than yes, maybe you need to set communities for further labelling and further use."

     

    • In the same way, communities are used in Service Provider environment. So routes have been "coloured" by your provider, tagged, and based on the tag you can take any decision that you like, specifically in this case to determine what will be the exit point to the specific prefix out of your AS.

      Yes, except that the tags have to be swapped at the edge, as propagating a route with community 123:456 probably won't get any special behavior in the next network, but translating that to "one prepend" will.


    This is the same as explained above, you may want to set comm value for further purposes.

    "If you do advertise the prefixes further, than yes, maybe you need to set communities for further labelling and further use.

    Also, setting the communities would make sense for prefixes that you advertise, outbound."

     

    So again, what am I missing ? Thanks for your time and sorry for the long post.

  • peetypeety ✭✭✭

    Let's see...other reasons why you might need to match and set...RTBH (real-time black hole).  Even as a stub AS, you "should" set up RTBH, which is basically a logic that you can blackhole any address by routing it to a magic next-hop, perhaps 192.0.2.1.  On every router, you'd put a static route for 192.0.2.1/32 -> null0, so that the route recurses to null0 everywhere.  Not only does this blackhole traffic TO whatever you route to 192.0.2.1, if you use uRPF on your perimeter it will blackhole anything FROM whatever you route to 192.0.2.1.  That said, if you have 100M pipes and the attack is 200M in size, it doesn't matter that you're blackholing it at your edge.  If you've also put a community (perhaps ASN:0, or maybe ASN:10 to distinguish your own space) on these routes, you could rewrite ASN:10 to whatever your provider uses for null routing, and have them route that one address/subnet to null in THEIR network, so if they've got multi-gig pipes, they can deflect the attack and you only receive traffic for N-1 of your addresses, keeping the rest of your network in business.

    Also, that edge community swapping becomes a lot cleaner if you can build a route map outbound to your provider that has all of the relevant translations built into it.  That way, even as a stub AS, you can go to the core routers that originate your aggregates and tweak the communities you put on those routes to contain generic codes (request X LP in all providers, request Y LP in provider 2, etc.).  That way you can control the behaviors centrally, rather than endlessly rewriting the edge route maps for each customization.

    Essentially, it's hard to envision when you have one router, but it's helpful to put a variety of scaling things into your BGP setup on day one so that new router additions become easy.

  • peety, you got it all wrong ! I was really not asking for anymore information !! 

    but hey ... thanks ! [:D]

     

Sign In or Register to comment.