Hi!
Could you please consider to implement possibility for Soft Reset in BGP (as per RFC2918).
This would allow to not reset BGP sessions completely on configuration change.
Thanks!
Artem
Hi!
Could you please consider to implement possibility for Soft Reset in BGP (as per RFC2918).
This would allow to not reset BGP sessions completely on configuration change.
Thanks!
Artem
I presume it will all be there in the mythical version 7!
RFC you mentioned is ‘Route Refresh Capability for BGP-4’
Route refresh capability is already supported for very long time.
If you change critical peer parameters, for example, keepalive timers, connection must be reset.
So what exactly you want us to implement?
I was changing Out Filter for one of peers which lead to BGP session reset, so I ended up with assumption that Soft Reset (Route Refresh) is not supported and created this thread.
Sorry for confusing you.
As I understood now - session in being reset on configuration change. This is not really good approach.
Would it be possible change behaviour to do soft reset instead of full session reset?
Thanks!
Artem
Changes in routing filter configuration does not reset BGP peer. If it did then probably there was some kind of routing crash., if you can repeat this problem contact support with attached supout file and description how you repeat the problem.
If you modify a peer by changing which out-filter chain is used, this causes ROS to reset the peering session.
I just replicated this using CHR v6.36rc13
I agree with artemk that this should not reset the entire session but do the same action that modifying the existing filter chain does.
In fact, it appears that making any change to the peer causes it to be reset - while it’s a guaranteed way to make sure that the live BGP state matches the configured state, it sure is disruptive to production networks. If you simply change the max prefix limit (for instance) then the session’s going to get bounced. It’s like how Windows 95 used to make you reboot just to change the IP address…
BGP session resets even if you change comment assigned to that peer. (and this has nothing to do with session other than pure information for the user) (tested on CCR v6.35)
But it has nothing to do with RFC stated in previous post.
I agree that comment or other non critical parameter should not reset connection, but most likely such behaviour will stay in ROS v6.
mrz, I agree regarding the topic. Current behaviour (session reset on any BGP peer config change) looks like a serious defect.
Should I create separate topic on forum for this? Or what would be the best way for this defect to be fixed?
Thanks!
Artem
Wait for ROSv7
So the question is, when?
I read this talk “wait for ROSv7” since 2014, now is 2016 and …
We have been limping along with bugs that are fixed in “new routing” or “v7” for the last 4 years now.
It always seems like v7 is just around the corner, there would be rumors that it was close but it has never been seen ![]()
Yes, as I mentioned before, it is like Windows Longhorn.
Then wait for RouterOS Longhorn ![]()
When will RouterOS Longhorn be released?
2017 it’s almost gone and no ROS v7 yet…
It seems to me that you are bs-ing us.