Hsrp

DevilWAH

Say I have 3 vlan inter faces


VLAN 10, 20 and 30

each with

standby 2 ip address 192.168.x.254 set so they are all using the same stand by group number.

what I am trying to work out is what it the interaction between the different interfaces.

is each seperate vlan a sepetate stand by group (dispite the same group number) or does a change in one vlan affect the others?

are there any benifits from having the same group number or having seperate ones?

Cheers

Aaron

AlanJames

Each vlan interface will have its own standby group

gorebrush

AlanJames wrote: »

Each vlan interface will have its own standby group

Yup

DevilWAH

Cool cheers guys,

seems a pity as I have two routers that run hsrp for about 15 vlans. idealy it would be nice to link the hsrp in to one instance as at the moment each instance has its own hello packets, but at the end of the day they are all set to fail over with the same limits.

seems more obvious to be able to have one hsrp group across mutiple interfaces, this would reduce resoruce usage.

cheers for the info though.

AAron

kryolla

DevilWAH wrote: »

seems more obvious to be able to have one hsrp group across mutiple interfaces, this would reduce resoruce usage.
AAron

how are you going to do that if each interface belongs to a specific subnet and the host default gateway belongs to that subnet.

DevilWAH

simple

you set up hsrp on int valn 1, with keep alives and an over all prority.

so this vlan is the one that send the keep alives and communicates with the other routers

then under uinterface vlan 2 you simple add an ip address to the stand by group..

then if the keep alives on vlan 1 fail, or the priority change and the hsrp switchs. all valns that have a stand by ip assigned to that group number would fail over.

in my case the two routers have an eithernet channel trunk between them. so if i have 15 hsrp groups set up they are all sending a keep alive packet down that ethernet channel, but thats 15 times more than needed, in what case would only vlan 1 fail, and vlan 15 stay up? (yes i know its possible but not really likley)

jason_lunde

DevilWAH wrote: »

simple
in what case would only vlan 1 fail, and vlan 15 stay up? (yes i know its possible but not really likley)

I dont think its so much that as why you would want that 1 router active for all of those VLANs. HSRP allows you to say R1 is primary for 1,2,3..., and R2 is primary for 4,5,6...offloading some of the "load" from both of the routers. Otherwise you sit there with 1 router doing everything (which IS the case in some places), and the other router doing nothing. I personally like to give each device a little piece of the pie.

edit: A good example of just one vlan failing...or a change occurring would be a standby group that is tracking an interface. The tracked interface goes down, thereby decrementing the group priority to a value lower than the standby router. You just want that one vlan to failover to the other router, and leave your others in place.

kryolla

HSRP operates independent from each other why would you want them as a group. It is made for redundant default gateway and each gateway is per subnet or you can load balance and have 2 default gateways and half the hosts pointing to one and the other half pointing to the other. So what if you have more traffic going across your layer 2 etherchannel due to the keepalives, isnt that what etherchannel are for to increase capacity and redundancy

DevilWAH

yes but then you would simple run 2 or 3 groups, each handeling some of the gate ways.

so vlan 1, 2 a nd 3 in group 1
vlan 4, 5 and 6 in group 2

one primare for group 1 the other for 2.

and the tracking could still work with mutiply vlans, and in generaly you are tracking the wan interface off site, ie the uplink interface so this will be common to mutiply vlans.

All i am suggesting is that there is one instance of the keep alive packet between the routers for mutiply interfaces, you could go even further .. if that keep alive packets contains the priority for each interface instance of the group, then there would be no reson why a single group can't deal with different tracking events for seperate interfaces and have some active and some stand by.

I can see the limitations of this idea but there are also benifits. It would make sence that a single group acts as a single group across the whole router. as you can set up mutily stand by groups, if you want each to be handeled seperately you use seperate group numbers, if you want to group fail over use a single group number.

much like the idea of Mulity vlan spanning tree. bundeling like things togather to reduce over heads.

in my case I have short keep alives 150msec, but in each vlan instance the same interfaces are getting tracked and the same IP sla's are running.

DevilWAH

kryolla wrote: »

