04-07-2014
01:44 PM
- last edited on
03-25-2019
03:41 PM
by
ciscomoderator
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
Solved! Go to Solution.
04-07-2014 02:39 PM
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.
04-07-2014 07:52 PM
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
04-07-2014 02:39 PM
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.
04-08-2014 07:59 AM
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.
04-08-2014 08:23 AM
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
!
04-08-2014 10:17 AM
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
04-09-2014 07:34 AM
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.
04-09-2014 07:49 AM
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.
04-09-2014 08:25 AM
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.
04-07-2014 07:52 PM
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
04-08-2014 07:54 AM
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.
04-08-2014 08:05 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide