MikroTik

hi guys,

help me to solve this :

09:11:49 route,bgp,info Failed to open TCP connection: No route to host
09:11:49 route,bgp,info RemoteAddr= x.x.x.x
09:11:49 route,bgp,info RemotePort=179

i use bgp multihop for this.

Tried a traceroute to the bgp-peer ?

Stefan

i can ping and trace to my ip bgp peer. i ever face this problem was long time ago but i forget,
i remember change the value of scope and target scope... please someone could help me please. this urgent
regards

Do you have a direct route to the peer instead of only the default gateway? I believe you need a route in the route table rather than just using the default gateway.

Here is example
http://wiki.mikrotik.com/wiki/Using_sco ... attributes

hi all,

my bgp multihop still not work. i have add static routing to my bgp peer. this my bgp configuration

name="peer" instance=default remote-address=x.x.x.x
remote-as=xxxxx tcp-md5-key="" nexthop-choice=default multihop=yes
route-reflect=no hold-time=3m ttl=255 in-filter=in-peer
out-filter=out-peer

at log i didn't see anymore error "no router to host" but bgp still not established.

Try adjusting the BGP peer TTL to better reflect the number of hops. MikroTk support suggested this and it worked for us recently.

Best,

Brad

I've seen the same thing on our BGP router before, it cleared it's self up in a few moments after reboot. on the other side of the connection the upstream BGP peer was showing MD5 auth error's on our BGP session while it was happening.

to fix i've done, either wait ~90 seconds for it to clear up automatically, or disable the peer and re-enable, either way it came back online immeaditly.

what version are you using? maybe send support-output to support?

what version are you using? maybe send support-output to support?

2.9.43... it's been working too good to upgrade yet, the issue is way too minor to make a big deal over for now. I'd rather wait a few moments for it to clear up the MD5 problem at boot, and see improvments done on the wireless speed and stability in v3... I'll send supout if it's still doing it when and if there are no other issues that are more important for me to see fixed...

ok, it did it to me again a few minutes ago, so I upgraded to 2.9.46 (don't trust 48 yet for something this critical, I think I found a bug earlier today in the interface graphing)

after the upgrade it still does it. I send into to support along with a supout

error on upstream provider's router error on MikroTik after disableing the peer and re-enableing it a few seconds later, everything came up fine.

Try adjusting the BGP peer TTL to better reflect the number of hops. MikroTk support suggested this and it worked for us recently.

Best,

Brad

I have same problem and I did change TTL, now working Ok.
Thaks!

I'm not using multihop, I'm directly connected to the same subnet as my upstream via fiber...

i have had this happen with a cisco peer as well... i think it has something to do with the remote end still having a session open (ip:port pair) and so it thinks it's part of the same conversation. Leaving the peer disabled more than the hold timer will cure that, but it's a pain. I believe if the remote end (cisco?) doesnt get a RST packet then it's confused. Not quite sure, just my guess.

if I understand what you're meaning correctly, say I reboot my router for reason X, and it boots back up and attempts to reconnect the BGP session to my upstream provider before the hold time my provider has programmed in has been reached, their system will reject the connection because it has not received a rst command?

if that is correct, first off, on shutdown or reboot, RouterOS needs to make sure to send a reset command to all peers.

and second, contacting my upstream provider to shorten the hold time may also take care of the issue in the mean time.

does all that sound correct?

That sounds right. I don't think its a matter of the BGP hold timer, I think its a TCP established session thing... it just happens that if the remote sides hold timer expires then the connection is removed and you can start over. I don't know very much about the MD5 passwords, but possibly for security reasons they are used as part of the tcp establishment as well. This problem doesn't seem to occur when there are no MD5 passwords. In reality you want the hold timer to last a few minutes because you want to be able to reboot without your routes flapping. Just not sure what a good workaround is (other than not using MD5?).

In reality you want the hold timer to last a few minutes because you want to be able to reboot without your routes flapping.

why would you want that? if you are rebooting a router, then the routes should be invalid otherwise anyone trying to route to your network would not be able to, effectivly you would then be down (going under the assumption that you are running BGP because you have more then one provider, and more then one router)

true. in some cases the 30 seconds of a reboot might be better to not flap your routes, in some cases you want them to. anyhow, i think it has to do with mikrotik not closing its bgp peer sessions (and closing tcp session) before it shuts down or something. next time try disabling the peer, then rebooting, and reenabling the peer and see if you have the same problems. it that works then maybe you can script a reboot that includes that - who knows ... : )

here is some info on why I think MD5 works at the TCP level, and therefore probably why the sessions don't close properly:

http://bgphints.ruud.org/articles/bgp-md5.html

http://www.postel.org/pipermail/end2end ... 05078.html

http://www.faqs.org/rfcs/rfc2385.html

It would be interesting to packet sniff one of these MD5 sessions from RouterOS to Cisco IOS ... and see if the TCP RST packet contains the MD5 password in it. Maybe it's closing out improperly and can be fixed by pointing it out to mt staff.

Sam

true. in some cases the 30 seconds of a reboot might be better to not flap your routes, in some cases you want them to. anyhow, i think it has to do with mikrotik not closing its bgp peer sessions (and closing tcp session) before it shuts down or something. next time try disabling the peer, then rebooting, and reenabling the peer and see if you have the same problems. it that works then maybe you can script a reboot that includes that - who knows ... : )

i tried that last night, disable the peer, reboot, enable the peer, it came up immeaditly without any md5 errors...

i dont know what a '/system reboot' performs before it does its thing. If it doesn't cleanly shutdown bgp peers then it will take a few minutes up to a day for it to reestablish. I've seen this many times yet just realizing this is why since you posted. Perhaps you can email support and find if there is a way to shut down bgp peers cleanly during a reboot. It is _only_ in the case of MD5 and BGP.