GRE IP address for the tunnel interface

[AdamBudzinski]

Is there any recommendation / best practice in regards to selecting the IP addresses for GRE tunnel interfaces ? 

[Joseph W. Doherty]

I would say treat them as any other p2p addresses within your IP allocation scheme.

[AdamBudzinski]

So, if I want to advertise OSPF routes across the Internet via GRE tunnel and the network that I want to advertise is 192.168.0.0 /16 the IP assigned to the tunnel interface could be from that range, e.g. 192.168.255.100, right ?

[Richard Burts]

I started to say that yes assigning 192.168.255.100 as the tunnel IP address would be fine. And then I realized that we need to know a bit more about your requirements. Do you mean that you want to advertise just the summary of 192.168.0.0/16? Or do you mean that you want to advertise multiple networks that are in the range of 192.168.0.0/16?

If you think of how OSPF generates and advertises summary routes it gets tricky trying to have an active subnet of the summary that you are trying to advertise. So if your requirement is to have OSPF advertise 192.168.0.0/16 over the GRE tunnel then the tunnel address should be in some other network (perhaps 172.16.1.100).

HTH

Rick

[AdamBudzinski]

Thank you Richard. I get your points. So say, I have a router with on LAN attached to it. The, say Gig0/1 interface has the 192.168.0.1 255.255.0.0 address assigned to it. So I enable OSPF specifying not the network address with wildcard mask but 192.168.0.1   0.0.0.0, which tells our router to enable the Gig0/1 interface for OSPF routing process. I know this is maybe not the best example, as it’s not probably the most efficient way to enable OSPF on a stub router, but anyway I was just curious. I guess in this case, I could go ahead and assign the 192.168.255.100 to the virtual tunnel interface, correct? Or will the router generate an error, saying that the networks overlap ?

[Richard Burts]

If gig0/1 has 192.168.0.1 255.255.0.0 then the router will reject the attempt to put 192.168.100.255.100 as the tunnel IP address because of the overlap.

And it does not matter how you enable OSPF. Using the network form or the host form has exactly the same result of activating OSPF on the interface. And the issue is not about OSPF running but is about IP address overlap. If 192.168.0.1 255.255.0.0 is assigned on an interface then no other interface on that router may be in 192.168.anything.

HTH

Rick

[AdamBudzinski]

So, the tunnel interface IP's can be set to whatever I want , I guess, right ? 

Considering this simple scenario, where I want to ping from Laptop1 at 129.168.2.2 to Laptop0 at 192.168.1.2 through a GRE tunnel, the tunnel interfaces are not present in the transport header or passenger header, correct? 

[Joseph W. Doherty]

Correct, the tunnel IPs would not be present within a transit packet.  The original packet's IPs would be encapsulated.  The outer tunnel packet's "normal" IPs would be the physical interface IPs.

I.e. tunnel packet (for your ping from 192.168.2.2 to 192.168.1.2):

dest IP 1.1.1.1 src IP 1.1.1.2

encapsulated:

dest IP 192.168.1.2 src IP 192.168.2.2

[Joseph W. Doherty]

Yes, you could use a /16 for a tunnel network although a GRE tunnels are p2p, it would be just a bit wasteful of address space.

As your later posts, and Rick's replies note, whatever interface the /16 is assigned to, other IPs from that network could not be used by other hosts, including router ports unless they were on the same physical network.  For example, you couldn't have the tunnel and a LAN interface both using IPs from the same /16 address block.

How you could use a /16, you might assign the first /24 for one LAN interface, the next /24 for another LAN interface, etc.  You could also use a /24 from the /16 for your tunnel network, but less wasteful would be to devote a /24 for p2p networks, and take either /30s or /31s networks out of that /24.