<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic RE: Analytics: Not all TCP flows shows Network or Applications Response time ? in ExtremeCloud IQ- Site Engine Management Center</title>
    <link>https://community.extremenetworks.com/t5/extremecloud-iq-site-engine/analytics-not-all-tcp-flows-shows-network-or-applications/m-p/49810#M7175</link>
    <description>Hi Mike,&lt;BR /&gt;
&lt;BR /&gt;
that sounds perfect for troubleshooting and debugging!&lt;BR /&gt;
&lt;BR /&gt;
Regards&lt;BR /&gt;</description>
    <pubDate>Tue, 28 Jun 2016 17:02:00 GMT</pubDate>
    <dc:creator>M_Nees</dc:creator>
    <dc:date>2016-06-28T17:02:00Z</dc:date>
    <item>
      <title>Analytics: Not all TCP flows shows Network or Applications Response time ?</title>
      <link>https://community.extremenetworks.com/t5/extremecloud-iq-site-engine/analytics-not-all-tcp-flows-shows-network-or-applications/m-p/49808#M7173</link>
      <description>PURVIEW / Analystics installation works fine till some TCP flows from some servers does not show Network or Applications Response time. Because the Netflow and Policy N-mirror sources are S4 core routers of 2 different locations we use a GRE Tunnel setup.&lt;BR /&gt;
&lt;BR /&gt;
So why are not all Response times are shown? Maybe the policy n-mirror is not complete ?&lt;BR /&gt;
Any other reasons ? &lt;BR /&gt;
&lt;BR /&gt;
If i have a LAG to some servers i set it on the LAG logical port too? (Necessary ?)&lt;BR /&gt;
i doublecheck the policy n mirror is set everywhere!&lt;BR /&gt;
&lt;BR /&gt;
But how can i troubleshoot / debug or confirm this (incoming policy mirror to a specific flow) ? Any suggestions ?&lt;BR /&gt;
&lt;BR /&gt;
Regards&lt;BR /&gt;</description>
      <pubDate>Mon, 27 Jun 2016 13:22:00 GMT</pubDate>
      <guid>https://community.extremenetworks.com/t5/extremecloud-iq-site-engine/analytics-not-all-tcp-flows-shows-network-or-applications/m-p/49808#M7173</guid>
      <dc:creator>M_Nees</dc:creator>
      <dc:date>2016-06-27T13:22:00Z</dc:date>
    </item>
    <item>
      <title>RE: Analytics: Not all TCP flows shows Network or Applications Response time ?</title>
      <link>https://community.extremenetworks.com/t5/extremecloud-iq-site-engine/analytics-not-all-tcp-flows-shows-network-or-applications/m-p/49809#M7174</link>
      <description>Hello Mattias,&lt;BR /&gt;
It is possible that the mirrorN did not get the correct information for the flow to determine it's round trip time. Taking a tcpdump at the purview appliance and filter for the source and destination on gre1 port is shortest path for starting to figure it out.&lt;BR /&gt;
It's important to note, that if you want to see round trip time, you want to have both netflow and mirrorN data traffic from the same port set. If it is a lag as a source port, then the lag should be specific in netflow as rx and in the policy section of the configuration as well.&lt;BR /&gt;
&lt;BR /&gt;</description>
      <pubDate>Tue, 28 Jun 2016 16:55:00 GMT</pubDate>
      <guid>https://community.extremenetworks.com/t5/extremecloud-iq-site-engine/analytics-not-all-tcp-flows-shows-network-or-applications/m-p/49809#M7174</guid>
      <dc:creator>Mike_Thomas</dc:creator>
      <dc:date>2016-06-28T16:55:00Z</dc:date>
    </item>
    <item>
      <title>RE: Analytics: Not all TCP flows shows Network or Applications Response time ?</title>
      <link>https://community.extremenetworks.com/t5/extremecloud-iq-site-engine/analytics-not-all-tcp-flows-shows-network-or-applications/m-p/49810#M7175</link>
      <description>Hi Mike,&lt;BR /&gt;
&lt;BR /&gt;
that sounds perfect for troubleshooting and debugging!&lt;BR /&gt;
&lt;BR /&gt;
Regards&lt;BR /&gt;</description>
      <pubDate>Tue, 28 Jun 2016 17:02:00 GMT</pubDate>
      <guid>https://community.extremenetworks.com/t5/extremecloud-iq-site-engine/analytics-not-all-tcp-flows-shows-network-or-applications/m-p/49810#M7175</guid>
      <dc:creator>M_Nees</dc:creator>
      <dc:date>2016-06-28T17:02:00Z</dc:date>
    </item>
    <item>
      <title>RE: Analytics: Not all TCP flows shows Network or Applications Response time ?</title>
      <link>https://community.extremenetworks.com/t5/extremecloud-iq-site-engine/analytics-not-all-tcp-flows-shows-network-or-applications/m-p/49811#M7176</link>
      <description>One think i guess is that the GRE tunnel (between S8 and PV-Engine) is maybe overloaded. &lt;BR /&gt;
