Same MAC on multiple infrastructures is partly "ignored" in sflow stats

[rasssta]

Briefly discussed this with nick previously.

SUMMARY

If customer A has MAC address 1.1.1 and is connected to 2 infrastructrues in the same IXP Manager installation, sflow statistics will only work for 1 of these infrastructures.

It happens in different cases. One is where the customer is using a Cisco 6500/7600 with SFP line cards where all ports have the same MAC address, and the customer is connected to a local infrastructure and remotely connected to another infrastructure (different ports, but same MAC).

[nickhilliard]

are you using the same 802.1q VLAN id for your different infrastructures?

[rasssta]

Yes!

[nickhilliard]

ok, don't do that then.

The reason why is that IXP Manager uses the source and destination 802.1q VLAN ID, and the srcmac / dstmac fields in the sflow packets to work out which infrastructure the frame was received on. If you use a unique 802.1q vlan id on your different infrastructures, this set of data points will uniquely identify which infrastructure and peering LAN the frame was received on.

Unfortunately, we can't easily use any of the other data fields in the sflow header. Here's an sflowtool output sample:

FLOW,193.242.111.152,2,21,0013136f2fc0,0010a52f261f,0x0800,10,10,94.1.115.114,80.1.2.222,6,0x00,124,1863,750,0x18,179,165,1024

The obvious candidate for this is the sflow Agent ID, but unfortunately this value could be anything depending on implementation. E.g. we've seen stuff like fe80::/64 IP addresses and ipv6 privacy addresses in that field. In other words, information in this field can change without notice to new values which can't be determined in advance. So there's no way of taking an agent ID and deterministically working out what switch / infrastructure it belongs too, unless you can guarantee that the agent ID is static. There are options to pin this down on some sflow implementations, but implementing this in code is messy.

After that, the interface IDs could be possible candidates, but only if you knew which switch they were coming from, i.e. what switch the agent ID was referring to. So these aren't useful either.

So your only option at the moment is to use different VLAN IDs on your different infrastructures. This would also solve issue #509.

[rasssta]

Ok, thanks!

[rasssta]

Btw, might be a good idea to add an info text, when adding infrastructures, about the advantage of unique VLAN IDs :-)