Skip to content
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

Switch Port Modes and VLAN CLI Enhancement #912

Merged
merged 70 commits into from
Jun 16, 2023

Conversation

ham-xa
Copy link
Contributor

@ham-xa ham-xa commented Dec 14, 2021

We have created an HLD for Switchport modes and enhancements to VLAN CLI.

Related PRs:

Repo PR title State
sonic-utilities Switch Port Modes and VLAN CLI Enhancement GitHub issue/pull request detail
sonic-buildimage Switchport Modes Port & Port Channel Yang Model Configurations GitHub issue/pull request detail
sonic-mgmt updated vlan creation in '/spytest/apis/switching/vlan.py' with switchport mode assignment GitHub issue/pull request detail

HLD signoff people:
@gechiang , @venkatmahalingam

Yang mode code PR:
@ganglyu

@ghost
Copy link

ghost commented Dec 14, 2021

CLA assistant check
All CLA requirements met.


## Introduction

IEEE 802.1Q is a networking standard which defines the VLANs tagging on an ethernet network. The Ethernet frame contains a TAG with fields that specify VLAN membership and user priority. As seen in the below Ethernet frame, the TAG is inserted between the Source MAC address and Type/Length. The TAG is of 16-bit length. The 802.1Q tags are inserted into the frames before transmitting out of the interface and similarly, the tags are removed from frames received from the interface. The frames are transmitted and received from the interfaces that are configured with VLAN and they are tagged with VID.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe, there is a HLD for VLAN stacking (https://github.com/Azure/SONiC/pull/915/files), this HLD seems duplicate, please clarify.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To the best of our understanding, our HLD and HLD 915 (VLAN Stacking), submitted about a week after our HLD, are very different. Our HLD covers the 802.1Q trunking encapsulation implementation within a client network. On the contrary, HLD 915 covers the VLAN staking Q-in-Q which is related to the ISP network. So, there is no duplication in both the HLDs.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per my understanding, the outer tag TPID is 0x8100 instead of 0x88a8 in the HLD 915, and I think, your encapsulation also does the same thing, please read the HLD 915 and combine the HLDs if required.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this HLD we have implemented 802.1Q standard with respect to client networks which performs frame tagging for carrying different VLANs traffic on the trunk link within a client network. Only one tag is added within the client network (No stacking). On the other hand, HLD # 915 has implemented 802.1ad which deals with the forwarding of VLAN IDs (VIDs) between geographically separated different sites of the clients connected via ISPs. ISPs use 802.1ad for stacking VID from different clients and add an ISP tag on top of those stacked VIDs. So, 802.1ad deals with the tagging inside an ISPs network and 802.1Q deals with the tagging inside clients networks. There is another type of tagging according to 802.1ah standard which deals with another layer of stacking of ISP's tags inside Backbone networks. All of these three Vlan tagging standards are independent and have a completely disjoint scope of operation. These standards are identified by switches from different values of TPID field inside the tags, 81-00 for customer VLAN Tag, 88-a8 for Service Provider or Backbone VLAN Tags and 88-e7 for Backbone Service Instance Tag. Please refer to table 9-1 of the IEEE 802.1Q-2018 standards guide for the details of technical differences in these standards. The IEEE 802.1Q-2018 standards guide is available at: https://standards.ieee.org/standard/802_1Q-2018.html. Thus, The scope of this HLD and HLD#915 are very different and are implementing related but different and disjoint standards. In SONiC roadmap "L2 Dot1Q tunneling support" is mentioned so we started implementation from the 802.1Q baseline standard and we have had plans for implementing 802.1ad and 802.1ah in separate HLDs.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feature is not in community release tracking list.

@yxieca yxieca force-pushed the master branch 2 times, most recently from 8498931 to 8837dc2 Compare April 15, 2022 16:51
@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Sep 30, 2022

@ham-xa ham-xa changed the title L2 IEEE 802.1Q Tunneling Support in SONiC Switch Port Modes and VLAN CLI Enhancement Oct 24, 2022
@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Oct 26, 2022

CLA Signed

The committers listed above are authorized under a signed CLA.

@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Oct 26, 2022

CLA Signed

The committers listed above are authorized under a signed CLA.

@ridahanif96
Copy link
Collaborator

We have updated our HLD along with the code. @venkatmahalingam pls review.

@zhangyanzhao
Copy link
Collaborator

@venkatmahalingam can you please review this PR and approve if you are ok? Thanks.

@zhangyanzhao
Copy link
Collaborator

@venkatmahalingam can you please help to review this HLD and corresponding code PR? Thanks.

@venkatmahalingam
Copy link
Collaborator

@venkatmahalingam can you please help to review this HLD and corresponding code PR? Thanks.

Yes @zhangyanzhao, I have added my comments.

@zhangyanzhao
Copy link
Collaborator

@venkatmahalingam can you please approve this PR if all your comments have been addressed? Otherwise, can you please help to repaste your question? I am not quite clear what is open now.

@venkatmahalingam
Copy link
Collaborator

@venkatmahalingam can you please approve this PR if all your comments have been addressed? Otherwise, can you please help to repaste your question? I am not quite clear what is open now.

I don't think, we need 'mode' field in the PORT table.

Please check following in VLAN_MEMBER table,
If the port is untagged to only one VLAN - Access mode
If the port is untagged member to one VLAN and tagged member to one or more VLAN - Trunk mode
If the port is not present in VLAN_MEMBER table - Routed mode

We can update the VLAN column of "show interface status" accordingly. IMO, adding 'mode' field in the PORT table is unnecessary.

@venkatmahalingam
Copy link
Collaborator

@prsunny @dgsudharsan Please review this HLD.

@ridahanif96
Copy link
Collaborator

@gechiang can you please review and merge this PR. Target is 202305

@ham-xa ham-xa requested a review from gechiang June 12, 2023 07:20

The following state transition depicts the behavior of Switchport modes access and trunk for adding port modes on a Port or PortChannel. Switching between these modes is also depicted here. Default port mode is “routed”.

![State-Transition-Diagram](https://user-images.githubusercontent.com/61490193/223195784-05cc4e98-8883-4911-bca3-fded6a87d202.png)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This diagram conflicts with what you have states under this section:

Examples/Usage of Switchport Modes Command
Following example shows usage of switchport modes “access” and “trunk” and switching of port mode from routed to access/trunk. Before switching mode from routed to access/trunk, the user must remove IP first. After the mode has been switched to access/trunk there will be no untagged/tagged vlan member(s) assigned

So when you move from trunk to access or vice versa, do youy keep the "untagged" membership or that is also removed? the diagram seems to say it retains the "untagged" membership. I actually like retaining the untagged membership and only force the user to have to remove the tagged memebrship when moving from trunk to access...

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, untagged member will be retained when moving from access to trunk or vice versa. Modified this section, as per your concern.

@ridahanif96
Copy link
Collaborator

@zhangyanzhao can you please merge this PR, Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.