EIGRP funny

j-stead · ‎09-16-2002

Sorry for the long post.....

Here we go.....Just wondering if anyone has seen the following behavior before in an EIGRP environment. I have 2x 3640's in the core talking to each other via MLPPP. 4Mb G.703(2x 2Mb)microwave link via VWIC-2MFT-G703 hardware. The entire network is 10.0.0.0 network (40 routers) with a very basic EIGRP setup. eg router eigrp 1.....network 10.0.0.0...no auto. no distro-lists or passive ints.

The multilink interfaces for the link are addressed 10.0.11.1/24(R1) and 10.0.11.2/24(R2), nothing tricky here...the problem is that the routers attached to this link do not advertise their local interface address via EIGRP to their first hop neighbours. They do, however, pass on the address of the links other end. eg. R1, ML interface address 10.0.11.1, will not advertise this address to neighbouring first hop routers, but will tell them about 10.0.11.2 being the other end of the link(R2). The same (but reversed) is happening on R2 end. As a result, traffic destined for these interfaces go via a less desirable path. I don't believe this is not a metric thing. The address of the interface is not passed at all, but all other routes are. With a "sh ip eigrp top" command on a neighbouring router, 1 hop from R1, you can see 10.0.11.0/24 via R1, 10.0.11.2/32(R2) via R1 but 10.0.11.1(R1's multilink int address) via another site, that does infact eventually get there across about 4 hops. As this update is 10.0.11.1/32, it is a longer match than the 10.0.11.0/24 reported by R1, so it installs the less efficient route.

I was not an issue in the past when the link was a single 2Mb leased line with address on the physical interface. It is a problem with our NMS as it is attempting to poll the interface address, and as we have multiple redundant paths in the network, this traffic takes less desirable routes to the destination and experiences latency resulting in NMS false positives.

Bug(CSCdk80809) seems to relate to this problem and as I have tried almost everything else, I have upgraded both routers to the recommended version 12.2(7c) but still have the issue...this problem could be resolved with static routes and distro-lists, but I believe I may just cover up an undelying problem and compromise the dynamic nature of this protocol.

Any ideas?

Jason.

i.fouraki · ‎09-18-2002

Hi,

do you see this ip as connected in your RT? Do you use redistribute connected?

Yanna

jcmartin · ‎09-19-2002

A router should not be advertising a connected route out the connected interface, but it should advertise it out all other interfaces. And since the interface is in the range defined by the network statement under eigrp, it shouldn't require redistribute connected. But, since this is a multipoint interface, it may be a split horizon issue. Try disabling split horizon on the multipoint interfaces and see if your problem goes away.

j-stead · ‎09-24-2002

The resolution I have configured to help resolve this issue is that I have configured a distribute list on R1 and R2 to prevent them from advertising the /32 addresses of the link interfaces. This way, the only update propagated for the link is the full /24. This seems to works fine. And still maintains a level of dynamics in the routing protocol.

Jason.

j-stead · ‎09-19-2002

Thanks Yanna,

Yes it does appear at a dirrectly connected route. But, I should not have to "redis connected" for this route to propagate through the network as it is covered in the EIGRP network statement. But yes I have tried this and it did not fix the issue. Thanks very much for your comment.

Jason.