route reflector setup problem
SC SCx
kredaxx at gmail.com
Sat Aug 28 17:05:38 CEST 2021
Sorry, the reply for some reason did not reference the original message
which included an ascii diagram.
as100 as200
> | |
> | |
> ebgp ebgp
> | |
> | |
> RR1(as999)--- ibgp --- RR2(as999)
> | \ / |
> | \ / |
> | \ / |
> | \ / |
> | \ / |
> | \ / |
> | \ / |
> | X |
> | / \ |
> | / \ |
> | / \ |
> | / \ |
> | / \ |
> rr client 1 rr client 2
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). So that RRs prefer prefixes of ibgp connections from
rr clients, rather than the ones learnt by ibgp between RR1 to RR2.
#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!
> 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.
as100 as200
> | |
> | |
> ebgp ebgp
> | |
> | |
> RR1(as999)--- ibgp --- RR2(as999)
> | \ / |
> | \ / |
> | \ / |
> | \ / |
> | \ / |
> | \ / |
> | \ / |
> | X |
> | / \ |
> | / \ |
> | / \ |
> | / \ |
> | / \ |
> rr client 1 rr client 2
I came up with a config like this (for simplicity's sake I will only show
> RR1's side since it's the equivalent for RR2 with just slightly different
> parameters like ip addresses, etc.)
# ebgp from RR1 to as100
> protocol bgp ebgp_as100 {
> local as 1000;
> neighbor 100.100.100.100 as 100;
> export filter {
> if PREFIXES_TO_EXPORT() then accept;
> reject;
> }
> import filter {
> if PREFIXES_TO_IMPORT_LTE_24() then accept;
> reject;
> }
> }
# ibgp from RR1 to RR2
> 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;
> }
# RR1 to rr client 1 (also has one for rr client 2)
> protocol bgp rr_client1{
> local as 999;
> neighbor 10.0.0.3 as 999;
> source address 10.1.0.1;
> rr client;
> rr cluster id 0.0.0.1;
> # next hop self #???
> export filter {
> if PREFIXES_TO_EXPORT() then accept;
> reject;
> };
> import filter {
> if PREFIXES_TO_IMPORT() then accept;
> reject;
> };
> }
##########################################################
# on rr client 1 to RR1 (also has one for RR2)
> protocol bgp rr1_ibgp {
> local as 999;
> neighbor 10.0.0.1 as 999;
> source address 10.1.0.3;
> next hop self;
> export all;
> import all;
> }
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?
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/20210828/785e5ccf/attachment.htm>
More information about the Bird-users
mailing list