BGP RTBH – Remotely-Triggered Black Hole
The aim of this lab is getting students familiar with the solution which is often used by telecommunication service providers in order to protect their clients from DoS-attacks. Obviously, protection against DoS attacks—and more to it DDoS—is more complicated and is not limited by the reviewed technology, but this kind of a solution is quite interesting by itself since various features of BGP are required for its usage. Doing this lab students will obtain practical skills of working with the community in BGP as well as get themselves familiar with some other peculiarities of router operation.
Students are allowed and encouraged to use varied literature and other information sources upon doing this lab.
The image above shows a simplified scheme of the provider networks and its two small clients. In order to ensure elementary fault-tolerance there are three routers used in the provider network. For the sake of simplicity clients’ networks are presented with one router.
There are two kinds of RTBH: source based and destination based, which are different in whether the receiver or sender is blocked. In this lab we are going to examine destination based RTBH since there may be too many malware traffic sources in DDoS-attacks, among other reasons.
RTBH enabling requires preliminary preparations on the provider and client that need to be carried out before the attack occurrence. If malware traffic is detected in a certain host in the client network, the administrators of the client company may block the traffic to that host in the provider network without involvement of the provider staff.
The lab is done using GNS3 emulator, version 1.1 or later. The routers used are 7204VXR model with installed 15.2(4)M6 IOS version or later with ADVENTERPRISEK9 feature pack.
- Build the scheme which is presented on the image above using the emulator. Switch all the devices on. Switch on all interfaces between the routers.
- Set up Loopback1 interface with X.X.X.X/32 IP-address, where X is the figure from the device name, on every router. This way, for example, 220.127.116.11 will be the address assigned to R4 router.
- Set up 192.168.YZ.Y/24 and 192.168.YZ.Z/24 IP-addresses, where Y is the number of the smallest device and Z is the number of the biggest device of the two, on links between the routers. This way, for example, 192.168.25.5 must be assigned to Gi0/0 R5 interface, whilst 192.168.25.2 address must be assigned to Fa2/0 R2.
- Make sure that the neighbouring device is available using ping command with all necessary parameters.
- Create Loopback0 interfaces on R4 and R5 routers and assign them IP-addresses like 10.X.0.1/16 where X is the device number. These prefixes will emulate routes for the internal clients' networks.
- Set up OSPF only between all provider routers.
- Redistribute all networks that are directly connected to these routers to OSPF.
- Make sure that all provider devices have the correct routing information.
- Configure BGP in the provider network between the physical interface addresses for all routers.
- Make sure that the neighbourhood has been established successfully.
- Configure BGP between the clients and the provider between the physical interface addresses.
- Disable automatic route summarization using no auto-summary command.
- Use network command to carry out the advertisement of 10.X.0.0/16 prefixes to BGP from both of the clients.
- Review routing tables on the clients. Make sure that they contain information about the other client's network.
- Make sure that the provider's OSPF process DOES NOT contain the routing information about the clients' networks. Explain why this is important.
- Disable Gi0/0 R1 interface using shutdown command.
- Make sure that the clients are not receiving information about prefixes of each other any more. Explain why this happened.
- Reconfigure BGP only inside the provider network in such a way so that the neighbourhood is established only between Loopback1 interfaces and not between the physical ones.
- Make sure that the BGP neighbourhood between R1 and R2 was restored.
- Make sure that the clients' routers started receiving information about each other networks once again.
- Make sure that the user traffic is transmitted between the clients' networks.
- Since R3 is not participating in the clients’ routes propagation, please explain whether it would be possible at all to disable BGP on R3. What will it lead to?
- Enable all interfaces that you previously disabled.
- Set up outgoing route filtration on R4 router using distribute-list or route-map commands. It's required that only the routes from 10.4.0.0/16 network with masks from 16 to 24 are transferred.
- Create Loopback2 with 10.3.0.1/16 address on R4 router. Use network command to advertise this prefix to BGP.
- Make sure that the BGP table on R4 contains 10.3.0.0/16 prefix using sho ip bgp command.
- Make sure that BGP tables on other routes do not contain the prefix.
- Enable support of the new community format on all routers using ip bgp-community new-format command.
- Create route-map 666 on R5 router. All routers with 666 tag must be assigned community 5:666.
- Carry out redistribution of the static routes to BGP on R5 router via route-map 666 using redistribute static route-map 666 command.
- Allow the transfer of community together with the prefixes in the entire lab network using send-community both feature which is specified separately for each BGP neighbour.
- Add a static route to 192.168.1.1/32 address to null 0 interface on all routers in the provider network.
- Use clear ip bgp * command to reestablish the BGP neighbourship with the provider on R4 and R5 routers. Do not use this command in the real network! Instead of it please take a look at less destructive counterparts of this command.
- Create a host static route for 10.5.1.1/32 address to null 0 interface with tag 666 on R5 router.
- Make sure that R5 router advertises only the host route from the previous item with the appropriate community value, whilst 10.5.0.0/16 is the route for the entire network without this attribute.
- Make sure that R2 router receives correct updates from the neighbouring R5.
- Set up route-map on R2 router for the entry from R5 with three records. The first record must check whether the prefix is in the 10.5.0.0/16 network. The second one checks against the community attribute with 666 value. If there is such attribute one should change next-hop attribute to 192.168.1.1 value. In order to check whether the update contains a certain community value, one will need to create a respective list of communities using ip community-list standard 666 permit 5:666 command and then perform a check in route-map record using match community 666 command. The third record must check whether the client sends you only prefixes with allowed prefix lengths from 16 to 24. The router logic of route-map object processing is similar to the one used upon operation with the access lists: any match leads to end of processing. In other words, the first matched record is the last one checked. This means that if the update contains a prefix from 10.5.0.0/16 network, its checking for community or mask length will not be performed. One needs to add continue keyword, which is a new feature added to the latest IOS versions, in the corresponding record in route-map in order to avoid it.
- Suggest how one can write route-map in such a way so that continue feature is not used. A design like this may come in handy upon deploying RTBH in the network with old routers.
- Recreate BGP-sessions between the clients' devices and provider.
- Review the BGP table in R2 router. What can you tell about the prefixes advertised by R5?
- Make sure that RIB R2 doesn't contain 10.5.1.1/32 prefix.
- This fact appears since the router IOS regards the address of the next hop for this prefix unreachable because the neighbour and the next hop are reachable through different interfaces. This problem won't be there if the neighbourship is established from Loopback interface. Reconfigure R2 and R5 routers in a way so that the BGP neighbourship is established between the following interfaces: R2 Loopback1 and R5 Gi0/0.
- Are there any other settings that one should make on R5 in order to be able to establish the neighbourship?
- Make sure that the BGP-session remains unestablished even after changing additional settings on R2. The above-mentioned issue is due to the fact that an eBGP-session must be established only between directly connected physical interfaces (checking via TTL). This kind of checking is not performed upon establishing an iBGP-session. One needs to use ebgp-multihop 255 feature for the respective neighbour so that the routers can establish an eBGP-connection between the devices that are not connected to one another directly. Make necessary settings on R2 and R5.
- Make sure that a BGP-session between R2 and R5 has been established.
- Make sure that the routing table of provider devices contains 10.5.1.1/32 prefix and points at the right interface.
- Make sure that the information about this prefix was delivered to the router of other client.
- Make changes in route-map 666 on R2 router in such a way so that prefixes with 5:666 community are both changed next-hop attributes and added community no-export.
- Reestablish the BGP-neighbourhood between R2 and R5.
- Check what communities are assigned to 10.5.1.1/32 prefix on all other routers.
- Make sure that now there's no 10.5.1.1/32 prefix in the second client's RIB.
- Check how the traffic from R4 router is transferred to 10.5.1.1 address. Explain it.
- Analyze all settings that you previously made. Make sure that you understand all of it.
Download the PDF file with the description of the lab.