Source-Based Black Holing in a VRF

Unanswered Question
Aug 27th, 2009


I am trying to setup Remote Triggered SBBH in a VRF, but it does not seem to be working.

I have the trigger router in a VRF connected to a PE (EBGP), but no matter what I configure on the PE, the next-hop is "inaccessible" for routes advertised by trigger. When I remove the VRF it is fine.

With as my discard route, I have tried on the PE:

ip route null 0

route-map FROM-TRIGGER

set ip next-hop

And I have tried:

ip route vrf INTERNET null 0

route-map FROM-TRIGGER

set ip vrf INTERNET next-hop

As well as combinations of the 2 above.

Is this configuration supported in a VRF?

thank you,


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Giuseppe Larosa Thu, 08/27/2009 - 22:43

Hello Bryan,

in MPLS VPN the BGP next-hop used in VPNv4 advertisements has to belong to the global table.

So first formulation should be correct.

You need to advertise in your IGP (OSPF or others) the next-hop ip address using a redistribute static.

if the next-hop is known in GRT you should see the vpnv4 prefixes with modified next-hop accepted on the other PE nodes.

Hope to help


dodgerfan78 Fri, 08/28/2009 - 06:13

Hi Giuseppe, thank you for the reply. For brevity I will show you what I have for the Trigger and the PE router. I have the next-hop set to and the null route is in the Global table.

TRIGGER = (s1/0)

PE1 = (s1/1)



interface Serial1/0

description to PE1

ip address


router bgp 65086

no synchronization

bgp log-neighbor-changes

redistribute static

neighbor remote-as 65000

neighbor description PE1

neighbor remote-as 65000

neighbor description PE2

no auto-summary


ip route Null0




rd 100:1

route-target export 100:1

route-target import 100:1


interface Loopback0

ip address


interface Serial1/1

description TRIGGER

ip vrf forwarding INTERNET

ip address


router bgp 65100

no bgp default ipv4-unicast

bgp log-neighbor-changes

bgp confederation identifier 65000

bgp confederation peers 65200

neighbor description RR

neighbor remote-as 65100

neighbor update-source Loopback0


address-family vpnv4

neighbor activate

neighbor send-community extended



address-family ipv4 vrf INTERNET

neighbor remote-as 65086

neighbor activate

neighbor route-map SBBH in

no synchronization



ip route Null0


ip bgp-community new-format


route-map SBBH permit 10

set local-preference 250

set ip next-hop

With this config, PE1 accepts the route to from Trigger and sets the next-hop to, however, this is what I get:

PE1#sho ip bgp vpnv4 all

BGP routing table entry for 100:1:, version 24

Paths: (1 available, no best path)

Flag: 0x820

Not advertised to any peer

65086 (inaccessible) from (

Origin incomplete, metric 0, localpref 250, valid, external

Extended Community: RT:100:1



Giuseppe Larosa Fri, 08/28/2009 - 06:34

Hello Bryan,

I think that PE1 should receive a route with next-hop and trigger should advertise a network with next-hop should be advertised in IGP.

PE1 has a route to null0 for and so when BGP checks if BGP next-hop is reachable it detects the problem.

have a look at

Hope to help


dodgerfan78 Fri, 08/28/2009 - 06:41

But for source-based black holing to work you need to have the next-hop recursively point to NULL so the RPF check fails. is the route I am trying to black hole. When PE1 receives traffic from and performs an RPF check (on the other interfaces, namely the one connected to the ISP), PE1 should recursively see the next-hop as This route points to NULL which is an invalid interface for RPF check and PE1 then drops the traffic.

This works without the VRFs. That's why I am wondering if it is supported in VRFs.

Giuseppe Larosa Fri, 08/28/2009 - 06:47

Hello Bryan,

sorry for my misunderstanding I was thinking of RTBH.

We can guess that MP BGP makes additional checks because the next hop is in GRT.

you are probably right and this feature is not working well with VPN traffic or some additional tricks are needed.

Hope to help


dodgerfan78 Fri, 08/28/2009 - 06:52

That's why I thought the "set ip vrf next-hop" would work, but it didn't :/

I have got it to work by peering trigger with the routers downstream of the PE (multihop EBGP)...the Internet border routers ("CE"), so this may be the way I have to go.

Thanks for your time!

dodgerfan78 Fri, 08/28/2009 - 14:25

Think I figured it out. Instead of setting next-hop inbound from trigger. I set it outbound from the PE towards the RR. Then I have the global null route on all PE's and the RR and the triggered route is now accepted.

Giuseppe Larosa Sat, 08/29/2009 - 03:27

Hello Bryan,

nice to hear you have found the right tricks.

so the PE is setting the special next-hop towards RRserver that propagates this to all other PE nodes.

each node has a local static route to null0 for the special next-hop.

It might be interesting if you could post the working configuration that could help other people interested in the same feature.

I took part in some testing on Cisco Guard in that case all nodes send the traffic to a special PE node that diverts traffic to the Cisco guard that acts like a washer trying to "clean" the traffic.

So the special next-hop was advertised in OSPF and traffic was diverted to Cisco guard.

in this case you are discarding traffic locally on each node if I have understood correctly.

Best Regards


Marwan ALshawi Sun, 08/30/2009 - 05:26

in the show ip bgp

the route shown not accessable by other bgp peers becuase your static route is global and the route-map applied under a VRF

u had to make your null route like:

ip route vrf INTERNET x.x.x.x y.y.y.y null0


This Discussion