search

faucetsdn / faucet

FAUCET is an OpenFlow controller for multi table OpenFlow 1.3 switches, that implements layer 2 switching, VLANs, ACLs, and layer 3 IPv4 and IPv6 routing.
http://faucet.nz
Apache License 2.0
554 stars 190 forks source link

FAUCET config/ACL management via RPC #1841

Closed anarkiwi closed 5 years ago

anarkiwi commented 6 years ago

faucet-config-acl-mgt

As discussed here in Wellington and via some different email threads.

We'd like a way to update FAUCET's config via an RPC, and also have a special case to change the ACL(s) assigned to a port on a DP via RPC.

To keep the system manageably small and simple, we propose a new component/process, separate but colocated (same host) as FAUCET.

It probably should be able to get/set Gauge config as well. We should have a way to make sure an AAA config error doesn't allow it to configure an access ACL on a trunk port (for example).

RPC transport/auth isn't defined here - specifically soliciting thoughts here.

Bairdo commented 6 years ago

Pasted from one of the email threads:

KitL commented 6 years ago

Hmm.. I guess we will need to be able to define ACLs on the fly then.

The issue we were trying to avoid was to do with trying to reduce having to add faucet configuration to things other than faucet. How do you configure the rules that Gasket will install at the moment?

On 12 April 2018 at 14:27, Michael Baird notifications@github.com wrote:

Pasted from one of the email threads:

-

Gasket (1X) deals with (port) ACLs which are intended to be associated to a user via a MAC address (dl_src), which we're only going to find out about at runtime. So this looks like a problem if the rule already needs to exist.

We've been thinking about adding VLAN support to Gasket (adding/removing tagged/native VLANs to access ports), the Baffle project is interested in Gasket being able to do that.

Another thing Baffle in particular is wanting is associating an user with an IP address, probably via integrating with a DHCP server (ISC). So again this match field would only be known at runtime.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/faucetsdn/faucet/issues/1841#issuecomment-380654697, or mute the thread https://github.com/notifications/unsubscribe-auth/AB48FS0qSs_0jf3AO10arFJEeBgZgm7cks5tnruAgaJpZM4TQ_r2 .

Bairdo commented 6 years ago

Gasket gets username, MAC address & a list of ACL names to apply from hostapd (via radius).

Gasket has a file 'rules.yaml' which contains the actual contents of the rule. (The rules from radius are under top level 'acls')

These rules can have the ACL values populated before writing to the faucet-acls.yaml.

grafnu commented 6 years ago

You might consider changing the direction of the RCP mechanism to reach OUT to the controlling O-client. Right now, OF reaches OUT to FAUCET for its programming. Similarly, FAUCET might then reach OUT to the O-client for its dynamic programming information. This would seem to fall more in line with the overall philosophy of SDN (top down orchestration). Otherwise, FAUCET ends up being a weak point in terms of system management/configuration (e..g, I need to now worry about authentication to the inbound RPC connection).

One idea would be to use websockets. Then if you really wanted you could have a snazzy web-based O-client. There's also other standard protocols like RabbitMQ or MQTT that fit well (all message-based remote-server systems).

grafnu commented 6 years ago

Also seems like this should be the same channel as the event socket. You have events and results going one way, and then commands, such as config changes, going the other way. Really would think there should be only one...

anarkiwi commented 5 years ago

Proposal v1.1:

We provide a new process, config manager (see original diagram). Config manager allows external applications to get/replace FAUCET and Gauge's config, and health check FAUCET and Gauge, via gNMI RPCs.

Typical usage:

  1. Config manager process starts up, connects to FAUCET and Gauge Prometheus clients to get initial state of both and to determine path to YAML configs.

  2. Config manager starts listening for RPCs.

  3. Upon a health check RPC, config manager returns OK or not OK, by integrating signals like whether FAUCET/Gauge Prometheus client responds, that FAUCET/Gauge don't assert config file errors, etc.

  4. Upon a get config RPC, config manager returns YAML config for FAUCET or Gauge as required.

  5. Upon a replace config RPC, config manager calls FAUCET/Gauge config checker to make sure config is valid. If it is not valid return an error. If valid, write out the new YAML and signal FAUCET/Gauge. If FAUCET/Gauge signal an error restore old config and return an error.

