3

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?

4

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.