Help with BGP - routes missing from route table

Teltonika Networks
1

Hey Guys,
I am running BGP over an IPSEC tunnel (to a different firewall, not a Teltonika).
IPSEC is up, BGP is established and neighbors learning routes form each other however I am unable to route.
When I check the routing table of my TRB500 via SSH I do not see the advertised routes that BGP is showing.
When I check the routes in the firewall on the other end i see the advertised route.
What am i doing wrong?

image
image1061×926 21.8 KB

image
image992×730 18.2 KB

image
image1062×948 26.4 KB

root@TRB500:~# ip route
default dev rmnet_data0 proto static scope link src 192.0.0.2 metric 4261413118
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.4.1
192.0.0.2 dev rmnet_data0 proto static scope link metric 1
192.168.97.0/24 dev br-lan proto kernel scope link src 192.168.97.1
192.168.99.0/24 dev br-lan proto kernel scope link src 192.168.99.1

I’ve done this and changed the metric on my WAN Default route, but regardless of this the route table does not show the routes advertised in BGP:

Any help is greatly appreciated.

2

Hi, it seems that all is well in terms of BGP application receiving routes, but they’re not being installed in routing table likely due to next hop being not directly connected and eBGP (two different AS) being used. I’m not sure if you set any value for “EBGP Multihop” option but it might be wise to try increasing that first (can’t see peer config, but this option should be under your current BGP instance “general”).

If above doesn’t help, try to configure BGP peer group with “Disable connected check” option enabled and see if that makes a difference. Peer group configuration will be needed for that.

3

Hi,
Thanks for the suggestions.
I’ve tried both but no luck unfortunately.

I turned on multihop on the peer, tried a fair few different weights, neighbor stays established:

image
image905×734 25 KB

I created a peer group as well, but didn’t make a difference:

image
image962×639 28.1 KB

No matter what I try, the BGP routes are never published in the route table:
root@TRB500:~# ip route
default dev rmnet_data0 proto static scope link src 192.0.0.2 metric 4261413118
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.4.1
192.0.0.2 dev rmnet_data0 proto static scope link metric 1
192.168.97.0/24 dev br-lan proto kernel scope link src 192.168.97.1
192.168.99.0/24 dev br-lan proto kernel scope link src 192.168.99.1

4

Another reason for BGP not installing routes could be that NEXT_HOP address is unreachable so recursive check fails on Teltonika side - because of that BGP does not even attempt to install any routes advertised by your neighbor. In other words, BGP NEXT_HOP address is not being reached via IPsec tunnel, but via default route.

Could you try adding next hop IP address to IPsec right (remote) side configuration on Teltonika? Also make sure to add it on the left side (for other device with which Teltonika is establishing the tunnel) so that this host is reachable directly via tunnel, without any routing information exchange. In other words - make sure that whichever router is advertised as NEXT_HOP is reachable without BGP process installing any routes.

I hope the description is clear, more or less. It’s a little convoluted, so in case you need extra info for specific configuration, please let me know.

In case that doesn’t help, could you please show output of the following commands from CLI:

ip route show table 220
vtysh -c 'show ip bgp'
vtysh -c 'show bgp all'
5

Hi,
Thanks very much for helping with this.
Yes, I had already published the subnets on both sides and the devices could communicate with each other (next hop) before establishing BGP.

image

root@TRB500:~# ip route show table 220
192.168.98.0/24 via xxx.xxx.xxx.xxx dev rmnet_data0 proto static src 192.168.99.1
Note: xxx.xxx.xxx.xxx is the other end IPSEC peer’s WAN IP

