BGP routing issue

RouterOS Forwarding Protocols
1

I am trying to create, in my home lab, a small scale version of an ISP. Specifically, I’m trying to create a BGP link between the “provider” router and “internal isp” that will allow me to pass traffic from inside the “internal isp” to the internet, so it will simulate a full ISP.

I have two hEX lites running the BGP link - both running ROS 6.49.18, the configurations are:

RB750 - “provider” router:

/interface ethernet
set [ find default-name=ether1 ] comment=internet
set [ find default-name=ether2 ] comment="link to ISP BGP router"
set [ find default-name=ether3 ] comment=local
set [ find default-name=ether4 ] comment=local
set [ find default-name=ether5 ] comment=mgmt
/routing bgp instance
set default disabled=yes
add as=65000 client-to-client-reflection=no name=to-ISP \
    redistribute-connected=yes redistribute-static=yes router-id=172.30.0.1
/ip neighbor discovery-settings
set discover-interface-list=!dynamic
/ip address
add address=172.31.0.1/24 comment=Management interface=ether5 network=\
    172.31.0.0
add address=192.168.5.254/24 comment="Home Network" interface=ether1 network=\
    192.168.5.0
add address=172.30.0.1/30 comment="Link to ISP Gateway" interface=ether2 \
    network=172.30.0.0
/ip dns
set servers=192.168.5.1
/ip route
add distance=1 gateway=192.168.5.1
add distance=1 dst-address=192.168.5.0/24 gateway=192.168.5.1
/routing bgp peer
add instance=to-ISP name=peer-to-isp remote-address=172.30.0.2 remote-as=\
    65010

And the RB750 “ISP gateway” router:

/interface bridge
add name=bridge-isp
/interface ethernet
set [ find default-name=ether1 ] comment="internet from Provider"
set [ find default-name=ether2 ] comment=local
set [ find default-name=ether3 ] comment=local
set [ find default-name=ether4 ] comment=local
set [ find default-name=ether5 ] comment=mgmt
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip hotspot profile
set [ find default=yes ] html-directory=hotspot
/routing bgp instance
set default disabled=yes
add as=65010 client-to-client-reflection=no name=to-provider \
    redistribute-static=yes router-id=172.30.0.2
/ip neighbor discovery-settings
set discover-interface-list=!dynamic
/ip address
add address=172.31.0.2/24 comment=Management interface=ether5 network=\
    172.31.0.0
add address=172.30.0.2/30 comment="Link to Provider" interface=ether1 \
    network=172.30.0.0
add address=172.16.255.1/24 comment="Internal ISP Network" interface=\
    bridge-isp network=172.16.255.0
/ip route
add distance=1 gateway=172.30.0.1
/routing bgp network
add network=172.16.255.0/24 synchronize=no
/routing bgp peer
add instance=to-provider name=peer-to-provider remote-address=172.30.0.1 \
    remote-as=65000

In my home router, an RB5009, I have a static route from it to 172.16.255.0/24 - gw: 192.168.5.254, and I’m able to ping 172.16.255.1 (the “internal isp” router network) with no problems.
From the “provider” router, I can ping 8.8.8.8, and do DNS lookups with no issues - everything appears to work fine.
From the “internal isp” router, when I attempt to ping either my home router, 192.168.5.1, or 8.8.8.8 (or anything past 172.30.0.1), I get timeouts - note: I can ping 172.30.0.1 AND 192.168.5.254 as these are both the same “provider” router.
When I run a traceroute from the “internal isp” router, I see it hitting the 172.30.0.1 (the “provider” router), but then nothing past that.

I believe I have a route (or more) missing from that “provider” router to my main router, but I’m missing what I need to do to get this running.

My network diagram:
Screenshot from 2025-05-02 10-06-35.png
Any pointers as to how I can resolve this?

2

The issue you are facing has nothing to do with BGP per se.

Your gateway to the internet is doing network address translation (NAT) to map local addresses to a public IP address provided from your upstream.
This NAT rule in that router does translate a certain range (usually 192.168.88.0/24 or 192.168.1.0/24) to the public IP assigned on the upstream.
Your internal routing (BGP or not) now maps additional internal ip ranges 172.16.x.x into your home zone but they might not be translated by your NAT rule. Hence your private IP addresses are not reachable from the outside because NAT doesnt consider them and the next hop will drop your packets (or the destination can at least not reply).

Furthermore you are running a old RouterOS. I strongly recommend to upgrade to RouterOS 7. Lots of quirks in RouterOS 6 when it comes to routing which are much more elegant in RouterOS 7.

3

I would not recommend updating a hEX lite to RouterOS v7.
Likely he now only uses those to play a little. Once the project gets a go-ahead, he needs to get more RB5009 or similar routers.

4

I don’t think hex lite has any issue with routeros 7. Büut it has with big routing tables . Full bgp would kill it in a few seconds.

The issue is a lot of stuff in bgp filtering has changed drastically between router os 6 and 7 so learning old ways of doing stuff which then is not applicable anymore in the newer boxes is kind of a waste of time. Never the less you can run BGP on router OS 6 of course, including all the edge cases where it failed. We had huge ipv6 issues in RouterOS6 (vlans+ospf) which made never want to go back to 6 ever again. All our routers are on 7, even the smallest ones (hap ac lite)

