EIGRP route advertisements not making it to ASA 5510

[sawyertech]

We are deploying a new office in the building next to our main office.  The main office has a Cisco ASA 5510 behind that is a Cisco 3750 stack. In the new office we are deploying a new Cisco 3750, they will be connected via fiber cable.  I have sliced off VLAN 800 as a transit link /30 with an address space of 10.249.249.1-4. 

The new 3750 only has two VLAN's 800 and 112 (10.112.0.0/24).  VLAN 112 routes are advertised to the neighboring 3750 properly as seen in the routing tables of the 3750 stack:

D       10.112.0.0/24 [90/3072] via 10.249.249.2, 00:22:24, Vlan800

Traffic passes between all local VLANS with no issue.  I found in order to get packets to pass between the ASA and the new 3750 I had to add a static route to the ASA:

S    10.112.0.0 255.255.255.0 [1/0] via 10.100.0.1, inside

My question is why is EIGRP not advertising the 10.112.0.0 network to the ASA.  Here are EIGRP configs on the switches

Existing 3750 Stack

router eigrp 100

network 10.0.0.0

redistribute static

eigrp stub connected summary

New 3750 Stack

router eigrp 100

redistribute connected

eigrp stub connected summary

network 10.0.0.0

I have tried to use the redistribute connected/static on both 3750's to no avai.  Any tips or hints?

[Reza Sharifi]

My question is why is EIGRP not advertising the 10.112.0.0 network to the ASA.  Here are EIGRP configs on the switches

Is the firewall running EIGRP too?

If not, than that is why you need a static route on the firewall.

HTH

[Richard Burts]

Fred

I believe that the explanation of the issue is found in this:

Existing 3750 Stack

router eigrp 100

eigrp stub connected summary

The use of EIGRP stub says that the existing 3750 stack will advertise its own routes to both of its neighbors, but that it will not advertise routes from one of its neighbors (the new 3750 stack) to its other neighbor (the ASA).

To get advertisements from the new 3750 stack to be advertised through the existing 3750 stack to the ASA you will need to remove EIGRP stub from the existing stack.

HTH

Rick

[Peter Paluch]

Hello Rick,

I also believe that the EIGRP Stub feature is the reason. Perhaps the EIGRP stub should not be deconfigured per se, but rather, a leak-map should be configured to allow a particular route to be advertised even from a router that is configured as a stub.

I have found Ivan Pepelnjak's articles about EIGRP Stub to be more descriptive than the official Cisco docs, so here's the link:

http://www.nil.si/ipcorner/eigrpstub/#chapter3

Best regards,

Peter

[Richard Burts]

Peter

It is a very interesting article, and I agree that Ivan frequently is the source of very good insight. +5 for sharing it with us.

I do not have much experience with leak map and therefore it was not high on my list of priorities. It looks like it would solve the issue of advertising 10.112.0.0 to the ASA. I am still not convinced that it is a complete solution. When we configure an EIGRP participant as stub we are asserting that there is no routing activity behind it. And that is not the case in the main office 3750 stack. One part of being EIGRP stub is that the main office 3750 stack will not advertise to the new 3750 any routes that it has learned dynamically via EIGRP. If there are no other EIGRP routes being learned then the leak map would be effective for this implementation. If there are any other EIGRP routes then I stand by my original suggestion to remove EIGRP stub from the main office 3750 stack.

HTH

Rick

[sawyertech]

Guys thank you for the feed back!

Before I forget here is the config on the ASA:

router eigrp 100

network 10.0.0.0 255.0.0.0

passive-interface outside

passive-interface bandwidth.com

redistribute static

I recently took over this role and my predisesor mentioned the stub command showed up after an IOS upgrade.  Before adding this new office the network was a stub.  Research on the Stub command recommend that tying "redistribute connected' vs 'redistribute static' command which did not seem to have any effect. 

http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/eigrpstb.html

Going to try remvoing the stub command after hours and see what happens.  This might also explain why I had to use the stub command on the new office 3750 for the 10.112.0.0 network to be advertised to the stack.  I found it odd that I had to put that command in and wondered why EIGRP didn't just advertise the network space.

I will report back my findings soon.  Thanks again everyone.

[sawyertech]

So I found out why the stub command is in place. 

(config-router)#no eigrp stub connected summary

EIGRP is restricted to stub configurations only on this platform.

Didn't see that coming.

Cisco IOS Software, C3750 Software (C3750-IPBASEK9-M), Version 12.2(55)SE4, RELEASE SOFTWARE (fc1)

Technical Support: http://www.cisco.com/techsupport

Copyright (c) 1986-2011 by Cisco Systems, Inc.

Compiled Tue 06-Sep-11 02:59 by prod_rel_team

Image text-base: 0x01000000, data-base: 0x02D00000

ROM: Bootstrap program is C3750 boot loader

BOOTLDR: C3750 Boot Loader (C3750-HBOOT-M) Version 12.2(44)SE5, RELEASE SOFTWARE (fc1)

stack01 uptime is 20 weeks, 1 day, 20 hours, 28 minutes

System returned to ROM by power-on

System image file is "flash:/c3750-ipbasek9-mz.122-55.SE4.bin"

[Richard Burts · Accepted solution]

Fred

I did not see that coming either (but perhaps I should have). The IP Base feature set on these switches gives only a very restricted implementation of EIGRP.

So I can think of a couple of alternatives that could help you solve this issue:

- upgrade the feature set of the software to a feature set that gives the full implementation of EIGRP.

- trunk VLAN 112 from the new office 3750 to the main office 3750, configure interface VLAN 112 on the main office 3750, and have the main office route for that subnet (and for this solution you do not need VLAN 800 as a transit VLAN.

HTH

Rick

[sawyertech]

Thank you everyone for the input.  Due to my deployment timeframe of the new office I don't have enough flexiblity to run an IOS upgrade.  So for now I took Richard's advice and simply turnked the ports. 

I do have one follow up question.  I have run IOS upgrades on switches before but the cluster in question has a VM Farm running on it which is very critical to the opperation of the company.  Has anyone ever experianced configuration issue's when running a IOS upgrade on a stack before?

Thanks again,

Frederick Sawyer

[Richard Burts]

Fred

Many of us have run into configuration issues when running IOS upgrades. They are not common but they do happen, usually when there is some new feature introduced which impacts existing implementations, or because there are changes in syntax for existing features. They are probably more common when you are updating to new major releases and less common when upgrading to a maintenance release within the same major release. If you are concerned about this I would suggest a close reading of the release notes for the new release.

I am glad that my suggestion did point the way to a solution for your issue. Thank you for using the rating system to mark this question as answered. It makes the forum more useful when people can read a question and can know that a solution was found. Your marking has contributed to this process.

HTH

Rick