<div dir="ltr"><div dir="ltr">On Mon, Oct 14, 2019 at 2:10 PM Ondrej Zajicek <<a href="mailto:santiago@crfreenet.org">santiago@crfreenet.org</a>> wrote:<br></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">On Mon, Oct 14, 2019 at 11:08:50AM +0100, Neil Jerram wrote:<br>
> Hi - I have a topology like this, using BIRD 1.6.7:<br>
> <br>
> I want BIRD-B to reflect routes within its own AS, but also propagate<br>
> routes to and from AS 65001.  So for the eBGP peering I have<br>
<br>
> My question is how to get the ideal next-hop-self behaviour, which I<br>
> think is<br>
> <br>
> - Do next-hop-self for routes from AS 65001 that are being passed on<br>
>   to Router B, C etc.  Otherwise those routes will be unreachable.<br>
> <br>
> - Don't do next-hop-self for reflected routes.  Next-hop-self isn't<br>
>   needed here, because the downstream Router B, C etc are already<br>
>   directly connected.<br>
<br>
Hello<br>
<br>
We implemented extension for next-hop-self in version 2.0.3 that allows<br>
to specify 'next hop self ebgp', this solves exactly this issue.<br>
<br>
For older versions, you would need to workaround that in filters,<br>
something like:<br>
<br>
if proto = "bgpX" then<br>
  bgp_next_hop = A.b.C.D;<br></blockquote><div><br></div><div>Thanks Ondrej.  Am I right in thinking that I should do this in the import filter?  (From reading the code, it appears that "next hop self" takes effect on import.)</div><div><br></div><div>Best wishes,</div><div>    Neil</div><div> </div></div></div>