Bird redundant routers with same AS on same location and prefix delegation to lower router

[Gelderman, Richard]

Hi,

I've tried to test two different approaches, but I am wondering what the most resilient is.

The first one is using a iBGP between R1 <> R2 with an private address range:

#R1
 from bgp_local {
         description "R2";
         neighbor 172.16.130.3 as my_as;
         import all;
 }

#R2
 from bgp_local {
         description "R2";
         neighbor 172.16.130.2 as my_as;
         import all;
 }

The second is using a public addresses.

What is the best pratice?

A underlying problem it creates is how can I export the 4 networks with prefix /24 from R3 out R1 and R2 who export a /22 who the R3 divides in to 4 networks?





-----Oorspronkelijk bericht-----
Van: Bird-users [mailto:bird-users-bounces at network.cz] Namens Ondrej Zajicek
Verzonden: dinsdag 19 september 2017 15:29
Aan: Andrew <nitr0 at seti.kr.ua>; Gelderman, Richard <r.gelderman at rtvoost.nl>
CC: 'bird-users at network.cz' <bird-users at network.cz>
Onderwerp: Re: Bird redundant routers with same AS on same location and prefix delegation to lower router

On Mon, Sep 18, 2017 at 03:44:40PM +0300, Andrew wrote:
> Hi.
> 
> Something like:
> 
> template bgp bgp_local {
>         local as my_as;
>         import filter import_bgp;
>         export filter export_bgp;
> multihop;
>         rr client;
>         rr cluster id 1.0.0.1;
> }
> 
> # R2 - also RR; import all routes from it protocol bgp bgp_peer_r2 
> from bgp_local {
>         description "R2";
>         neighbor x.x.x.x as my_as;
>         import all;
> }
> 
> # C1 - client
> protocol bgp bgp_peer_c1 from bgp_local {
>         description "C1";
>         neighbor x.x.x.y as my_as;
> }
> 
> cluster id should be same on all RRs.

Hi

Note that you configured your RR-RR session as mutual-RR-client. While such setting has also its uses, the usual way is to configure RR-RR session as regular IBGP session (without 'rr client'). But both approaches will work, and unless you have more non-RR-clients it does not matter.

Another approach is to set each RR as independent RR cluster (with own RR cluster ID) and just connect RR clients to two RR clusters. Such approach is less customary, but has some advantages.

To the original question - loops between RRs are prevented by CLUSTER_LIST option, so there is no reason to be afraid.

If there are just two dedicated RRs in one cluster (which is not the case in the original example as they also have EBGP links), you can just skip RR-RR session altogether as CLUSTER_LIST prevents to propagate anything by that session.

--
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."