Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

eigrp and GRE tunnels

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)

Everyone's tags (3)
22 REPLIES
New Member

eigrp and GRE tunnels

Randall

can you post the show ip route eigrp from both switches? I would like to see both routes in the table

New Member

eigrp and GRE tunnels

The eigrp topology shows two paths (potential routes). Only one route is selected by eigrp, and that one is shown and labeled as an eigrp route.

Additional info: show eigrp events says duplicate router ID and ignores the secondary path. This makes sense to me since it's getting eigrp on two connections from the same router, and the router IDs are definitely different. I would expect this would not happen if there were additional routers in between.

eigrp and GRE tunnels

So you have the same VLAN on both switches like:

Switch A: VLAN 10 lets say with an IP of 192.168.1.0/24

Switch B: VLAN 10 192.168.1.0/24

???

Silver

eigrp and GRE tunnels

Is the tunnel destination by any chance routed via the VLAN interface?

Post your config and routing table.

New Member

eigrp and GRE tunnels

Switch-A

VLAN 1 192.168.1.0/24 with 6 access ports assigned.

VLAN 2 129.168.2.0/24 with 6 access ports assigned.

Both VLAN interface addresses are .1 in their subnet.

VLAN 10 10.10.10.1/30 a single access port which connects to switch B over a QnQ Ethernet circuit.

VLAN 20 publicIP single access port connected to firewall and then Internet.

Tunnel-1 10.10.20.1/30 connected to switch B across the Internet.

Switch-B

VLAN 1 192.168.11.0/24 six access ports assigned.

VLAN 2 192.168.12.0/24 six access ports assigned.

VLAN 10 10.10.10.2/30 One access port, QnQ to switch A.

VLAN 30 publicIP single access port to firewall then to Internet.

Tunnel-1 10.10.20.2/30 connected to switch A across Internet.

I'm posting from my iPhone so the actual config will have to wait.

I've done eigrp countless times but usually with more routers involved and more routers between potential paths. Could this have something to do with there being only two routers?

Bronze

Re: eigrp and GRE tunnels

Without routing and topology table output, it's going to be darn difficult to help you. With the Vlan interface down, what is the expected path between tunnel endpoints?

Sent from Cisco Technical Support iPad App

New Member

Re: eigrp and GRE tunnels

Below is the releavant config and output for "sho ip eigrp top". The "sho ip rout" on both switches shows everything correctly when its working, with both paths up. There are no duplicated routes and wether it's L C or D is correct. When the primary path goes down only the L and C routes are shown and only the local networks are shown in the topology.

You'll have to take some of this on faith since I'm not going to post anything that hasn't been sanatized for public consumption. For now let's assume that after 25 years I've got some idea what I'm doing and I've had at least 6 others look at the configs and haven't seen anything they'd call 'wrong"

"With the Vlan interface down, what is the expected path between tunnel endpoints?" On sw-A the tunnel goes over vlan20 which has a public IP, is assigned to only one access port, and connects to a firewall running in router mode. The tunnel then travels accross the Internet finally going through another firewall, also in router mode, and then to the single access port assigned to vlan30 on sw-B which has a piblic IP.

Switch-A

router eigrp 42

network 10.10.10.0 0.0.0.3

network 10.10.20.0 0.0.0.3

network 192.168.1.0 0.0.0.255

network 192.168.2.0 0.0.0.255

network 222.222.222.192 0.0.0.63

eigrp router-id 222.222.222.193

EIGRP-IPv4 Topology Table for AS(42)/ID(222.222.222.193)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

       r - reply Status, s - sia Status

P 222.222.222.192/26, 1 successors, FD is 2816

        via Connected, Vlan30

P 111.111.111.192/26, 1 successors, FD is 3072

        via 10.10.10.1 (3072/2816), Vlan10

        via 10.10.20.1 (286976/2816), Tunnel1

P 192.168.11.0/24, 1 successors, FD is 3072

        via 10.10.10.2 (3072/2816), Vlan10

        via 10.10.20.2 (286976/2816), Tunnel1

P 192.168.12.0/24, 1 successors, FD is 3072

        via 10.10.10.2 (3072/2816), Vlan10

        via 10.10.20.2 (286976/2816), Tunnel1

P 10.10.20.0/30, 1 successors, FD is 286720

        via Connected, Tunnel1

P 10.10.10.0/30, 1 successors, FD is 2816

        via Connected, Vlan10

