Route Origin Validation Lab

Introduction

This lab investigates using the newly configured RPKI support on the lab routers to explore routes with origins Valid, Invalid and Not Found.

Lab Topology

The diagram below is a reminder of the lab topology:

Propagating Validation State

Cisco IOS, by default, does not conform to the route origin validation standards. The RPKI state attached to the prefix should be just that; information for the network operator to implement policy on. However, Cisco IOS does two things:

• automatically drops prefixes which have RPKI state Invalid

• marks all prefixes announced by IBGP as Valid (even if they are Not Found).

We need to fix the first problem. We will address the second problem in the next lab.

We have set up the Border, Peering, and Access Routers to talk with the validator cache. We now need to tell these routers to not drop Invalids. To do this, enter the following:

router bgp X0
 address-family ipv4
  bgp bestpath prefix-validate allow-invalid
!
 address-family ipv6
  bgp bestpath prefix-validate allow-invalid
!

These three routers will now pass on prefixes marked as Invalid, allowing the operator to implement the policy they want (including dropping the prefixes).

Checking ROAs

APNIC, one of the five RIRs, has a block of 6 ASNs and 6 IPv4 /24s available for technical training like this. ROAs are signed for the address block to be originated by the ASN listed next to it.

We will now configure the Customer Router in each group to be in the ASN listed in the following table, and to announce the address block also listed in the table.

BGP on the Customer Router

We now will set up BGP on the customer router to use these AS numbers.

Check the Customer Router first. If BGP is already running using AS64512, then make a note of the prefixes being originated and the peer addresses (IPv4 and IPv6 - refer to the Securing BGP Lab earlier), and then enter configuration mode and remove BGP by entering:

no router bgp 64512

Then, we create a new BGP process and originate the address block as listed in the table above (include the address block we used in the earlier Securing BGP Lab). Here is an example for Group 6:

router bgp 135538
 bgp log-neighbor-changes
 bgp deterministic-med
 no bgp default ipv4-unicast
!
 address-family ipv4
  network 61.45.253.0 mask 255.255.255.0
  network 100.68.106.0 mask 255.255.255.0
  distance bgp 200 200 200
!
 address-family ipv6
  network 2001:DB8:101::/48
  distance bgp 200 200 200
!
ip route 61.45.253.0 255.255.255.0 null0
!
interface Null 0
 no ip unreachables
 no ipv6 unreachables
!

Each group should modify the above example for their own needs - don’t copy and paste the above, as we will come to prefix hijacking later on in this lab!

Next we need to set up eBGP with the Access Router. First we create the prefix-lists needed, for inbound and outbound filtering - again working with Group 6 as the example:

no ip prefix-list Cust6-out
!
ip prefix-list Cust6-out permit 61.45.253.0/24
ip prefix-list Cust6-out permit 100.68.106.0/24
!
ip prefix-list default permit 0.0.0.0/0

Do the same for IPv6, noting that there is no test IPv6 prefix:

ipv6 prefix-list CustX-v6out permit 2001:DB8:10X::/48
!
ipv6 prefix-list v6default permit ::/0

and then applying the configuration to the eBGP neighbour (Group 6 used as an example):

router bgp 135538
!
 address-family ipv4
  neighbor 100.68.6.34 remote-as 60
  neighbor 100.68.6.34 prefix-list Cust6-out out
  neighbor 100.68.6.34 prefix-list default in
!
 address-family ipv6
  neighbor 2001:DB8:6:31:: remote-as 60
  neighbor 2001:DB8:6:31:: prefix-list Cust6-v6out out
  neighbor 2001:DB8:6:31:: prefix-list v6default in
!

BGP on the Access Router

We now need to set up the matching configuration on the Access Router in each group’s AS. Again we need to set up prefix-lists before we set up the eBGP session - here is an example of the IPv4 prefix-list for Group 6, announcing the original customer assignment as well as the /24 we are going to use for testing ROAs:

ip prefix-list Cust6-in permit 61.45.253.0/24
ip prefix-list Cust6-in permit 100.68.6.64/26
!
ip prefix-list default permit 0.0.0.0/0
!

And the IPv6 prefix-list for all groups (we aren’t testing ROAs on any IPv6 address blocks as of now) which just announces the existing /52 assigned to the Customer:

ipv6 prefix-list CustX-v6in permit 2001:DB8:X:4000::/52
!
ipv6 prefix-list v6default permit ::/0
!

Note that we don’t expect any IPv6 prefixes from the upstream provider. And then we set up the eBGP session on the access router - if there is an existing configuration coming from an earlier lab, copy it into a text editor, change the AS number, delete the neighbour on the router, and then apply the modified configuration:

router bgp 60
!
 address-family ipv4
  neighbor 100.68.6.35 remote-as 135538
  neighbor 100.68.6.35 prefix-list Cust6-in in
  neighbor 100.68.6.35 prefix-list default out
  neighbor 100.68.6.35 default-originate
  neighbor 100.68.6.35 route-map set-pi-community in
!
 address-family ipv6
  neighbor 2001:DB8:6:31::1 remote-as 135538
  neighbor 2001:DB8:6:31::1 prefix-list Cust6-v6in in
  neighbor 2001:DB8:6:31::1 prefix-list v6default out
  neighbor 2001:DB8:6:31::1 default-originate
  neighbor 2001:DB8:6:31::1 route-map set-pi-community in
!

Note the default-originate on the eBGP session - we are announcing the default route to our customer as they do not need the full BGP table or any other routes apart from default.

Also, check on the Core Router that the test IPv4 prefix we just configured is visible. Run the show ip bgp command and check that the /24 is visible.

