iBGP Won't Establish

RouterOS Forwarding Protocols
1

I cannot get iBGP to establish between two devices on Client’s Network. When I copy the configurations into our lab devices, iBGP establishes immediately. There are no firewall rules in place. Routers are communicating over ether6 successfully.

Router A:
/ip address
add address=10.1.0.1 comment=“iBGP Router ID” interface=Lo1 network=10.1.0.1
add address=10.2.0.5/29 comment=“iBGP Connection to RTR B” interface=ether6 network=10.2.0.0
/routing bgp instance
add as=65531 name=“iBGP RTR B” router-id=10.1.0.1
/routing bgp peer
add instance=“iBGP RTR B” name=“iBGP Peer” remote-address=10.2.0.6 remote-as=65531

Router B:
/ip address
add address=10.1.0.2 comment=“iBGP Router ID” interface=Lo1 network=10.1.0.2
add address=10.2.0.6/29 comment=“iBGP Connection to RTR A” interface=ether6 network=10.2.0.0
/routing bgp instance
add as=65531 name=“iBGP RTR A” router-id=10.1.0.2
/routing bgp peer
add instance=“iBGP RTR A” name=“iBGP Peer” remote-address=10.2.0.5 remote-as=65531

2

Does /tool sniff have anything to say in terms of confirming that the routers are trying to establish a TCP socket? If the connection establishes but something else goes wrong, it might be captured in the BGP logs. You can up the BGP logging in /system logging. I don’t see anything obviously wrong with the configurations.

3

It should be obvious if you /tool sniffer it, but it’s possible that for some reason they’re both using different source addresses and subsequently are ignoring each others’ connection attempts. If that’s what shows up you could try to set update-source to force it to use the address you want.

I’m guessing you have a good reason to be running iBGP over the internal link addresses rather than between the loopbacks you configured, but in case you don’t, you might as well consider doing that now. It shouldn’t break anything but it’s generally good practice so that the iBGP sessions don’t crumble in response to a specific link failing.

4

Any logs showing up? That will give us hint on what could be wrong. Also, is there a reachability between loopbacks of both routers?

5

What software load are you running? With 7.x you need to define local address.

Gilbert

6

The OS Version is v.6.48.1 - CCR1009-7G-1C-S+
The Loopbacks cannot reach each other.
I will provide logs soon.

7

This is what the sniffer is showing on ether 6 for both Routers. Output is specifically from router using 10.2.0.5.
Sniffer Screenshot.PNG

8

I’ve set update source to ether6, but the issue remains.

9

This is from the Router using 10.2.0.6 [BGP Logs]
Logging Screenshot.PNG

10

Well seems like reachability is fine since you can see the connection attempts going in both directions. I assume the two sides can ping each other’s BGP addresses and the ARP tables are fine? And /ip route check shows the interface you expect on both sides?

If you forcibly set multihop=yes on both sides do the peers come up? I can’t see why you’d need to set it in this case. There shouldn’t be a TTL decrement, the far side is in an attached network prefix, and you’re doing iBGP so it should be the default. I just can’t think of anything where the reachability is otherwise fine that would prevent getting further in the BGP FSM than “Connect”. Firewall/nat/mangle rules or multihop is the only thing I can fathom.

11

Well it is stuck on connect state so three-way handshake is not successful.

Can you ping to the destination IP specifying the source address?
Can you confirm there’s no firewall rules blocking TCP 179 on both ends? Just to make sure, can you add an “accept” rule for TCP 179 on each router and see if the counters increment.

12

It is, in fact, a firewall rule that is preventing our iBGP peers from establishing. Here’s the rule:

add action=drop chain=input log-prefix=“input drop”

Adding the /29 to an access list and referencing that via a new firewall rule has resolved our issue.

For context, we are running dual-multihomed, hence why I was needing to establish the iBGP connection between our routers.

My question is, why does this block the iBGP connection between our internal peers, and not the eBGP connection from our routers to our eBGP Peer? The /29 our eBGP connection is using is not referenced in any access list or firewall rule to my knowledge.

13

Phew, that is a lot easier to explain than what else I could imagine. Glad you found it.


I suspect that’s because the outbound eBGP TCP session from your router gets in the conntrack table via the output chain not the input chain. I imagine if the remote eBGP peer initiates the connection first it would fail, but fortunately both sides will try if they’re configured. That doesn’t happen in the iBGP instance because presumably both of your routers have that on their input chains, so neither direction works.