eigrp and GRE tunnels

[rcohenbci]

I've got 2 3750x with IP Services

switch-A(GRE Tunnel delay 120)---------bunch of stuff----------(GRE Tunnel delay 120)switch-B

On the same switches

switch-A(vlan interface)---------------ethernet------------------(vlan interface)switch-B

One eigrp process on each switch same AS

The vlan and gre have unique /30 subnets and these are included in the eigrp process (along with other subnets local to each switch)

sho eigrp top shows that both paths are seen.

Everything works when both connections are up, and when only the vlan/ethernet connection is up, but if I lose the vlan connection it doesn't redirect over the gre, which is of course the whole reason for the gre being there. Routes are lost, eigrp doesn't see the neighbor. When its working , the topology showing both paths "should" mean that eigrp is going over the tunnel, and the tunnel does pass traffic.

Any ideas are more than welcome. This shouldn't be a problem but I just can't see what's wrong.

router eigrp 42

network <tunnel subnet>

network <vlan subnet>

network <local unique subnet>

network <local unique subnet>

eigrp router-id <local unique int IP>    (added this when it was suggested it could be the problem, didn't change anything)

[rcohenbci]

do you mean the IPs of the tunnel interfaces, or the tunnel "source" and tunnel "destination"? The latter is going to be a number of internet hops, it's not even the same carrier at both ends.

[dslice]

Tunnel source and destination.  Tracing the tunnel IP addresses should show one hop across the tunnel.  The question is what path is used to reach the other end of the tunnel and does it require VLAN10 to be up in order to complete the tunnel.

[rcohenbci]

Well that found a problem, I'm not sure it's THE problem, but definitely A problem. The trace showed the tunnel is going over vlan10. And I can see why now, the source and destination subnets are part of the eigrp on their respective switches, resulting in a Dynamic route being added (in preference over the 0 route) so the gre gets established accross vlan10.

But, this doesn't change that when the vlan10 goes down I can re-route traffic over the gre with a static route. I'd think that when vlan10 goes down, the dynamic route is cleared, the gre re-establishes via the default route. Not what I intended, and it means that the traffic to/from one host on sw-A which I thought I was redirecting over the gre/internet via a route-map is actually going over my QnQ. Not a lot of traffic now but it would have haunted me later.

Before you say it ;-), absolutly this needs to be fixed first. I didn't see the routing confict before, so why would I assume I'm not missing somthing else.

I need to think about how to fix this, I could do a single host static route or a route-map to force the traffic over the correct path, but I'm not sure yet how this may affect the rest of the system...... Hold on, I could do it via a route-map limited to just gre traffic between the two IPs, but where would I apply it? It wouldn't be int vlan10 because I don't want it to go that way in the first place, not int vlan20(30) because wouldn't it be outbound traffic and route-maps are applied to inbound. Or is my resoning flawd.

Please, let me know what you think.

[dslice]

Would you still be able to route the way you want if you just left the tunnel endpoints out of EIGRP?  In other words, use more specific network statements and leave the interface you plan to use for the tunnel source/destination out of EIGRP completely.

[rcohenbci]

Sort of thinking out loud here.

On both sides I have both public and private subnets that need to communicate with each other without translation and for the most part over the primary QnQ path (which has QoS). In the event the primary path fails, the traffic must still get to the other side without NAT (hence the GRE). This is VoIP traffic.

On the sw-A side (and maybe on the B side in the future) I have a high traffic node that does not require QoS but there cannot be NAT between it and the other nodes, regardless of whether they are public or private IPs. So this traffic should go over the Internet through the GRE to maintain the private addressing and keep the traffic over the QnQ to a minimum. But unlike the QoS traffic, which must go through even when it's primary path goes down, if the Internet goes down for a little while I can live with this traffic being interrupted. This is NetFlow traffic. Right now a route-map sets the next hop of traffic to/from this node to the far end of the GRE. I can't use a static route because on the A side it needs to be source-based.

Private subnets are added, changed, or removed on an almost daily basis, so dynamic routing is esential.

If I took the GRE subnet out of the eigrp I can see everything working in the primary mode. But without the GRE subnet in eigrp wouldn't this prevent eigrp from seeing the secondary path, so if the QnQ went down there would be no route to the far end???

So someplace I would need a static route or a route-map for the tunnel source/destination forcing it over the Internet without affecting the rest of the traffic. I'm concerned that putting in a static route would cause other problems since the source/destination IPs are the vlan interfaces. And I'm not sure where I would need to apply a route-map to accomplish my goal. I also need to keep the adding and removing of subnets (vlans) as simple as possible since, once everything is worked out, this will often be done by less skilled techs.

What if I assigned a secondary IP to the vlan interfaces (that are currently the tunnel source/destination), then I could use the secondary IPs as the tunnel source/destination, assign static routes for just these IPs, and be sure that it won't interfere with anything else that's going on??

Sometimes I mis the days working someplace where I have peers to brainstorm with. Sure, being top-dog is nice (where I'm at, not saying I'm the best there is by any stretch) but it can be lonely.

[dslice]

I don't have time at work today to completely evaluate your comments, but I did want to mention one thing pertaining to the following statement.

"If I took the GRE subnet out of the eigrp I can see everything working in the primary mode. But without the GRE subnet in eigrp wouldn't this prevent eigrp from seeing the secondary path, so if the QnQ went down there would be no route to the far end???"

Not knowing your topology, I don't know how your tunnel endpoints are reachable, but I'm afraid you may be confusing the tunnel enpoints I'm talking about and the IP addresses applied to the tunnel interfaces.  The tunnel interface addresses do have to be included under a network statement for EIGRP to form peers, but the actual tunnel source/destination (what I'm referring to as the endpoints) just need to be reachable via some method, not necessarily (ore even desirably) via EIGRP.

I'll try to remember to spend some more time looking at your comments when I get home from work but I'm too tied up with my day-job to spend any time on it now.

[Peter Koltl]

Yes, tunnel source and destination addresses (let's call them NBMA addresses for tradition) should be excluded from any dynamic routing. (These are public addresses.) Do they have alternative paths to form that GRE tunnel?

[rcohenbci]

Well at least the problem is clear.

definitions;

source and destination (or NBMA) are exacly what is listed as "source" or "destination" in the Tunnel interface configuration and they are public Internet IP addresses on a different carrier at each location.

Tunnel interface IP is what follows "IP address" in the tunnel interface config.

Since the public(Internet) subnets at either end need to be part of the eigrp (so they will go over our private network instead of the internet), I can't use an IP within those subnets as either the tunnel source or destination.

Let me look at my available IPs, maybe I can further subnet them or get another small subnet from the carriers.