84405ab953
**- Why I did it** FRR introduced [next hop tracking](http://docs.frrouting.org/projects/dev-guide/en/latest/next-hop-tracking.html) functionality. That functionality requires resolving BGP neighbors before setting BGP connection (or explicit ebgp-multihop command). Sometimes (BGP MONITORS) our neighbors are not directly connected and sessions are IBGP. In this case current configuration prevents FRR to establish BGP connections. Reason would be "waiting for NHT". To fix that we need either add static routes for each not-directly connected ibgp neighbor, or enable command `ip nht resolve-via-default` **- How I did it** Put `ip nht resolve-via-default` into the config **- How to verify it** Build an image. Enable BGP_MONITOR entry and check that entry is Established or Connecting in FRR Co-authored-by: Pavel Shirshov <pavel.contrib@gmail.com> Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
28 lines
527 B
Django/Jinja
28 lines
527 B
Django/Jinja
!
|
|
{% block vrf %}
|
|
{% if VNET is defined %}
|
|
{% for vnet_name, vnet_metadata in VNET.iteritems() %}
|
|
vrf {{ vnet_name }}
|
|
vni {{ vnet_metadata['vni'] }}
|
|
!
|
|
{% endfor %}
|
|
{% endif %}
|
|
{% endblock vrf %}
|
|
!
|
|
{% block interfaces %}
|
|
! Enable nht through default route
|
|
ip nht resolve-via-default
|
|
! Enable link-detect (default disabled)
|
|
{% for (name, prefix) in INTERFACE|pfx_filter %}
|
|
interface {{ name }}
|
|
link-detect
|
|
!
|
|
{% endfor %}
|
|
{% for pc in PORTCHANNEL %}
|
|
interface {{ pc }}
|
|
link-detect
|
|
!
|
|
{% endfor %}
|
|
{% endblock interfaces %}
|
|
!
|