An engineer configures ERSPAN on Router R1 to monitor traffic from VLAN 100 to a remote collector at 192.168.10.10 via a GRE tunnel. The source interface is GigabitEthernet0/0/0. After configuration, the collector receives no mirrored packets. R1's configuration: monitor session 1 type erspan-source source interface Gi0/0/0 both destination erspan-id 100 ip address 192.168.10.10 origin ip address 10.1.1.1 no shutdown. R1's routing table shows a default route via 10.1.1.2, and a static route to 192.168.10.0/24 via 10.1.1.2. The tunnel interface Tunnel0 is up/up with IP 10.1.1.1/30. What is the most likely root cause?
The source IP 10.1.1.1 is the tunnel interface IP, and the destination 192.168.10.10 is routed via 10.1.1.2, which is the tunnel's next-hop. This recursion causes the encapsulated packet to be dropped.
Why this answer
ERSPAN encapsulates mirrored packets in GRE with a destination IP of the collector. The router must have a route to the collector IP, but the encapsulated packets use the routing table of the default VRF. If the destination IP is reachable via a route that points to a next-hop that is not directly connected, the router may attempt to use the GRE tunnel interface itself, causing a recursive routing loop.
The GRE tunnel interface IP (10.1.1.1) is used as the source, but the destination 192.168.10.10 is routed via 10.1.1.2, which is the tunnel's next-hop. This creates a recursion: the packet is encapsulated with destination 192.168.10.10, then routed, which again matches the tunnel, leading to a loop and packet drop. The fix is to use a separate source IP or ensure the route to the collector does not point back through the tunnel.