FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
ojacinto
Staff
Staff
Article Id 280677
Description This article describes how to troubleshoot the error 'denied due to originator is us' in an IBGP scenario with a route reflector.
Scope

FortiOS 6.4.0 and later.
FortiOS 7.0.0 and later.

FortiOS 7.2.0 and later.
Solution

Consider the following scenario:

 

ScreenHunter_87 Oct. 24 15.46.jpg

 

Spoke2 (router-id 10.10.1.5) will advertise the following prefixes to the HUB device by IBGP:

172.18.117.0/24.

172.18.115.0/24.

172.18.109.0/24.

Spoke2:

config router bgp

    set as 65400

    set router-id 10.10.1.5  <--
    set ibgp-multipath enable

    set additional-path enable

    set additional-path-select 4

        config neighbor

            edit "10.10.1.1"

                set soft-reconfiguration enable

                set remote-as 65400

            next

            edit "10.20.2.1"

                set soft-reconfiguration enable

                set remote-as 65400

            next

        end

        config network

            edit 1

                set prefix 172.18.109.0 255.255.255.0

            next

            edit 2

                set prefix 172.18.115.0 255.255.255.0

            next

            edit 3

                set prefix 172.18.117.0 255.255.255.0

            next

        end

end

 

The HUB device working as a RR will advertise these prefixes to the Spoke1.

 

HUB:

config router bgp

    set as 65400

    set router-id 10.10.1.1  <--

    set ibgp-multipath enable

    set additional-path enable

    set additional-path-select 4

        config neighbor-group

            edit "Primary_ADVPN"

                set next-hop-self enable

                set next-hop-self-rr enable <--

                set soft-reconfiguration enable

                set remote-as 65400

                set route-reflector-client enable <--

            next

            edit "Secondary_ADVPN"

                set next-hop-self enable

                set next-hop-self-rr enable  <--

                set soft-reconfiguration enable

                set remote-as 65400

                set route-reflector-client enable   <--

            next

        end

        config neighbor-range

            edit 1

                set prefix 10.10.1.0 255.255.255.0

                set neighbor-group "Primary_ADVPN"

            next

            edit 2

                set prefix 10.20.2.0 255.255.255.0

                set neighbor-group "Secondary_ADVPN"

            next

        end

   

SPOKE1:

config router bgp

    set as 65400

    set router-id 5.5.5.5   <--

    set ibgp-multipath enable

    set additional-path enable

    set additional-path-select 4

        config neighbor

            edit "10.10.1.1"

                set soft-reconfiguration enable

                set remote-as 65400

            next

            edit "10.20.2.1"

                set soft-reconfiguration enable

                set remote-as 65400

            next

        end

        config network

            edit 11

                set prefix 172.15.32.0 255.255.255.0

            next

end

 

When prefixes 172.18.117.0/24, 172.18.115.0/24 and 172.18.109.0/24 are advertised from HUB to Spoke1, it is noticeable that routes are not installed into the Spoke1 RIB and the BGP debug shows the following messages:

 

BGP: 10.20.2.1-Outgoing [RIB] Update: Prefix 172.18.117.0/24 path_id 0 denied due to originator is us

 

BGP: 10.20.2.1-Outgoing [RIB] Update: Prefix 172.18.115.0/24 path_id 0 denied due to originator is us

 

BGP: 10.20.2.1-Outgoing [RIB] Update: Prefix 172.18.109.0/24 path_id 0 denied due to originator is us

 

If a packet capture between Spoke1 and Hub device for BGP protocol (TCP 179) is done, on Wireshark it is possible to see the update messages and the attributes for those prefixes:

 

ScreenHunter_86 Oct. 24 15.23.jpg

 

197    10.20.2.1     10.20.2.2     BGP    714 UPDATE Message, UPDATE Message

 

Under the Path attribute, there is the information for ORIGINATOR_ID:

It is possible to see that HUB is reporting the ORIGINATOR_ID as 5.5.5.5, the same router-id that is configured on the Spoke1 device, this is why when Spoke1 sees the NLRI, the prefixes are denied due to ORIGINATOR_ID belongs to Spoke1.

 

Border Gateway Protocol - UPDATE Message.

    Marker: ffffffffffffffffffffffffffffffff

    Length: 556

    Type: UPDATE Message (2)

    Withdrawn Routes Length: 0

    Total Path Attribute Length: 35

    Path attributes

        Path Attribute - ORIGIN: IGP

        Path Attribute - AS_PATH: empty

        Path Attribute - NEXT_HOP: 10.20.2.1

        Path Attribute - LOCAL_PREF: 100

        Path Attribute - ORIGINATOR_ID: 5.5.5.5

        Path Attribute - CLUSTER_LIST: 10.10.1.1

    Network Layer Reachability Information (NLRI)

        172.18.117.0/24

            NLRI prefix length: 24

            NLRI prefix: 172.18.117.0

        172.18.115.0/24

            NLRI prefix length: 24

            NLRI prefix: 172.18.115.0

        172.18.109.0/24

            NLRI prefix length: 24

            NLRI prefix: 172.18.109.0

 

In this specific case, the issue is related to the configuration on the HUB side:

 

config neighbor-group

    edit "Primary_ADVPN"

        set next-hop-self enable

        set next-hop-self-rr enable  <--

    edit "Secondary_ADVPN"

        set next-hop-self enable

        set next-hop-self-rr enable   <--

 

This matches known issue ID# 781483 and appears in v7.2.0 Release Notes. The issue is resolved in FortiOS versions 7.0.14, 7.2.0 and later.


Workarounds:

 

If it is not possible to upgrade, apply one of the below workarounds and soft reset the BGP neighborship.

  • disable 'next-hop-self-rr' under Hub BGP settings.
  • add a unique unused community attribute when advertising routes from Spoke to Hub, using route-map-out.

 

Related articles: