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: santi...@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."
