This lab demonstrates how to implement Remote Trigger Black Hole (RTBH) Filtering within the local AS.
The diagram below is a reminder of the lab topology.
It introduces a new router, a trigger router. In a typical network, the trigger router is a separate device used solely to implement RTBH Filtering. (We could combine the configurations on to the access or the core router, but that would be a more complicated set up - try this in your spare time if you are interested!)
This lab will set up RTBH filtering within each group’s network. This will prepare us for the following lab which will demonstrate RTBH filtering between two different groups (mapping on to how one network operator will send a trigger to their upstream provider to help deal with a Distributed Denial of Service Attack).
As mentioned earlier, this lab introduces a new router, a Trigger Router, which will be used to implement our RTBH lab. We need to configure it first. Refer back to the Setup Lab to do the basic configuration for the router, the IS-IS Lab to add the router to the AS’s IGP, the Securing Router Lab to secure the router, the IBGP Lab to add the router to the iBGP, and the Communities Lab to include the Community Policy that was set earlier. If you do all that, the configuration should look something like what is documented in Appendix A.
Note that you will need to add the Trigger Router to the iBGP on the Core Router too. The interface configuration on the Core Router for the connection to the Trigger Router is our standard secure best practice, as we’ve seen before:
interface FastEthernet3/0
description P2P Ethernet Link to TriggerX
ip address 100.68.X.22 255.255.255.254
no ip redirects
no ip proxy-arp
ip router isis asX0
ipv6 address 2001:DB8:X:13::/127
ipv6 nd prefix default no-advertise
ipv6 nd ra suppress all
ipv6 router isis asX0
isis network point-to-point
isis metric 2
isis ipv6 metric 2
!And the extra BGP configuration on the Core Router would look something like this:
router bgp 30
address-family ipv4
neighbor 100.68.3.5 peer-group ibgp-partial
neighbor 100.68.3.5 description iBGP with Trigger
!
address-family ipv6
neighbor 2001:DB8:3::5 peer-group ibgpv6-partial
neighbor 2001:DB8:3::5 description iBGP with Trigger
!
The next step is to prepare the routers across our AS to support RTBH filtering. The IPv4 address block 192.0.2.0/24 is a TEST network and is commonly used to support RTBH. The equivalent IPv6 address block is 100::/64, defined by IANA as the Discard Prefix (refer to the presentation).
We will set up static routes for the discard route on all 5 routers (we now have a Trigger Router too) in our AS, like this:
ip route 192.0.2.1 255.255.255.255 Null0
ipv6 route 100::1/128 Null0(The Customer Router doesn’t get this configuration, it’s not part of our AS.)
These two host addresses are the next-hop targets for the RTBH configuration. Destinations we want to drop will have their respective IPv4 and IPv6 next-hops changed to these two addresses, which will cause all traffic to those destinations to be dropped into the Null interface on the router.
Remember that the Null interface is a silent discard interface on a hardware router - packets sent here are completely dropped by the interface hardware itself.
The simple way to apply RTBH to a destination we want to block is to set up a static route to Null for that destination. We will tag that static route in a special way such that our router configuration will redistribute it into and announce it by BGP with a next-hop pointing to the configured discard address. As you learned in the presentation, this destination can be anywhere in the Internet (which of course includes the local AS).
To do all this, first we create route-maps for IPv4 and for IPv6 to look for this special static route. Doing IPv4 first:
route-map black-hole-trigger permit 10
description Blackhole route conditions
match tag 66
set ip next-hop 192.0.2.1
set local-preference 1000
set origin IGP
set community no-export
!Explaining each line:
match tag looks for a route with a tag of 66 on it
Then set the next-hop to the discard address, put a very high local preference on the destination (higher than any other policy preference in the network)
Make origin IGP (no real reason - redistribute commands create origin UNKNOWN)
Mark the redistributed route as no-export so it won’t accidentally head outside the autonomous system.
We do the same for IPv6 - it needs a separate route-map because the next-hop address is an IPv6 address, and next-hops must belong to the same address family as the destination:
route-map black-hole-triggerv6 permit 10
description Blackhole route conditions
match tag 66
set ipv6 next-hop 100::1
set local-preference 1000
set origin IGP
set community no-export
!
Recall that we set up the iBGP peer-group for the Trigger Router to include a next-hop-self statement - we were just following the steps we did in the earlier labs.
If we apply the above route-map, IOS will apply the next-hop-self statement after the route-map, so will override the next-hop being pointed to the discard address.
So we need to remove the next-hop-self command from the iBGP:
router bgp 10
address-family ipv4
no neighbor ibgp-rr next-hop-self
!
address-family ipv6
no neighbor ibgpv6-rr next-hop-self
!And now, with the route-map created, we can apply it to the BGP session on the Trigger Router, like this:
router bgp 10
address-family ipv4
redistribute static route-map black-hole-trigger
!
address-family ipv6
redistribute static route-map black-hole-triggerv6
!We are now ready to test the trigger.
We are now going to test the trigger configuration. We are going to use the host address 8.8.8.8 and 2001:4860:4860::8888 for testing purposes. (Check with the lab instructors if IPv6 connectivity is available for the workshop lab.)
Before you start, try tracing to the destinations from your Trigger router:
TX# trace 8.8.8.8and
TX# trace 2001:4860:4860::8888and note the output. Cut and paste from the terminal screen and save in a text file on your laptop.
Now we will activate our trigger. We simply create a static route to Null on our Trigger router for these two addresses:
ip route 8.8.8.8 255.255.255.255 null0 tag 66
ipv6 route 2001:4860:4860::8888/128 null0 tag 66Don’t forget the tag keyword1!
Once the static route has been created, trying tracing to the two above destinations from the Access, Core, and Border routers. What happens now?
Try some other destinations. Log in to the Core, Border and Access routers and now look at the BGP table and routing table for both 8.8.8.8 and 2001:4860:4860::8888. What do you see?
Does the BGP table entry look like this on the Core router?
cX>sh ip bgp | i 8.8.8.8
*>i 8.8.8.8/32 192.0.2.1 0 1000 0 iDoes the routing table entry look like this?
cX>sh ip route 8.8.8.8
Routing entry for 8.8.8.8/32
Known via "bgp X0", distance 200, metric 0, type internal
Last update from 100.68.X.4 7w0d ago
Routing Descriptor Blocks:
* 192.0.2.1, from 100.68.X.4, 7w0d ago
Route metric is 0, traffic share count is 1
AS Hops 0
MPLS label: noneWhat about the routing table entry for the discard route?
cX>sh ip route 192.0.2.1
Routing entry for 192.0.2.1/32
Known via "static", distance 1, metric 0 (connected)
Routing Descriptor Blocks:
* directly connected, via Null0
Route metric is 0, traffic share count is 1Once you are satisfied that your RTBH set up is working, demonstrate the set up to the workshop instructors.
This lab has shown the simple configuration required to set up RTBH in a service provider network. With this configuration in place, it becomes very simple for the operator to block attacks on hosts connected to the network by simply setting up a tagged static route to a null interface.
The next lab will build on this configuration to demonstrate how to signal to another network operator to drop packets to a particular hosted destination addresses.
The setup configuration of the Trigger Router should look something like this:
version 15.2
service timestamps debug datetime msec localtime show-timezone year
service timestamps log datetime msec localtime show-timezone year
service password-encryption
!
hostname TX
!
logging buffered 16384
no logging console
enable secret lab-EN
!
aaa new-model
aaa authentication login default local
aaa authentication enable default enable
!
clock timezone AEST 10 0
no ip source-route
ip cef
no ip domain lookup
ip domain name ws.nsrc.org
no ipv6 source-route
ipv6 unicast-routing
ipv6 cef
!
key chain asX0-key
key 1
key-string isplab
!
username isplab secret lab-PW
!
ip ssh source-interface Loopback0
ip ssh version 2
!
interface Null0
no ip unreachables
no ipv6 unreachables
!
interface Loopback0
description Loopback on TX
ip address 100.68.X.5 255.255.255.255
ipv6 address 2001:DB8:X::5/128
!
interface FastEthernet0/0
description P2P Ethernet Link to CX
ip address 100.68.X.23 255.255.255.254
no ip redirects
no ip proxy-arp
ip router isis asX0
ipv6 address 2001:DB8:X:13::1/127
ipv6 nd prefix default no-advertise
ipv6 nd ra suppress all
ipv6 router isis as60
isis network point-to-point
isis metric 2
isis ipv6 metric 2
!
router isis asX0
net 49.0001.000X.0005.00
is-type level-2-only
authentication mode md5 level-2
authentication key-chain asX0-key level-2
metric-style wide
set-overload-bit on-startup wait-for-bgp
log-adjacency-changes all
metric 100000
passive-interface Loopback0
!
address-family ipv6
multi-topology
set-overload-bit on-startup wait-for-bgp
metric 100000
exit-address-family
!
router bgp X0
bgp log-neighbor-changes
bgp deterministic-med
no bgp default ipv4-unicast
!
address-family ipv4
neighbor ibgp-rr peer-group
neighbor ibgp-rr remote-as 60
neighbor ibgp-rr description iBGP with RR
neighbor ibgp-rr password BGPlab
neighbor ibgp-rr update-source Loopback0
neighbor ibgp-rr send-community
neighbor ibgp-rr next-hop-self
neighbor 100.68.X.2 peer-group ibgp-rr
neighbor 100.68.X.2 description iBGP with Core
distance bgp 200 200 200
!
address-family ipv6
neighbor ibgpv6-rr peer-group
neighbor ibgpv6-rr remote-as 60
neighbor ibgpv6-rr description iBGP with RR
neighbor ibgpv6-rr password BGPlab
neighbor ibgpv6-rr update-source Loopback0
neighbor ibgpv6-rr send-community
neighbor ibgpv6-rr next-hop-self
neighbor 2001:DB8:X::2 peer-group ibgpv6-rr
neighbor 2001:DB8:X::2 description iBGP with Core
distance bgp 200 200 200
!
ip bgp-community new-format
ip community-list standard aggregate permit X0:1000
ip community-list standard subnets permit X0:1001
ip community-list standard customer-pi permit X0:1005
ip community-list standard private-peer permit X0:1100
ip community-list standard bilateral-peer permit X0:1200
ip community-list standard RS-peer permit X0:1300
!
ip access-list standard SNMP
permit 100.68.X.30
deny any log
!
ip access-list extended ipv4-vty
permit ip 100.68.X.0 0.0.0.15 any
deny ip any any log
!
logging trap debugging
logging facility local4
logging source-interface Loopback0
!
snmp-server community NetManage RO SNMP
snmp-server trap-source Loopback0
snmp-server source-interface informs Loopback0
snmp-server location NSRC Lab
snmp ifmib ifindex persist
!
ipv6 access-list ipv6-vty
permit ipv6 2001:DB8:6::/64 any
deny ipv6 any any log
!
banner login ^
Routing Infrastructure and Security Operations Workshop Lab
^
!
line con 0
transport preferred none
transport output ssh
line vty 0 4
access-class ipv4-vty in
exec-timeout 15 0
ipv6 access-class ipv6-vty in
transport preferred none
transport input ssh
transport output ssh
!If you forget the tag keyword, Cisco IOS gives the static route a distance of 66 rather than the default of 1.↩