I attached a simple diagram of four routers, rtr1 in each city are physically cabled between each other on port 2/1 and rtr2 are the same on thier 2/1 port. the local routers 1 and 2 are physically cabled between each other on port 1/19. They are configured with ibgp sessions using thier loopbacks and they are running OSPF for thier physically and loopback addresses. connectivity is great, and the BGP sesions came up. Rtr1 and RTR2 in each seperate city have a bgp multihop session for thier ibgp and they are not physically connected.
My issue stems from the same provider having ebgp sessions in two different cities. One with rtr1 and the other city with rtr2. The routes learned are the same.
In City A, rtr1 sends packets out to provider A which is good. Rtr2 in City A sends packets to rtr1 and out to provider A which is what we want. The issue is with City B. Rtr 2 in City B sends packets to provider A via its BGP session locally. That is expected. Rtr1 in City B is sending traffic to rtr1 in City A and not locally to rtr2 for those routes. We do not want that to go to city A. We want the traffic to stay local and get sent to rtr2 and out to provider A. This way traffic does not have to travel the WAN.
We have simple BGP up, so peer statement, AS statement and update source is loopbacks. That is all for the ibgp session.
If anyone can help with geting the bgp sessions configured so we are sending packets to the locally shortest patch versus over the WAN I would appreciate it.
You need to look at the attributes on BGP routes you are receiving on router B1 to find out why routes to A1 are preferred over ones from B2.
show ip bgp
If all attributes are the same routes from the neigbors, you may be routed to A b/c of
lower IP from A. Look into weight attribute for BGP Path Selection.
CityB-rtr1 could be making the decision to route via CityA with a number of factors. The full BGP decision criteria is detailed here:
To find out what CityB-rtr1 is using to make its decision you will need to provide a 'show ip bgp x.x.x.x/x' for the route in question from CityB-rtr1.
If you want to force CityB-rtr1 to use CityB-rtr2 then the correct attribute to do this would be LOCAL PREFERENCE.
The configuration below on CityB-rtr1 will do what you need:
router bgp xxxx
neighbor 172.17.2.4 route-map LP in
route-map LP permit 10
set local-preference 300
You might find you'll have to reset the BGP peer between CityB-rtr1 and CityB-rtr2 to make it work after this.
Do you see the local BGP routes in cityB R1 and R2 through EBPG ?
I dont think so because R2 will see its own AS in the list and discard it,which is why both R1 and R2 are sending traffiic to city A.
To confirm this :
Send the output of show ip bgp x.x.x.x/x command as pointed by Simon.
After that we could move further.
local AS number is added only on eBGP neigbor sessions.
Here the reason for the choice should be:
Step 11 of BGP path selection from link posted by Simon
Prefer the route that comes from the BGP router with the lowest router ID
if all links have equal IGP costs, and provider A sends routes with the same attributes.
from the pdf we can see that cityA:R1 has lower loopback address and likely lower BGP router-id.
Hope to help
Hi Giuseppe ,
The original post says
"My issue stems from the same provider having ebgp sessions in two different cities"
Will that not mean if customer will send a route from r1 the provider in city A will use the AS number of customer say 10
and send to CITY B provider router ,once the route will exit the provider router at city B it will have provider AS and customer AS prepend say 20 10
and when the customer will see its own AS (10) will it not drop that route from the update.
Am i mising something here .
my understanding is different the scenario is eBGP multihoming in two different points with a full mesh of iBGP sessions.
the sessions are not used to make the two sites to exchange routes at least not in normal scenario.
BGP AS path attribute received is propagated unchanged (without adding the local AS number) to an iBGP peer with just an i code to says it is received over an iBGP session on the other routers.
sh ip bgp | inc 195.22.
* i184.108.40.206/24 x.y.z.6 0 110 0 8968 3356 7018 2386 i
the i after the leftmost * stays for received on an iBGP session;
the local AS number is NOT 8968, that is AS path attribute is not changed
BGP AS number of the network would be added when advertising the prefix to another eBGP peer.
Hope to help
I think what is happening here is the BGP paths have the same weights through the entire BGP path selection until the router ID. The reason City B rtr2 is not sending to city A rtr 1 is becuase it is learning the routes via the connected peer ISP. So it is going to trust that since EBGP is cost 20 over iBGP cost 200.
What I am thinking of doing here is using communities to tag routes and let route maps change local prefs. So for instance, I was thinking to have city A learned routes tagged with 1:200 and any routers in that city woudl have a route map matching for that community to set local pref high, say 200. City B would tag with 1:201 and in that city set local pref to 200. in City A, when seeing the community 1:201 from city B the route map would set pref to say 120. Vice versa in City B. This way any routes learned from that city it would exit AS 1 locally instead of traversing the WAN like it is doing today.
Does that make sense or is there a better way.
as suggested by others you may want to evaluate the use of BGP weight instead of local preference.
if your iBGP mesh is made only of the 4 routers shown in your picture you should use weight to avoid to influence choices of devices of the other city.
the simplest solution could be
router bgp xx
neigh cityB:R2 weight 500
this should give you the desired effect without influencing other devices.
the risk with local preference is that cityB:R1 can cause cityA routers to elect city:R2 as preferred exit point.
Alternatively, you can selectively increase weight using set weight
Hope to help
Hi Giuseppe ,
What you are saying is right BUT.
What i am trying to say is Both cities EBGP ISP router will receive router on there EBGP session and will always prefer them ,
While the customer network will receive the route through IBGP.
And the router inside the ISP will receive those route but they will never be best route .
So the internal path will always prefer IBGP over EBGP to reach those network.
And if the IBGP session goes down between the 2 router it will not accept the route through EBGP because of it own AS number.