HSRP Not recognising Peer & State Change

[amarsh]

Hi all, I would like to thank you in advance for any assistance I can get with this problem.

I have been trying to implement HSRP redundancy between two routers on our network but seem to be experiencing propblems as the conversation title states above.

The 2 cust-rtr1 (3640) & cust-rtr02 (3662) are currently configured using one interface that's configured with 4 sub-interfaces for the 4 vlans. VLAN 10 is connected to the extranet backbone where customers are connected to our network.

When i tried moving vlan 32 onto a separate interface and connecting it to another switch the 2 cust-rtr01 & cust-rtr02 interfaces show as active with no known standby, plus continual state changes taking place.

So my question is this, what is the easiest way to setup HSRP between these 2 routers using the 1 pyhsical interface that represents 4 sub-interfaces and have failover perform for all sub-interfaces should int fa0/0.10 on cust-rtr01 fail?

[Richard Burts]

Anthony

I have looked at the drawing that you posted and have read the description. But I am still confused about what your problem is.

If you have configured both routers to interface to the switch trunk ports and have configured 4 subinterfaces so that you have a subinterface for each VLAN, then HSRP should be relatively straightforward. You would need HSRP on each of the subinterfaces. (Each subinterface would have its own unique IP address and would have standby ip and any other appropriate standby parameters.)

I am not clear what you are describing when you talk about attempting to move VLAN 32 onto a separate interface. Perhaps you could clarify.

Part of what confuses me about your question is that you seem to be associating HSRP with the entire interface. But HSRP would operate at the subinterface. Also the last part of your question asks how to have all subinterfaces fail over if fa0/0.10 fails. But that is not how HSRP works. If fa0/0.10 fails on router1 then that VLAN (and that subnet) should fail over. But the failure of VLAN 10 should not impact VLAN 32. HSRP should be configured on each VLAN and will operate independently on each VLAN.

Perhaps we would understand better if you include some specifics about how the router interface and subinterfaces are configured.

HTH

Rick

[amarsh]

I was trying to configured HSRP on cust-rtr01 & cust-rtr02 using the 4 physical interfaces on each router instead of one sub-interface for the 4 vlans, but each time i tried I had the HSRP state changes happening and not recognising the peer.

I am going to do the HSRP based on your reply and see what happens. I appreciate that my message wasn't as detailed as it should be, but your reply was what i needed to read.

It cleared up a lot of questions.

Thanks

Will post my findings tonight once atempted tonight.

[amarsh]

Rick,

Thanks again for your insight into my HSRP issue.

My update from last night is as follows:-

I configured cust-rtr01 and cust-rtr02 with there respective HSRP settings, as you will see from the config files attached. When I issued the no shut command on cust-rtr02 you will see that 2 of the 4 interfaces actually came up active/standby for fa0/0.10 & fa0/0.60 on cust-rtr01/cust-rtr02's sub interfaces, but fa0/0.32 and fa0/0.73 sub interfaces were both active/unknown on the two routers.

I also had a duplicate IP address error message, to which I know the IP in question isn't used anywhere else.

And finally, the HSRP state change occurring again by relearning mac-address.

Any feedback would be greatly appreciated.

Thanks

[Richard Burts]

Anthony

I have looked at the files that you posted. HSRP appears to be configured and working correctly for two VLANs (VLAN 10 and 73) and not working for the other two VLANs. The symptoms shown in what you posted suggest that the routers are not seeing each other on those VLANs. There are several ways that this can be checked. One thing that would be interesting would be to do show cdp neighbor (or show cdp neighbor detail) on the switch to which they are connected and see if they show up properly. Another good test would be to do an extended traceroute on r1. In the extended traceroute specify the destination as the address of r2 in VLAN 32 and specify the source of the traceroute as the address of r1 in VLAN 32. See if you get a response and see if the response comes from the VLAN 32 address of r2. Then do the same process for VLAN 60.

HTH

Rick

[amarsh]

Mr Burts,

I will try this later this evening. When I do this extended traceroute, if the response does in fact come from VLAN 32 & VLAN 60 of r2 then what should I deduce from this?

Thanks

am

[Richard Burts]

Anthony

When you do the extended traceroute I think that there are 3 possible outcomes. Here is what I think they would mean:

- get no answer. This would indicate that they are not communicating on this VLAN. Need to check to see if something is misconfigured or is not connected as it is supposed to be.

- get an answer, but the answer is not sourced from the the same VLAN interface. This would indicate that they are not communicating on that VLAN but are communicating on other VLANs and routing over the other VLANs. Need to check to see if something is misconfigured or is not connected as it should be.

- get an answer and the answer is sourced from the same VLAN interface. This would indicate that they are communicating with each other on this VLAN.

In this test it is important to control both the destination and the source address.

HTH

Rick