p – display the process ID associated with each connection. a – display information about all connections (both listening and non-listening).In this example, we’ve used several options: Tcp 4452 1237 localhost.localdo:46940 nbg1-speed.hetzne:https ESTABLISHED 46022/wget Tcp 4452 1448 localhost.localdo:46940 nbg1-speed.hetzne:https ESTABLISHED 46022/wget Tcp 3345 7242 localhost.localdo:46940 nbg1-speed.hetzne:https ESTABLISHED 46022/wget Tcp 3345 1448 localhost.localdo:46940 nbg1-speed.hetzne:https ESTABLISHED 46022/wget Then, we can check the connection of our process: $ netstat -taucp | grep 46022 Let’s install the package first: $ yum install -y net-tools Netstat is part of the net-tools package. We can also use netstat to display network connections of a specific process. Netstat is a tool that displays network-related information, such as network connections and routing tables. The output displays a list of system calls made by the process, such as restart_syscall, ioctl, getpgrp, write, and clock_nanosleep. Moreover, we used -e to determine the type of system calls. In this case, we used the -p option to specify the PID of the process to trace. Now, we can start our tracing: $ strace -p 46022 -e trace=networkĬlock_nanosleep(CLOCK_REALTIME, 0,, NULL) = 0 We can use strace to capture network-related system calls made by a single process.įirst, let’s install strace via yum: $ yum install -y strace I’ll post more solutions as I encounter them.Strace is a command-line tool that we can use to trace system calls and signals of a process. Try changing the source interface to source vlan and use the VLAN you want to capture. This might be related to Problem 1, but haven’t confirmed. In some cases I found that capturing an interface would not work reliably, but capturing the VLAN would. Here is an example where I filter down traffic to 8.8.8.8. This statement indicates that the RSPAN traffic wouldn’t be cloned (thus creating an infinite loop of traffic), but I couldn’t get it to work without the filter. Each ERSPAN source session can have either ports or VLANs as sources, but not both.” Source Cisco The documentation indicates that it should work:ĮRSPAN source sessions do not copy ERSPAN GRE-encapsulated traffic from source ports. The fix was to apply an ACL filter and then traffic started showing up. I found that the ERSPAN would not work reliably if it was being transported over the same interface the capture was running on. If all looks correct there, what can we do? If you don’t see packets in Wireshark then run show monitor session 1 to see the details of the RSPAN. You should now see Wireshark receiving the capture! By default the session is setup in a shutdown state. On the Cisco device enter the monitor session 1 type erspan-source config mode and run no shutdown. To do this enter ip proto 0x2f (GRE is protocol 47 which is 2F in HEX) and then start the capture. On the workstation start Wireshark, but don’t start the capture just yet! First create a capture filter and let’s only capture GRE packets so that we’re only seeing the ERSPAN traffic in Wireshark. Origin ip address is the interface on the Cisco device where the tunnel will be sourced. Ip address is the IP of the workstation where Wireshark is running. Source can either be an interface or VLAN from which you want to pull the capture.Įrspan-id is the ID of the GRE tunnel and can be anything between 1-64. Type erspan-source signifies that this will be an encapsulated SPAN session. The session number is simply the monitor session and can be any available session. On the device where you want to run the capture enter global config mode and enter the following: Here’s how it’s done: How to Setup the ERSPAN Tunnel interfaces by default use GRE and simply require a source and destination address to start encapsulation.Īny destination IP address can be used with ERSPAN, so what happens if the destination address is where Wireshark is running on a computer? Wireshark sees the live capture! The packets are encapsulated in GRE, but Wireshark displays the information of the encapsulated traffic, so it’s not a problem. It’s often paired up with IPSEC and used in VPN scenarios. GRE (generic routing encapsulation) is a common way to tunnel traffic across networks. This week I learned a trick that allows much more flexibility!ĮRSPAN is like RSPAN in that you can send mirrored traffic to other devices, but that “E” (which stands for encapsulated) makes a world of difference! ERSPAN encapsulates SPAN into GRE. Typically when I need to do a packet capture on a remote Cisco IOS/IOS-XE device, I use RSPAN to mirror that traffic someplace where a VM can receive the capture.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |