OSPFv3-BGP Association
When a new device is deployed on a network or a device is restarted, network traffic may be lost during BGP route convergence because IGP routes converge more quickly than BGP routes. OSPFv3-BGP association can address this problem.
After a device on a BGP network recovers from a fault, BGP convergence is performed again and packet loss may occur during the convergence.
In Figure 1, traffic from DeviceA to DeviceD through DeviceC traverses a BGP network.
If DeviceC fails, traffic is switched to DeviceB after rerouting. Packets are lost when DeviceC recovers.
Because OSPFv3 route convergence is faster than BGP route convergence, OSPFv3 convergence is complete whereas BGP route convergence is still going on when DeviceC recovers. The next hop of the route from DeviceA to DeviceD is DeviceC, which, however, does not know the route to DeviceD since BGP convergence on DeviceC is not complete.
Therefore, DeviceC discards the packets destined for DeviceD after receiving them from DeviceA, as shown in Figure 2.
OSPFv3-BGP Association Process
When a device with OSPFv3-BGP association restarts, the device sets the weight to the largest value (65535) in LSAs, instructing other OSPFv3 routers not to use it as a transit router for data forwarding. BGP routes, however, can still reach the device.
In Figure 1, OSPF-BGP synchronization is enabled on DeviceC. In this situation, before BGP route convergence is complete, DeviceA keeps forwarding data through DeviceB rather than DeviceC until BGP route convergence on DeviceC is complete.