Allow alternative agentx socket configuration #92
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
* ifSpeed now reports speed under 2^32 bps * ifSpeed returns 2^32 is speed is above * ifHighSpeed reports the interface speed in Mbps * ifHighSpeed defaults to 40000 if speed not available in APPL_DB * unit tests for rfc1213 and rfc2863 * appl_db.json modified to provide variety of speeds Signed-off-by: michel.moriniaux@gmail.com
* ifSpeed now reports speed under 2^32 bps * ifSpeed returns 2^32 is speed is above * ifHighSpeed reports the interface speed in Mbps * ifHighSpeed defaults to 40000 if speed not available in APPL_DB * unit tests for rfc1213 and rfc2863 * appl_db.json modified to provide variety of speeds Signed-off-by: michel.moriniaux@gmail.com
* ifSpeed now reports speed under 2^32 bps * ifSpeed returns 2^32 is speed is above * ifHighSpeed reports the interface speed in Mbps * ifHighSpeed defaults to 40000 if speed not available in APPL_DB * unit tests for rfc1213 and rfc2863 * appl_db.json modified to provide variety of speeds Signed-off-by: michel.moriniaux@gmail.com
* ifAlias should retrun the interface description not the SONiC name * unit tests Signed-off-by: michel.moriniaux@gmail.com
* missing self. keyword Signed-off-by: michel.moriniaux@gmail.com
* added code to read the snmpd.conf file for alternate agentx socket * added code to open the connection according to the type of socket This will allow external containers to use agentx to communicate with the snmp container. This is done by changing the default unix socket /var/agentx/master to a tcp socket via the /etc/snmp/snmpd.conf file. The agentx implementation reads the config directive from this file and adapts accordingly This allows export of SNMP metrics by the FRR container for eg. signed-off-by: Michel Moriniaux <michel.moriniaux@gmail.com>
qiluo-msft
reviewed
Nov 19, 2018
qiluo-msft
reviewed
Nov 19, 2018
qiluo-msft
reviewed
Nov 19, 2018
qiluo-msft
reviewed
Nov 19, 2018
qiluo-msft
reviewed
Nov 19, 2018
qiluo-msft
reviewed
Nov 19, 2018
qiluo-msft
reviewed
Nov 19, 2018
|
Could you refine the PR title, with at least one verb? #Closed |
|
May I ask if vanilla quagga also has the capability? Not limited to FRR? #Closed |
I wasn't able to make it work on Quagga, even though documentation says it should work. I was not able to compile a working snmp version of Quagga. #Resolved |
MichelMoriniaux
changed the title
Changed #Resolved |
* added code to read the snmpd.conf file for alternate agentx socket * added code to open the connection according to the type of socket * corrections and coments from Qi Luo This will allow external containers to use agentx to communicate with the snmp container. This is done by changing the default unix socket /var/agentx/master to a tcp socket via the /etc/snmp/snmpd.conf file. The agentx implementation reads the config directive from this file and adapts accordingly This allows export of SNMP metrics by the FRR container for eg. signed-off-by: Michel Moriniaux <michel.moriniaux@gmail.com>
|
changes addressed and commits done |
qiluo-msft
reviewed
Nov 20, 2018
* added code to read the snmpd.conf file for alternate agentx socket * added code to open the connection according to the type of socket * corrections and coments from Qi Luo This will allow external containers to use agentx to communicate with the snmp container. This is done by changing the default unix socket /var/agentx/master to a tcp socket via the /etc/snmp/snmpd.conf file. The agentx implementation reads the config directive from this file and adapts accordingly This allows export of SNMP metrics by the FRR container for eg. signed-off-by: Michel Moriniaux <michel.moriniaux@gmail.com>
* added code to read the snmpd.conf file for alternate agentx socket * added code to open the connection according to the type of socket * corrections and coments from Qi Luo This will allow external containers to use agentx to communicate with the snmp container. This is done by changing the default unix socket /var/agentx/master to a tcp socket via the /etc/snmp/snmpd.conf file. The agentx implementation reads the config directive from this file and adapts accordingly This allows export of SNMP metrics by the FRR container for eg. signed-off-by: Michel Moriniaux <michel.moriniaux@gmail.com>
qiluo-msft
approved these changes
Nov 21, 2018
@MichelMoriniaux Since FRR is the default routing stack on master branch, would you like continue the integration? |
|
I think we'll need to create a build option in rules/config as I believe
there is a licencing issue that prevents to distribute binary frr packages
with snmp support built-in. So we would need to put that option in so that
the images available on the Azure Jenkins don't get you in trouble.
What do you think?
…On Wed, May 8, 2019, 19:42 Qi Luo ***@***.***> wrote:
Once the frr container is built with snmp support, the addition of a
/etc/snmp/frr.conf with a single line containing "agenXSocket
tcp:localhost:705" does the trick and BGP information can be polled from
the switch via the BGPv4 MIB.
@MichelMoriniaux <https://github.com/MichelMoriniaux> Since FRR is the
default routing stack on master branch, would you like continue the
integration?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#92 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADBS7WSV5EL5XP34HYKDUS3PUOFRHANCNFSM4GBR6L6Q>
.
|
|
Hi Michel, Can you please elaborate on the licensing issues here? Thanks |
|
The following is extracted from: sonic-frr/frr/debianpkg/README.Debian
* Why has SNMP support been disabled?
=====================================
FRR used to link against the NetSNMP libraries to provide SNMP
support. Those libraries sadly link against the OpenSSL libraries
to provide crypto support for SNMPv3 among others.
OpenSSL now is not compatible with the GNU GENERAL PUBLIC LICENSE (GPL)
licence that FRR is distributed under. For more explanation read:
http://www.gnome.org/~markmc/openssl-and-the-gpl.html
http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs
Updating the licence to explecitly allow linking against OpenSSL
would requite the affirmation of all people that ever contributed
a significant part to Zebra / Quagga or FRR and thus are the collective
"copyright holder". That's too much work. Using a shrinked down
version of NetSNMP without OpenSSL or convincing the NetSNMP people
to change to GnuTLS are maybe good solutions but not reachable
during the last days before the Sarge release :-(
*BUT*
It is allowed by the used licence mix that you fetch the sources and
build FRR yourself with SNMP with
<remove the "grep ^smux" block at the end of debian/frr.preinst>
# export WANT_SNMP=1
# apt-get -b source frr
Just distributing it in binary form, linked against OpenSSL, is forbidden.
best regards,
Michel
…On Mon, May 13, 2019 at 12:14 PM pavel-shirshov ***@***.***> wrote:
Hi Michel,
Can you please elaborate on the licensing issues here?
Is there a special license for frr - snmp integration?
Thanks
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#92>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADBS7WVYD33G532CTWKMJZLPVG4XXANCNFSM4GBR6L6Q>
.
|
|
Hi Michel, Thank you for the valuable information. Thanks |
|
I will start implementation on the rules/config option next week, that way
we will have choice
…On Mon, May 13, 2019 at 1:47 PM pavel-shirshov ***@***.***> wrote:
Hi Michel,
Thank you for the valuable information.
Thanks
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#92>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADBS7WT3ALPOXEVDE42K5TLPVHHXHANCNFSM4GBR6L6Q>
.
|
|
Thanks @MichelMoriniaux! Seems a workable solution we could follow. |
|
Agreed, I will still implement the current solution as we have only
recently moved to FRR 4.0 and Stretch. so it might take some time before we
go to 6.0 and Buster
…On Mon, May 13, 2019 at 11:28 PM Qi Luo ***@***.***> wrote:
Thanks @MichelMoriniaux <https://github.com/MichelMoriniaux>!
I notice that https://github.com/FRRouting/frr/releases/tag/frr-6.0.2
isolated frr-snmp from frr. This is also the case of debian packages:
https://packages.debian.org/buster/frr
https://packages.debian.org/buster/frr-snmp
Seems a workable solution we could follow.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#92>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADBS7WXJESD6IU4XGYCIU73PVJLYRANCNFSM4GBR6L6Q>
.
|
|
Just to clarify, the master branch of sonic-buildimage is building frr 6.0.2-0 into a stretch docker image. I do see frr-snmp_6.0.2-0_amd64.deb in Jenkins workspace, but I have never tested it. |
|
oooh nice! I must've missed the last train. OK I'll add investigating all
that to my sprint next week and come up with the most standard non
disruptive way of doing it
…On Tue, May 14, 2019 at 1:34 PM Qi Luo ***@***.***> wrote:
Just to clarify, the master branch of sonic-buildimage is building frr
6.0.2-0 into a stretch docker image. I do see frr-snmp_6.0.2-0_amd64.deb in
Jenkins workspace, but I have never tested it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#92>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADBS7WUM6ISTEXMTT3ORV43PVMO4BANCNFSM4GBR6L6Q>
.
|
|
Now we have frr-7.0 in sonic-master |
|
Shiny! do we have an idea of when we will be getting 6.0 or 7.0 in the
"stable" branches? I'm right now moving my org to 201904 but we are still
heavily invested in 201811
…On Thu, May 16, 2019 at 12:56 PM pavel-shirshov ***@***.***> wrote:
Now we have frr-7.0 in sonic-master
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#92>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADBS7WROXGYBM4YUZPS5HHDPVW377ANCNFSM4GBR6L6Q>
.
|
|
please see sonic-buildimage PR 2981 |
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 point of this commit is to open up the snmp container to other agentx implementations in other containers.
By default the snmp agentx implementation uses '/var/agentx/master' unix domain socket as per RFC.
If we want other containers to be able to connect to the snmp container we need to expose this unix socket outside the container. To do this the unix socket needs to be instantiated on the host then exposed via a mount or volume to the containers that wish to use it including the snmp container. This is a good option which allows securing the socket via Unix file system permissions but in reality these permissions end up being too wide and a LOT of files need to be touched in a lot of repos to get this to work. additionally this breaks backwards compatibility. We believe there is a better way.
In this implementation we chose to use the snmp provisions to override the default socket via a configuration directive in the /etc/snmp/snmpd.conf file:
agentxsocket tcp:localhost:705
we modify the ax_implementation so that this directive is read and the client connects to the defined tcp port, modifies unix socket or the default socket if the directive is not present. Thus we do not break behavior for existing configs and we allow the use of the facility in case it is configured.
The main real-world direct application of this is to allow the docker-fpm-frr container to feed bgp metrics to the snmp-container so that they can be polled.
Once the frr container is built with snmp support, the addition of a /etc/snmp/frr.conf with a single line containing "agenXSocket tcp:localhost:705" does the trick and BGP information can be polled from the switch via the BGPv4 MIB.
- What I did
- How I did it
- How to verify it
- Description for the changelog