[c-nsp] Blackholing in MPLS VPNs

[Arie Vayner (avayner)]

Ran,

I just ran it through in my lab.
The trick was to set a route-map on the outgoing BGP session for VPNv4
on the originating PE (the one that generates the Null route).
On this route-map I matched on an ext-community (I guess it could be a
regular one too), and did a set ip next-hop to 192.168.2.1

Then, I have created a static route to 192.168.2.1 on the remote PE both
in the global routing table (or else it does not get imported) and then
also in the VRF (both pointing to Null0)

This is my VRF routing table:

R102#show ip route vrf v1

     200.1.1.0/32 is subnetted, 2 subnets
B       200.1.1.1 [200/0] via 192.168.2.1, 00:03:58
B       200.1.1.2 [200/0] via 1.1.1.2, 00:03:58
     192.168.2.0/32 is subnetted, 1 subnets
S       192.168.2.1 is directly connected, Null0 

Arie

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Arie Vayner
(avayner)
Sent: Saturday, September 20, 2008 19:24 PM
To: ranl at purepeak.com; cisco-nsp
Subject: Re: [c-nsp] Blackholing in MPLS VPNs

Ran,

Did you try adding a community to the prefix, and then try to match on
it and set next hop locally on the PE?
I did not try it, but can try it later in the lab.

Arie 

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Ran Liebermann
Sent: Saturday, September 20, 2008 13:41 PM
To: cisco-nsp
Subject: [c-nsp] Blackholing in MPLS VPNs

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
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/