As you have already stated, this is expected because of the fact that the CEs are VRF-unaware. So they simply terminate the GRE tunnel as normal, and any traversal of the PE routers simply becomes encapsulated using the technology they are running, just like any other packets.
You may be correct that it may have to do with the subinterfaces you’re using, however, there’s no way to know for sure, based on the info you shared. My hunch is that the reason the tunnel is not coming up is the same as in your previous post, that GRE keepalives are not compatible with the use of VRFs on GRE tunnels. Have you attempted to disable the keepalives to see what results you get? Try it and let us know… If we eliminate that as a possibility, we can then go on to the troubleshooting step of checking out the use of the dot1q encapsulation…
Hello Laz - thanks again for looking into this…
So just to clear up the “keepalives” — I omitted these in the config I sent you. There is “show run” output for the GRE tunnel config on R2# included in the CML screenshot annotations but it is easy to miss - it’s on the left hand side of the canvas.
In any event, I did some more trial-and-error with this CML model where I removed the subinterfaces and replaced them with physical interfaces in the respective VRFs. I actually confined my test to the CUST-A VRF.
This does not work either.
I have included the yaml for the original (dot1q) and revised (physical intf) models.
I am starting to suspect that all the tunnel related addressing can not be contained in the same-single VRF. The example from the web I sent you in the original note places the src/dst in one vrf and tu intf in another vrf.
I wish I could find some documentation from Cisco that explains this in black and white.
PS if the yaml files are too cumbersome let me know and I will send you text files of “sho run” ; also, the CML version is 2.6
PPS Laz - I think I finally found the Cisco document that explains how to configure the VRF-aware GRE endpoints…
Updated:
July 31, 2019
Chapter: Configuring GRE Tunnel IP Source and Destination VRF Membership
Chapter Contents
Restrictions for GRE Tunnel IP Source and Destination VRF Membership
Information About GRE Tunnel IP Source and Destination VRF Membership
How to Configure GRE Tunnel IP Source and Destination VRF Membership
Configuration Example for GRE Tunnel IP Source and Destination VRF Membership
Additional References
Feature History for Generic Routing Encapsulation Tunnel IP Source and Destination VRF Membership
Restrictions for GRE Tunnel IP Source and Destination VRF Membership
Both ends of the tunnel must reside within the same VRF.
The VRF associated with the tunnel vrf command is the same as the VRF associated with the physical interface over which the tunnel sends packets (outer IP packet routing).
The VRF associated with the tunnel by using the ip vrf forwarding command is the VRF that the packets are to be forwarded in as the packets exit the tunnel (inner IP packet routing).
The feature does not support the fragmentation of multicast packets passing through a multicast tunnel.
The feature does not support the ISIS (Intermediate System to intermediate system) protocol.
Keepalive is not supported on VRF aware GRE tunnels.
Yes, you are indeed correct, my apologies, I did miss it… I see now that the VRFs were configured on the GRE tunnel. And as you mention they are the same single VRF.
Thank you for sharing all of your research, experimentation, and your lab topology with us. Indeed, the subinterfaces do not affect the end result, and it is indeed the use of VRFs, as the document you shared suggests. I have since added a link to the document you shared in the NetworkLessons note on the topic for future reference.
When it comes to tunneling, can we agree that the two defining factors are encapsulation and path abstraction? For example, with MPLS, pure MPLS without any RDs/RTs isn’t a tunneling mechanism because it’s basically just another way of forwarding data (only encapsulation is achieved).
However, I might be overthinking this or perhaps I don’t know it at all, but what exactly is path abstraction? What am I supposed to imagine under it?
The primary characteristic of a tunnel is encapsulation. This is the process of wrapping a packet within another protocol’s headers (GRE, VXLAN, IPsec, etc.). This allows a complete packet (with its own headers) to be treated as a payload only, completely ignoring the original packet’s headers until it is encapsulated. This allows the tunneling protocol (i.e. the protocol of the prepended headers) to deal with transporting the original packet through a part of the network, until it reaches the location of decapsulation. Once decapsulated, the original headers are used to get the packet to its destination (if it has not already reached it). More about tunneling can be found at this NetworkLessons note.
Now path abstraction is a characteristic of tunneling. It refers to the process of hiding the actual physical path between endpoints. From the point of view of an encapsulated IP packet, for example, it is only “aware” of the tunnel entrance point and the tunnel exit point. Because it is carried as a payload in its entirety, it doesn’t “know” anything about how the tunnel is physically routed. This abstraction essentially says "you know the entrance point, and the exit point of the tunnel, and that’s all you need to know. How the tunnel goes from one to the other is abstracted, or is a black box as far as the tunneled packet is concerned.
Now as far as MPLS goes, it is a bit of a different situation. It can be considered tunneling because of the fact that an additional header is prepended on the IP packet, and it is then transmitted using labels. However, the argument has been made, and it’s a good one, that it is not true tunneling because the header that is added is at a lower layer, so it’s just normal encapsulation. GRE tunneling puts one IP packet into another - same layer. But the MPLS header, considered to operate at “Layer 2.5,” is just a normal encapsulation. MPLS-TE, on the other hand, uses LSP tunnels, which although they too are simply composed of an RSVP header that’s normally encapsulated within an IP packet. So even though they’re called tunnels, they don’t conform to the classic definition of tunnels. So for MPLS, strictly speaking, it is not tunneling, but you’ll find a lot of different opinions. MPLS does indeed constitute a special case and may be somewhat up to interpretation. Does that make sense?
My questions revolve around a scenario in which we have more than a single branch router that needs to form a GRE tunnel with the HQ router shown in the topology.
If we were to add 2 more branch routers to the topology shown in the lesson, and connect them to the ISP router, and wanted to configure a GRE tunnel from each branch to the existing HQ, I have the following questions. Lets also assume that these new routers and the HQ router have entries on their routing tables to reach each other on the appropriate interfaces:
On the HQ router, we would need to configure two new tunnel interfaces that correspond to the two GRE tunnels for each separate branch router we just added. Both of these new tunnel interfaces, lets call them tunnels 2 and 3, would each also need a unique IP subnet in order to establish the tunnels to the new branch routers. I came to this conclusion due to the fact that I cannot configure multiple tunnel destinations under the already existing tunnel 1 interface on the HQ router. Is this correct?
Can the HQ router use the same physical interface, in this case Fa0/0, to establish more than a single GRE tunnel? My assumption is that it can. Even though we would be specifying the same tunnel source interface under the configuration for the new tunnel interfaces on the HQ router, as long as the configuration under the new tunnel interfaces is using a separate destination IP address for each tunnel then it would work, correct? Also, would using the same source interface on the HQ router for multiple tunnels cause any issues if those tunnels are encrypted with IPsec?
The configuration for these new tunnels on the two new branch routers would not involve anything other than simply creating a new tunnel interface, giving the tunnel a unique IP address for whatever subnet we chose for that tunnel, and specifying the source and destination interfaces, correct?
Would there by a way to use the existing subnet that Tunnel 1 is using (192.168.13.0/24), and integrate the two new routers into the already existing tunnel 1 by giving the tunnel interfaces on the new routers a unique IP on the 192.168.13.0/24 subnet? My assumption is no, since we would need a separate tunnel interface for each branch router we added due my reasoning that I mentioned on the first question. I also believe the only way to use a single subnet across multiple routers all wanting to establish GRE tunnels would be to configure mGRE in a DMVPN scenario, correct?
Yes that is correct. The GRE tunnels that are configured in this lesson are point to point tunnels, and require a single remote endpoint. However, it is possible to create what is known as a multipoint GRE tunnel or mGRE. This can be done by applying the tunnel mode gre multipoint configuration command on the tunnel interface configuration mode. In this way, you can create a single tunnel interface on your HQ, which acts as the hub, and multiple endpoints for your multiple branches, and all tunnel interfaces on all devices will be in the same subnet.
More info about this can be found here:
Yes it can, and your description is correct. For point to point GRE tunnels, you can use the same interface to terminate the tunnels, but each tunnel must have an IP address in a different subnet, and each tunnel must have a different destination IP as well.
Yes that is correct.
Using point to point GRE your assumption is correct. DMVPN does use mGRE along with dynamic NHRP, but you can also use static NHRP mapping as well. But certainly DMVPN would be the preferrable way to go as it is much more scalable.