As Juniper side we can set no-nexthop-change and BGP always send nexthop which same routing table. But when I set-up BGP with Mikrotik, it always send local IP address to neighbor for next hop
How do I set-up BGP to send route table same as routing table?
For a BGP peer configuration, there is an option “nexthop choice” with the default is “default” and alternate choices of “force self” and “propogate” (haha - spelling error)
This should probably have the effect that you want.
Nope, I tested with all but it always send self.
admin@MikroTik] /ip route> print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 X S 0.0.0.0/0 10.4.4.237 1
1 ADC 10.0.0.0/24 10.0.0.1 ether2 0
2 ADC 10.4.4.0/24 10.4.4.9 ether1 0
3 A S 192.168.1.4/32 10.0.0.2 1
/routing bgp peer> print
Flags: X - disabled, E - established
# INSTANCE REMOTE-ADDRESS REMOTE-AS
0 default 10.4.4.57 100
admin@MikroTik] /routing bgp advertisements> print
PEER PREFIX NEXTHOP AS-PATH ORIGIN LOCAL-PREF
peer1 192.168.1.4/32 10.4.4.9 incomplete 100
origin incomplete is suspicious. Are you using redistribute to get routes into BGP?
(this is usually bad practice)
I assumed this was for iBGP which leaves the next hop alone by default… Are both routers in the same AS?
I’m going to play around with a couple of things to see what I can find.
2 sides are same, AS100
[admin@MikroTik] /routing bgp aggregate> /routing bgp network print
Flags: X - disabled
# NETWORK SYNCHRONIZE
0 192.168.1.4/32 no
When I inserted IP to aggregate, origin has been turned to igp. But next hop is still same.
[admin@MikroTik] /routing bgp aggregate> /routing bgp advertisements print
PEER PREFIX NEXTHOP AS-PATH ORIGIN LOCAL-PREF
peer1 192.168.1.4/32 10.4.4.9 igp 100
After messing around a bit, here are some things I found:
Using iBGP, even with nexthop choice=propogate, I see the same behavior as you regardless whether it is redistributed or originated from igp.
I compared the behavior to Cisco:
When it is iBGP, the next hop address is propagated as you’re expecting
e.g.:
R1:
ip route 190.0.2.0 255.255.255.0 1.1.0.190
router bgp 100
redistribute static !! or network 190.0.2.0 mask 255.255.255.0
Either origination method, I see 192.168.1.190 as the next hop in R2 when using iBGP
-however-
EBGP is interesting.
If I do standard ebgp, next-hop-self is the only thing it allows, and acts as you’d expect.
(so next hop is always the other end of the /30 between the two EBGP peers)
When I configured it for ebgp multihop, In R1 I could set neighbor 2.2.2.2 next-hop-unchanged.
Even when I did this, though, the next hop was the peer address (as in next hop self)!
On R1: (originating router - 1.1.1.1)
Network Next Hop Metric LocPrf Weight Path
*> 1.1.0.0/24 0.0.0.0 0 32768 i
*> 190.0.2.0/24 1.1.0.190 0 32768 i
On R2: (ebgp multihop neighbor - 2.2.2.2)
Network Next Hop Metric LocPrf Weight Path
*> 1.1.0.0/24 1.1.1.1 0 0 100 i
*> 190.0.2.0/24 1.1.1.1 0 0 100 i
EVEN MORE INTERESTINGLY
keeping the eBGP multihop as shown here, I added a 3rd router to the mix, an iBGP peer with R1. It originated 4.4.0.0/24 in the same manner as R1 originated 190.0.2.0/24 (via a static route to 3.3.0.4)
In iBGP for ASN100, Both R1 and R3 show Next Hop = 3.3.0.4
But R2 (the ebgp neighbor) shows next hop of 3.3.0.4 - unchanged! while 190.0.2.0 still shows next hop 1.1.1.1
So R1 changed the next hop to self, even when told not to on the route that it originated, but left alone the prefix it learned from iBGP.
When I changed R1 to use next-hop-self, on the ebgp session to R2, both prefixes changed to next hop 1.1.1.1 as expected.
Sumary:
Mikrotik iBGP sets next hop self, but should be unaltered by default for iBGP. Ignores directive to leave unaltered.
(I need to try the 3rd router option as I did with Cisco)
Cisco does as you expected by default with iBGP
Cisco does as you expected for a next-hop-unaltered ebgp multihop neighbor IF the route was learned from ibgp.
Cisco alters the next hop even for a next-hop-unaltered ebgp multiop neighbor IF the route was originated locally.
My conclusion:
I think Mikrotik’s behavior for iBGP is incorrect, but Cisco’s was interesting too, so maybe this is one of those “your mileage may vary based on implementation” things… I need to test with a 3rd Mikrotik now.
In any case, I bet Mikrotik support doesn’t see this as a bug.