Follow up question on "next hop self"
Hello, I was wondering about how bird solves the following problem with next hop self enabled: R1 <--------> R2 \ / \ / upstream 1 So both routers receive the same routes from upstream and insert them with the same local_pref. With "next hop self" on, both routers will think that the path is not the same and potentially either of the two routers could start routing via the other router instead of via upstream directly. What is the typical approach to solve this situation correctly? Does making setting the local_pref lower if received from an iBGP router make sense in that case? Best regards, Nico -- Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch
Hi, On ven. 20 déc. 22:36:29 2019, Nico Schottelius wrote:
Hello,
I was wondering about how bird solves the following problem with next hop self enabled:
R1 <--------> R2 \ / \ / upstream 1
So both routers receive the same routes from upstream and insert them with the same local_pref. With "next hop self" on, both routers will think that the path is not the same and potentially either of the two routers could start routing via the other router instead of via upstream directly.
What is the typical approach to solve this situation correctly? Does making setting the local_pref lower if received from an iBGP router make sense in that case?
Best regards,
Nico
There will be no loop because eBGP paths are preferred over iBGP ones if the routes are equals. https://tools.ietf.org/html/rfc1771#section-9.1 BTW, using classical iBGP, RRs and an IGP will solve many of this kind of problems. -- Alarig
Hey Alarig, Alarig Le Lay <alarig@swordarmor.fr> writes:
[...] What is the typical approach to solve this situation correctly? Does making setting the local_pref lower if received from an iBGP router make sense in that case?
Best regards,
Nico
There will be no loop because eBGP paths are preferred over iBGP ones if the routes are equals. https://tools.ietf.org/html/rfc1771#section-9.1
BTW, using classical iBGP, RRs and an IGP will solve many of this kind of problems.
I have had a look at OSPF, but for our relatively simple network it looks like an overkill. Do you have any other recommendations for what to run the IGP with instead? The main reason I so far tried to stay on iBGP only is to reduce complexity. Best, Nico -- Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch
On sam. 21 déc. 00:39:43 2019, Nico Schottelius wrote:
I have had a look at OSPF, but for our relatively simple network it looks like an overkill. Do you have any other recommendations for what to run the IGP with instead?
The main reason I so far tried to stay on iBGP only is to reduce complexity.
You could try babel but the doc says “When retracting a route, Babel generates an unreachable route for a little while (according to RFC). The interaction of this behavior with other protocols is not well tested and strange things may happen.” However, OSPF isn’t very complex, but every interface in area 0 (on a soft router you will have more than enough CPU for this) and you’re done. This way, you will not have to deal with stubby and not-so-stubby areas. -- Alarig
On Sat, Dec 21, 2019 at 12:39:43AM +0100, Nico Schottelius wrote:
I have had a look at OSPF, but for our relatively simple network it looks like an overkill. Do you have any other recommendations for what to run the IGP with instead?
The main reason I so far tried to stay on iBGP only is to reduce complexity.
Well, you can run just IBGP, if you use direct + 'next hop self' options, which should be OK in your simple topology. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
On Sun, Dec 22, 2019 at 3:03 PM Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Sat, Dec 21, 2019 at 12:39:43AM +0100, Nico Schottelius wrote:
I have had a look at OSPF, but for our relatively simple network it looks like an overkill. Do you have any other recommendations for what to run the IGP with instead?
The main reason I so far tried to stay on iBGP only is to reduce complexity.
Well, you can run just IBGP, if you use direct + 'next hop self' options, which should be OK in your simple topology.
According to my understanding of the BIRD code, 'next hop self' is only relevant when exporting a locally originated route to a BGP peer. So, assuming the original question was about what happens on R1 and R2, I would not expect it to be relevant at all. Is that right?
On Mon, Jan 06, 2020 at 06:25:30PM +0000, Neil Jerram wrote:
On Sun, Dec 22, 2019 at 3:03 PM Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Sat, Dec 21, 2019 at 12:39:43AM +0100, Nico Schottelius wrote:
I have had a look at OSPF, but for our relatively simple network it looks like an overkill. Do you have any other recommendations for what to run the IGP with instead?
The main reason I so far tried to stay on iBGP only is to reduce complexity.
Well, you can run just IBGP, if you use direct + 'next hop self' options, which should be OK in your simple topology.
According to my understanding of the BIRD code, 'next hop self' is only relevant when exporting a locally originated route to a BGP peer. So, assuming the original question was about what happens on R1 and R2, I would not expect it to be relevant at all. Is that right?
Option 'next hop self' is relevant in both exporting locally originated route to a BGP (i.e. a route without existing bgp_next_hop attribute) and exporting route from BGP to another BGP (i.e. a route with existing bgp_next_hop attribute). See bgp_use_next_hop() and bgp_use_gateway() functions and their usage. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
On Tue, 7 Jan 2020, 00:39 Ondrej Zajicek, <santiago@crfreenet.org> wrote:
On Mon, Jan 06, 2020 at 06:25:30PM +0000, Neil Jerram wrote:
On Sun, Dec 22, 2019 at 3:03 PM Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Sat, Dec 21, 2019 at 12:39:43AM +0100, Nico Schottelius wrote:
I have had a look at OSPF, but for our relatively simple network it looks like an overkill. Do you have any other recommendations for what to run the IGP with instead?
The main reason I so far tried to stay on iBGP only is to reduce complexity.
Well, you can run just IBGP, if you use direct + 'next hop self' options, which should be OK in your simple topology.
According to my understanding of the BIRD code, 'next hop self' is only relevant when exporting a locally originated route to a BGP peer. So, assuming the original question was about what happens on R1 and R2, I would not expect it to be relevant at all. Is that right?
Option 'next hop self' is relevant in both exporting locally originated route to a BGP (i.e. a route without existing bgp_next_hop attribute) and exporting route from BGP to another BGP (i.e. a route with existing bgp_next_hop attribute).
Thanks, yes, I should have mentioned the second case too. But both cases are on export, so I think my point still stands that 'next hop self' is not relevant to the question that began this thread. (Unless I misunderstood that question.) Best wishes, Neil
On Tue, Jan 07, 2020 at 12:05:21PM +0000, Neil Jerram wrote:
On Tue, 7 Jan 2020, 00:39 Ondrej Zajicek, <santiago@crfreenet.org> wrote:
Well, you can run just IBGP, if you use direct + 'next hop self' options, which should be OK in your simple topology.
According to my understanding of the BIRD code, 'next hop self' is only relevant when exporting a locally originated route to a BGP peer. So, assuming the original question was about what happens on R1 and R2, I would not expect it to be relevant at all. Is that right?
Option 'next hop self' is relevant in both exporting locally originated route to a BGP (i.e. a route without existing bgp_next_hop attribute) and exporting route from BGP to another BGP (i.e. a route with existing bgp_next_hop attribute).
Thanks, yes, I should have mentioned the second case too.
But both cases are on export, so I think my point still stands that 'next hop self' is not relevant to the question that began this thread. (Unless I misunderstood that question.)
Yes, 'next hop self' is relevant just for export, that is why i suggested direct + 'next hop self' - 'next hop self' on export side ensures that direct (or rather 'gateway direct') on import side has reachable next hop address. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
participants (4)
-
Alarig Le Lay -
Neil Jerram -
Nico Schottelius -
Ondrej Zajicek