Cisco Support Community
Community Member

BGP triggered blackholing within MPLS VPN


I have a MPLS L3 VPN setup.

CE1--PE1-----PE2--CE2. The client advertises advertises its routes through BGP to the PE which includes a supernet of PE-CE connected interface. This makes PE1 connected interface IP reachable from CE2. The inbound ACL on the PEs doesnot help as we cannot restrict a valid client subnet.

I am planning to create a BGP triggerd blackhole in the PEs for the other PE connected interface. This way even if a packet from CE2 for PE1-CE1 connecting IP for PE1 enters my network it will be dropped in PE2.

Client Supernet :

PE1-CE1 connecting subnet

PE1 related config:


address-family ipv4 vrf Kiran_Test

neighbor remote-as 12644

neighbor activate

no auto-summary

no synchronization

bgp dampening 1

network mask route-map test_ashish



route-map test_ashish permit 10

set ip next-hop

set community 0:100


ip route vrf Kiran_Test Null0


!this route is used to blackhole the traffic.


I have the same static blackholing route in PE2 also

ip route vrf Kiran_Test Null0


PE2#sh ip route vrf Kiran_Test

Routing Table: Kiran_Test

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is not set is subnetted, 3 subnets

S is directly connected, Null0

B [20/0] via, 16:27:04

B [20/0] via, 16:27:04 is subnetted, 1 subnets

B [20/0] via, 16:27:04 is variably subnetted, 2 subnets, 2 masks

B [200/0] via, 14:04:42

B [200/0] via, 14:17:46


The problem is that the next hop is not changing to in the BGP updates received at PE2. The route-map set in PE1 is working though as I can see the metric I am setting thare is getting reflected in PE2 but the next hop doesnot change.


PE2#sh ip bgp all community 0:100

For address family: IPv4 Unicast

For address family: IPv6 Unicast

For address family: IPv4 Tunnel

For address family: IPv4 MDT

For address family: VPNv4 Unicast

BGP table version is 143798759, local router ID is

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 12641:900012 (default for vrf Kiran_Test)

* i20.1.1.0/30 0 100 0 i

*>i 0 100 0 i

For address family: IPv4 Multicast

For address family: IPv6 Multicast



Is this because of an IBGP update where the nest hop remains unchanged? Can we tweeak it somehow? Please let me know if you have any other solutions on how to make it work.




Re: BGP triggered blackholing within MPLS VPN


In standard BGP, an eBGP speaker advertises externally received routes to all internal neighbors without changing the external next-hop. In this scenario, if you do not want to advertise external link addresses on the inside, you need to use next-hop-self.

In the MPLS/VPN environment things are different. Each PE will advertise by default itself as the next-hop for routes it sends to MP-iBGP neighbors. This is done so that packets can be label switched to a PE that has knowledge of the VPN label (PE is endpoint of LSP for VPN destination). The address used by the PE is the address specified in update-source for the MP-iBGP session with neighbor.

So, I think you are setting the next-hop in the ipv4 vrf BGP address-family before those routes get automatically redistributed into MP-iBGP. When they do, redistribution changes the next-hop from what you had set it, to the local PE address and advertises route to remote PE.

Applying a route-map in the vpnv4 session of PE1 towards PE2 (out direction) for the specific route might fix your issue. If all fails, you could blackhole on PE2 the PE1-CE1 link route with a static route on PE2 for the /30 pointing directly to null0 (although this is not very scalable if you need a solution used often, it could be a temporary quick fix).

Kind Regards,


p.s. Remember to take additional measures (e.g. no-export keyword or other filters) when setting community for blackholing purposes, to avoid blackholing youtube or something (it has happened in the past, it can happen to any good (address-)family). If circumstances allow, you could end up advertising the blackhole route towards CE1 or some other router.

CreatePlease to create content