-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiple Spanning Tree Protocol (MSTP) HLD #1298
Conversation
5321c1e
to
7d5eb3e
Compare
@zhangyanzhao can you please assign this HLD to @hamnarauf Thanks! |
SONiC community review recording https://zoom.us/rec/share/3XxqJ20eag07iK0x7T_4YqBq6jhbyWXGjpk72AvHL35peWSOXZ04w_ZQjGlwXJbM.0DPyXu03R_bS0Gry |
doc/stp/MSTP_HLD.md
Outdated
||SAI_SWITCH_ATTR_MAX_STP_INSTANCE| | ||
|
||
## New SAI Attributes | ||
MSTP design requires one new attribute `SAI_HOSTIF_TRAP_TYPE_MSTP` for control trap packets which will be defined in saihostif.h. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please explain why SAI_HOSTIF_TRAP_TYPE_STP is not sufficient. The DMAC and LLC fields are identical for STP and MSTP. Creating separate trap types for STP and MSTP would required the hardware to parse/match the BPDU protocol identifier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can discuss this in coming SAI meeting. For reference, please see this PR Add hostif trap for MSTP
@lguohan , Please find following are unmerged PRs of PVST, that needs to merged for MSTP: |
@zhangyanzhao pls add @wajahatrazi as assignee for this HLD. |
@hamnarauf can you please help to add the code PR list in this HLD? Thanks. |
Hi @zhangyanzhao , Hamna is no longer assignee on this feature. Please consider @Wajahat as assignee on this from now onward. We are working on MSTP code and waiting for @adyeung help in unmereged code PR of PVST. Thanks! |
@ridahanif96 can you please help to add the code PRs to this HLD by referring to #806 ? Thanks! |
@divyachandralekha Hi Divya,can you please review this HLD! |
The table holds the state of a port i.e forwarding, learning, blocking with respect to each instance. | ||
#### STP_VLAN_INSTANCE_TABLE | ||
The table holds the VLAN to instance mapping. | ||
#### STP_FASTAGEING_FLUSH_TABLE |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A per-VLAN flush may trigger a lot of churn, especially considering the possibility of 4K VLANs mapped to one MST instance. Here, only one flush is necessary. You may need to consider optimisation in this scenario.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it might be cumber-sum to flush for each VLAN. We will consider one FDB Flush for every MSTI for optimization.
doc/stp/MSTP_HLD.md
Outdated
# Sequence Diagrams | ||
## MSTP global enable | ||
|
||
Only the VLANs that are currently present will be mapped to IST instance. A VLAN cannot be mapped to an instance if it has not been created yet. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When we have this limitation , managing the IST configuration becomes more complex. Especially in environments where VLANs are frequently added or removed. Administrators must continuously update the IST configuration to reflect changes in VLAN membership.
Creating a VLAN and then adding it to the Internal Spanning Tree (IST) configuration can potentially create convergence churn and disturb the existing network.
You may need to consider pre-configuring VLAN-to-instance mapping before actually creating the VLAN.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, we will consider pre-configuring VLAN-to instance mapping to avoid convergence churn.
Below commands allow configuring on region basis: | ||
|
||
- **config spanning_tree region name \<region-name\>** | ||
- Edit the name of region |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you support empty region name ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Name is an empty string it could have 0 value by default for region name
doc/stp/MSTP_HLD.md
Outdated
- **config spanning_tree instance (add|del) \<instance-id\>** | ||
- Creation or deletion of an instance. | ||
- instance-id: Default: 0, range: 1-63 | ||
- Instance can not be deleted if VLAN(s) are associated with it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the reason behind this restriction?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The restriction here on an MSTP instance when VLANs are associated with it serves to prevent accidental deletions that could lead to network inconsistencies and loops in VLAN topologies. This approach aligns with industry standards followed by Cisco, Huawei, and SONiC, ensuring consistency and clarity for users familiar with these platforms. Additionally, in SONiC, an interface associated with a VLAN also prevents the deletion of that VLAN, maintaining the integrity of the network configuration.
Hi @divyachandralekha , do you have more suggestions on the design? if no can you please help approve this PR. Also we can discuss offline for PVST code PRs and our workflows for bringing STP/PVST/MSTP to SONiC |
@ridahanif96 The earlier PVST code PRs will be updated and reposted in the next community release |
@adyeung thanks Adam!, till then it would be great if we also finalize this design and merge this. |
@rck-innovium Hi Ravi, can you please help review this design. As per suggestion earlier in SAI community we had updated SAI Modification for MSTP control packets. |
Update CONFIG/APP DB and yang model
2. Assigning VLAN to instance via SAI STP API and SAI VLAN API. | ||
3. Creation of STP Port and assigning port state with respect to each instance via SAI STP API. | ||
4. Flushing FDB entries via SAI FDB API. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BPDU guard functionality requires link-state control, maybe we need to add SAI api that control link state here as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PortOrch already has link state control SAI attributes. STP notifies OrchAgent of any link state changes, which are then managed accordingly.
- Configure an interface as a bpdu_guard. | ||
|
||
Interface level CLI configurations of root guard, BPDU guard will also be supported for spanning-tree mode `mstp`. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see STP can be enabled on "portchannel" as well, so im assuming we may need to add CLI restrictions to ensure that when STP is enabled on a portchannel, the portchannel group cannot be deleted/modified.
If thats true, please ensure its captured here or a different section of HLD
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Design will handle Portchannel modification/deletion automatically , so we don't plan to add any restrictions to prevent these operation on a STP enabled PortChannel.
Responsible for all MST protocol related calculations. BPDUs are sent and received in STPd and states are updated accordingly. | ||
|
||
### STPSync | ||
A process running as a part of STPD. Responsible for updating all the MSTP states in APP DB. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple of questions here,
- is "stpSync" process forked within "STPd".
- Is "STPd" taken from a open-source implementation for instance https://github.com/sonic-net/sonic-stp ?
Assuming the answer to the above is 'yes', would be it cleaner to have "STPsync" implemented outside of "STPd" and then have IPCs to communicate port-states, fdb flush & link state events.
Doing this will ensure "STPd" repo has minimal integration changes and syncing it later to open-source repo would be easier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
stpsync is not a process. STPSync is a component integrated within STPd responsible for managing and updating all operational STP data to APP DB.
We will update the same in HLD.
### STPSync | ||
A process running as a part of STPD. Responsible for updating all the MSTP states in APP DB. | ||
|
||
The BPDU rx/tx, BPDU processing, handling of timers, handling of changes related to port or LAG using netlink events and STP port state sync to Linux Kernel will function the same as PVST. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the port state programming fails, how to handle the use-case. Can you please provide your thought process on the same
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if port state programming we will keep trying to set it until succeeds.
} | ||
default 128; | ||
description | ||
"The manageable component of the Port Identifier, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please add the information that priority values should be increments of 16 in the description?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We will update the HLD
- Specify configuring the port level priority for root bridge in seconds. | ||
Default: 128, range 0-240 | ||
- **config spanning_tree mst cost \<cost-value\>** | ||
- Specify configuring the port level priority for root bridge in seconds. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this description needs an update to match the command? And path cost configuration should be supported only per interface or global?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Path cost works for both cases per interface and global. These are two separate set of commands for each case.
- **config spanning_tree interface \<ifname\> bpdu_guard {enable|disable}** | ||
- Configure an interface as a bpdu_guard. | ||
|
||
- **config spanning_tree interface \<ifname\> guard {root|bpdu}** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this CLI command a condensed version of the above two seperate bpdu and root guard configuration commands?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We will update HLD with reference to this point
Is the plan to merge the code for both PVST and MSTP together for the community sonic or would one be merged before? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good
No, As discussed in PENS WG , we will only provide MSTP for the community in this release ,we will not be looking into PVST code merged. |
@madhupalu , @praveenraja1 , @sutharsansr @adyeung @zhangyanzhao , This PR will be closed to avoid confusion. |
Closing this PR, revised HLD in the following submission |
This document describes the design details for IEEE 802.1s - Multiple Spanning Tree Protocol (MSTP) support in SONiC.