Looking through the Internet, there are much howto’s specially in the OpenSource field but a guide line for a redundant and secure internet connection based on BGP (full table) is not something you find on many sites. So I thought I write such a documentation and I’m hoping it helps some networks admins in setting up their company internet connection. BGP is not that hard ;-).

General conditions

Following points are the general conditions for this howto:

Two Internet Uplinks to two different providers, each connected via one fibre link

One provides the BGP peer in the same VLAN and one peer is only reachable via a routing hop (to show the different configuration)

One provider hands the customer only one peering IP address and the other two (to show the different configuration)

We use 2 BGP routers on our side for redundancy

Both provide IPv4 and IPv6 Full Tables

No traffic engineering to steer traffic to one provider over the other is done

A failure of

one router must not change anything for the user/customer

one switch is allowed to lose one Uplink but not both, so traffic for the user/customers needs to be unaffected

one fibre link leads to one Uplink down, but the traffic for the user/customers needs to be unaffected

Secure setup

Setting up the layer 2 switches and the redundant firewall behind the routers is not part of this howto

Using Mikrotik RouterOS devices as the routers in the config part, but the same setup would also work with Cisco or Vayatta routers, which I’ve also used for BGP based Internet connections.

Setup

Following drawing shows the setup for the BGP Internet connection.

As you see I’m using 2 switches as media converters and to distribute the provider transit networks to both routers. Why I do this as there are Mikrotik routers with SPF and SPF+ modules? First using a Mikrotik on a x86 provides you with no switching (just bridging). Secondly even if you use a Mikrotik Hardware router with switching support, a switch that is only used for layer 2 stuff and has no IP interface in the public networks (only in the management network) will be more stable specially concerning firmware updates than routers which are used for active interaction with other systems. No update for multiple years is not uncommon for switches in this scenario, which is not valid for the routers, specially if you use some special features on the routers. This means you can update a router without the Ethernet link to the provider going down and as the Mikrotik boots under 30 seconds its a minimal impact. The default switching time for BGP is 180 seconds (3*60 seconds) which is much longer than a boot after a firmware update.

Configuration of the routers

If not specified the configuration is the same for both routers and the syntax works with RouterOS 6.10, but it does not change that much normally, at least not since version 4 when I started using Mikrotiks.

First we start with the names of the routers

BGP1:/system identity set name=bgp1

BGP2:/system identity set name=bgp2

And now to the actual work – we need to configure our interfaces. We create a loopback interface for at least following reasons:

This interface is always up, so the IP address is always up – good for monitoring the node vs interfaces

As Mikrotik allows to rename the interface we do so as it makes configuration lines which use these interfaces much easier to understand … believe me I’ve routers with > 100 interfaces :-). For the transit network to the firewall we’ll setup a VRRP and to be somewhat more secure than normal VRRP we also set a long and random password. We configure also a no default VRID, as most system use 1 as default and who knows what the firewalls use. 😉

Now we add our static routes we need. We need to set one for our management network, so we can be reached via the admin computers and set the route for provider 1 as the BGP routers are not in the same subnet. Also the router to the firewalls for our internal network is clear, but we need one more feature which needs some explaining. If the link to the firewalls goes down on a router, the IP address / network also goes down and its routes over this interface. As the router redistributes the connected and static routes via BGP it will not anymore send it out. This is basically ok, but now something comes into play that is called “BGP Route Flap Damping“, which can lead to the problem that everything is running again but some AS are not setting traffic to you for some time. So it is paramount to keep the announcing running as stable as possible, which leads us to black hole routes. As in IPv6 Mikrotik does not support it (as of yet) we use a workaround to accomplish the same. PS: you can use the same to black hole an attacker .. really fast and without much load on the system … just saying 🙂

After the IP addresses and static routes are configured we need to secure our setup before doing anything else. As the BGP routers are in front of the firewalls they can get attacked directly from the Internet, sure, but traffic (e.g. attacks, P2P, …) to systems behind it can also make problems for the routers, so we’ll do something that we normally don’t do. We’ll disable connection tracking – we are a plain and stupid router … let the firewall track connections, we don’t care. This takes much work from the router if you’ve many many connections over it. Sure it makes the firewall settings on the router harder but as said, let the router focus on its single task – route traffic as much and as fast as possible. I sometimes see BGP routers overloaded with other tasks and than people complain that they have problems with high loads. If your network/uplinks is so small, that it does not matter, sticking with connection tracking is also ok – you’ll just can change the firewall rules to use connection awareness.

