Solved: Re: HSRP Problem

lamav · ‎07-16-2008

R1:

interface FastEthernet0/0

description *** LAN Connection to Client Router ***

ip address 172.27.101.129 255.255.255.192 secondary

ip address 10.0.102.11 255.255.255.0

ip access-group CLIENT.LAN.ACL in

no ip redirects

no ip proxy-arp

ip nat inside

ip virtual-reassembly

ip route-cache flow

ip tcp adjust-mss 1360

duplex full

speed 100

standby 17 ip 10.0.102.10

standby 17 timers 1 3

standby 17 priority 105

standby 17 preempt

standby 17 authentication XXXX

standby 17 name HSRP17

standby 17 track ATM0/0/0.551

standby 17 track Tunnel10551

standby 17 track 10

service-policy input MARKING-LAN-INGRESS

!

interface FastEthernet0/1

description Healing Link -> R2

ip address 172.22.142.173 255.255.255.252

ip nat inside

ip virtual-reassembly

duplex full

speed 100

R1> sh standby

FastEthernet0/0 - Group 17

State is Active

Virtual IP address is 10.0.102.10

Active virtual MAC address is 0000.0c07.ac11

Local virtual MAC address is 0000.0c07.ac11 (v1 default)

Active router is local

Standby router is unknown

R2:

interface FastEthernet0/0

description *** LAN Connection to Client router 2 ***

ip address 172.27.101.130 255.255.255.192 secondary

ip address 10.0.102.12 255.255.255.0

ip access-group CLIENT.LAN.ACL in

no ip redirects

no ip proxy-arp

ip nat inside

ip virtual-reassembly

ip route-cache flow

ip tcp adjust-mss 1360

duplex full

speed 100

standby 17 ip 10.0.102.10

standby 17 timers 1 3

standby 17 preempt

standby 17 authentication XXXX

standby 17 name HSRP17

service-policy input MARKING-LAN-INGRESS

!

interface FastEthernet0/1

description Healing Link -> R1 Fa0/1

ip address 172.22.142.174 255.255.255.252

ip nat inside

ip virtual-reassembly

duplex full

speed 100

R2> sh standby

FastEthernet0/0 - Group 17

State is Active

Virtual IP address is 10.0.102.10

Active virtual MAC address is 0000.0c07.ac11

Local virtual MAC address is 0000.0c07.ac11 (v1 default)

Active router is local

Standby router is unknown

Here goes...seems like R1 and R2 are not exchanging HSRP hellos because each router is calling himself the "active" one and neither sees the other (standby unknown).

For both routers to NOT be exchanging HSRP Hellos, that would mean that the L2 link between the 2 routers is lost/non-existent. IOW< the common subnet requirement is violated.

Sound right?

Thats what I thought, but if I do an ARP lookup on R1 for R2s LAN interface (102.12), it DOES see the MAC address for 102.12. So, that must mean that there IS L2 connectivity between the 2.

Is that correct?

If so, what the heck is going on?

HELP!!!!! :-)

VL

Kevin Dorrell · ‎07-16-2008

Victor,

By L3, I really mean that there should be nothing "layer-3" that would stop the communication, for example an IP access list. I guess I was a bit loose with my terminology there.

I think the most likely explanation is the authentication issue, for example trailing spaces. That can happen, for example, if you type the password then a space then '?' to see if there are any more parameters. You find there are not, so you just ENTER. VoilÃ , a trailing space on the password.

I suppose also if somone had done something to the switch that interferes with the multicast distribution, that would also stop the HSRP (and a lot of other useful stuff) working.

Kevin Dorrell

Luxembourg

View solution in original post

Kevin Dorrell · ‎07-16-2008

My guess is it's something to do with that access-group, or the service-policy. Have you tried logging the drops at the end of the access-list?

Kevin Dorrell

Luxembourg

lamav · ‎07-16-2008

Hey, Kevin.

I was thinking along those lines, too...

The access list applied to those HSRP LAN interfaces is the following:

