Redirect inbound traffic to another router not running BGP

Question

People,

I've two routers on my ISP's core. First of them is a bit old Cisco gear, which is where I have eBGP sessions with my upstreams, IX and downstreams. The second is a MikroTik CCR, which act as DHCP Server, firewall, etc. for my customers.

Due to increasing of our network, the old Cisco router is not being able to deal with all current traffic fluidly, but because of internal reasons we can't change it to another gear for now.

I'm considering redirect all incoming traffic directly to MikroTik gear, in a such way it doesn't need to be routed by Cisco one. But I'm not sure it is possible.

I use a /29 range with each of my upstreams, so I can have MikroTik router addressed within same range as my and upstream's border routers. Ex.:

• Upstream's 1st router: 198.51.100.1/29
• Upstream's 2nd router: 198.51.100.2/29
• My Cisco router: 198.51.100.6/29
• My MikroTik router: 198.51.100.5/29

192.0.2.1 is default gateway for MikroTik router (192.0.2.2).

It would be easy to get this solved using as-path prepend if MikroTik gear was running BGP, but it isn't and can't get being for technical and commercial reasons.

I thought the redirection could be done by changing advertised prefixes' BGP next-hop attribute to MikroTik router's IP address, in the following way (in conformance with above network diagram):

route-map CHANGE_NEXTHOP permit 10
 set ip next-hop 198.51.100.5
!
router bgp XXXXXX
 neighbor 198.51.100.1 route-map CHANGE_NEXTHOP out
 neighbor 198.51.100.2 route-map CHANGE_NEXTHOP out
!

That way, upload traffic would flow through direct connection between both routers, whereas download traffic would flow from upstreams directly to MikroTik router.

However, I read somewhere this is only possible when BGP sessions are multihop, not when neighbors are directly connected. Moreover, from what I understood, changing next-hop is an iBGP only feature.

I'm far from being a Cisco expert and searched a lot but found no conclusive answer to my doubts, so could somebody tell me if is it possible to do what I described in above config. snippet or suggest any solution to my tricky situation?

Unfortunately I currently have no ways to run it on a lab (even using virtual machines) to test if works as intended.

I will be thankful for this and any further information you provide.

Answer 1

There may be a way to acheive this by exploiting the following BGP next hop rule:

From RFC 4271, 5.1.3 NEXT_HOP:

When sending a message to an external peer, X, and the peer is one IP hop away from the speaker:

- If the route being announced was learned from an internal peer or is locally originated, the BGP speaker can use an interface address of the internal peer router (or the internal router) through which the announced network is reachable for the speaker for the NEXT_HOP attribute, provided that peer X shares a common subnet with this address. This is a form of "third party" NEXT_HOP attribute.

Could you try this:

• Remove the OSPF adjacency between Cisco and Mikrotik on network 192.168.2.0/30

• Create the OSPF adjacency between the Cisco and Mikrotik routers across the shared network 198.51.100.0/29

• Make sure that the routes the Cisco router is learning via OSPF have a next hop of 198.51.100.5

• Clear the BGP sessions. The Cisco router should now advertise routes to internal subnets with a BGP NEXT_HOP of 198.51.100.5

This article shows an example:

http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/26634-bgp-toc.html

BGP Next Hop (Multiaccess Networks)

This example shows how the next hop behaves on a multiaccess network such as Ethernet.

Assume that RTC and RTD in AS300 run OSPF. RTC runs BGP with RTA. RTC can reach network 180.20.0.0 via 170.10.20.3. When RTC sends a BGP update to RTA with regard to 180.20.0.0, RTC uses as next hop 170.10.20.3. RTC does not use its own IP address, 170.10.20.2. RTC uses this address because the network between RTA, RTC, and RTD is a multiaccess network. The RTA use of RTD as a next hop to reach 180.20.0.0 is more sensible than the extra hop via RTC. Note: RTC advertises 180.20.0.0 to RTA with a next hop 170.10.20.3. If the common medium to RTA, RTC, and RTD is not multiaccess, but NBMA, further complications occur.

Answer 2

I assume that you want to affect INBOUND internet traffic, and you know how to handle your OUTBOUND traffic.

Then the easiest way to accomplish this would be to do "as-path prepending" on your Cisco router when it's advertising to its upstream. Then, your INBOUND internet traffic would definitely take the shortest as-path towards you, which will be through the MikroTik router.

To see an example, see this.

Answer 3

Create a vrrp address for the cisco and mikrotik and make that the default gateway from the core switch. Set the mikrotik as the higher priority member.

The mikrotik should have a default route received from the cisco router and a from "my network", preferring "my network" as the preferential route. This can be via OSPF or statically assigned.

Have an IP SLA probe either from the microtik or cisco to check the upstream connectivity to "my network". If there is a problem upstream, reduce the vrrp priority on the mikrotik router so traffic will head out via the cisco instead.

In the setup, you will have redundundancy and you would not have any issues with incoming traffic via the cisco assuming you are natting incoming traffic on the cisco. Incoming and outgoing traffic will be taking different paths.

Answer 4

MicroTik supports BGP. Redirecting inbound traffic may require you to run BGP.