1. Home
  2. Cisco Systems
  3. HSRP neighbors confusion

HSRP neighbors confusion

My MSFC has been reporting an issue with HSRP for the past few days. Seeing the following:

33w6d: IP-EIGRP: Neighbor 10.73.136.2 not on common subnet for Vlan158 (10.73.65.3 255.255.255.0) 33w6d: IP-EIGRP: Neighbor 10.73.65.3 not on common subnet for Vlan17 (10.73.136.3 255.255.248.0) Jan 10 15:02:48: %STANDBY-3-BADAUTH: Bad authentication from 10.73.65.2, remote state Standby 33w6d: IP-EIGRP: Neighbor 10.73.136.2 not on common subnet for Vlan158 (10.73.65.3 255.255.255.0) 33w6d: IP-EIGRP: Neighbor 10.73.65.3 not on common subnet for Vlan17 (10.73.136.3 255.255.248.0) 33w6d: IP-EIGRP: Neighbor 10.73.136.2 not on common subnet for Vlan158 (10.73.65.3 255.255.255.0) Jan 10 15:03:19: %STANDBY-3-BADAUTH: Bad authentication from 10.73.136.2, remote state Active

I know what everyone will say "Check authentication". Been there done that.

Topology:

2 Cat6509s. Each with dual Supervisor/MSFC modules. Both switches connect together via Etherchannel. HSRP Vlan peers are setup where peer 1 is in Switch/MSFC-1 and peer 2 is in Switch/MSFC-2.

MSFC configuration: Compared running and starting configuration on both MSFCs. IP addressing and HSRP authentication are correct.

MSFC-1

---------- interface Vlan17 ip address x.x.17.130 255.255.255.0 secondary ip address 10.73.136.2 255.255.248.0 no ip redirects no ip unreachables ip pim version 1 ip pim sparse-mode standby 1 timers 5 15 standby 1 priority 110 preempt standby 1 authentication vlan17 standby 1 ip 10.73.136.1 standby 1 ip x.x.17.129 secondary

interface Vlan158 ip address x.x.158.2 255.255.255.0 secondary ip address 10.73.65.2 255.255.255.0 no ip redirects no ip unreachables ip pim version 1 ip pim sparse-mode standby 1 timers 5 15 standby 1 priority 110 preempt standby 1 authentication vlan158 standby 1 ip 10.73.65.1 standby 1 ip x.x.158.1 secondary end

MSFC-2

----------- interface Vlan17 ip address x.x.17.131 255.255.255.0 secondary ip address 10.73.136.3 255.255.248.0 no ip redirects no ip unreachables ip pim version 1 ip pim sparse-mode standby 1 timers 5 15 standby 1 priority 100 preempt standby 1 authentication vlan17 standby 1 ip 10.73.136.1 standby 1 ip x.x.17.129 secondary end

interface Vlan158 ip address x.x.158.3 255.255.255.0 secondary ip address 10.73.65.3 255.255.255.0 no ip redirects no ip unreachables ip pim version 1 ip pim sparse-mode standby 1 timers 5 15 standby 1 priority 100 preempt standby 1 authentication vlan158 standby 1 ip 10.73.65.1 standby 1 ip x.x.158.1 secondary end

====================================

My question is why is my Vlan 17 neighbor trying to authenticate with my Vlan 158 neighbor according to the syslog message? I believe this is why the authentication message appears. These messages are only occurring on 1 of the MSFCs.

Thanks in advance.

Reply to
brickwalls19
Loading thread data ...

I guess it could all be down to some weird bug or other however the most reasonable explanation is that your VLANs (17 and 158) have been connected together.

Anyone done any patching recently? Alternative explanation could be missmatched native vlans in trunk or maybe a SPAN session piping the traffic between vlans.

I would suppose that the other switch should be seeing these messages too. Maybe logging is configured differently.

it seems that you have some eigrp debug running on one switch anyway.

serv timestamps debug uptime serv time log datetime

sh cdp neighbour would be one place to start. sh mac-a may help you to track down the interconections

Reply to
Bod43

Create "standby" on the different HSRP groups. For example:

interface Vlan17 ... standby 1 ... standby 1 ip 10.73.136.1 standby 1 ip x.x.17.129 secondary

interface Vlan158 ... standby 2 ... standby 2 ip 10.73.65.1 standby 2 ip x.x.158.1 secondary

In this case HSRP neighbors will not mix VLANs.

Good luck,

Mike

------ Cisco IP Phone Mobile Hands-Free Adapters

formatting link

Reply to
headsetadapter.com

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.