Cisco BGP RTBH Setup with ISP – How to Configure

bgpciscoisprouting

I had a discussion a while ago, related how to stop DDoS. Read this first: BGP null route when DDoS?

Finally, we talked to the ISP, and it agreed on setting up a BGP trigger so the next time a DDoS happens, we can trigger RTBH to null route (DDoS) the target IP address to stop traffic at the PE.

Question: I am not an expert in BGP, so my question is how/what I need to configure on my router, and how can I trigger a null route from my router so it will null traffic at the ISP edge router?

Scenario in GNS:

Here i am trying to trigger RTBH from R2 router to R1 so it will null route 172.16.10.100 at R1 (ISP router), But its not working, what i am missing here?

R1: ISP Router
R2: My Router

I have configured iBGP between this two router and trying to simulate RTBH to understand.

R1:

Do i need to configure anything else on R1 to accept trigger?

R1(config)# router bgp 64520
...
...
R1(config)# ip route 192.0.2.1 255.255.255.255 Null0

R2:

R2(config)# route-map RTBH
R2(config-route-map)# match tag 666
R2(config-route-map)# set ip next-hop 192.0.2.1
R2(config-route-map)# set origin igp
R2(config-route-map)# set community no-export

R2(config)# router bgp 64520
R2(config-router)# redistribute static route-map RTBH

Trying to trigger Null route

R2(config)# ip route 172.16.10.100 255.255.255.255 Null0 tag 666

Best Answer

Most RTBH implementations at ISPs require you to announce a subnet (let it be a /32) with appropriate BGP community (again, at most ISPs it's 666) to trigger RTBH at PE.

It seems like you're on right track. I'd also check for something like set community additive 64520:666 on R2.

Related Solutions

Routing – BGP remote-triggered blackhole (RTBH) filter for Juniper

There is no reason to limit customer to blackhole only /32, allow them to blackhole anything from them.

Something like this:

policy-statement AS42-IN {
    term blackhole {
        from {
            community BLACKHOLE;
            prefix-list-filter AS42 orlonger;
        }
        then {
            community add NO-EXPORT;
            next-hop 192.0.2.1;
            accept;
        }
    }
    term advertise {
        from {
            prefix-list AS42;
        }
        then {
            community add ADVERTISE;
            next-hop peer-address;
            accept;
        }
    }
    term reject {
        then reject;
    }
}

Remember to set 'accept-remote-nexthop' under BGP settings, so that the next-hop can be changed to something else than link address.

I also strongly support that providers start to support different blackhole communities than just 'full blackhole'. Especially if you operate in more than one country usually attack is from transit and often customer actually mostly wants to access domestic peerings, so it's useful to implement several levels of blackhhole:

Full
Outside local country (local IXP, whole own AS + customers seen)
Outside local area (if applicable, like for me it could be 'Nordics')
Include/Exclude specific peering router in blackhole

I'm happy to give example how to implement something like this with JNPR DCU/SCU, provided your peering routers are JNPR, but it's possible with just communities, just bit more awkward.

If you absolutely want to limit your customer's options you can add this:

policy-statement /32 {
    term /32 {
        from {
            route-filter 0.0.0.0/0 prefix-length-range /32-/32;
        }
        then accept;
    }
    term reject {
        then reject;
    }
}

policy-statement AS42-IN {
    term blackhole {
        from {
            community BLACKHOLE;
            policy /32;
            prefix-list-filter AS42 orlonger;
        }
..
}

This way it should be logical AND. But I really don't see the value in creating complexity to reduce expressiveness of configuration.

Cisco – route tags and policy routing alternatives – traffic engineering question

I am not 100% sure whether tags are carried in BGP updates but here is what I put together pretty quick:

enter image description here

Router "Static":

interface Loopback0
 ip address 172.16.1.1 255.255.255.0
!
interface Loopback1
 ip address 172.16.2.1 255.255.255.0

interface Ethernet0/1
 ip address 172.16.0.1 255.255.255.0
 half-duplex

ip route 0.0.0.0 0.0.0.0 172.16.0.2

Router R1:

interface Ethernet0/0
 ip address 10.0.0.1 255.255.255.252
 half-duplex

interface Ethernet0/1
 ip address 172.16.0.2 255.255.255.0
 half-duplex

ip route 172.16.1.0 255.255.255.0 172.16.0.1 tag 20
ip route 172.16.2.0 255.255.255.0 172.16.0.1 tag 20

router eigrp 100
 redistribute static route-map MyRouteMap
 network 10.0.0.0 0.0.0.3
 no auto-summary

route-map MyRouteMap permit 10
 match tag 20

Router R2:

interface Ethernet0/0
 ip address 10.0.0.2 255.255.255.252
 half-duplex

interface Ethernet0/1
 ip address 10.0.0.5 255.255.255.252
 half-duplex

router eigrp 100
 network 10.0.0.0 0.0.0.3
 no auto-summary

router bgp 65000
 no synchronization
 bgp log-neighbor-changes
 redistribute eigrp 100 route-map MyRouteMap
 neighbor 10.0.0.6 remote-as 65000
 neighbor 10.0.0.6 next-hop-self
 no auto-summary

route-map MyRouteMap permit 10
 match tag 20

R2#show ip route 172.16.1.0
Routing entry for 172.16.1.0/24
  Known via "eigrp 100", distance 170, metric 307200
  Tag 20, type external

Router R3:

interface Ethernet0/1
 ip address 10.0.0.6 255.255.255.252
 half-duplex

router bgp 65000
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.0.0.5 remote-as 65000
 no auto-summary

R3#show ip bgp 172.16.1.0
BGP routing table entry for 172.16.1.0/24, version 3
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  Local
    10.0.0.5 from 10.0.0.5 (10.0.0.2)
      Origin incomplete, metric 307200, localpref 100, valid, internal, best

I hope this is what you were asking for.

Scenario in GNS:

Best Answer

Related Solutions

Routing – BGP remote-triggered blackhole (RTBH) filter for Juniper

Cisco – route tags and policy routing alternatives – traffic engineering question

Related Topic