[vlanmgr] Support Jumbo Frame By Default #1393
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
The brdige created for vlans has a a default MTU of 1500 which is serving as default for vlans added to the bridge. This PR changes the default MTU to 9100 to be inline with portchannels and other interfaces. signed-off-by: Tamer Ahmed <[email protected]>
prsunny
reviewed
Aug 11, 2020
prsunny
approved these changes
Aug 11, 2020
yxieca
approved these changes
Aug 12, 2020
|
retest vs please |
abdosi
pushed a commit
that referenced
this pull request
Aug 19, 2020
The bridge created for vlans has a a default MTU of 1500 which is serving as default for vlans added to the bridge. This PR changes the default MTU to 9100 to be inline with portchannels and other interfaces. signed-off-by: Tamer Ahmed <[email protected]>
|
@tahmed-dev, @prsunny: Should this PR have been cherry-picked to the 201911 branch? It appears the kernel did not add support for this until 4.18, yet the 201911 branch is still running 4.9. |
3 tasks
I am not aware of different Kernel behavior related to Bridge MTU size between versions 4.9 and 4.18. I can verify it with a 201911 image. |
|
@jleveque , yes, I think we cannot port it back to 201911. This explains why we haven't considered this fix before. |
|
@abdosi: It appears you may need to remove this patch from the 201911 branch. |
|
yes, ACK |
|
Reverted from 201911. |
jleveque
added a commit
to sonic-net/sonic-buildimage
that referenced
this pull request
Sep 1, 2020
…nce again (#5242) Remove radvd Makefile and patch, change docker-router-advertiser Dockerfile template to simply install the vanilla radvd package using apt-get. - In PR #2795, we started building radvd from source and patching it to prevent it from erroring out when advertising an MTU of 9100 which was greater than the MTU size configured on the bridge interface (1500), which was due to a limitation in the 4.9 Linux kernel. - Master branch is now using Linux kernel 4.19. As of 4.18, the kernel supports setting a bridge MTU to a value > 1500. - PR sonic-net/sonic-swss#1393 modified vlanmgrd to take advantage of this and now configures the MTU of bridge interfaces in SONiC to the proper size of 9100. Therefore, we no longer need to patch radvd. Since we no longer need to patch radvd, we no longer need to build it from source, so we can save build time by going back to simply installing the vanilla radvd Debian package in the router-advertiser container.
santhosh-kt
pushed a commit
to santhosh-kt/sonic-buildimage
that referenced
this pull request
Feb 25, 2021
…nce again (sonic-net#5242) Remove radvd Makefile and patch, change docker-router-advertiser Dockerfile template to simply install the vanilla radvd package using apt-get. - In PR sonic-net#2795, we started building radvd from source and patching it to prevent it from erroring out when advertising an MTU of 9100 which was greater than the MTU size configured on the bridge interface (1500), which was due to a limitation in the 4.9 Linux kernel. - Master branch is now using Linux kernel 4.19. As of 4.18, the kernel supports setting a bridge MTU to a value > 1500. - PR sonic-net/sonic-swss#1393 modified vlanmgrd to take advantage of this and now configures the MTU of bridge interfaces in SONiC to the proper size of 9100. Therefore, we no longer need to patch radvd. Since we no longer need to patch radvd, we no longer need to build it from source, so we can save build time by going back to simply installing the vanilla radvd Debian package in the router-advertiser container.
EdenGri
pushed a commit
to EdenGri/sonic-swss
that referenced
this pull request
Feb 28, 2022
…sonic-net#1393) Add PortChannels to the list of interfaces (port_id_2_iface) to support FDB dump for PortChannel in a VLAN group. Fix sonic-net/sonic-buildimage#4793 - How I did it - Get LAG ID from the DB. - Find the LAG name from APP DB. - Add it to the list of 'port_id_2_iface' to be used. - How to verify it Reproduce the issue mentioned on this PR and try to run fast-reboot with this fix. - Previous command output (if the output of a command-line utility has changed) Traceback: src_ifs = {map_mac_ip_per_vlan[vlan_name][dst_mac] for vlan_name, dst_mac, _ in arp_entries} KeyError: 'b8:59:9f:a8:e2:00' Signed-off-by: Shlomi Bitton <[email protected]>
EdenGri
pushed a commit
to EdenGri/sonic-swss
that referenced
this pull request
Feb 28, 2022
bug introduced in sonic-net#1393 Signed-off-by: Guohan Lu <[email protected]>
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.
The bridge created for vlans has a a default MTU of 1500 which is
serving as default for vlans added to the bridge. This PR changes
the default MTU to 9100 to be inline with portchannels and other
interfaces.
signed-off-by: Tamer Ahmed [email protected]
What I did
Change the default mtu size of the host bridge interface
Why I did it
Adding support for jumbo frames
How I verified it
building an image with the change and could see Vlan100 having mtu set as 9100
Adding/removal of different vlan members with mtu 1500 did not affect the Bridge MTU settings.
Details if related