root@TRB500:~# vtysh -c ‘show ip bgp’
BGP table version is 3, local router ID is 192.168.99.1, vrf id 0
Default local pref 100, local AS 65005
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop’s vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
0.0.0.0/0 192.168.98.1 0 0 65003 i
10.0.0.0/24 192.168.98.1 0 65003 65000 65002 ?
10.0.0.0/25 192.168.98.1 0 65003 65000 ?
10.0.0.128/25 192.168.98.1 0 65003 65000 ?
10.20.30.0/24 192.168.98.1 0 65003 65000 65002 ?
10.81.234.0/24 192.168.98.1 0 65003 65000 65001 i
10.100.0.0/24 192.168.98.1 0 65003 65000 65002 ?
10.101.0.0/24 192.168.98.1 0 65003 65000 65002 ?
10.200.0.0/16 192.168.98.1 0 65003 65000 65001 i
10.201.2.0/24 192.168.98.1 0 65003 65000 65001 i
10.202.1.0/24 192.168.98.1 0 0 65003 i
172.16.1.0/24 192.168.98.1 0 65003 65000 65002 ?
172.16.254.252/30
192.168.98.1 0 65003 65000 65002 ?
192.168.0.0/24 192.168.98.1 0 65003 65000 65002 ?
192.168.1.0/24 192.168.98.1 0 65003 65000 65002 ?
192.168.2.0/24 192.168.98.1 0 65003 65000 65002 ?
192.168.3.0/24 192.168.98.1 0 65003 65000 65002 ?
192.168.5.0/24 192.168.98.1 0 65003 65000 65002 ?
192.168.6.0/24 192.168.98.1 0 65003 65000 65002 ?
192.168.7.0/24 192.168.98.1 0 65003 65000 65002 ?
192.168.8.0/24 192.168.98.1 0 65003 65000 65002 ?
192.168.9.0/24 192.168.98.1 0 65003 65000 65002 ?
192.168.16.0/24 192.168.98.1 0 65003 65000 65002 ?
192.168.17.0/24 192.168.98.1 0 65003 65000 65002 ?
192.168.51.0/24 192.168.98.1 0 65003 65004 i
*> 192.168.97.0/24 0.0.0.0 0 32768 i

Displayed 26 routes and 26 total paths
root@TRB500:~# vtysh -c ‘show bgp all’

For address family: IPv4 Unicast
BGP table version is 3, local router ID is 192.168.99.1, vrf id 0
Default local pref 100, local AS 65005
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop’s vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path
0.0.0.0/0 192.168.98.1 0 0 65003 i
10.0.0.0/24 192.168.98.1 0 65003 65000 65002 ?
10.0.0.0/25 192.168.98.1 0 65003 65000 ?
10.0.0.128/25 192.168.98.1 0 65003 65000 ?
10.20.30.0/24 192.168.98.1 0 65003 65000 65002 ?
10.81.234.0/24 192.168.98.1 0 65003 65000 65001 i
10.100.0.0/24 192.168.98.1 0 65003 65000 65002 ?
10.101.0.0/24 192.168.98.1 0 65003 65000 65002 ?
10.200.0.0/16 192.168.98.1 0 65003 65000 65001 i
10.201.2.0/24 192.168.98.1 0 65003 65000 65001 i
10.202.1.0/24 192.168.98.1 0 0 65003 i
172.16.1.0/24 192.168.98.1 0 65003 65000 65002 ?
172.16.254.252/30
192.168.98.1 0 65003 65000 65002 ?
192.168.0.0/24 192.168.98.1 0 65003 65000 65002 ?
192.168.1.0/24 192.168.98.1 0 65003 65000 65002 ?
192.168.2.0/24 192.168.98.1 0 65003 65000 65002 ?
192.168.3.0/24 192.168.98.1 0 65003 65000 65002 ?
192.168.5.0/24 192.168.98.1 0 65003 65000 65002 ?
192.168.6.0/24 192.168.98.1 0 65003 65000 65002 ?
192.168.7.0/24 192.168.98.1 0 65003 65000 65002 ?
192.168.8.0/24 192.168.98.1 0 65003 65000 65002 ?
192.168.9.0/24 192.168.98.1 0 65003 65000 65002 ?
192.168.16.0/24 192.168.98.1 0 65003 65000 65002 ?
192.168.17.0/24 192.168.98.1 0 65003 65000 65002 ?
192.168.51.0/24 192.168.98.1 0 65003 65004 i
*> 192.168.97.0/24 0.0.0.0 0 32768 i

Displayed 26 routes and 26 total paths

Happy to organise a separate DM if you prefer, let me know how to reach you.

6

Hm, this is pretty strange. Next hop should be reachable for sure from regular Linux, but maybe FRR is having some problems with reaching it and that’s why BGP routes are not being installed.

Could you try to login to FRR management shell via CLI by entering the following command:
vtysh
That should put you in a Cisco-like CLI. From there, could you try to ping next hop:
ping 192.168.98.1

Since it doesn’t seem like you’re using VRFs, the ping should work. If you can ping this host from regular CLI, but not from vtysh CLI then we might be able to narrow this issue down. Also, could you show what routes FRR is seeing from its perspective? While in vtysh CLI, try to run this command:
show ip route

Also, have you tried disabling the eBGP Requires Policy option? Maybe this feature is somehow not functioning correctly or I’m misinterpreting its functionality.

Regarding communication - it’s all good to keep posting information here if that’s ok with you. Someone else might be able to jump into this topic and point out the issue, because maybe I’m not seeing something. Unfortunately, I cannot try to replicate the issue since I don’t have router to test with.