Verify the GRE/UDP tunnel between vSCOUT and vSTREAM: Difference between revisions

From wiki.comcert.com
Jump to navigation Jump to search
VisualWikitext
No edit summary
No edit summary
 
(15 intermediate revisions by the same user not shown)
Line 2: Line 2:
== Introduction ==
== Introduction ==


vSCOUT does not produce session detail records nor does it store packets . However, you can still gain access to session details and packet-level data by configuring traffic forwarding from vSCOUT to vSTREAM or InfiniStream interface 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.  
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.  


This procedure allows you to verify the existance of the tunnel i.e. packets being transported between vSCOUT and vSTREAM.
The next procedure allowverification of the tunnel i.e. if there are GRE or UDP packets being forwarded between vSCOUT and vSTREAM.


 
 
Line 10: Line 10:
== Solution ==
== Solution ==


This procedure assumes vSCOUT/vSTREAM has been installed and configured correctly by COMCERT engineers and has worked correcly.
=== Testing ===


On vSTREAM:
On vSTREAM, [[Default_credentials|login to vSTREAM CLI (ssh) as root]].


Login to vSTREAM CLI (ssh) as root
First we need to identify the interface terminating the GRE or UDP tunnel.
 
First we need to identify the interface terminating the GRE or UDP tunnel 


Execute the command:
Execute the command:
Line 26: Line 24:
</pre>
</pre>


In this example, we want to test the tunnel between the vSCOUT running on host <IP-VSCOUT> and the vSTREAM whlle the tunnel is terminating on interface <INT>.
In the following example, our goal is to see the tunnel traffic between the vSCOUT running on host '''10.165.30.146'''&nbsp;and the vSTREAM. We learned from the previous command execution that&nbsp;the tunnel is terminating on vSTREAM's interface '''eth1'''.


There is only traffic from vSCOUT towards vSTREAM.&nbsp; To visulalize this traffic, execute the command:
To view the&nbsp;traffic, execute the command:
<pre># tcpdump -i <INT> src host <IP-VSCOUT></pre>
<pre># tcpdump -i eth1 -n host 10.165.30.146
</pre>


Example:
Should output (omit all warnings):
<pre># tcpdump -i eth1 host 52.29.161.66
<pre>[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
</pre>
</pre>


Should output:
By default GRE packets are used.&nbsp;However unlikely, it is possible to use UDP instead.&nbsp;See the tunnel&nbsp;setup in nGeniusONE Server for more information.
 
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.&nbsp;


# tcpdump -i eth1 host 52.29.161.66<br/> tcpdump: /lib64/libcrypto.so.10: no version information available (required by tcpdump)<br/> tcpdump: WARNING: eth1: no IPv4 address assigned<br/> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode<br/> listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes<br/> 07:19:06.259943 IP CRT-VIR-W-TLG.comcert.crt > ec2-52-29-161-66.eu-central-1.compute.amazonaws.com: ICMP echo request, id 35, seq 12167, length 40<br/> 07:19:06.260114 IP CRT-VIR-W-TLG.comcert.crt > ec2-52-29-161-66.eu-central-1.compute.amazonaws.com: ICMP echo request, id 35, seq 12168, length 40<br/> 07:19:06.286638 IP ec2-52-29-161-66.eu-central-1.compute.amazonaws.com > CRT-VIR-W-TLG.comcert.crt: ICMP echo reply, id 35, seq 12167, length 40<br/> 07:19:06.286642 IP ec2-52-29-161-66.eu-central-1.compute.amazonaws.com > CRT-VIR-W-TLG.comcert.crt: ICMP echo reply, id 35, seq 12168, length 40<br/> 07:19:11.248473 IP CRT-VIR-W-TLG.comcert.crt > ec2-52-29-161-66.eu-central-1.compute.amazonaws.com: ICMP echo request, id 35, seq 12198, length 40<br/> 07:19:11.248592 IP CRT-VIR-W-TLG.comcert.crt > ec2-52-29-161-66.eu-central-1.compute.amazonaws.com: ICMP echo request, id 35, seq 12199, length 40<br/> 07:19:11.274693 IP ec2-52-29-161-66.eu-central-1.compute.amazonaws.com > CRT-VIR-W-TLG.comcert.crt: ICMP echo reply, id 35, seq 12198, length 40<br/> 07:19:11.274698 IP ec2-52-29-161-66.eu-central-1.compute.amazonaws.com > CRT-VIR-W-TLG.comcert.crt: ICMP echo reply, id 35, seq 12199, length 40<br/> &nbsp;
It is possibe to use&nbsp;FQDN instead of IP address.


&nbsp;
&nbsp;


&nbsp;
=== Post testing ===
 
To restart vSCOUT on Linux host:
<pre># service vscoutd stop
# service vscoutd start</pre>
 
To restart vSCOUT on Windows host:
<pre>Use the vSCOUT tray application to stop and start the deamon
or
<install-dir>\rtm\bin\stop.bat
<install-dir>\rtm\bin\start.bat
</pre>
 
To restart the tunnel:
<pre>On nGenius Server > Device Configuration, untick and tick the box "Enable Traffic Forwarding"</pre>


Note that you will only see GRE or UDP traffic when there is activity on the host running vSCOUT.
<br/> &nbsp;


&nbsp;
&nbsp;

Latest revision as of 15:35, 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 GRE packets are used. However unlikely, it is possible to use UDP instead. See the tunnel setup in nGeniusONE Server for more information.

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"


 

 

 

 

 

 

Retrieved from "https://wiki.comcert.com/index.php?title=Verify_the_GRE/UDP_tunnel_between_vSCOUT_and_vSTREAM&oldid=2732"