<div dir="ltr"><div>Sorry, the reply for some reason did not reference the original message which included an ascii diagram.</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">as100 as200<br>| |<br>| |<br>ebgp ebgp<br>| |<br>| |<br>RR1(as999)--- ibgp --- RR2(as999)<br>| \ / |<br>| \ / |<br>| \ / |<br>| \ / |<br>| \ / |<br>| \ / |<br>| \ / |<br>| X |<br>| / \ |<br>| / \ |<br>| / \ |<br>| / \ |<br>| / \ |<br>rr client 1 rr client 2</blockquote><div><br></div><div dir="ltr"><div>I have successfully been running this on bird 2.0.8 with the next hop self ebgp option. Thank you for the suggestions!<br></div><div><br></div><div>One last question about this scenario:<br></div><div><br></div><div>Lets assume that my AS999 announces two prefixes: <a href="http://1.1.1.0/24" target="_blank">1.1.1.0/24</a> and <a href="http://2.2.2.0/24" target="_blank">2.2.2.0/24</a> to ebgp peers (via RR1 and RR2)</div><div><br></div><div>On RR1 client I export <a href="http://1.1.1.1/32" target="_blank">1.1.1.1/32</a> to RR1 and RR2 (rr1 client has an ibgp connection to each RR).</div><div>On RR2 client I export <a href="http://2.2.2.2/32" target="_blank">2.2.2.2/32</a> to RR1 and RR2 (rr2 client has an ibgp connection to each RR).</div><div><br></div><div>With this above, I have weird issues with the /32 prefixes.<br></div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>#example of one side<br></div><span class="gmail-im" style="color:rgb(80,0,80)"><div>protocol bgp ibgp {<br> local as 999;<br> neighbor 10.0.0.2 as 999;</div><div> source address 10.1.0.1;<br> next hop self;<br> rr cluster id 0.0.0.1;<br></div></span><div> import filter {</div><div> if source = RTS_BGP && net ~ [<a href="http://1.1.1.1/32" target="_blank">1.1.1.1/32</a>, <a href="http://2.2.2.2/32" target="_blank">2.2.2.2/32</a>] {</div><div> preference = 90;</div><div> }</div><div> accept;<br></div><div> }<br></div><div>}</div><div><br></div><div>With that said, is this a correct fix, or is there a more generic solution around this issue?<br></div></div><div><br></div><div>Thanks! </div><div><br></div><div> </div></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I am trying to setup two route reflectors (that also pass traffic) that<br>peer with ebgp (and exchange routes via ibgp between themselves). So<br>something like.</blockquote><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">as100 as200<br>| |<br>| |<br>ebgp ebgp<br>| |<br>| |<br>RR1(as999)--- ibgp --- RR2(as999)<br>| \ / |<br>| \ / |<br>| \ / |<br>| \ / |<br>| \ / |<br>| \ / |<br>| \ / |<br>| X |<br>| / \ |<br>| / \ |<br>| / \ |<br>| / \ |<br>| / \ |<br>rr client 1 rr client 2</blockquote><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I came up with a config like this (for simplicity's sake I will only show<br>RR1's side since it's the equivalent for RR2 with just slightly different<br>parameters like ip addresses, etc.)</blockquote><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"># ebgp from RR1 to as100<br>protocol bgp ebgp_as100 {<br> local as 1000;<br> neighbor 100.100.100.100 as 100;<br> export filter {<br> if PREFIXES_TO_EXPORT() then accept;<br> reject;<br> }<br> import filter {<br> if PREFIXES_TO_IMPORT_LTE_24() then accept;<br> reject;<br> }<br>}</blockquote><br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"># ibgp from RR1 to RR2<br>protocol bgp ibgp {<br> local as 999;<br> neighbor 10.0.0.2 as 999;<br> source address 10.1.0.1;<br> next hop self;<br> rr cluster id 0.0.0.1;<br>}</blockquote><br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"># RR1 to rr client 1 (also has one for rr client 2)<br>protocol bgp rr_client1{<br> local as 999;<br> neighbor 10.0.0.3 as 999;<br> source address 10.1.0.1;<br> rr client;<br> rr cluster id 0.0.0.1;<br> # next hop self #???<br> export filter {<br> if PREFIXES_TO_EXPORT() then accept;<br> reject;<br> };<br> import filter {<br> if PREFIXES_TO_IMPORT() then accept;<br> reject;<br> };<br>}</blockquote><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">##########################################################</blockquote><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"># on rr client 1 to RR1 (also has one for RR2)<br>protocol bgp rr1_ibgp {<br> local as 999;<br> neighbor 10.0.0.1 as 999;<br> source address 10.1.0.3;<br> next hop self;<br> export all;<br> import all;<br>}</blockquote><br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This works, but with some problems.</blockquote><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Prefixes learned from AS100 and AS200 that get exported to RR clients are<br>unreachable unless they passed through the IBGP connection between RR1 and<br>RR2.</blockquote><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Makes sense, since the IBGP connection between RRs is defined with next hop<br>self, and the RR client connections aren't.</blockquote><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So, I went in, and added "next top self" to the connections between RRs and<br>RR clients. It has fixed the unreachable problem but caused another one.</blockquote><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Now prefixes that are exported on RR clients to RRs have their next hop<br>changed which is not what I want. I want to leave them intact. (e.g. RR<br>clients can export some private ip ranges which I don't want to be routable<br>on the RRs)</blockquote><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So I *think* that I need a way on the RRs to only change next hop of EBGP<br>prefixes that get exported from RRs to RR clients but leave other prefixes<br>unaffected.</blockquote><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Is my thinking correct? How can this be achieved?</blockquote><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks.</blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">czw., 29 lip 2021 o 12:06 Ondrej Zajicek <<a href="mailto:santiago@crfreenet.org" target="_blank">santiago@crfreenet.org</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Jul 29, 2021 at 11:34:18AM +0200, SC SCx wrote:<br>
> Hi,<br>
> <br>
> I am trying to setup two route reflectors (that also pass traffic) that<br>
> peer with ebgp (and exchange routes via ibgp between themselves). So<br>
> something like.<br>
> <br>
> This works, but with some problems.<br>
> <br>
> Prefixes learned from AS100 and AS200 that get exported to RR clients are<br>
> unreachable unless they passed through the IBGP connection between RR1 and<br>
> RR2.<br>
> <br>
> Makes sense, since the IBGP connection between RRs is defined with next hop<br>
> self, and the RR client connections aren't.<br>
> <br>
> So, I went in, and added "next top self" to the connections between RRs and<br>
> RR clients. It has fixed the unreachable problem but caused another one.<br>
> <br>
> Now prefixes that are exported on RR clients to RRs have their next hop<br>
> changed which is not what I want. I want to leave them intact. (e.g. RR<br>
> clients can export some private ip ranges which I don't want to be routable<br>
> on the RRs)<br>
> <br>
> So I *think* that I need a way on the RRs to only change next hop of EBGP<br>
> prefixes that get exported from RRs to RR clients but leave other prefixes<br>
> unaffected.<br>
> <br>
> Is my thinking correct? How can this be achieved?<br>
<br>
Hi<br>
<br>
You are right. There are two ways how to fix it:<br>
<br>
1) Add non-BGP routes for inter-AS networks to local routers (RR<br>
clients). If you use OSPF, then just add inter-AS networks as stubs to<br>
OSPF area. Then you do not need 'next hop self'.<br>
<br>
2) As you noticed, the issue with 'next hop self' is that it is configured<br>
on exporting IBGP session, but it should really depend on BGP session who<br>
imported the route (so it is applied on routes received through EBGP, but<br>
not ones received through IBGP). In BIRD 2, we added support for 'next<br>
hop self ebgp', which does exactly that. But you seems to use BIRD 1,<br>
you can do the same with export filter expressions instead:<br>
<br>
if proto = "EBGP_PROTOCOL_NAME" then bgp_next_hop = LOCAL_IP;<br>
accept;<br>
<br>
(substitute EBGP_PROTOCOL_NAME and LOCAL_IP).<br>
<br>
-- <br>
Elen sila lumenn' omentielvo<br>
<br>
Ondrej 'Santiago' Zajicek (email: <a href="mailto:santiago@crfreenet.org" target="_blank">santiago@crfreenet.org</a>)<br>
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, <a href="http://wwwkeys.pgp.net" rel="noreferrer" target="_blank">wwwkeys.pgp.net</a>)<br>
"To err is human -- to blame it on a computer is even more so."<br>
</blockquote></div></div>
</blockquote></div></div>