P 192.168.1.0/24, 1 successors, FD is 2816

        via Connected, Vlan1

P 192.168.2.0/24, 1 successors, FD is 2816

        via Connected, Vlan2

Switch-B

router eigrp 42

network 10.10.10.0 0.0.0.3

network 10.10.20.0 0.0.0.3

network 192.168.11.0 0.0.0.255

network 192.168.12.0 0.0.0.255

network 111.111.111.192 0.0.0.63

eigrp router-id 111.111.111.193

EIGRP-IPv4 Topology Table for AS(42)/ID(111.111.111.193)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

       r - reply Status, s - sia Status

P 111.111.111.192/26, 1 successors, FD is 2816

        via Connected, Vlan30

P 222.222.222.192/26, 1 successors, FD is 3072

        via 10.10.10.1 (3072/2816), Vlan10

        via 10.10.20.1 (286976/2816), Tunnel1

P 192.168.1.0/24, 1 successors, FD is 3072

        via 10.10.10.1 (3072/2816), Vlan10

        via 10.10.20.1 (286976/2816), Tunnel1

P 192.168.2.0/24, 1 successors, FD is 3072

        via 10.10.10.1 (3072/2816), Vlan10

        via 10.10.20.1 (286976/2816), Tunnel1

P 10.10.20.0/30, 1 successors, FD is 286720

        via Connected, Tunnel1

P 10.10.10.0/30, 1 successors, FD is 2816

        via Connected, Vlan10

P 192.168.11.0/24, 1 successors, FD is 2816

        via Connected, Vlan1

P 192.168.12.0/24, 1 successors, FD is 2816

        via Connected, Vlan2

Bronze

Re: eigrp and GRE tunnels

This still doen't provide any output pertaining to the routing for the tunnel endpoints with the vlan down. I'm guessing that with the vlan down, the tunnel itself is down and EIGRP is unable to form peers. Can you ping the tunnel source and destination on both switches with the VLAN down? 

BTW, please don't feel insulted when folks ask for more data in order to make a guess.  My ability to give you a good answer is directly based on my understanding of the situation, and without real data it's impossible for me to know what is going on.  I appreciate your 25 years of experience and am not trying to disparage your capabilities.  I just don't know how to troubleshoot without information.

