We've safely returned back to New Zealand from FAUCETcon and are excited to
be able to continue shipping new features and bug fixes.
Many thanks to the new developers who managed to get code into this
release, our work would be possible without your contributions.
Here's the release highlights for today:
- IPv6 L3 pipeline cleanup (no longer need ip_proto, icmpv6_type matches
in eth_src table).
- Handle IPv6 NA with different source/target IP.
- BGP routes not re-inserted when dataplane restarts.
- LACP tests flakey and could cause loopback - log LACP changes and
block when LACP down.
- Tests verify hard_timeout present on eth_src.
- Experimental simple loop mitigation.
- Upgrade to Ryu 4.18
I'm looking to gets hooks out of Faucet that tell a Northbound App (or that
a Northbound App can ask) when things like a port goes up/down or a new MAC
is learned. Or a new datapath is added.
I've noticed these get logged in the faucet log as `faucet.valve INFO` and
I'm wondering where I should be looking to hook directly into this. Is
this in gauge, or prometheus, or perhaps using fctl? I'm just looking for
some pointers of how I can programmatically retrieve these events.
I just added the first pieces of very simple LACP support (this is intended
to help make redundancy interoperability with non-SDN devices a little
I'll have some more detail around the implementation for next week. In the
meantime there are unit tests now in "master" to ensure that LACP between
Linux and FAUCET comes up.
It seems to work fine with hardware switches also, but since LACP is pretty
low level I can imagine it will expose some bugs and/or undesired
hybrid/local switching behavior that will have to be addressed.
Can we have "include" files in gauge.yaml? This will allow me to put all
the database related configuration in one file and include it.
Also, what is the difference between "include" and "include-optional" ?
I’m a member of the team at Cisco implementing GNMI functionality on IOS-XE devices (eg. Catalyst 9000 switches). As we prepare for plugfest next week I wanted to clarify some questions that have arisen as we look over the current GNMI content in FAUCET.
The config contained in “typical_ofsw_config.json” along with the contents of the overall message as they exist (ie. an empty “Path” message) pose a number of problems if we were to attempt to send that RPC verbatim to one of our live devices. Is this config and message intended only for example purposes or is the expectation that this RPC would be accepted by any GNMI-compliant device?
Core Software Group
Tel: +1 613 254 4816
Cisco Systems Canada Co. / Les Systèmes Cisco Canada cie
2000 Innovation Drive
[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]Think before you print.
This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
Cisco Systems Canada Co, 88 Queens Quay West, Suite 2900, Toronto,
ON, Canada, M5J 0B8. Phone: 416-306-7000; Fax: 416-306-7099.
Please click here<http://www.cisco.com/web/about/doing_business/legal/cri/index.html> for Company Registration Information.
One port only right now but that's good (I needed to set the "aggregatable"
flag, of course. Just testing that now and will merge. That will probably
cause also Brad's Dell switch's port channel to come up also.
faucet-lag-dev0#show interfaces port-channel 1
Port-channel1 is up, line protocol is up (connected)
Hardware is EtherChannel, address is 544a.0031.0681 (bia 544a.0031.0681)
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, link type is auto, media type is unknown
input flow-control is off, output flow-control is unsupported
Members in this channel: Gi0/1
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:01, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 1000 bits/sec, 1 packets/sec
68 packets input, 8704 bytes, 0 no buffer
Received 68 broadcasts (68 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 68 multicast, 0 pause input
0 input packets with dribble condition detected
faucet-lag-dev0#show lacp neighbor
Flags: S - Device is requesting Slow LACPDUs
F - Device is requesting Fast LACPDUs
A - Device is in Active mode P - Device is in Passive mode
Channel group 1 neighbors
LACP port Admin Oper Port
Port Flags Priority Dev ID Age key Key Number
Gi0/1 FP 255 0e00.0000.0001 0s 0x0 0xB 0xB 0x3E
Gi0/2 SP 0 0000.0000.0000 2069594s 0x0 0x0 0x0
We've just published v1.6.7 on docker & pypi. I'm happy to announce that
along with 1.6.7 we are now supporting our VM again and this will be kept
up to date with new releases of faucet.
Information on the new VM can be found here:
Release highlights for 1.6.7:
- Add unit tests for gauge
- Add a python console script for running FCTL
- Update gNMI tester with Set/Capabilities and Mock Target
- Actually delete dead FIB routes
- Add packaging scripts for new FAUCET VM
I suspect this will be our last release before FAUCETcon (assuming we don't
find any new major issues). On behalf of the FAUCET dev team, we hope to
see many of you next week at LBL!
I've been working on packaging faucet (and related tools) inside a new
VM image based on ubuntu-minimal.
The VM includes a preinstall/preconfigured
faucet+gauge+prometheus+grafana and is intended to demonstrate how these
components fit together for testing/development. The VM currently isn't
production ready due to some intentional security issues but I'm happy
to provide a second "secure" VM that would be production ready.
I've pushed my first iteration of the builder code (based on Openstack's
diskimage-builder) to github:
I'm looking for people to test this and give feedback, the pre-built
disk images are available on our build host:
If you want more architectures or different disk formats please do let
I'm pleased to report the faucet team have just shipped our latest stable
release v1.6.6. We also briefly had a v1.6.5 published however we quickly
identified some performance regressions introduced in this release and have
remedied those in 1.6.6.
To detect these regressions at an earlier phase of our development pipeline
in future we have now added cProfiling abilities to the test suite to
pickup performance problems.
We have a number of cool features introduced in this release, including:
- Experimental passive LACP support (for LACP interop testing only,
currently does not aggregate or provide redundancy, and works only on
- New fctl CLI tool for querying controller state from faucet
Release highlights from 1.6.5:
- Docker images built with Alpine Linux (drastically smaller - approx
170M versus 800M)
- Upgrade Ryu to 4.17
- Allow pushing of 0x88a8 VLAN tags
- Further strict eth_type checks before sending a packet to route
- Fix state change of mirror ports not handled
- Don't even try to flood to down ports (can get EPERM on packet out
- Test suites run against OVS 2.7.3.
- Test suites can use an http_proxy.
- Test suite diagnostic improvements (sanity checks describe switch
ports and minimum speed/status, and workaround ptys leak in mininet which
also caused tshark to crash), and are much quieter.
- Test suite doesn't allocate a TCP port to OVS switches anymore
(unnecessary), and allocate fewer test TCP ports overall.
- Reduce size of test container (remove unused mininet dependencies)
- Unit tests for Gauge
Release highlights from 1.6.6:
- Bug fixes & performance improvements
- Change default log level of faucet/gauge to INFO (use environment
variables FAUCET_LOG_LEVEL/GAUGE_LOG_LEVEL to override log level)
To fix a performance regression in 1.6.5 (not announced; 1.6.6 is being
released shortly), I added cProfile support.
If you're developing you can set CPROFILE to True in
faucet_mininet_test_topo.py. Ongoing there will be tests that keep an on on
packet handling performance so we can catch regressions at dev time.
This information is also quite useful for seeing where time goes inside Ryu.
root@faucet:~/faucet/tests# grep packet_in
10 0.000 0.000 0.047 0.005 faucet.py:347(*packet_in*
24 0.000 0.000 0.007 0.000 valve_packet.py:84(parse_
10 0.000 0.000 0.000 0.000 valve.py:644(_rate_limit_