Gre source interface question

[ColForbin]

I have router a with a gre tunnel (tunn 1)to router b. Gig 0/0/0 to Gig 0/0/0

i need to make another tunnel from A to a third on router C. C is connected to B on gig 0/0/1. 

No routing protocols it’s a small network all static’s. 

What’s the best way to handle the source interface on router A?  Use the public IP?  The interface itself, gig 0/0/0? Or the Tunn 1 IP addr?

[MHM Cisco World]

Never mind

MHM

[M02@rt37]

hello @ColForbin 

Tunnel1 as source will not work _ tht IP exist only after the first tunnel is UP ...

Be sure Router C has got a static route back to Router A's source IP through Router B for the tunnel to come up successfuly.

[Joseph W. Doherty]

I have router a with a gre tunnel (tunn 1)to router b. Gig 0/0/0 to Gig 0/0/0

Do those two interfaces share a link and in the same subnet?

C is connected to B on gig 0/0/1.

Ditto question?

If answers, above, are yes, then why tunnels?  A learning lab?  Could you explain purpose and topology choice for these tunnels?

That aside, you can "multiplex" the same interface IP for multiple tunnels.  (The one device, I recall it was recommended not to do this on was the 6500.  For it, each tunnel was recommended to have its own source interface, which could be accomplished by using loopbacks.  [I believe this was to insure optimal hardware processing of each tunnel's traffic.])

Could the second tunnel use the first tunnel's IPs?  I'm unsure that it's impossible.  You would have to be very careful with routing loops caused by faulty recursive routing, which often happens to those new to tunneling even with a single tunnel.

M02@rt37 mentions

Be sure Router C has got a static route back to Router A's source IP through Router B for the tunnel to come up successfuly.

He's 100% correct, router C needs to know how to reach router A's tunnel destination, but the converse is true too, i.e. A=>C.  Further this applies to all transit L3 hops, like router B.  But although static route statements are generally used, how routing is structured is an "it depends".  For example if both routers A and C had a default static to router B, that might work in your case (cannot be sure as you haven't fully described your topology).

[ColForbin]

Sorry about the delay. Had the VMware hat on.

It’s an actual setup. A dev environment. And shocker, there’s issues. The networks between are all /30.  

The reason I asked…Could the second tunnel use the first tunnel's IPs?  The answer is yes it’s possible. That’s the setup i walked into which is why I asked. I was surprised by it and wanted to see what y’all thought. It’s up it’s routing. But yeah the second tunnel is dependent on the first. So not exactly the best design. 
It’s another case of needing to encrypt traffic, that’s the reason for the second tunnel. 
Im thinking the next step is verify all the static’s there and back and recreate the tunnel source with the interface IP….

[Joseph W. Doherty]

So your tunnels are actually GRE/IPSec?  If so, IPSec VTI tunnels have a bit less overhead, and the config is a tiny bit neater.

For either, though, tunnel A<>B and tunnel A<>C both use the router A g0/0/0 interface as source and destination for tunnels.

Since the A<>C tunnel transits router B, router A needs to be able to route to router C's physical interface, and the converse is true for router C.  (All you need to do is to route to router's B same side physical interface facing either A or C.)

BTW, using one tunnel's src/dst interface using another tunnel's IP, besides making routing even more complex, it might also encapsulate/encrypt the A<>C traffic if it tunnel's the A<>C traffic though the A<>B tunnel.  So, although you've may have confirmed my remark using a tunnel IP for another tunnel might work, it's really something to avoid.

Also BTW, don't forget to try to mitigate fragmentation due to tunneling.

[MHM Cisco World]

Never Mind

MHM

[Joseph W. Doherty · Accepted solution]

You can as I mention before use router-A interface as source for both tunnel

BTW, as OP did ask "What’s the best way to handle the source interface on router A?".  One, might argue using loopback interfaces might be the "best way", but using the physical interface is probably the most common way and also likely "good enough".

[MHM Cisco World]

Never mind

Sauron 

[Joseph W. Doherty]

If he use IP as tunnel source then device can not detect status of IP and hence even if this IP is not more in RIB the tunnel will be UP 

If he use interface as tunnel source then router can detect status of interface abd make tunnel UP or down depend on that

Using LO as tunnel source 

For single WAN that so so bad idea' since LO same as IP always UP

All true, but "so bad", debatable.

As tunnels often span multiple devices you can run into the situation where each ends' local physical interfaces are up, but tunnel path broken somewhere in transit. For GRE tunnels, its optional keepalive feature will down tunnel interfaces if end-to-end tunnel connectivity lost.  Unfortunately, I recall (?) it doesn't work for many crypto variants, so then you either need to rely on a crypto session disconnect option, if available, or dynamic routing keep alives, or something else (e.g. BFD?), if possible.  The problem with the latter they might not down the tunnel interfaces so that simple SNMP NMS can easily see the tunnel loss.

For dual WAN' here we use LO to make router get benefit of dual WAN and routing tunnel traffic through one is UP

Multi interface paths, was exactly something I had in mind.  Since LO, supports either single or multiple interface paths, and, as noted above, tunnel interfaces reflecting valid end-to-end tunnel connectivity, is, perhaps, "ify", I believe using a loopback interface is possibly better, but that's IMO, and in typical usage, whether you use a LO or physical interface for tunnel end points, I would leave to implementor's preference.  I.e., I wouldn't call either a best practice.

As a side note, I'll also mention, with various MetroE, WAN or Internet using Ethernet hand-offs, they too can lose connectivity while interface is "up", is possibly why I don't consider a tunnel interface not going down to reflect loss of end-to-end connectivity particularly "bad".

[ColForbin]

It’s a chain of routers. And swapped the second tunnel source to the interface ip. And tunnel destination on the other side to that ip. Tunnel came right back up no issue. 

I was just perplexed when I saw one tunnel ip as a source. And it was working. 

thanks fellas. 

I wasn’t expecting that to be possible.