BGP blackhole service

BGP blackhole service supports the use of a BGP community to trigger destination based blackhole routing.  By tagging routes with our blackhole community, routers will drop traffic destined to networks.  When possible, communities will also be passed on to transit ISP providers that support blackhole routing.


  • A multihop BGP session used exclusively for announcing blackholed hosts will be used.  We have chosen this method for multiple reasons.
  • Upon reception of the blackhole BGP community, we will rewrite the next-hop to a local discard interface.  The most reliable way to do this is with multihop BGP.
  • While we can technically use the same BGP session as your normal prefix announcement session [if applicable], having two sessions means a misconfiguration of the blackhole BGP session is less likely to affect production traffic.  We can also set more appropriate filters and limits on each session separately.
What can this service do?
  • Drop traffic destined to a local host on your network based on IP address [v4 or v6]
What can this service NOT do?
  • While we do support source based loose uRPF drops for discard routes, we do not delegate this ability to connectors as it affects all connectors.
  • Drop traffic destined to your local host, but only for a certain port
Contact engineers via if you are interested in this service.

  • See for information on the communities in use
  • Historically connectors peered with r-uwmadison-hub and/or r-uwmilwaukee-hub using and loopback addresses as the source address of peering for v4, 2600:1d00:0:100::a and 2600:1d00:0:100::b loopback addresses as the source address of peering for v6.  Moving forward it would likely be best to peer with the local PE loopback.
  • The following discard interface is configured on all iBGP speakers    
        dsc {
        description ":XFU: BGP blackhole interface";
        unit 0 {
            description ":XFU: BGP blackhole interface";
            family inet {
                address {

  • For IPv6, a discard route is used as the dsc interface doesn't support inet6

  • The blackholing [v4 and v6] now extends to the mx104 via route reflection.

  • Accepting blackhole announcements from customers: Preceding this term should be a term that matches the customer subnets.
      @r-mx960-lab-re0# show policy-options policy-statement uwsysnet_blackhole
      term uwsysnet_blackhole {
          from {
              protocol bgp;
              community uwsysnet_blackhole;

  • Using static routes to push BGP blackhole from the lab, r-uwmadison-hub-2 or r-uwmilwaukee-hub-2.  In the below example the loopback for r-uweauclaire-hub [v4/v6] is used.
    set routing-options rib inet6.0 static route 2600:1d00:0:100::41/128 discard
    set routing-options rib inet6.0 static route 2600:1d00:0:100::41/128 community 3128:911

    set routing-options static route discard
    set routing-options static route community 3128:911

KeywordsBGP blackhole service   Doc ID41936
OwnerMichael H.GroupUW System Network
Created2014-07-17 11:09 CDTUpdated2021-10-01 08:25 CDT
SitesUniversity of Wisconsin System Network
Feedback  1   0