OBJECTIVE:
This is an example how to use the BGP RTBH feature in IPv4 and VPNv4 environment on Cisco IOS-XR based platform. This text briefly describes how this feature might be useful for Service Provider using Cisco IOS-XR based platform and how to implement it. Before reading further, you may need to take a look on the RFC 5635, which describes the concepts behind it and on the Cisco's whitepaper, which details the implementation steps in IPv4 Unicast environment using Cisco IOS. If you are interested to learn more about uRPF, please refer to the following link. Also if you are interested in VPNv4 implementation on IOS you may take a look at this document.
OVERVIEW:
The BGP Remotely Triggered Black Hole (RTBH) is a security technique used to divert or black-hole some traffic away from POP routers to an appropriate point in the network where it can be black holed based on source or destination and so there are two available options for RTBH: Source based and Destination based. In this example it will shown configuration examples and validation for both options.
Typically this technique is accomplished by using a trigger router. The trigger router generates a BGP advertisement toward all the other routers in an autonomous system.
And normally, black-holes are what definitely have to be avoided in BGP core as it means that some traffic will be lost and there are some techniques to prevent such type of issues. But under certain conditions, like DoS attacks coming into core and then destined to the SP customers, it would be necessary to drop some traffic before it will "kill" some PE and/or CE routers or over utilize some links.
Please note that the BGP RTBH is just one of hundreds of security techniques available and should be deployed only with careful understanding of how this feature is working.
For a global view of the methodology how to mitigate DDOS attacks please review RFC 2827.
NETWORK TOPOLOGY AND INITIAL CONFIGURATION for IPv4 RTBH:
In this section the following topology will be used to demonstrate how to use IPv4 Destination and Source based RTBH on IOS-XR platforms.
Please note in current examples XR12000 is used, so command outputs might slightly differ on ASR9000 and CRS platforms
And some information about IGP and other features configuration not directly related to tested scenarios has been skipped to make the document more readable and avoid unnecessary details.
The same is related to the provided output of “show...” commands to omit details which are not relevant to the topic.
The simplified topology shows two BGP Autonomous Systems: AS1 which belongs to us as Service Provider and peering AS 65001. “PE1” and “PE2” routers in our AS are XR12000 and these two devices have iBGP peering with Route-Reflector “RR” which is CRS-1 router.
In addition to that PE1 has eBGP peering with router “R1” XR12000 router in the AS65001
For testing purposes and simplification of tests let’s consider that host under attack is interface loopback1 on “PE2” and, again, for the test, router “R1” is generating legitimate and attack traffic.
As a trigger device we will use “RR”.
Initial configuration includes:
“PE1” | “PE2” |
RP/0/1/CPU0:PE1#show run router bgp router bgp 1 bgp router-id 1.1.1.100 address-family ipv4 unicast ! neighbor 11.11.11.1 remote-as 65001 address-family ipv4 unicast route-policy bgp_all in route-policy bgp_all out ! ! neighbor 192.168.1.2 remote-as 1 update-source Loopback0 address-family ipv4 unicast next-hop-self ! | RP/0/4/CPU0:PE2#show run router bgp router bgp 1 bgp router-id 10.210.0.4 address-family ipv4 unicast network 10.20.30.1/32 ! neighbor 192.168.1.2 remote-as 1 update-source Loopback0 address-family ipv4 unicast ! |
“RR” | “R1” |
RP/0/RP0/CPU0:RR#show run router bgp router bgp 1 bgp router-id 192.168.1.2 address-family ipv4 unicast ! neighbor 1.1.1.100 remote-as 1 update-source Loopback77 address-family ipv4 unicast route-reflector-client ! ! neighbor 10.210.0.4 remote-as 1 update-source Loopback77 address-family ipv4 unicast route-reflector-client ! | RP/0/8/CPU0:R1#show run router bgp router bgp 65001 bgp router-id 10.210.0.2 address-family ipv4 unicast network 10.210.0.2/32 network 10.220.0.2/32 ! neighbor 11.11.11.2 remote-as 1 address-family ipv4 unicast route-policy bgp_all in route-policy bgp_all out ! |
Configuration notes: there is route-policy bgp_all for ingress and egress directions for eBGP connections on “PE1” and “R1” which are just passing all prefixes. Without these policies there will be no prefix exchange over eBGP peering and it is expected IOS-SR behavior.
BGP prefixes on all routers:
RP/0/1/CPU0:PE1#show bgp
BGP router identifier 1.1.1.100, local AS number 1
<the rest is omitted>
Network Next Hop Metric LocPrf Weight Path
*>i10.20.30.1/32 10.210.0.4 0 100 0 i
*> 10.210.0.2/32 11.11.11.1 0 0 65001 i
*> 10.220.0.2/32 11.11.11.1 0 0 65001 i
RP/0/4/CPU0:PE2#show bgp
BGP router identifier 10.210.0.4, local AS number 1
<the rest is omitted>
Network Next Hop Metric LocPrf Weight Path
*> 10.20.30.1/32 0.0.0.0 0 32768 i
*>i10.210.0.2/32 1.1.1.100 0 100 0 65001 i
*>i10.220.0.2/32 1.1.1.100 0 100 0 65001 i
RP/0/8/CPU0:R1#show bgp
BGP router identifier 10.210.0.2, local AS number 65001
<the rest is omitted>
Network Next Hop Metric LocPrf Weight Path
*> 10.20.30.1/32 11.11.11.2 0 1 i
*> 10.210.0.2/32 0.0.0.0 0 32768 i
*> 10.220.0.2/32 0.0.0.0 0 32768 i
At the beginning we have traffic from “R1” sourced from interface Loopback0 and Loopback1
destined to Loopback1 interface on “PE2”
RP/0/8/CPU0:R1#show run int lo 0
interface Loopback0
ipv4 address 10.210.0.2 255.255.255.255
!
RP/0/8/CPU0:R1#show run int lo 1
interface Loopback1
ipv4 address 10.220.0.2 255.255.255.255
!
RP/0/4/CPU0:PE2#show run int lo 1
interface Loopback0
ipv4 address 10.20.30.1 255.255.255.255
!
RP/0/8/CPU0:R1#ping 10.20.30.1 source Loop0 count 10
Sending 10, 100-byte ICMP Echos to 10.20.30.1, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 2/3/5 ms
RP/0/8/CPU0:R1#ping 10.20.30.1 source Loop1 count 10
Sending 10, 100-byte ICMP Echos to 10.20.30.1, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 2/3/7 ms
As you can see both traffic flows are going OK.
If we check CEF entries for each particular prefix on “PE1” we see:
RP/0/1/CPU0:PE1#show cef 10.220.0.2/32
<the rest is omitted>
Prefix Len 32, traffic index 0, precedence routine (0)
via 11.11.11.1, 2 dependencies, recursive, bgp-ext [flags 0x20]
path-idx 0
next hop 11.11.11.1 via 11.11.11.1/32
Load distribution: 0 (refcount 1)
Hash OK Interface Address
0 Y GigabitEthernet0/3/3/1 11.11.11.1
RP/0/1/CPU0:PE1#show cef 10.210.0.2/32 det
<the rest is omitted>
Prefix Len 32, traffic index 0, precedence routine (0)
via 11.11.11.1, 2 dependencies, recursive, bgp-ext [flags 0x20]
path-idx 0
next hop 11.11.11.1 via 11.11.11.1/32
Load distribution: 0 (refcount 1)
Hash OK Interface Address
0 Y GigabitEthernet0/3/3/1 11.11.11.1
RP/0/1/CPU0:PE1#show cef 10.20.30.1/32 det
<the rest is omitted>
Prefix Len 32, traffic index 0, precedence routine (0)
via 10.210.0.4, 2 dependencies, recursive [flags 0x0]
path-idx 0
next hop 10.210.0.4 via 10.210.0.4/32
Load distribution: 0 (refcount 1)
Hash OK Interface Address
0 Y GigabitEthernet0/2/0/4 10.10.10.1
Now, as we agreed, let’s decide for the test that the traffic form Loopback0 on “R1” is “attack” traffic and traffic from Loopback1 on “R1” is the “legitimate” traffic. Again it is done for the simplicity of the test.
Of course, in real life, we need to identify what is attack related traffic’s parameters and there are many tools and techniques to do it. NetFlow is one of these and let’s try this one to see how it may help.
Let’s have simple NetFlow configured on the “PE1” on the interface facing the “R1”, i.e on gi 0/3/3/1.
RP/0/1/CPU0:PE1#show run int gig 0/3/3/1
interface GigabitEthernet0/3/3/1
ipv4 address 11.11.11.2 255.255.255.0
flow ipv4 monitor RTBH sampler RTBH ingress
!
RP/0/1/CPU0:PE1#show run flow monitor-map RTBH
flow monitor-map RTBH
record ipv4
!
RP/0/1/CPU0:PE1#sh run sampler-map RTBH
sampler-map RTBH
random 1 out-of 1
!
The detail configuration of NetFlow on IOS-XR is out of the scope of this document.
Now, using NetFlow we can verify what the source address of the attacker is and what is the destination of the attack and check how many packets are being sent.
RP/0/1/CPU0:PE1#show flow monitor RTBH cache for reco loc 0/3/cpu0
<the rest is omitted>
========== Record number: 1 ==========
IPV4SrcAddr : 10.210.0.2
IPV4DstAddr : 10.20.30.1
L4SrcPort : 0
L4DestPort : 0
BGPDstOrigAS : 0
BGPSrcOrigAS : 0
BGPNextHopV4 : 10.210.0.4
IPV4DstPrfxLen : 32
IPV4SrcPrfxLen : 32
IPV4Prot : icmp
IPV4TOS : 0
InputInterface : Gi0/3/3/1
OutputInterface : Gi0/2/0/4
L4TCPFlags : 0
ForwardStatus : Fwd
FirstSwitched : 48 02:39:49:889
LastSwitched : 48 02:39:49:923
ByteCount : 1000
PacketCount : 10
Dir : Ing
SamplerID : 2
========== Record number: 2 ==========
IPV4SrcAddr : 10.220.0.2
IPV4DstAddr : 10.20.30.1
L4SrcPort : 0
L4DestPort : 0
BGPDstOrigAS : 0
BGPSrcOrigAS : 0
BGPNextHopV4 : 10.210.0.4
IPV4DstPrfxLen : 32
IPV4SrcPrfxLen : 32
IPV4Prot : icmp
IPV4TOS : 0
InputInterface : Gi0/3/3/1
OutputInterface : Gi0/2/0/4
L4TCPFlags : 0
ForwardStatus : Fwd
FirstSwitched : 48 02:39:47:411
LastSwitched : 48 02:39:47:447
ByteCount : 1000
PacketCount : 10
Dir : Ing
SamplerID : 2
Again, detailed explanation of the NetFlow configuration and functionality is out of the scope of this document, but provided example shows how helpful it might be.
Now, let’s make initial configuration for IPv4 RTBH.
To achieve that we have to have static route configured on PE routers and on the RR
and redistribute static routing into the BGP.
The IP address used for the static route may come from an RFC 1918 address or simply the 192.0.2.0/24 address allocated by IANA for use in documentation. The 192.0.2.0/24 address commonly known as test-net finds its use in internetworking documentation so that its verbatim use does not cause problems on the Internet.
In our test we are using IP address from the network 192.0.2.0/24 and redistributing the static route into BGP using route-policy RTBH, setting local preference as 200, origin as igp and community as no-export.
We can add additional setting if we need them, of course.
On “RR” router:
RP/0/RP0/CPU0:RR#show run router bgp
router bgp 1
bgp router-id 192.168.1.2
address-family ipv4 unicast
redistribute static route-policy RTBH <<<
!
RP/0/RP0/CPU0:RR#show rpl route-policy RTBH
route-policy RTBH
if tag eq 666 then
set next-hop 192.0.2.1
set local-preference 200
set community (no-export)
set origin igp
endif
end-policy
!
RP/0/1/CPU0:RR#sh run router static
router static
address-family ipv4 unicast
192.0.2.1/32 Null0
On “PE1” router:
RP/0/1/CPU0:PE1#sh run router static
router static
address-family ipv4 unicast
192.0.2.1/32 Null0
The above configuration is essential for IPv4 BGP RTBH on trigger device with is in our case CRS working as RR and on PE device. The trigger device is not necessarily an RR, it may be PE or even separate device, but it has to have iBGP peering with all PEs.
So now we have initial configuration and ready to deploy IPv4 RTBH.
DESTINATION BASED IPv4 RTBH
As we know the traffic from interface Loopback 0 on “R1” is attack destined to loopback address on “PE2”, so let’s try to block all traffic destined to the PE2’s loopback address, i.e. implement destination-based RTBH.
To do that let’s add the static route on the trigger device
RP/0/RP0/CPU0:RR(config)#router static
RP/0/RP0/CPU0:RR(config-static)#address-family ipv4 unicast
RP/0/RP0/CPU0:RR(config-static-afi)#10.20.30.1/32 NUll 0 tag 666
RP/0/RP0/CPU0:RR(config-static-afi)#commit
Now on “PE1” device we see:
RP/0/1/CPU0:PE1#sh cef 10.20.30.1/32 det
<the rest is omitted>
next hop 192.0.2.1 via 192.0.2.1/32
Load distribution: 0 (refcount 1)
Hash OK Interface Address
0 Y Unknown null0
So, as expected, if we start “attack” traffic from “R1” we see drops:
RP/0/8/CPU0:R1#ping 10.20.30.1 source Loop0 count 10
Sending 10, 100-byte ICMP Echos to 10.20.30.1, timeout is 2 seconds:
..........
Success rate is 0 percent (0/10)
Great, we block the “attack” traffic and everything is OK. Right? No!
Check the “legitimate” traffic which is in our test traffic from R1’s loopback 1 towards PE2’s loopback
RP/0/8/CPU0:R1#ping 10.20.30.1 source Loop1 count 10
Sending 10, 100-byte ICMP Echos to 10.20.30.1, timeout is 2 seconds:
..........
Success rate is 0 percent (0/10)
So, as you can see the legitimate traffic is being dropped as well and that is the big disadvantage of destination based RTBH. We may consider this technique to be used in case the source address of the attacker cannot be identified because of some reasons and there is one connection to AS where attack traffic is coming from and the only option to “defend” the host under attack is to drop all traffic which is destined towards this host coming from this particular AS.
We may implement much better approach if we will use:
SOURCE BASED IPv4 RTBH.
First, let’s add uRPF loose mode on the PE1’s interface facing the “R1”.
P/0/1/CPU0:PE1#sh run int gig 0/3/3/1
interface GigabitEthernet0/3/3/1
ipv4 address 11.11.11.2 255.255.255.0
ipv4 verify unicast source reachable-via any <<<
flow ipv4 monitor RTBH sampler RTBH ingress
Then, change the static router configuration on “RR” and use source address instead of destination one
RP/0/RP0/CPU0:RR(config)#router static
RP/0/RP0/CPU0:RR(config-static)#address-family ipv4 unicast
RP/0/RP0/CPU0:RR(config-static-afi)#10.210.0.2/32 Null 0 tag 666 <<<
RP/0/RP0/CPU0:RR(config-static-afi)#commit
Now, as we can see “attack” traffic is being dropped:
RP/0/8/CPU0:R1#ping 10.20.30.1 source Loop0 count 10
Sending 10, 100-byte ICMP Echos to 10.20.30.1, timeout is 2 seconds:
..........
Success rate is 0 percent (0/10)
RP/0/1/CPU0:PE1#sh bgp
BGP router identifier 1.1.1.100, local AS number 1
<the rest is omitted>
Network Next Hop Metric LocPrf Weight Path
*>i10.20.30.1/32 10.210.0.4 0 100 0 i
* 10.210.0.2/32 11.11.11.1 0 0 65001 i
*>i 192.0.2.1 0 200 0 i
*> 10.220.0.2/32 11.11.11.1 0 0 65001 i
Prefix 10.210.0.2/32 in BGP is currently has next-hop 192.0.2.1 which is in our case pointed to Null 0
And since we have Loose uRPF configured on interface gi 0/3/3/1, uRPF checks the packet and forwards it if there is a route entry for the source IP of the incoming packet in the router FIB. If the router does not have an FIB entry for the source IP address, or if the entry points to Null0, the Reverse Path Forwarding (RPF) check fails, and the packet is dropped. In our case FIB entry pointing to a Null 0.
RP/0/1/CPU0:PE1#sh cef 10.210.0.2/32 det
<the rest is omitted>
next hop 192.0.2.1 via 192.0.2.1/32
Load distribution: 0 (refcount 1)
Hash OK Interface Address
0 Y Unknown null0
At the same time, for the “legitimate” traffic we have:
RP/0/1/CPU0:PE1#sh cef 10.220.0.2/32 det
<the rest is omitted>
next hop 11.11.11.1 via 11.11.11.1/32
Load distribution: 0 (refcount 1)
Hash OK Interface Address
0 Y GigabitEthernet0/3/3/1 11.11.11.1
RP/0/8/CPU0:R1#ping 10.20.30.1 source Loop1 count 10
Sending 10, 100-byte ICMP Echos to 10.20.30.1, timeout is 2 seconds:
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 2/3/4 ms
So now “legitimate” traffic is passing through, while attack traffic is being dropped.
NETWORK TOPOLOGY AND INITIAL CONFIGURATION for VPNv4 RTBH:
In this section the following topology will be used to demonstrate how to use Source based RTBH on IOS-XR platforms and we ill skip the Destination based one.
Please noted in current examples XR12000 is used, so command outputs might slightly differ on ASR9000 and CRS platforms
And some information about IGP, MPLS LDP and other features configuration not directly related to tested scenarios has been skipped to make the document more readable and avoid unnecessary details.
The same is related to the provided output of “show...” commands to omit details which are not relevant to the topic.
The simplified topology shows Service Provider BGP AS 1 and VPN “ABC”.
“PE1” and “PE2” routers in SP AS1 are XR12K and these two devices have iBGP peering with Route-Reflector “RR” which is CRS-1 router. In addition to that, PE1 has eBGP peering with router “R1” XR12K router in VPN “ABC”
For testing purposes and simplification of tests let’s consider that host under attack is interface loopback 1 on “PE2” and, again, for the test, router “R1” is generating “legitimate” and “attack” traffic.
As a trigger device we again will use “RR”.
Initial configuration includes:
“PE1” | PE2” |
RP/0/1/CPU0:PE1#show run router bgp router bgp 1 bgp router-id 1.1.1.100 address-family ipv4 unicast ! address-family vpnv4 unicast ! neighbor 192.168.1.2 remote-as 1 update-source Loopback0 address-family vpnv4 unicast next-hop-self ! ! vrf ABC rd 100:100 address-family ipv4 unicast ! neighbor 11.11.11.1 remote-as 65001 address-family ipv4 unicast route-policy bgp_all in route-policy bgp_all out ! RP/0/1/CPU0:PE1#sh run vrf ABC vrf ABC address-family ipv4 unicast import route-target 100:100 ! export route-target 100:100 ! | RP/0/4/CPU0:PE2#show run router bgp router bgp 1 bgp router-id 10.210.0.4 address-family ipv4 unicast ! address-family vpnv4 unicast ! neighbor 192.168.1.2 remote-as 1 update-source Loopback0 address-family vpnv4 unicast next-hop-self ! ! vrf ABC rd 100:100 address-family ipv4 unicast network 10.20.30.1/32 ! ! RP/0/4/CPU0:PE2#sh run int lo1 interface Loopback1 vrf ABC ipv4 address 10.20.30.1 255.255.255.255 |
“RR” | “R1” |
RP/0/RP0/CPU0:RR#show run router bgp router bgp 1 bgp router-id 192.168.1.2 address-family ipv4 unicast ! address-family vpnv4 unicast ! neighbor 1.1.1.100 remote-as 1 update-source Loopback77 address-family vpnv4 unicast route-reflector-client ! ! neighbor 10.210.0.4 remote-as 1 update-source Loopback77 address-family vpnv4 unicast route-reflector-client ! ! | RP/0/8/CPU0:R1#show run router bgp router bgp 65001 bgp router-id 10.210.0.2 address-family ipv4 unicast network 10.210.0.2/32 network 10.220.0.2/32 ! neighbor 11.11.11.2 remote-as 1 address-family ipv4 unicast route-policy bgp_all in route-policy bgp_all out ! |
Configuration notes: there is route-policy bgp_all for ingress and egress directions for eBGP connections on “PE1” and “R1” which are just passing all prefixes. Without these policies there will be no prefix exchange over eBGP peering. Configuration on “PE1” and “PE2” changed a little bit and only VPNv4 address family is active between PE’s and route-reflector which is enough for the test. VRF configuration is quite simple, but again is enough for the intended test.
Normally, on the route-reflector we don’t have configured VRF, but in our case we would like to use “RR”
as a trigger device and so, we need to send BGP update in a VRF. therefore, we may either configured each VRF on “RR” or used some other techniques, like configuring “dummy” VRF and configuring route-policy, but tuning of the BGP configuration is out of scope of this text, so let’s go by simplest way.
So, for the simplicity, let’s create the VRF on “RR”
RP/0/RP0/CPU0:RR#show run router bgp
router bgp 1
<the rest is omitted and still the same as before>
vrf ABC
rd 100:100
address-family ipv4 unicast
redistribute static route-policy RTBH
!
RP/0/RP0/CPU0:RR#show rpl route-policy RTBH
route-policy RTBH
if tag eq 666 then
set next-hop 192.0.2.1
set local-preference 200
set community (666:666) - it will be used later
set origin igp
endif
end-policy
RP/0/RP0/CPU0:RR#show run vrf ABC
vrf ABC
address-family ipv4 unicast
import route-target
100:100
!
export route-target
100:100
!
As you can see the configuration is pretty straightforward and hardly requires any additional comments
So, it looks like we have the initial configuration and ready to go.
As it has been mentioned we are not going to cover destination based VPNv4 RTBH and only source based one will be configured and verified.
SOURCE BASED VPNv4 RTBH.
First, let’s add static route for the same IP address as we used in IPv4 configuration on the trigger device and PE.
RP/0/RP0/CPU0:RR#sh run router static vrf ABC
router static
vrf ABC
address-family ipv4 unicast
192.0.2.1/32 Null0
!
RP/0/1/CPU0:PE1#sh run router static vrf ABC
router static
vrf ABC
address-family ipv4 unicast
192.0.2.1/32 Null0
!
Then, again add uRPF loose mode on the PE1’s interface facing the “R1”
RP/0/1/CPU0:PE1#sh run int gig 0/3/3/1
interface GigabitEthernet0/3/3/1
vrf ABC
ipv4 address 11.11.11.2 255.255.255.0
ipv4 verify unicast source reachable-via any
flow ipv4 monitor RTBH sampler RTBH ingress
Note: NeFlow configuration is still the same under the interface level and from sampler-map and monitor-map point of view.
And, again, using NetFlow we can verify what the source address of the attacker is and what is the destination of the attack and check how many packets are being sent, for example.
RP/0/1/CPU0:PE1#show flow monitor RTBH cach for record loc 0/3/cpu0
<the rest is omitted>
========== Record number: 1 ==========
IPV4SrcAddr : 10.210.0.2
IPV4DstAddr : 10.20.30.1
L4SrcPort : 0
L4DestPort : 0
BGPDstOrigAS : 0
BGPSrcOrigAS : 0
BGPNextHopV4 : 10.210.0.4
IPV4DstPrfxLen : 32
IPV4SrcPrfxLen : 32
IPV4Prot : icmp
IPV4TOS : 0
InputInterface : Gi0/3/3/1
OutputInterface : Gi0/2/0/4
L4TCPFlags : 0
ForwardStatus : Fwd
FirstSwitched : 01 09:06:15:461
LastSwitched : 01 09:06:15:497
ByteCount : 1000
PacketCount : 10
Dir : Ing
SamplerID : 2
Remember, we considered before that the traffic from interface Loopback0 on “R1” is attack one and traffic from Loopback1 on “R1” is the legitimate one. So let’s block the source address of the attacker like we have done in IPv4 scenario.
To do that let’s add the static route on the trigger device
RP/0/RP0/CPU0:RR#sh run router static vrf ABC
router static
vrf ABC
address-family ipv4 unicast
10.210.0.2/32 Null0 tag 666 <<< added source address
192.0.2.1/32 Null0
So, now we expect to have incoming traffic is being dropped by uRPF on ingress interface on “PE1”
Let’s check the BGP table on “PE1”:
RP/0/1/CPU0:PE1#sh bgp vpnv4 unicast
BGP router identifier 1.1.1.100, local AS number 1
<the rest is omitted>
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:100 (default for vrf ABC)
*>i10.20.30.1/32 10.210.0.4 0 100 0 i
* 10.210.0.2/32 11.11.11.1 0 0 65001 i
*>i 192.168.1.2 0 200 0 i
*> 10.220.0.2/32 11.11.11.1 0 0 65001 i
And, strangely, for the prefix 10.210.0.2/32 next-hop is 192.168.1.2 which is the peering address of RR and not 192.0.2.1 as we may expect.
The reason is for VPNv4 prefixes next-hop address will be always set to a peer address, unless it hasn’t been modified explicitly.
So, let’s modify the configuration a little bit on “RR”
RP/0/RP0/CPU0:RR#show run router bgp
<the rest is omitted>
neighbor 1.1.1.100
remote-as 1
update-source Loopback77
address-family vpnv4 unicast
route-reflector-client
route-policy sam-out out <<<
RP/0/RP0/CPU0:RR#show rpl route-policy sam-out
route-policy sam-out
if community matches-any (666:666) then
set next-hop 192.0.2.1
else
pass
endif
end-policy
After that we have on “PE1”:
RP/0/1/CPU0:PE1#sh bgp vpnv4 unicast
BGP router identifier 1.1.1.100, local AS number 1
<the rest is omitted>
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:100 (default for vrf ABC)
*>i10.20.30.1/32 10.210.0.4 0 100 0 i
*> 10.210.0.2/32 11.11.11.1 0 0 65001 i
* i 192.0.2.1 0 200 0 i
*> 10.220.0.2/32 11.11.11.1 0 0 65001 i
So, now the next-hop seems to be right. Let’s verify it a little bit deeper.
RP/0/1/CPU0:PE1#show bgp vrf ABC 10.210.0.2/32
BGP routing table entry for 10.210.0.2/32, Route Distinguisher: 100:100
<the rest is omitted>
Local
192.0.2.1 (inaccessible) from 192.168.1.2 (192.168.1.2)
Received Label 16023
Origin IGP, metric 0, localpref 200, valid, internal, import-candidate, imported
Received Path ID 0, Local Path ID 0, version 0
Community: 666:666
Extended community: RT:100:100
And as you can see there is an issue with the next hop because it is inaccessible
The reason is because the next-hop resolution process for the VPNv4 routes will use the global routing table and the static route for 192.0.2.1/32 therefore needs to be configured in the global routing table:
RP/0/1/CPU0:PE1#conf t
RP/0/1/CPU0:PE1(config)#router static
RP/0/1/CPU0:PE1(config-static)#address-family ipv4 uni
RP/0/1/CPU0:PE1(config-static-afi)#192.0.2.1/32 null 0
RP/0/1/CPU0:PE1(config-static-afi)#commit
RP/0/1/CPU0:PE1#sh bgp vrf ABC 10.210.0.2/32
<the rest is omitted>
Local
192.0.2.1 from 192.168.1.2 (192.168.1.2)
Received Label 16023
Origin IGP, metric 0, localpref 200, valid, internal, best, group-best, import-candidate, imported, import suspect
Received Path ID 0, Local Path ID 1, version 25
Community: 666:666
Extended community: RT:100:100
So now the BGP next-hop and FIB entry seems to be OK. And finally, let’s verify the “attack” traffic is blocked and “legitimate” traffic is reaching the destination.
RP/0/8/CPU0:R1#ping 10.20.30.1 source Loop0 count 5
Sending 5, 100-byte ICMP Echos to 10.20.30.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
RP/0/8/CPU0:R1#ping 10.20.30.1 source Loop1 count 5
Sending 5, 100-byte ICMP Echos to 10.20.30.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/3/4 ms
Of course, there are many ways to tune this configuration and apply additional policies, but as it has been mentioned, the idea of this test is give the understanding how the RTBH works and how it can be used to in some particular scenarios.
If you have any questions, suggestions or want to add something to the subject being discussed, please post your input in the comments section.
