[j-nsp] Setting RTBH next-hop at RR for L3VPN routes

[OBrien, Will]

Tag your discard and use the tag to set a community. Then the community can be used to take the desired action.

Will O'Brien

> On Feb 8, 2014, at 1:17 PM, "Phil Mayers" <p.mayers at imperial.ac.uk> wrote:
> 
> All,
> 
> We're wanting to deploy RTBH, and I'm running into issues because when the route is injected into an L3VPN, the next hop is set to the advertising PE, not the RTBH "discard" next-hop.
> 
> I figure I can change this with a route-map on the other PEs facing the RR, but that seems clumsy, so I tried to set it on the RRs instead using a policy like so:
> 
> [edit routing-options]
> +   rib inet.0 {
> +       static {
> +           route 192.0.2.1/32 {
> +               discard;
> +               no-readvertise;
> +           }
> +       }
> +   }
> [edit protocols bgp group RR-client]
> +    export BGP-rr-out;
> [edit policy-options]
> +   policy-statement BGP-rr-out {
> +       term t1 {
> +           from community RTBH;
> +           then {
> +               next-hop 192.0.2.1;
> +               accept;
> +           }
> +       }
> +       term t2 {
> +           then accept;
> +       }
> +   }
> [edit policy-options]
> +   community RTBH members 64580:666;
> 
> ...however the routes are not being advertised to the RR clients, reporting:
> 
> * 192.168.0.0:1:x.x.x.x/32 (2 entries, 1 announced)
> BGP group RR-client type Internal
>     Route Distinguisher: 192.168.0.0:1
>     BGP label allocation failure: protocols mpls not enabled on interface
>     Nexthop: Not advertised
>     Flags: Nexthop Change
>     MED: 0
>     Localpref: 100
>     ...
> 
> I'm assuming that what's happening here is the JunOS RR is trying to allocate a label to put into the inet-vpn update, but can't. Is there any way I can force this to happen? The actual label doesn't matter I guess, since the RTBH next-hop will be routed to null0/discard on all the RR clients.
> 
> Note that the RR doesn't have routing-instance statements for the L3VPN; it's just reflecting inet-vpn. Presumably if I did define the routing-instances, and if I put the discard route in each instance, it would work but that again seems clumsy. Maybe I'm just being too choosy ;o)
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp