Hi Abhinav, thank you for presenting an interesting scenario for a discussion. I have several questions to better understand it:
- How the network failure that triggers the recovery process is detected? - If the failure detection mechanism is not multi-hop BFD, what is the relationship between the detection intervals of heat mechanism and the multi-hop BFD session? Regards, Greg On Wed, Mar 22, 2023 at 4:36 PM Abhinav Srivastava <[email protected]> wrote: > Hi all, > > > > I needed clarification around whether source port can be changed for a BFD > session in case of multi hop BFD. The ability to change BFD source port > when BFD session goes down helps BFD session to recover if its stuck on a > network path where there is some intermittent but significant packet loss. > > > > In such cases, normally without BFD, end to end application traffic would > eventually settle down on a good path as applications typically change > source port after experiencing disconnection or failures. But if BFD is > being used to monitor some part of a path which is experiencing significant > but not 100% packet loss, it will start causing next hop list of associated > static route or the associated BGP sessions to start flapping forever, as > BFD packets would be stuck to that partial lossy path forever (until BFD > session is deleted and recreated by admin action). This may also hinder > the typical application recovery strategy of changing source port on > failure. > > > > Ability to dynamically change BFD source port can help BFD recover in such > cases. Is this something that is allowed as per RFC? The RFC5881, section > 4 (for single hop) case states that – > > *“The source port MUST be in the range 49152 through 65535. The same UDP > source port number MUST be used for all BFD Control packets associated with > a particular session”* > > > > Thanks > > Abhinav >
