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

Port Mirroring and ICMP type 5 Redirects

0

I want to use Port Mirroring switch to capture and analyze on a Win10 PC VoIP traffic going to my VoIP phone on the same LAN segment. I hooked the phone to port 1 of Netgear GS105E mirroring switch, configured the switch to mirror port 1 to port 2, hooked the PC with Wireshark to port 2. The switch port 5 WAN is connected to the router.

When I start capturing VoIP traffic on the mirror port, the connection is quickly saturated by ICMP Redirect type 5 packets, and blocks VoIP phone access to the web. Ongoing traffic between VoIP Phone and PC raises to 5-10MB/s in each direction, despite no calls in progress. The PC CPU is at 100% load. As soon as I stop capture, traffic drops to 0, and everything back to normal, even with calls in progress.

500729  31.612461   67.216.88.32  192.168.10.112    SIP 365 Request: OPTIONS sip:[email protected]:8240;transport=udp |

500730 31.612474 192.168.10.114 192.168.10.112 ICMP 509 Redirect (Redirect for network)

My questions: Is it a typical situation, when a mirrored traffic generates DDoS flow of ICMP Redirect packets from OS TCP Stack? If Yes, why its not mentioned anywhere in the Manuals of Mirrored Switch or Wireshark setup? How can I resolve the issue? I tried blocking ICMP Redirects by Firewall, but they are still generated and saturate the link. Why ICMP packets flow stops as soon as capture stops, despite the switch keeps mirroring VoIP packets to PC?

Can I use the same PC NIC to capture VoIP phone traffic and browse the web at the same time? Or its better to capture SIP traffic on one NIC, and browse the web via another NIC installed on the same PC? In this case, how to assign NICs priority correctly?

I noticed, Wireshark uses WinPCap 4.1.3 based on NDIS 5.x driver model, despite Win10PCap exists based on NDIS 6.x driver model, and compatible with Wireshark. What version would you recommend for Win10 64-bit PC, and why? Could it affect ICMP Redirects?

asked 05 Nov ‘16, 17:06

zamar24's gravatar image

zamar24
6348
accept rate: 0%

edited 09 Nov ‘16, 09:56


3 Answers:

1

Can I use the same PC NIC to capture VoIP phone traffic and browse the web at the same time? Or its better to capture SIP traffic on one NIC, and browse the web via another NIC installed on the same PC?

The way port monitoring works on most switches, it is not possible to use the PC's NIC connected to a monitoring port to connect the PC to the network, at least because the ingress direction of a monitoring port is disabled. Therefore, the port cannot forward even the NIC's ARP responses to their destinations.

If your PC can browse the web while connected to a monitoring port of a switch and there is no other wired or wireless NIC active, either the implementation of monitoring on that switch is really unusual or the configuration is wrong. I don't have GS105Ev2 yet, but this question suggests that the manual may not be really clear, so please double-check your settings.

In this case, how to assign NICs priority correctly?

There's nothing as sophisticated as priority here. At the NIC you want to use for monitoring, you either disable IP (both v4 and v6) and, eventually, also other L3 protocols on that NIC. If DHCP client mode is normally configured on the NIC, you don't need to do anything at all. The key is to make the NIC not applicable for the network stack, and the NIC cannot ever get a DHCP offer through a monitoring port of a switch (unless the monitoring behaves really unusually as described above).

I tried blocking ICMP Redirects by Firewall, but they are still generated and saturate the link.

If you have in mind the Windows firewall, the icmp packets are generated between the firewall and the NIC, so the firewall cannot block them.

What version would you recommend for Win10 64-bit PC, and why?

WinPcap 4.1.3 is supported by the Wireshark project, Win10Pcap is not. On top of the two, there is also NPcap from the NMap project, which is an experimental development supported by Wireshark project. For your purpose, none of them has any clear advantage over the remaining two. The capturing filter is not related to generation of ICMP redirects.

Is it a typical situation, when a mirrored traffic generates DDoS flow of ICMP Redirect packets from OS TCP Stack?

Slightly off-topic, the first D in DDoS is "distributed", which is clearly not the case here. To the matter, of course it is not a typical behaviour - normally a network stack sends ICMP Redirect packets only if it is configured as a gateway but cannot deliver the received packet to the destination. So to trigger an ICMP redirect packet, an incoming packet should have a destination MAC address of your PC and destination IP address of some other host.

