9

I'm trying to find the most elegant way to implement a RTBH filter for routes received from a customer.

The filter should:

  1. Only accept the customers own prefixes from a prefix-list
  2. Only accept /32 prefixes
  3. Only prefixes with the blackhole community
  4. Set the next-hop to the RTBH next-hop (192.0.2.1)

To begin I looked at the "Configuring Match Conditions in Routing Policy Terms" document from Juniper.

First I thought about combining a prefix-list-filter to only match routes from the customers prefix-list and a route-filter to limit the accepted prefixes to /32, like so:

from {
    as-path customer;
    community blackhole;
    prefix-list-filter customer-prefixes orlonger;
    route-filter 0.0.0.0/0 prefix-length-range /32-/32;
}

But then I stumbled about this information in the document:

If you configure a policy that includes some combination of route filters, prefix lists, and source address filters, they are evaluated according to a logical OR operation or a longest-route match lookup.

As I understand this (and I find it a bit unclear), if I use prefix-list-filter, route-filter and/or source-address-filter in the same term it would be evaluated with a longest-match OR between all of them, which makes this approach unusable.

What I came up with is this the following filter. The hostroutes-only term diverts all prefixes shorter than /32 to the next policy. After that the prefixes term matches if the /32 is in the range of the customer, matches his as-path and has the blackhole community set:

term hostroutes-only {
    from {
        route-filter 0.0.0.0/0 prefix-length-range /0-/31;
    }
    then next policy;
}
term prefixes {
    from {
        as-path customer;
        community blackhole;
        prefix-list-filter customer-prefixes orlonger;
    }
    then {
        next-hop 192.0.2.1;
        accept;
    }
}

So, is this the most elegant way to handle this? Any other solutions?

8

There is no reason to limit customer to blackhole only /32, allow them to blackhole anything from them.

Something like this:

policy-statement AS42-IN {
    term blackhole {
        from {
            community BLACKHOLE;
            prefix-list-filter AS42 orlonger;
        }
        then {
            community add NO-EXPORT;
            next-hop 192.0.2.1;
            accept;
        }
    }
    term advertise {
        from {
            prefix-list AS42;
        }
        then {
            community add ADVERTISE;
            next-hop peer-address;
            accept;
        }
    }
    term reject {
        then reject;
    }
}

Remember to set 'accept-remote-nexthop' under BGP settings, so that the next-hop can be changed to something else than link address.

I also strongly support that providers start to support different blackhole communities than just 'full blackhole'. Especially if you operate in more than one country usually attack is from transit and often customer actually mostly wants to access domestic peerings, so it's useful to implement several levels of blackhhole:

  1. Full
  2. Outside local country (local IXP, whole own AS + customers seen)
  3. Outside local area (if applicable, like for me it could be 'Nordics')
  4. Include/Exclude specific peering router in blackhole

I'm happy to give example how to implement something like this with JNPR DCU/SCU, provided your peering routers are JNPR, but it's possible with just communities, just bit more awkward.


If you absolutely want to limit your customer's options you can add this:

policy-statement /32 {
    term /32 {
        from {
            route-filter 0.0.0.0/0 prefix-length-range /32-/32;
        }
        then accept;
    }
    term reject {
        then reject;
    }
}

policy-statement AS42-IN {
    term blackhole {
        from {
            community BLACKHOLE;
            policy /32;
            prefix-list-filter AS42 orlonger;
        }
..
}

This way it should be logical AND. But I really don't see the value in creating complexity to reduce expressiveness of configuration.

  • Thank you for your answer. I don't want customers to blackhole larger portions of their space because mostly they're shooting themselves in the foot with it. Regarding 'accept-remote-nexthop', I change the next-hop on our side in the policy filter so I don't need to enable it on the session. – Sebastian Wiesinger Jun 12 '13 at 9:50
  • We're not "punishing" anyone. If they want to blacklist larger prefixes they certainly can ask for it. In the last few years no one asked for it. – Sebastian Wiesinger Jun 12 '13 at 10:57
  • You're seeing additional trouble, adding complexity, to reduce expressiveness. If you've never offered this, how do you know your customers would accidentally add blackhole community to larger nets than /32? Coincidentally when ever we ask feature from vendors, they reply 'no one has ever asked for it' and when you talk to the community, you'll find many people in want for such feature. Anyhow I added suggestion on how to implement this limit. – ytti Jun 12 '13 at 11:00
  • I realized that in your example, you don't accept the prefixes at all without blackholing. So you're probably having two peerings, one for normal traffic and one for blackholing, and the blackholing likely is multihop in your case, in multihop the next-hop checking is already turned off, so you don't need 'accept-remote-nexthop'. My example covers both BGP peerings in same config, and as it is direct PE<->CE without multihop, it needs 'accept-remote-nexthop'. – ytti Jun 12 '13 at 11:13
  • Yes that's true, you need it on direct sessions. The filter should work in both situations, you would chain it up with other filtering policies behind it in the PE<->CE scenario. – Sebastian Wiesinger Jun 12 '13 at 11:57

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.