Source-Based RTBH (Community-Based)
Last updated
Last updated
Topology: bgp-mh-iol
All links are in the format 100.X.Y.X/24.
For example, the link between R4 and R7 is 100.4.7.0/24.
Lo0 is X.X.X.X/32 and is used for iBGP
Lo1 is <AS>.0.0.X/32 and is used as a public IP address that is pingable. The public Lo1 addresses are aggregated into a /8 at each edge router.
eBGP and iBGP is fully preconfigured.
Instructions:
Configure source-based RTBH for 10.0.0.1/32 within AS20.
R2 should drop traffic sourced from this IP at the edge.
Use the least restrictive method when dropping traffic inbound.
Use R4 as the blackhole trigger point, using communities to signal the blackhole from R4 instead of nexthop.
Using communities is usually a more elegant method to implement RTBH. On IOS-XE, there is no “set next-hop discard” option like there is on IOS-XR. So on the PEs, we must match the RTBH community and set the next-hop to a dummy null0 route.
On R4, we trigger the RTBH. We must match the static route like usual, and set the community to 20:666 and no-export. This is a bit more elegant than the previous solution, because we do not have to a complicated route-map that changes the nexthop to our iBGP peers based on the community. (next-hop=192.0.2.1 for RTBH routes, and next-hop=self otherwise). Instead, the community itself is what triggers blackholing on the remote PEs. Make sure to send community to the iBGP peers as well.
Finally, on R2, we implement loose uRPF on the interface facing R1 again.
Verification is similar to the previous lab. First, we can verify on R2 that the 10.0.0.1/32 prefix was received from R4 with the correct community, and that the nexthop was changed to our dummy null0 route.
If we source pings from R1, we should see the uRPF drops increment on eth0/1.
