The main plot of the issue: (Someone else's post)
We just bought some new Cat4507R+E distribution switches. When we bought the switches, we asked for an Advanced Services K9 image, but our reseller told us they only come with a Universal K9 image. I didn't know better, so I said OK.
However, when I tried to bring the switches online in production, I had a problem with a huge number of unreachable subnets. After sweating it for a very long fifteen minutes (while my boss insulted me for not testing the switch), I finally tracked the problem down to
eigrp stub connected
in the EIGRP process.
I tried remove the "eigrp stub" statement but I couldn't. When I tried, the switch errors out with
EIGRP is restricted to stub configurations only on this platform
.
I had to roll back to our original distributions and my boss got even hotter about it.
My google searches blame this problem on the ip base license, which only supports EIGRP stub routing. Our reseller says it will take at least 24 hours and thousands of dollars to get the Advanced Services K9 upgrade. We didn't budget for the extra expense and we have other business units waiting on the upgrade. Oh yeah, and my boss isn't happy.
Before we borrow money from another department, is there anything else we can do to get this working now?
& this was the MAGIC fix
I really don't like how Cisco crippled EIGRP in the ipbase image... at a minimum, you should get some kind of warning that your configuration won't work, but they haven't done that either.
As you discovered,
eigrp stub
prevents EIGRP from advertising downstream routes from the switches connected to your distribution.
You can trick EIGRP into advertising routes it learned from other routers (even as a
stub
router) by using a stub leak-map...ip prefix-list p~MATCH_ANY seq 5 permit 0.0.0.0/0 le 32
!
route-map r~MATCH_ANY permit 10
match ip address prefix-list p~MATCH_ANY
!
router eigrp 100
no auto-summary
network 172.16.0.0
eigrp log-neighbor-warnings
eigrp log-neighbor-changes
eigrp stub connected summary static redistributed leak-map r~MATCH_ANY
Technically, you can get away with using
eigrp stub leak-map
indefinitely, without upgrading your ipbase image.
I have tried this and WORKS a treat - So well worth having this in your tool box :-) and we are now going to be running EIGRP as the protocol of choice - but only after some more testing in GNS3 :-p
Genius thanks
ReplyDeleteThis does not seem to work anymore. Maybe they blocked it in a recent IOS upgrade.
ReplyDeleteMy version is: c3560e-ipbasek9-mz.150-2.SE8.bin
Debugs show the following:
Oct 21 10:47:28.961: EIGRP-IPv4(100): Processing routemap EIGRP_STUB_FUDGE tableid:(0) map(0) for addr: 10.20.110.0/24- denied by stub
Oct 21 10:47:28.961: EIGRP-IPv4(100): table(default): 10.20.111.0/24
Oct 21 10:47:28.961: EIGRP-IPv4(100): Processing routemap EIGRP_STUB_FUDGE tableid:(0) map(0) for addr: 10.20.111.0/24- denied by stub
Oct 21 10:47:28.961: EIGRP-IPv4(100): table(default): 10.20.112.0/24
Oct 21 10:47:28.961: EIGRP-IPv4(100): Processing routemap EIGRP_STUB_FUDGE tableid:(0) map(0) for addr: 10.20.112.0/24- denied by stub
Oct 21 10:47:28.961: EIGRP-IPv4(100): table(default): 10.20.113.0/24
Oct 21 10:47:28.961: EIGRP-IPv4(100): Processing routemap EIGRP_STUB_FUDGE tableid:(0) map(0) for addr: 10.20.113.0/24- denied by stub
Oct 21 10:47:28.961: EIGRP-IPv4(100): table(default): 10.20.114.0/24
Oct 21 10:47:28.961: EIGRP-IPv4(100): Processing routemap EIGRP_STUB_FUDGE tableid:(0) map(0) for addr: 10.20.114.0/24- denied by stub
Oct 21 10:47:28.961: EIGRP-IPv4(100): table(default): 10.20.115.0/24
Oct 21 10:47:28.961: EIGRP-IPv4(100): Processing routemap EIGRP_STUB_FUDGE tableid:(0) map(0) for addr: 10.20.115.0/24- denied by stub
God bless brother
ReplyDelete