HSRP operates independent from each other why would you want them as a group. It is made for redundant default gateway and each gateway is per subnet or you can load balance and have 2 default gateways and half the hosts pointing to one and the other half pointing to the other. So what if you have more traffic going across your layer 2 etherchannel due to the keepalives, isnt that what etherchannel are for to increase capacity and redundancy

I disagree, it is good practice to reduce overheads as much as possible, and to insure data is routed and switched in the most efficent method possible.

a good network design, cuts out any unnessery packets being sent across a link, and duplicated data. This should also be reflected in you configurations that should also not inclued unessery duplicated entries.

The fact you have gigabytes of spare links hanging around does not mean you have to fill it with useless data.

kryolla

DevilWAH wrote: »

I disagree, it is good practice to reduce overheads as much as possible, and to insure data is routed and switched in the most efficent method possible.

a good network design, cuts out any unnessery packets being sent across a link, and duplicated data. This should also be reflected in you configurations that should also not inclued unessery duplicated entries.

The fact you have gigabytes of spare links hanging around does not mean you have to fill it with useless data.

so you reduce overhead at the expense of additional cpu processing if it would work how you imagine it, I'll take the lan overhead thank you

Also you talke about data being routed and switched as efficient as possbile and not control traffic (HSRP keepalives) which I agree

Forsaken_GA

DevilWAH wrote: »

I disagree, it is good practice to reduce overheads as much as possible, and to insure data is routed and switched in the most efficent method possible.

a good network design, cuts out any unnessery packets being sent across a link, and duplicated data. This should also be reflected in you configurations that should also not inclued unessery duplicated entries.

The fact you have gigabytes of spare links hanging around does not mean you have to fill it with useless data.

There's a little bit of give and take. I personally prefer the modularity and the flexibility of each vlan interface having an independent configuration, and a little bit of control traffic is a small price to pay.

I agree with your stance in principle, but it needs to be tempered with a little bit of reality. Unless your links are already heavily saturated, this is a non concern. If I have a gigabit link that's only being used on average at 300/mbps and at peak only hits 600/mbps, then the link is underutilized and I'm going to do more important things with my time than play bit ****

Forsaken_GA

DevilWAH wrote: »

in what case would only vlan 1 fail, and vlan 15 stay up? (yes i know its possible but not really likley)

That's easy.

The customer on that vlan is deprovisioned and I remove all ports from their vlan, causing the interface to go down.

If it operated the way you wanted it, I'd take all redundancy down.

Or, more likely, I just flat out remove that vlan. What then?

The obvious answer is that I'd never be able to remove that vlan, if the implementation worked that way, I've just created a dependency that allows one stupid mistake to take down multiple network links.

In other words, I've created a single point of failure.

I'm sure I don't really have to explain why that's a catastrophic design flaw for a redundancy protocol

jason_lunde

Not to mention the nature of HSRP is to assign a mac-address of 0000.0c07.acxx where xx is group number in hex. In an env. that does not support per-vlan mac address tables this causes chaos. So unless the admin statics each mac...for each vlan, you have issues.

Forsaken_GA

jason_lunde wrote: »

Not to mention the nature of HSRP is to assign a mac-address of 0000.0c07.acxx where xx is group number in hex. In an env. that does not support per-vlan mac address tables this causes chaos. So unless the admin statics each mac...for each vlan, you have issues.

Not an issue. Or at least, it wouldn't be a new issue. HSRP already operates this way. Ie, if I create stand-by group 2 on vlan 1, and stand-by group 2 on vlan 2, IOS will generate the same virtual-mac for the VIP on both vlan's.

I'll let Cisco explain it better -

Q. What is the implication of using the same HSRP group ID on multiple interfaces?

A. When you define the same HSRP group ID on multiple interfaces, they share the same HSRP virtual MAC address. In most modern LAN switches, there are no issues because they maintain a per-VLAN MAC address table. However, if your network contains any third-party switches, which maintain a system wide MAC address table regardless of VLAN, you can experience problems. If VLANs are not specified to a HSRP group, the VLANs default to Group 0.

jason_lunde

Right. I was just saying that in some older networks, or with 3rd party equipment not supporting per-vlan mac-address tables, assigning the same group number per SVI would be a no-no.

Forsaken_GA

jason_lunde wrote: »

