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.
- Drop traffic destined to a local host on your network based on IP address [v4 or v6]
- 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
- 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.
@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