Verify the GRE/UDP tunnel between vSCOUT and vSTREAM: Difference between revisions
No edit summary |
No edit summary |
||
| Line 24: | Line 24: | ||
</pre> | </pre> | ||
In the following example, our goal is to | In the following example, our goal is to see the tunnel traffic between the vSCOUT running on host '''10.165.30.146''' and the vSTREAM. We learned from the previous command execution that the tunnel is terminating on vSTREAM's interface '''eth1'''. | ||
To view the traffic, execute the command: | To view the traffic, execute the command: | ||
| Line 57: | Line 57: | ||
07:37:06.953132 IP 10.165.30.146 > 10.165.30.185: GREv0, length 1425: gre-proto-0x4e54 | 07:37:06.953132 IP 10.165.30.146 > 10.165.30.185: GREv0, length 1425: gre-proto-0x4e54 | ||
</pre> | </pre> | ||
By default we use GRE traffic. It is possible UDP is used instead. See the tunnel setup in NGeniusONE Server. | |||
Note that you will only see GRE or UDP traffic (depending on his the tunnen is configured in nGeniusONE Server > Device Configuration) when there is activity on the host running vSCOUT. | Note that you will only see GRE or UDP traffic (depending on his the tunnen is configured in nGeniusONE Server > Device Configuration) when there is activity on the host running vSCOUT. | ||
Revision as of 15:33, 1 March 2018
Introduction
vSCOUT does not produce session detail records nor does it store packets . However, you can still gain access to packet-level data by configuring traffic forwarding from vSCOUT to vSTREAM or InfiniStream managed by the same nGeniusONE server. Forwarded packets can be stripped out of the tunnel and made availabe for packet-level analysis on the receiving interface.
The next procedure allowverification of the tunnel i.e. if there are GRE or UDP packets being forwarded between vSCOUT and vSTREAM.
Solution
Testing
On vSTREAM, login to vSTREAM CLI (ssh) as root.
First we need to identify the interface terminating the GRE or UDP tunnel.
Execute the command:
# cat /opt/NetScout/rtm/bin/monitor_ip.conf
Should output:
[root@CRT-VIR-A-VSTREAM6 ~]# cat /opt/NetScout/rtm/bin/monitor_ip.conf eth1:10.165.30.185
In the following example, our goal is to see the tunnel traffic between the vSCOUT running on host 10.165.30.146 and the vSTREAM. We learned from the previous command execution that the tunnel is terminating on vSTREAM's interface eth1.
To view the traffic, execute the command:
# tcpdump -i eth1 -n host 10.165.30.146
Should output (omit all warnings):
[root@CRT-VIR-A-VSTREAM6 ~]# tcpdump -i eth1 -n host 10.165.30.146 tcpdump: /lib64/libcrypto.so.10: no version information available (required by tcpdump) tcpdump: WARNING: eth1: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes 07:37:05.878177 IP 10.165.30.146 > 10.165.30.185: GREv0, length 1435: gre-proto-0x4e54 07:37:05.878196 IP 10.165.30.146 > 10.165.30.185: GREv0, length 1435: gre-proto-0x4e54 07:37:05.878207 IP 10.165.30.146 > 10.165.30.185: GREv0, length 1435: gre-proto-0x4e54 07:37:05.878221 IP 10.165.30.146 > 10.165.30.185: GREv0, length 1435: gre-proto-0x4e54 07:37:05.878236 IP 10.165.30.146 > 10.165.30.185: GREv0, length 1435: gre-proto-0x4e54 07:37:06.010301 IP 10.165.30.146 > 10.165.30.185: GREv0, length 1423: gre-proto-0x4e54 07:37:06.010320 IP 10.165.30.146 > 10.165.30.185: GREv0, length 1423: gre-proto-0x4e54 07:37:06.010336 IP 10.165.30.146 > 10.165.30.185: GREv0, length 1423: gre-proto-0x4e54 07:37:06.010350 IP 10.165.30.146 > 10.165.30.185: GREv0, length 1423: gre-proto-0x4e54 07:37:06.010365 IP 10.165.30.146 > 10.165.30.185: GREv0, length 1423: gre-proto-0x4e54 07:37:06.376144 IP 10.165.30.146 > 10.165.30.185: GREv0, length 1401: gre-proto-0x4e54 07:37:06.376167 IP 10.165.30.146 > 10.165.30.185: GREv0, length 1401: gre-proto-0x4e54 07:37:06.376177 IP 10.165.30.146 > 10.165.30.185: GREv0, length 1401: gre-proto-0x4e54 07:37:06.376194 IP 10.165.30.146 > 10.165.30.185: GREv0, length 1401: gre-proto-0x4e54 07:37:06.376204 IP 10.165.30.146 > 10.165.30.185: GREv0, length 1401: gre-proto-0x4e54 07:37:06.951974 IP 10.165.30.146 > 10.165.30.185: GREv0, length 1425: gre-proto-0x4e54 07:37:06.953081 IP 10.165.30.146 > 10.165.30.185: GREv0, length 1425: gre-proto-0x4e54 07:37:06.953093 IP 10.165.30.146 > 10.165.30.185: GREv0, length 1425: gre-proto-0x4e54 07:37:06.953123 IP 10.165.30.146 > 10.165.30.185: GREv0, length 1425: gre-proto-0x4e54 07:37:06.953132 IP 10.165.30.146 > 10.165.30.185: GREv0, length 1425: gre-proto-0x4e54
By default we use GRE traffic. It is possible UDP is used instead. See the tunnel setup in NGeniusONE Server.
Note that you will only see GRE or UDP traffic (depending on his the tunnen is configured in nGeniusONE Server > Device Configuration) when there is activity on the host running vSCOUT.
There is only traffic from vSCOUT towards vSTREAM.
It is possibe to use FQDN instead of IP address.
Post testing
To restart vSCOUT on Linux host:
# service vscoutd stop # service vscoutd start
To restart vSCOUT on Windows host:
Use the vSCOUT tray application to stop and start the deamon or <install-dir>\rtm\bin\stop.bat <install-dir>\rtm\bin\start.bat
To restart the tunnel:
On nGenius Server > Device Configuration, untick and tick the box "Enable Traffic Forwarding"