Mailing List Archive: Policy to allow customers to null-route traffic at edge

Policy to allow customers to null-route traffic at edge

Aug 28, 2003, 7:24 PM

Post #1 of 3 (1324 views)

All,

Can someone point out the flaw in my configuration/concept (or both) please?
Some specifics have been changed or obfuscated.

I have a policy set up allowing customer-peers to tag a specific bgp
community-id (19962:911) to a route, thus causing me to black-hole the
traffic at my edge. This is obviously an attempt to keep the DOS traffic
off of the customers link, without need for my involvement.

My edge router isn't accepting the route due to an 'Unusable' next hop. I'm
attempting to do this in a recursive manner, as Juniper policy doesn't allow
me to change the next-hop to discard. Because the next-hop is 'Unusable',
the route remains inactive, and therefore the traffic still transits to the
customer, because of the less-specific the customer is also exporting to me.

Obviously, the policy-statement "<$customer-as>-routes" is applied as an
import policy facing the customer. Configuration from my edge-router,
connected to customer-peer:

static {
route 192.168.255.254/32 {
discard;
install;
}

policy-statement <$customer-as>-routes {
term prefix-list-blackhole {
from {
protocol bgp;
community customer-blackhole;
route-filter <customer-route>/19 upto /32;
}
then {
community add no-export;
next-hop 192.168.255.254;
next policy;
accept;
}
}
}

community customer-blackhole members "^19962:911$";

-------------------

user@router> show route community 19962:911 hidden extensive

inet.0: 123327 destinations, 123343 routes (123318 active, 2 holddown, 8
hidden)
<customer-route/24> (1 entry, 0 announced)
BGP /-501
Next hop type: Unusable
State: <Hidden Ext>
Local AS: 65001 Peer AS: <$customer-as>
Age: 1:42:56 Metric: 0
Task: BGP_<$customer-as>.<$customer-peer-ip>+1255
AS path: <$customer-as> <$customer-as> ?
Communities: 19962:911 19962:1004 19962:65001 no-export
Localpref: 500
Router ID: <$customer-rtr-id>
Merit (last update/now): 787/274
damping-parameters: damp-long
Last update: 00:45:37 First update: 01:46:51
Flaps: 3
History entry. Expires in: 00:13:40
<snip>

Sincerely,
-Ben Bird

Policy to allow customers to null-route traffic at edge [ In reply to ]

roque at juniper

Aug 28, 2003, 7:56 PM

Post #2 of 3 (1307 views)

Permalink

bbird@epik.net writes:

> All,
>
> Can someone point out the flaw in my configuration/concept (or both) please?
> Some specifics have been changed or obfuscated.

The policy that you post will work on an iBGP session. On an eBGP
session, unless 'multihop' is set, junos refuses to use a nexthop that
is not on link, and considers the route to be unreachable.

The idea being that on non-multihop eBGP peerings, nexthops must be on
link and that route resolution (even via static discard) is not
allowed.

On the peering session torwards your peer just don't attempt to change
the nexthop, propagate...

Then at the ingress to your network, where the route is received via
iBGP you can easily change the nexthop into never-never land (or to a
logging server farm of lost and doomed packets).

What you can also look into is to use the community to mark traffic w/
destination class and then use that as the key to policers.

Now, if i'm allowed to peddle my wares...

Would you ever be interest in allowing you peers to specify most
specific flow descriptions than destination addresses as described in:
ftp://ftp.ietf.org/internet-drafts/draft-marques-idr-flow-spec-00.txt

cheers,
Pedro.

> I have a policy set up allowing customer-peers to tag a specific bgp
> community-id (19962:911) to a route, thus causing me to black-hole the
> traffic at my edge. This is obviously an attempt to keep the DOS traffic
> off of the customers link, without need for my involvement.
>
> My edge router isn't accepting the route due to an 'Unusable' next hop. I'm
> attempting to do this in a recursive manner, as Juniper policy doesn't allow
> me to change the next-hop to discard. Because the next-hop is 'Unusable',
> the route remains inactive, and therefore the traffic still transits to the
> customer, because of the less-specific the customer is also exporting to me.
>
> Obviously, the policy-statement "<$customer-as>-routes" is applied as an
> import policy facing the customer. Configuration from my edge-router,
> connected to customer-peer:
>
>
> static {
> route 192.168.255.254/32 {
> discard;
> install;
> }
>
> policy-statement <$customer-as>-routes {
> term prefix-list-blackhole {
> from {
> protocol bgp;
> community customer-blackhole;
> route-filter <customer-route>/19 upto /32;
> }
> then {
> community add no-export;
> next-hop 192.168.255.254;
> next policy;
> accept;
> }
> }
> }
>
> community customer-blackhole members "^19962:911$";
>
>
> -------------------
>
> user@router> show route community 19962:911 hidden extensive
>
> inet.0: 123327 destinations, 123343 routes (123318 active, 2 holddown, 8
> hidden)
> <customer-route/24> (1 entry, 0 announced)
> BGP /-501
> Next hop type: Unusable
> State: <Hidden Ext>
> Local AS: 65001 Peer AS: <$customer-as>
> Age: 1:42:56 Metric: 0
> Task: BGP_<$customer-as>.<$customer-peer-ip>+1255
> AS path: <$customer-as> <$customer-as> ?
> Communities: 19962:911 19962:1004 19962:65001 no-export
> Localpref: 500
> Router ID: <$customer-rtr-id>
> Merit (last update/now): 787/274
> damping-parameters: damp-long
> Last update: 00:45:37 First update: 01:46:51
> Flaps: 3
> History entry. Expires in: 00:13:40
> <snip>
>
> Sincerely,
> -Ben Bird
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp

Policy to allow customers to null-route traffic at edge [ In reply to ]

avram at juniper

Sep 2, 2003, 10:26 PM

Post #3 of 3 (1319 views)

Permalink

Hey Ben,

This should work fine with multi-hop as was previously stated.

Starting with 5.6, you can actually configure a discard interface:

http://www.juniper.net/techpubs/software/junos/junos56/swconfig56-
interfaces/html/interfaces-discard-config.html#1014275

dsc {
unit 0 {
family inet {
address 10.10.10.1/32 {
destination 10.10.10.2;
}
}
}
}

dsc's are point-to-point, so then use an identical policy, but set the
next-hop to the p2p destination of the dsc interface.

policy-statement DoS_Policy {
term 1 {
from {
protocol bgp; community DoS_Comm;
}
then {
next-hop 10.10.10.2; accept;
}
}
}

It's the same thing, but now you can actually still count statistics on
the traffic you are discarding, with a firewall filter, by applying it
as an output filter on the dsc.

HTH,
Avram

On Thursday, August 28, 2003, at 07:22 PM, bbird@epik.net wrote:

> All,
>
> Can someone point out the flaw in my configuration/concept (or both)
> please?
> Some specifics have been changed or obfuscated.
>
> I have a policy set up allowing customer-peers to tag a specific bgp
> community-id (19962:911) to a route, thus causing me to black-hole the
> traffic at my edge. This is obviously an attempt to keep the DOS
> traffic
> off of the customers link, without need for my involvement.
>
> My edge router isn't accepting the route due to an 'Unusable' next
> hop. I'm
> attempting to do this in a recursive manner, as Juniper policy doesn't
> allow
> me to change the next-hop to discard. Because the next-hop is
> 'Unusable',
> the route remains inactive, and therefore the traffic still transits
> to the
> customer, because of the less-specific the customer is also exporting
> to me.
>
> Obviously, the policy-statement "<$customer-as>-routes" is applied as
> an
> import policy facing the customer. Configuration from my edge-router,
> connected to customer-peer:
>
>
> static {
> route 192.168.255.254/32 {
> discard;
> install;
> }
>
> policy-statement <$customer-as>-routes {
> term prefix-list-blackhole {
> from {
> protocol bgp;
> community customer-blackhole;
> route-filter <customer-route>/19 upto /32;
> }
> then {
> community add no-export;
> next-hop 192.168.255.254;
> next policy;
> accept;
> }
> }
> }
>
> community customer-blackhole members "^19962:911$";
>
>
> -------------------
>
> user@router> show route community 19962:911 hidden extensive
>
> inet.0: 123327 destinations, 123343 routes (123318 active, 2 holddown,
> 8
> hidden)
> <customer-route/24> (1 entry, 0 announced)
> BGP /-501
> Next hop type: Unusable
> State: <Hidden Ext>
> Local AS: 65001 Peer AS: <$customer-as>
> Age: 1:42:56 Metric: 0
> Task: BGP_<$customer-as>.<$customer-peer-ip>+1255
> AS path: <$customer-as> <$customer-as> ?
> Communities: 19962:911 19962:1004 19962:65001 no-export
> Localpref: 500
> Router ID: <$customer-rtr-id>
> Merit (last update/now): 787/274
> damping-parameters: damp-long
> Last update: 00:45:37 First update:
> 01:46:51
> Flaps: 3
> History entry. Expires in: 00:13:40
> <snip>
>
> Sincerely,
> -Ben Bird
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp