cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4804
Views
0
Helpful
16
Replies

HSRP multicast IP address

jorge.calvo
Level 1
Level 1

Hello,

IP address 224.0.0.2 is reserved for HSRP so, if I do a ping to 224.0.0.2 in a router/switch configured with HSRP only the IPs belonging to the HSRP groups should reply, I am right?

However if I ping that IP I got a SAN replying to the ping.

Could this the cause of an HSRP bouncing between standby/active/standby states?

I have discarded all physical and configuration problems I know.

Cheers

1 Accepted Solution

Accepted Solutions

If you have a smartnet contract, I suggest opening a case with TAC.

View solution in original post

16 Replies 16

lamav
Level 8
Level 8

Jorge:

[EDIT]

Where does the SAN fit into your topology?

Victor

The topology is:

CORE1---HSRP---CORE2

|

|

Switch

|

|

SAN

The problem I have is that the standby router changes to speak even though the active is up and when it notices the active is up it returns to standby state.

This problem is completely random.

Regards.

It sounds as though you are dropping HELLO packets between the core routers. If the active and standby HSRP routers fail to exchange HELLO messages for as long as the default dead timer, the active router will begin the process of going active. However, once the active and standby routers exchange their first HELLO packet, and if preemption is configured on the active router, the standby router should go back to standby.

This is what I am imagining is happening.

Can you show us an example of what is happening?

Victor

Hi,

You can try clearing ARP of the core switches. This is just a suggestion.

As correctly pointed eariler if hello's are missed, seondary router will definitely will make an attempt to become primary router. You can enable debug standy packets on both routers. Which will let you know if you are receiving hellos from neighbor. Then you can pin point the problem.

HTH

Thanks

Subodh

Edison Ortiz
Hall of Fame
Hall of Fame

Pinging 224.0.0.2 will cause a reply from all multicast capable routers, not just HSRP enabled routers.

Your HSRP instability can be attributed to a number of reasons. Can you provide portion of the config along with a small diagram of the network components on that segment?

Have you check the interfaces for errors on the HSRP device as well as the switch on which these devices are connected?

__

Edison.

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Jorge,

224.0.0.2 is not reserved to HSRP but it means all routers in subnet.

So pinging 224.0.0.2 you may see answers from devices not running HSRP.

see

http://www.iana.org/assignments/multicast-addresses/

You can check the health of HSRP communication with

sh standby brief on the core devices.

The standby protocol runs on top of UDP, and uses port number 1985.

Packets are sent to multicast address 224.0.0.2 with TTL 1.

see

http://www.faqs.org/rfcs/rfc2281.html

So the fact that another device has answered to 224.0.0.2 it is not a problem for HSRP in the subnet.

Hope to help

Giuseppe

Hello,

Thanks for all the replies. In the attachements is some log entries and configurations.

The topology is:

CORE01--Port-Channel (HSRP)--CORE02

| |

| |

SwitchA SwitchB

| |

SAN & servers Servers

There are no errors in any interface in any switch. STP is stable. No CPU or any other physical problem on the switches.

No packet loss or overload in the links (max. 5% utilization).

Any ideas?

Cheers

Sorry the topology cannot be seen properly.

It is the typical:

- 2 cores switches connected via a Port-channel running HSRP for each SVI between them.

- Cores are connected via redundant links to 2 access switches and several servers are connected to these switches.

Regards.

Jorge,

Your HSRP timers are quite aggressive and they can be the reason for the HSRP flap. Please raise the HSRP timers to msec 400 msec 1200 and see if it helps.

Hi,

This is the first thing I thought but the network has been working with this timings without any flap for more than 2 years.

And 2 days ago the problem started suddenly. Maybe I should try a reboot of both switches.

Cheers.

Could the problem be that all SVIs belong to standby group 1 although some of them have core1 as active and the other ones have core2 as the active router?

I am not sure about that because I think the HSRP group number is local to the interface only.

Any thoughts?

Regards.

I doubt the problem is related to the HSRP Group. The HSRP Group is used for the Virtual MAC and the standard virtual MAC address is used: 0000.0C07.ACxy, where xy is the group number in hexadecimal.

All that information remains within the Vlan, so there isn't any conflict with other SVIs using the same group.

__

Edison.

Thanks for you answer. We also changed the timers as you suggested, we put the default ones and even then the problem was there. Furthermore, this week the problem is constant and not random so we are thinking about reloading both switches.

Any other thing to check to avoid the reload?

Cheers.

Thanks for you answer. We also changed the timers as you suggested, we put the default ones and even then the problem was there. Furthermore, this week the problem is constant and not random so we are thinking about reloading both switches.

Any other thing to check to avoid the reload?

Cheers.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco