As present I don't have any PTP failover links ! So not sure if should still use BFD!
Unfortunately MikroTik just isn't as stable as Cisco/Juniper etc. In an ideal world BFD would just work flawlessly all the time and then its an an easy answer of enable it everywhere in the network
Sometimes its not the MikroTik routers that are at fault, some radio's don't play well with BFD either
You just need to look at your network and determine the best course of action. Another big reason for us moving off PPPoE inside our backhaul is to massively reduce the downtime that can happen when a link is interrupted. PPPoE tunnels seem ok with a short interruption but say 5+ seconds nope I find they'll drop rather than resume. MikroTik routers are quick to re-establish, adding around 2-5 seconds but other vendors can be up to 2 minutes. This totally kills productivity, everyones sessions die, PBX/VoIP systems have to time out and re-register etc. Removing PPPoE means the tunnel doesn't need to come down and re-establish itself so the time to restore customer traffic is the same as the OSPF reconvergence time. Plus if the core devices fail and flip over to backup there's no need to re-establish connectivity unlike with PPPoE since it can't transfer the session from 1 device to another, but IP can just reroute (or have VRRP in place)
- At the moment we generally don't run BFD where there's a single link and use OSPF timers of 2/1/1/4 by default
- Wherever there's a backup link in place I enable BFD on the primary and leave the secondary without and default 5/1/10/40 (since the failover to the much slower backup can over saturate the link until TCP sessions slow down, 2/1/1/4 may result in missed OSPF packets and an adjacency drop)
- If there's no direct backup link but there is an alternate path through the network around to the core, i'll make a decision if fast failover or highest reliability is more appropriate and go from there
If you can't make up your mind, leave BFD on and if you havn't had an adjacency drop in 30 days you're probably fine to leave it in place. We've had some drop every few days hence we don't run it wherever its not needed
Most of my routers have 1598 or 1600 L2MTU
I don't just mean the routers, also check your radio links and switches between the routers
You can test L2MTU by making a new VLAN on the interface (i.e.ether2.50) and set L3MTU to the size you want to test -4bytes (to account for the extra VLAN header), then do a ping between them with the same packet size and tick don't fragment
I.e. we test 1538 so i'll make VLAN50 with L3MTU of 1534 and run a 1534 byte ping from BOTH sides (you may have different MTU in 1 direction). If it succeeds this means the link can carry a full 1556 L2 packet (including ethernet and FCS). Different vendors have different classification for MTU. MikroTik for instance does not include the the ethernet header (+14 bytes) or FCS trailer (+4 bytes). So a 1542 byte L2MTU in MikroTik actually means 1560 = big enough
Netonix does, so 1542 byte L2MTU means exactly 1542 = not big enough
This is why you need to test (but there is no harm in setting L2MTU as high as possible)
We have less than routers on the network and 800 routes !
Probably still fine. What's your congervence time when you stop OSPF and start the instance again? If the time is low enough, don't worry about it. HEX has more than enough grunt
or PTP to PTP (OSPF point-to-point BFD /30)
( PTP to HEXPOE port1 (OSPF broadcast /30)
(on HEXPOE port 2 AP1( OSPF area=area1111 /30 )
(on HEXPOE port 3 AP2( OSPF area=area1111 /30 )
(on HEXPOE port 4 AP2( OSPF area=area1111 /30 )
not sure what the correct OSPF Instance setting on HEXPOE should be?
'Instance' is a copy of the OSPF software running. When you make another instance they are totally separate from each other. 99% of the time you never need to make another instance, you can run as many area's as you want in the same instance thats fine. Reason you may want to run a different instance is when you have separate networks with overlapping area numbers i.e. 2 separate Area0 networks. You can run a separate instance for each, then redistribute some routes between them rather than joining them together. Or if you have a customer/company with doing OSPF routing with you, you can specify a different routing table (CustomerA) so their routes don't end up in your main routing table, and you aren't leaking your routes to them