Stages in Faucet switch dev-cycle
A template for implementing Faucet compatible OF switch.
Nitin Karkhanis- nkarkhan@arista.com

1

Engineer’s perspective-2

Arista has been supporting OpenFlow single-table for a while
Initial contact with faucet - 2016 - real work was in 2019
Team comprised of folks with platform and upper layer expertise
OpenFlow switches are dumb - how hard can this be?

Engineer’s perspective - Denial- Faucet matched the pipeline of many commercially available ASICs.
- Initial plan was to match faucet table to appropriate ASIC table.
Implementation reality- Test - faucetTaggedTest - tables used - vlan, ethSrc, ethDst, ﬂood
- Install tables in parallel TCAM lookup with table priority
vlan - if tagged then goto ethSrc. (ignore goto)
ethSrc - drops a few Src Macs, table miss punts to controller and goto
ﬂood. (ignore goto)
ethDst - ﬂows installed when MACs are learnt
ﬂood - sends to all ports except incoming.
Packets match multiple ﬂows in diﬀerent tables (even unintended tables)
and if there are no conﬂicting actions then the test passes.

3

Engineer’s perspective - Anger-Faucet tables matched ASIC tables in “name”. Functionality expected wasvery diﬀerent.
e.g. TFM for vlan says matching can be on DstMac, EthType and/orInPort. ASIC can probably do vlan assignment based on SrcMac andInPort.
ethSrc table could match on SrcMac, DstMac, EthType and/or InPort.
Realization that faucet tables can’t all be mapped to ASIC tables.
Getting a few tests to pass did not mean we had a workable approach.
Passing tests at this pointFaucetTaggedTest
FaucetTaggedScaleTest
FaucetTaggedBroadcastTest

4

Engineer’s perspective - Bargaining--

5

Maybe Faucet is not that detached from ASIC reality, maybe there is nouse case for matching any packet ﬁeld in any table.
Maybe some hacks are okay
Maybe this 1 hack to glean router MAC address from ﬂows andprogramming router MAC table is ﬁne.
Build a ARP table in SW by combining info from ethDst and FIB.
Send packets to SW for handling hard to implement ﬂows.
Implementation reality
IP packets destined to this router MAC could be processed thru ASIC’s
routing pipeline and apply operations like decrement TTL change src
MAC, dst MAC, Vlan on the packet.
Faucet test has routed packet in 1 direction and reply packet is bridged
but has routing operations.

Engineer’s perspective - Depression--

6

Dev stage names don’t match reality.
Faucet pipeline doesn’t match ASICs pipeline.
Gleaning information from ﬂows to ﬁgure out if it was a routed or bridged
domain ﬂow was not scalable and would increase complexity.
If you have custom enhancements/features faucet will never ﬂy. Nobody
will write vendor speciﬁc code in controller.
If ( vendorName == “Initech” ) {IpAddrMatchInEthSrcTable = true;} // will never ﬂy!
Switch API has to be kept generic, don’t pollute controller code withvendor speciﬁcs

Engineer’s perspective - Acceptance-Do the right thing.
Switch table ﬂexibility is critical for Faucet’s success.
Vendor/Chip speciﬁc code on the controller side doesn’t help.

Implementation reality - Switch code gets complicated to ﬁgure out which ASIC tables to use

7

Engineer’s perspective -8

Current state
90 % of faucet tests pass
Switching/Routing/8021.x tests pass.
Using the right generic approach got us stacking tests.

Thank You
www.arista.com
9