answered 06 Nov '16, 01:15

sindy's gravatar image

sindy
6.0k4851
accept rate: 24%

Thanks Sindy for exhaustive answers. Very clear and useful. I'm doing some extra testing now with various configuration scenarios, will report the results later. Would you be so kind to answer the above question:

Why ICMP packets flow stops as soon as Wireshark capture stops, despite the switch keeps mirroring VoIP packets to the PC?

Can these ICMP packets be generated by a NIC card, not Windows TCP stack? I ask, because I have 2 different NIC cards installed on my PC, and currently the 2nd model of commercial 2-port grade seems to give better results than the basic Motherboard NIC.

(06 Nov '16, 18:21) zamar24

I'm running Win10 64-bit Pro, not server, as mentioned above. How do I check, whether routing is enabled in its TCP stack? And why would it be enabled by default?

Still it doesn't explain, why ICMP packets stop when Wireshark capture stops? What can be the link between Wireshark capture and ICMP packets generation?

(07 Nov '16, 00:20) zamar24

Why ICMP packets flow stops as soon as Wireshark capture stops, despite the switch keeps mirroring VoIP packets to the PC?

I'm afraid I was too optimistic regarding how the software part of the network stack behaves.

Normally, the hardware filter in the NIC only lets in frames with destination MAC address matching one of the NIC's own ones (the unicast one and possibly a collection of multicast ones). When you start capturing, this filter is deactivated, so all frames are let in. This is called "promiscuous mode" and is necessary to allow capturing of 3rd party traffic such as your VoIP phone's one. You can disable promiscuous mode in the NIC settings in Wireshark before starting to capture to check whether it is the reason.

It seems that the IP stack doesn't check the destination MAC address, assuming that only valid frames can reach it, so it only looks at the destination IP address and as it is not its own and the NIC through which it would route to that destination IP would be the same one through which the packet came in, it generates the ICMP redirect.

But the decision criteria may be different, so even if the packet would be forwarded using another NIC, the ICMP redirect may still be sent. Can you confirm that if you use the NIC deactivation methods suggested (disable protocols or activate DHCP client mode) on the NIC you use for monitoring, the ICMP redirect issue disappears?

Can these ICMP packets be generated by a NIC card, not Windows TCP stack? I ask, because I have 2 different NIC cards installed on my PC, and currently the 2nd model of commercial 2-port grade seems to give better results than the basic Motherboard NIC.

The ICMP packets should be generated by the TCP stack, not the NIC driver. My assumption is that different behaviour of the distinct NIC drivers in promiscuous mode or different L3 configuration of the distinct NICs explains the difference in sending of ICMP redirect.

(07 Nov '16, 01:03) sindy

Hi sindy,

I'm still testing another NIC, the delay is caused by my VoIP phone couldn't register any longer with the provider due to frequent changes on the LAN segment. :)

Your input is very useful for many folks, since it uncovers more depth about port mirroring and packet interaction with various hardware and OS components. In fact, Netgear Switch docs are completely silent about anything except usage basics.

You mentioned L3 NIC configuration. What settings do you mean? Each NIC has usual Advanced Settings choice in Properties. Which typical NIC settings may positively affect the VoIP capture task?

As well, GS105E switch has the ability to create port based VLANs, but not LAGs (see Prosafe+ Config Utility Manual http://downloadcenter.netgear.com/en/product/GS105E#searchResults ). Does it mean its L3 configurable (https://documentation.meraki.com/MS/Layer_3_Switching/Layer_3_versus_Layer_2_Switch_for_VLANs)? Can creating a separate VLAN on the mirroring port 2 help in eliminating ICMP Redirects, and why?

(07 Nov '16, 09:58) zamar24

You mentioned L3 NIC configuration. What settings do you mean? Each NIC has usual Advanced Settings choice in Properties.

L3 means Layer 3 which can be simplified to "any protocol which uses the Ethernet as transport". The ICMP redirect is solely an issue of the IP, while L3 stacks other than IP may exhibit similar issues following their own house rules.

So what I had in mind was that the (IP address; subnet mask; gateway) settings of the interfaces together with the routing settings. My experience is that the gateway item should be defined only for one NIC per system because it is copied to the routing table as the default route each time the NIC goes up, which means that the last NIC to be connected to the network wins.

I guess there is no point looking for anything in the Advanced Settings of the network card as I don't believe anyone would make the check of the destination MAC address a configurable item. Checking it is normally useless as the hardware filter on the NIC prevents such frames from getting in, and as it costs some CPU cycles, I guess most drivers don't do it at all.

I'm not even 100% sure whether there actually is some NIC type dependent code which could do the MAC address check between the place where WinPcap's packet "filter" is inserted and the bottom of the IP stack.

Which typical NIC settings may positively affect the VoIP capture task?

There's nothing special about VoIP versus other types of traffic in this regard. You'd get the same issue with any other IP traffic, like e.g. a browser access to your phone's web interface.

(07 Nov '16, 10:35) sindy

As well, GS105E switch has the ability to create port based VLANs, but not LAGs, does it mean its L3 configurable?

VLANs are considered part of L2, and so are LAGs (although most LAG implementations can use L3 addresses to spread the load among the LAG member links, but that's far away from the original topic).

Can creating a separate VLAN on the mirroring port 2 help in eliminating ICMP Redirects, and why?

That's also more complex than it seems.

First, many Windows NIC drivers strip away any VLAN headers before letting the frame in (rather than ignoring the frame completely), and only some of them allow to change this in the Advanced Settings.

Second, advanced implementations of port mirroring usually permit to mirror to a port

  • the complete traffic of a (direction of a) source port, regardless to how many VLANs the source port belongs, which means that any VLAN tags are kept as they are, or

  • the a complete traffic of a VLAN, regardless how many member ports it has, which may cause bandwidth issues (this type of traffic mirroring is not possible with the GS105Ev2),

but I have never seen an implementation which would add VLAN tags to the monitored traffic at the egress of the monitoring port as there are no use cases for such behaviour (other than the one you've just suggested). For reasons explained here and because the switches do not take VLAN IDs into account when building the associations between MAC addresses and ports, you cannot transport the monitored traffic from the monitoring port to the capturing interface using L2 infrastructure even if you would add a VLAN ID to it.

(07 Nov '16, 10:55) sindy

What I mean, the VLAN tags can be added by the router to VoIP traffic, and then switch ports assigned to accept certain VLAN traffic only. However, you say it will hardly allow to avoid generation of ICMP Redirects by TCP stack.

This raises an obvious question. Switches like GS105E are consumer+ grade, and widely used to analyze and capture mirrored network traffic like VoIP using Wireshark or similar tool on a Windows PC. If passing such mirrored traffic in promiscuous mode would inevitably result in ICMP Redirects generated by TCP stack that flood the network segment, such capture would not be generally possible, and therefore use of the mirror switch. But reports like mine aren't widespread on the web. This means, standard ways exist to bypass this stack assumed behavior and successfully capture mirrored traffic. What are these ways?

(07 Nov '16, 12:07) zamar24

I thought we were on the same page, but seems there are still gaps between the parts of my explanation, so I'll try to summarize it in different words.

Affection of the "physical" traffic in the monitored network

If the ICMP redirect packets sent by the capturing NIC connected to a traffic mirroring port of a switch would make it to the network, there would have to be something wrong with how the mirroring works on that switch. Do you suppose or know that the switch forwards the ICMP redirection packets sent by the capturing NIC further to the network?

Affection of the contents of the capture file

have you tried, on the NIC used for capturing, to

  • disable IP protocol completely, or

  • configure the IP protocol for DHCP client mode, or

  • statically configure an IP from another subnet than the one you are monitoring

and capture again? The ICMP redirect should only be sent if the destination IP address of the triggering received packet is from the same IP subnet like the IP address of the receiving (in our case, capturing) NIC; in worst case, if it is from the same IP subnet like the IP address of any of the active NICs on the receiving PC. So to avoid the problem, it should be enough to avoid capturing a subnet which is at the same time active at the capturing NIC or, in worst case, at any of the capturing PC's NICs.

Besides, as the mirroring port normally comes up in full duplex mode, the ICMP redirect packets do not reduce the amount of the monitored traffic as long as the network stack can deal with it, so you can easily filter them out from the capture using a display filter, and maybe even a capture filter could be composed.

(07 Nov '16, 13:18) sindy

There are couple of issues here. Netgear 2nd level support advised to attempt capture mirrored traffic and browse the web through the same NIC, despite I initially channeled the traffic through 2 different NICs (prior to your config suggestions, so both were DHCP). We might misunderstood the issue jointly with Netgear. The other thing, my VoIP phone couldn't register with provider anymore due to extensive testing. I'll try your suggestions now, sure they should work. The mirror capture NIC is configured to get IP from the router via DHCP, though I'm not sure how it can help in contrast with no IP?

I monitor traffic with NetBalancer on my PC, so I do know that switching Wireshark On raises traffic between VoIP Phone and PC to 10MB/s in each direction, and completely saturates the 100Mbps VoIP link making calls impossible, and web browsing on the PC very slow, possibly due to special traffic handling by the mirror port.

Your replies are invaluable, a much deeper understanding that Netgear CS has, but of course their devs don't deal with users. I doubt however, most of mirror port users know what you suggested because its not posted anywhere, yet they capture traffic somehow. I was stripped of 10 karma points for asking Qs. :)

(07 Nov '16, 14:33) zamar24

The mirror capture NIC is configured to get IP from the router via DHCP, though I'm not sure how it can help in contrast with no IP?

For capturing mirrored traffic, DHCP client mode normally has no operational advantage over disabling IP completely. But if you use DHCP client mode on that interface when using it for normal network connections, the advantage is that you don't have to do anything at all when connecting it to a mirroring port instead. But that is true only if the mirroring port works the usual way; if it lets through regular traffic on top of mirroring another port's traffic, the DHCP negotiation can take place and so the DHCP client mode doesn't prevent all those bad things from happening. So only disabling IP completely on the capturing NIC can sort this out.

Netgear support advised to attempt capture mirrored traffic and browse the web through the same NIC, despite I initially channeled the traffic through 2 different NICs (prior to your config suggestions, so both were DHCP).

If Netgear support says that the mirroring port can be used to connect the PC to the network, it means that their idea of how the traffic mirroring port should behave really differs from the common one. Weird. Maybe they wanted to emulate the behaviour of a plain hub? I was going to buy one once I've noticed its existence from the questions here, but this information makes me think one more time whether it is a good idea. @Bob Jones, as you have got many of them, can you confirm that the port configured as mirroring destination can still be used for normal traffic?

I don't understand what you mean by channelling traffic through 2 NICs, was it a port channel (LAG) or did you have in mind something else? Did the two NICs share the same IP subnet?

(07 Nov '16, 14:54) sindy

I just got the switch. Having 2 NICs in my PC, one was hooked to the switch port3 to browse the web, and another to port2 getting mirroring traffic from the phone's port1. Both NICs were configured DHCP on the same subnet with the router and switch. Using Wireshark resulted in ICMP flood, I contacted support, and their response was scarce at best, mostly asking about network layout etc, suggested joint traffic (possibly simply through one switch as I've 2). Then I posted here, and got background explanation and 2 suggestions: 1) modify L3 NIC setup, separate traffic; 2) change Windows IP Router Reg settings. I'm checking them both now.

I'm typing this reply, while connected to the web through the active Netgear mirroring port. If I switch On Wireshark now, it will make it impossible to Save this comment due to flood. :) If I disable switch mirroring feature, turning On Wireshark won't notably affect traffic through same ports. It might be Netgear larger switches follow different logic, but small low cost switches are set this way, as home users often having no extra ports to hook more equipment, and spare ports are hot commodity.

(07 Nov '16, 16:41) zamar24

I've just ordered it, as after all a gigabit hub is worse than a normal gigabit mirroring switch but still better than nothing.

In the past, most Wireshark users were using plain hubs, whose all ports behave the same like the mirroring one of this box, in exactly the same arrangement where a single NIC was used for both network communication and capturing in promiscuous mode, and nobody seems to have complained about ICMP redirect floods back then.

So something may have changed about the behaviour of the IP stack of Windows 10 as compared to the behaviour of the Windows versions released at times when hubs used to be commonplace.

Delivery time promised is 24 hours, so we'll see tomorrow.

(08 Nov '16, 03:01) sindy

can you confirm that the port configured as mirroring destination can still be used for normal traffic?

I am travelling now for a couple of weeks so cannot check until next month. I believe it does act this way. I understand that Cisco does not allow ingress by default (it's an option) but many other mirror port -capable systems do.

I use these all the time and usually couple them with a USB ethernet adapter and advise to disable all protocols so there is no contamination of the network by this additional NIC. I think most here believe this would be best practice, but is certainly not required. Windows, when DHCP fails, takes a link-local address and will still send frames which get picked up by the trace. Easy enough to ignore them, but for beginners, just easier not to have them.

I suspect the capture device as root cause is likely off track. I would focus on Windows behavior. Did you post a short trace of the issue so we can identify the sources of the ICMP traffic, or whatever the flood is causing the problem?

(08 Nov '16, 04:40) Bob Jones

Posting VoIP trace is problematic due to privacy issues. But I added some trace info to the original question above. What's interesting, Redirect packets contain more info than the original mirrored packets, unless packets are processes by Windows TCP stack with delay, or the info is gradually collected by Windows from received packets and stored somewhere.

(08 Nov '16, 07:24) zamar24

Hm, after all there is a Wireshark (2.2.1 to date) issue with RTP packet loss evaluation.

I've connected port 1 to a free NIC on my PC (with IPv4 enabled with static address), and inserted the GS105E into the Ethernet connection of a VoIP terminal, port 4 looking towards the terminal and port 5 looking towards the original switch, and started mirroring port 5 to port 1.

Then I've started capturing and went for lunch.

After almost 1/2 hour, I've stopped the capture and used Telephony -> RTP -> RTP streams to see the loss ratios. Two out of four streams were showing 8.3 % packet loss and some sane number of lost packets, and the other two were showing 1,800,000 % (yes, one and something million percent) packet loss and something like 2^32 lost packets. The indicated loss ratio depended on direction.

So I've applied a display filter to choose just one of the "8.3%" streams and used Telephony -> RTP -> Stream Analysis, and there was 0% loss in the analysis; then I've chosen a stream in the opposite direction, and there was 0% loss as well.

And after choosing Telephony -> RTP -> RTP streams, there was 0% loss shown for all streams.

So you should try the same with your "lossy" captures to find out whether it is a capturing issue or a dissection issue. The 25 Mbit/s absolute maximum of download speed of your uplink is 40 times less than the 1 Gbit/s bandwidth of the Ethernet, so there is no reason for the mirrored packets to not fit into the wire - except if they wouldn't be buffered at all as outlined earlier.

I just have no idea how to file this as a bug as when I save the capture, close Wirehark, and open the file again, the first Telephony -> RTP -> RTP streams shows correct results (leaving aside that the capture file has 13 MB zipped).

(10 Nov '16, 06:25) sindy

Likely, the switch would pass all VoIP traffic available, but the internet upload speed seems to be a limiting factor in sending VoIP packets out, so some are dropped when PC plays YouTube HR video, since heavy downloads are often accompanied by upload "received confirmation" or "request next" packets, or opposite traffic in P2P applications.

(20 Nov '16, 07:22) zamar24

The internet uplink speed may be a limiting factor but it is not the case of missing CPE->internet packets in the capture - these packets would be dropped later at the modem's uplink interface, not already at the switch, so you would still see them in the capture. The downlink direction is a different case.

And in my case, there was almost no other traffic than those two bidirectional RTP streams, and still the first analysis of Wireshark in RTP -> Show All Streams was reporting losses; the next analysis of the same capture by the same run of Wireshark, i.e. without saving the file, restarting Wireshark, was correct. And so was the first analysis of the saved file by a new run of Wireshark.

So what I was trying to tell you was that you should try to capture the RTP again while playing the video, but to run the RTP analysis more than once.

(20 Nov '16, 08:02) sindy

I will definitely try that. Because many people only have one Ethernet adapter in their PC, so they can't separate VoIP traffic, while still want to record it without artifacts.

(20 Nov '16, 09:06) zamar24
showing 5 of 18 show 13 more comments

1

I only get ICMP issues when I use the tunneled packet capture services, from, for example, Mikrotik with TZSP or some of the other systems that will encapsulate and forward the frames to our collection PC. In this case, the frame is destined for the capture PC and likely nothing is there to collect it. I do netcat or something on that port and pipe to /dev/null to avoid this, but these are usually not redirects, though they are ICMP.

If you are generating redirects I would think you have routing enabled in your stack. Can you try disabling it if you have it enabled? I have those switches with mirror ports configured (they are very inexpensive and I have many of them to support my colleagues when they need to do packet capture on their development systems) and have no issue such as this. you didn't post a trace so we can't check, but what is the source address of the redirects? That will give you some clues as to the interface that is generating them.

I don't know what OS you are using, but you mention Windows components so I assume it is some Windows variant. Windows can route, even the regular non-server OSs, but it requires a registry change. You might be running server and that could have routing on by default, or through some configuration.

answered 06 Nov '16, 22:38

Bob%20Jones's gravatar image

Bob Jones
1.0k2515
accept rate: 21%

Updated the original question, giving some limited trace info. Wanted to upvote your answer as well, but don't have enough rep points. :) It still remains unclear, why changing EnableICMPRedirec reg key does nothing to stop the flooding?

(08 Nov '16, 14:04) zamar24
2

why changing EnableICMPRedirect reg key does nothing to stop the flooding?

Because the key name should actually read something like "FollowICMPRedirect" - it controls the reaction of the IP stack to a received ICMP redirect. From the Microsoft knowlegde base (in network security context, so you have to filter the bias of the wording):

Description: Modifying this registry value to 0 prevents the creation of expensive host routes when an ICMP redirect packet is received.

(10 Nov '16, 04:02) sindy

0

I'm grateful for all advice in this thread provided by sindy and Bob Jones. Just wish to report initial test results of their suggestions. First test case was passing both internet and mirroring port traffic through a basic PC NIC integrated on the mobo. As desire was keeping more switch ports available for other tasks, and both helpers mentioned possible Windows interference no matter how many NICs are used, I tried first changing some Windows settings.

Blocking or permitting ICMP traffic through Firewall by changing advanced IDS - Packet Inspection settings didn't affect the flooding at Wireshark traffic capture from the mirror port. I then changed the following Registry keys:

Switched Off ICMP Redirects. That didn't produce any improvements on its own or at all upon reboot:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableICMPRedirect, 1= enable and 0=disable

Disable Windows IP Routing. That upon reboot stopped ICMP packets flooding through the NIC:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\IpEnableRouter, 1= enable and 0=disable

I also tried stopping & starting Routing and Remote Access Service said to be linked to that IP Routing Reg key, but it didn't affect the flood.

While the culprit was found, there are caveats:

  • Windows 10 Pro 64-bit was installed just a month ago, not sure whether that Reg setting was set to 1 by default, or changed by some apps. It needs some research.
  • NIC model choice may degrade audio quality of captured on PC VoIP traffic, but not the call-in-progress itself, when downloading heavy content in parallel through the same switch mirroring port, while talking on the phone
  • Therefore, 2 NICs setup (one for capture traffic from a mirrorring port, another for internet browsing) is preferred, especially if your NICs are standard Mobo chipset gear. More tests are on the way later, time permitting.

answered 08 Nov '16, 07:21

zamar24's gravatar image

zamar24
6348
accept rate: 0%

edited 08 Nov '16, 07:59

FWIW, it's disabled on the 2 Win10 systems I have at hand (one upgraded from Win 8.1, through to build 1607, the other a clean install of build 1511).

(08 Nov '16, 07:58) grahamb ♦
1

Feedback from my side, my Anniversary-updated Windows 10 64 bit obtained through autoupgrade from Windows 7 64 bit have HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\IpEnableRouter set to 0. I've never touched it knowingly, but I have set up and deconfigured Windows connection sharing multiple times on this machine while still running Windows 7. WCS is basically a router with a DHCP server on NICs chosen to be LAN interfaces and NAT on the NIC chosen to act as WAN interface.

As for the capturing quality: I'd assume the choice of mode (i.e. whether the NIC connected to the monitoring port also carries own traffic of the PC or not) affects the quality of capturing mirrored data rather than the choice of a particular NIC.

Example of port occupation: 1 - IP phone 2 - capturing PC's "shared mode" NIC 3 - another local PC 4 - unused 5 - WAN uplink

In this case, if the IP phone talks to the VoIP service via the WAN port and the capturing PC downloads a file from another local PC, using almost the full bandwidth of the port, it is no wonder that the other 5->1 traffic doesn't fit well into that bandwidth even if the mirroring can buffer frames and send them when the line is free.

If there is no buffering and the mirrored frames are only sent via the mirroring port when no own traffic frame is currently being sent on it, and get dropped otherwise, running the NIC in shared mode causes random loss of the mirrored frames because at least the Windows generate some incoming traffic on their own all the time. If both own and mirrored frames come from the same source interface (e.g. the WAN uplink), they should not overlap in time and thus collide this way. If they come from different source interfaces, collisions may occur and own traffic should always win.

If the NIC should be guilty for missing mirrored frames due to lower wire-to-kernel throughput than the physical speed on the wire, you would have to see TCP retransmissions in own traffic.

(08 Nov '16, 08:00) sindy

I just checked on my Win 10 64-bit laptop, and IpEnableRouter is set to 0 as well. This means, some network analysis apps recently used likely switched the setting On for their own purposes. Would tracing network layout, response, or collecting stats & controlling speeds by such purpose apps usually require that setting On?

(08 Nov '16, 08:11) zamar24

Would tracing network layout or response by such apps usually require that setting On?

That does not make much sense to me. Also I'd expect any modifications to registry to cause a popup asking for admin permission (unless that change would be done as part of installation of the app which asks for such permission once for all steps).

If saving of restore points is active on that system, I guess there is some tool which can look through them for eventual changes of that registry key.

(08 Nov '16, 08:16) sindy

Most network apps I use ask for admin permission whether to install, start, or run as portable. I didn't change that setting manually for sure. :) I need to run more tests later to investigate your suggested causes.

However, the issue I see now doesn't seem to fit well. When I watch 4K Video in full reso on YouTube, and talk on the phone at the same time, quality of VoIP call-in-progress isn't affected, while recorded VoIP audio is degraded, but only in one direction, i.e. incoming to the phone mirrored traffic is passed OK through Wireshark & NIC, but outgoing from VoIP phone traffic is degraded severely when passing the NIC. I found it strange, since both incoming and outgoing phone traffic are "incoming" when passed through the mirror port, as it doesn't send them out. Why this may happen? I also found, my 2-port pro NIC handles traffic a lot easier.

However, more detail tests are needed to capture all nuances. CPU load at processing 4K YouTube video through Adobe Flash plugin in real time is high, but why the recording is degraded only in one direction? Internet connection is asymmetrical 25/5 at best, but it doesn't affect the VoIP phone originated calls, likely hinting its hardware demands priority traffic from the router or switch. However, it at times affects softphone upload jitter.

(08 Nov '16, 08:37) zamar24

Try to mirror the WAN port instead of the IP phone port (or, even better, swap the two cables so that you don't affect the switch settings) and try the same again. That should give a clue whether there is a difference between mirroring of ingress packets and mirroring of egress packets on the switch or whether the NIC dislikes the phone -> WAN packets.

(08 Nov '16, 08:49) sindy

This is a fascinating topic to research. However, mirroring entire switch traffic will be more abusive for the NIC and PC CPU. What do you mean under "dislikes"? It doesn't dislike them under low traffic. :) I've severe time shortage right now, but will definitely get back to these tests later.

(08 Nov '16, 09:00) zamar24

I didn't expect you would have more WAN traffic than the one generated by the PC and the IP phone, but I've forgotten that by mirroring the WAN port you'd get all the PC's Tx traffic back, so it requires a bit more fiddling - you would have to generate the PC traffic load using another LAN port and have the WAN used only by IP phone traffic to obtain useful results when swapping the roles of the IP phone and WAN port by swapping cables.

By "dislikes" I had in mind just the fact that you get less of the phone->internet frames under high traffic so if the reason is not different treatment of these frames on the switch, it must be a different treatment of them at the NIC.

(08 Nov '16, 09:25) sindy
showing 5 of 8 show 3 more comments