And now we configure our peers. For the 2 BGP routers which are reachable only via an other router we need to set multihop to yes. We need also to make a link between our 2 routers if one sees a peer the other does not but he still is the the VRRP master.

That was not that hard, but what are all this filter names? As I told you in the beginning we’re paranoid so we don’t trust anyone so we’re filtering all routes going in and out. So lets start with the out filters as they are much easier. They just let us announce our own networks, so we won’t account networks of the one provider to the other and therefore make a link for them over us.

The in filters are at little bit more complicated, but not that hard. We make sure that every AS path we get from the provider starts with his AS. It had happened that some provider are a little bit messy there.

After this is clear, I only need to explain the reason for the filterIpv4Nomartians and filterIpv6Nomartians filters. Its quite easy, these lists contain IP subnets that we should not get via BGP, because they are not used on the Internet (at least not by good people) so we’ll filter them.

Now we’re done with the BGP setup, only some OSFP stuff is left open. Why OSFP? We want to reach our loopback interfaces via the other router, as only one can be the VRRP master. BGP will only redistribute our complete network and the networks from the provides between our 2 routers, but not some parts of our networks – for this we need OSFP.

If you wonder why we use an IPv4 address for the OSFPv3, its because even if its an IPv6 protocol no IPv6 address can be used there … its more like an ID field. Now we only need to set our interfaces and network (only for IPv4 needed):

And at last we send traffic samples to our SFlow server …. I would recommend you to have also a good SFlow server for your BGP routers.

/ip traffic-flow target add address=10.x.x.x:9996 version=9

Now you could test your routers, but one last thing I recommend you to install on your router is following script written by MarkB. With one command you get something that looks like show ip bgp summary on Cisco or Vayatta and that makes looking at the BGP stuff much easier on a Mikrotik. Get the script from here.

I assume you use x86 machines for this setup. But let’s say if MT CCRs are used. Wouldn’t it be wise to drop all firewall rules and let it go fastpath? I mean, would it pose any security threats then? You can disable unnecessary services and those you do need, you can limit to only your allowed subnets..

The problem is not only the firewall. You can also not use the netflow stuff, sniffer or any QoS. Sure you can set the services to only accept traffic from specific subnets, but if you use a management network it is possible for an attacker to get over the BGP router into the management network.

The other question is, do you’ve a 10Gbit internet uplink? As 2x1Gbit Uplink is possible without fastpath. And I can’t recommend more than 2-3 full feed IPv4 tables on a CCR, as the BGP calculating stuff is only done in one core.

Well, as you’ve said “plain stupid router” for BGP and leave all other stuff to other machines that go further down the network?

As for my planned setup, I’d like to use a couple RB1100AHx2’s for the task, have a single 1Gbit ISP uplink and now wonder if go fastpath or configure the firewall. We do not run full table. There are ~1k local routes announced by our ISP and a default route for the rest of the internet. Looking at the RB performance test table seems like I’d be ok with 1100AHx2 for a while if using fastpath. Without, I’m not so sure..

[…] while avoiding route flap? I was a bit stumped about this, but I found a more complex article that describes a multi-homed BGP setup. A key part of that setup was a little trick to avoid this problem. Nameley, set up a static, black […]

thanks for the excellent article!
Regarding the rules to discard martians, I believe you should add the appropriate prefix-lengths to the filters. For example:
add action=discard chain=filterIpv4Nomartians prefix=10.0.0.0/8 prefix-length=8-32

otherwise the rule will only discard the exact prefix 10.0.0.0/8 but will accept 10.1.0.0/16, which is also a martian.

I think there are two typos in IPv4 martians:
– IP range 192.168.0.0/15 does no should appear (192.168.0.0/16 is already included and 192.169.0.0 is global routable)
– 168.254.0.0/16 should be 169.254.0.0/16.