Right. I was just saying that in some older networks, or with 3rd party equipment not supporting per-vlan mac-address tables, assigning the same group number per SVI would be a no-no.

Oh, I agree, which is why I've developed the habit of using unique group numbers regardless (we use VRRP at work because we have non-Cisco switches involved with redudancy, and it has the same issue)

I was just pointing out that it's irrelevant to the idea of one interface putting out the keepalives for interfaces that are sharing group numbers, as the non-unique MAC's are something we already have to deal with.

DevilWAH

Forsaken_GA wrote: »

That's easy.

The customer on that vlan is deprovisioned and I remove all ports from their vlan, causing the interface to go down.

If it operated the way you wanted it, I'd take all redundancy down.

Or, more likely, I just flat out remove that vlan. What then?

The obvious answer is that I'd never be able to remove that vlan, if the implementation worked that way, I've just created a dependency that allows one stupid mistake to take down multiple network links.

In other words, I've created a single point of failure.

I'm sure I don't really have to explain why that's a catastrophic design flaw for a redundancy protocol

well no becasue you would just remove that Vlan interface from the stand by group, before you remove the VLAN.

the situations you are talking about require or benefit from multiply standby groups, and may have problems with the idea of a standby group spanning interfaces.

I on the other hand am in a position where it is a large switched internal network, and the core switches are running mutiply gateways, each one of which has an identical config (about 15 lines of code for the HSRP settings) for the stand by group.

I was never suggesting that this is how it should be done, just the idea of another way to approach HSRP, in the same way MVST does not replace PVST, it would be intresting (and in my case useful) to have the choice.

actuly it would be easy to do, all you need would be a command that said some thing like..

#int van 2
#standby 2 ip 192.168.1.254
#standby 2 state track standby 2 VLAN 1

where the tracking/standby config is configured on the VLAN 1 interface. so rather than send out keep alive and worry about priority's. it just keeps an eye on the local state of vlan 1's group and copies it.

CISCO SORT IT OUT... (in fact i wonder if its already there?)

so you reduce overhead at the expense of additional cpu processing if it would work how you imagine it

I not quite sure how reducing the number of stand by groups would increase CPU usage. less stand by packets to process, a single stand by group to watch, only having to track an interface once per group instance, rather than repetedly?

DevilWAH

LOL maybe like the

#standby 2 follow <HSRP group name> command??? DOH

there is also the standby BFD command, for lowering the overheads both network and CPU for mutiply standby groups running over a singel interface

The HSRP BFD peering feature introduces BFD in the HSRP group member health monitoring system. Previously, group member monitoring relied exclusively on HSRP multicast messages, which are relatively large and consume CPU memory to produce and check. In architectures where a single interface hosts a large number of groups, there is a need for a protocol with low CPU memory consumption and processing overhead. BFD addresses this issue and offers subsecond health monitoring (failure detection in milliseconds) with a relatively low CPU impact. This command is enabled by default.

Forsaken_GA

DevilWAH wrote: »

I on the other hand am in a position where it is a large switched internal network, and the core switches are running mutiply gateways, each one of which has an identical config (about 15 lines of code for the HSRP settings) for the stand by group.

I work for a web hosting company. High availability is an absolute must for us, or else our customers would leave. I have several hundred vlans with virtually identical VRRP configurations, save for the real IP and virtual IP for each group. So yes, I have many keepalive messages going across my trunk link to the secondary router. I am *quite* familiar with the situation you're describing.

actuly it would be easy to do, all you need would be a command that said some thing like..

#int van 2
#standby 2 ip 192.168.1.254
#standby 2 state track standby 2 VLAN 1

Unless I'm totally misunderstanding you, the amount of lines in the config isn't your issue. HSRP configuration isn't hard, and it's going to have to vary from interface to interface just by virtue of the fact that your real IP's and your VIP's are going to be different for each interface.

What I'm taking issue with is the idea of one interface being responsible for the keepalives for an entire group that spans multiple interfaces. That creates an unnecessary dependancy. If Vlan1 is sending out keepalives for 10 vlans, and vlan1 gets removed, then those 10 vlans are no longer sending keepalives. What are you going to do, add failover for your failover protocol? It's much more resilient to keep each interface responsible for keeping it's state, which is the entire purpose for a gateway redundancy protocol in the first place.

