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:[email protected]] Namens Ondrej Zajicek
Verzonden: dinsdag 19 september 2017 15:29
Aan: Andrew <[email protected]>; Gelderman, Richard <[email protected]>
CC: '[email protected]' <[email protected]>
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: [email protected]) OpenPGP encrypted
e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to
blame it on a computer is even more so."
