BGP LP assignment based on community value


R1 (AS100)========================R3(AS200)

R1 assign community 200:200 to for routes oriniated in AS 60
R3 macthing the community and assigning Local preference of 200 to community of 200:200

Rack1R1#sh ip bgp regexp _60$
BGP table version is 36, local router ID is 150.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
s>i112.0.0.0        204.12.1.254             0    100      0 54 50 60 i
s>i113.0.0.0        204.12.1.254             0    100      0 54 50 60 i

router bgp 100
 no synchronization
 bgp log-neighbor-changes
 bgp dmzlink-bw
 network 1.1.1.1 mask 255.255.255.255
 aggregate-address 112.0.0.0 248.0.0.0 as-set summary-only attribute-map ATT
 neighbor 155.1.13.3 remote-as 200
 neighbor 155.1.13.3 send-community both
 neighbor 155.1.13.3 soft-reconfiguration inbound
 neighbor 155.1.13.3 unsuppress-map TO_AS200
 no auto-summary

 

ip bgp-community new-format

Rack1R1#sh route-map TO_AS200
route-map TO_AS200, permit, sequence 10
  Match clauses:
    ip address prefix-lists: LOOP113
  Set clauses:
    community 200:200
  Policy routing matches: 0 packets, 0 bytes

Rack1R1#sh ip prefix-list LOOP113
ip prefix-list LOOP113: 2 entries
   seq 5 permit 113.0.0.0/8
   seq 10 permit 112.0.0.0/8


ON R3-----------------

 

router bgp 200
 no synchronization
 bgp always-compare-med
 bgp log-neighbor-changes
 bgp bestpath as-path ignore
 aggregate-address 10.0.0.0 255.255.252.0 summary-only
 neighbor 155.1.13.1 remote-as 100
 neighbor 155.1.13.1 send-community both
 neighbor 155.1.13.1 soft-reconfiguration inbound
 neighbor 155.1.13.1 route-map TOAS_60 in
 no auto-summary

ip bgp-community new-format
ip community-list standard 200:200 permit 200:200


Rack1R3#sh route-map TOAS_60
route-map TOAS_60, permit, sequence 10
  Match clauses:
    community (community-list filter): 200:200
  Set clauses:
    local-preference 200
  Policy routing matches: 0 packets, 0 bytes

route-map TOAS_60, permit, sequence 20
  Match clauses:
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes

 

Rack1R3#
*Mar  1 01:26:49.419: %BGP-5-ADJCHANGE: neighbor 155.1.13.1 Up
Rack1R3#sh ip bgp 113.0.0.0/8
BGP routing table entry for 113.0.0.0/8, version 93
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Flag: 0x8E0
  Advertised to update-groups:
        1    2    4
  100 54 50 60
    155.1.13.1 from 155.1.13.1 (150.1.1.1)
      Origin IGP, localpref 200, valid, external, best
      Community: 200:200 <-----------------------set LP =200 for community of 200:200

  100 54 50 60, (received-only)
    155.1.13.1 from 155.1.13.1 (150.1.1.1)
      Origin IGP, localpref 100, valid, external <----------What is this part of BGP table ?
      Community: 200:200                         <----------What is this part of BGP table ?


Why in the BGP table two entries are showing ?

