Api process of a template announce routes to other templates

[cedrictabary]

** Bug Report **

Describe the bug

I have two templates, one for public IP announce and another one for private IP announce to a different network/interface.
Each templace has an api process that announce specific routes.
But all routes are sent to all peers ignoring the inherited template.

To Reproduce

Use this config (local/remote AS removed...) :

process dynamic_routes_public {
        run /some/script/that/announce/a/prefix;
        encoder text;
}
process dynamic_routes_private {
        run /some/script/that/announce/another/prefix;
        encoder text;
}
template {
        neighbor public {
                api {
                        processes [ dynamic_routes_public ];
                }
        }
        neighbor private {
                api {
                        processes [ dynamic_routes_private ];
                }
        }
}
neighbor x.x.x.x {
        inherit public;
}
neighbor y.y.y.y {
        inherit private;
}

Expected behavior

Routes announced by process dynamic_routes_public should only be announced to neighbor x.x.x.x.
Routes announced by process dynamic_routes_private should only be announced to neighbor y.y.y.y.

Environment (please complete the following information):

• OS: Ubuntu 20.04.1 LTS
• Version: 4.2.4-1

Additional context

[thomas-mangin]

Thank you for the report Cédric. Have you tested if things are working as should when the process section is under the neighbour, please?

[cedrictabary]

I just removed all template and used only neighbors with process inside.

something similar to :

process dynamic_routes_public {
        run /some/script/that/announce/a/prefix;
        encoder text;
}
process dynamic_routes_private {
        run /some/script/that/announce/another/prefix;
        encoder text;
}
neighbor x.x.x.x {
         router-id ....;
        local-address ....;
        local-as .....;
        peer-as .....;
        api {
                        processes [ dynamic_routes_public ];
         }
}
neighbor y.y.y.y {
         router-id ....;
        local-address ....;
        local-as .....;
        peer-as .....;
        api {
                        processes [ dynamic_routes_private ];
         }
}

Still no luck.
After full restart of exabgp I still have a combination of both process announces.

[aj-gh]

I remember reading somewhere ages ago - I could be wrong though - that there were some known limitations of API / processes causing cross-neighbor propagation back then, not sure if this still applies.
(Update: I think this was #268 and #280 almost 6 years ago so likely already addressed)
In any case I also have the issue that the healthcheck via API-process of one peer propagates these routes to all other peers as well.

[adzhurinskij]

In my case similar to. All routes are sent to all peers ignoring the inherited template.
Config example:

process p1 {
        run /api-announce.run;
        encoder json;
}

process p2 {
        run /api-reload.run;
        encoder json;
}

template {
  neighbor t1 {
    router-id 172.17.40.87;
    local-address 172.17.40.87;
    local-as 65531;

    family {
      ipv4 unicast;
    }
  }
}

neighbor 172.24.8.246 {
  inherit t1;
  description "chr01";
  peer-as 65530;

  api {
          processes [ p1 ];
  }
}

neighbor 172.24.8.40 {
  inherit t1;
  description "chr02";
  peer-as 65530;

  api {
          processes [ p2 ];
  }
}

Version:

13:42:18 | 36087  | welcome       | Thank you for using ExaBGP
13:42:18 | 36087  | version       | 4.2.13  
13:42:18 | 36087  | interpreter   | 3.8.2 (default, Dec 21 2020, 15:06:03)  [Clang 12.0.0 (clang-1200.0.32.29)]
13:42:18 | 36087  | os            | Darwin MacBook-Pro-Aleksandr.local 20.3.0 Darwin Kernel Version 20.3.0: Thu Jan 21 00:06:51 PST 2021; root:xnu-7195.81.3~1/RELEASE_ARM64_T8101 arm64

[ktims]

I'm having the same issue with the processes set under the neighbor statements. I have separate processes for v4 and v6 healthchecks, and they are associated with the BGP session on the matching address family, which also passes the matching NLRIs only.

With the desired configuration, I get errors about mismatched address family constantly appearing in the logs. On further investigation, adding both v4/v6 unicast to both BGP sessions, I can confirm that the 'foreign' routes are being passed to the peer.

Maybe the configuration is incorrect? The documentation for this feature is terrible. There doesn't seem to be a single example with multiple healthchecks in one configuration.

What I have (want) is

template {
        neighbor anycast {
                local-as 65520;
                peer-as 65521;
                router-id 1.2.3.4;
        }
}

process service-dns4 {
        run exabgp-healthcheck -s --config /etc/exabgp/service-check4.conf;
        encoder text;
}
process service-dns6 {
        run exabgp-healthcheck -s --config /etc/exabgp/service-check6.conf;
        encoder text;
}

neighbor 1.2.3.1 {
        inherit anycast;
        description "anycast-ipv4";
        local-address 1.2.3.4;
        family inet4 {
                ipv4 unicast;
        }
        api services4 {
                processes [ service-dns4 ];
        }
}

neighbor 2607:1:2:3::1 {
        inherit anycast;
        description "anycast-ipv6";
        local-address 2607:1:2:3::4;
        family inet6 {
                ipv6 unicast;
        }
        api services6 {
                processes [ service-dns6 ];
        }
}

With this configuration, routes from both service checks appear at both BGP peers.

I am using the Ubuntu 20.04 packages, but did confirm the same behaviour with 4.2.13.

ExaBGP : 4.2.4
Python : 3.8.10 (default, Jun  2 2021, 10:49:15)  [GCC 9.4.0]
Uname  : Linux dns3 5.4.0-80-generic #90-Ubuntu SMP Fri Jul 9 22:49:44 UTC 2021 x86_64
Root   : 

[ottorei]

I am experiencing a similar issue. All processes are run on all neighbors even when explicitly stating the process names on them.

ExaBGP : 4.2.4
Python : 3.8.10 (default, Mar 15 2022, 12:22:08) [GCC 9.4.0]

[Solvik]

Thank you @thomas-mangin !

[thomas-mangin]

You are nice, but I should be sorry as I overlooked this for way too long ...