Hi @lagapidis
Is there any extra configuration we need to take in consideration to mirror traffic from a VRF that belong to GRE Tunnel.
Ex :
A=====GRE=======B------------>Wireshark ( GRE Tunnel is established between A and B)
when I ERSPAN the GRE tunnel i see the traffic but i can’t see the traffic goes through the VRF
BR
Hello Mohammed
Can you tell us a little bit more about the trouble you are having? When you say you can see the traffic but you cannot see the traffic that goes through the VRF, do you mean that you see it encapsulated but can’t read it? Or you don’t see it at all? Are you sure it is routed through the GRE tunnel?
For ERSPAN, a GRE tunnel interface can be used as the source of an ERSPAN session. This feature is supported. And VRFs are not a configuration that will affect the operation of ERSPAN since ERSPAN captures any frames going through that interface, no matter what upper layer characteristics they have. So I would suggest you troubleshoot not so much the ERSPAN, but your topology and ensure that the VRF in question is indeed going through the GRE tunnel.
It would be helpful if you shared a little bit more about your VRF and GRE config at A and B as well as a packet capture so that we can help you further.
I hope this has been helpful!
Laz
Hello.
ERSPAN configuration is rather confusing in comparison with SPAN/RSPAN.
Question 1
If I understand this right, if the ip address command is under the destination section, it’s telling R1 to which IP address it should tunnel traffic over. You also configure the origin ip address here which is the IP address that you’ll use, just like with traditional GRE configuration.
Question 2
What’s pretty confusing to me is why the destination is 172.16.2.200. which is the traffic analyzer. I’ve seen Kevin Wallace use the same configuration but this isn’t something mandantory. I could just as well specify R2’s G3 interface as the destination.
R1
monitor session 1 type erspan-source
no shutdown
source interface Gi1
destination
erspan-id 100
ip address 192.168.12.2
origin ip address 192.168.12.1
R2
monitor session 1 type erspan-destination
no shutdown
destination interface Gi2
source
erspan-id 100
ip address 192.168.12.2
PC2(config-if)#do ping 192.168.11.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.11.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
PC2(config-if)#
R2 - WIRESHARK
The traffic is being mirrored and appears there 
So where did this idea behind specifying the traffic analyzer’s IP as the destination for GRE come from?
R1 - R2
It seems that the destination doesn’t really care about what IP is being used, as long as one that can actually reach R2 is being used, its fine. Since SPAN takes over and sends over the received packet.
Question 3
Here we are telling R2 to send anything that it receives from R1 towards G2. The source here specifies from who we should send the packet towards G2? So from someone whose SPAN session is 100 (R1!). However, why the need for the IP address? I’ve configured this without it and it works.
It’s just all slightly confusing considering that the configuration is completely different than from RSPAN. On the RSPAN destination device, you’d specify the source as the remote RSPAN VLAN while here, you use the SPAN session ID as source on R2
RSPAN
monitor session 1 source remote vlan x
ERSPAN
monitor session 1 type erspan-destination
source
erspan-id 100
Not to mention that source interface serves as the source of from where packets should be monitored while the entire source section is relevant to the GRE tunnel
That’s all, thanks!
David
Hello David
I like the experimentation you are performing to examine all of the various options for these commands. Indeed it does seem that the configuration of ERSPAN is very forgiving, allowing you to get it to work even if some IP addresses are configured differently.
Remember, the feature creates a GRE tunnel between the two network devices. So it seems that as long as you put in a destination IP that is somewhere on the destination device, or even within the subnet of one of the addresses on one of the interfaces of the destination device, it creates that GRE tunnel. And based on the interface specified, it forwards the spanned traffic to the packet analyzer.
I hope this has been helpful!
Laz
Hello Lazarus - I am afraid my information will arrive “after the fact” but I had this very same question about ERSPAN and the terminus of the GRE tunnel.
The first configuration I tried used the WS ( SNIFFER in my model) as the terminus. But this never made any sense to me and I still am unclear why it works. Although I think I saw you mention in one of the threads that WS recognizes the GRE packets. But then what is the use of the destination interface on the destination router when the GRE tunnel already terminates on the WS interface itself…
So I tried your suggestion and placed the terminus of the GRE tunnel on the inbound interface of the destination router, R1-G1 in my case.
All this works just fine as far as I can tell from the CML packet captures which I have included. These show a ping that was sent from the PC to the inbound interface G2 of router R2. This is the source interface for the ERSAPN session.
I am sorry I haven’t included more detail on the CML Workbench canvas but I am desperately trying to get ready to take the ENCOR in the arc of a week or so.
If anything in the screenshots is unclear let me know and I will be happy to clarify.
But it would be good to know if this configuration is appropriate.
BTW, there are two packet captures - one on the upstream link attached to interf G1 of router R1 (terminus of the GRE); and another on the downstream link G2 of R1(ERSPAN destination interf).
One other thing - the packet capture on the segment between R2-R1 where the GRE tunnel is configured — the CML packet capture list shows this as an ICMP which is the payload of the GRE tunnel. I would have expected this to appear as GRE or ERSPAN — it is only when you crack open the packet that you see these.
Hello Sandro
Thanks for sharing your experimentation with us! It’s always helpful!
Yes indeed! In another post, we saw @davidilles perform a similar experiment, and based on that I mentioned in my post that:
Even if you use the IP address of the sniffer device, the GRE tunnel still terminates on the connected interface, and not the sniffer. It just seems like that’s how it works.
Keep in mind that packet captures in CML will not simulate the packet capturing capability of the Wireshark device. The purpose of these captures is to see how ERSPAN works, and not to actually capture specific packets on the Wireshark device. But it does give you an understanding of how ERSPAN works. It is indeed interesting that even though it is a GRE tunnel, the protocol indicated in the packet list is ICMP. This may just be how the packet capture facility in CML is configured, to perform in this manner.
I hope this has been helpful!
Laz
Thanks for the follow-up Lazarus.
There is one other item I would like you to confirm if possible.
Since ERSPAN ( and RSPAN and SPAN for that matter ) are really meant to be used with switches.
And so the lab experiment I really wanted to try was with ERSPAN working between two switches where the destination or terminating switch has several VLANs and where the switchport analyzer is connected to a port in one of the VLANs. All the VLANs terminate on their respective SVIs. See the simple schematic attached to this thread.
Regrettably I can not perform this in CML 2.6 because the Nexus switch image only supports ERSPAN-source for some reason.
In the diagram I show the terminus of the GRE tunnel on the SVI (the IP addr of the SVI) of VLAN 100 where the WS device resides. Then in ERSPAN-destination mode on the terminating switch I would configure the destination of the ERSPAN packets as the actual port where the WS device is attached.
Is this correct?
Lazarus - don’t go crazy with the follow-up question I submitted regarding the svi’s and the vlans - unless you happen to know the answer of the top of your head.
I think I found a way to try this out with the cat 9000 v in the devnet sandbox. I have this image available on my local copy of CML but I don’t think I can run it on my machine - it requires too much RAM.
If I can get to it this weekend I’ll put together a quick topology and let you know the results.
Hello Sandro
The way you described your intended ERSPAN configuration appears to follow Cisco’s recommended approach. Here are some additional thoughts that may help to make the configuration approach clearer.
In your description, you are terminating the GRE tunnel on the SVI for VLAN 100 which is valid. Just make sure that the SVI is operational and its IP address is reachable from the ERSPAN source switch. When you configure the ERSPAN destination, you must explicitly define the destination interface in the ERSPAN destination session. Also confirm the erspan-id is identical on both source and destination sessions as mismatches prevent traffic forwarding.
This setup is valid provided the ERSPAN-ID, IP reachability, and physical destination interface are correctly aligned.
Take a look at these documents for further information about ERSPAN for IOSXE and Nexus devices:
I hope this has been helpful!
Laz
Hello Sandro
OK great, if you do get it to work over the weekend, let us know how you get along!
Laz
Well I should have suspected that this was too good to be true.
The CML Sandbox requires the use of Cisco Secure Connect (ex AnyConnect) as the VPN client. Perfect. When you attempt to download this software from the Cisco web site you discover that only Cisco enterprise customers have rights to this feature. The alternative is the unsupported open source OpenConnect which I am not prepared to install on my machine.
So as a work-around I found the Cat9000v AlwaysOn sandbox and logged into that device via ssh and tried to configure the ERSAPN feature. ERSPAN is nowhere to be found on that device - in spite of what the documentation claims. So my little experiment is on hold TBD regrettably.
Hello Sandro
That’s too bad, I’d hoped it would work out, but sometimes that’s how things work out. Hopefully, someone with the appropriate credentials will pick up where you left off to complete the experiment. I think it would be worthwhile.
In any case, if anything comes up and you do end up able to complete it, let us know!
Laz
I know others have been commenting about the ERSPAN configuration causing the packets captured to show the GRE (ERSPAN) encapsulation in the packets that are captured. I did not like this at all, as I believe the captured packets should look exactly as they do on the wire (no GRE/ERSPAN encapsulation whatsoever).
I labbed this myself with GNS3 using Cisco Image CSR1000v (v16.02.02) and successfully captured packets via Wireshark on an Ubuntu VM (24.04.4 desktop) and the packets reflect NO GRE/ERSPAN encapsulation whatsoever.
Below is my topology information.
Here’s the basic erspan configuration for each router
R1#show run | section monitor
monitor session 1 type erspan-source
source interface Gi4
destination
erspan-id 100
ip address 3.3.3.3
origin ip address 1.1.1.1
-----
R3#show run | section monitor
monitor session 1 type erspan-destination
destination interface Gi4
source
erspan-id 100
ip address 3.3.3.3
Here’s a screenshot of the captured packets (no GRE/ERSPAN encapsulation)
The “trick” I used is to originate the erspan-source (R1) from Loopback0, with destination of R3 Loopback0.
The wireshark machine has no IP address whatsoever, nor does the Cisco interface which it connects to. In reality, the host/wireshark machine would have two NICs. One NIC would be IP’ed for Management access and isolated from the second NIC which would have no IP address just like in my lab.
R1 running-configuration
R1#show run
Building configuration...
Current configuration : 1790 bytes
!
! Last configuration change at 01:46:30 UTC Tue Jul 7 2026
!
version 16.2
service timestamps debug datetime msec
service timestamps log datetime msec
no platform punt-keepalive disable-kernel-core
platform console auto
!
hostname R1
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
!
!
!
!
!
!
!
!
!
!
ip dhcp pool VPCS
network 192.168.255.0 255.255.255.0
default-router 192.168.255.1
lease 0 0 5
!
!
!
!
!
!
!
!
!
!
subscriber templating
!
!
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
!
!
!
!
!
!
license udi pid CSR1000V sn 9HOW73ACHYA
diagnostic bootup level minimal
!
spanning-tree extend system-id
!
!
redundancy
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
ip ospf 1 area 0
!
interface GigabitEthernet1
description to_R2
ip address 192.168.2.1 255.255.255.248
no ip redirects
no ip proxy-arp
ip ospf 1 area 0
negotiation auto
!
interface GigabitEthernet2
no ip address
shutdown
negotiation auto
!
interface GigabitEthernet3
no ip address
shutdown
negotiation auto
!
interface GigabitEthernet4
description to_VPCS (PC1)
ip address 192.168.255.1 255.255.255.0
no ip redirects
no ip proxy-arp
ip ospf 1 area 0
negotiation auto
!
router ospf 1
passive-interface default
no passive-interface GigabitEthernet1
!
!
virtual-service csr_mgmt
!
ip forward-protocol nd
no ip http server
no ip http secure-server
!
ip tftp source-interface GigabitEthernet1
!
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
!
line con 0
logging synchronous
stopbits 1
line vty 0
login
line vty 1
login
length 0
line vty 2 4
login
!
!
monitor session 1 type erspan-source
source interface Gi4
destination
erspan-id 100
ip address 3.3.3.3
origin ip address 1.1.1.1
!
!
!
!
!
!
!
end
R2 running-configuration
R2#show run
Building configuration...
Current configuration : 1424 bytes
!
! Last configuration change at 01:11:06 UTC Tue Jul 7 2026
!
version 16.2
service timestamps debug datetime msec
service timestamps log datetime msec
no platform punt-keepalive disable-kernel-core
platform console auto
!
hostname R2
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
!
!
!
!
!
!
!
!
!
no ip domain lookup
!
!
!
!
!
!
!
!
!
!
subscriber templating
!
!
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
!
!
!
!
!
!
license udi pid CSR1000V sn 9HOW73ACHYA
diagnostic bootup level minimal
!
spanning-tree extend system-id
!
!
redundancy
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
ip ospf 1 area 0
!
interface GigabitEthernet1
description to_R1
ip address 192.168.2.2 255.255.255.248
ip ospf 1 area 0
negotiation auto
!
interface GigabitEthernet2
description to_R3
ip address 192.168.3.2 255.255.255.248
ip ospf 1 area 0
negotiation auto
!
interface GigabitEthernet3
no ip address
shutdown
negotiation auto
!
interface GigabitEthernet4
no ip address
shutdown
negotiation auto
!
router ospf 1
!
!
virtual-service csr_mgmt
!
ip forward-protocol nd
no ip http server
no ip http secure-server
!
ip tftp source-interface GigabitEthernet1
!
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
!
line con 0
logging synchronous
stopbits 1
line vty 0
login
line vty 1
login
length 0
line vty 2 4
login
!
!
!
!
!
!
end
R2#
R3 running-configuration
R3#show run
Building configuration...
Current configuration : 1574 bytes
!
! Last configuration change at 02:41:38 UTC Tue Jul 7 2026
!
version 16.2
service timestamps debug datetime msec
service timestamps log datetime msec
no platform punt-keepalive disable-kernel-core
platform console auto
!
hostname R3
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
!
!
!
!
!
!
!
!
!
no ip domain lookup
!
!
!
!
!
!
!
!
!
!
subscriber templating
!
!
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
!
!
!
!
!
!
license udi pid CSR1000V sn 9HOW73ACHYA
diagnostic bootup level minimal
!
spanning-tree extend system-id
!
!
redundancy
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
ip ospf 1 area 0
!
interface GigabitEthernet1
ip address dhcp
negotiation auto
!
interface GigabitEthernet2
description to_R2
ip address 192.168.3.3 255.255.255.248
no ip redirects
no ip proxy-arp
ip ospf 1 area 0
negotiation auto
!
interface GigabitEthernet3
no ip address
shutdown
negotiation auto
!
interface GigabitEthernet4
no ip address
negotiation auto
!
router ospf 1
passive-interface default
no passive-interface GigabitEthernet2
!
!
virtual-service csr_mgmt
!
ip forward-protocol nd
no ip http server
no ip http secure-server
!
ip tftp source-interface GigabitEthernet1
!
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
!
line con 0
logging synchronous
stopbits 1
line vty 0
login
line vty 1
login
length 0
line vty 2 4
login
!
!
monitor session 1 type erspan-destination
destination interface Gi4
source
erspan-id 100
ip address 3.3.3.3
!
!
!
!
!
!
!
end
R3#
Wireshark pcap file
Ubuntu_VM_Wireshark_cap.pcapng (1.7 KB)
Hello Efrain
Thanks for sharing your lab experiment with us! Indeed, there was a question in a previous post about whether the captured packets show GRE encapsulation. This is because the lesson’s example capture was taken on the transport link between R1 and R2 (i.e., directly on the GRE tunnel), not on R2’s destination interface facing the Wireshark host. That capture legitimately shows the GRE/ERSPAN headers because it’s sniffing the tunnel itself, not the decapsulated output. That was done on purpose to show that it is indeed a GRE tunnel that enables ERSPAN.
When you apply it the way you did, you don’t see any GRE encapsulation. The key here is that the erspan-destination session on the destination router is responsible for de‑encapsulating the GRE/ERSPAN header and forwarding only the original, native Layer‑2 frame out the configured destination interface. If you plug Wireshark into that destination interface (rather than sniffing the GRE tunnel link itself), you will see the traffic exactly as it looked on the original source interface, without GRE or ERSPAN headers, or extra IP headers.
Remember, the mechanism that strips the GRE/ERSPAN wrapper is built into the erspan-destination session type itself. There’s no extra configuration needed beyond aligning those parameters.
I hope this has been helpful!
Laz
Ah I did not notice that capturing the tunnel itself was the capture. So meta! Thanks for the clarification