[BGPCEP-410] When using clustering with replication, linkstate topology of non-leaders is not available via restconf Created: 16/Mar/16 Updated: 03/Mar/19 Resolved: 28/Jul/16 |
|
| Status: | Resolved |
| Project: | bgpcep |
| Component/s: | BGP |
| Affects Version/s: | Bugzilla Migration |
| Fix Version/s: | Bugzilla Migration |
| Type: | Bug | ||
| Reporter: | Ajay L | Assignee: | Ajay L |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| External issue ID: | 5536 |
| Description |
|
Using 3-node cluster, setup using instructions from here https://wiki.opendaylight.org/view/BGP_LS_PCEP:Lithium_User_Guide Each node is BGP peering with a separate Cisco XRv instance. Even though each router is sending linkstate update to node, only the topology for shard leader shows up in http://localhost:8181/restconf/operational/network-topology:network-topology/ output Each node is configured for different rib-id and topology-id as per the instructions. The topology-provider on each node listens on data changes in associated RIB’s sub-tree. Since both config and operational stores are replicated in default config, DataTreeChangeListener is invoked only on the leader node which is not listening on RIB’s used by other 2 nodes and so those changes get lost. If ClusteredDataTreeChangeListener is used instead, it will ensure that changes are seen on all nodes and are acted upon by each node for the RIB it is using If BGP shards are not replicated, this problem may not happen, but since that is not the default config, opening this bug to evaluate using ClusteredDataTreeChangeListener in the code which will work irrespective of whether BGP shards are enabled |
| Comments |
| Comment by Ajay L [ 09/Apr/16 ] |
|
As noted earlier, issue is that in clustered setup, when BGP RIB shard is replicated and each node is configured with different rib-id, DataTreeChangeListener (DTCL) onDataTreeChanged() is received on shard leader only, thus updates for the non-leader node rib-id’s are missed. If ClusteredDataTreeChangeListener is used instead update is received on all nodes and since a node is listening for updates to its rib-id only, all updates are processed without any duplication A single node can have multiple BGP peers and the learnt routes are stored in loc-rib (reference: https://wiki.opendaylight.org/view/BGP_LS_PCEP:Developer_Guide#RIB_handling). As an extension of this (as a distributed router), is possible that some user configures same rib-id on all cluster nodes? i.e. different nodes learn routes from their BGP peers and best routes are stored in same loc-rib sub-tree shared by all nodes. In that scenario, usage of ClusteredDataTreeChangeListener will result in duplicate processing of loc-rib change events. This is bit tricky as it depends on how user configures BGP in cluster i.e. same rib-id or different. Our user-guide on wiki specifies use of different rib-id on each node. Can I assume that rib-ids will be different on each cluster node? (when BGP RIB replication is enabled). When BGP RIB replication is disabled, it does not matter and it works in either case |
| Comment by Ajay L [ 03/Jun/16 ] |
|
Going with the assumption that in cluster scenario, same rib-id will not be configured on multiple nodes (this leads to various issues like conflicting datachange exceptions, etc.) Proposed patch based on approach mentioned in previous comments (use of clustered DTCL) is below. Have verified in a cluster that all topologies are displayed correctly (not just the shard leader's) with this change |