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