<div dir="ltr"><div dir="ltr">Hi Ian,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 22 Jun 2023 at 17:26, Ian Chilton <<a href="mailto:ian@lonap.net">ian@lonap.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="font-size:10pt;font-family:Verdana,Geneva,sans-serif">On 2023-06-22 14:32, André Grüneberg wrote:
<blockquote type="cite" style="padding:0px 0.4em;border-left:2px solid rgb(16,16,255);margin:0px">
<div id="m_5587707080920195525replybody1">
<div dir="ltr">
<div>Are you by any chance using vlan translation or L2 sub-interfaces (with non default VLAN IDs) on your Arista gear?</div>
</div>
</div>
</blockquote>
<div id="m_5587707080920195525replybody1">
<div dir="ltr">
<div> </div>
<div>We have just started using L2 sub-interfaces in the last few months and it seems this has been a problem for longer for this.</div>
<div> </div>
<div>We're aware that traffic on sub-interfaces won't be counted, but that only accounts for a fraction of the discrepancy we are seeing.</div>
<div> </div>
<div>In addition, the member who was reporting inconsistency with their ports and their peers are not using sub-interfaces so that's not a factor there.</div></div></div></div></blockquote><div><br></div><div>This does not matter. All traffic coming from others to this one member is NOT being measured on the member's port but on others' ports.</div><div>Presuming that you have sFlow enabled only on edge ports and your're generating sFlow for inbound traffic flow (the usual setting for Arista).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="font-size:10pt;font-family:Verdana,Geneva,sans-serif"><div id="m_5587707080920195525replybody1"><div dir="ltr">
<div>  <br></div>
</div>
</div>
<blockquote type="cite" style="padding:0px 0.4em;border-left:2px solid rgb(16,16,255);margin:0px">
<div id="m_5587707080920195525replybody1">
<div dir="ltr">
<div>In these cases the sFlow packets contain the VLAN ID on the wire and will not be matched into the right buckets.</div>
<div>We "enhanced" the sflow collector script with some hack to map the VLAN ID. [I may go into details]</div>
</div>
</div>
</blockquote>
<div id="m_5587707080920195525replybody1">
<div dir="ltr">
<div> </div>
<div>As I say, a different problem, but one that's on my list to fix so would be interested in what you did here.</div>
<div> </div>
<div>Presumably it's just a case of extracting VLAN -> VLAN mappings of subinterfaces and substituting that in sflow data as it's processed?</div></div></div></div></blockquote><div><br></div><div>Yes, it's intoducing a mapping of the tuple (agent, interfaceid, vlanid) -> peering VLAN ID ... so the rest of the script can digest the flow as "peering traffic". :)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="font-size:10pt;font-family:Verdana,Geneva,sans-serif"> <br><blockquote type="cite" style="padding:0px 0.4em;border-left:2px solid rgb(16,16,255);margin:0px">
<div id="m_5587707080920195525replybody1">
<div dir="ltr">
<div>We believe that our results (<a href="https://www.bcix.de/ixp/statistics/vlan" rel="noopener noreferrer" target="_blank">https://www.bcix.de/ixp/statistics/vlan</a>) are very close to reality.</div>
</div>
</div>
</blockquote>
<p>Interesting! - so right now you're doing 507Gbps according to MRTG and showing 349G (v4) + 72G (v6) = 421G with sflow.</p></div></blockquote><div></div><div>Well, there are some "heavy" PVLANs that can easily account for ~50G at that time. And the remainder is within our acceptable error margin of 10%.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="font-size:10pt;font-family:Verdana,Geneva,sans-serif">
<p>Are you using Arista too? - what sample rate?</p></div></blockquote><div></div><div>Yes, mostly we are running smapling rate 16384 -- same as yours.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="font-size:10pt;font-family:Verdana,Geneva,sans-serif">
<p></p>
<p>I have just found another smoking gun - when running sflow-to-rrd-handler with debug mode, I see a lot of dropped/rejected flows. Some (most?) of these seem to be sub-interfaces, but it turns out that some MACs are not in the discovered macs table, so I need to investigate that further, but now we are using MAC ACLs, we'd probably be better switching to configured macs.</p></div></blockquote><div><br></div><div>Indeed, using learned MACs was one of our major issues in the beginning. This always required getting Port-Channel names correctly (had some severe issues with that on Dell, back in the times). When we moved to Arista, we immediately switched to configured MACs also working towards config automation (generation of MAC ACLs).</div><div><br></div><div>While using learned MAC table we always had to "amend" the DB table with some manual additions.</div><div><br></div><div>The migration towards configured MACs is rather simple ... so go for it!</div><div><br></div><div>André<br clear="all"></div></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">André Grüneberg, Managing Director<br><a href="mailto:andre.grueneberg@bcix.de" target="_blank">andre.grueneberg@bcix.de</a></div><div dir="ltr">+49 30 2332195 42<br><p>BCIX Management GmbH<br>Albrechtstr. 110<br>12103 Berlin<br>Germany</p><p>Geschäftsführer/Managing Directors: Jens Lietzmann, André Grüneberg<br>Handelsregister: Amtsgericht Charlottenburg, HRB 143581 B</p><font size="1"><span style="font-family:Calibri,"sans-serif"" lang="EN-US"></span></font></div></div></div></div></div></div></div></div></div></div></div>