## Introduction

With propagation of validation state now operational, this lab explores how Remote Trigger Blackhole Filtering functions in the presence of ROV.

## Lab Topology

The diagram below is a reminder of the lab topology:

## Background

Network operators who support Remote Trigger Black Hole filtering will naturally also want to deploy RPKI. However, creating a ROA for aggregates and routed subnets causes a further issue. If a host address from the aggregate is announced, its validation state will be `Invalid`. And using Cisco IOS defaults, and industry recommendations, `Invalid`s need to be dropped.

This lab explores how to support RTBH when Route Origin Validation is deployed.

## Testing RTBH with RPKI deployed

We will now check how our RTBH support in our network will operate with RPKI and Route Origin Validation deployed on the network. It is important to be able to support RTBH and ROV, as these are two important techniques to help secure the global Internet infrastructure and routing system.

### Increasing Max-Prefix

Because we are announcing another route from our group, it would be a good idea to increase the max-prefix setting on our EBGP sessions on the Peering Router. Otherwise the EBGP sessions will be shut down.

Here is an example configuration - we boost the `maximum-prefix` up from 5 to 10 for the private-peer; we can leave the IXP peer `maximum-prefix` at 25:

    router bgp X0
     address-family ipv4
      neighbor <private-peer> maximum-prefix 10
    !

No change is needed for the IPv6 peerings as we are only using the public address space we used for route origin validation to verify that our RTBH still works.

We also need to increase the `maximum-prefix` on our Border Router, up from 30 we set up earlier, to 40 now.

    router bgp X0
     address-family ipv4
      neighbor <upstream> maximum-prefix 40
    !

### Announcing a test RTBH prefix

Now we will move to our Trigger Router and announce a new /32 we want our network, and our peers to black hole. We will pick a /32 from the RPKI prefix we deployed in the previous lab. Use the x.x.x.240/32 address from the list of addresses provided earlier - here is the table, as a reminder:

Group | ASN | IP address block
--- | --- | ---
1 | 135533 | 61.45.248.0/24
2 | 135534 | 61.45.249.0/24
3 | 135535 | 61.45.250.0/24
4 | 135536 | 61.45.251.0/24
5 | 135537 | 61.45.252.0/24
6 | 135538 | 61.45.253.0/24
7 | 135539 | 61.45.254.0/24
8 | 135540 | 61.45.255.0/24

Here is an example of the `tag 666` Null route we set up for Group 1:

    ip route 61.45.248.240 255.255.255.255 Null0 tag 666

Make sure you use the correct address for your Group - do NOT copy the above if you are not Group 1.

### Updating Filters on the Peering Router

Next we will update the inbound RTBH prefix list on the Peering Router to allow the new RPKI address block in. If you check on the Peering Router, you will see that the prefix list looks like this:

    ip prefix-list RTBHv4-filter permit 100.68.0.0/16 ge 32

To this we will add a new line to allow host routes from the address block used by all Groups:

    ip prefix-list RTBHv4-filter permit 61.45.248.0/21 ge 32

Once you have done this, refresh the EBGP sessions on the Peering Router inbound.

### Confirmation

Once the tag route has been set up, the Trigger Router will announce the prefix by IBGP with the RTBH community set on it - here is what we see on the Core Router of Group 1 after the addition of the above static route:

         Network          Next Hop            Metric LocPrf Weight Path
    V*>i 61.45.248.0/24   100.68.1.4               0    100      0 135533 i
    V*>i 61.45.248.240/32 192.0.2.1                0   1000      0 i

and

    C1>show ip bgp 61.45.248.240
    BGP routing table entry for 61.45.248.240/32, version 3
    BGP Bestpath: deterministic-med
    Paths: (1 available, best #1, table default)
      Advertised to update-groups:
         1          2
      Refresh Epoch 1
      Local, (Received from a RR-client)
        192.0.2.1 from 100.68.1.5 (100.68.1.5)
          Origin IGP, metric 0, localpref 1000, valid, internal, best
          Community: 65535:666
          path 7EFE8C149EA8 RPKI State valid

Note the Cisco IOS curiosity - it marks all locally originated (IBGP) prefixes as Valid, by default, even though there is no validation data covering this /32.

Now ask the groups you peer with (private or across the IXP) what they see for this prefix.

Does it match this? Shown below is the output seen on Group 2’s Core Router:

         Network          Next Hop            Metric LocPrf Weight Path
    V*>i 61.45.248.0/24   100.68.2.3               0    200      0 10 135533 i
    I*>i 61.45.248.240/32 192.0.2.1                0   1000      0 10 i

and:

    C2>sh ip bgp 61.45.248.240
    BGP routing table entry for 61.45.248.240/32, version 56
    BGP Bestpath: deterministic-med
    Paths: (1 available, best #1, table default, not advertised to EBGP peer)
      Advertised to update-groups:
         1
      Refresh Epoch 1
      10, (Received from a RR-client)
        192.0.2.1 from 100.68.2.3 (100.68.2.3)
          Origin IGP, metric 0, localpref 1000, valid, internal, best
          Community: no-export
          Extended Community: 0x4300:0:2
          path 7F1FA0214518 RPKI State invalid

Note that the VRP for 61.45.248.0/24 only covers the /24. So the /32 is validation state `Invalid`, and because we allow IOS to propagate `Invalid`s we see it on the Core Router, the next-hop is 192.0.2.1, and thus traffic to this IP address is Null routed within Group 2’s network.

## Summary

The lab has demonstrated that RTBH still works if Route Origin Validation is configured on the network. To support RTBH, we need IOS to propagate Invalids rather than automatically dropping them.

Important Note: most operators will test validation state on their EBGP speaking routers only and will not have any need or reason to distribute state elsewhere in their IBGP mesh unless they are supporting inter-AS RTBH. Consult the RPKI presentation for more information.