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:
- Full
- Outside local country (local IXP, whole own AS + customers seen)
- Outside local area (if applicable, like for me it could be 'Nordics')
- 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.
- Do you need a "from" clause in a policy-statement?
No. You don't. Without a "from" class everything will match.
- Can you pre-pend your own AS on advertisements in JUNOS to eBGP peers?
Yes, of course you can, that's the typical way in which AS prepending is being done.
So the real question is: why doesn't this work? One thing which I'm not sure about is the to protocol bgp
statement, I've never used that in policies for prepending. The best thing to do is verify if you're actually prepending by checking what you're advertising: show route advertising-protocol bgp aaa.bbb.ccc.ddd detail
, where aaa.bbb.ccc.ddd
is the peer IP.
Best Answer
set
replaces the current communities on a route with the specified community, whileadd
adds the specified community to any communities already present on that route.