This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Is it possible to run a network tap on a Port Channel?

0

Hi all,

Whilst this is not strictly Wireshark related, I wondered if anyone would know whether it would be possible to run a network tap on a single logical Port Channel comprise of multiple physical Ethernet links?

Many thanks

Chris

asked 20 Jan '14, 11:05

swinster's gravatar image

swinster
26226
accept rate: 0%


One Answer:

3

Yes. Taps are transparent to the two systems, even for port channel groups. Tap all physical links on the port channel, and you'll need to aggregate them somewhere to get it into a single stream (either at a tap aggregator, a switch that is SPANing all the receive ports, or even a server that's running simultaneous packet captures on all the receiving NICs). The link aggregation logic between the two systems is not disrupted as long as the taps continue to carry line voltage and pass all the frames across (including any dynamic aggregate link control traffic, like that of LACP or PAgP).

answered 20 Jan '14, 18:21

Quadratic's gravatar image

Quadratic
1.9k6928
accept rate: 13%

Many thanks for this confirmation. Now the next bit is the difficult part!

The Port Channel is run over two x 10 Gbit (copper) links. To get a tap capable of running at 10 Gbit, then to get a device capable of capturing the traffic flow (which will probably require 4 x 10 Gbit ports), is going to cost $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$!!!!!!!

(22 Jan '14, 06:18) swinster

well, there is a simple and cheap alternative: Don't look at the traffic and ignore the problem ;-))

(22 Jan '14, 06:26) Kurt Knochner ♦

Touché :)

We deal with many large public institutions (education/government) WRT their videoconferencing, although we are not directly responsible for their underlying networks. Of course, we have to consult with the network teams highlighting what they may need to do to make their networks work for real time video and attempt to help them diagnose any issues that arise. A lot of money is spent on the infrastructure but surprising little is spent on any diagnoses equipment that might be needed to help fault find.

We are actually a not for profit organisation and in the past we have done well with some simple 10/100Mibit taps and a multi-NIC device. Of course, times have moved on and whilst it would be great if we could invest in equipment capable of tapping an capturing multiple 10 Mbit links, we simply don't work that way have to rely on the institutions.

Unfortunately, Kurt, your are closer to the truth that I care to mention. Video is classed as "unimportant" but is generally the first thing to suffer and highlight an issue. Of course we do emphasis that fix issue that are sensitive for video will in-turn benefit the entire network, but often it falls on deaf ears!

(23 Jan '14, 11:14) swinster

well, network testing/troubleshooting equipment is usually not in the focus of the people who spend the money, as that equipment sometimes costs more than the core infrastructure components (depends obviously on the vendor and other parameters), and it does not solve an immediate problem. It's more like an insurance. Actually you buy something in the hope that you'll never need it. I believe that's one important reason why people don't spend money on troubleshooting equipment and resources (know-how, etc.). Only after they hit a hard problem, they will think about that issue, which I can understand (somehow) ;-))

There is no general solution for this 'problem'. Usually you'll have to be patient and let people hit the wall. Then they will come back to you and ask for help ;-))

For your video troubleshooting: Wouldn't it be possible to analyze the problem closer to the client? You won't have (several aggregated) 10Gig links there and therefore you can still use your good old troubleshooting equipment (Laptop with TAP or SPAN port on the switch).

(24 Jan '14, 07:49) Kurt Knochner ♦

Hey Kurt. Indeed we have followed those steps and identified that the problem is somewhere close to the edge of the network. We utilise a Cisco VCS firewall traversal system which combines a VCS Expressway and VCS Control. The Expressway is located in the suppliers address space and is effectively connected directly to the CPE (via our switch - but on the suppliers side), the CPE then routes into the organisation edge router and from there into the core. We then have a port in our VLAN on the core switch that connects to our VCS Control (via another or our switches).

We can see the stats on the VCS devices for various legs of a call - as a call is placed and it traverses these VCS devices, it effectively gets terminated and retransmitted. This means we can see what is going on in various network segments. We can see there are dropped packets from the VCS-E and inbound to the VCS-C from the stats, but to prove the point we can run a SPAN on our switches so monitor the uplink to the CPE on the suppliers side and the uplink to the core on the organisation side. We can see the RTP stream sequence leaving the VCS-E and we can see RTP packets in the sequence missing on the arrival at the VCS-C (thanks to Wireshark)

Physically there are only a few devices involved in the sequence but calls placed internally within the organisation, both within the same VLAN and inter VLAN via the core switch are working successfully. This would suggest that the internal network to the core is OK.

In addition, we have other organisation whose VCS-Cs peer to this particular VCS-E without issue, so I can effectively rule out the VCS-E and the CPE.

I would like to capture traffic hitting the edge from the CPE and again before the core to see if the problem lies on these edge routers - this is what my gut is telling me!

(24 Jan '14, 08:38) swinster