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 172.31.254.254 and the null route is in the Global table.

TRIGGER = 192.168.2.2 (s1/0)

PE1 = 192.168.2.1 (s1/1)

TRIGGER

-------

interface Serial1/0

description to PE1

ip address 192.168.2.2 255.255.255.0

!

router bgp 65086

no synchronization

bgp log-neighbor-changes

redistribute static

neighbor 192.168.2.1 remote-as 65000

neighbor 192.168.2.1 description PE1

neighbor 192.168.4.1 remote-as 65000

neighbor 192.168.4.1 description PE2

no auto-summary

!

ip route 12.12.12.12 255.255.255.255 Null0

PE1

---

ip vrf INTERNET

rd 100:1

route-target export 100:1

route-target import 100:1

!

interface Loopback0

ip address 10.1.1.1 255.255.255.255

!

interface Serial1/1

description TRIGGER

ip vrf forwarding INTERNET

ip address 192.168.2.1 255.255.255.0

!

router bgp 65100

no bgp default ipv4-unicast

bgp log-neighbor-changes

bgp confederation identifier 65000

bgp confederation peers 65200

neighbor 10.1.3.3 description RR

neighbor 10.1.3.3 remote-as 65100

neighbor 10.1.3.3 update-source Loopback0

!

address-family vpnv4

neighbor 10.1.3.3 activate

neighbor 10.1.3.3 send-community extended

exit-address-family

!

address-family ipv4 vrf INTERNET

neighbor 192.168.2.2 remote-as 65086

neighbor 192.168.2.2 activate

neighbor 192.168.2.2 route-map SBBH in

no synchronization

exit-address-family

!

ip route 172.31.254.254 255.255.255.255 Null0

!

ip bgp-community new-format

!

route-map SBBH permit 10

set local-preference 250

set ip next-hop 172.31.254.254

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

PE1#sho ip bgp vpnv4 all 12.12.12.12

BGP routing table entry for 100:1:12.12.12.12/32, version 24

Paths: (1 available, no best path)

Flag: 0x820

Not advertised to any peer

65086

172.31.254.254 (inaccessible) from 192.168.2.2 (192.168.4.2)

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

Extended Community: RT:100:1

PE1#

Thanks,

Hello Bryan,

I think that PE1 should receive a route with next-hop 12.12.12.12 and trigger should advertise a network with next-hop 12.12.12.12

12.12.12.12/32 should be advertised in IGP.

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

have a look at

http://www.arbornetworks.com/index.php?option=com_docman&task=doc_download&gid=112

Hope to help

Giuseppe

But for source-based black holing to work you need to have the next-hop recursively point to NULL so the RPF check fails.

12.12.12.12 is the route I am trying to black hole. When PE1 receives traffic from 12.12.12.12 and performs an RPF check (on the other interfaces, namely the one connected to the ISP), PE1 should recursively see the next-hop as 172.31.254.254. 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.

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

Giuseppe

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!

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.

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

Giuseppe

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