Juniper keeps a received BGP prefix in hidden state when the BGP next-hop is overwritten to a static route

Question

I have a routing policy named rtbh configured as an ingress policy for a BGP peer:

root@PE3> show configuration policy-options policy-statement rtbh term ipv4 | display inheritance no-comments
from {
    family inet;
    community BLACKHOLE;
    route-filter 0.0.0.0/0 prefix-length-range /32-/32;
}
then {
    local-preference 170;
    origin igp;
    next-hop 192.0.2.1;
    accept;
}

root@PE3>

As seen above, it matches a /32 prefix if it has a specific BGP community attached and then rewrites the next-hop to 192.0.2.1 and accepts the prefix. The route for 192.0.2.1 exists:

root@PE3> show route 192.0.2.1 detail

inet.0: 17 destinations, 18 routes (16 active, 0 holddown, 1 hidden)
192.0.2.1/32 (1 entry, 1 announced)
        *Static Preference: 5
                Next hop type: Discard, Next hop index: 0
                Address: 0xa1de64c
                Next-hop reference count: 2
                State: <Active NoReadvrt Int Ext>
                Local AS: 65005
                Age: 1
                Validation State: unverified
                Task: RT
                Announcement bits (2): 0-KRT 4-Resolve tree 1
                AS path: I

root@PE3>

root@PE3> ...configuration routing-options rib inet.0 | display inheritance no-comments
static {
    route 192.0.2.1/32 {
        discard;
        install;
        no-readvertise;
    }
}
martians {
    192.0.2.1/32 exact allow;
}

root@PE3>

However, when I receive a matching prefix for the rtbh policy, then it stays hidden:

root@PE3> show route receive-protocol bgp 10.94.0.1 extensive hidden

inet.0: 17 destinations, 18 routes (16 active, 0 holddown, 1 hidden)
  203.0.113.1/32 (1 entry, 0 announced)
     Accepted
     Nexthop: 10.94.0.1
     AS path: 65004 I
     Communities: 65005:666

inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

root@PE3>

When I delete the next-hop 192.0.2.1 statement in the rtbh policy, then the 203.0.113.1/32 becomes active. What's causing this behavior?

Answer 1

The problem is lack of accept-remote-nexthop configuration on the BGP neighbor. Junos is applying your ingress policy-statement, then doing a validation check. This probably isn't how it should work but it's a Juniper-ism. The documentation of this "feature" is bad but here's the link.

If you prefer not to configure accept-remote-nexthop an alternate method to implement RTBH is to use a forwarding-table export policy to match RTBH routes (e.g. by community) and rewrite the next-hop to discard upon installing those routes into the FIB.