Expose FRR /var/run/frr (frr sockets) to the host system

[mslocrian]

This is more of a query, than anything.

I would like to expose the frr socket path (/var/run/frr) to the host system. That is so it could be shared with other containers, where desired. I find it useful to be able to utilize the various frr .vty sockets to gather information about the routing daemons (eg: gather output from show ip bgp sum json for example), and expose that metrics to other tools like prometheus. (It's 2019 and saddens me that snmp is still so prevalent, so it'll be nice to also have a knob to disable it like in #2622 ... )

I am curious about other people's opinions about this, and if people are amenable, then where I might be able to implement that.

I've been able to take a first pass on my own by just modifying the /usr/bin/bgp.sh script on the host system and exposing the docker volumes. I would much prefer to get that into the build, but I haven't been able to find where the bgp.sh is created in the sonic-buildimage repo. I'll keep hunting for other repos, too. On top of that, we would also probably want to add the FRR users/group on the host system, to ensure we can sanely keep track of permissions on the directory on the host. I am also sure I'm missing some.

thanks for your input!
stegen

[gord1306]

Does it mean that other processes have a chance to close these socket? I am not familiar FRR, is there any interfaces like fpm can do similar operations?

[mslocrian]

Hi @gord1306 ,

It would mean that any process that lives on the host system would be able to read or write to the frr (and quagga as well. If we are doing one, we should do the other.) configuration. The closing of the sockets should only occur when the frr/quagga daemons stop (in their own container).

My goal with this is that I, and perhaps other users, would like to be able to share those sockets, via docker volume mounts, to other containers. By being able to communicate with the sockets directly you can gather all sorts of statistics by directly querying the socket, and pushing out/exposing telemetry / configuration state data (not via snmp).

eg:

sonic# show ip bgp json
{
 "vrfId": 0,
 "vrfName": "Default",
 "tableVersion": 1,
 "routerId": "10.1.0.1",
 "routes": { "10.1.0.1/32": [ { "valid": true, "bestpath": true, "pathFrom": "external", "prefix": "10.1.0.1", "prefixLen": 32, "med": 0, "weight": 32768, "peerId": "(unspec)", "aspath": "", "origin": "IGP", "nexthops": [ { "ip": "0.0.0.0", "afi": "ipv4", "used": true } ] } ] }  } sonic#
sonic#

sonic# show ip bgp sum json
{
"ipv4Unicast":{
  "routerId":"10.1.0.1",
  "as":65100,
  "vrfId":0,
  "vrfName":"Default",
  "tableVersion":1,
  "ribCount":1,
  "ribMemory":160,
  "peerCount":32,
  "peerMemory":672256,
  "peers":{
    "10.0.0.1":{
      "remoteAs":65200,
      "version":4,
      "msgRcvd":0,
      "msgSent":0,
      "tableVersion":0,
      "outq":0,
      "inq":0,
      "peerUptime":"never",
      "peerUptimeMsec":0,
      "prefixReceivedCount":0,
      "state":"Active",
      "idType":"ipv4"
    },
[...]
 },
  "totalPeers":32,
  "dynamicPeers":0,
  "bestPath":{
    "multiPathRelax":"true"
  }
}
}
sonic#

With access to those sockets, you can programmatically shove those commands right in there, and get easily consumable output.

We would need to change the frr/quagga startup scripts (at the least) to get the socket path into the host system.

Does that help clarify what I'm looking for?
stegen

[xinliu-seattle]

Will need to take some time to look into this. We can discuss in one of the community meetings.

[mslocrian]

Thanks @xinliu-seattle,

Can we Please keep the ticket posted as to when that community meeting will be so that I may participate? Otherwise will try to keep tabs on the mailing group threads.

Thanks!
stegen

[yxieca]

Done.