Consider the following statement from Cisco.com : “Routers do not form EIGRP neighbors over secondary networks.”
A Routing-BitsHandbook candidate queried this last week, claiming the statement is misleading and that EIGRP will indeed form an adjacency using a secondary IP address under specific conditions.
Consider the following configuration. R1 connects to R2 using a back-to-back serial connection. Both S1/1 interfaces have a primary and a secondary IP address defined. The EIGRP processes only matches the secondary IP addresses.
R1# interface Serial1/1 ip address 10.1.1.1 255.255.255.0 secondary ip address 10.5.1.1 255.255.255.0 ! router eigrp 1 network 10.1.1.1 0.0.0.0 no auto-summary R2# interface Serial1/1 ip address 10.0.1.2 255.255.255.0 secondary ip address 10.5.1.2 255.255.255.0 ! router eigrp 1 network 10.0.1.2 0.0.0.0 no auto-summary
So what do you think will happen in this scenario? Will R1 and R2 become adjacent? Cisco explicitly mentions that a secondary IP address is not used in the EIGRP hello packets, therefore EIGRP neighbors will not become adjacent using secondary IP addresses.
In the example above R1 and R2 will definitely become EIGRP neighbors!! Huh? But you said? WTH? This is one of those unique cases where you have to look very carefully at the wording and understand what happens behind the scenes to summize what is really going on.
Look at the “debug ip packet” output on R1 during the neighbor establishment.
* IP: s=10.5.1.1 (Serial1/1), d=224.0.0.10, len 60, rcvd 2 * IP: s=10.5.1.1 (Serial1/1), d=224.0.0.10, len 60, rcvd 2 * IP: s=10.5.1.2 (local), d=224.0.0.10 (Serial1/1), len 60, sending broad/multicast * IP: s=10.5.1.2 (local), d=10.5.1.1 (Serial1/1), len 40, sending * %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.5.1.1 (Serial1/1) is up: new adjacency
Look at the first hello packet that leaves R1, it has a source of 10.5.1.1, (the primary address/no matching network statement). Same when R2 acknowledges, it replies with a source of 10.5.1.2 (the primary address/no matching network statement).
Consider what the network statement with EIGRP does. It says enable sending hello packets out an operational interface, if that interface has an IP address configured which is matched by one of EIGRP network statements. This is standard behavior to discover other EIGRP neighbors. In this unique scenario both Serial1/1s will start sending hello packets, since both interfaces have matching EIGRP network statements, the secondary IP addresses. When the Hellos are crafted and send out the EIGRP enabled interfaces, by Cisco’s rules, the source IP address of the packets are the primary IP address on the egress interface, and not the secondary IP addresses. Given that R1 and R2 primary IP addresses are on the same network, they have no problem becoming adjacent. If R1 and R2 primary IP addresses were on different subnets, you would receive an ‘Inconsistent IP address’ error.
So technically this EIGRP neighbor relationship was not setup using the secondary addresses. Both R1 and R2 used the primary addresses on interfaces that were enabled for EIGRP.
So would you agree then that the statement then is not misleading, ” EIGRP does not establish adjacencies on secondary network IPs”.
Routing-Bits 
I don’t agree that Cisco’ statement in misleading. It says that don’t expect to match the secondary address on the interface between routers and expect adjacency.
what will be the output of the “sh ip eigrp neighbour” ?
Dont be lazy now. The config was provided. Copy/paste and see the output. :)
I don’t thinks it’s misleading, i think if you look at the adjacency you’ll see the primary addresses for each neighbour. What would solidify Cisco’s statement would be is you had no multicast and had to configure the neighbours manually with the neighbour statement. In this case the adjacency would not form because the unicast hello’s are directed towards the secondary address of the remote peer but it will reply with it’s primary.
That’s how I see it anyway…!!
In EIGRP putting network statement will not work unless its not in the local interface, EIGRP advertise the interface not network, and putting the network statement with wild mask its matches the existing interface to participate, in above case network statement are the secondary IPs of interface but its include the interface itself, once interface added to eigrp process its start sending the control msg to build the neighbor relationship.
its corect