Source-Based Black Holing in a VRF

Unanswered Question
Aug 27th, 2009

Hello,

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 172.31.254.254 as my discard route, I have tried on the PE:

ip route 172.31.254.254 255.255.255.255 null 0

route-map FROM-TRIGGER

set ip next-hop 172.31.254.254

And I have tried:

ip route vrf INTERNET 172.31.254.254 255.255.255.255 null 0

route-map FROM-TRIGGER

set ip vrf INTERNET next-hop 172.31.254.254

As well as combinations of the 2 above.

Is this configuration supported in a VRF?

thank you,

Bryan

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
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

Giuseppe

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 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,

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

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

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.

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.

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

Giuseppe

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

Giuseppe

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

Actions

This Discussion