Comments

  • ack1R3#
    *Mar  1 01:26:49.419: %BGP-5-ADJCHANGE: neighbor 155.1.13.1 Up
    Rack1R3#sh ip bgp 113.0.0.0/8
    BGP routing table entry for 113.0.0.0/8, version 93
    Paths: (2 available, best #1, table Default-IP-Routing-Table)
    Flag: 0x8E0
      Advertised to update-groups:
            1    2    4
      100 54 50 60
        155.1.13.1 from 155.1.13.1 (150.1.1.1)
          Origin IGP, localpref 200, valid, external, best
          Community: 200:200 <-----------------------set LP =200 for community of 200:200

      100 54 50 60, (received-only)
        155.1.13.1 from 155.1.13.1 (150.1.1.1)
          Origin IGP, localpref 100, valid, external <----------What is this part of BGP table ?
          Community: 200:200                         <----------What is this part of BGP table ?


    Why in the BGP table two entries are showing ?

    Paths that are marked as (received-only) in the show ip bgp  output, the policy has rejected these paths. The router has stored the paths because you have configured soft-reconfiguration inbound for the neighbor that sends the path.

    Can you try removing soft-reconfiguration inbound? Please update here...

  • That's rite....when i removed the soft-configuration in that part of BGP table is removed.

    Thanks for explantination!!!

    Also can i enable " soft-configuration in " In the exam even if its not asked to do so...just for troubleshooting purpose.....If NO which command i can use to see number of prefixes received from specific neighbour ?

  • Also can i enable " soft-configuration in " In the exam even if its not asked to do so...just for troubleshooting purpose.....If NO which command i can use to see number of prefixes received from specific neighbour ?

    Yes for show ip bgp neighbor received-routes, you need to enable soft-configruation, which is memory consuming command as well. I would recommend to use show ip bgp neighbor advertised-routes instead of received.

    Good Luck

  • Also can i enable " soft-configuration in " In the exam even if its not asked to do so...just for troubleshooting purpose.....If NO which command i can use to see number of prefixes received from specific neighbour ?

    Hi!

    You can use ...

    sh ip bgp neighbors 1.1.1.1 received-routes on the receiving side

    or

    sh ip bgp neighbors 2.2.2.2 advertised-routes on the sending side.

     

    Regards!

    Markus

  • Yeah - please don't mess with soft-reconfiguration inbound, it is no longer needed :). It was in the past, but no more.

    Just my 2 cents.

  • peetypeety ✭✭✭

    Why in the BGP table two entries are showing ?

    Paths that are marked as (received-only) in the show ip bgp  output, the policy has rejected these paths. The router has stored the paths because you have configured soft-reconfiguration inbound for the neighbor that sends the path.

    Can you try removing soft-reconfiguration inbound? Please update here...

    Two entries are showing because you've enabled soft-reconfiguration inbound, you're learning a path and modifying its attributes.  With SRI enabled, the as-learned (i.e. unmodified) path appears in the BGP RIB as either received-only or "received & used".  If SRI is enabled and you have modified any of the attributes in such a way that the route is still being accepted, you'll see a second version of the route with the modifications applied, without any reference to it being a 'received' route.  In your example case, you're modifying the local preference to 200.

    To correct the previous answer you were given, seeing a path marked as 'received only' is NOT necessarily that the policy has rejected this path.  If you "see it twice" (once unmodified, once modified), it was accepted and modified.  If you see it once and marked "received and used" it was accepted and not modified by inbound policy.  If you see it once and marked "received-only", then you know that inbound policy rejected it.

  • peetypeety ✭✭✭

    Yeah - please don't mess with soft-reconfiguration inbound, it is no longer needed :). It was in the past, but no more.

    Just my 2 cents.

    It has significant value both in production and in the CCIE environment.  It allows "you" to see the impact of any inbound filtering, and differentiate between "my neighbor never sent me the route" and "my inbound policy discarded some routes that the neighbor did send".

    It's very useful with customers who don't understand BGP.  Those who are too lazy to learn/use 'sh ip b nei x.x.x.x adv' really hate when you show them 'sh ip b nei x.x.x.x received-r' and the route they think they're sending isn't there.

  • Peety,

    I understand that it helps understanding what has been filtered, etc. But is it really worth using it in production environments? In the customers I have supported so far, it is usually not enabled. It may vary, though.

  • peetypeety ✭✭✭

    In my previous days in the Service Provider space, none of my BGP customers knew what they were doing with BGP.  Having SRI enabled meant a huge time savings no matter what they were trying to do.  For those that didn't know how to filter, they didn't know how to check their own advertisements either, so being able to show them that they were sending every single route within their network to us was very powerful.  For those who knew how to filter and thought they knew how to prepend, SRI was very useful to show them the unmodified advertisements.

    It was also useful on provider connections, particularly when they were having issues.  Our NTT/Verio link dropped one day at the exact same time as two other local transport circuits, so I suspected a power problem at a CO/POP.  Sure enough, power problem, but NTT's Juniper gear completely lost their startup config.  As soon as the link went down, I immediately applied our "maintenance" route-maps, which meant NTT would be used only if all our other carriers died.  When it came back up, the BGP session restored (so they had no alarms caused by us 'shutting' the session) but we weren't trusting their routes, and we were only getting 300-400 routes instead of the 250k we'd expected.  With SRI, we were able to view them without our route maps' alterations and see that we were only getting routes pertaining to local Houston customers for about four hours.

     

  • You can use ...

    sh ip bgp neighbors 1.1.1.1 received-routes on the receiving side

    or

    sh ip bgp neighbors 2.2.2.2 advertised-routes on the sending side.

     

    Hi Markus,

    ganpatspatil is asking in case of soft-reconfiguration is not enabled. If soft-reconfiguration is not enabled, you can't use show ip bgp neighbor x.x.x.x recevied routes command.

    See here:

    R1(config-router)#do show ip bgp neighbor 12.12.12.2 received-routes
    % Inbound soft reconfiguration not enabled on 12.12.12.2

     

  • I understand that it helps understanding what has been filtered, etc. But is it really worth using it in production environments? In the customers I have supported so far, it is usually not enabled. It may vary, though.

    Qqabdal,

    This feature is still being used in customer side:Let's say you have BGP peering with customer router who doesn't understand anything about routing/BGP. As soon as you make changes in routing policies, you should reset/clear the BGP peering to apply the policies(either hard reset or soft, soft is recommended). clear ip bgp * soft in|out. If person don't know about this command, neighbor soft-reconfiguration command directed the Cisco IOS software in the local BGP router to store all received (inbound) routing policy updates without modification. This method is memory-intensive and not recommended unless absolutely necessary. (Outbound updates have never required the extra memory and are not affected by this feature.)

  • Narayan and peety,

    Thanks for the explanation. I understand that it may have advantages in some situations. In this specific customer, we are not using due to the memory utilization related to this feature.

    Cheers!

  • Thanks for the explanation. I understand that it may have advantages in some situations. In this specific customer, we are not using due to the memory utilization related to this feature.

    Soft-reconfiguraiton is memory intensive commands and command was developed before clear ip bgp * soft in|out released and without soft-reconfiguration you can't use show ip bgp neighbor x.x.x.x recevied-routes command.

  • peetypeety ✭✭✭

    This method is memory-intensive and not recommended unless absolutely necessary.

    Please stop spreading FUD (fear, uncertainty, doubt).  This method uses memory, but it's not "intensive".  It's recommended in a variety of solutions as I pointed out, so therefore it's wrong to say it's not recommended unless absolutely necessary.

    In the context of THIS FORUM (CCIE Route/Switch Technical), I would say that it's highly recommended and the memory usage is inconsequential.

  • Peety,

    I guess we need to step back and think about it better. I do agree with you it all depends. So let's say you have 100-10000 routes in your BGP routing table, that shouldn't problem. However, if we are talking about the whole Internet routing table (+300000), then, I would start to be concerned about it.

     

  • Please stop spreading FUD (fear, uncertainty, doubt).  This method uses memory, but it's not "intensive".  It's recommended in a variety of solutions as I pointed out, so therefore it's wrong to say it's not recommended unless absolutely necessary.

    It all depends on you, how do you intepret it, if you look on Cisco documentation also you can find soft-reconfiguration is "memory-intensive not recommend..." So keep in mind this is not a FUD...

  • Mr. Peety,

    I talk to people like you all day.. I just mute and laugh.. You got your point across sir. thank you.

  • Chill guys! :) You both have valid points. The recommendation to to not use soft-reconfiguration and call it memory intensive was based on hardware from far back. Todays hardware has much more memory and processing power and can handle it in a better way.

    Route refresh takes away most of the usage of soft-reconfiguration but it has one valid use as peety is pointing out and that is to test filters. Just make sure that you know what the feature does before you turn it on. There is probably a way to check how much memory it uses extra per route and then calculate how much it will take in total. If you have the RAM and the need for it then go for it.

  • Hi peety,

    So u mean to say

    1)If route is marked with "received-only" or "received & used" then it is unmodified route.

     2)If SRI is enabled and you have modified any attributes in such a way that route is still being accepted then route will be marked as "received" ?

    Please correct my understanding and any poing if u want to .

    /Ganpat

  • peetypeety ✭✭✭

    Hi peety,

    So u mean to say

    1)If route is marked with "received-only" or "received & used" then it is unmodified route.

     2)If SRI is enabled and you have modified any attributes in such a way that route is still being accepted then route will be marked as "received" ?

    Please correct my understanding and any poing if u want to .

    If SRI is not enabled, you won't see (received-only) or (received&used).

    If SRI is enabled, a route that is accepted by your policy and NOT modified will appear as (received & used).  The unmodified version of any route modified or blocked by your policy will appear as (received-only); a modified copy of that route will also appear if you policy accepted (and modified) it.

  • peetypeety ✭✭✭

    Chill guys! :) You both have valid points. The recommendation to to not use soft-reconfiguration and call it memory intensive was based on hardware from far back. Todays hardware has much more memory and processing power and can handle it in a better way.

    Route refresh takes away most of the usage of soft-reconfiguration but it has one valid use as peety is pointing out and that is to test filters. Just make sure that you know what the feature does before you turn it on. There is probably a way to check how much memory it uses extra per route and then calculate how much it will take in total. If you have the RAM and the need for it then go for it.

    Yes, I do get "wound up" on certain topics.  That said, Cisco's recommendations due to hardware concerns have no merit when studying for a CCIE exam, as it is not a real-world exam.  I struggled too many times "in the room" because of real-world habits, and we all need to be clear on this when studying.

Sign In or Register to comment.