BGP on Peering Router

With your local AS now announcing a new address block, we can take advantage of our community configuration to propogate this announcement to all our peers and transits. Our outbound filter is a community based one which allows the community customer-pi out already.

But we would also want see the new prefix originated by our peers arrive at our peering router. We will now update the inbound IPv4 prefix filters to allow these new prefixes in via the bi-lateral and IXP peerings. First the bi-lateral peering needs to be updated to add the block announced by the neighbouring AS:

ip prefix-list ASX0-block permit <new-block>/24

and the IXP-RS IPv4 prefix-list needs to be updated to add the 6 new prefixes being originated:

ip prefix-list IXP-RS permit 61.45.248.0/24
ip prefix-list IXP-RS permit 61.45.249.0/24
ip prefix-list IXP-RS permit 61.45.250.0/24
ip prefix-list IXP-RS permit 61.45.251.0/24
ip prefix-list IXP-RS permit 61.45.252.0/24
ip prefix-list IXP-RS permit 61.45.253.0/24

Once the prefix-list filters have been updated, refresh the EBGP sessions on the Peering Router. After that you should see the new address blocks in the BGP table.

Checking Validation State

Now that we have announced the prefix from the Customer to inside our ASN, go to the Border and Peering Routers and check the validation state. Try showing the BGP table entry for the /24 prefix learned from your customer (Group 6 again used as an example):

show ip bgp 61.45.253.0

What do you see?

The output should look similar to below:

B6>show ip bgp 61.45.253.0
BGP routing table entry for 61.45.253.0/24, version 67
BGP Bestpath: deterministic-med
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1
  Refresh Epoch 1
  135538
    100.68.6.4 (metric 4) from 100.68.6.2 (100.68.6.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Community: 60:1005
      Originator: 100.68.6.4, Cluster list: 100.68.6.2
      path 67426B0C RPKI State valid

Note the last line in the output - do you see the words RPKI State valid as shown above?

What about Invalids?

The workshop instructors will have originated the remaining prefixes listed in the table at the start of this lab from the two Transit AS. Check the validation state of those prefixes. Run the command:

show ip bgp 61.45.254.0

What do you see?

The output should look similar to below:

B6>sh ip bgp 61.45.254.0
BGP routing table entry for 61.45.254.0/24, version 0
BGP Bestpath: deterministic-med
Paths: (1 available, no best path)
  Not advertised to any peer
  Refresh Epoch 1
  122 121
    100.122.1.4 from 100.122.1.4 (100.122.1.4)
      Origin IGP, localpref 50, valid, external
      path 674269BC RPKI State invalid

Note the last line in the output - do you see the words RPKI State invalid ?

Why do you think the router is saying that the RPKI state is invalid? Refer to the presentation if you are not sure.

What about the other prefix? Run the command:

show ip bgp 61.45.255.0

Do you see something like this:

B1>sh ip bgp 61.45.255.0
BGP routing table entry for 61.45.255.0/24, version 30
BGP Bestpath: deterministic-med
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     2
  Refresh Epoch 1
  121
    100.121.1.0 from 100.121.1.0 (100.121.1.4)
      Origin IGP, metric 0, localpref 50, valid, external, best
      path 68C642D4 RPKI State not found

This prefix is actually meant to be originated from AS135540, as you can see if you check the route object in the APNIC database:

$ whois -h whois.apnic.net 61.45.255.0
...
% Information related to '61.45.255.0/24AS135540'

route:          61.45.255.0/24
descr:          Prefix for APNICTRAINING LAB - AS135540
origin:         AS135540
mnt-by:         MAINT-AU-APNICTRAINING
country:        AU
last-modified:  2016-06-16T23:27:01Z
source:         APNIC

There is no ROA for this prefix, even though the route object states the origin AS. So the router shows the RPKI state as Not Found.

Checking on the Core Router

What do you see on the Core Router when you check the validation state of your newly originated prefix, or the prefix the instructors originated, or the prefixes originated by your peers?

Discussion: The instructors will demonstrate what is seen on the Core Router on the class projector. Can you explain what you are seeing in the BGP table here? Any surprises?

Further Testing

The instructors may have originated other prefixes from the Transit routers, just so you can check validation states of those. Again, these should all be invalid - confirm with the instructors and show them the results you see in your BGP table.

Here is the BGP table as seen on Group 6’s Border Router in a previous version of this workshop:

B6>sh ip bgp
BGP table version is 81, local router ID is 100.68.6.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop        Metric LocPrf Weight Path
N*>  0.0.0.0          100.122.1.4                        0 122 i
V*>  61.45.248.0/24   100.122.1.4                50      0 122 121 10 135533 i
V*>  61.45.249.0/24   100.122.1.4                50      0 122 121 20 135534 i
V*>  61.45.250.0/24   100.122.1.4                50      0 122 121 30 135535 i
V*>  61.45.251.0/24   100.122.1.4                50      0 122 40 135536 i
V*>  61.45.252.0/24   100.122.1.4                50      0 122 50 135537 i
V*>i 61.45.253.0/24   100.68.6.4           0    100      0 135538 i
I*   61.45.254.0/24   100.122.1.4                50      0 122 121 i
...

What about Not Founds?

The default state for any prefix not present in the validator cache is called Not Found. If you check all¹ the other prefixes in the BGP table you will see they are listed as Not Found. Their ROAs have not been signed (and indeed being private address space are unlikely to ever be signed as they are not routed on the public Internet).

Summary

This lab has shown how to investigate whether a prefix’s origin has been validated by the owner, and shown what happens when invalid announcements are made.