[c-nsp] Blackholing in MPLS VPNs

Sun Sep 21 03:14:41 EDT 2008

Ran,

I would assume that the next-hop has to be available through the global
routing table, as with any other regular L3 VPN router, as the next-hop
is the loopback of the originating PE. If its not reachable, the route
is not being imported into the VRF.

Arie 

-----Original Message-----
From: Ran Liebermann [mailto:ranmails at gmail.com] 
Sent: Saturday, September 20, 2008 23:35 PM
To: Arie Vayner (avayner)
Cc: cisco-nsp
Subject: Re: [c-nsp] Blackholing in MPLS VPNs

Seems good.
I'll try this in my deployment.

You know why it's required to make the static route in the receiving
router both in the vrf and the global table? Seems a bit odd...
Also, I noticed that the announcing router always has this prefix with
the 0x820 flag set on, even after a while when all announcements should
have been stabalized.

Thanks,
--
Ran.

On Sat, Sep 20, 2008 at 10:18 PM, Arie Vayner (avayner)
<avayner at cisco.com> wrote:
> 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/
> _______________________________________________
> 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/
>

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