(And just so you know, I've been troubleshooting networks now for 35 years and have spent 18 years at Cisco including 11 years as an EIGRP developer.  My questions are not intended to be insulting or frivolous.)

New Member

Re: eigrp and GRE tunnels

I'm really glad to hear about how long you've been doing this, finally someone you knows the difference between an interface and a port (despite how they are using interchangably now days).

Since all interfaces on these switches are vlans, I'm assuming you're reffering to vlan10 which connect to either end of the carrier provided QnQ circuit. Whenever a problem has occured vlan10 stays up but no traffic is passed (carrier issue someplace), and eigrp look just as it would if was receiving nothing. BUT, the gre is still up and passing traffic. I've confirmed this with both a ping, as well as, traffic that always goes over the gre (directed via route-map) continues uninterupted.

At first I thought eigrp wasn't going over the gre tunnel, and the results certainly look like this could be the problem, but the topology does show two potential paths;

P 192.168.1.0/24, 1 successors, FD is 3072

        via 10.10.10.1 (3072/2816), Vlan10

        via 10.10.20.1 (286976/2816), Tunnel1

Is there a better, more accurate, way to determine if eigrp is going over the gre? I know when the primary path is out of service I lose all my eigrp, so again it looks like eigrp isn't going over the gre....but the topology says....

BTW I'm absolutly certain the gre is up, I was able to add static routes when the primary path was down and all the traffic went over the gre just fine.

Hmmm...does the public interface the gre goes over need to be in the eigrp config as well? If so I'd have to make sure that both ends only allowed/sent eigrp to the other end and not to the internet in general. What do yoiu think?

Bronze

Re: eigrp and GRE tunnels

When VLAN 10 goes down or is not passing traffic, do you see the peer go down through VLAN 10 and the peer stay up through the tunnel interface? 

As for how to tell if EIGRP going across the tunnel, you can do "debug eigrp packet" (or some subset of EIGRP packets, such as HELLOs, etc.) to see if communications are continuing properly with VLAN10 down.  Also my question above about the peer relationship will tell you if at least the multicast hello packets are being exchanged.

As for your last question about the public interface needing to be in EIGRP, the answer should be no.  Whatever technology is used to advertise the tunnel endpoints so the tunnel can be established is independent of the EIGRP peer relationship and routing updates sent across the tunnel.

I also realized that we may be having a communications problem ourselves.  Just for clarity, when I say tunnel endpoints, I'm not talking about the IP addresses assigned to the tunnel interface.  The tunnel itself has a source and destination address for the tunnel creation, then the defined tunnel IP addresses are applied to the tunnel interface created and used for EIGRP to form peers and send updates.

Silver

Re: eigrp and GRE tunnels

Please post some EIGRP debugs taken when primary path goes down

I would check the GRE transfer for large packets too, there might be an MTU issue when HELLOs get through but large packets not.  Please post your tunnel interface config. What is the achievable MTU via the path? Do you also have IPsec encapsulation involved?

You mention a route-map that directs traffic to tunnel. Let's see that config part too.

I'm wondering whether we should boycott further assisting without seeing the anonymized config and the routing table and the logs.

New Member

Re: eigrp and GRE tunnels

I'm working on getting the debugs with the primary path down, not that easy since it's in constant use and it's not really a situation where I can just take it down.

Peter, no one has any obligation to help anyone else. This is a community site and personally I feel the very idea of "boycott"ing anyone for any reason, other than being verbally abusive, is contrary to the community idea. Please note that this is what "I feel", I never pretend to know what others are thinking or their intent. Don't let the small numbers of my posts on this site fool you, I've been helping others (peers and new) since before there was a web, anyone remember FidoNet.

Anonymizing an 800+ line config while being sure it's still consistent isn't fun. I'm trying to post everything relavent without causing confusion, or jepordizing security. And I think I'm doing pretty good given that 90% or more of the config is irrelavant, still I'll be posting more.

I think Donald is right, in that I really can't confirm that there are eigrp HELLOs getting through on the secondary when the primary is down, although I can't see why this would happen, I also can't prove it's not happening. I'm assuming the HELLOs are getting through on the secondary when the primary is up only because the topology shows two paths. Is it possible that it's learning of the second path via the eigrp exchange on the primary path, I would think not, but it would explain what I'm seeing.

I kind of dought there is an MTU issue. The HELLOs are either not going through or are being ignored. Keep in mind that by adding a static route, traffic over the GRE works fine. This would have no affect on frame size. The tunnel is also set with an "ip mtu 1400".

I'm hoping to grab some time Monday night to get the debugs.

New Member

Re: eigrp and GRE tunnels

Just FYI, this is with both paths up

debug eigrp packet hello from switch-A

Sep 13 18:05:11.625: EIGRP: Sending HELLO on Vlan10

Sep 13 18:05:11.625:   AS 42, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0

Sep 13 18:05:12.682: EIGRP: Sending HELLO on Tunnel1

Sep 13 18:05:12.682:   AS 42, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0

Sep 13 18:05:13.613: EIGRP: Received HELLO on Tunnel1 nbr 10.10.20.1

Sep 13 18:05:13.613:   AS 42, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

Sep 13 18:05:14.728: EIGRP: Received HELLO on Vlan10 nbr 10.10.10.1

Sep 13 18:05:14.728:   AS 42, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

debug eigrp packet hello from switch-B

Sep 13 18:05:13.612: EIGRP: Sending HELLO on Tunnel1

Sep 13 18:05:13.612:   AS 42, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0

Sep 13 18:05:14.728: EIGRP: Sending HELLO on Vlan10

Sep 13 18:05:14.728:   AS 42, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0

Sep 13 18:05:16.372: EIGRP: Received HELLO on Vlan10 nbr 10.10.10.2

Sep 13 18:05:16.372:   AS 42, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

Sep 13 18:05:17.337: EIGRP: Received HELLO on Tunnel1 nbr 10.10.20.2

Sep 13 18:05:17.337:   AS 42, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

Bronze

Re: eigrp and GRE tunnels

Traceroute from tunnel end-point to tunnel end-point to see how the tunnel travels

New Member

Re: eigrp and GRE tunnels

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.

Bronze

Re: eigrp and GRE tunnels

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.

New Member

Re: eigrp and GRE tunnels

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.

Bronze

Re: eigrp and GRE tunnels

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.

New Member

Re: eigrp and GRE tunnels

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.

Bronze

Re: eigrp and GRE tunnels

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.

Silver

Re: eigrp and GRE tunnels

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?

New Member

Re: eigrp and GRE tunnels

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.

5373
Views
15
Helpful
22
Replies