MAPS RBL BGP Feed Configuration FAQ for Cisco Routers


About This Document

This document is a tutorial intended to help in the configuration of a Cisco router to receive a BGP feed from the MAPS RBL. The MAPS RBL (Mail Abuse Prevention System Realtime Blackhole List) is a list of IP addresses and subnets which are known to be the origination point of "spam" email transmission. The result of configuring your routers to discard packets destined TO these addresses is that you will discard any replies to packets that are sent to you from those addresses. This is efficacious since although you'll still receive the very small TCP SYN packets which the spam-sending mailserver uses to try to initiate an SMTP/TCP session, you'll discard the replying TCP SYN-ACK packets which allow the spam-sending mailserver requires before it can proceed with the transaction and actually send you the (much larger) email itself. Unlike methods of spam-blocking which are implemented on the receiving mailserver, this method elimitates IP transit transmission costs on your side, and avoids all but the minimum of reception costs.

An ancillary feature of this method is that the spam-sending mailserver has a limited number of TCP transmission buffers, some of which are reserved for each new attempted TCP transmission... many mailserver-based spam-blocking methods reject TCP connections immediately, which allows the spam-sending host to immediately proceed to the next target. This router-based method instead forces the spam-sending server to continue to hold one of its limited number of TCP transmission buffers in reserve for the entire timeout period of the TCP SYN, thus substantially limiting the number of recipients it can target in any period of time.

Overview of the Blocking Method

A BGP router belonging to the MAPS RBL project will establish an external BGP multi-hop peering session with one or more of your routers. It will feed you a set of routes which describe prefixes from which spam is originating. You use a route-map to modify the next-hop of each of those routes, such that packets to destinations within those subnets are routed to Null0, your router's way of discarding a packet. As spammers come and go, their prefixes will be announced and withdrawn across the RBL's peering session with you, which will dynamically update the routing table in your router.

Configuration and Testing on a Cisco Router

This example contains both text which must be typed into your router verbatim, and variable text which is dependent upon your specific network's configuration. Text which must be replaced with your specific information I've denoted through the use of a dollar-sign and capital letters, thus: $VARIABLE, and I'll explain what the variable denotes in the body of this document. Any text which you'll need to type is denoted by bold monospaced type, while that which the router displays on its console is shown in plain monospaced type.

First, contact the MAPS RBL staff and arrange for a BGP feed. They'll need your Autonomous System Number (ASN), and an IP address for your end of the connection. The ASN is the same number that you use for any other BGP peering that you may already have configured. The IP address should be a single, globally-routable IP address with its own /32 ( subnet mask. That is, it needs to be a subnet of its own, not an address that's included in a larger subnet that you're already using somewhere else in your network. The address needs to by statically allocated, and it needs to be reachable from the Internet.

In your router, begin by creating a loopback interface with the IP address that you've chosen for your end of the peering session:

Router> en
Router# configure terminal
Router(config)# interface loopback 7777
Router(config-if)# description MAPS RBL BGP Peering Address
Router(config-if)# ip address $LOOPBACKIPADDRESS
Router(config-if)# exit
Router(config)# end
Note that you should not use a preexisting loopback address or interface, even one that you've created specifically for the termination of other BGP peering sessions, because if you're using it for anything else, it won't be portable between routers when you need to reconfigure your network.

Next, use ping or traceroute to verify that the MAPS RBL router can be reached using the IP address you've chosen:

Router# ping
Protocol [ip]:
Target IP address:
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: yes
Source address or interface: loopback 7777
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echoes to, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 76/105/136 ms

