LINX Route-Server Basic Remote-Triggered-Blackhole (RTBH) Service
 LINX offers its members a basic Black-holing service on the LINX route-servers to effectively divert the flow of any DDoS traffic that is part of an attack to a specific IP next-hop where this affected traffic will be discarded.
 By directing the affected traffic to a specific IP next-hop this ensures that no traffic will reach the original destination which means peering, connectivity and other infrastructure in the members AS can remain unaffected and any DDoS traffic is dropped closer to the source.
The Blackholing service is currently only available on LINX LON1 and LON2 exchanges for both IPv4 and IPv6. The service will be available at other LINX exchanges in Q2/Q3 of 2024.
 How Basic RTBH works at LINX
In the example below we have a number of peers connected to LINX Peering LAN infrastructure and a route-server . Assuming that all connected members peer with the route-server then each peer will announce their prefixes to the route-server where these prefixes will be announced and redistributed to all other connected peers.
In the example below we see that AS6504 announces its prefixes to the route-server and these prefixes are then announced from the route-server to all other AS’s , AS65401, AS65402 and AS65403.
With BGP Route Advertisements being received for AS65404 from other AS’s can send traffic towards AS65404 as they learn the next-hop and the routes for AS65404.
Now let's assume that AS65404 is now suffering a DDoS attack from 2 members on the same LINX infrastructure as shown below. The DDoS attack affects the peering router and reachability of any infrastructure within AS65404. Traffic from AS65403 is legitimate and is not part of the DDoS attack.
As we can see below devices in AS65404 are affected by this DDoS attack and the target of the attack is the prefix 63.73.199.0/24. Each of the routers for AS65401, AS65402 and AS65403 have learned the prefix for 63.73.199.0/24 with a next-hop of 192.168.250.4 and its MAC address of AB:CD:EF:04:04:04.
To mitigate this DDoS attack the member for AS65404 announces the route for 63.73.199.0/24 to the route-server with its next-hop of 192.168.250.4 and tags the Blackhole community 65535:666 to the prefix.
Once the route-server receives the BGP advertisement for 63.73.199.0/24 it detects that this route is tagged with the Blackhole community 65535:666. This signals the route-server to
Rewrite the next-hop address to that of the Blackhole next-hop which in this example is 192.168.250.232.
Tag the BGP ‘NO-EXPORT’ Community to the route so the receiving AS does not announce this route to another external AS.
The route is then redistributed from the route-server to other peers and especially to the peers that are originating the DDoS attack at the exchange. The prefix is then updated on the members routers BGP table.
Members routers would have learned the MAC for Black-Hole next-hop via ARP and NDP (for IPv6)
Once members have received the BGP update from the route-server for 63.73.199.0/24 with the changed next-hop of the BLACKHOLE device with next-hop of 192.168.250.254 and MAC address DE:AD:BE:EF:DE:AD DDoS traffic is then diverted to this destination by the member routers.
Traffic destined for 192.168.250.254 and MAC address DE:AD:BE:EF:DE:AD is then dropped by the connected edge router as each member port on the exchange is binded to a L2 MAC destination filter dropping all traffic to a device with destination MAC DE:AD:BE:EF:DE:AD.
Now with traffic dropped by the destination L2 filter for MAC DE:AD:BE:EF:DE:AD DDoS at the edge, AS65404 and affected devices within this AS are no longer under attack.
Any legitimate traffic for 63.73.199.0/24 from AS65403 will also be dropped as it will also learn the updated BGP route with the Blackhole next-hop.
Things to note
All prefixes tagged announced to the Route-Server and tagged with the Black-Hole community still need to pass validation. If you announce a route less than a /8 or greater then a /24 that originates from your AS it will still require a valid IRR route-object.
If a route less than a /8 or greater then a /24 is announced with the Blackhole community it will still need to pass validation for origin-AS, prefix-object and RPKI otherwise it will not be announced to other route-server peers.
This also applies for IPv6 for prefixes less than a /8 or greater then a /48
If a route less than a /8 or greater then a /24 is announced with the Blackhole community other route-server peers will need t adjust there inbound filters to accept prefixes less than a /8 or greater then a /24.
This also applies for IPv6 for prefixes less than a /8 or greater then a /48
Any legitimate traffic for a affected route where its next-hop has been changed by the route-server will also be dropped
Solution: If you are aware which peers are orginating the DDoS attack then you can apply the BGP Policy Community (Standard community - 0:<peer-as>, Large Community 8714:0:<peer-as>) to the prefix under attack.
Members who do not peer with the route-servers can still use the Blackhole next-hop to mitigate a DDoS attack.
The next-hop needs to be changed on outbound to any of there peers where the DDoS attack is sourced from.