Source-Based RTBH (VRF Provider-triggered)
Topology: ine-spv4
Load rtbh.vrf.init.cfg
R1, XR2, R7 and R8 are all dual-stacked internet peers in an INET VRF. Configure source-based RTBH within the core so that traffic sourced from 1.1.1.1/32 and 2001:1::1/128 is dropped, as well as traffic sourced from 20.20.20.20/32 and 2001:20::20/128. Use R4 as the signaling server, using communities for triggering the RTBH.
Answer
Explanation
Source-based RTBH in a VRF is not very different from destination-based RTBH in a VRF. The cleanest way to implement it is to use a community. The IOS-XR PEs can simply match the community and “set next-hop discard.”
However the IOS-XE PEs must use a dummy null0 route in the global VRF. We can take advantage of IPv4-mapped IPv6 nexthops and use a single dummy route.
The triggering router simply tags these routes with the RTBH community and no-export. Make sure to send-community both as well.
The RR must send the standard community too.
Up until this point we have essentially implemented destination-based RTBH. To do source-based RTBH we just add the loose uRPF check at the ingress PEs.
Verification
On the ingress PEs, verify that all four routes point to a null0 adjacency in the FIB for the INET VRF.
When the customer routes originate traffic, we should see the uRPF drops increment on R2 and XR1.
The drops for IPv6 on R2 might be a little confusing in the output. It says “0 verification drops” but “5 (CEF)” drops. It seems that when the null0 route is matched, it’s a “CEF drop” instead of a “verification drop.” To be completely sure, we can use an ACL to verify the drops.
When we ping from R1, we should now see the logging entry:
Note that if we ping from the other loopbacks on R1 or XR2, traffic works as expected.
Last updated