That's true, but in an IX environment the number of MACs is relatively
limited and slowly changes.
In an IX environment it is a standard expected feature to know how much
traffic is exchanged between peers.
On Thu, Feb 16, 2017 at 7:56 AM, Truong Huu Trung <trungdtbk(a)gmail.com>
You will need NxN rules.
I just wonder why do they care about the amount of traffic A sends to B.
On Thu, 16 Feb 2017, 07:21 Josh Bailey <joshb(a)google.com> wrote:
> For 2, we can add a count only (ie. allow) rule.
> On Thu, Feb 16, 2017 at 4:31 AM, Truong Huu Trung <trungdtbk(a)gmail.com>
> I assume they have three requirements as follow:
> 1. No broadcast. VLAN ACLs can accomplish this task. We only need to
> generate the ACLs based on some inputs.
> 2. Monitoring. It seems that they want to monitor exactly how much
> traffic is being exchanged between any pair of participants.
> Faucet can't provide that now. As src and dst are separated into two
> tables, we can see how much one receives or sends but not from whom
> 3. Fast failover: I'm in favor of the use of group table. As I think it
> should be quicker to react than with the controller involvement. We could
> extend our stack to support two ports between switches, and make use of
> group table for redundancy or load balance (configurable).
> On Wed, Feb 15, 2017 at 10:58 AM Josh Bailey <joshb(a)google.com> wrote:
> Hi all;
> My friend and colleague Marc designed and built the OpenFlow based IX,
> TouSIX, in Toulouse, France. You can read a bit more about TouSIX here (
> shows the topology as well). Marc is negotiating deployment at an IX in
> Japan (where he now lives). There is an opportunity to use FAUCET instead.
> TouSIX uses a forwarding algorithm called Umbrella. The point of
> Umbrella, is turn broadcast into unicast and not require a controller to
> respond (in other words, relatively static flows are pushed, that cause
> traffic such as ARP requests to be directly forwarded to the port where the
> target is known to be). This way you can't have a broadcast storm because
> there are no broadcasts.
> Marc has sent us a couple of dumps of the flows, on each of the 3
> switches in the exchange. Both flows and groups are used. Taking at look at
> the flows, I believe all of them can be accomplished as FAUCET ACLs.
> Considering the groups - Marc uses the fast failover feature of groups
> for redundancy. We could implement the same, or alternatively, we could
> have a colocated controller with each switch that runs FAUCET, and FAUCET
> can do active link checking/listen to port status messages and decide to
> switch redundant paths.
> I am disposed towards the latter approach, because while it does require
> a controller, that controller can be rebooted etc without disruption to the
> network, and we can have some more local intelligence to diagnose soft
> failures (eg low level packet loss).
> Would very much appreciate your thoughts!
> Faucet-dev mailing list