Hi Chris, thanks. So vlan based filtering will not work with more than one vlan. I'm thinking about a workaround.
Something about the background: We're using Arista 7120 switches in one of our DC locations. These switches mainly build the 10G layer-2 infrastructure for our vSphere environment connecting the VMware servers as well as an iSCSI storage. The second purpose for the switches is acting as our core routers. The problem is, that we only need to account traffic that is been routed to the ISP uplinks. Unfortunately the sflow implementation for this switches is ingress only per each physical interface. Thus we need to activate sflow for each interface and filter out the required flows. So I need to filter for the vlans and our public networks. Two workarounds came to my mind. 1. We do not filter for the vlan, but use the vlan for aggregation instead. On a daily basis we remove the records for unneccessary vlans from the database. 2. I create an incoming and outgoing plugin/aggregate/filter for each vlan that aggregate and write to the database independently. Is there a recommendation for a maximum plugin instances? We need at least 6 vlans resulting in 12 instances. Cheers, Bernd > -----Ursprüngliche Nachricht----- > Von: [email protected] [mailto:pmacct-discussion- > [email protected]] Im Auftrag von Chris Wilson > Gesendet: Donnerstag, 9. Juni 2011 19:04 > An: [email protected] > Betreff: Re: [pmacct-discussion] Broken aggregate Filter > > Hi Bernd, > > On Thu, 9 Jun 2011, Bernd Bornkessel wrote: > > > The working filter is: > > > > vlan and (dst net 192.76.141.0/24 or dst net 194.55.246.0/23 or dst > > net > > 195.246.160/19 or dst net 88.215.224.0/19 or dst net 62.93.212.0/23 or > > dst net 62.93.246.0/23 or dst net 88.215.192.0/19) > > > > The non-working are: > > > > vlan and ((vlan 365 or vlan 1337) and (dst net 192.76.141.0/24 or dst > > net 194.55.246.0/23 or dst net 195.246.160/19 or dst net > > 88.215.224.0/19 or dst net 62.93.212.0/23 or dst net 62.93.246.0/23 or > > dst net > > 88.215.192.0/19)) > > > > ((vlan 365 or vlan 1337) and (dst net 192.76.141.0/24 or dst net > > 194.55.246.0/23 or dst net 195.246.160/19 or dst net 88.215.224.0/19 > > or dst net 62.93.212.0/23 or dst net 62.93.246.0/23 or dst net > > 88.215.192.0/19)) > > I think you may be falling victim to this (from man pcap-filter(7)): > > vlan [vlan_id] > > True if the packet is an IEEE 802.1Q VLAN packet. If > [vlan_id] is specified, only true if the packet has the specified vlan_id. > Note that the first vlan keyword encountered in expression changes the > decoding offsets for the remainder of expression on the assumption that the > packet is a VLAN packet. The vlan [vlan_id] expression may be used more > than once, to filter on VLAN hierarchies. Each use of that expression > increments the filter offsets by 4. > > Therefore I don't think you can use the "vlan" keyword more than once in the > same expression (unless you have vlan hierarchies). This appears to be a > limitation (and a rather "unusual" one) of libpcap, not pmacct. > > If they really want to support nested vlans (and I would seriously question > the sanity of anyone who used them) I would respectfully suggest that they > modify the "vlan" keyword to not change the filter offset, and create a new > keyword like "nested-vlan" which does. > > Cheers, Chris. > > _______________________________________________ > pmacct-discussion mailing list > http://www.pmacct.net/#mailinglists _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
