EIGRP multicast failure unidirectional

[j.england]

Hi all,

This issue is a bit confounding for me, but hopefully simple for one of you.  I have two sites, one in Alaska and one in California, connected via 10mb QinQ service from an ISP in Alaska.  The ISP is utilizing Verizon from Seattle south who is delivering the circuit on a DS3 here in California.  The ISP gear on site here is a Tasman.  The Tasman is directly connected to a Cisco 3845 G0/1 with a routing subinterface.  In Alaska, the ISP is directly connected to a 6513 which in turn is connected to a 7206 with a routing subinterface.  I cannot seem to get the 7206 and 3845 to come up as neighbors.

The 7206 receives the 3845's Hello and the 7206 shows the 3845 as a neighbor until the hold time expires.  It does not see updates from the 3845 since the 3845 never sees a Hello from the 7206 and comes up as a neighbor to send an update.  The 3845 does see EIGRP updates from the 7206, but no Hello.  Pinging 224.0.0.10 from the 7206 does not get a response from the 3845, but it does get a response from many other sites/neighbors, including another site here in California with a nearly identical setup (same provider and gear).  I am ableto ping between the devices' routing interfaces.  Being QinQ, I don't believe the ISP could possibly be the issue (the circuit is clean and stable) as they don't filter any of our packets.  There are no ACLs applied to these interfaces.  The 3845 does have other EIGRP neighbors from sites over a TLAN around here in SoCal.

Any ideas why the Hellos may not be reaching the 3845?  I have verified they're being sent from the 7206.

Thanks in advance, and please let me know if there is any other information I can provide.

Justin

[Phillip Remaker]

Sounds like a unidirectional multicast issue.

Hellos are unicast.  Updates are too, but updates will be unicast to known end nodes that do not acknowledge the mutlicast.  So it sounds like a service provider issue.

As a workaround, you can set static neighborship between the two devices, if they are the only two devices in that broadcast domain (since setting up a static neighbor disables the multicasting)

See: http://www.cisco.com/en/US/tech/tk365/technologies_q_and_a_item09186a008012dac4.shtml#nine

[j.england]

Phillip, thank you very much for the response.  I was under the impression the initial Hello was multicast.  This would explain why one device never comes up as a neighbor since it doesn't receive any multicast traffic from the Alaska side (on that subnet), but why it does see unicast Updates and display that the "neighbor is unknown" in the debug.  I of course defer to your experience and knowledge, as I'm a novice.  But now I don't have nearly the grip on the issue that I thought!  It at least made sense to me before, where as it now confounds me far further.  I did find this, hence my misunderstanding:

"For example, on a multi-access network that has multicast capabilities, such as Ethernet, it is not necessary to send hellos reliably to all neighbors individually. So EIGRP, sends a single multicast hello with an indication in the packet informing the receivers that the packet need not be acknowledged. Other types of packets, such as updates, require acknowledgment and this is indicated in the packet. The reliable transport has a provision to send multicast packets quickly when there are unacknowledged packets pending. This helps insure that convergence time remains low in the presence of varying speed links."

From: http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093f07.shtml

Oh, and thank you very much for the link.  I had considered creating a static neighbor relationship, but I was hoping to resolve the issue without having to configure that, as it is merely a bandage in this case.

If your're still of a mind that it's provider issue, might you have any pointers I can provide to them for troubleshooting?  They've stated they've checked everything possible, and since it is QinQ neither of us really know what might be causing filtering of one type of traffic within our packets.

Thanks agaqin for your response and time!

[j.england]

Something else interesting to note:  We have another circuit that terminates in this 3845 (after passing through a 3750 stack) that also seems to be having EIGRP issues.  However in this case, the neighbors successfully come up, but no Updates are received by the other sides.  The Alaska side is terminated in another 7206 at a different site.  So it seems for that link, only multicast is working.  Very frustrating.  I may open a TAC case on this, but any assistance in the mean time would be very much appreciated.

[Phillip Remaker · Accepted solution]

The initial hello IS multicast, but if one side receives the multicast, they can unicast the other side and form a relationship.  The unidirectionality causes interesting problems, though (as you see).

If you need to dig deeper with specific configurations, a TAC case may be the way to go.  You can use the new feature to launch a TAC case directly from the forum.

https://supportforums.cisco.com/docs/DOC-13755

[j.england]

Ah that's much more clear, thank you!  And thank you very much for the link.  I'm waiting for the service contract to get added to my CCO account for this device, so it unfortunately may be a couple of days before I can post a resolution, but your help has been valuable.

[j.england]

Just wanted to update with a resolution.  BOTH of these issues were caused by ISP telco gear.  Different ISPs, too.  One was an ADVA and one was a Nortel/Tasman.  I wouldn't have thought their gear could cause this and neither did they, especially being QinQ... but so it goes.  Don't discount anything as a possible source of a problem!