This lab is focused on demonstrating how to implement remote trigger black hole filtering between adjacent ASes.
The diagram below is a reminder of the lab topology:
In the previous lab we set up the RTBH infrastructure for own autonomous system. We are now going to extend this to add RTBH filtering capability between adjacent ASes. This is a common service offered to their BGP customers by many transit providers, and is often set up between peers as well to deal with incidents occurring between their respective networks.
To support inter-AS RTBH we need to tag our problem destinations with the industry standard community set aside for RTBH use. This community is defined in RFC7999 and recorded by IANA and is 65535:666.
The first step is to tidy up the Trigger router from the previous lab: remove any tag 66 static routes you created to test your RTBH filtering configuration. Once they are removed, verify using the router trace command that you can reach those destinations again.
The previous lab set the community on the destination we wanted to be blocked to be no-export. We need to remove this from the Trigger router as well, as we want to announce this “to be blocked” destination to our neighbouring AS.
route-map black-hole-trigger permit 10
no set community no-exportand
route-map black-hole-triggerv6 permit 10
no set community no-export
We will now add the standard RTBH community to the route-maps we created earlier. The following configuration shows what needs to be done:
route-map black-hole-trigger permit 10
set community 65535:666and
route-map black-hole-triggerv6 permit 10
set community 65535:666
As Cisco IOS doesn’t have a keyword for this standard community, we need to create the RTBH community across all our routers (Border, Core, Peering, Access, and Trigger):
ip community-list standard RTBH permit 65535:666
With the community-list now defined, we need to add the RTBH community to our IBGP policy - the Core Router only announces prefixes according to the route-map iBGP-partial. We need to update this route-map to include the RTBH community as well:
route-map partial-iBGP permit 5
match community RTBH(Recall in the previous lab that we only saw the locally triggered prefix on the Core and Border routers - the Peering and Access didn’t see this prefix because the iBGP route-map didn’t include it.)
Because our neighbours will be setting up inter-AS RTBH as well, we need to add support to our eBGP sessions for them sending any prefixes with the RTBH community set. That way, we can drop traffic to prefixes which they tell us are under attack in their network.
Previous labs set up inbound BGP filters on our Border and Peering routers. It is unlikely that our upstream provider is going to send us destinations with the RTBH community set, so we will just focus on configuring the Peering router only.
We need to add a line to allow a prefix (host address only) tagged with the RTBH community to have its next-hop set to the discard prefix. So we need to match a host prefix from our BGP neighbour’s address space, and match the RTBH community.
We need to modify the incoming route-map to look for a prefix with the incoming RTBH community set on it, and let that prefix into the BGP local table without applying any policy.
First, we define a prefix-list for IPv4 and for IPv6 which only allows a host address for the range of addresses used in this workshop. Here is an example:
ip prefix-list RTBH-filter permit 100.68.0.0/16 ge 32
!
ipv6 prefix-list RTBH-v6filter permit 2001:DB8::/32 ge 128These will only match single host addresses. We want the filter to be quite specific1 - the last thing we want is for our peer or customer to send us routes which are found outside their or your AS and they cut you off from those destinations.
Then, we create a new line in the Route-Server route-map - we make it line 1 in the configuration below:
route-map IXP-RS-in permit 1
description Look for RTBH routes from IX peers
match community RTBH
match ip address prefix-list RTBH-filter
!
route-map IXP-RS-in permit 5
description Local pref for IXP RS Peers
match ip address prefix-list IXP-RS
set local-preference 150
set community X0:1300
!Note that line 5 already exists - please check that what you have matches the example shown.
We need to do the same for the private peer route-map, again line 1 below:
route-map private-peer-in permit 1
description Look for RTBH routes from private peers
match community RTBH
match ip address prefix-list RTBH-filter
!
route-map private-peer-in permit 5
description Local pref for Private Peer
match ip address prefix-list ASY0-block
set local-preference 200
set community X0:1100
!Do the same for IPv6! Something like this, for the Route-Server route-map:
route-map IXP-RSv6-in permit 1
description Look for RTBH routes from IX peers
match community RTBH
match ipv6 address prefix-list RTBH-v6filter
!
route-map IXP-RSv6-in permit 5
description Local pref for IXP RS Peers
match ipv6 address prefix-list IXP-v6RS
set local-preference 150
set community X0:1300
!and the private-peer route-map:
route-map private-peerv6-in permit 1
description Look for RTBH routes from private peers
match community RTBH
match ipv6 address prefix-list RTBH-v6filter
!
route-map private-peerv6-in permit 5
description Local pref for Private Peer
match ipv6 address prefix-list ASY0-v6block
set local-preference 200
set community X0:1100
!This updates the inbound policy on the Peering Router with its EBGP neighbours.
We also need to fix the iBGP configuration on the peering router to catch any prefix with the RTBH community and set its next-hop to the discard address. To do this we need to create a route-map to be used for iBGP policy. As in the previous lab, we have to fix the next-hop as there is no next-hop-self keyword supported in Cisco IOS route-maps for both IPv4 and IPv6.
The new IPv4 route-map is shown here:
route-map ibgp permit 10
description Catch RTBH routes
match community RTBH
set ip next-hop 192.0.2.1
set local-preference 1000
set origin IGP
set community no-export
!
route-map ibgp permit 20
description next-hop-self for normal routes
set ip next-hop 100.68.X.3
!and the IPv6 route-map is shown here:
route-map ibgpv6 permit 10
description Catch RTBH routes
match community RTBH
set ip next-hop 100::1
set local-preference 1000
set origin IGP
set community no-export
!
route-map ibgpv6 permit 20
description next-hop-self for normal routes
set ipv6 next-hop 2001:DB8:X::3
!Explaining each line:
match community looks for a route with the RTBH community set 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 received route as no-export so it won’t accidentally head outside the autonomous system.
Fix the next-hop of remaining routes so they originate from the router Loopback (like next-hop-self does)
Finally, once the two route-maps are created, we apply them to the iBGP peer-group. Remember to delete the next-hop-self line in the peer-group as well:
router bgp X0
address-family ipv4
no neighbor ibgp-rr next-hop-self
neighbor ibgp-rr route-map ibgp out
!
address-family ipv6
no neighbor ibgpv6-rr next-hop-self
neighbor ibgpv6-rr route-map ibgpv6 out
!After this is done, refresh the BGP sessions, and the Peering router should now be ready to handle prefixes from peers arriving with the RTBH community set on it.
We need to modify our filters on our eBGP sessions to allow the standard RTBH community out of our network. On the Border Router, previous labs have created the transit provider route-map called Transit-out - we need to add the RTBH community to the list of permitted communities. Here is what the route-map now looks like:
route-map Transit-out permit 5
match community aggregate customer-pi RTBH
!We need to do the same on the Peering Router, for all our private peers:
route-map private-peer-out permit 5
match community aggregate customer-pi RTBH
!and for our IXP Route Server peers:
route-map IXP-RS-out permit 5
match community aggregate customer-pi RTBH
!Then, we need to add in the send-community configuration on our EBGP sessions so that RTBH community will actually be sent along with the RTBH prefixes. If we miss the send-community configuration out, our neighbours will simply see the host routes from us, with no community attached.
router bgp X0
address-family ipv4
neighbor <p2p> send-community
address-family ipv6
neighbor <p2p> send-community
!Once the RTBH community has been added to the route-maps on the Border and Peering routers, and send-community has been configured on the EBGP sessions, refresh the BGP sessions so that the community filter is applied.
On a side note, see how easy it is to modify BGP peering policy because we have already implemented BGP communities across the network. To allow the RTBH prefix out, we simply added that community to our configuration.
We are now going to test the trigger configuration - and the target will be the loopback address used on the Customer Router which we will “pretend” is under attack from the outside.
What we are going to do is use the Trigger Router to announce this loopback address to the other ASes connected to the group.
The configuration is simple, a single static route with tag 66 on it, like this, on the Trigger Router:
ip route 100.68.X.64 255.255.255.255 null0 tag 66Once applied, check the BGP table on all the routers in the group - they should show the route to 100.68.X.64 as having next-hop 192.0.2.1.
Do the same for the IPv6 loopback on the Customer router:
ipv6 route 2001:DB8:X:4000::/128 null0 tag 66Again, check the BGP table to make sure that the next-hop for 2001:DB8:X:4000::/32 points to 100::1.
Check with the other groups. Once they have completed their configurations, trying pinging or tracing to their customer routers and their loopback interfaces. What happens?
What do you see in the BGP table now? Do you see the RTBH routes appearing from the upstream provider, across the IX, and through the private peering?
Here is the IPv4 BGP table from the Border Router in Group 1, from an earlier version of this lab:
B1#show ip bgp
BGP table version is 45, local router ID is 100.68.1.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
*> 0.0.0.0 100.121.1.0 0 121 i
*>i 100.68.1.0/24 100.68.1.2 0 100 0 i
*>i 100.68.1.28/30 100.68.1.2 0 100 0 i
*>i 100.68.1.64/32 192.0.2.1 0 1000 0 i
*>i 100.68.1.64/26 100.68.1.4 0 100 0 i
* 100.68.2.0/24 100.121.1.0 50 0 121 20 i
*>i 100.68.1.3 0 150 0 20 i
* 100.68.2.64/32 100.121.1.0 50 0 121 20 i
*>i 192.0.2.1 0 1000 0 20 i
*>i 100.68.3.0/24 100.68.1.3 0 150 0 30 i
* 100.121.1.0 50 0 121 30 i
*>i 100.68.3.64/32 192.0.2.1 0 1000 0 30 i
* 100.121.1.0 50 0 121 30 i
*>i 100.68.4.0/24 100.68.1.3 0 150 0 40 i
* 100.121.1.0 50 0 121 122 40 i
* 100.68.4.64/32 100.121.1.0 50 0 121 122 40 i
*>i 192.0.2.1 0 1000 0 40 i
*>i 100.68.5.0/24 100.68.1.3 0 150 0 50 i
* 100.121.1.0 50 0 121 122 50 i
*>i 100.68.5.64/32 192.0.2.1 0 1000 0 50 i
* 100.121.1.0 50 0 121 122 50 i
*>i 100.68.6.0/24 100.68.1.3 0 150 0 60 i
* 100.121.1.0 50 0 121 122 60 i
*>i 100.68.6.64/32 192.0.2.1 0 1000 0 60 i
* 100.121.1.0 50 0 121 122 60 i
*>i 100.68.101.0/24 100.68.1.4 0 100 0 64512 i
* 100.68.102.0/24 100.121.1.0 50 0 121 20 i
*>i 100.68.1.3 0 150 0 20 i
*>i 100.68.103.0/24 100.68.1.3 0 150 0 30 i
* 100.121.1.0 50 0 121 30 i
*>i 100.68.104.0/24 100.68.1.3 0 150 0 40 i
* 100.121.1.0 50 0 121 122 40 i
*>i 100.68.105.0/24 100.68.1.3 0 150 0 50 i
* 100.121.1.0 50 0 121 122 50 i
*>i 100.68.106.0/24 100.68.1.3 0 150 0 60 i
* 100.121.1.0 50 0 121 122 60 i
*> 100.121.0.0/16 100.121.1.0 0 50 0 121 i
*> 100.122.0.0/16 100.121.1.0 50 0 121 122 iAre you able to explain the cause of all the entries you see now?
Do you see the IPv4 /32 being announced by other groups? Here is the one being sent by Group 5:
B1#show ip bgp 100.68.5.64
BGP routing table entry for 100.68.5.64/32, version 39
BGP Bestpath: deterministic-med
Paths: (2 available, best #1, table default, not advertised to EBGP peer)
Not advertised to any peer
Refresh Epoch 1
50
192.0.2.1 from 100.68.1.2 (100.68.1.2)
Origin IGP, metric 0, localpref 1000, valid, internal, best
Community: no-export
Originator: 100.68.1.3, Cluster list: 100.68.1.2
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
121 122 50
100.121.1.0 from 100.121.1.0 (100.121.1.4)
Origin IGP, localpref 50, valid, external
rx pathid: 0, tx pathid: 0The best path is of course pointing to the Null interface via the 192.0.2.1 next-hop value. But note you also see the path via the upstream provider - this is because the upstream is doing no filtering whatsoever in this lab (not the normal occurrence in today’s global Internet). You’d not normally see your upstream provider passing on RTBH prefixes from other customers!
Finally: Demonstrate your inter-AS RTBH set up to the workshop instructors.
Once the lab instructor gives you the go-ahead, please remove the two static routes you added to test the Trigger. We will need to use our customer router again for the following labs, so we need to ensure that the Loopback interface address is routable.
Simply go to the Trigger Router and do:
no ip route 100.68.X.64 255.255.255.255 null0 tag 66
no ipv6 route 2001:DB8:X:4000::/128 null0 tag 66and the two host routes will become usable again.
In real life the inbound filter will match exactly the address space learned from each customer. Inter-AS RTBH is usually used in a customer to transit provider relationship - the transit provider only allows host addresses from the customer’s address space to be sent with the RTBH community set.↩