BGP Communities on MPLS network

[firecodex]

Here's the scenario:

I have two main sites with a route to a remote network (over point to point T1's) and I have two other branches that need to access that network. All four of these sites are connected over an MPLS network. Both main sites are advertising a route to the remote network using eBGP. I need one of the branches to route through main site 1 and the other to route through main site 2. At the same time, I would like to have a secondary route for each of the branches in case one of the main sites goes down. What are the commands & community strings I would enter to enable this to work as intended? I know how to do this when I have two different neighbors to each site (A to B, B to C, C to A), but in this situation each site only has one neighbor as there is only one MPLS circuit to each site.

Thanks in advance for your help.


------------------
Firecodex
CCNA/MCSA/MCP/A+/Net+

 

[helpdeskdan]

If one wishes to prefer one route over the other, the simplest thing to do would be to change the weight.

http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/bgp.htm#wp1020576

On each router, choose the route which you wish BGP to prefer. Weight is not propagated to other routers.

 

[firecodex]

Thanks for the link helpdeskdan.

All this time I've been trying to use the "local-preference" attribute, and I know that this is propogated to neighbors. It seems to have no effect. When both of my main sites advertise a route to the host network, one of my branch routers changes its route to point to the wrong network, completely ignoring the local-pref.

My network is a little different than the one described in the cisco article as it is an MPLS network with only one link and one neighbor per site (not including the host network we're trying to route to). I'm going to try using the "weight" attribue as you suggested, but I would have thought that I'd want the neighbor router (AT&T) to be aware of my router's preferred route? Maybe not?


------------------
Firecodex
CCNA/MCSA/MCP/A+/Net+

 

[helpdeskdan]

If there is only one link and one neighbor per site, then wouldn't there be only one route it can take?

Also, local pref is transmitted inside a system only via iBGP. It won't effect any eBGP routes. I wouldn't worry about informing AT&T what route to take. FYI - this would be done by setting the MED value. But, MED is something that is considered after many other things. If you have multiple paths and you want to influence it (on that router only) then weight is the way to go.

 

[firecodex]

Well this is what I've got, can you tell me what we're doing wrong? We want router C to go out router B to access the host and router D to go out router A to access the host. Additionally, we would like the option of failing over to A or B respectively, if one of them should go down.

If I add the line "network 10.46.0.56 mask 255.255.255.255" to router B, then router D starts routing to router B instead of to router A which it is doing now.

Please note that we have two links to the MPLS network from router A and that we're using eBGP multihop to load balance those circuits. I've also cleared out the WAN addressing and renamed a few other things for privacy reasons.

-------------------------------------------------
Router A:

interface Serial0/0/0
description Connection to MPLS Network
bandwidth 1500
ip address x.x.x.x 255.255.255.252
ip nat inside
ip virtual-reassembly
encapsulation ppp
!
interface Serial0/1/0
description Connection to MPLS Network
bandwidth 1500
ip address x.x.x.x 255.255.255.252
ip nat inside
ip virtual-reassembly
encapsulation ppp
!
router bgp 65000
no synchronization
bgp log-neighbor-changes
network 0.0.0.0
network 10.11.100.0 mask 255.255.255.0
network 10.31.254.12 mask 255.255.255.252
network 10.40.0.0 mask 255.255.248.0
network 10.46.0.0 mask 255.255.252.0
network 10.46.0.56 mask 255.255.255.255
network 10.46.240.0 mask 255.255.255.128
network 10.54.157.0 mask 255.255.255.0
network 10.63.34.128 mask 255.255.255.128
network 10.63.38.0 mask 255.255.255.0
network 170.209.0.2 mask 255.255.255.255
network 170.209.0.3 mask 255.255.255.255
network 223.3.3.111 mask 255.255.255.255
neighbor 10.10.10.1 remote-as 7000
neighbor 10.10.10.1 ebgp-multihop 2
neighbor 10.10.10.1 update-source Loopback0
neighbor 10.10.10.1 send-community
neighbor 10.10.10.1 route-map RouterA out
no auto-summary

access-list 1 permit 10.46.0.56
access-list 1 permit 10.46.0.0 0.0.255.255
access-list 1 permit 10.46.240.0 0.0.0.255
access-list 2 permit any

route-map RouterA permit 10
description host routes via RouterA
match ip address 1
set community 100
!
route-map RouterA permit 20
description All other RouterA routes
match ip address 2

-------------------------------------------------
Router B:

interface Serial0/1/0
description Connection to RouterC (point to point T1)
bandwidth 1500
ip address 10.70.1.1 255.255.255.252
encapsulation ppp
service-module t1 remote-alarm-enable
!
interface Serial0/2/0
description Connection to MPLS Network
bandwidth 1500
ip address x.x.x.x 255.255.255.252
encapsulation ppp
service-module t1 remote-alarm-enable
!
router bgp 65000
no synchronization
bgp log-neighbor-changes
network 10.40.18.0 mask 255.255.254.0
network 10.65.81.192 mask 255.255.255.192
neighbor x.x.x.x remote-as 7000
neighbor x.x.x.x send-community
neighbor x.x.x.x route-map RouterB out
no auto-summary

access-list 1 permit 10.46.0.56
access-list 1 permit 10.46.0.0 0.0.255.255
access-list 1 permit 10.46.240.0 0.0.0.255
access-list 2 permit any

route-map RouterB permit 10
description host routes via RouterB
match ip address 1
set community 250
!
route-map RouterB permit 20
description All other RouterB routes
match ip address 2

-------------------------------------------------
Router C:

interface Serial0/1/0
description Connection to RouterB (point to point T1)
bandwidth 1500
ip address 10.70.1.2 255.255.255.252
encapsulation ppp
service-module t1 remote-alarm-enable
!
interface Serial0/2/0
description Connection to MPLS Network
bandwidth 256
ip address x.x.x.x 255.255.255.252
encapsulation ppp
service-module t1 timeslots 1-4
service-module t1 remote-alarm-enable
!
router bgp 65000
no synchronization
bgp log-neighbor-changes
network 10.40.20.0 mask 255.255.254.0
network 10.65.82.192 mask 255.255.255.192
neighbor x.x.x.x remote-as 7000
neighbor x.x.x.x route-map RouterC in
no auto-summary

ip community-list 1 permit 250
ip community-list 2 permit 100
ip community-list 3 permit local-AS

route-map RouterC permit 10
description Host Routes from RouterB
match community 1
set weight 500
!
route-map RouterC permit 20
description Host Routes from RouterA
match community 2
set weight 300
!
route-map RouterC permit 30
description All remaining routes (local-as)
match community 3

-------------------------------------------------
Router D:

interface Serial0/1/0
description Connection to MPLS Network
bandwidth 1500
ip address x.x.x.x 255.255.255.252
ip nat outside
ip virtual-reassembly
encapsulation ppp
service-module t1 remote-alarm-enable
!
router bgp 65000
no synchronization
bgp log-neighbor-changes
network 10.40.26.0 mask 255.255.254.0
neighbor x.x.x.x remote-as 7000
neighbor x.x.x.x route-map RouterD in
no auto-summary

ip community-list 1 permit 250
ip community-list 2 permit 100
ip community-list 3 permit local-AS

route-map RouterD permit 10
description Host routes from RouterA
match community 2
set weight 500
!
route-map RouterD permit 20
description Host routes from RouterB
match community 1
set weight 300
!
route-map RouterD permit 30
description All remaining routes (local-as)
match community 3



------------------
Firecodex
CCNA/MCSA/MCP/A+/Net+

 

[helpdeskdan]

This has been a fun review of BGP for me; it really is amazing how quickly you can forget this stuff if you don't use it.

Router D only has one int. It is going to take interface Serial0/1/0 no matter what you do. I guess I'm not completely clear on what you wish to do or your topology, but I see you are using communities to attempt to do it. You are setting communities with the intent of using route maps to set different weights which will influence the exit interface, correct?

As Router D has only 1 interface, everything will take that interface regardless of the weight. Weight is not transitive; no other router will receive this information. You must set it on the end router.

 

[firecodex]

Thanks for the help. To answer your question, I was trying to affect the route it takes within the network, not the exit interface itself. I realize that weight is not transitive which is why I was using local-pref before but that wasn't working so I tried metric and then weight and that was where I left off.

Anyway, I posted the same question on Cisco's website and a CCIE from Cisco was able to confirm what I was thinking. He says that AT&T's backbone is running BGP and is choosing the best route for me rather than passing all of the routes to me. So regardless of what I do, AT&T's core routers will always pick what it believes to be the best route, and transfer the packet there.

Thanks again for your help.


------------------
Firecodex
CCNA/MCSA/MCP/A+/Net+

 

[helpdeskdan]

Ah - yeah, that explains it. Even if you were to set the an attribute that would influence what AT&T would do, they may choose to filter it out. Thanks for posting instead of abandoning the thread.

 

[jneiberger]

helpdeskdan is right. If you only have one exit interface then you have very limited control over routing decisions. In order to do what you're trying to do, you'd probably have to have some control over how AT&T routes your packets.

I used to run a similar network that used Qwest MPLS. I had a similar problem, but it's not quite the same. I had one location that was the central site for most services, so I configured that site to advertise 0.0.0.0. However, I had a backup site that I wanted people to go to if the main site was down. Luckily for me, Qwest left my MED attribute alone, so I just configured the second site to advertise 0.0.0.0 with a higher MED. That worked with no problem.

 

[helpdeskdan]

Thanks for the added information, jneiberger.

 

[plshlpme]

so to do what you want could you not just create a tunnel between the two endpoints and route traffic through it?

that way you would be in control of where the traffic went.