summaryrefslogtreecommitdiffstats
path: root/ospf6d/ospf6_bfd.h (follow)
Commit message (Collapse)AuthorAgeFilesLines
* ospf6d: rework BFD integrationRafael Zalamena2021-04-221-6/+3
| | | | | | Use the new BFD library to integrate with BFD. Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
* ospf6d: Json support added for command "show ipv6 ospf6 interface [json]"github login name2020-11-171-0/+1
| | | | | | | Modify code to add JSON format output in show command "show ipv6 ospf6 interface" with proper formating Signed-off-by: Yash Ranjan <ranjany@vmware.com>
* ospf6d: Json support added for command "show ipv6 ospf6 neighbor [json]"github login name2020-11-051-3/+3
| | | | | | | Modify code to add JSON format output in show command "show ipv6 ospf6 neighbor" with proper formating Signed-off-by: Yash Ranjan <ranjany@vmware.com>
* *: reindentreindent-master-afterwhitespace / reindent2017-07-171-15/+10
| | | | | | indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* *: make consistent & update GPLv2 file headersDavid Lamparter2017-05-151-4/+3
| | | | | | | | | | | The FSF's address changed, and we had a mixture of comment styles for the GPL file header. (The style with * at the beginning won out with 580 to 141 in existing files.) Note: I've intentionally left intact other "variations" of the copyright header, e.g. whether it says "Zebra", "Quagga", "FRR", or nothing. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* Fix for IPv6 OSPF BFD session staying down when ifdown/ifup on logical ↵radhika2015-10-091-0/+2
| | | | | | | | | | | | | | | | interfaces Ticket: CM-7649 Reviewed By: Donald Testing Done: This is porting of the patch, ospf6d-bfd-fix-dereg-miss.patch from br2.5. Issue: The IPv6 OSPF BFD sessions stay down after ifdown/ifup on logical interfaces. This problem doesn’t exist for BFD sessions created by BGP and IPv4 OSPF. Root cause: When the interface is brought down the IPv6 neighbors discovered on that interface are deleted. This deletion happens without first bringing down the neighbor and the BFD deregistration happens only when the neighbor state changes. This leaves an orphaned BFD session in PTM. Also, the BFD session socket that is bound to the interface that was brought down loses connection. The socket has to be rebound to the interface when it comes up. This problem will not happen if the client deleted the sessions and re-adds it when interface goes down and come up. IPv4 OSPF and BGP work exactly like that. Fix: Added the BFD deregistration code to IPv6 OSPF neighbor delete.
* Support of BFD status in Quaggaradhika2015-08-311-0/+10
| | | | | | | | | | | | | | | | Ticket:CM-6802, CM-6952 Reviewed By: Donald, Kanna Testing Done: Double commit of b76943235e09472ec174edcf7204fc82d27fe966 from br2.5. But, manually resolved all the compilation errors. Also, modified the shows to support the json format which was not supported in br2.5. CM-6802 – Currently, BFD session status can be monitored only through ptmctl. There is no way to check the BFD status of a peer/neighbor through Quagga. Debugging becomes easier if BFD status is shown in Quagga too. BFD status is relevant when it is shown against the BGP peer/OSPF neighbor. For, this following code changes have been done: - Only down messages from PTM were being propagated from Zebra daemon to clients (bgpd, ospfd and ospf6d). Now, both up and down messages are redistributed to the clients from zebra. BFD status field has been added to the messaging. Handling of BFD session up messages has been added to the client code. BGP/OSPF neighbor is brought down only if the old BFD session status is ‘Up’ to handle extra/initial down messages. - BFD status and last update timestamp fields have been added to the common BFD info structure. Also, common show functions for showing BFD information have been added to BFD lib. - Modified the BGP neighbor show functions to call common BFD lib functions. - For ospf and ospf6, BFD information was maintained only at interface level. To show BFD status per neighbor, BFD information has been added at neighbor level too. “show ip ospf interface”, “show ip ospf neighbor detail”, “show ipv6 ospf6 interface” and “show ipv6 ospf6 neighbor detail” output have been modified to show BFD information. CM-6952 - IBGP peers were always assumed to be multi-hop since there was no easy way to determine whether an IBGP peer was single hop or multihop unlike EBGP. But, this is causing problem with IBGP link local peers since BFD doesn't allow multihop BFD session with link local IP addresses. Link local peers were discovered when the interface peering was enabled. Interface peering is always singlehop. So, added checks to treat all interface based peers as single hop irrespective of whether the peer is IBGP or EBGP.
* This patch changes ospfd from only listening mode for BFD status updates to ↵Donald Sharp2015-07-221-0/+36
interactive mode of dynamically registering/deregistering neighbors discovered on BFD enabled interfaces with PTM/BFD through zebra. Neighbor is registered with BFD when 2-way adjacency is established and deregistered when adjacency goes down if the BFD is enabled on the interface through which the neighbor was discovered. OSPF BFD command enhancement to configure BFD parameters (detect multiplier, min rx and min tx). interface <if-name> ip ospf bfd <detect mult> <min rx> <min tx> This patch also adds BFD support for IPv6 OSPF. ospf6d will dynamically register/deregister IPv6 neighbors with BFD for monitoring the connectivity of the neighbor. Neighbor is registered with BFD when 2-way adjacency is established and deregistered when adjacency goes down if the BFD is enabled on the interface through which the neighbor was discovered. OSPF6 BFD command added to configure BFD and parameters (detect multiplier, min rx and min tx). interface <if-name> ipv6 ospf6 bfd <detect mult> <min rx> <min tx> Signed-off-by: Radhika Mahankali <radhika@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Kanna Rajagopal <kanna@cumulusnetworks.com>