Howto for BGP black holing/null routing
I was wondering if anyone has a howto floating around on the step by step setup of having an internal bgp peer for sending quick updates to border routers to null route sources of undesirable traffic? I've seen it discussed on nanog from time to time, typically suggesting using Zebra, but could not search up a link on a step by step. Thanks, David
On 2011-02-22 22:42, David Hubbard wrote:
I was wondering if anyone has a howto floating around on the step by step setup of having an internal bgp peer for sending quick updates to border routers to null route sources of undesirable traffic? I've seen it discussed on nanog from time to time, typically suggesting using Zebra, but could not search up a link on a step by step.
Take a look here for starters: http://www.cisco.com/web/about/security/intelligence/blackhole.pdf Searching through NANOG archives will return a couple of sessions that went through the other vendor configs for such functionality. -- "There's no sense in being precise when | Łukasz Bromirski you don't know what you're talking | jid:lbromirski@jabber.org about." John von Neumann | http://lukasz.bromirski.net
Also: http://docs.as701.net/tmp/CustomerBlackhole.txt Remember to set eBGP multihop on sessions for the next-hop rewrite capability :) - Jared On Feb 22, 2011, at 4:54 PM, Łukasz Bromirski wrote:
On 2011-02-22 22:42, David Hubbard wrote:
I was wondering if anyone has a howto floating around on the step by step setup of having an internal bgp peer for sending quick updates to border routers to null route sources of undesirable traffic? I've seen it discussed on nanog from time to time, typically suggesting using Zebra, but could not search up a link on a step by step.
Take a look here for starters: http://www.cisco.com/web/about/security/intelligence/blackhole.pdf
Searching through NANOG archives will return a couple of sessions that went through the other vendor configs for such functionality.
-- "There's no sense in being precise when | Łukasz Bromirski you don't know what you're talking | jid:lbromirski@jabber.org about." John von Neumann | http://lukasz.bromirski.net
2011/2/22 Jared Mauch <jared@puck.nether.net>:
Also:
http://docs.as701.net/tmp/CustomerBlackhole.txt
Remember to set eBGP multihop on sessions for the next-hop rewrite capability :)
oh hey, I was looking for that! :) (I'll try to re-setup the www.secsup.org links tonight) ... this is a 'how to setup so a customer can blackhole', which you should be able to easily hack to 'make my quagga server a customer, make him be able to blackhole all of 0/0 by /32s' keep in mind also that somethings do not react well to k's of /32's ...
- Jared
On Feb 22, 2011, at 4:54 PM, Łukasz Bromirski wrote:
On 2011-02-22 22:42, David Hubbard wrote:
I was wondering if anyone has a howto floating around on the step by step setup of having an internal bgp peer for sending quick updates to border routers to null route sources of undesirable traffic? I've seen it discussed on nanog from time to time, typically suggesting using Zebra, but could not search up a link on a step by step.
Take a look here for starters: http://www.cisco.com/web/about/security/intelligence/blackhole.pdf
Searching through NANOG archives will return a couple of sessions that went through the other vendor configs for such functionality.
-- "There's no sense in being precise when | Łukasz Bromirski you don't know what you're talking | jid:lbromirski@jabber.org about." John von Neumann | http://lukasz.bromirski.net
Maybe I read your question wrong, but null-routing things at your border is often not very useful if the traffic is flooding your transit links. Most transits publish their community lists - you just need to tag the prefix you want to blackhole with the right community. See example from HE: http://www.he.net/adm/blackhole.html <http://www.he.net/adm/blackhole.html>-Jack Carrozzo On Tue, Feb 22, 2011 at 4:42 PM, David Hubbard < dhubbard@dino.hostasaurus.com> wrote:
I was wondering if anyone has a howto floating around on the step by step setup of having an internal bgp peer for sending quick updates to border routers to null route sources of undesirable traffic? I've seen it discussed on nanog from time to time, typically suggesting using Zebra, but could not search up a link on a step by step.
Thanks,
David
On Tue, Feb 22, 2011 at 4:55 PM, Jack Carrozzo <jack@crepinc.com> wrote:
Maybe I read your question wrong, but null-routing things at your border is often not very useful if the traffic is flooding your transit links. Most transits publish their community lists - you just need to tag the prefix you want to blackhole with the right community.
This is certainly true. Although most "big transit networks" offer this feature today, there are some important differences in what some of them will and won't accept. Some will only learn /32s, some say they'll accept /30-/32 but nothing shorter, some will honor anything you send them. This may be undocumented. Some networks seem to have forgotten about this feature when implementing IPv6, even though it is offered for IPv4. I don't see any value in not accepting a RTBH /24 but accepting a /30. I also don't know of any platform issues which would make deploying RTBH for IPv6 BGP customers any more difficult than doing so for IPv4. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
On Feb 23, 2011, at 5:42 AM, David Hubbard wrote:
I've seen it discussed on nanog from time to time, typically suggesting using Zebra, but could not search up a link on a step by step.
<https://files.me.com/roland.dobbins/dweagy> ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> The basis of optimism is sheer terror. -- Oscar Wilde
I can't give you a step-by-step with configuration examples off the top of my head, but, hopefully this helps: 1. Create a static anchor route to a magic "next-hop" value such as 192.168.99.99 or whatever you choose. 2. Configure all your routers to route 192.168.99.99 to null. 3. Advertise that into your iBGP mesh from the blackhole anchor router. Owen On Feb 22, 2011, at 1:42 PM, David Hubbard wrote:
I was wondering if anyone has a howto floating around on the step by step setup of having an internal bgp peer for sending quick updates to border routers to null route sources of undesirable traffic? I've seen it discussed on nanog from time to time, typically suggesting using Zebra, but could not search up a link on a step by step.
Thanks,
David
On Tue, 22 Feb 2011, David Hubbard wrote:
I was wondering if anyone has a howto floating around on the step by step setup of having an internal bgp peer for sending quick updates to border routers to null route sources of undesirable traffic? I've seen it discussed on nanog from time to time, typically suggesting using Zebra, but could not search up a link on a step by step.
I actually did a blog entry just a couple weeks ago about this with relatively step by step [cisco] instructions. http://jonsblog.lewis.org/2011/02/05#blackhole I'm curious what others think of the setup. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Tue, 22 Feb 2011 16:42:28 -0500, David Hubbard wrote
I was wondering if anyone has a howto floating around on the step by step setup of having an internal bgp peer for sending quick updates to border routers to null route sources of undesirable traffic? I've seen it discussed on nanog from time to time, typically suggesting using Zebra, but could not search up a link on a step by step.
Ultimately it depends on the transit provider. For example, some have you set up a separate BGP session with a black hole router. Any prefix sent will be blackholed network wide. Some, such as the case of Level3, they are looking for specific community tags on your primary BGP session. So in a nutshell...lets blackhole a host: ip route x.x.x.x 255.255.255.255 null0 tag 255 Then set up a static-to-bgp with route-map to add community strings (for example 3356:9999 for level3) to your routes with tag 255. route-map STATIC-TO-BGP permit 10 match tag 255 set community 3356:9999 set origin igp And in your BGP config: redistribute static route-map STATIC-TO-BGP Now, for the case of level3, you're already set (just be sure to apply send-community on the neighbor). Now for a provider having a unique blackhole BGP session, you want a special route-map to filter prefixes going out that session: ip community-list BLACKHOLE seq 10 permit 3356:9999 route-map BLACKHOLE permit 10 match community BLACKHOLE Now for the blackhole session: neighbor <blackhole_peer> route-map out BLACKHOLE It can get more complicated than this (for example, you've got more than one EBGP router) but this is just a simple case. I hope it helps... ~Randy
Team Cymru has some really good examples on how to configure something similar (utilizing their BOGON feed). http://www.team-cymru.org/Services/Bogons/bgp.html Scroll down to "AUTOMATICALLY FILTERING BOGONS" for IOS, JUNOS, etc examples On Tue, Feb 22, 2011 at 4:42 PM, David Hubbard < dhubbard@dino.hostasaurus.com> wrote:
I was wondering if anyone has a howto floating around on the step by step setup of having an internal bgp peer for sending quick updates to border routers to null route sources of undesirable traffic? I've seen it discussed on nanog from time to time, typically suggesting using Zebra, but could not search up a link on a step by step.
Thanks,
David
On 2/22/11 1:42 PM, David Hubbard wrote:
I was wondering if anyone has a howto floating around on the step by step setup of having an internal bgp peer for sending quick updates to border routers to null route sources of undesirable traffic? I've seen it discussed on nanog from time to time, typically suggesting using Zebra, but could not search up a link on a step by step.
Thanks,
I'd include: https://tools.ietf.org/html/rfc5635 in your list of reading materials.
David
participants (12)
-
Christopher Morrow -
David Hubbard -
Dobbins, Roland -
Jack Carrozzo -
Jared Mauch -
Jeff Wheeler -
Joel Jaeggli -
Jon Lewis -
Owen DeLong -
Rafael Rodriguez -
Randy McAnally -
Łukasz Bromirski