&lt;BR /&gt;
I check port counters of the native port tg.4.20 (which connected S8 and PV Server) and the dummy port (for GRE Setup) ge.2.48 - no packets are discarded or error.&lt;BR /&gt;
&lt;BR /&gt;
Can it be the the dummy port ge.2.48 (which is the GRE source port) limit the GRE tunnel bandwith to 1GB ? Or any other limitation OR does the GRE tunnel transport fully 10GB traffic if needed ? &lt;BR /&gt;
&lt;BR /&gt;
Regards&lt;BR /&gt;</description>
      <pubDate>Tue, 28 Jun 2016 17:10:00 GMT</pubDate>
      <guid>https://community.extremenetworks.com/t5/extremecloud-iq-site-engine/analytics-not-all-tcp-flows-shows-network-or-applications/m-p/49811#M7176</guid>
      <dc:creator>M_Nees</dc:creator>
      <dc:date>2016-06-28T17:10:00Z</dc:date>
    </item>
    <item>
      <title>RE: Analytics: Not all TCP flows shows Network or Applications Response time ?</title>
      <link>https://community.extremenetworks.com/t5/extremecloud-iq-site-engine/analytics-not-all-tcp-flows-shows-network-or-applications/m-p/49812#M7177</link>
      <description>It's not likely discarding. It may be more likely that internally, if switch packet processing spikes above 60 percent that a flow did not get created or mirrored. It's also possible in some instances to see on the other side, a purview appliance with high CPU (as measured via TOP) or if it is a virtual machine, the overall VM hardware is sometimes overloaded CPU's, and then problems can occur that way as well. So it VM are used it is a good idea to make adequate resources available.&lt;BR /&gt;
&lt;BR /&gt;
However the most common explanation of your problem is the netflow data appears, but the corresponding mirrorN does not occur, at least bilaterally&lt;BR /&gt;
&lt;BR /&gt;</description>
      <pubDate>Tue, 28 Jun 2016 17:16:00 GMT</pubDate>
      <guid>https://community.extremenetworks.com/t5/extremecloud-iq-site-engine/analytics-not-all-tcp-flows-shows-network-or-applications/m-p/49812#M7177</guid>
      <dc:creator>Mike_Thomas</dc:creator>
      <dc:date>2016-06-28T17:16:00Z</dc:date>
    </item>
    <item>
      <title>RE: Analytics: Not all TCP flows shows Network or Applications Response time ?</title>
      <link>https://community.extremenetworks.com/t5/extremecloud-iq-site-engine/analytics-not-all-tcp-flows-shows-network-or-applications/m-p/49813#M7178</link>
      <description>Hi Mike,&lt;BR /&gt;
thanks for your explanation!&lt;BR /&gt;
&lt;BR /&gt;
But i want you asking again - is the configured speed of the GRE Source port (1GB) a bandwith limiter of the GRE Link? Or ask i an other way - does is the GRE Tunnel will be faster / thicker if i use a tg.x.y port as the source port?&lt;BR /&gt;
&lt;BR /&gt;
Thanks &lt;BR /&gt;</description>
      <pubDate>Tue, 28 Jun 2016 17:16:00 GMT</pubDate>
      <guid>https://community.extremenetworks.com/t5/extremecloud-iq-site-engine/analytics-not-all-tcp-flows-shows-network-or-applications/m-p/49813#M7178</guid>
      <dc:creator>M_Nees</dc:creator>
      <dc:date>2016-06-28T17:16:00Z</dc:date>
    </item>
    <item>
      <title>RE: Analytics: Not all TCP flows shows Network or Applications Response time ?</title>
      <link>https://community.extremenetworks.com/t5/extremecloud-iq-site-engine/analytics-not-all-tcp-flows-shows-network-or-applications/m-p/49814#M7179</link>
      <description>I have confirmed with development that the GRE Source port will affect output performance across the egress GRE tunnel. We have yet to see this as a limitation with most mirrorN setups, but it is possible. So a 10G port or a TBP on a PV-FC-180 may be recommended in these cases.</description>
      <pubDate>Tue, 28 Jun 2016 17:16:00 GMT</pubDate>
      <guid>https://community.extremenetworks.com/t5/extremecloud-iq-site-engine/analytics-not-all-tcp-flows-shows-network-or-applications/m-p/49814#M7179</guid>
      <dc:creator>Mike_Thomas</dc:creator>
      <dc:date>2016-06-28T17:16:00Z</dc:date>
    </item>
    <item>
      <title>RE: Analytics: Not all TCP flows shows Network or Applications Response time ?</title>
      <link>https://community.extremenetworks.com/t5/extremecloud-iq-site-engine/analytics-not-all-tcp-flows-shows-network-or-applications/m-p/49815#M7180</link>
      <description>Hi Mike,&lt;BR /&gt;
tbp port is my favorit - but we have a S8 (but S180 Series modules) and no PV-FC-180. &lt;BR /&gt;
Do you think it will work with a tbp on S8 or have i sacrify a real tg.x.y port ?&lt;BR /&gt;</description>
      <pubDate>Tue, 28 Jun 2016 17:16:00 GMT</pubDate>
      <guid>https://community.extremenetworks.com/t5/extremecloud-iq-site-engine/analytics-not-all-tcp-flows-shows-network-or-applications/m-p/49815#M7180</guid>
      <dc:creator>M_Nees</dc:creator>
      <dc:date>2016-06-28T17:16:00Z</dc:date>
    </item>
    <item>
      <title>RE: Analytics: Not all TCP flows shows Network or Applications Response time ?</title>
      <link>https://community.extremenetworks.com/t5/extremecloud-iq-site-engine/analytics-not-all-tcp-flows-shows-network-or-applications/m-p/49816#M7181</link>
      <description>There is no tbp possible on S8, only on the PV-FC-180, as it is internally using unused hardware. So you may need to sacrifice a 10G port if bandwidth is an issue.</description>
      <pubDate>Tue, 28 Jun 2016 17:16:00 GMT</pubDate>
      <guid>https://community.extremenetworks.com/t5/extremecloud-iq-site-engine/analytics-not-all-tcp-flows-shows-network-or-applications/m-p/49816#M7181</guid>
      <dc:creator>Mike_Thomas</dc:creator>
      <dc:date>2016-06-28T17:16:00Z</dc:date>
    </item>
  </channel>
</rss>

