- \n
- Direct BFD sessions between two routers using a LAG port.<\/li>\n\n\n\n
- BFD sessions established between two routers, with an L2 switch between them forming a LAG port.<\/li>\n<\/ul>\n\n\n
![\"\"](\"https:\/\/www.lastopinion.io\/wp-content\/uploads\/2024\/03\/LAG_Routing.png\")
<\/figure>\n<\/p>\n\n\nHow BFD and LAG Works<\/strong> :<\/p>\n\n\n\n
The BFD protocol operates within Layer 4 of the network stack, employing common IP addresses and UDP ports. Therefore, when the router initializes a session, the ‘Load Balancing’ algorithm determines the appropriate link for transmitting this session.<\/p>\n\n\n\n
![\"\"](\"https:\/\/www.lastopinion.io\/wp-content\/uploads\/2024\/03\/LAG_Routing_BFD-1.png\")
<\/figure>\n\n\n\nTo make things more interesting, each router may select a different link for its session (in a “non echo”\/asynchronous mode) :<\/strong><\/p>\n\n\n\n
![\"\"](\"https:\/\/www.lastopinion.io\/wp-content\/uploads\/2024\/03\/LAG_Routing_BFD_BIDI-1.png\")
<\/figure>\n\n\n\nWhat is the issue<\/strong> :<\/p>\n\n\n\n
You probably began to guess where the issue lies here ^^<\/p>\n\n\n\n
The BFD protocol is generaly configured with more aggressive timers compared to LACP, enabling quicker detection of link abnormalities. Thus, if there’s an issue on link “3”, BFD might detect it and initiate a timeout prior to LACP’s detection of the problem. Consequently, the BFD client protocol could report adjacency down.<\/p>\n\n\n\n
Also, deploying a BFD session across the aggregation without internal insight into the member links would render BFD incapable of ensuring detection of physical member link failures especialy if the LACP timer is high (30s for example). The objective is to confirm link continuity for each member link.<\/p>\n\n\n\n
![\"\"](\"https:\/\/www.lastopinion.io\/wp-content\/uploads\/2024\/03\/LAG_Routing_BFD_Incident.png\")
<\/figure>\n\n\n\nThe traditional approach to solving this problem<\/strong> :<\/p>\n\n\n\n
- \n
- Simply accept it as it is; this may not pose a significant issue for you, especially if you have sufficient capacity on the backup link to handle traffic switching<\/li>\n\n\n\n
- Remove the BFD if you don’t need it<\/li>\n\n\n\n
- Increase the single interface capacity if feasible, and remove the LAG bundle<\/li>\n\n\n\n
- Using ECMP involves employing multiple distinct interconnections instead of a single LACP link. However, depending on the scale and requirements of your network, it may be more advantageous to establish LAG bundle instead of relying on ECMP. This approach may helps mitigate platform-specific scaling challenges and prevents unnecessary interference with your IGP<\/li>\n\n\n\n
- Set a more aggressive setting for LACP (.i.e. fast or short LACP), ensuring faster periodic updates, while allowing BFD timers to be slightly longer; however, this is sometimes not available or not tunable enough depending on the router vendor\/OS<\/li>\n<\/ol>\n\n\n\n
RFC 7130 approach to resolve this<\/strong> :<\/p>\n\n\n\n
Micro-BFD<\/strong> : Integrating BFD across all LAG member links which necessitates the BFD code’s understanding of LAG configurations, enabling it to verify connectivity independently across each constituent link. It will depend on vendor, and their OS, if they did develop this functionality Consulting RFC 7130 <\/a>offers additional information.)<\/p>\n\n\n\n
![\"\"](\"https:\/\/www.lastopinion.io\/wp-content\/uploads\/2024\/03\/LAG_Routing_BFD_Micro.png\")
<\/figure>\n\n\n\nShould even a single micro BFD session be Up, the port-channel session will reflect its state as Up.<\/p>\n\n\n\n
Some vendors support the RFC<\/strong> 7130<\/strong> :<\/p>\n\n\n\n
- \n
- Juniper : https:\/\/www.juniper.net\/documentation\/us\/en\/software\/junos\/high-availability\/topics\/task\/bfd-protocol-configuring-micro-bfd-for-lag.html<\/li>\n\n\n\n
- Cisco NX-OS and XE : https:\/\/www.cisco.com\/c\/en\/us\/td\/docs\/routers\/ios\/config\/17-x\/ip-routing\/b-ip-routing\/m-micro-bfd-sessions.html<\/li>\n\n\n\n
- Cisco XR (named BLB & BOB) : https:\/\/www.cisco.com\/c\/en\/us\/td\/docs\/routers\/asr9000\/software\/asr9k-r6-9\/routing\/configuration\/guide\/b-routing-cg-asr9000-69x\/implementing-bfd.html<\/li>\n\n\n\n
- Arista : https:\/\/www.arista.com\/en\/um-eos\/eos-bidirectional-forwarding-detection<\/li>\n<\/ul>\n\n\n\n
Other still not :<\/strong><\/p>\n\n\n\n
- \n
- Palo Alto Firewalls : https:\/\/docs.paloaltonetworks.com\/pan-os\/11-1\/pan-os-networking-admin\/bfd\/bfd-overview\/non-supported-rfc-components-of-bfd<\/li>\n\n\n\n
- Fortinet Firewalls not supported<\/li>\n<\/ul>\n\n\n\n
In conclusion<\/strong><\/p>\n\n\n\n
Configuring BFD is simple, configuring LAG bundle is simple, but configuring both need some intereaction and anticipation, the more protocols you add together in your design, the more complexity and unexpected results you may have.<\/p>\n\n\n\n
So regarding micro-bfd, at the end, depending on your specific requirements, this may not be necessary, and simplicity could be prioritized since enabling micro-BFD may come with certain limitations, which can vary depending on the vendor (make sure to refer to the vendor configuration guide for specific details). Ultimately, as always, you have to consider the required resilience level and adherence to your SLA objectives.<\/p>\n\n\n\n
Are you considering tuning your network or do you have any questions about it? We can assist you. You can reach out to us through the CONTACT-US<\/a> page or by emailing us at contact@lastopinion.io<\/a> for advise assistance.<\/p>\n\n\n\n