You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/defender-for-iot/organizations/best-practices/traffic-mirroring-methods.md
+15-4Lines changed: 15 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,7 +13,7 @@ This article is one in a series of articles describing the [deployment path](../
13
13
14
14
The decision as to which traffic mirroring method to use depends on your network configuration and the needs of your organization.
15
15
16
-
To ensure that Defender for IoT only analyzes the traffic that you want to monitor, we recommend that you configure traffic mirroring on a switch or a terminal access point (TAP) that includes only industrial ICS and SCADA traffic.
16
+
To make sure Defender for IoT only analyzes the traffic that you want to monitor, we recommend that you configure traffic mirroring on a switch or a terminal access point (TAP) that includes only industrial ICS and SCADA traffic.
17
17
18
18
> [!NOTE]
19
19
> SPAN and RSPAN are Cisco terminology. Other brands of switches have similar functionality but might use different terminology.
@@ -23,7 +23,7 @@ To ensure that Defender for IoT only analyzes the traffic that you want to monit
23
23
24
24
We recommend configuring your traffic mirroring from all of your switch's ports, even if no data is connected to them. If you don't, rogue devices can later be connected to an unmonitored port, and those devices won't be detected by the Defender for IoT network sensors.
25
25
26
-
For OT networks that use broadcast or multicast messaging, configure traffic mirroring only for RX (*Receive*) transmissions. Multicast messages will be repeated for any relevant active ports, and you'll be using more bandwidth unnecessarily.
26
+
For OT networks that use broadcast or multicast messaging, configure traffic mirroring only for RX (*Receive*) transmissions. Multicast messages are repeated for any relevant active ports, and you'll be using more bandwidth unnecessarily.
27
27
28
28
## Compare supported traffic mirroring methods
29
29
@@ -72,7 +72,7 @@ We recommend TAPs especially when traffic mirroring for forensic purposes. Advan
72
72
73
73
- TAPs aren't processor-sensitive, which means that packet timing is exact. In contrast, switches handle mirroring functionality as a low-priority task, which can affect the timing of the mirrored packets.
74
74
75
-
You can also use a TAP aggregator to monitor your traffic ports. However, TAP aggregators aren't processor-based, and aren't as intrinsically secure as hardware TAPs. TAP aggregators may not reflect exact packet timing.
75
+
You can also use a TAP aggregator to monitor your traffic ports. However, TAP aggregators aren't processor-based, and aren't as intrinsically secure as hardware TAPs. TAP aggregators might not reflect exact packet timing.
76
76
77
77
### Common TAP models
78
78
@@ -99,7 +99,7 @@ The sensor's monitoring interface is a promiscuous interface and doesn't have a
99
99
Use ERSPAN encapsulation when there's a need to extend monitored traffic across Layer 3 domains. ERSPAN is a Cisco proprietary feature and is available only on specific routers and switches. For more information, see the [Cisco documentation](https://learningnetwork.cisco.com/s/article/span-rspan-erspan).
100
100
101
101
> [!NOTE]
102
-
> This article provides high-level guidance for configuring traffic mirroring with ERSPAN. Specific implementation details will vary depending on your equipment vendor.
102
+
> This article provides high-level guidance for configuring traffic mirroring with ERSPAN. Specific implementation details vary depending on your equipment vendor.
103
103
>
104
104
105
105
### ERSPAN architecture
@@ -124,6 +124,17 @@ ERSPAN source options include elements such as:
124
124
125
125
For more information, see [Update a sensor's monitoring interfaces (configure ERSPAN)](../how-to-manage-individual-sensors.md#update-a-sensors-monitoring-interfaces-configure-erspan).
126
126
127
+
### VLAN ID considerations for ERSPAN
128
+
129
+
When setting up ERSPAN, it's important to understand how VLAN IDs are handled based on the type of mirrored port:
130
+
131
+
- Tagged VLANs: These VLANs are present in packets from trunk mirrored ports. They remain intact within the packet payload during encapsulation and are supported by the Microsoft Defender for IoT sensor.
132
+
- Untagged VLANs: These VLANs originate from access mirrored ports. They're stripped from the payload during decapsulation, resulting in their loss. They aren't supported by the Microsoft Defender for IoT sensor.
133
+
134
+
To ensure accurate VLAN detection, configure your network and ERSPAN router so that all mirrored ports use tagged VLANs. This means using mirror ports configured as trunk ports. This setup ensures that VLAN information remains preserved in the packet payload throughout the ERSPAN process, providing full visibility for monitoring on the Defender for IoT sensor.
135
+
136
+
137
+
127
138
## Traffic mirroring with virtual switches
128
139
129
140
While a virtual switch doesn't have mirroring capabilities, you can use *Promiscuous mode* in a virtual switch environment as a workaround for configuring a monitoring port, similar to a [SPAN port](../traffic-mirroring/configure-mirror-span.md). A SPAN port on your switch mirrors local traffic from interfaces on the switch to a different interface on the same switch.
0 commit comments