## Introduction

This lab demonstrates how to implement Remotely Triggered Black Hole (RTBH) Filtering within the local AS.

## Lab Topology

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!)

## Introduction

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).

## Configuration Steps

### Configuring the Trigger Router

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.

From the diagram above, you will see that the Trigger Router uses interface `GigabitEthernet 0/1` to connect to the Core Router. Refer back to the Setup Lab to do the basic configuration for the router, the Address Plan for the required addressing, 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 for the Community Policies that were set earlier. If you do all that, the configuration should look something similar to what is documented in Appendix A.

### Introducing the RTBH Community

For ease of use later on in this workshop, we are going to add the well-known RTBH community1 definition to all our routers in the lab. (Access, Border, Core, Peering, and Trigger routers.)

    ip community-list standard RTBH permit 65535:666

### Updating the Core Router configuration

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 GigabitEthernet5
     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 X0
     address-family ipv4
      neighbor 100.68.X.5 peer-group ibgpv4-partial
      neighbor 100.68.X.5 description iBGP with Trigger
    !
     address-family ipv6
      neighbor 2001:DB8:X::5 peer-group ibgpv6-partial
      neighbor 2001:DB8:X::5 description iBGP with Trigger
    !

We will also need to allow any RTBH tagged prefixes to be propagated to the other partial IBGP peers in our network, so that those routers can implement the Null route for those RTBH tagged prefixes.

To do this we need to update the route-map used by the `ibgpv4-partial` and `ibgpv6-partial` peer-groups to include the RTBH community:

    route-map partial-iBGP permit 5
     match community RTBH
    !

The core router will now also propagate any prefix with the RTBH community set to the partial route peers in the network.

### Preparing the Routers

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 as it is 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.

### Setting up the Trigger Router

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-triggerv4 permit 10
     description Blackhole route conditions
     match tag 666
     set ip next-hop 192.0.2.1
     set local-preference 1000
     set origin IGP
     set community no-export 65535:666
    !

Explaining each line:

- `match tag` looks for a route with a tag of `666` 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

- Also tag the redistributed route with the RTBH community so we recognise it across our IBGP (for routing policy purposes)

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 666
     set ipv6 next-hop 100::1
     set local-preference 1000
     set origin IGP
     set community no-export 65535:666
    !

### Updating BGP on Trigger Router

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 X0
     address-family ipv4
      no neighbor ibgpv4-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 X0
     address-family ipv4
      redistribute static route-map black-hole-triggerv4
    !
     address-family ipv6
      redistribute static route-map black-hole-triggerv6
    !

We are now ready to test the trigger.

### Testing 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.8

and

    TX# trace 2001:4860:4860::8888

and 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 666
    ipv6 route 2001:4860:4860::8888/128 null0 tag 666

Don’t forget the `tag` keyword2!

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  i

Does 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.5 7w0d ago
      Routing Descriptor Blocks:
      * 192.0.2.1, from 100.68.X.5, 7w0d ago
          Route metric is 0, traffic share count is 1
          AS Hops 0
          MPLS label: none

What 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 1

Once you are satisfied that your RTBH set up is working, demonstrate the set up to the workshop instructors.

## Conclusion

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.

## Appendix A

The setup configuration of the Trigger Router should look something like this:

    version 15.7
    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 algorithm-type scrypt 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 algorithm-type scrypt 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 TriggerX
     ip address 100.68.X.5 255.255.255.255
     ipv6 address 2001:DB8:X::5/128
    !
    interface GigabitEthernet0/1
     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 asX0
     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 ibgpv4-rr peer-group
      neighbor ibgpv4-rr remote-as X0
      neighbor ibgpv4-rr description iBGP with RR
      neighbor ibgpv4-rr password BGPlab
      neighbor ibgpv4-rr update-source Loopback0
      neighbor ibgpv4-rr send-community
      neighbor ibgpv4-rr next-hop-self
      neighbor 100.68.X.2 peer-group ibgpv4-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 X0
      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 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
     permit ip 100.64.0.0 0.0.3.255 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-server ifindex persist
    !
    ipv6 access-list ipv6-vty
     permit ipv6 2001:DB8:X::/64 any
     deny ipv6 any any log
    !
    banner login ^
    Routing Infrastructure and Security Operations Workshop
               Network Startup Resource Center
    ^
    !
    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
    !

1. See https://www.rfc-editor.org/rfc/rfc7999.txt↩︎

2. If you forget the `tag` keyword, Cisco IOS gives the static route a distance of 666 rather than the default of 1.↩︎