[c-nsp] Blackholing in MPLS VPNs

[Ran Liebermann]

Hi All,

Common blackholing mechanisms (such as RFC 3882) rely on the next-hop
attribute of BGP, such that the next-hop of the announced prefix will
remain the same as the static route even through the BGP prefix is
locally originated via the redistribute command. This of course works
well when the mechanism is operating in the global routing table of
the routers.

However when trying to operate the mechanism in an MPLS VPN (for
example a VPN for internet traffic instead of the global routing
table), then the mechanism breaks down becuase the prefixes are
announced with the next-hop as the local router. (output examples at
the end of the email).

Does anyone have a nice and elegant solution to this?

Thanks,
--
Ran.



For example here is the view of the prefix in the announcing router:

ANNOUNCING_ROUTER#show ip bgp vpnv4 vrf INTERNET 2.2.2.2
BGP routing table entry for 64512:100:2.2.2.2/32, version 153
Paths: (1 available, best #1, table INTERNET)
Flag: 0x820
  Advertised to update-groups:
     1
  Local
    192.168.255.255 from 0.0.0.0 (172.17.17.1)
      Origin IGP, metric 0, localpref 50, weight 32768, valid, sourced, best
      Community: 64512:65535
      Extended Community: RT:64512:100
      mpls labels in/out 33/nolabel

And here is the view of the prefix in the receiving router:

RECEIVING_ROUTER#show ip bgp vpnv4 vrf INTERNET 2.2.2.2
BGP routing table entry for 64512:100:2.2.2.2/32, version 24
Paths: (1 available, best #1, table INTERNET)
Flag: 0x820
  Not advertised to any peer
  Local
    172.17.17.1 (metric 20) from 172.17.17.1 (172.17.17.1)
      Origin IGP, metric 0, localpref 50, valid, internal, best
      Community: 64512:65535
      Extended Community: RT:64512:100
      mpls labels in/out nolabel/33


--
Ran Liebermann,
VP Engineering, PurePeak
ranl at purepeak.com
http://purepeak.com