Notes:

The critical functionality to deliver is RPC based config updates.

@grafnu - I don't understand your point about RPC direction? Are you proposing some kind of config streaming connection? Certificates/auth information is still required no matter the direction so I don't understand an advantage there. FAUCET and Gauge are just reading YAML files from a local filesystem.

grafnu commented 5 years ago

The RPC direction has to do with connection to/from the Config Manager. The current chain of this architecture is:

Alternatively it could be something like:

TL;DR: question would be "Why aren't you following the same SDN connection model as OpenFlow itself?"

Use case would be to have the TCCM hosted elsewhere -- not the same when you look at firewall traversal and NAT, etc... What would it mean to e.g. host the TCCM somewhere in the cloud?

NB: Seems like event streaming really should be the same API -- maybe just v2 -- but I would at least make sure there's a plan for it. It seems unfortunately to maintain two APIs long-term.

On Thu, Nov 22, 2018 at 5:05 PM Josh Bailey notifications@github.com wrote:

Proposal v1.1:

We provide a new process, config manager (see original diagram). Config manager allows external applications to get/replace FAUCET and Gauge's config, and health check FAUCET and Gauge, via gNMI RPCs.

Typical usage:

1.

Config manager process starts up, connects to FAUCET and Gauge Prometheus clients to get initial state of both and to determine path to YAML configs. 2.

Config manager starts listening for RPCs. 3.

Upon a health check RPC, config manager returns OK or not OK, by integrating signals like whether FAUCET/Gauge Prometheus client responds, that FAUCET/Gauge don't assert config file errors, etc. 4.

Upon a get config RPC, config manager returns YAML config for FAUCET or Gauge as required. 5.

Upon a replace config RPC, config manager calls FAUCET/Gauge config checker to make sure config is valid. If it is not valid return an error. If valid, write out the new YAML and signal FAUCET/Gauge. If FAUCET/Gauge signal an error restore old config and return an error.

Notes:

The critical functionality to deliver is RPC based config updates.

-

No event streaming in the API at this time (possibly later version).

We could add a special case call for updating port ACLs but the calling application will still need to know the right ACL/contents anyway.

Config is just FAUCET's YAML config. The config manager doesn't natively understand FAUCET's config language (it might in future). FAUCET already knows how to apply config diffs. Config manager could potentially manage other FAUCET-friends' config files in the same way.

@grafnu https://github.com/grafnu - I don't understand your point about RPC direction? Are you proposing some kind of config streaming connection? Certificates/auth information is still required no matter the direction so I don't understand an advantage there. FAUCET and Gauge are just reading YAML files from a local filesystem.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/faucetsdn/faucet/issues/1841#issuecomment-441139598, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBHj1wVmbMoLmZvkMxnt_4s2NQaJdVtks5ux0nNgaJpZM4TQ_r2 .

byllyfish commented 5 years ago

I like the idea of using gNMI to manage a Faucet "switch".

Event streaming can be implemented at a later time by a Subscribe that reads JSON values from the current event socket.

gNMI is built on gRPC which is layered on top of http/2. It would be nice to have the config manager dial out via http/2 transport, but then reverse the roles of server/client so the accepting end of the http/2 connection is the gRPC client. AFAICT, this is not currently supported by gRPC API's.

dojolabs-ci commented 5 years ago

any update on this one? its implemented? any pointer to documentation?

anarkiwi commented 5 years ago

https://github.com/faucetsdn/faucetagent

Most basic version implemented.

https://github.com/openconfig/reference/blob/master/rpc/gnmi/gnmi-specification.md#5-appendix-current-outstanding-issuesfuture-features

documents "dial out" as a future extension.