803c71c86a
<!-- Please make sure you've read and understood our contributing guidelines: https://github.com/Azure/SONiC/blob/gh-pages/CONTRIBUTING.md ** Make sure all your commits include a signature generated with `git commit -s` ** If this is a bug fix, make sure your description includes "fixes #xxxx", or "closes #xxxx" or "resolves #xxxx" Please provide the following information: --> #### Why I did it fixes: https://github.com/sonic-net/sonic-buildimage/issues/16001 Caused by: https://github.com/sonic-net/sonic-buildimage/pull/15487 The above PR introduced change to use Management and Loopback Ipv4 and ipv6 addresses as snmpagent address in snmpd.conf file. With this change, if Link local IP address is configured as management or Loopback IPv6 address, then snmpd tries to open socket on that ipv6 address and fails with the below error: ``` Error opening specified endpoint "udp6:[fe80::5054:ff:fe6f:16f0]:161" Server Exiting with code 1 ``` From RFC4007, if we need to specify non-global ipv6 address without ambiguity, we need to use zone id along with the ipv6 address: <address>%<zone_id> Reference: https://datatracker.ietf.org/doc/html/rfc4007 ##### Work item tracking - Microsoft ADO **(number only)**: #### How I did it Modify snmpd.conf file to use the %zone_id representation for ipv6 address. #### How to verify it In VS testbed, modify config_db to use link local ipv6 address as management address: "MGMT_INTERFACE": { "eth0|10.250.0.101/24": { "forced_mgmt_routes": [ "172.17.0.1/24" ], "gwaddr": "10.250.0.1" }, "eth0|fe80::5054:ff:fe6f:16f0/64": { "gwaddr": "fe80::1" } }, Execute config_reload after the above change. snmpd comes up and check if snmpd is listening on ipv4 and ipv6 addresses: ``` admin@vlab-01:~$ sudo netstat -tulnp | grep 161 tcp 0 0 127.0.0.1:3161 0.0.0.0:* LISTEN 274060/snmpd udp 0 0 10.1.0.32:161 0.0.0.0:* 274060/snmpd udp 0 0 10.250.0.101:161 0.0.0.0:* 274060/snmpd udp6 0 0 fc00:1::32:161 :::* 274060/snmpd udp6 0 0 fe80::5054:ff:fe6f::161 :::* 274060/snmpd -- Link local admin@vlab-01:~$ sudo ifconfig eth0 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.250.0.101 netmask 255.255.255.0 broadcast 10.250.0.255 inet6 fe80::5054:ff:fe6f:16f0 prefixlen 64 scopeid 0x20<link> ether 52:54:00:6f:16:f0 txqueuelen 1000 (Ethernet) RX packets 36384 bytes 22878123 (21.8 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 261265 bytes 46585948 (44.4 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 admin@vlab-01:~$ docker exec -it snmp snmpget -v2c -c public fe80::5054:ff:fe6f:16f0 1.3.6.1.2.1.1.1.0 iso.3.6.1.2.1.1.1.0 = STRING: "SONiC Software Version: SONiC.master.327516-04a6031b2 - HwSku: Force10-S6000 - Distribution: Debian 11.7 - Kernel: 5.10.0-18-2-amd64" ``` Logs from snmpd: ``` Turning on AgentX master support. NET-SNMP version 5.9 Connection from UDP/IPv6: [fe80::5054:ff:fe6f:16f0%eth0]:44308 ``` Ran test_snmp_loopback test to check if loopback ipv4 and ipv6 works: ``` ./run_tests.sh -n vms-kvm-t0 -d vlab-01 -c snmp/test_snmp_loopback.py -f vtestbed.yaml -i ../ansible/veos_vtb -e "--skip_sanity --disable_loganalyzer" -u === Running tests in groups === Running: pytest snmp/test_snmp_loopback.py --inventory ../ansible/veos_vtb --host-pattern vlab-01 --testbed vms-kvm-t0 --testbed_file vtestbed.yaml --log-cli-level warning --log-file-level debug --kube_master unset --showlocals --assert plain --show-capture no -rav --allow_recover --ignore=ptftests --ignore=acstests --ignore=saitests --ignore=scripts --ignore=k8s --ignore=sai_qualify --junit-xml=logs/tr.xml --log-file=logs/test.log --skip_sanity --disable_loganalyzer .. snmp/test_snmp_loopback.py::test_snmp_loopback[vlab-01] PASSED ``` <!-- If PR needs to be backported, then the PR must be tested against the base branch and the earliest backport release branch and provide tested image version on these two branches. For example, if the PR is requested for master, 202211 and 202012, then the requester needs to provide test results on master and 202012. --> #### Which release branch to backport (provide reason below if selected) <!-- - Note we only backport fixes to a release branch, *not* features! - Please also provide a reason for the backporting below. - e.g. - [x] 202006 --> - [ ] 201811 - [ ] 201911 - [ ] 202006 - [x] 202012 - [x] 202106 - [x] 202111 - [x] 202205 - [x] 202211 - [x] 202305 #### Tested branch (Please provide the tested image version) <!-- - Please provide tested image version - e.g. - [x] 20201231.100 --> - [ ] <!-- image version 1 --> - [ ] <!-- image version 2 --> #### Description for the changelog <!-- Write a short (one line) summary that describes the changes in this pull request for inclusion in the changelog: --> <!-- Ensure to add label/tag for the feature raised. example - PR#2174 under sonic-utilities repo. where, Generic Config and Update feature has been labelled as GCU. --> #### Link to config_db schema for YANG module changes <!-- Provide a link to config_db schema for the table for which YANG model is defined Link should point to correct section on https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-yang-models/doc/Configuration.md --> #### A picture of a cute animal (not mandatory but encouraged) |
||
---|---|---|
.azure-pipelines | ||
.github | ||
device | ||
dockers | ||
files | ||
installer | ||
platform | ||
rules | ||
scripts | ||
sonic-slave-bullseye | ||
sonic-slave-buster | ||
sonic-slave-jessie | ||
sonic-slave-stretch | ||
src | ||
.artifactignore | ||
.gitignore | ||
.gitmodules | ||
azure-pipelines.yml | ||
build_debian.sh | ||
build_debug_docker_j2.sh | ||
build_docker.sh | ||
build_image.sh | ||
check_install.py | ||
functions.sh | ||
get_docker-base.sh | ||
install_sonic.py | ||
LICENSE | ||
MAINTAINERS | ||
Makefile | ||
Makefile.cache | ||
Makefile.work | ||
onie-image-arm64.conf | ||
onie-image-armhf.conf | ||
onie-image.conf | ||
onie-mk-demo.sh | ||
push_docker.sh | ||
README.buildsystem.md | ||
README.md | ||
slave.mk | ||
ThirdPartyLicenses.txt | ||
update_screen.sh |
master builds:
202305 builds:
202211 builds:
202205 builds:
202111 builds:
202012 builds:
201911 builds:
201811 builds:
sonic-buildimage
Build SONiC Switch Images
Description
Following are the instructions on how to build an (ONIE) compatible network operating system (NOS) installer image for network switches, and also how to build docker images running inside the NOS. Note that SONiC images are build per ASIC platform. Switches using the same ASIC platform share a common image. For a list of supported switches and ASIC, please refer to this list
Hardware
Any server can be a build image server as long as it has:
- Multiple cores to increase build speed
- Plenty of RAM (less than 8 GiB is likely to cause issues)
- 300G of free disk space
- KVM Virtualization Support.
Note: If you are in a VM, make sure you have support for nested virtualization. Some cases (e.g. building OVS image) also requires extra configuration options to expose the full KVM interface to the VM (e.g. the KVM paravirtualization support on VirtualBox).
A good choice of OS for building SONiC is currently Ubuntu 20.04.
Prerequisites
- Install pip and jinja in host build machine, execute below commands if j2/j2cli is not available:
sudo apt install -y python3-pip
pip3 install --user j2cli
- Install Docker and configure your
system to allow running the 'docker' command without 'sudo':
- Add current user to the docker group:
sudo gpasswd -a ${USER} docker
- Log out and log back in so that your group membership is re-evaluated
- Add current user to the docker group:
Note: If a previous installation of Docker using snap was present on the system, remove it and also remove docker from snap before reinstallating docker. This will avoid known bugs that falsely report read-only filesystems issues during the build process.
Clone the repository with all the git submodules
To clone the code repository recursively:
git clone --recurse-submodules https://github.com/sonic-net/sonic-buildimage.git
Usage
To build SONiC installer image and docker images, run the following commands:
# Ensure the 'overlay' module is loaded on your development system
sudo modprobe overlay
# Enter the source directory
cd sonic-buildimage
# (Optional) Checkout a specific branch. By default, it uses master branch.
# For example, to checkout the branch 201911, use "git checkout 201911"
git checkout [branch_name]
# Execute make init once after cloning the repo,
# or after fetching remote repo with submodule updates
make init
# Execute make configure once to configure ASIC
make configure PLATFORM=[ASIC_VENDOR]
# Build SONiC image with 4 jobs in parallel.
# Note: You can set this higher, but 4 is a good number for most cases
# and is well-tested.
make SONIC_BUILD_JOBS=4 all
The supported ASIC vendors are:
- PLATFORM=barefoot
- PLATFORM=broadcom
- PLATFORM=marvell
- PLATFORM=mellanox
- PLATFORM=cavium
- PLATFORM=centec
- PLATFORM=nephos
- PLATFORM=innovium
- PLATFORM=vs
Usage for ARM Architecture
ARM build has dependency in docker version 18. If docker version is 19, downgrade to 18 with:
sudo apt-get install --allow-downgrades -y docker-ce=5:18.09.0~3-0~ubuntu-xenial
sudo apt-get install --allow-downgrades -y docker-ce-cli=5:18.09.0~3-0~ubuntu-xenial
To build Arm32 bit for (ARMHF) platform
# Execute make configure once to configure ASIC and ARCH
make configure PLATFORM=[ASIC_VENDOR] PLATFORM_ARCH=armhf
make target/sonic-[ASIC_VENDER]-armhf.bin
example:
make configure PLATFORM=marvell-armhf PLATFORM_ARCH=armhf
make target/sonic-marvell-armhf.bin
To build Arm32 bit for (ARMHF) Marvell platform on amd64 host for debian buster using cross-compilation, run the following commands:
# Execute make configure once to configure ASIC and ARCH for cross-compilation build
NOJESSIE=1 NOSTRETCH=1 BLDENV=buster CROSS_BLDENV=1 \
make configure PLATFORM=marvell-armhf PLATFORM_ARCH=armhf
# Execute Arm32 build using cross-compilation environment
NOJESSIE=1 NOSTRETCH=1 BLDENV=buster CROSS_BLDENV=1 make target/sonic-marvell-armhf.bin
Running the above Arm32 build using cross-compilation instead of qemu emulator drastically reduces the build time.
To build Arm64 bit for platform
# Execute make configure once to configure ASIC and ARCH
make configure PLATFORM=[ASIC_VENDOR] PLATFORM_ARCH=arm64
# example:
make configure PLATFORM=marvell-arm64 PLATFORM_ARCH=arm64
NOTE:
-
Recommend reserving at least 100G free space to build one platform with a single job. The build process will use more disk if you are setting
SONIC_BUILD_JOBS
to more than 1. -
If Docker's workspace folder,
/var/lib/docker
, resides on a partition without sufficient free space, you may encounter an error like the following during a Docker container build job:/usr/bin/tar: /path/to/sonic-buildimage/<some_file>: Cannot write: No space left on device
The solution is to move the directory to a partition with more free space.
-
Use
http_proxy=[your_proxy] https_proxy=[your_proxy] no_proxy=[your_no_proxy] make
to enable http(s) proxy in the build process. -
Add your user account to
docker
group and use your user account to make.root
orsudo
are not supported.
The SONiC installer contains all docker images needed. SONiC uses one image for all devices of a same ASIC vendor.
For Broadcom ASIC, we build ONIE and EOS image. EOS image is used for Arista devices, ONIE image is used for all other Broadcom ASIC based devices.
make configure PLATFORM=broadcom
# build debian stretch required targets
BLDENV=stretch make stretch
# build ONIE image
make target/sonic-broadcom.bin
# build EOS image
make target/sonic-aboot-broadcom.swi
You may find the rules/config file useful. It contains configuration options for the build process, like adding more verbosity or showing dependencies, username and password for base image etc.
Every docker image is built and saved to target/ directory. So, for instance, to build only docker-database, execute:
make target/docker-database.gz
Same goes for debian packages, which are under target/debs/:
make target/debs/swss_1.0.0_amd64.deb
Every target has a clean target, so in order to clean swss, execute:
make target/debs/swss_1.0.0_amd64.deb-clean
It is recommended to use clean targets to clean all packages that are built together, like dev packages for instance. In order to be more familiar with build process and make some changes to it, it is recommended to read this short Documentation.
Build debug dockers and debug SONiC installer image
SONiC build system supports building dockers and ONIE-image with debug tools and debug symbols, to help with live & core debugging. For details refer to SONiC Buildimage Guide.
SAI Version
Please refer to SONiC roadmap on the SAI version for each SONiC release.
Notes
- If you are running make for the first time, a sonic-slave-${USER} docker image will be built automatically. This may take a while, but it is a one-time action, so please be patient.
- The root user account is disabled. However, the created user can
sudo
. - The target directory is
./target
, containing the NOS installer image and docker images.- sonic-generic.bin: SONiC switch installer image (ONIE compatible)
- sonic-aboot.bin: SONiC switch installer image (Aboot compatible)
- docker-base.gz: base docker image where other docker images are built from, only used in build process (gzip tar archive)
- docker-database.gz: docker image for in-memory key-value store, used as inter-process communication (gzip tar archive)
- docker-fpm.gz: docker image for quagga with fpm module enabled (gzip tar archive)
- docker-orchagent.gz: docker image for SWitch State Service (SWSS) (gzip tar archive)
- docker-syncd-brcm.gz: docker image for the daemon to sync database and Broadcom switch ASIC (gzip tar archive)
- docker-syncd-cavm.gz: docker image for the daemon to sync database and Cavium switch ASIC (gzip tar archive)
- docker-syncd-mlnx.gz: docker image for the daemon to sync database and Mellanox switch ASIC (gzip tar archive)
- docker-syncd-nephos.gz: docker image for the daemon to sync database and Nephos switch ASIC (gzip tar archive)
- docker-syncd-invm.gz: docker image for the daemon to sync database and Innovium switch ASIC (gzip tar archive)
- docker-sonic-p4.gz: docker image for all-in-one for p4 software switch (gzip tar archive)
- docker-sonic-vs.gz: docker image for all-in-one for software virtual switch (gzip tar archive)
- docker-sonic-mgmt.gz: docker image for managing, configuring and monitoring SONiC (gzip tar archive)
Contribution Guide
All contributors must sign a contribution license agreement before contributions can be accepted. Visit EasyCLA - Linux Foundation.
GitHub Workflow
We're following basic GitHub Flow. If you have no idea what we're talking about, check out GitHub's official guide. Note that merge is only performed by the repository maintainer.
Guide for performing commits:
- Isolate each commit to one component/bugfix/issue/feature
- Use a standard commit message format:
[component/folder touched]: Description intent of your changes
[List of changes]
Signed-off-by: Your Name your@email.com
For example:
swss-common: Stabilize the ConsumerTable
- Fixing autoreconf
- Fixing unit-tests by adding checkers and initialize the DB before start
- Adding the ability to select from multiple channels
- Health-Monitor - The idea of the patch is that if something went wrong with the notification channel, we will have the option to know about it (Query the LLEN table length).
Signed-off-by: user@dev.null
- Each developer should fork this repository and add the team as a Contributor
- Push your changes to your private fork and do "pull-request" to this repository
- Use a pull request to do code review
- Use issues to keep track of what is going on
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.