Route Origin Validation and RTBH Lab

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, Invalids 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 20 for the private-peer and from 20 to 30 for the IXP peers:

router bgp X0
 address-family ipv4
  neighbor <private-peer> maximum-prefix 20
  neighbor 100.127.1.254 maximum-prefix 30
!

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, again up from 20 we set up earlier, to 30 now.

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

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:

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

ip route 61.45.248.240 255.255.255.255 Null0 tag 66

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 RTBH-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 RTBH-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>sh ip bgp 61.45.248.240
BGP routing table entry for 61.45.248.240/32, version 37
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 67A58138 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 54
BGP Bestpath: deterministic-med
Paths: (1 available, best #1, table default, not advertised to EBGP peer)
  Advertised to update-groups:
     2
  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 684BD93C 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 Invalids 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.