BGP blackhole service

BGP blackhole service

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

Requirements:

  • 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 uwsys.net 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 uwsys.net if you are interested in this service.



  • See https://cms.uwsys.net/communities.html for information on the communities in use
  • Historically connectors peered with r-uwmadison-hub and/or r-uwmilwaukee-hub using 143.235.32.14/32 and 143.235.32.15/32 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 uwsys.net iBGP speakers    
        dsc {
        description ":XFU: BGP blackhole interface";
        unit 0 {
            description ":XFU: BGP blackhole interface";
            family inet {
                address 143.235.32.16/32 {
                    destination 143.235.32.17;
                }
            }
        }
    }

  • 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.
      m7h@r-mx960-lab-re0# show policy-options policy-statement uwsysnet_blackhole
      term uwsysnet_blackhole {
          from {
              protocol bgp;
              community uwsysnet_blackhole;
          }   
              next-hop 143.235.32.17;
              accept;
          }
      }

  • 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 143.235.32.41/32 discard
    set routing-options static route 143.235.32.41/32 community 3128:911

See Also:




Keywords:BGP blackhole service   Doc ID:41936
Owner:Michael H.Group:University of Wisconsin System Network
Created:2014-07-17 11:09 CDTUpdated:2016-09-14 11:35 CDT
Sites:University of Wisconsin System Network
Feedback:  1   0