ip access-list extended CLIENT.LAN.ACL

permit ip any 10.0.0.0 0.255.255.255

permit udp host 10.0.102.12 eq 1985 host 224.0.0.2

That ACL exists on both routers (The source for the HSRP packets for the ACL on the other router is 102.11, of course) and is applied to the LAN interfaces of both routers, as you can see above.

So, it seems that -- at least as far as the config is concerned -- the HSRP Hellos should be getting through to both ends.

Unfortunately, I dont have permission to go into config mode or run any debugs, else I would have debugged HSRP hellos.

Is there any other reason why each router would be calling itself the HSRP active router and not seeing the other BESIDES a loss of L2 connectivity between them? <----Barring a misconfig, of course, which you can check out above and see if there is one....

Kevin Dorrell · ‎07-16-2008

Mmm, that looks as though it should work.

I know it sounds a daft question: one of the access lists has 10.0.102.11 and the other has 10.0.102.12, right? Are they the right way round?

Are we sure that HSRP uses 1985 as a source port as well as a destination? Although I cannot imagine why it would use any other port as source.

Also, the service policy ... is that transparent?

As to your last question, I am working on the lines of "Yes there is .... loss of L3 or multicast connectivity." The ARP is working, so you seem to have L2 working. (Does the ARP work both ways?)

As a last resort, the authentication password: have you checked the spelling, and that there are no trailing spaces?

Kevin Dorrell

Luxembourg

lamav · ‎07-16-2008

Kevin:

1. Yes, the ACL addresses are correct.

I thought it was funny to create an ACL thatmatched on the source port of 1985. I would have matched 1985 as a destination port, no? But I didnt configure it.

permit udp host 10.0.102.11 224.0.0.2 1985 (NO?)

2. Service policy is nothing. Just setting dscp markings....

3. Let me ask you this retarded question then...Im getting confused:

For HSRP to work between a pair of routers, do you need an L3 link between them? I know -- and weve discussed -- that there is a need for L2 connectivity (common subnet), but how about a routed link between HSRP routers?

4. Each router can PING their HSRP partner.

Im starting to think that there is an authentication issue. Cant run debugs now.

Thanks

VL

Kevin Dorrell · ‎07-16-2008

Victor,

By L3, I really mean that there should be nothing "layer-3" that would stop the communication, for example an IP access list. I guess I was a bit loose with my terminology there.

I think the most likely explanation is the authentication issue, for example trailing spaces. That can happen, for example, if you type the password then a space then '?' to see if there are any more parameters. You find there are not, so you just ENTER. VoilÃ , a trailing space on the password.

I suppose also if somone had done something to the switch that interferes with the multicast distribution, that would also stop the HSRP (and a lot of other useful stuff) working.

Kevin Dorrell

Luxembourg

lamav · ‎07-17-2008

Thanks everyone.

Appreciate your time.

Victor

lamav · ‎07-17-2008

Gotcha.

Thanks, buddy...

VL

Edison Ortiz · ‎07-16-2008

In addition to the ACL suggestion by Kevin, you can also verify the HSRP authentication between devices.

A space at the end of a password (often a common problem with authentication) does make a difference.

To answer your question, if the HSRP peers can't see each other, they will both be 'active' since they don't know of any other HSRP router in the network.

HTH,

__

Edison.

keeleym · ‎07-16-2008

Hi There

Not sure whether or not you have looked at this document already, but if not it may be useful.

http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094afd.shtml#t2

It seems to suggest that mismatched VTP modes can cause this problem. Maybe this is something to check.

HTH

Best Regards,

Michael

Giuseppe Larosa · ‎07-16-2008

Hello,

to verify layer 2 and layer 3 connectivity a ping test is enough if 10.10.102.11 can ping 10.10.102.12 there is no L2, L3 connectivity issue.You can also check MAC addresses and ARP tables.

For the ACL could be an idea to enable the whole udp to dest 224.0.0.2

Authentication can be the problem.

I think you can use some debug command to see what happens

use debug standby

Hope to help

Giuseppe