Hi Guys

Ive searched the forum a bit and have been unable to come up with an reasonable answer.

I am looking for the optimal BGP Hold timer over a wireless network, our network is starting to "mesh like" with a lot of p2p Links that some devices have up to 7 links with up to 4 Mikrotik devices (ibgp) and then we run EBGP to the next "site" so each physical location has its own ASN and each device has its own Lo0 the majority of sites that participate in bgp has 2~3. we mostly use RB433's AH U and standard also some 435's a few powerpc's and a few x86 devices

I was wondering if there is an optimal BGP Hold time to use, all the BB links gets configured with scan lists so reconnects are almost imediate, the only killer is reboots, that on the 433's take up to 10 seconds.

I have recently been experiencing some instances where bgp "falls over" cpu load reaches 100% and under pro-filer 80%+ sits under routing. sine there is no static routing in play (except for clients ranges that is served by that site and advertised by that site). u can still mac telnet into the RB's most of the time and get a reboot, some units refuse to ping from the neighbor, and becomes irresponsible to mac telnet. You are unable to do an /bgp peer pr (it just waits there), the rest of the router seems responsive, i believe this is from BGP flapping, but cant say for sure, I will do an sup out next time this happens for support. until then I'm just hunting after a good :

1) Hold-time To use

The following is some more detail into the problem.

>sys reso pr
uptime: 21h37m44s
version: 5.6
free-memory: 40144KiB
total-memory: 62196KiB
cpu: MIPS 24Kc V7.4
cpu-count: 1
cpu-frequency: 300MHz
cpu-load: 100%
free-hdd-space: 30948KiB
total-hdd-space: 61440KiB
write-sect-since-reboot: 46224
write-sect-total: 2878652
bad-blocks: 0%
architecture-name: mipsbe
board-name: RB433
platform: MikroTik

>tool profile
NAME USAGE
wireless 1%
snmp 0.5%
ethernet 0.5%
console 0.5%
management 3.5%
profiling 0%
queuing 0.5%
routing 93.5%
unclassified 0%

mailed a supout to support as well

It is possible that there are too many recursive routes for the hardware in question.
Try using filters to set inbound/outgoing next hop addresses that resolves to interface addresses and see if the load is reduced.
Recursive routes are a bit hard to explain but it is essentially routes that is found behind a gateway which is in a subnet that needs to be resolved before the router knows which gateway to really send it to.