BGP Community Sent and Received on both sides of an MPLS circuit

Started by Seittit, January 06, 2015, 02:35:52 PM

Previous topic - Next topic

dely

If you'd like to prefer one route over the other, what about a using route maps and set the local preference to meet your needs?

Quote from: Seittit on January 08, 2015, 10:31:05 AM
Quote from: wintermute000 on January 08, 2015, 02:40:31 AM
BTW regex based filtering/route manipulation is a common CCIE lab scenario, and the good old ^$ trick is a fantastic one to have in your locker (for any stub sites esp. EIGRP stub, filter outbound BGP via ^$ i.e. only allow local originated routes, its clean and no maintenance).

for the sake of redundancy, we don't want to filter out BGP routes learned on our MPLS head end routers. We'd like to prefer one path over another, and in the event of a failure, switch over to the alternate path as quickly as possible.

BGP != quick

Here's a thought:

  • field site sends community ABC for subnets ABC to both MPLS providers
  • field site sends community XYZ for subnets XYZ to both MPLS providers
  • two MPLS routers back at datacenter, R1 peers with Provider 1 and R2 peers with Provider 2
  • router 1 redistributes all Provider 1 BGP routes into EIGRP, but applies a nasty EIGRP metric to anything with community XYZ
  • router 2 redistributes all BGP routes into EIGRP, but applies a nasty EIGRP metric to anything with community ABC

With some EIGRP manipulation at the site, you can ensure that subnets A, B, and C will traverse Provider 1 and all subnets X,Y, and Z will traverse Provider 2 when sending traffic to the datacenter.
Back in the datacenter, an aggregate router between routers 1 and 2 will make the final decision as to which provider to traverse to when sending traffic to the site.

wintermute000

OP has already stated

"this is a solution we initially discussed, but was dismissed as unsupportable. We have just six engineers on the team: only three of us could handle this task and all six of us are stretched incredibly thin. We need a solution that's as dynamic as we can get it, unfortunately."