5

Well, I have huge BGP issues in RouterOS v7.16 and later and I would LOVE to be able to go back to v6.49 when it was possible on my hardware!

6

maybe I can help with your 7.x bgp issues.
Besides bug in BGP routing lockup (also happened in 6), it’s often just a question of getting the new way of doing things right. Was not easy to migrate for us but now everything works fine. The stability is more of a generic issue, independent of the version.

7

BGP before v7 and in versions 7.10-7.15.3 was absolutely stable for us.
We do not use it for internet tables but to route our own RFC1918 addresses over a mesh of tunnels.
See the recent release topics for my problems. It simply does not reliable store fallback routes anymore.

8

I have been using BGP on v6 for years, with no issues with IPv4 or IPv6.

After some forced use of v7 on CCR2004,
I removed that router because it works better with CCR1036 on v6.
I can’t wait for them to fix all the issues on v7.
Listing here is pointless, the forum is full of complaints that have remained in vain for years.

As for simulations, unless you have more than one provider or want to “play” with BGP, the full routing table is completely useless, the default route is enough.

9

if you only have a single upstream, then BGP is completely useless anyway. In fact you can only get an AS number if you are multihomed. And the number one reason to become multihomed is because you have multiple upstreams or at least some peerings. So a large routing table makes sense (but doesnt have to be full but something like all regional AS numbers).

10

If I remember correctly, or if it hasn’t changed over time, it’s not enough to be multihomed with two links to the same AS, but you need at least two different AS…

Unless you need to assign different ways to reach different remote IPs,
even if you have two or more providers, the default route will still suffice, and you still use BGP to publish the IPs you want to be reachable.


Whatever happens, it’s best to practice BGP with v7.16.2, v6 is pretty much abandoned.

11

We do not use it for internet tables but to route our own RFC1918 addresses over a mesh of tunnels.

12

Have You run a torch on this address? This way we can see what’s getting there - if it’s getting there at all.
It looks like routing, NAT or firewall.

Wait
Are You using Mikrotik’s default firewall? The last input rule is

/ip/firewall/filter/add action=drop chain=input comment=“defconf: drop all not coming from LAN” in-interface-list=!LAN log=yes

Did You put your 172.30.0.0/24 range on the LAN adress list?

13

there is only an INTERFACE LIST called “LAN” in defconf
no address-list is present in defconf

the interface which got assigned that 172.30.0.0/24 subnet added to interface-list “LAN” MIGHT help. but not sure if this is the fully right/elegant solution to this when this lab setup reaches real-world

14

You have to open the firewall in order to receive packets. If I'm right, it is dropping everything coming from this range and destined to the router. Test it, and we know. At the very least we will know that isn't it.

Or we will find out the problem.

15

You are all continuing to write in a circle, but no one has a response from the OP who wanted a solution IMMEDIATELY,
instead he was written to 12 days later and the user has already disappeared.

You are making empty conjectures, because:

  1. You have no responses or confirmations;
  2. In the “assumed” export there are no firewall rules.

Clue that these are exports of a machine with empty configuration:

/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik

And this clue:

/ip neighbor discovery-settings
set discover-interface-list=!dynamic

means that the device has been updated, instead of using netinstall to install the latest v6.

16

good to have you here then, to clear everything up

17

Thanks for replying to this thread. Appreciate it.

The end goal is to lab a v6 BGP/OSPF setup, and then take steps to upgrade to v7.
I recently was put in charge of an ISP that has ~50 CCR’s (a mix of 1016 (OSPF), 1036 (OSPF) and a few 1072’s (OSPF/BGP) )
As these devices are no longer found, and as the equipment ages, we need a route to upgrade to CCR2004/2116/2216 which only support v7.
(I’ve picked up 6 of these hEXlite’s for my lab, and I’ve upgraded/downgraded a few between 6.49.18 and 7.18.2)

I’m trying to get a feel for the configuration process - before we have an emergency and trying to setup/configure a device live.

The part that is/was confusing me, is that the “provider” router has full internet access - but that is because it’s on the 192.168.5.0/24 network, from the “provider” router, it has access to the Internet.

From what I’m reading, I need to create a NAT/Filter to route from 172.30.0.0/24 to the 192.168.5.0/24 - and this will need to be done on the “provider” router.

As @rextended mentioned:

  1. In the “assumed” export there are no firewall rules.

This is correct, both of these two lab routers do NOT have any firewall rules in place. And the two exports posted are the full exports of the two lab routers - the comments with the MAC were removed.

18

@ marty,

From what I’m reading, I need to create a NAT/Filter to route from 172.30.0.0/24 to the 192.168.5.0/24 - and this will need to be done on the “provider” router.

correct. you need srcnat or nat masquerade on providers interface facing the real internet.

even just for lab - there is not much of a difference from that in the real world schema. your providers router is your upstream isp. may it be tier 1 or 2 ‘regional isp’. and your internal isp could be tier 3 leaf isp.

you need to define your tier 3 isp ‘public - internet routable ip’ and your internal isp transport ip.

your tier 3 isp only need bgp default route from your upstream isp bgp peer. the rest is interior routing ospf to interconnect the internal network and to carry your ‘public ip’ for the subscribers. be it static or DHCP or ppp your choice your network design.