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
So where did this idea behind specifying the traffic analyzer’s IP as the destination for GRE come from?
R1 - R2
Question 3
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