2 BGP Peers/2 address blocks/1 Customer

[EMES]

I have a customer utilizing two address blocks at two locations(geographically different). We use static routes at both locations to direct traffic for these networks. Recently they have requested the ability to use either address block at either location. Their goal is to route both of these networks within their private network and advertise both networks to us via BGP. Each peer will transmit one network with higher prepends to make one location preferred for inbound routing. The design seems to work but I am not getting the results I expect when I do a show iproute for these networks. I would expect to either see the preferred route shared within my private network or both of them with varying distances. My two BGP Routers have similar results:
Router.15 # show iproute 10.0.140.0/23 Ori Destination Gateway Mtr Flags VLAN Duration
#be 10.0.140.0/24 10.0.42.218 6 UG-D---um--f X480Test 2d:19h:0m:17s #be 10.0.141.0/24 10.0.42.218 2 UG-D---um--f X480Test 2d:19h:0m:17sThe other router shows the same thing with the metrics flipped. I believe this to be functional but show iproute and traceroute's show it to be taking the shortest path and ignoring prepends. Let me know where I can provide further details to try and get to the bottom of this.

[EMES]

Does anybody know of a way to disable aggregation on ibgp neighbors via config options or with routing policies? aggregation is set to summary only and if I add a more specific aggregate route for the subnet that I need to be routed over these two peers then both of my ibgp peers point to each other and say that the best route is via the neighbor which just creates a routing loop. Willing to try any test designs at this point but right now I've reached my limits and I'm still waiting on support to get me a response that pushes this project along.

[Stephane_Grosj1]

Did you enable aggregation with summary-only? Without it, you would announce both the aggregated route and the contributing ones. I tend to believe aggregates are good on external, to reduce BGP table size. But it requires a bit more of attention and thinking, to avoid fragmented (bad) things on certain designs.

To better understand the whole config, I bet setting up a VM lab would be good (I don't have time right now, sorry).

AS-Path prepend is a way to try to influence the traffic coming back to you (when you have several paths). Local-Pref is your way to influence how traffic is exiting your network. Local-Pref is local to your AS, and is preferred over AS-Path length. So the way you set Local-Pref is important.

Considering the other side can do the exact same thing than you, you need some agreement so that they set their attribute the way you need. Using communities is a best practice to do so.

[EMES]

I added a private address range to the scope of things so that I was testing with a network that we haven't setup for bgp aggregation. My test results differ substantially so this is a good thing. My advertisements from the new peers look the same and from my side of the connection I see the advertised networks as expected. The changes I see are on the show route. Previously my two iBGP routers would only show the iproute of the local peer. Now it appears to show the route of the oldest BGP connection.
* iBGProuter1.63 # show bgp nei CPEPEER1 rec all Feasible Routes --------------- Destination Peer Next-Hop LPref Weight MED AS-Path i 192.168.140.0/24 CPEPEER1 CPEPEER1 64580 64580 64580 64580 64580 i 192.168.141.0/24 CPEPEER1 CPEPEER1 64580 64580 *>i 10.0.140.0/24 CPEPEER1 CPEPEER1 64580 64580 64580 64580 64580 *>i 10.0.141.0/24 CPEPEER1 CPEPEER1 64580 64580 Total Routes Rxed from Peer : 4 Accepted Routes from Peer : 4 Rejected Routes from Peer : 0 Active Routes from Peer : 2 * iBGProuter1.63 # show iproute 192.168.140.0/23 Ori Destination Gateway Mtr Flags VLAN Duration #bi 192.168.140.0/24 iBGPpeer 2 UG-D---um--f P2P_iBGP 0d:0h:3m:33s #bi 192.168.141.0/24 iBGPpeer 6 UG-D---um--f P2P_iBGP 0d:0h:3m:22sIf I disable the CPEPeer2 neighbor on the iBGPpeer then the received routes will populate as active. I believe this is some version of progress!

EDIT: Tried a different AS on CPEPeer2 and the condition still exists, the preferred route is the one that has been up the longest. So the influence has to be coming from LPref....adjusted CPEPeer to 100, ibgp peer is 50. I set the CPEPeers to 50 and I get the results expected from sh iproute.

Closing arguments: I have enabled bgp aggregation, can I disable that on an ibgp peer so that those networks are advertised? It appears that it would be best to run different private ASN's at each location but is the best solution to make both peers have the same local preference as my iBGP so they have the same weight and I can then look at prepends?

[EMES]

Your description is correct. From my two test peers, I receive the two routes mentioned with the paths that I have set...one with 2 prepends and one with 6. I am sending a default route to the would be CPE router and they are sending me both test networks. I have tried this with differing ASN's and similar ASN's with no difference in results but I can say that I have changed lots of things so I could go back and perform this testing again with more control. We set local pref for our main DIA(200), a CDN(1), backup DIA(100), iBGP(50), and I had originally set the CPE peers as 200 but I tried to set them to 40 as well so that they wouldn't overwrite each other in favor of the better route via iBGP, share your thoughts if this idea was flawed! Last question, I have set next-hop-self on the iBGP peers.

I am taking over the reigns on this network so some of this is a bit foreign, at least compared to the person that set it all up. If I left any voids, please let me know what details I can provide.

I am going to do a quick test in the AM but BGP aggregation is setup on both of the core Peers and I am curious if this is causing some of my issues. I think it is somewhat atypical to advertise your aggregated networks via ebgp. Perhaps in this scenario it is best to install a managed router at customer prem? Or is it advisable to allow them to use our AS when peering with our IP space? I have route policies in place to prevent them from advertising anything other than the blocks we have provided and we only provide them a default route.

I will setup a pair of private address blocks on these lab switches and allow them in the route policies to see if they will show up as I am expecting in the route tables.