Router# trace
Protocol [ip]:
Target IP address:
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to (

1 ( [AS 3557] 4 msec 4 msec 4 msec
2 ( [AS 3557] 4 msec 4 msec 4 msec
3 ( [AS 3557] 4 msec 4 msec 4 msec

Next, create the BGP route-filter which will keep you from advertising your own routes to the MAPS RBL route-server:
Router(config)# ip access-list extended MAPS-RBL
Router(config-ext-nacl)# deny ip any any
This filter is absolutely necessary, as the current implementation of the MAPS RBL route-server will not maintain a BGP peering session with any peer which attempts to send it routes.  If your outbound filter fails to prevent your router from sending routes to the MAPS RBL route-server, your session will fail each time it's set up, with the error "Write queue size of n exceeded limit of 300 messages."

Next, create the route-map and the Null0 "blackhole" route into which you'll direct spam replies:

Router(config)# route-map MAPS-RBL permit 10
Router(config-route-ma)# set ip next-hop
Router(config-route-ma)# set local-preference 7777
Router(config-route-ma)# set community no-export
Router(config-route-ma)# exit
Router(config)# ip route Null0
Last, configure and examine your BGP peering session:
Router(config)# router bgp $ASN
Router(config-router)# neighbor remote-as 7777
Router(config-router)# neighbor description MAPS RBL BGP peer
Router(config-router)# neighbor ebgp-multihop
Router(config-router)# neighbor update-source loopback 7777
Router(config-router)# neighbor distribute-list MAPS-RBL out
Router(config-router)# neighbor route-map MAPS-RBL in
Router(config-router)# exit
Router(config)# end

Router# show ip bgp summary
BGP router identifier $LOOPBACKIPADDRESS, local AS number $ASN
BGP table version is 1, main routing table version 1

Neighbor        V    AS  MsgRcvd  MsgSent  TblVer  InQ  OutQ   Up/Down  State/PfxRcd  4  7777      428      429       1    0     0  00:02:14      4291

Configuration Refinements

You may wish to add some additional features to the minimal functional example described above. For example, you may wish to discard any announcements of your own prefixes which you hear from the MAPS RBL, so that you don't loose internal connectivity in the event that one of your own customers makes it onto the list. You may wish to create a descriptive DNS PTR record for the IP address associated with your Null0 route, so that folks doing traceroutes to blackholed destinations can discover the reason for their lack of connectivity.


If your router has an IOS image prior to about 12.0, it may not recognize named access lists, in which case you'll see the following error:
Router(config)# ip access-list extended MAPS-RBL
% Invalid input detected at '^' marker.
If your router gives you such an error, you should use numbered access-lists instead:
Router(config)# access-list 77 deny any
Router(config)# ip as-path access-list 77 deny any
This pair of access lists is redundant, in that the first access-list blocks the exporting of any routes which contain any prefix, and the second one blocks the exporting of routes with any AS-path. This is belt-and-suspenders approach, and generally considered good practice, since it allows you to perform maintenance work on either access-list without affecting the state of the peering session.

If you use numbered access-lists, your BGP peering session will need to be configured with them by number as well:

Router(config)# router bgp $ASN
Router(config-router)# neighbor remote-as 7777
Router(config-router)# neighbor description MAPS RBL BGP peer
Router(config-router)# neighbor ebgp-multihop
Router(config-router)# neighbor update-source loopback 7777
Router(config-router)# neighbor distribute-list 77 out
Router(config-router)# neighbor filter-list 77 out
Router(config-router)# neighbor route-map MAPS-RBL in
Router(config-router)# exit
Router(config)# end

Author's Address

Bill Woodcock
Packet Clearing House
404 Balboa
San Francisco, California
94118-3938 USA
+1 415 BGP PEER
+1 866 BGP PEER (toll-free in the United States)

Authoritative Sources of This Document

Revision History

Rev 0.1, August 10, 2000: by Bill Woodcock, based upon Zocalo's January 1997 configuration, so some things may be a little out-of-date. Specifically, is route-mapping next-hop to an address which is statically routed to null0 still the most CPU-efficient way of dropping a packet? Noah, do you want to spin a Juniper version of this document?
Rev 0.2, november 27, 2000: by Bill Woodcock, with addition of warning about failing to filter announcements toward the route-server, per J.D. Falk.