On 10/08/17 01:28, Ondrej Zajicek wrote:
On Mon, Aug 07, 2017 at 06:49:56PM +0300, Mikhail Mayorov wrote:
Please help me with recursion to caclulate bgp_next_hop using IGP.
I have 2 router "A" and "B" connected to each other via iBGP. Each of the
routers has connection to the outside world in different AS and get full
view. "A" has a eBGP session to the neighbor "A2" and "B" has a eBGP session
to the neighbor "B2". I configure "gateway recursive; direct;" on iBGP.
In this case, all the routes from the A2 got to B via A are as unreachable.
Recursive routes are supposed to be resolved through IGP routes, they
cannot be resolved through routes that are also recursive (to avoid
multiple levels of recursion and cycles). You could set 'next hop self'
so bgp_next_hop is directly 188.8.131.52, or just do not use
'gateway recursive' in this case.
Now I have zebra(quagga) for eBGP and bird for OSPF (IGP). So as I use
iBGP between borders and I configure "next hop self" on they. And I was
planning to switch IGP to iGBP on all my routers. It's 3 borders + 30 NAS.
From documentation on bird:
next hop self
Avoid calculation of the Next Hop attribute and always advertise our own
source address as a next hop. This needs to be used only occasionally to
circumvent misconfigurations of other routers. Default: disabled.
I want to throw away the crutch "next hop self". I may be wrong?!
I'm more interested in the principle of seeking this route (next_hop)
and why it is not found. I understand the IGP table is the same table
connects to protocol. Here I do not understand how this recursion works.
I received an announcement net = 184.108.40.206/22, BGP.next_hop:
I have a config file explicitly specified "gateway recursive;".
If you search for route 220.127.116.11, we find:
18.104.22.168/30 via 22.214.171.124 on vlan8 [twix_ipv4 07.08.2017
17:17:17] * (100) [i]
Type: BGP unicast univ
Why bird don't set gw = 126.96.36.199?! This host from local connected
Mikhail V. Majorov