HELP: BGP inbound route selection

[allenelson]

Hello

I'm trying to come up with a good way to prefer inbound BGP routes on a provider MPLS network. My initial thoughts were setting up and using communities, but unfortunately this lead to some headache and wasted time. I'm looking for a simple way to advertise the same networks from routers A & B but select which ones to prefer at C & D. This is going to be used for redundancy and load balancing bandwidth intensive applications that have their own circuits back to the vendor networks installed at A & B. Changing the metrics doesn't seem feasible because all sites will prefer the same path.

In a nutshell, is there an easy way to filter a specific community similar to using "ip as-path access-lists" ? I'll post my configs below but these were not working. When trying to verify the correct routes were installed and saved, the backup route wasn't showing up at all in the backup table, so my thoughts are the provider routers are blocking the route completely for whatever reason.

Another issue with this setup is the community tag set on the provider routers. I can't tell what is set, but if I block and allow specific communities it appears to block the downstream routers community tag as well, rendering all of the MPLS routes invalid and killing the connections.

The AS's in use are 65000 and 15270 but I've also seen 65007 via show ip bgp. My guess is that's another AS in the middle of the provider network somewhere.

rtr-A#

ip bgp-community new-format

router bgp 65000
 bgp log-neighbor-changes

 network 192.168.5.0 mask 255.255.255.0
 neighbor 1.1.1.185 remote-as 15270
 neighbor 1.1.1.185 update-source MFR1.502
 neighbor 1.1.1.185 send-community
 neighbor 1.1.1.185 soft-reconfiguration inbound
 neighbor 1.1.1.185 route-map SITEA out

!

route-map SITEA permit 10
 match ip address prefix-list OUTBOUND
 set community 7000:20

!

ip prefix-list OUTBOUND seq 5 permit 172.16.26.0/24
ip prefix-list OUTBOUND seq 10 permit 172.16.29.0/24
ip prefix-list OUTBOUND seq 15 permit 172.16.33.0/24
ip prefix-list OUTBOUND seq 20 permit 192.168.5.0/24

rtr-B#

ip bgp-community new-format

router bgp 65000
 bgp log-neighbor-changes

 network 192.168.240.0 mask 255.255.255.0
 neighbor 1.1.1.205 remote-as 15270
 neighbor 1.1.1.205 update-source Serial0/0/0.502
 neighbor 1.1.1.205 send-community
 neighbor 1.1.1.205 soft-reconfiguration inbound
 neighbor 1.1.1.205 route-map SITEB out

!

route-map SITEB permit 10
 match ip address prefix-list OUTBOUND
 set community 6000:20

!

ip prefix-list OUTBOUND seq 5 permit 172.16.26.0/24
ip prefix-list OUTBOUND seq 10 permit 172.16.29.0/24
ip prefix-list OUTBOUND seq 15 permit 172.16.33.0/24
ip prefix-list OUTBOUND seq 20 permit 192.168.240.0/24

[Renan Abreu · Accepted solution]

Hi allenelson,

     In my understanding communities would be the best way for you to do it, but are you receiving the communities correctly?

     1 - Do you want to set the community on the links you mentioned and not pass the rest of it? On the route-map SITEA for example, you're setting the community for 4 prefixes and blocking all the rest, if you still want to send the rest but without the community, you need to enter another permit statement with nothing inside it.

     2 -  When you said you're blocking and allowing specific communities, do you really mean that? would it be better to change the local_preference for that specific community and leave the others as backup?

     3 - You need to make sure the communities are reaching your C and D devices, the SP may be stripping them off so you are matching actually nothing.

[allenelson]

1. I am setting the communities and am receiving them on the far end. I like where you went with this, something I hadn't thought of. If there are 3 routes advertised by A & B, maybe I should set them to different communities and the routes that aren't duplicates set them as another? So in that case at each site I'd have 2 distribute lists, with 2 different communities. Community 7000:20 could advertise the 3 172.x.x.x's while community 7001:20 could advertise it's local LAN 192.168.5.0? I could then replicate this at site B with community 6000:20 and 6001:20 ?

2. That's the issue, I don't want to block any communities yet I want to prefer which community to inject into the forwarding table. That's basically why I'm asking for assistance, maybe communities aren't the attribute I'd like to use in this equation?

3. The provider routers are passing the community tag, I've verified this. But on the provider equipment I think it's just using it's AS number as the community field as well.

[allenelson]

This is my thought now.. I'm reiterating what was said in #1 about setting up multiple communities. I'm hoping on sites C & D I don't have to block anything which should allow the provider routes to come through. As an example, this is one of the provider routes and the community value that is set.

Gateway#show ip bgp 63.139.151.69
BGP routing table entry for 63.139.151.69/32, version 16
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  15270 65007, (received & used)
    74.9.113.185 from 74.9.113.185 (64.80.254.206)
      Origin IGP, localpref 100, valid, external, best
      Community: 65007:10129

