Uisp integration enhancements: Topology #328
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Rather than obeying the "parent" field, which leads to wrong-way up graphs when building from a non-root site - instead build a complete cost-based spanning tree from the specified root node. Then use the generated tree - falling back on parent if nothing is found - to populate the tree in order. Tested on Herbert's network, correctly generates topology from several different locations. Still to come: adding a mechanism for providing parenting overloads to allow for cases where a long path is actually optimal, but we have no way of knowing that.
…te determination. Requested by D. Denson. Now that the UISP network tree is built as a spanning tree, with 10 cost per hop we can reliably flip the tree from A->B->C to C->B->A depending upon root positioning. This addition allows you to specify additional routes (that MUST exist!) e.g. A->C and specify a cost to use instead of the default 10. This allows for topologies in which A-B-C is actually faster than a direct A-C route (for example, becuase of short 60ghz hops).
|
is each 'hop' a cost of 1? for example, A>B>C>D is cost 3. So A<>D cost 4 would be sufficient to keep it out of the chain? |
|
The default cost is 10 (to allow for cases where you may want to use a
lower override)
…On Tue, Apr 11, 2023, 4:12 PM syadnom ***@***.***> wrote:
is each 'hop' a cost of 1? for example, A>B>C>D is cost 3. So A<>D cost 4
would be sufficient to keep it out of the chain?
—
Reply to this email directly, view it on GitHub
<#328 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADRU4375GN63YRMPLEGNVK3XAXCK7ANCNFSM6AAAAAAW2OP2NQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
This made it to where I can finally let the UISP integration dynamically update the network.json file. Saves me lots of time previously spent on adjustments to network.json Thank you @thebracket ! |
|
You're very welcome - glad it's working! It solved an issue we'd been
having, too (with a site that is linked to two towers, and UISP getting
confused)
…On Tue, Apr 11, 2023 at 5:57 PM Robert Chacón ***@***.***> wrote:
This made it to where I can finally let the UISP integration dynamically
update the network.json file. Saves me lots of time previously spent on
adjustments to network.json Thank you @thebracket
<https://github.com/thebracket> !
—
Reply to this email directly, view it on GitHub
<#328 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADRU4337AYZR3O7LQBAVWLLXAXOXHANCNFSM6AAAAAAW2OP2NQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Replace the UISP network.json generator that previously used UISP's "parent" nodes to determine tree position with a full cost-based spanning tree (Dijkstra). This makes multi-homed networks easier to manage, by specifying a root position other than the "natural" route and regenerating the entire tree relative to this node location. So flipping
A->B->C->Dto beD->C->B->Aworks well, as doesB->A, B->C->D.The second half adds a file named
integrationUISProutes.csv. It contains "from", "to" and "cost" fields. When the tree builder finds a route "from->to", it uses the cost specified in this file. This allows you to override behavior, for example if you haveA->B->Cand also haveA->Cbut don't wantA->Cto be the default - you can specify a high cost (say 100) forA->C.For example, given the following topology:
graph LR A-->B B-->C C-->DYou could change the root to be D and have:
graph LR D-->C C-->B B-->AGiven a more complex hierarchy:
graph LR D-->C C-->B B-->A D-->AOne could enter a row in
integrationUISProutes.csv:And the shorter D->A route would be ignored:
graph LR D-->C C-->B B-->A D--Ignored-->A