Eigrp neighbours not on common subnet for vlan

Answered Question
Sep 1st, 2010

Hi All,

we are using one cisco 4507 in our network as core. some vlans are created on that and EIGRP is running on that. now I am getting one error message that says " IP-EIGRP(Default-IP-Routing-Table:1): Neighbor 10.2.4.251 not on common subnet for Vlan20 " and " IP-EIGRP(Default-IP-Routing-Table:1): Neighbor 10.2.20.251 not on  common subnet for Vlan4".

while 10.2.4.251 is ip address on interface vlan 4 and 10.2.20.251 is interface vlan ip for vlan 20

Can anyone please suggest any resolution for this.

Thanks

Correct Answer by Giuseppe Larosa about 6 years 5 months ago

Hello Sharma,

someone may have joined broadcast domains Vlan 20 and Vlan 4.

EIGRP messages have a multicast destination both at Layer3 and at Layer2 so the switch is receiving on vlan 20 its own hellos sent in vlan 4 and viceversa.

if CDP is enabled looks for CDP messages in log messages specially for native vlan-id mismatch also on access layer switches to find the unwanted connection.

Or from an host on vlan4 make an ARP request and look for host's MAC address in Vlan 20 CAM table if you find it you have confirmation of above and looking for the port where the MAC address is learned you can find the unwanted connection.

Or it could be sign of bridging loop but it would cause network performance to drop down.

Hope to help

Giuseppe

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Federico Coto F... Wed, 09/01/2010 - 08:31

Hi,

Who is the 4507 peering to? (from EIGPP perspective).

You're saying that the 4507 has the following:

interface vlan 4

ip add 10.2.4.251

interface vlan 20

ip add 10.2.20.251

Please explain.

Federico.

Correct Answer
Giuseppe Larosa Wed, 09/01/2010 - 12:23

Hello Sharma,

someone may have joined broadcast domains Vlan 20 and Vlan 4.

EIGRP messages have a multicast destination both at Layer3 and at Layer2 so the switch is receiving on vlan 20 its own hellos sent in vlan 4 and viceversa.

if CDP is enabled looks for CDP messages in log messages specially for native vlan-id mismatch also on access layer switches to find the unwanted connection.

Or from an host on vlan4 make an ARP request and look for host's MAC address in Vlan 20 CAM table if you find it you have confirmation of above and looking for the port where the MAC address is learned you can find the unwanted connection.

Or it could be sign of bridging loop but it would cause network performance to drop down.

Hope to help

Giuseppe

sharma16031981 Fri, 09/03/2010 - 05:04

Hi Giuseppe

I got the systems in the network where they were throwing native vlan mismatch after resolving there was no log in core switch now.

Thanks,

Hemant

Actions

This Discussion