So I'm looking at 65007:10129.. But I'm hoping it doesn't matter because I'll add a last resort permit statement in the route-map that allows all communities through. I'll post a sample for site C below, let me know if you think this would work. This is based on the fact I'll be receiving 4 communities, 7000:20 7001:20 6000:20 and 6001:20 plus unknowns. The communities I'd like to weigh are 7001:20 and 6001:20 which contain the 172.16.x.x routes. 7000:20 and 6000:20 will have the local LANs and should be the same weight throughout locations. The last permit statement in the route-map should allow the carrier to pass whatever community it sends without blocking it.

router bgp 65000
 neighbor x.x.x.x route-map INBOUND in
!
ip bgp-community new-format
!
ip community-list 1 permit 7000:20
ip community-list 2 permit 7001:20
ip community-list 3 permit 6000:20
ip community-list 4 permit 6001:20
!
route-map INBOUND permit 10
 match community 1
 set local-preference 120
route-map INBOUND permit 20
 match community 2
 set local-preference 120
route-map INBOUND permit 30
 match community 3
 set local-preference 120
route-map INBOUND permit 40
 match community 4
 set local-preference 130
route-map INBOUND permit 50

!

[Renan Abreu]

Hi,

     Well, the way you configured, you'll prefer 6001:20 over 7001:20 (Higher local_pref is chosen) and 7000:20 and 6000:20 will have the same local_pref, they'll be chosen with the other attributes subsequents from local_pref (path selection can be seen in the link below), is that what you looking for? All the other prefixes will be installed in BGP table unchanged as you're allowing them in permit 50.

http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html

[allenelson]

Apologies I wrote the local preference backwards.. Confused lower taking precedence over the higher.

That's exactly what I'm after though. Will the route-map permit 50 allow the rest of the communities in.. I think you've answered that for me and that's the answer I was hoping for. I wasn't sure because I was permitting the 4 communities but not specifying the unknowns. My hopes were the permit statement in the route-map would take care of that for me.

I'll post the results after I can schedule downtime and test. I thank you both for the help, I wasn't thinking out of the box on this one stuck on single communities at each location.

[Renan Abreu]

Cool, let us know the results.

The ACLs implicit DENY could be thought the same way to route-maps, although, they behave differently depending where you're applying it, PBR for example, will not drop based on the implicit deny, it will just send it untouched and not send the packet to the CPU to be interpreted by it.

The route-map for BGP is a filter, so if you don't explicitly say it is permitted, it won't allow the prefixes to go through.

[allenelson]

Gotcha gotcha, duly noted. The community statements had me questioning the validity..

ip community-list X permit

Since I don't plan on adding them for the unknown communities. This is great info though, once again many thanks, sometimes I get stuck thinking inside the box.

[Julio Carvajal · Accepted solution]

Hello,

So you want to influence Inbound traffic.

For that you have 2 BGP attributes to play with, the MED and the BGP Autonomous System.

Now I can see that you are talking about filtering routes which is different as you will be basically ignoring some routes (not accepting them into BGP) which will basically drop away the opportunity to use load-balancing or even a backup route.

Either way in the case of communities, just make sure you are sending the routes to the neigbhor with the right community value and that on the device where the filtering should take place you just match the community in a route-map as follows

ip community-list 1 permit 100:300

route-map TEST deny 10 

match community-list 1

route-map TEST permit 20 

router bgp 100

neig x.x.x.x route-map TEST in 

That's how you do it :)

With a show ip bgp x.x.x.x/Y (prefix and netmask) you will be able to determine if your router is actually learning the community value 

Hope that I could help

Regards

[allenelson]

If I allow 1 community in I lose a few things. The first is all of the MPLS routes that are provided by the carrier's equipment. I'd basically block routes to their routers and wouldn't be able to access the community allowed in the ACL due to that. The next problem is, I'd also lose the LAN network route from community X which I need because lets say it's the main branch. The main branch advertises 3 duplicate network routes, but also it's own local subnet.

[allenelson]

To add onto this, I have no control over the provider equipment, whatever they send me I'm at the mercy of. This is what was strange to me.. Without blocking anything, just setting up communities, when I advertise 172.16.29.0/24 from site A and B, I look on site C using show commands and can only see the route it actually preferred. Couldn't find an alternate path in the backup table at all. Is this normal behavior?

Part of the issue is that I'm peering with the provider equipment. None of the neighbors are customer owned equipment which is why I'm trying to tag the routes as they come through so I can then influence which one to prefer somehow. But like I was saying, whichever route is installed into the table, that's it, no backup is found. Is there an alternate in the provider router? More than likely but I can't see it and I think that's why I can't influence it. Metrics considered, both routes should be equal cost in my eyes, but how many routers downstream on the provider side is unknown, so they may not be equal cost in reality.