7

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

Network diagram - core

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.

  • Perhaps I'm misunderstanding what you're trying to accomplish, but how would configuring what you describe help you not needing to do eBGP on that Cisco router? A network diagram may help a lot here, but what you're doing here won't work how you intend to. Also, what's 192.51.100.5? – Teun Vink Aug 20 '15 at 5:12
  • Are they all connected to the same segment and do you run any internal routing protocol between the Cisco router and MikroTik device? Would also be helpful to know if this is an Ethernet segment or something else. Default behaviour for ethernet seems to be to not change advertised next-hop address when advertised on the same segment as the next-hop address. I tried this in a small lab with 4 routers connected by a switch and on the cisco router I used a static route pointing to MikroTik as next-hop for networks connected to it and advertised routes got MikroTik as next-hop automatically. – Jimmy Aug 20 '15 at 6:02
  • @TeunVink I need to keep eBGP on Cisco router, but it can't deal with all our current network traffic anymore. There is no 192.51.100.5... but 198.51.100.5 is my MikroTik router, as described. – Tiago.SR Aug 20 '15 at 18:08
  • @Jimmy Cisco router is directly connected to my dedicated circuits with upstreams. MikroTik router can be added to same Ethernet segment by VLAN and bridge, becoming the 198.51.100.5. It's Ethernet. I'm trying to change this default behavior by manually setting next-hop to MikroTik router's IP address using set ip next-hop... on Cisco. I'll draw a network diagram and update original post as soon as possible. – Tiago.SR Aug 20 '15 at 18:14
  • 1
    AFAIK next-hop modification can be used to traffic balancing in described way. Generally it must work, at least from Mikrotik point of view, but it depend on upstream router configuration. For example filters on upstream can prohibit such announces. – mmv-ru Jun 14 '16 at 12:42
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)

enter image description here

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.

0

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.

  • Thanks, you nearly understood it, except MikroTik gear is not running BGP and it is not possible to change this. It's mainly because of this detail I'm failing on get a solution to this problem. – Tiago.SR Aug 24 '15 at 1:33
  • while AS-PATH prepending is commonly cited as a solution to direct traffic to a specific BGP router, it is not very efficient, many upstream refuse to propagate prefixes with more than 3 occurrence of the AS number, and some traffic will still come the "backup" router. – JFL Apr 20 '16 at 6:48
  • @JFL that's not quite true - AS Path pre-pending is a perfectly valid way of de-preferencing inbound traffic. The only traffic it will not affect is that from the directly attached upstream AS and their clients - they will more often than not still use Local-Preference internally to send traffic to you via their link, rather than another AS – Benjamin Dale Aug 18 '16 at 11:14
0

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.

0

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.