How to monitor 2 direction of 1 TCP connection?

[Hieu Nguyen]

Dear sFlow members,

I'm using OVN for ml2 plugin in OpenStack Neutron, with this topo:

internet vlan --- |br-ex| --- |br-int| --- |br-cus| --- customer vlan

I config sFlow in br-cus with this command:

ovs-vsctl -- --id=@s3 create sflow agent=vlan2201 target="\"collector:6343\"" header=128 sampling=100 polling=10  -- set bridge br-cus sflow=@s3

Only throughput from customer vlan to the internet is exported, there's no metric about internet-to-customer throughput. If I add sFlow in br-ex, I do see the internet-to-customer one, but the destination IP is pre-NAT IP (public IP). How to monitor the missing throughput metric directly? 

Best regards,

Hieunt

[Neil McKee]

When an sFlow agent is sampling on ingress, to see both directions you have to enable sFlow on all ports of that  switch. This tends to simplify the analysis because you know that everything going through that switch in any direction is counted once by that agent.  But I think in this setup OVS does not consider |br-cus| as being a whole switch,  right?  The link between |br-cus| and |br-int| is considered "internal" and so packet sampling does not happen there. Have I understood correctly?  So even if you ask for sFlow to be enabled everywhere possible, the NAT step happens deep inside OVS and so the client and server directions of a TCP flow are hard to match up.

Some implementations allow bidirectional sampling to be configured,  so if you only care about one port then enabling bidirectional sampling there can make sense,  but when you are monitoring a whole network and enabling sFlow on all ports then ingress-only is more common.  (I don't remember if OVS allows bidirectional sampling or not?  Worth checking.)

But however you configure sampling,  NAT can be tricky.  There are (optional) sFlow structures that allow an agent to tell you about the NAT translations.  See "extended_nat" and "extended_nat_port" here:

https://sflow.org/developers/structures.php.  If you don't run sFlow at the point where NAT is happening, or that step does not include structures 0:1007 and 0:1020 in the feed,  then there is often no clear way to match up the internal and external TCP/UDP traffic. (I don't remember if OVS exports those structures? Worth checking. sflowtool will print them if they are there.)

If you have control over what runs on the end hosts/VMs,  and they are Linux,  then running hsflowd (https://sflow.net) there is a workaround option. The hsflowd tcp{} module can also annotate the samples with delay/loss/jitter metrics lifted from the kernel.

------
Neil McKee
InMon Corp.

--
You received this message because you are subscribed to the Google Groups "sFlow" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sflow+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/sflow/1dd45f90-b8d9-4c7c-bc00-beccb4eb7c1fn%40googlegroups.com.