route reflector setup problem

[SC SCx]

I have successfully been running this on bird 2.0.8 with the next hop self
ebgp option. Thank you for the suggestions!

One last question about this scenario:

Lets assume that my AS999 announces two prefixes: 1.1.1.0/24 and 2.2.2.0/24
to ebgp peers (via RR1 and RR2)

On RR1 client I export 1.1.1.1/32 to RR1 and RR2 (rr1 client has an ibgp
connection to each RR).
On RR2 client I export 2.2.2.2/32 to RR1 and RR2 (rr2 client has an ibgp
connection to each RR).

With this above, I have weird issues with the /32 prefixes.

I guess this is because each /32 prefix is then reachable from two places
(it is learned from RR client to RR ibgp connection and via an ibgp
connection between RRs) and the routing table is not optimal.

The way I had "fixed" it was creating an import filter on the IBGP
connection between RRs and setting the preference of the /32 prefixes to 90
(lower than the rest).

#example of one side
protocol bgp ibgp {
        local as 999;
        neighbor 10.0.0.2 as 999;
        source address 10.1.0.1;
        next hop self;
        rr cluster id 0.0.0.1;
        import filter {
               if source = RTS_BGP && net ~ [1.1.1.1/32, 2.2.2.2/32] {
                      preference = 90;
               }
               accept;
        }
}

With that said, is this a correct fix, or is there a more generic solution
around this issue?

Thanks!

czw., 29 lip 2021 o 12:06 Ondrej Zajicek <santiago at crfreenet.org>
napisał(a):

> On Thu, Jul 29, 2021 at 11:34:18AM +0200, SC SCx wrote:
> > Hi,
> >
> > I am trying to setup two route reflectors (that also pass traffic) that
> > peer with ebgp (and exchange routes via ibgp between themselves). So
> > something like.
> >
> > This works, but with some problems.
> >
> > Prefixes learned from AS100 and AS200 that get exported to RR clients are
> > unreachable unless they passed through the IBGP connection between RR1
> and
> > RR2.
> >
> > Makes sense, since the IBGP connection between RRs is defined with next
> hop
> > self, and the RR client connections aren't.
> >
> > So, I went in, and added "next top self" to the connections between RRs
> and
> > RR clients. It has fixed the unreachable problem but caused another one.
> >
> > Now prefixes that are exported on RR clients to RRs have their next hop
> > changed which is not what I want. I want to leave them intact. (e.g. RR
> > clients can export some private ip ranges which I don't want to be
> routable
> > on the RRs)
> >
> > So I *think* that I need a way on the RRs to only change next hop of EBGP
> > prefixes that get exported from RRs to RR clients but leave other
> prefixes
> > unaffected.
> >
> > Is my thinking correct? How can this be achieved?
>
> Hi
>
> You are right. There are two ways how to fix it:
>
> 1) Add non-BGP routes for inter-AS networks to local routers (RR
> clients). If you use OSPF, then just add inter-AS networks as stubs to
> OSPF area. Then you do not need 'next hop self'.
>
> 2) As you noticed, the issue with 'next hop self' is that it is configured
> on exporting IBGP session, but it should really depend on BGP session who
> imported the route (so it is applied on routes received through EBGP, but
> not ones received through IBGP). In BIRD 2, we added support for 'next
> hop self ebgp', which does exactly that. But you seems to use BIRD 1,
> you can do the same with export filter expressions instead:
>
>   if proto = "EBGP_PROTOCOL_NAME" then bgp_next_hop = LOCAL_IP;
>   accept;
>
> (substitute EBGP_PROTOCOL_NAME and LOCAL_IP).
>
> --
> 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."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20210827/e4a80c73/attachment.htm>