Using Destination and Source based BGP RTBH on IOS-XR platforms.

Document

Dec 5, 2011 8:11 AM
Dec 5th, 2011

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”.

RTBH ipv4 topology.jpg

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”.

RTBH vpnv4 topology.jpg

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.

Average Rating: 0 (0 ratings)

Actions

Login or Register to take actions

This Document

Posted December 5, 2011 at 8:11 AM
Stats:
Comments:0 Avg. Rating:0
Views:3056 Contributors:0
Shares:0
Tags: No tags.