bird bgp metric distance

Question

In my lab I have two routers which are connected to different ISPs.
They're not directly connected via a wire, but they're connected via a tunnel.

Through that tunnel I used to create an iBGP peer and they exchange routes.

Now, router A sends a better route to router B which now installs it into its routing table.

Now Router B is "able" to reach everything through the tunnel via Router A.

The above scenario describes my problem and I thought the solution was to check incoming routes which come from the neighbor router in the same AS and add a higher distance so that existed routes won't change.

Is that even a good solution? If yes, how am I able to do that?

Here's my filter configuration so far, but, unfortunately, it doesn't work properly:

import filter {
   if bgp_path ~ [= AS_NUMBER =] then
       {
             bgp_path.prepend(AS_NUMBER);
             bgp_path.prepend(AS_NUMBER);
             bgp_path.prepend(AS_NUMBER);
             bgp_path.prepend(AS_NUMBER);
             bgp_path.prepend(AS_NUMBER);
             bgp_path.prepend(AS_NUMBER);
             bgp_path.prepend(AS_NUMBER);
             accept;
           }
         reject;
 };

But the problem seems to be more complicated:

I need to adjust a preference on both iBGP routers.

E.g. router A has a higher preference than router B, router B will send send everything through router A.

Either my settings are wrong, or performing an iBGP peer through a tunnel is more than wrong.

Answer 1

You problem seems to be related to the iBGP rule that iBGP routers will not advertise a route learned from another iBGP speaker. The problem is that iBGP will not change the AS_PATH, and this creates the problem of routing loops. To avoid routing loops, iBGP speaker will not advertise to any other iBGP speakers prefixes learned through iBGP. That is why iBGP requires a full-mesh (every iBGP speaker must have a connection to every other iBGP speaker) or a mitigation such as route reflectors or confederations.

If you are trying to advertise, through the tunnel, prefixes learned from another iBGP speaker, that will not work. You need to either use eBGP through the tunnel, or set up the routers at the tunnel ends as route reflectors or separate confederations. The route reflectors must have a connection to every router for which it is a route reflector, or confederations must have a full-mesh of iBGP speakers.

The methods used to modify routing for eBGP, such as AS_PATH prepending or changing the metric (MED), are for eBGP, not iBGP.

Answer 2

If I understand correctly (as it is not clearly elaborated) the problem that you are encountering is related to how the routes are prioritized for the same prefixes learned through both providers ISPA and ISPB, for some reason when traffic leaving your network hits router B it doesn't go via ISPB link, but it goes via tunnel --> router A --> ISPA link, even though router B also has the routes for the same destinations received from ISPB provider.

In case you want to change this behavior and you look forward to use the directly provider connected to that router once the traffic reaches it then you have to tune up or remove the Local Preference configured for iBGP session between Router A and B, as Local Preference is the parameter that can prioritize the order on how a BGP decision will be processed, for more details please refer to this link http://www.techrepublic.com/blog/data-center/understand-how-the-bgp-best-path-selection-algorithm-works-on-your-router/.

In addition, as it was already explained previously by Ron Maupin user, the AS_PATH prepending or changing of the metric (MED) doesn't affect iBGP behavior, these attributes change only eBGP behavior and will allow you to define the policy for the incoming traffic not for outbound traffic, which means you can define the policy on how your prefixes associated to your ASN should be advertised to the entire world.