I think you just can't seem to conceive of a situation where your 'stable' vlan interface would ever be down. I, on the other hand, provision and deprovision vlans on a regular basis, so I can easily see a situation where chaining multiple SVI's to the state of one could cause some pretty serious problems. I understand that you may find it frustrating that you have multiple interfaces that are essentially identical configs doing identical things, but you can't lose sight of the fact that these are discrete entities and need to be treated as such.

I certainly wouldn't take issue with some sort of templating to cut down on the lines of configuration, that's not a bad idea. Creating a single point of failure whereby the other standby groups inherit their status from one particular interface is a horrible idea.

DevilWAH

see in this case the HRSP is first configured on interfaces that are the WAN links out of the site. if this interface fails, then there is no reason I ever want the router/switch to stay active for the other VLANS . there's no point the, WAN link has to be down if that interface has failed. if that single HSRP group fails it means there is no longer a route out of site.

that HSRP group fails over then end of story, move every thing to the second core switch.. I don't need to check if the other core switch is up or not, if its not then its no loss the primary switch is still going to be down..

IE are my WAN ports up, can i reach remote IP's through them? If I can good, if I can't every thing currently active fail over to the secondary switch. I only need the HSRP running on those physical interfaces to do it. If i set up mutiply standby groups or simply have all VLANS follow one. my single point of failer still my WAN links they are they have ultermate control.

So in my case the standby group I want to follow is God.

PS. if anyone is silly enough to, first of all set up something like this, where there is the potential of someone removing a VLAN with out fully understanding the implications. And secondly you have someone working on the network that makes changes with out first confirming what effect it will have on a network.. They should not be working on the network in the first place.

Forsaken_GA

DevilWAH wrote: »

see in this case the HRSP is first configured on interfaces that are the WAN links out of the site. if this interface fails, then there is no reason I ever want the router/switch to stay active for the other VLANS . there's no point the, WAN link has to be down if that interface has failed. if that single HSRP group fails it means there is no longer a route out of site.

Ok, well I'll start with the obvious flaw in this scenario - what if you're multihomed? I have 8 10 gig circuits on each core router from 5 different providers. I'm going to fail over all of my traffic to the backup router just because level3 decided to bounce my circuit? Or because someone at the facility accidentally unplugged the wrong circuit in the MDF?

And really? You have absolutely no intervlan communication? You honestly want all of your vlans to take an unnecessary failover just because your WAN circuit goes down? Did you not implement your IGP well enough to send egress traffic to the other router in the event that your primary WAN circuit goes down?

Forsaken_GA

DevilWAH wrote: »

PS. if anyone is silly enough to, first of all set up something like this, where there is the potential of someone removing a VLAN with out fully understanding the implications. And secondly you have someone working on the network that makes changes with out first confirming what effect it will have on a network.. They should not be working on the network in the first place.

And if you expect everyone working on a network to never ever make any mistakes, you shouldn't be managing one. Yes, people shouldn't make mistakes. Problem is, people do. It's one of those things about being human we don't like to talk about!

I understand I may be coming across as hostile, but I'm not trying to be a dick. I just have my head firmly rooted in practicality. I'm not trying to bring you down a few pegs, and I'm not on an ego trip, I'm trying to get you to understand why this idea is not so good, and I guess I'm a little frustrated in expressing that.

DevilWAH

LOL no worries mate, and me neither. Its good to share ideas about networks, no one has every learnt it all on there own..

I do see the problems with my approach, but in my situation I do think the benefits out weight the downsides. And like you mention the problem with some one deleting a vlan, in the same way you can argue the issue of miss typing a config entry (even using copy/pate and note pad) there's always room for the human error factor.

I think one of the issues is you are supporting a large number of quite dynamic external customers with a lot of routing I can Imagen. Where as In my network it all internal and mainly quite static. And I'm also looking at this from the switch point of view, which i am sure gives me a different perspective. Although I would not say an any better.

I know i will be using both of these solution, I know some of my network needs the granularity of indivual groups, but I can also see that the simplification of configs and the network design itself by using the "Follow" command is espicaly in the short term while I am making some major topology changes. is going to be useful.

