SPAN port

[fsck]

I'd like to learn more about SPAN and get into the details of the packets flowing across the network.  What do you guys use as the packet analyzer?  Wireshark is the first one that comes to mind, along with Packetyzer, TCPdump.

[Reggle]

Currently Wireshark (or tcpdump to file to open it in Wireshark later). I read the Wireshark book and have plenty of experience in it so for application performance I can use it for troubleshooting.
Howver, I'm being send to an application & network performance training soon with a new tool. Let's see how that works out.

[routerdork]

I've always used Wireshark and consider it part of my standard install on any of my machines.

[fsck]

I'd be very curious to hear about that training course.  Alrighty so looks like I'm on the right track.  I just remember seeing other people use specific paid software to analyze the traffic.  I think it was something from SolarWinds.  I don't know squat about Wireshark.  I guess I have some reading to do and testing to do.  I've always wanted to learn Wireshark but it's a little intimidating.

[dlots]

For capture I often prefer TCPdump as I am often capturing on a Linux box that already has TCP dump installed by default.  For looking at the captures it's wireshark

[NetworkGroover]

Oh my god.... I had a big write-up of awesome real life examples where Wireshark saved my butt and I accidentally closed the window... ugh. Long stories short, Wireshark helped me identify the exact issue in a vendor's NDP implementation, and fix an issue where an application installer's error message was completely wrong.

Yeah - trust me, learn Wireshark.

I've also used it to learn protocols and write my blog, example: http://aspiringnetworker.blogspot.com/2013/10/ospf-link-state-advertisements-lsas-and.html

[fsck]

Oh my god.... I had a big write-up of awesome real life examples where Wireshark saved my butt and I accidentally closed the window... ugh. Long stories short, Wireshark helped me identify the exact issue in a vendor's NDP implementation, and fix an issue where an application installer's error message was completely wrong.

Yeah - trust me, learn Wireshark.

I've also used it to learn protocols and write my blog, example: http://aspiringnetworker.blogspot.com/2013/10/ospf-link-state-advertisements-lsas-and.html

I'm going to learn Wireshark for sure.  I really like your blog.  You've got lots of details and took the time to go through the entire process.  I like that.

[NetworkGroover]

Oh my god.... I had a big write-up of awesome real life examples where Wireshark saved my butt and I accidentally closed the window... ugh. Long stories short, Wireshark helped me identify the exact issue in a vendor's NDP implementation, and fix an issue where an application installer's error message was completely wrong.

Yeah - trust me, learn Wireshark.

I've also used it to learn protocols and write my blog, example: http://aspiringnetworker.blogspot.com/2013/10/ospf-link-state-advertisements-lsas-and.html

I'm going to learn Wireshark for sure.  I really like your blog.  You've got lots of details and took the time to go through the entire process.  I like that.

Thanks man... those were the days where I had plenty of free time at work.    Not like now, that's for sure.

[Fred]

Wireshark is a necessary tool of the trade, even without span ports. Having them throughout your network certainly makes life nice, though.

Also, while learning, don't ignore the sample captures page: https://wiki.wireshark.org/SampleCaptures

[Reggle]

Wireshark is a necessary tool of the trade, even without span ports. Having them throughout your network certainly makes life nice, though.

Also, while learning, don't ignore the sample captures page: https://wiki.wireshark.org/SampleCaptures

I've got my own sample captures folder with interesting captures gathered through the years. E.g. a SIP voice call, a BGP neighborship setup,... Useful to compare with as a baseline. Also useful if you doubt whether a certain QoS marking always is present, and so on.

[fsck]

I setup a SPAN port with wireshark.  Supposedly we are sending a ton of traffic to the address 192.42.117.40 from our network.

If I run ip.addr==192.42.117.40 in Wireshark on that SPAN port, and we really are sending to that address is that how I would see it?  Or am I wrong?

[deanwebb]

Sure, but if you want to check volume, I'd go with netflow.

[fsck]

Sure, but if you want to check volume, I'd go with netflow.

When you say check volume with Netflow, do you mean the amount of traffic?  I presume Netflow lays it out by usage?  Never used it before.  Is Netflow free?  I thought they had different versions, can't remember.

[wintermute000]

netflow is a reporting protocol. The collector (what receives the info and then reports/collates it into human readable format) is what you may have to pay for. There are free, open source versions like nfsen (works fine, horrible interface, but free so what the heck).

You need to figure out what you're trying to accomplish. If you need traffic reports/trends, netflow. if you're analysing a specific application or issue and want to zero in on the inner workings - span/wireshark. In your case I'd start with netflow, collect a day's worth of data then run a query to identify al the flows from the dodgy IP - see what the destinations are, what ports / protocol it is, and go from there. If you start with wireshark you'll see the payload and all the detailed application level stuff BUT you won't have any clue of the overall picture.

- if you're looking for traffic reporting (top talkers, what protocols, etc.) netflow is the right tool
- wireshark/tcpdump/span is literally capturing the actual packets - its useless for traffic pattern/volume analysis. But what it is good for is working out what is going on within a given flow that is reportedly not working or you suspect is misbehaving.

Other use cases for span include call recording (span off the voice vlan into specialised recording servers, e.g. NICE) or IDS/IPS (obvious reasons)

[fsck]

netflow is a reporting protocol. The collector (what receives the info and then reports/collates it into human readable format) is what you may have to pay for. There are free, open source versions like nfsen (works fine, horrible interface, but free so what the heck).

You need to figure out what you're trying to accomplish. If you need traffic reports/trends, netflow. if you're analysing a specific application or issue and want to zero in on the inner workings - span/wireshark. In your case I'd start with netflow, collect a day's worth of data then run a query to identify al the flows from the dodgy IP - see what the destinations are, what ports / protocol it is, and go from there. If you start with wireshark you'll see the payload and all the detailed application level stuff BUT you won't have any clue of the overall picture.

- if you're looking for traffic reporting (top talkers, what protocols, etc.) netflow is the right tool
- wireshark/tcpdump/span is literally capturing the actual packets - its useless for traffic pattern/volume analysis. But what it is good for is working out what is going on within a given flow that is reportedly not working or you suspect is misbehaving.

Other use cases for span include call recording (span off the voice vlan into specialised recording servers, e.g. NICE) or IDS/IPS (obvious reasons)

For this particular case it would be for analysis.  Thank you for the breakout that did help alot.