1. Home
  2. Cisco Systems
  3. Multiple router eigrp 65536 - can't delete or edeit

Multiple router eigrp 65536 - can't delete or edeit

A brief summary of the problem.

I have a Catalyst 6506, running IOS 12.2(18) with multiple VRFs configured. One interface (through which it is managed) is on the default VRF, and all other interfaces are on one of the named VRFs. The switch currently is the only router on each of the environments it supports, but I have been tasked with extending the environments across a MAN to another data centre.

VRFs are configured as simply as can be:

ip vrf DEV rd 3:3 ! ip vrf ITF rd 2:2 ! ip vrf TPF rd 1:1

Interface configs are also pretty simple.

interface Vlan13 description DEV-Intel ip vrf forwarding DEV ip address 172.16.85.254 255.255.255.0 ! interface Vlan14 ip vrf forwarding DEV ip address 172.16.86.254 255.255.255.0 ip helper-address 172.16.85.2 ip helper-address 172.16.85.14 ip helper-address 172.16.85.23

The problem is that whenever I enter the command "router eigrp 65535" a new "router eigrp 65535" section is created. I now have 12:

router eigrp 65535 ! router eigrp 65535 no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp auto-summary ! address-family ipv4 vrf DEV no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp network 172.16.84.0 0.0.3.255 auto-summary exit-address-family ! router eigrp 65535 no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp network 172.16.84.0 0.0.3.255 auto-summary ! router eigrp 65535 no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp auto-summary ! router eigrp 65535 no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp auto-summary ! router eigrp 65535 no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp auto-summary ! router eigrp 65535 no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp auto-summary ! router eigrp 65535 no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp auto-summary ! router eigrp 65535 ! router eigrp 65535 no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no auto-summary ! router eigrp 65535 no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp auto-summary ! router eigrp 65535 no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp no redistribute eigrp auto-summary !

I cannot remove any of them with the commend "no router eigrp 65535.

If I create an eigrp process with anothe AS number, (e.g. 65534) it behaves normally, but we are using eigrp 65535 internally, and I don't want to change it - and anyway, even if I did, I can't remove the address-family ipv4 vrf DEV section, because I can't access the original router clause to change it.

Any suggestions will be gratefully received. I'm totally stumped, and have not turned up anything like it on CCO or Google.

Reply to
David Haggett
Loading thread data ...

If you have not saved the configuration can try to reload

Reply to
MC

Unfortunately someone else has saved the config - plus although it is a non-production environment, it is in constant use.

Reply to
David Haggett

open a case with the Cisco TAC

Reply to
Merv

You should be able to change the startup config by copying a new one on with tftp (or ftp or whatever). This replaces the existing config file. By default they use unix new-lines and I have not been brave enough to try with windows new-lines.

I use Windows, so the last time I did this I used unix2dos and dos2unix from Cygwin to convert the formats and edited with Notepad.

Reload, done.

Reply to
Bod43

I will do - when I return from leave. It ain't hurting anyone at the moment, and my boss and team are aware.

Reply to
David Haggett

Also works if you edit the text file in wordpad, or there used to be a java based text editor (Arachnophilia?) which lets you choose between windows or unix style line ends.

Except of course I actually do want to make the config work, so just going back to where I was before is only half the story. I will raise a TAC case when I get back from vacation.

Thanks for all who responded with advice.

Reply to
David Haggett

I try to avoid using unusual parameters in router configs. For example when writing software the test cases that I would use would usually be the largest, the smallest and maybe a few in between. Extreme values are often where the logic of programs is incorrect. Additionally , many thousands of users have 'tested' eigrp with the process id's of one, two,

100, 200, I guess, but how many have used 65535?

I think that I might have avoided using eigrp process ID 65535 if I had ever used eigrp in anger. Why not keep it under 32766 too and thereby avoid any potential signed/unsigned bugs (and avoiding 32767 too).

For example - I have recently been doing an OSPF design that needed non-default link costs. One of the decisions that I have made is to _avoid_ our OSPF costs ever reaching the maximum value allowed - 65535 (IIRC). I just see no point it being that kind of pioneer on a production network.

Reply to
Bod43

I sort of get your point, but you are the first person I've encountered who's ever suggested this as a valid philosophy. I'm not sure I agree with the logic that 65535 is more susceptible to buggy code than 1, and I definitelely don't agree with the suggestion that I should abitrarily exclude the use of potential parameters "just in case". What if I should exclude the wrong one?

Incidentally, we have been using 65535 as our EIGRP AS number for at least

5 years, and never encountered any problems. Several "experts" have looked at our WAN/LAN infrastructure as part of the normal review process, and none have commented on the unusualness of the number.

If the bug does turn out to be related to the use of 65535, but can be remedied by upgrading the IOS to a version without the bug, does this still mean I should't use it because there may be another bug?

Reply to
David Haggett

Using 65535 as an EIGRP AS number should NOT be a problem.

What image is being used - post output of show version

The following 12.2 images have been yanked:

12.2.18-SXD3 (DF) 12.2.18-SXD2 (DF) 12.2.18-SXD1 (DF) 12.2.18-SXD (DF)
Reply to
Merv

Thanks for confirming.

Funnily enough, I think it is 12.2.18-SXD, but I'll have to check when I get back to work - sad, because I think we standardised images on all the devices to that software - so we'll have to upgrade the entire production core before we can proceed with the changes.

At least we know now _before_ we've started to implement (what labs are for I suppose).

Reply to
David Haggett

Picking a new IOS image for the 6500 can be a pick tricky.

Make sure you go thru the release notes for any new target release very carefully.

When I did a CCO search there are numerous EIGRP bugs listed for

12.2(18)
Reply to
Merv

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.