little bit of this and a little bit of that, its what its all about

I like to find out all the possible ways to do some thing, before I decide how I will actuly do it. rest asured all you comments are bouncing around my head will all the rest at the moment as I'm thinking.. "yer that link needs to be like that, and that one I can be like that. that one don't worry about cause it will be gone after I set that up.... etc..."

Cheers for the input dude.

ConstantlyLearning

Been reading up on HSRP over the last few days.

Could someone explain the below a bit more please?

"When you define the same HSRP group ID on multiple interfaces, they share the same HSRP virtual MAC address. In most modern LAN switches, there are no issues because they maintain a per-VLAN MAC address table. However, if your network contains any third-party switches, which maintain a system wide MAC address table regardless of VLAN, you can experience problems."

I have two VLAN interfaces in the same group. According to the above, regardless of whether a device from VLAN10 or VLAN20 ARP's for their respective VLAN's virtual ip address's mac address, they will get the same virtual mac address.

I'm not sure why this isn't a problem with per-vlan mac address tables and is without?

Cheers.


Output from show standby on a 3550:

Vlan10 - Group 1
Local state is Standby, priority 100, may preempt
Hellotime 200 msec, holdtime 800 msec
Next hello sent in 0.052
Virtual IP address is 10.0.10.1 configured
Active router is 10.0.10.2, priority 150 expires in 0.640
Standby router is local
13 state changes, last state change 12:41:39
IP redundancy name is "hsrp-Vl10-1" (default)
Vlan20 - Group 1
Local state is Active, priority 150, may preempt
Hellotime 200 msec, holdtime 800 msec
Next hello sent in 0.074
Virtual IP address is 10.0.20.1 configured
Active router is local
Standby router is 10.0.20.2 expires in 0.636
Virtual mac address is 0000.0c07.ac01
2 state changes, last state change 01:24:13
IP redundancy name is "hsrp-Vl20-1" (default)

DevilWAH

the switch stores its mac addresstabels some thing like this

mac addres a = ip address x
mac address b = ip address y
mac address c = ip address z
etc

now on a switch that has a gloable address list his will happen, lets assume mac address b is the address used by HSRP.

mac address a = ip addres x
mac address b = ip address y
mac addres b = ip address z

ie the mac address would appear twice in the same table with multiply ip address assigned to it. This would generally be consider an error to have multiply IP addresses assigned to a single mac address.

if the switch has per-vlan mac tables then you don't get the problem as the switch only sees the mac address once per VLAN instance. So each mac address table only has one instance of the mac address in it.

also imagen if you have switch A as active for VLAN 1 and switch B active for VALN 2.

with out separate mac address tables, other switches in the network may see the mac address comming in on two separate interfaces. This is bad, its often known as flapping, as it either suggests a loop in the network or two copies of a mac address on the network, and as the switch uses its mac address table to forward frames, if it sees one on two seperate inetfaces and it can't see different vlan's how does it know what interface to forward a frame out to?

Forsaken_GA

ConstantlyLearning wrote: »

I'm not sure why this isn't a problem with per-vlan mac address tables and is without?

Alright, well ask yourself this - Why do MAC addresses need to be unique? If more than one node has the same MAC address, then confusion about where to send the traffic ensues.

If a switch is storing mac address tables on a per vlan basis, then the HSRP non-unique mac isn't an issue, because while globally the mac may not be unique, logically for a given VLAN, it is. If a switch doesn't maintain that seperation, but instead only maintains a global mac address table, you've got the potential for problems.

alicesmile

i like it so much

deth1k

DevilWAH wrote: »

Cool cheers guys,

seems a pity as I have two routers that run hsrp for about 15 vlans. idealy it would be nice to link the hsrp in to one instance as at the moment each instance has its own hello packets, but at the end of the day they are all set to fail over with the same limits.

seems more obvious to be able to have one hsrp group across mutiple interfaces, this would reduce resoruce usage.

cheers for the info though.

AAron

Use a routing protocol instead of HSRP to provide redundancy.

DevilWAH

deth1k wrote: »

Use a routing protocol instead of HSRP to provide redundancy.

How does a routing protocol provide physical redundency for the router holding the DFGW of the clients?