Re: HSRP & subinterface issue.

gills · ‎02-13-2006

We have 2 2600s routers running hsrp, with two switches (4006) in between running trunking 802.1q. The trunking is working fine, the hsrp groups are set up on 1 interface and 1 subinterface on the routers.

When this is set up, 1 hsrp group works as it should, the other is active at both ends, causing 2 interfaces to flap in one of the switches due to it learning the same mac address from different interfaces.

If we take off the subinterfaces, we can get the hsrp working as it should trying both vlans and groups.

We can't get the hsrp to work when using the interface and vlan subinterfaces. The config is below.

Router 1

interface FastEthernet0/0

no ip address

no ip directed-broadcast

speed 100

full-duplex

interface FastEthernet0/0.2

description Vlan 2

ip address 192.168.16.1 255.255.255.0

encapsulation dot1q 2

no ip redirects

no ip directed-broadcast

speed 100

full-duplex

standby 2 priority 120 preempt

standby 2 ip 192.168.16.2

interface FastEthernet0/1

description VLAN 3

ip address 192.168.17.1 255.255.255.0

no ip redirects

no ip directed-broadcast

speed 100

full-duplex

standby 3 priority 120 preempt

standby 3 ip 192.168.17.2

Router 2

interface FastEthernet0/0

no ip address

no ip directed-broadcast

speed 100

full-duplex

interface FastEthernet0/0.2

description Vlan 2

ip address 192.168.16.10 255.255.255.0

encapsulation dot1q 2

ip helper-address 10.169.21.20

ip helper-address 10.181.3.20

no ip redirects

no ip directed-broadcast

speed 100

full-duplex

standby 2 priority 100 preempt

standby 2 ip 192.168.16.2

interface FastEthernet0/1

description VLAN 3

ip address 192.168.17.10 255.255.255.0

no ip redirects

no ip directed-broadcast

speed 100

full-duplex

standby 3 priority 100 preempt

standby 3 ip 192.168.17.2

Any ideas why hsrp does not work when we are using the subinterface?

Cheers,

Gills

lgijssel · ‎02-13-2006

Your config looks correct. The most likely problem is that the intermediate switch-network does not forward frames for vlan2. Either is the attached switchport not connect as a trunk or vlan2 is not known on the switch.

Step one to resolve this would be to remove hsrp and verify ip connectivity between both fa0/0.2-interfaces.

If this works (which I expect to fail initially) you can reapply the HSRP config. Reconfigure the the switch as required and try again.

Regards,

Leo

gills · ‎02-13-2006

Thanks for your response. The problem seems to be when we have multiple subinterfaces. We can have 1 standby group as active/standby on the subinterface, but any other subinterfaces with hsrp configured would be active/active, this was the case using vlan 2 and 3.

Both vlans pass on the existing trunk between the the switches.

We have tested ip connectivity and this is working ok.

Do you have any other ideas?

Thanks,

Gills

lgijssel · ‎02-13-2006

This could perhaps be an issue with the sw feature set. I noticed with an 8xx series last year that VLAN support is limited on a standard image. You will need adv ip services or similar to use multiple vlans.

Of course, this is just a theory, will need the running feature set to be sure but in my case, I found that the system lets you configure everything completely, the only thing is that is simply doesn't work. Very annoying.

Regards,

Leo

gills · ‎02-13-2006

Thanks for your response. The problem seems to be when we have multiple subinterfaces. We can have 1 standby group as active/standby on the subinterface, but any other subinterfaces with hsrp configured would be active/active, this was the case using vlan 2 and 3.

Both vlans pass on the existing trunk between the the switches.

We have tested ip connectivity and this is working ok.

Do you have any other ideas?

Thanks,

Gills

vladrac-ccna · ‎02-13-2006

I'm not sure if this will work, but you could try to change the mac-address of the subinterface with the command:

(config-if)# mac-address

Also, could you provide us the output of the debug standby command using all the options?

Just part of if, showing the erros, and the hellos from both sides?

Regards,

vlads

amaitre · ‎02-13-2006

Hi Gills

Leo has a point there, it's very likely to be a feature set problem. I know that if you have IOS 12.0 below 8.1, HSRP is not supported on 802.1Q subinterfaces. Could you give us you IOS version?

Pls rate all posts

Antoine

gills · ‎02-14-2006

Hi,

It is a good point, and the IOS is old, Version 12.0(5)T1. This had crossed my mind, but I found a page on the web site that said 12.0(8.1)T or later supported HSRP....it could be that it just does not support the 802.1q subinterface, I have so far failed to find anything else on it.

Running debugs and upgrading the IOS is my next step, and this will be carried out shortly. I have to jump through hoops at work to do this kind of stuff...change management is a pain...

The other router is running 12.2(1c).

Cheers,

Gills

lgijssel · ‎02-14-2006

Hi Gills,

First of all thanks for rating my posts. That seems to be a rare habit these days.;-)

Reading your response I get the impression that you are looking at the specific version of your IOS. This might be an issue as well but what I meant was the feature set i.e. ip-base or advanced ip services

My thought was that ip base does not support more than one interface (either vlan or physical) on a router port. You can configure it but it doesn't work.

Regards,

Leo

amaitre · ‎02-14-2006

Hi Leo,

All recent IOS version support subinterfacing on router physical interfaces. The issue here is about HSRP not supporting subinterfaces in his old IOS version.

regards,

Antoine

gills · ‎02-14-2006

Sorry, I forgot to add that to my message, both are running IP Plus.

raarons · ‎02-14-2006

Time for some simple debugging.

On the sub-interface when both nodes are active, what happens when you apply

debug standby

Are both nodes sourcing HSRP hellos?

If so, is the lower-priority node seeing its peer's inbound hellos? My bet is that it isn't.

If it isn't, trying reversing the HSRP priorities. Do the debugs show the same problem in the other direction?

One final thing to try. I had some vaguely similar problem - on pretty much the same kit and probably similar code versions - which was cured by configuring "standby use-bia". It's only vague now because it was a long time ago and my memory isn't what it was, so I can't recall the precise reason, but I do remember the fix. Try it and see.