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
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.
