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]

Tunnel IP use as source of tunnel that can not be 

Use IP as source or egress interface 

Sure egress interface' this make your tunnel down when source interface is down.

Can I use same interface as source interface of two different tunnel points to two different remote peer ? YES sure you can 

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.