[j-nsp] Policy to allow customers to null-route traffic at edge

Pedro Roque Marques roque at juniper.net
Fri Aug 29 00:56:19 EDT 2003


bbird at 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 at 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 at puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp


More information about the juniper-nsp mailing list