-
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
Switch Port Modes and VLAN CLI Enhancement #912
Conversation
|
||
## 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. |
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 believe, there is a HLD for VLAN stacking (https://github.com/Azure/SONiC/pull/915/files), this HLD seems duplicate, please clarify.
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.
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.
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.
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.
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.
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.
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.
This feature is not in community release tracking list.
8498931
to
8837dc2
Compare
|
74da15e
to
818f47a
Compare
We have updated our HLD along with the code. @venkatmahalingam pls review. |
@venkatmahalingam can you please review this PR and approve if you are ok? Thanks. |
@venkatmahalingam can you please help to review this HLD and corresponding code PR? Thanks. |
Yes @zhangyanzhao, I have added my comments. |
@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, We can update the VLAN column of "show interface status" accordingly. IMO, adding 'mode' field in the PORT table is unnecessary. |
@prsunny @dgsudharsan Please review this HLD. |
@gechiang can you please review and merge this PR. Target is 202305 |
|
||
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) |
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.
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...
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, untagged member will be retained when moving from access to trunk or vice versa. Modified this section, as per your concern.
doc/vlan/switchport-mode-support/Switchport Mode and VLAN CLI Enhancement.md
Show resolved
Hide resolved
doc/vlan/switchport-mode-support/Switchport Mode and VLAN CLI Enhancement.md
Show resolved
Hide resolved
doc/vlan/switchport-mode-support/Switchport Mode and VLAN CLI Enhancement.md
Show resolved
Hide resolved
@zhangyanzhao can you please merge this PR, Thanks |
We have created an HLD for Switchport modes and enhancements to VLAN CLI.
Related PRs:
HLD signoff people:
@gechiang , @venkatmahalingam
Yang mode code PR:
@ganglyu