Let’s up the stakes for this contest by giving two questions instead of one unlike what we have done for previous contests. This contest will focus on the workings of the Border Gateway Protocol (BGP). The first question deals with how to tweak the default behavior of BGP to suit our needs. The second question presents a troubleshooting scenario which involves BGP.
Question 1: eBGP peering with Loopback interfaces
In the diagram below, an eBGP peering relationship should exist between R1 and R2 using their loopback interfaces.
The configuration on the routers as shown below does not work. There are at least two ways to get the eBGP peering relationship to form. Provide these solutions.
hostname R1 ! interface FastEthernet0/0 ip address 10.1.1.1 255.255.255.0 interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! router bgp 1 neighbor 2.2.2.2 remote-as 2 neighbor 2.2.2.2 update-source lo0 ! ip route 2.2.2.2 255.255.255.255 10.1.1.2
hostname R2 ! interface FastEthernet0/0 ip address 10.1.1.2 255.255.255.0 interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! router bgp 2 neighbor 1.1.1.1 remote-as 1 neighbor 1.1.1.1 update-source lo0 ! ip route 1.1.1.1 255.255.255.255 10.1.1.1
Question 2: Remotely Triggered Black Hole (RTBH)
Recent attacks against the web server (10.0.0.100) on the organization’s network shown below have prompted the network administrator to configure RTBH. The attacks come in from the Extranet interface to which the LAN network (10.0.0.0/24) is visible (i.e. no NAT). However, the administrator has not been able to determine the source of the attacks and so she has concluded that it is better to enable destination-based RTBH. R1 is the Edge router while R2 will serve as the trigger.
The configuration on R1 is as follows:
interface Ethernet0/0 description ***Extranet Interface*** ip address 172.16.1.1 255.255.255.0 interface Ethernet0/1 description ***Connected to LAN*** ip address 10.0.0.1 255.255.255.0 interface Ethernet0/2 description ***Connected to Trigger*** ip address 192.168.99.1 255.255.255.0 ! ip bgp-community new-format ip community-list 1 permit 99:1 ! route-map RTBH permit 10 match community 1 set ip next-hop 192.0.2.1 ! router bgp 1 neighbor 192.168.99.2 remote-as 1 neighbor 192.168.99.2 route-map RTBH in !
The configuration on R2 is as follows:
interface Ethernet0/0 ip address 192.168.99.2 255.255.255.0 ! ip bgp-community new-format ! route-map RTBH permit 10 match tag 99 set community 999:1 no-export ! router bgp 1 redistribute static route-map RTBH neighbor 192.168.99.1 remote-as 1
Some days after she added this configuration, she noticed another DoS attack occuring against the web server and entered the following command to put the RTBH to work:
ip route 10.0.0.100 255.255.255.255 null0 tag 99
To her dismay, the attack did not stop. There are three configuration errors in her RTBH configuration; spot them and fix them.
The winner of this contest has the following prize options:
- N3,000 sent to a Nigerian bank account
- Amazon gift card worth $15
- $15 sent to a PayPal account
Remember to subscribe via Email to receive updates about new contests and solutions. Success!
iContests 
Problem1: you need to add neighbor x.x.x.x next-hop-self on both routers or advertise both router’s connected interfaces in bgp.
LikeLike
Solution 1:
Method1:add neighbour disable-connected-check on both routers.
Method2: add neighbor ebgp-multihop 2
Solution 2:
Shortly……
LikeLike
Sol 1:
we actually have 3 solutions:
neigh x.x.x.x disable-connected-check
neigh x.x.x.x ebgp-multihop 2
neigh x.x.x.x ttl-securityhops 2
LikeLike
Question 1: This is fairly straight forward, quite rightly there are two ways
a. use ‘ neighbor x.x.x.x disable-connected-check’- Because by default, eBGP will only form when the neighbor is directly connected unless of course you using the command below.
b. use ‘ neighbor x.x.x.x ebgp-multihop 2. effectively increasing the TTL to 2. By default, TTL is 1 for eBGP
Question 2: – The edge router R1 is missing a static route to null0, to help blackhole the traffic
ip route 192.0.2.1 255.255.255.255 null0
– On R2, which serves as the trigger,
route-map RTBH permit 10
match tag 99
set community 99:1 no-export (change community value to match that expected by R1)
set origin igp
set ip next-hop 192.0.2.1 (set the next-hop so it will be blackholed)
!
LikeLike
Basically, R2 says to get to 10.0.0.100 the next-hop is 192.0.2.1 and sends it out as BGP update. R1 sees the nexthop for the prefix as 192.0.2.1, hence, because of the static null route it has, the traffic is blackholed thus protecting the server.
LikeLike
set origin igp
set ip next-hop 192.0.2.1 (set the next-hop so it will be blackholed)
Do we really need to add these 2 commands ?
When traffic for 10.0.0.100 comes to R2 from R1, R2 has null route in its routing table so its going to drop anyway…..
LikeLike
yes we need to set the nexthop. Hence the name Remotely Triggered blackhole routing. The trick here is about getting R2 to protect the server. This is done by setting the nexthop for the server IP address (10.0.0.100) to an address that will be blackholed. To do this, the edge routers (in this case R1) will drop the traffic immediately it gets into the network and prevents it from sending packets that R2 will eventually drop, thus saving BW and resources. Imagine if we had a Larger AS domain, this is a quick way to quickly protect the server from attacks. The server is protected in the next bgp update message.
‘I see it as nipping it at the bud’, quite literally, stopping the traffic at its entry point.
origin is set to IGP, cos you know IGP>EGP>? in the BGP path algorithm. This isnt entirely necessary tbh.
Some best practices advise local preference as well as origin be set.
LikeLike